netsecurity database

A friend of mine asked me a very basic but fundemental question that I had not addressed until now: "what is netscdb all about?". Here is my understanding:

This is how the Internet looks most of the time to us:

and this is the perspective from netsecdb:

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.

You may have find your way to this page,
because your smtp-server received a message like:

550 SMTP/S access denied. (according to smtp-rfc's)

doing a telnet to port 25 shows in addition:

netsecurity-db status: <CIDR of netrange> recorded as spammer
(<timestamp of last received spam>).
Ref-ID: <reference id> from: <country>
See http://www.netsecdb.de for more info.

So what the hell is netsec-db
and why is the network-range blocked?

• we 'map networks' logically, not spying users privacy
• we take respect to the different network levels on the way to our customer networks
• we control access to our services.

  

• we know our customers networks
  and their communication partners
• we have set up self-educating engines
• we know more than 7.66 million networks
• we know 113.203 spammer networks
  (current stats on left part of frontpage)
• we hold other metadata regarding the known netranges
  (572575 filter+tags)
• think of it as an 'streetmap of the internet'
• in third dev-level, users shall be able to apply their own profiles to manage and generate individual configurations matching their customer-situation like we do today

What is that good for?
what can we do with it?

• 
  we integrated netsec-db functions into woltlab bulletin boards:
  • www.chatcops.de (mixed community)
  • www.net4cops.de (closed community - police officers only), international collegues welcome.
  • www.german-police.de (mixed community)
• police officers from the above mentioned bulletin boards have direct access to netsecdb in order to support their work.
• we integrated netsec-db and live-monitoring functions into drupal cms:
  • www.netsecdb.de (this page)
  • www.marxmeier.de
  • www.cologne-crocodiles.de
• request live security relevant infos about visitors/users
  
• import missing info and judge the net by mouseclkick
• block or open servers/nets/ports from the frontend
• netsec-db uses the database content to automatically generate config-files and firewall rulesets
• in addition, the netsec-db is automatically updated from logfiles (mail/web/syslog):

  
  
  

• 
  we currently generate:

  • hosts.deny files for plesk/qmail/xinetd
  • evil-client.cidr for postfix,
  • exim4_local_host_blacklist for exim4.x,

  

  • .htaccess-files for apache,
  • iptables-scripts for debian/SuSE and
  • cmdlets for use with Microsoft Exchange Server7 Series

  to be used by external partners.
  
  
  
  
  
  
  
  
  
  

• we are able to process and analyse logfiles very fast against netsec-db and give quick reports
• do you ever received logs you have to pay for (like advertising clicks) and like to check them for plausibility? - now one can analyze them
• netsec-db has been hosted behind two redundant and stateful firewalls and switched to ordinary rootserver in a standard hosting environment.
• we save load and energy costs, getting our servers back to their work - of course, you can filter each mail by content, like we do with the remaining ones (and the ones from customer nets) - but 98% traffic and cpu for nothing?
• we want to fight internet crime fast and effectively.

For further documentation please check out the documentation section.
A quickjump to tagging rulesets.

In general - it does not look pretty like an advertisment spam, but it works in production.

Applying netsecdb mapping on spams,
we have the following results:

we have decreased them more than 98% on this server.

Take a look at the current mailstats on the left

 

---

From 2008/07/07 to 2008/09/12
we prevented
1.763.693 connects
to srv01 from
known spammer-nets.
We reduced load and traffic to approx. 1% of before:

With the saved resources we drive netsecdb engines and database.

---