netsecurity database

Die Telefonnummern-CD mit Rückwärtssuche für Deutschland kennt man -
die bekommt man mittlerweile beim Lebensmitteldiscounter für unter 10 Euro hinterhergeworfen.

Klingt komisch - ist aber so.

Braucht man nicht gross zu erklären, was man damit machen kann.

Was ist nun mit diesem Internet?

Dieses Internet basiert auf IP-Adressen, ähnlich der Telefonnummern. Da gibt es dann 2 Arten - Wir beschränken uns mal auf die traditionellen vom IPV4-Typ.
Dazu wechseln die dynamischen IP-Adressen immer wieder den Besitzer. Der DBA kann manuell oder automatisiert mit nslookup, whois, dig, traceroute etc. versuchen etwas über seinen Gegenüber herauszufinden. Das ist zum einem dann morgen schon Schnee von gestern und zum anderen ist da ja noch die Sache mit den Anonymisierern wie jap, tor und Konsorten.

Ist die Verbindung über eines dieser Netze zu Stande gekommen, bekomme ich nur den Ausstiegspunkt aus diesen Netzen zu sehen - der eigentliche Kommunikationspartner bleibt dann verborgen.

Also wozu habe ich nun netsecdb gebaut?

Die netsecdb beinhaltet die Netzwerk-Informationen von ripe, apnic, jpinc, cnnic etc.
Wer um Himmels Willen ist denn das?

Das sind die "Verzeichnisse" im Internet in dem, nach Erdball-Regionen getrennt, die Informationen über vorhandene registrierte Netze abrufbar sind:

Alles, was auf der Karte dunkelgrün eingefärbt ist, hat die netsecdb im Datenbestand. Immer wieder wird mit dem Datenbestand der Registries synchronisiert. Eine grosse Herausforderung dabei war, die verschiedenen Datenformate auf einen gemeinsamen Nenner zu bringen - und sie immer wieder updaten zu können. Wenn im Bereich Dokumentation also etwas von 'sync with ripe, arin, apnic, lacnic o.ä. steht heisst das, dass der Gesamtdatenbestand abgeglichen wird.

[UPDATE]: Es fehlt nur noch der Bulk Whois BRNIC (Brasilien).

Die Routinen dafür mussten erstmal geschrieben werden. Die RPSL-Parser Funktionen sind der Community innerhalb des pwhois Projektes zur Verfügung gestellt worden. Die Daten wurden so angelegt, dass sie optional als Informationen mittels whois Abfrage zur Verfügung gestellt werden könnten.

Also wozu netsecdb, wenn ich alles abrufen kann?

Diese Verzeichnisse enthalten bis herunter auf die Netzverantwortlichen inkl. Kontaktdaten alle Informationen, können aber nur limitiert abgefragt werden.
Weitere Zusatzinformationen über ein Netz gibt es nicht.

Mal ein praktisches Beispiel:

Auf dem Server kommen von einer IP jede Menge unsaubere Anfragen. Sei es, dass versucht wird ein Forum zu knacken, sei es, dass Spammails an die User angeliefert werden.
Dieser ungewollte Datenverkehr kommt natürlich nicht von einer festen IP, sondern von einer dynamisch vergebenen oder wie in letzter Zeit schon Standard, von einer Vielzahl dynamischer IP Adressen weltweit gesteuert von einer unbekannten Quelle (Stichwort botnet).

Netsecdb besteht aus mehreren Teilen:

• Erstens.

Die generellen Netzinformationen (wo fängt es an, wo hört es auf). Auf wen registriert? Aus welchem Land kommt es? Was hostet es (Stichwort Warez, Filesharing, Hacker, Pornos)? Werden spams mit diesem Netz als Ziel versendet?
Dafür wurden einige Millionen domains auf ihre IP aufgelöst und dann auf das kleinste, registrierte Netzsegment eingetragen.



• Zweitens.

Die groben Metainformationen: Kam aus diesem Netz schon Spam? Wann zuletzt? Gab es Hackversuche?



• Drittens.

Aktuelle Filterinformationen: z.B. ist die Gegenstelle ein Tor-Exit-Node d.h. der Punkt an dem die Anfragen das Tor-Netz verlassen, nachdem sie vorher über zwei andere Server geleitet wurden?

Wenn man bislang alles manuell ermittelt hat, ist an dieser Stelle Schluss.

Es ist ja witzlos, wenn eine Exit-Node ist :( Na ja, nicht wenn ich auf Basis von netsecdb dynamische Firewall-Regeln generiere, die jeden Verkehr mit statischen aber auch den bekannten dynamischen Exit-Nodes generell unterbinden.
Ebenso mit allen bekannten open-proxies, mit allen statischen IPs, die als Hackernetze eingetragen sind. Genauso könnte ich mit einem Mausklick z.B. alle bekannten Netze bestimmter Firmen oder Regionen sperren.
Ich müsste nur die Informationen aus den verschiedensten Quellen über die gesamten Netze haben, meinen eigenen Logfiles oder woher auch immer und sie zentral miteinander verknüpfen.

Das ist der Sinn und Zweck von netsecdb:

Dem kriminellen Missbrauch des Internets die existenziellen Grundlagen zu entziehen. Im Gegensatz zu den am Markt befindlichen Filterlösungen geht es nicht nur um den Schutz des Kunden (Server/Workstation), sondern langfristig um eine Beseitigung des Problemes.

Die Spammer-Netze aus dem Land, welches die TOP25 anführt, werden registrierten Usern kostenlos zum Download angeboten.
In verschiedenen Formaten als 'Fertigfutter' für verschiedene am Markt verwendete MTA's.

Durch die Veröffentlichung der Spamlinkdest-Liste in verschiedenen Formaten können die Spammer und Botnetzbetreiber fleissig neue Domains registrieren und versenden - die Zielnetze lassen sich leicht sperren und keiner geht hin.

So funktioniert die netsecdb:

Eine soweit als möglich aktuelle Erfassung der Netzbereiche und die Echtzeitabfrage der gesammelten Informationen.
Das Abprüfen von Logfiles und deren IPs gegen die Datenbank kann dadurch automatisiert werden. Die Informationsbasis dafür ist komplett intern.

Das automatische Generieren von auf den Ziel-Server und dessen Funktionen angepassten Firewall-Scripten kann übernommen werden.
Innerhalb dieses Server-Verbundes hat es die Spam-Abwehr drastisch vereinfacht:
Die Logfiles werden stündlich überprüft, eine Liste mit IP-Adressen generiert die dann auf ihren Ursprung hin überprüft werden. Das Netzsegment wird in der Datenbank als Spammer markiert und nach eigenen Regeln erstmal für den Mailempfang gesperrt.
Kommen danach verdächtige Anfragen aus dem Netz, wird es als Web-Spammer, bei Angriffen als Hacker eingestuft und wiederum nach Regeln in der Datenbank als gesperrt gekennzeichnet.

Regelmässig fragt der Server die Datenbank ab und je nach gesetzten Markierungen baut der netsecdb-Server die Regeln.

Die Partner-Server können zusätzlich einen RBL-Server abrüfen, sind aber nicht mehr darauf angewiesen, sondern haben die komplette Konfigurationen lokal im System und arbeiteten bei Ausfällen unabhängig weiter.

Das ist der Output von netsecdb:

Update: Die Liste ist völlig veraltet - hier lang zur aktuellen Übersicht.

• iptables-scripte in 2 Varianten
• .htaccess-file für apache
• evil-clients.cidr für postfix
• exim4_local_host_blacklist für Exim 4.x
• hosts.deny für Verwendung mit inetd/xinetd
• qsheff.rules für den qmail-wrapper
• cmdlets für Microsoft Exchange Server in 2 Versionen

Was sich einsparen lässt:

Im Allgemeinen würde man ja im Mailhosting mit wenigen Servern auskommen - wenn da nicht die Spammerattacken und -wellen wären. Ein Hoster erzählte mir bei den Webhostingdays 2008, dass er 5 Server brauche und 15 in Reserve halte, um Lastspitzen durch Spammer abfangen zu können. Was spart man sich also bei diesem 1:3 Verhältnis an Kosten für Hardware und Rackhosting ein, wenn der Datenmüll erst gar nicht zur Verarbeitung ansteht? Kann sich jeder für sein Hosting-Setup leicht ausrechnen. Dagegen stehen mit einer Auto-Update- Lizenz eines netsecdb-Bundles Kosten von ca. 4 fakturierten Technikerstunden a 75,- EUR im Jahr. Registrierte user können sich tryouts herunterladen, die auf das führende TOP25 Spammer-Land reduziert sind und damit selbst überprüfen, was es bringt.

Damit jetzt kein Datenschützer rote Augen kriegt:

netsecdb enthält keinerlei personenbezogene Daten weder ORG, noch POC, noch die unserer User. Braucht sie auch nicht, da es bei diesem Ansatz darum geht, eine zentrale Instanz zu haben, die Kommunikationspartner definiert und qualifiziert.

Der Direktzugriff auf netsecdb ist auf DBAs, direkte Kooperationspartner und Ermittler aus dem Bereich Internetkriminialität beschränkt, da jede Anfrage einige Millionen Datensätze durchsucht und entsprechend Ressourcen kostet.

Fragen die immer wieder auftauchen:

• Nein! Es gibt keine Zuschüsse oder materielle Unterstützung seitens irgendwelcher Organisationen oder Firmen.
• Ja! Deutsche Behörden haben, sofern erwünscht, von Anfang an Vollzugriff auf die netsecdb Outputs und internationale haben Kooperationsangebote erhalten
• Nein! Nicht alle taggings werden dokumentiert. Die Bearbeitung dauert ein paar Sekunden, die Dokumentation frisst Minuten - dafür sind's zu viele
• Ja! Netsecdb muss in Englisch sein, da dies im technischen Bereich die Standardsprache ist.
• Ja! Dieser Text ist im Vergleich zur englischen Doku einfach gehalten.