[HaBo]

Harry Boeck

Anzeige

Einleitung...

Hallo,

ich arbeite gerade an einem Werkzeug zur Verfolgung von Angriffen auf Server.
Ein Element davon ist die Ermittlung von Mail-Adressen der Ansprechpartner von befallenen Servern, die für solche Angriffe mißbraucht werden (um diesen automatisiert eine Warnung schicken zu können).

Sowas macht man ja nun über whois, indem man nach Feldern für "irt" (Incident Response Team) oder "abuse" oder wenigstens "admin-c" sucht, die etwas in der Art einer Mail-Adresse enthalten.

Mit dem originalen "whois" gibt es nun Probleme dahingehend, daß die aus einer Abfrage stammende IP-Adresse nicht gerade fein granuliert aufgelöst wird. Abhilfe soll hier, soweit ich das verstanden habe, seit einiger Zeit das rwhois-Protokoll schaffen.

Ich versuche gerade, mich durch das rfc 2167 zu beißen, um dem rwhois-Client das hierarchische Verfolgen beizubringen. Dabei stoße ich leider wie üblich am laufenden Band auf Formulierungen, die VIELLEICHT IRGENDWO im Text erklärt sind, und die man VIELLEICHT sogar finden würde - wenn man denn wüßte, wie sie gemeint und daraus abgeleitet, wie und wo sie erklärt sind. DANN allerdings braucht man den ganzen Kladderadatsch von Erklärungen in aller Regel selbstredend nicht mehr... (soll heißen: Das RFC kann man mal wieder als besseres Klohpapier benutzen...)

----

Problem...

Ich suche nun jemanden, der sich mit dem Zeug schon etwas auskennt.
Konkret mit dem Abschnitt "2.5 Query Routing".
Unter anderem mit den Formulierungen

• "search value of the query term"
• "hierarchical portion of the search value"
• "be hierarchical"

Mein Problem: Ich habe z.B. eien "query term" = "198.173.255.187".
WAS DARAN soll durch "search value" beschrieben werden?
Oder zu deutsch: WAS soll der "Suchwert" des Strings "198.173.255.187" sein?
WAS soll die "hierarchische Portion" des "Suchwertes" des Strings "198.173.255.187" sein??
WANN soll eine "hierarchische Portion" des "Suchwertes" des Strings "198.173.255.187" dann auch noch "hierarchisch sein"???
Und hierarchisch bezüglich WAS????

(Bzw. implizit: Wer hat sich diesen Schwachsinn von Terminologie in einem RFC ausgedacht? :-/ )

Und wie bekommt man einen "punt referral" von einem "link referral" unterschieden?
Außer den Erklärungen, inwiefern diese sich in ihrer Bedeutung unterscheiden, bekomme ich nichts herausgelesen, was eine Unterscheidung auf Seite des Clients gestattet. Außer eventuell, daß man auf Client-Seite nochmal eine Analyse der gemeldeten "auth-area" macht. Aber da wüßte ich auch nicht so recht weiter: In den Beispielen werden in JEDEM Fall (bei "punt" und "link" referrals) in der "auth-area" Bereiche gemeldet, die einen größeren Bereich als die requestete IP oder den requesteten Domainnamen beinhalten. Was ja auch logisch ist: Immerhin geht es ja um nichts anderes als den Verantwortungsbereich des Servers, der mit dem referral vermittelt wird. Und der ja wohl jede Menge von Bereichen verwalten soll. Ist ja der tiefere Sinn der Sache. Was also soll man auf Client-Seite daraus schlußfolgern?
Oder soll man als Client blindlings immer alle referrals verfolgen, zwischenspeichern und anschließend eigenständig daraufhin parsen, welches Ergebnis am ehesten brauchbar ist?

Kennt jemand ein vernünftiges Tutorial für die Benutzung des rwhois-Dienstes?

----

Ergänzung:

Bin jetzt erstmal damit durch, alles gesammelt zu kriegen, und beginne mit dem Auswerten nach dichtestem Match und auswertbaren Infos...

Die nächsten Fragen wachsen:

Statt Emails findet man sowas wie
Tech-Contact;I:IA3913-VRIO.127.0.0.1/32

Was soll das Zeug bedeuten?

Alle meine bisherigen Versuche, mittels Suche im RFC-Text irgendwas brauchbares zu finden, schlugen fehl. Weder unter den Beispielen noch in den Erklärungen findet sich irgendwas, was auf den vorhandenen Unterbau aufsetzen könnte.

Es sollte sich doch irgendwie weiter auswerten lassen, oder?
Oder benutzen die Leute da draußen, die Admins von riesigen Rechenzentren und Telekommunikations-Unternehmen sind, dieses Zeug nur zum Verarschen?
Bin ich wirklich schon wieder mal auf dem falschen Planeten?
(Ne "127.0.0.1" als Kontaktadresse fasse ich bei einem Rechenzentrum als Frechheit auf...)

----

Bei CastleCops lief wohl (oder läuft noch immer) eine ähnliche Aktion, wo Freiwillige Admins mitarbeiten, entsprechende Angriffe zu melden:

http://www.castlecops.com/modules.ph...id=131954&in=1

Hilft aber zur Verarbeitung der rwhois-Daten keinen Schritt weiter...

...Bzw. doch: Unter

http://www.castlecops.com/wsirt

kann man Reports mehr oder weniger direkt zu den passenden Empfängern liefern (darunter neben den abuse-Mailfächern sowas wie Anitiviren-Hersteller und das FBI).
Was ich erstmal vorhatte, meine Mecklenburger Polizei zu beliefern, dürfte dagegen unsinnig sein. In diese Falle wünschte ich mir mal, daß die grünen Jungs ein bißchen Intelligenz walten ließen und sehr wohl international zusammenarbeiten würden.

Das Nachvollziehen einiger Beispiele anhand meiner soweit vorhandenen whois-Werkzeuge liefert: Am sinnvollsten scheint immer noch das normale whois mit seiner zentralen Datenbank zu funktionieren. Dort muß man zwar gegebenenfalls alle Kontinente durchprobieren, landet dann aber scheinbar immer einen Treffer. Und zwar einen, der sich im Gegensatz zum rwhois-Zeugs verwerten läßt.

Nachteilig ist nur, daß auf castlecops ein spam-Filter liegt, so daß die Automatisierung erstmal wieder stockt... Nein, stimmt nicht ganz: Wenn man eingelogged ist, geht's ohne Spam-Filter...

----

Ein bißchen Vorsicht ist bei der Zusammenarbeit mit Castlecops angesagt: Die werden offenbar auch von den "bösen Jungs" eingesehen und ausgewertet. Nur halt andersrum: Unmittelbar nach Einstellung meines ersten Einbruchs-Logs dort bekam mein Server Besuch von einem Botnetz: Rund 500 Rechner klopften auf alle möglichen Schwachstellen ab (und fanden natürlich nichts :-P ).