Anonymisierungskonzept für P2P Botnetze

Hi,
ich habe mich vor kurzem mit P2P Botnetzen beschäftigt und bin fasziniert von den Möglichkeiten die sich durch eine solche Architektur auftun (Man kann nahezu unbegrenzt viele Bots halten,man braucht streng genommen keine neue Hardware da der Server ja kaum Verbindungen halten muss usw.)

Aber es gibt auch einige Probleme,wie die Tatsache das einigen PCs im Botnet die IP des Masters bekannt ist,was etwas ist das man vermeiden sollte.Dazu kommt das der Botherder ja auch erfahren muss das ein neuer PC dazu gekommen ist,da er ja irgendeinen PC braucht der den Rest des Netzwerks in Kentniss über die neuen Befehle setzt.Ausserdem ist es schlecht wenn ein Bot die IP eines anderen Bots kennt bzw. man könnte es vermeiden.

Ich bin mir darüber im klaren das diese Idee schoneinmal kam oder sogar bereits in die Tat umgesetzt wird.Ausserdem ist mir bewusst das ich vielleicht vollkommenen Mist von mir gebe.Wen dies der Fall ist,dann habt bitte Gnade mit mir.Ich will einfach nur erfahren ob das Konzept theoretisch funktionsfähig ist.



Erste Ausfürung bzw. Anbindung an das Netzwerk
Da der neue Botrechner ja keine Ahnung hat wohin er sich verbinden muss,weil keine IPs fest eingespeichert sind muss er wohl oder übel einige IPs abklappern.Er sendet mit einer gespooften IP Addresse ein UDP Paket (Bei UDP kommt ja keine Verbindung zu stande und es gibt keinen Handshake) mit Informationen über IP Ranges in denen sich der Rechner befinden könnte (Einer ist natürlich richtig)und einem Hash an zufallsgenerierte(oder auch systematisch erstellte IP Addressen) und wartet auf eine Antwort.Wenn das Paket die IP Ranges enthält in denen sich der Bot befinden könnte ,werden diese in irgendeiner Art und Weise abgespeichert.Nachdem alles gespeichert wurde fragt er am anderen Rechner Informationen über die Bots an die er kennt (Keine Klaren IPs ,nur die Range-Informationen).Falls die Mindestanzahl an bekannten Informationen eingehalten wird,fängt der Bot an für Anfragen bereit zu werden(Und tut was sein eigentlicher Verwendungszweck ist).

Empfangen von Anfragen durch neue Bots
Sobald der Bot bereit ist,lauscht er auf einen nicht besetzten Port.Falls Anfragen eintreffen ,die die Richtlinien erfüllen, wartet er einen zufallsgenerierten Zeitraum damit keine Vermutungen über seinen Standort angestellt werden können, und antwortet dann über eine beliebige gespoofte IP und sagt dem Bot einige IP Ranges in denen er stehen könnte(in einem davon steht er ja letzendlich) und speichert die Informationen ab die der neue Bot ihm gesendet hat.

Nutzung als Kontaktpunkt durch den Herder
Wenn der Bot auf einem bestimmten Port mit einem passenden Befehlspaket kontaktiert wird,dann greift er auf seine Liste bekannter Bots zurück und leitet über eine gespoofte IP das Befehlspaket an sie weiter.Jeder Bot der das Befehlspaket erhält,sendet es an seine "Kontakte" weiter.
Hinweis:Falls einer der in Kentnis gesetzten Bots kontaktiert wird,wird das Befehlspaket weitergeleitet.

Das Senden von Daten an den Herder
Da leider keiner der Bots den Herder kennt müssen sehr viele IPs systematisch mit kleinen Paketen abgegrast werden,um die Rangeinformationen des Herders zu bekommen.Der Herder muss sich nur auf besondere Art und Weise authentifizieren und benimmt sich ansonsten genau so wie die Bots.


Hinweis 1:ALLE IPs über die die Pakete gesendet werden sind gespooft.
Hinweis 2as Anfangspaket könnte wie folgt aussehen:
<Hash>
<Random>.<Random>.<Random>.*
<Random>.<Random>.<Random>.*
<Random>.<Random>.<Random>.*
<Random>.<Random>.<Random>.*
<Random>.<Random>.<Random>.*
<Random>.<Random>.<Random>.*
<Richtige Zahl>.<Richtige Zahl>.<Richtige Zahl>.*
Hinweis 3:Alle Pakete müssen verschlüsselt übermittelt werden,da ansonsten Informationen über den wahren Standort herauskommen könnten.
Hinweis 4akete werden nicht an die angegebene gespoofte IP gesendet.

Ich weiß zwar schon das dies wahrscheinlich nicht allzu sicher ist,aber dies ist nur ein Grundriss.Ich will wissen was ihr von der Idee im Allgemeinen haltet und wie die theoretischen Chancen dieses Konzepts stehen erfolgreich zu sein.


PSa es sich ja hauptsächlich um Anonymität dreht denke ich mal das dies das richrige Forum ist.

1. Wieso sollte ein einzelner Bot "anonym" bleiben wollen? Letzten Endes geht es doch nur darum, dass der Betreiber des Netzwerkes gegenüber Strafverfolgern anonym bleibt, oder? Wie könnte man das in einem P2P-System erreichen?

2. Muss es wirklich immer einen "Master" oder einen "Herder" geben? Versuche doch mal ein reines P2P-System zu entwerfen, ansonsten kannst du dir auch ein P2P-Netzwerk bauen, welches das TOR-Netzwerk als Underlay "missbraucht" und erreichst so viel einfacher die dir gesetzten Ziele.

3. Deine Bots scheuchen durch ihr sinnloses Gesende von UDP-Paketen mit falschen IP-Adressen an ganze IP-Ranges jedes NIDS auf, wie ein Fuchs einen Hühnerstall. Wählst du stattdessen eine Systematik dahinter, liesse sich diese ebenfalls als Heuristik in ein NIDS eintragen und damit leicht filtern. Du musst dir also insgesamt etwas anderes überlegen, als wild Pakete durch die Gegend zu senden.

4. Es gibt bereits genügend gute P2P-Protokolle und Konzepte (Einführungen siehe hier oder hier). Diese könntest du dir anschauen und versuchen hinsichtlich Anonymität zu erweitern. Das wäre ein weitaus erfolgsversprechender Ansatz, als dir selbst etwas auszudenken.

5. Verschlüsselung erfordert die Kenntnis von Schlüsseln und damit einen Schlüsselaustausch. Der fehlt bei dir vollständig.

6. Zur Beschreibung von Abläufen und Protokollen gibt es fest spezifizierte Formen. Protokolle lassen sich z.B. sehr gut mittels Sequenzdiagrammen erklären.

masterplc hat gesagt.:

Sobald der Bot bereit ist,lauscht er auf einen nicht besetzten Port.

Zum Vergrößern anklicken....

Das öffnen von Backdoors ist der grösste Fehler, den Bots begehen können. Deswegen haben bereits in den 80er Jahren die Bots via IRC ihre Befehle entgegen genommen, weil sie damit wie ein "normaler" Client und nicht wie ein Server auftreten.

So mal als Ergänzung zu SB's Post.
Der Teufel steckt bei P2P immer im Detail. Gibt ja nicht umsonst so viele unterschiedliche Ansätze

masterplc hat gesagt.:

Informationen über die Bots an die er kennt (Keine Klaren IPs ,nur die Range-Informationen).Falls die Mindestanzahl an bekannten Informationen eingehalten wird,fängt der Bot an für Anfragen bereit zu werden(Und tut was sein eigentlicher Verwendungszweck ist).

Zum Vergrößern anklicken....

Das nennt man Bootstrapping und das ist immer problematisch. Normalwerweise ist es aber am günstigsten, sofern es mal mit der Verbindung geklappt hat, eine Liste mit Nachbarn vorzuhalten und erstmal diese abzuklappern.
Denn "Feuern" auf "Gut Glück" klappt erst ab einer gewissen Botnetgröße. Und btw. - lauschen auf einem Port kann der Bot gerne - allerdings müssen ja auch noch UDP Packete da ankommen. Gibt ja nicht umsonst STUN - Wikipedia, the free encyclopedia, TCP/UDP-Holepunching und anderen NAT traversal - Wikipedia, the free encyclopedia Kram
Und - jedes Mal quasi komplettes Bootstrapping durchzulaufen lädt den AV/ISP/Konkurrenten förmlich dazu ein, eigene UDP Packete mit eigener, "korrekter" Information zu verschicken und die Bots zu übernehmen/abzuschalten

sie weiter.Jeder Bot der das Befehlspaket erhält,sendet es an seine "Kontakte" weiter.
Hinweis:Falls einer der in Kentnis gesetzten Bots kontaktiert wird,wird das Befehlspaket weitergeleitet.

Zum Vergrößern anklicken....

Das ist Gnutella aka "ungeordnetes P2P Netzwerk" aka "jeder mit jedem". Hauptnachteil ist die immense Bandbreite, die für die Verwaltung drauf geht, nicht vorhandene Skalierbarkeit und einige Anforderungen an die "Gutwilligkeit" der Nachbarknoten.
Sofern mich nicht alles täuscht, sorgten in den späteren Phasen des P2P Netzwerkes z.B Suchanfragen (trotz eine Tiefenbegrenzung von 5-7(?) Knoten) für eine Auslastung des Netzes. In Deinem Fall werden ebenso die Befehle des Masters weitergeleitet.
Query flooding - Wikipedia, the free encyclopedia
Lässt sich auch leicht nachrechnen: wir nehmen im Schnitt 5 Nachbarn an (sehr wenig für den stabilen Betrieb), es gibt insgesamt 100 Bots. Pi mal Daumen sind es "mal eben" 4^100 Anfragen 1606938044258990275541962092341162602522202993782792835301376L
Nehmen wir realisitischere 15-40 Nachbarn und paar 1000 Clients an, wird es zu lang zum Posten . Vor allem wenn statt konkreter Adressen nur Bereiche vorhanden sind.

Deswegen wurde bei Gnutella/Ähnlichem ein T(ime)T(o)L(ive) verwendet. Man kann diesen auch ausrechnen (5 Nachbarn, 1 Mio Bots => Max TTL um alle zu erreichen == log5(1mio) ~ 9).
Allerdings - mit gepatchten Clients (die größere TTLs erlaubten), konnten bei GT die"Außerwählten" eine größere Suche starten - und nichts hindert einen AV/Konkurrenten daran, hier die gleiche Taktik zu verwenden.

Das ist das allgemeine Problem mit der Anforderung an die "Gutwilligkeit" der Nachbarknoten. Stichworte wären hier "p2p attack" oder Sybil attack - Wikipedia, the free encyclopedia

Z.B um Dein Netzwerk lahm zu legen, müsste man nur paar zusätzliche Knoten einführen (also Rechner infizieren lassen) und dann fleißig immer alles mehrmals weiterleiten - man muss dazu nur den Bot"client" patchen oder das P2P-Protokoll auseinanderbröseln (je nach dem, was einfacher ist).
Benutzte Verschlüsselungen/Signierungen sollte also auf jeden Fall Replay-Attacken widerstehen können.

Oder man fälscht die "einfache" Peer-to-Peer Kommunikation (also das Finden der Nachbarn usw.) - sendet z.B Packete mit Ip-Ranges "in die Welt", die die Bots in Honeypots/eigene Netze führen.

Btw: Als "Anti-Botnetter" hat man sowieso deutlich mehr Möglichkeiten (und i.d.R kooperierende ISPs)