Hin und wieder ist es nötig, aber ein bisschen Respekt hat man doch jedesmal wieder davor — und checkt fünfmal, dass man es auch auf der richtigen Maschine ausführt… :

dd if=/dev/zero of=/dev/sda bs=10240
dd if=/dev/zero of=/dev/sdb bs=10240

Und tschüß

Immer wieder versuchen nervige Script-Kiddies, Spam-Bots oder sonstige bösgestimmte Zeitgenossen, durch viele Anfragen an Webserver in sehr kurzer Zeit deren Funktion zu beeinträchtigen und die Auslieferung der Inhalte an „normale“ Besucher dadurch zu erschweren oder gar ganz zu verhindern.
Heutzutage generieren sich viele Webprojekte aus dynamisch erzeuten Seiten; die Bildung der Inhalte benötigt daher Rechenzeit und Speicher auf derm Webserver, was das DoS-Problem verstärkt. Durch zu viele Anfragen in zu kurzer Zeit steigt die CPU-Auslastung an und in ungünstigen Situation ist kein Seiteaufbau mehr möglich, da dem Server der RAM ausgeht.
Um hier Entlastung zu bringen wurde das Apache-Modul mod_evasive entwickelt (Download-Mirror), welches die maximal möglichen Verbindungen pro IP-Adresse kontrolliert und im Bedarfsfall abblockt. (weiterlesen…)

Vielleicht standet ihr auch schon vor dem Problem: die URL-Struktur einer Webpräsenz hat sich geändert, Skripte, welche Inhalte dynamisch generieren, liegen an anderen Orten und u.U. hat sich auch die Struktur der zu übergebenden GET-Variablen geändert.
Prinzipiell eigentlich kein Problem, schließlich sollten die dynamischen Inhalte aus dem Gesamtkontext mit der neuen Struktur erzeugt werden; anders sieht es jedoch aus, wenn es sich bei den Skript-Dateien um wichtige Inhalte handelt, die auch bei Google schon gut indiziert sind.
Es wäre ärgerlich, wenn die bei Google geführten Links nicht mehr gültig sind und ins Leere laufen – oder sogar 404-Fehler erzeugen.
Um die Struktur von Web-Präsenzen auf neue Ziele „umzubiegen“ bietet sich ein Regelwerk in der sogenannten .htaccess-Datei an.
Leider ist die Umleitung von GET-Variablen nicht ganz trivial.
Der erste Gedanke wäre z.B. folgende Lösung, um die Parameter des Skripts datei.php — param1 sowie param2 auf die neue Location umzuleiten:

RewriteRule ^datei\.php\?param1=([^&]+)&param2([^&]+) /neu/datei/$2/$1 [R=301,L]
#falsch!!

So klappt es leider nicht, da mod_rewrite diese Behandlung von QueryParametern nicht toleriert.
Der richtige Ansatz läuft über Analyse des QueryStrings, um die GET-Parameter zu separieren:

RewriteEngine On 
RewriteCond %{QUERY_STRING} ^param1=([^&]+)&param2=([^&]+)$ 
RewriteRule ^datei\.php$ /datei/%2/%1? [R=301,L] 

Per %n wird hier auf die ‘Variablen’ der vorigen RewriteCond zugegriffen.
Nach diesem Muster lassen sich auch anspruchsvolle Umstukturierungen “google-freundlich” durchführen. Beispiele für weitere Rewrite-Methoden gibt es in der Apache-Dokumentation.

Wer sich schon einmal näher mit Spamassassin beschäftigt hat wird wissen, dass dieses hilfreiche Werkzeug die durchgeleitete eMail mittels verschiedener Algorithmen bewertet und während der Ausführung der diversen Tests bei passender Konfiguration die als positiv erkannten Spamerkennungs-Treffer durch Schlagworte im Mailheader anzeigt.
Ein Beispiel:

X-Spam-Status: No, score=-1.5 required=8.8 tests=AWL,BAYES_00,
    FORGED_RCVD_HELO,HTML_90_100,HTML_IMAGE_RATIO_02,HTML_MESSAGE,
    SPF_HELO_PASS autolearn=no version=3.1.1

Die Stichwörter besitzen zwar einigermaßen sprechende Namen, manchmal wäre es aber doch hilfreich, nähere Details über den positiven Treffer zu erhalten.
Hier eine Auflistung der am häufigsten anzutreffenden Schlüsselworte mit Erklärung und Ort der Erkennung:
(weiterlesen…)

Schon vor gut 1 1/2 Jahren startete das Projekt roundcube mit der Umsetzung eines Webmail-Clients, der die einfachen Zugriff über jeden Webbrowser mit dem Komfort & den Features einer Offline-eMail-Anwendung kombiniert.
Möglich macht dies der konsequente Einsatz von AJAX-Technologie, wodurch das bei älteren Vertretern (wie z.B. Horde) übliche andauernde Neuladen kompletter Seiten und den damit verzögerten Arbeitsablauf ausgleicht.
Obwohl die Versionsnummer mit 0.1-beta2 noch sehr niedrig angesiedelt ist, und sich das Team mit der Veröffentlichung neuer Meilensteine einige Zeit lässt, lohnt sich vor allem der Blick auf den aktuellen Entwicklersnapshot per SVN.
Hier finden sich zumeist wesentlich mehr implementierte Funktionen als in den mit ’stable’ deklarierten Versionen – und trotz Dev-Status lassen sich die SVN-Versionen meist ohne Probleme einsetzen.
roundcube eignet sich für alle Server, die Zugriff über IMAP bieten und stellt dem Nutzer bisher u.a. Ordnermanipulationen, MIME-Unterstützung, Adressbuch, Drag’n'Drop, Suche, Rechtschreibprüfung etc. an.
Nach der Installation kann z.B. die Webmail-Funktion von Plesk von Horde auf roundcube „umgebogen“ werden. Der einfachste Weg besteht in einer Anpassung der Apache-Konfiguration von Plesk. Bei Debian befinden sich die Einträge in /etc/apache/conf.d/zz010_psa_httpd.conf
Dort finden sich sowohl für http- als auch für https-Zugriff auf webmail.domain.de Einträge, die auf Horde verweisen: DocumentRoot /usr/share/psa/horde, sowie die Freigaben des PHP-openBaseDir. Diese Verweise müssen einfach auf den Ordner von roundcube geändert werden (z.B. /usr/share/roundcube), und schon kann der übliche Webmail-Account von Plesk mit roundcube genutzt werden.

Neben der Erkennung von Spam über die herkömmlichen Regelsets von Spamassassin, dem Selbsttraining mittels Bayes und dem Abgleich bei bekannten Anti-Spam-Netzwerken wie razor2 oder pyzor, bietet es sich an, den Mailverkehr auch gegen die NiX-Spam-Liste des iX-Teams aus dem Hause Heise abzuprüfen.
NiX-Spam bietet eine ständig erweiterte Hash-Datenbank alter und neuer Spaminhalte. Mittels eines einfachen Plugins können wir aus Mails, die Spamassassin durchlaufen, einen Hash-Abgleich mit der online verfügbaren NiX-Spam-Liste durchführen lassen. (weiterlesen…)