Unter der Lupe
Was wäre ein sauber arbeitender Daemon ohne Logging und Debugging-Funktionalität. Unter OpenBSD stehen in Bezug auf Spamd zwei Userland-Tools sowie eine Logdatei zur Analyse des Spamd-Systems bereit. »pfctl« dient als Schnittstelle zu PF und klärt über den Inhalt der Tabellen auf. Die Manpage »pfctl(8)« erklärt die mächtige Syntax im Detail. »spamdb« zeigt den Inhalt der Spamd-Datenbank oder führt mit zusätzlichen Parametern Änderungen daran durch. Die wichtigsten Kommandos listet Tabelle 1 auf.
|
|
|
Befehl
|
Erklärung
|
|
sudo pfctl -t spamd-white -Ts
|
Zeige alle IPs der Tabelle »spamd-white«
|
|
sudo pfctl -t spamd-white -Ta $IP
|
Füge IP-Adressen der Tabelle »spamd-white«
hinzu
|
|
sudo pfctl -t spamd-white -Td $IP
|
Entferne IP-Adressen von der Tabelle spamd-white«
|
|
sudo pfctl -t spamd-white -Tt $IP
|
Teste, ob die Tabelle »spamd-white« die IPs
enthält
|
|
spamdb | grep ^GREY
|
Zeige alle Einträge mit Greylisted-Status
|
|
spamdb | grep ^WHITE
|
Zeige alle Einträge mit Whitelisted-Status
|
|
spamdb | grep ^BLACK
|
Zeige alle Einträge mit Blacklisted-Status
|
|
sudo spamdb -a $IP
|
Whiteliste IP-Adresse
|
|
sudo spamdb -d $IP
|
Entferne IP-Adresse aus der Datenbank
|
Die Ausgabe von »spamdb« lässt sich leicht parsen. Tabelle 2 zeigt einige Beispieleinträge. Die Spalten »first«, »pass« und »expire« zählen die Sekunden seit Epoch. Die drei Zeitstempel geben an, wann die Software den Sender erstmals registrierte, wann die IP zum Status »WHITE« wechselte und wann der »WHITE«-Status auslaufen wird. Bei einem »GREY«-Eintrag sind deshalb die letzten beiden Daten identisch.
Der »block«-Zähler zeigt an, wie häufig Spamd den Host mit dem Antwortcode »451« abgespeist hat. Wie viele Male die IP zum Backend-MTA durchgelassen wurde, protokolliert »spamlogd« im »pass«-Zähler, hier natürlich ebenfalls noch Null. Das Format für »WHITE«- und »TRAP«-Einträge ist ähnlich, unterscheidet sich aber in der Anzahl Felder. Datensätze mit dem Status »BLACK« sind nicht explizit aufgeführt, denn Tupel mit diesem Wert stehen nicht in der Datenbank.
Logfiles
Die vom Spamd-Daemon protokollierten Meldungen finden sich in »/var/log/daemon«. Der Greyscanner kann so konfiguriert werden, dass er in dieselbe Datei schreibt (Listing 3). Zeile 1 zeigt den Verbindungsaufbau einer unbekannten IP. In Klammern steht die Zahl der derzeitigen Spamd-Verbindungen und die der sich im Tarpit befindlichen IPs.
01 Oct 9 14:06:47 mygate spamd: 81.143.30.46: connected (46/35)
02 Oct 9 14:06:49 mygate spamd: 91.122.70.203: disconnected after 12 seconds.
03 Oct 9 14:06:49 mygate spamd: 83.22.246.134: disconnected after 81 seconds. lists: spamd-greytrap
04 Oct 9 14:06:50 mygate spamd: 195.117.152.136: connected (45/34), lists: uatraps
05 Oct 9 14:06:53 mygate greyscanner: Scan started
06 Oct 9 14:07:17 mygate greyscanner: scanned 9866 whitelisted, 4506 trapped, 1475 unique greys
07 Oct 9 14:14:17 mygate greyscanner: Trapped 124.121.75.161: Host sending from 14 domains (> 3)
08 Oct 9 14:14:17 mygate greyscanner: Trapped 67.234.218.185: Invalid source address Matthias (rfc822)
09 Oct 9 14:14:21 mygate greyscanner: Scan completed
|
Zeile 2 protokolliert das Ende einer 12 Sekunden andauernden Verbindung. Also landet sie als »GREY« in der Spamd-Datenbank, da sie die 10 Sekunden des anfänglichen Stotterns brav geduldet hat. Zeile 3 zeigt einen weniger wohlgesonnen Genossen. Spamd hatte diese IP als »TRAP« erkannt und rang dem Spammer 81 Sekunden Zeit und damit Geld ab. Spitzenreiter kommen auf viele Stunden. Zeile 4 zeigt eine IP, die die Blacklist »uatraps« erkannt hat. Sie wandert ebenfalls in den Tarpit und wird beim Disconnect erneut im Log erscheinen.
Die restlichen Einträge stammen vom Greyscanner im Debug-Modus. Zunächst verschafft er dem Admin eine Übersicht der gescannten Einträge, bevor er sich den verdächtigen Kandidaten widmet. Die Zeilen 7 und 8 trappen die entsprechenden IPs und nennen einen Grund. So behält der Admin die Übersicht über die Spamd-Abläufe und kann notfalls manuell eingreifen - sofern der Umfang der empfangenen Mails das noch zulässt.
| Whitepaper |
|---|
|
Daten Migration - Eine Publikation von Bloor Research
Datenmigrationsprojekte überschreiten häufig das Budget, neigen zu Verzögerung und werden unter Umständen komplett abgebrochen. Bloor Research ist eines der weltweit führenden IT-Forschungs-, Analyse- und Beratungsunternehmen und wird in dem vorliegenden White Paper die wichtigsten Aspekte dieser Problematik näher beleuchten. Ferner werden praktische Empfehlungen für erfolgreiche Migrationsprojekte gegeben, die Sie auf Ihr nächstes Projekt übertragen können.
Download PDF (Registrierung erforderlich)
|
|
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele
Über die letzten Jahre hinweg haben sich Open Source Lösungen als fester Bestandteil des gesamten Datenintegrationsmarktes etabliert. Viele Unternehmen haben bereits das Open Source Modell für Ihre Datenintegrationsprojekte aufgegriffen. Das vorliegende White Paper illustriert anhand ausgewählter Fallstudien und Anwendungsbeispiele die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.
Download PDF (Registrierung erforderlich)
|
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links"
nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedrucken Fassung entsprechen.
|
