Coding

Ich hasse Spam - Du doch auch, oder? (Botnetzbetreiber lesen bitte gleich den nächsten Artikel)!
Da ja bekanntlich die bösen Bots (nein, ich meine an dieser Stelle nicht den Googlebot ) wehrlose Webseiten nach eMail-Adressen durchgrabben, um diese dann für Spammings zu verwenden bzw. zu 100k-Blöcken oder sowas an hochseriöse Firmen für das Taschengeld eines 15-Jährigen zu verticken, sollte man heutzutage seine eMail-Adresse nicht mehr im Klartext oder gar als mailto: - Link auf der eigenen Website platzieren.

Viele Webmaster greifen zu tollen Grafiken, die dann die Mailadresse darstellen - i.d.R. sehen diese aber irgendwie nicht so toll aus und entsprechen nicht dem Design der Homepage. Auch bei Schreibweisen wie "name[at]domain.de", "name(at)domain.de" oder "name.at.domain.de" kann man sich wohl kaum sicher fühlen - schließlich sind das 2 Zeilen Code, die der Botbetreiber ändern muss, um so etwas auslesen zu können. Ein wenig effektiver erscheint mit da noch die Variante "name at domain dot de", denn das könnte ja auch ein normaler Text sein. Dennoch wird das sicherlich auch schon längst erkannt und mit in die Spamdatenbanken aufgenommen.

Deshalb nutze ich seit Jahren eine kleine JavaScript-Funktion mit dem Versuch, das Ganze zu umgehen:

function mail_me() {

pt1 = "robert";
pt2 = "klikics";
tld = "de";
window.location = "mailto:" + pt1 + "@" + pt2 + "." + tld;
}

Idealerweise sollte man den Funktionsnamen und die Variablennamen (pt1, pt2 & tld) immer mal verändern, wenn man es auf verschiedenen Websites einsetzt. Prinzipiell denke ich aber schon, dass die Spambots dies nicht auslesen können. Und die Besucher können den Link im Stile javascript:mail_me() wie gewohnt anklicken.

Mittels PHP ist es ebenfalls möglich, eine eMail zu kodieren:

function mask_email($email) {

$masked_mail = "";

for($i = 0; $i < strlen($email); $i++) {

$char = $email{$i};
$masked_mail.= "&#".ord($char).";";
}

return $masked_mail;
}

Bei dieser Variante wird die jeweilige ASCII-Kodierung genutzt. Meine eMail-Adresse lautet dann &#114;&#111;&#98;&#101;&#114;&#116;&#64;&#107;&#108;&#105;&#107;&#105;&#99;&#115;&#46;&#100;&#101;.
Natürlich kann kein Mensch, der nicht gerade Obergeek oder sowas ist, diese Kodierung lesen, um eine Mail an den dahinter verborgenen Empfänger abzusetzen. Zum Glück wissen aber die Browser etwas damit anzufangen, weshalb man via mailto:[kodierte Zeichen] problemlos eine Mail an den Empfänger absetzen kann. Natürlich kann ich nicht garantieren, dass die Spambots dies nicht auch schon verstehen, allerdings bestehen daran berechtigte Zweifel ... in diesem Sinne: "Fight for a spamfree world!" - oder so ähnlich

Ich benutze seit einer ganzen Weile den Loadbalancer pound, da dieser sehr wenige Ressourcen benötigt, selbst wenn die Seite stark frequentiert ist. Außerdem ist es sehr bequem, da dieser auch als SSL-Proxy arbeitet, d.h. man muss die Keys nur auf dem Loadbalancer einspielen und die Backends arbeiten normal mit HTTP auf Port 80 weiter. Alles in Allem eine sehr runde Sache, die ich ruhigen Gewissens weiterempfehlen kann.

Natürlich will ein Statistik-Freak wie ich dann auch wissen, wieviele Requests pro Sekunde der LB abarbeiten muss. Pound bietet zwar mit dem Tool poundctl seit einigen Versionen ein Kommandozeilentool, mit dem man die Vitalität der Backende sowie die Anzahl der aktiven Sessions monitoren kann, die Requests pro Sekunde lassen sich aber nicht ohne Weiteres herausfinden. Also musste eine kleine Scriptlösung her, um die Werte für das Monitoring-Tool cacti aufzubereiten. Wenn man Logging aktiviert hat (pound unterstützt verschiedene Loglevel, u.a. auch Apache-Style), ist das kein Problem. Allerdings wird das Logfile sehr groß, wenn man viele Requests hat. Im Apache-Format schnell mal 10 GByte/Tag - und i.d.R. hat man in einem LB nicht gerade 500er Platten verbaut

Also das Logging ein wenig reduziert (Loglevel 3 in der Config), so dass nur IP und Aufruf in je einer Zeile geloggt werden. Damit halbiert man die Größe des Logfiles ca. um die Hälfte. Mit einem kleinen PHP-Script kann man dann einfach aus der /var/log/daemon.log die Anzahl der Zeilen je Sekunde bzw. Minute herausfinden. Und so sieht das Ganze dann aus:

$tstamp = date("H:i", strtotime("-1 minute"));
$call = "tail -n 200000 /var/log/daemon.log|grep $tstamp|wc -l";
$num = `$call`;
$num = $num / 60;

echo round($num);

Damit werden die Requests pro Minute ermittelt und dann durch 60 geteilt, um den Wert je Sekunde zu bekommen. Wie man das Script dann ganz einfach in cacti einbindet, wird hier beschrieben.

Nach meiner Veröffentlichung dieses kleinen Codefetzens in der pound-Mailingliste hat Bob Apthorpe sich gleich noch hingesetzt und das Ganze in Perl gebaut, so dass man es einfach als Daemon laufen kann. Sein Script samt Doku ist hier zu finden. Beide Lösung geben die gleichen Werte zurück, so dass es eigentlich keine Rolle spielt, welches man verwendet. Ich nutze die PHP-Lösung und frage einfach von meinem Cacti-Server mit einem weiteren Miniscript via ssh loadbalancer php script.php aller 5 Minuten den Wert ab.

Und so sieht das Ganze dann als Graph im Cacti aus: