Flashe auf der Box mit dem Recovery-Tool wieder die originale AVM-Firmware und benutze die Packetdump-Funktion dieser Firmware. Mit iptables und LOG-Target erwischst Du nicht alle "beschleunigten" Daten und für eine forensische Analyse wäre (meine Meinung) der komplette Datenverkehr geeigneter.
Zwar wird die aufzuzeichnende Datenmenge auch entsprechend größer, aber dann nimm eben den potentesten sauberen Client (noch besser ein Live-System) in Deinem Netzwerk für die Speicherung der Packetdump-Ausgabe.
Mit Wireshark kann man dann an dem aufgezeichneten Traffic Analysen vornehmen.
Wenn ich dann von der Telekom die IP des Sinkhole bekomme, könnte ich mit dem iptables Kommando gezielt die Aufrufe an diese Adresse filtern und hätte den Verursacher in meinem Netzwerk. Den würde ich dann notfalls plattmachen und neu aufsetzen.
Wenn Du von der Telekom die Sinkhole-Adresse bekommst, kannst Du gezielt im aufgezeichneten Verkehr danach suchen.
Sofern der Schädling mit HTTPS (Port 443) mit seinen C&C-Server kommuniziert, würdest Den den Inhalt des Traffics ja auch nicht als verdächtig erkennen, da der Router keiner der beteiligten Endpunkte ist und somit nur die verschlüsselten Daten sieht.
Aber auch dann, wenn die Telekom die Sinkhole-Adresse nicht herausgeben sollte, kann man mit etwas mehr Arbeit dem Problem noch auf den Grund gehen.
Für den Schädling gibt es ja nur eine Möglichkeit, den C&C-Server zu kontaktieren ... er braucht seine IP-Adresse. Da verzweigen sich dann allerdings die Möglichkeiten, wenn es darum geht, wie er an diese kommt.
1. Die Adresse ist fest einprogrammiert.
2. Die Adresse wird per DNS-Abfrage eines festen DNS-Servers ermittelt.
3. Die Adresse wird per DNS-Abfrage des lokal gültigen DNS-Servers ermittelt.
Das kann sich natürlich auch als Mischform wiederfinden in dem Bot, mit DNS-Abfragen und Fallbacks, falls die Domains abgeschaltet werden oder auch mit kaskadierten Serverlisten, wo in der Malware eine Liste von IP-Adressen fest hinterlegt wird, von denen der Reihe nach versucht wird, die aktuellen Listen mit den Namen/Adressen von möglichen C&C-Servern zu laden. Aber das sind ja alles nur Maßnahmen der Malware-Entwickler gegen die Abschaltung von C&C-Servern und/oder Domains, das spielt für Deine Analyse nur eine untergeordnete Bedeutung in der Hinsicht, daß nicht zustande kommende ausgehenden Verbindungen auch ein Zeichen für das "Abklappern" einer solchen Liste sein können.
Je nach o.a. Weg lassen sich unterschiedliche Symptome feststellen:
zu 1.) Es werden TCP-Verbindungen auf Port 80 oder 443 zu Servern aufgebaut, für die keine vorherige DNS-Abfrage stattgefunden hat. Der eigentliche IRC-Port 194 wird eher selten genutzt, da viele Sicherheitslösungen darauf "anspringen" und wenn ich Dich richtig verstanden habe, hat die Telekom Dir ja die Ports 80 und 443 explizit ans Herz gelegt.
zu 2.) Es werden von einem Client im LAN selbständige DNS-Abfragen eines externen DNS-Servers getätigt.
zu 3.) Alle extern sichtbaren DNS-Abfragen stammen von der Box, hier hilft dann nur ein interner Mitschnitt auf "dev lan", da die DNS-Abfragen an die FRITZ!Box nur dort noch den Absender erkennen lassen.
Die Fälle 1+2 lassen sich schön detektieren, bei 3 wird es schon schwieriger, dafür könnte da dann etwas zusätzliche Software (z.B. eine Linux-VM mit LAN-Brigde, die einen DHCP-Server bereitstellt und die DNS-Abfragen über sich selbst leitet) die Eingrenzung des Schuldigen wieder erleichtern.
Voraussetzung wäre allerdings, daß Du wirklich alle Geräte in Deinem Netzwerk - bis auf den als Protokoll-Host auserwählten PC, den Du am besten auch mit einem Live-System bootest - von der FRITZ!Box und vom Strom trennst. Dann die FRITZ!Box neu starten und als erstes den passenden Packetdump starten, dabei ein Laufwerk mit ausreichender Kapazität zum Speichern der Daten verwenden. Je nach Szenario müßte zwar mal die interne Schnittstelle (lan) oder die externe Schnittstelle (1. Internetschnittstelle) mitgeschnitten werden, aber ein Mitschnitt des internen Traffics enthält auch die Übertragung der mitgeschnittenen Daten an den aufzeichnenden Rechner und der Traffic auf der externen Schnittstelle enthält nur noch die externe Adresse der FRITZ!Box. Daher schneidet man in so einem Falle praktischerweise auf der "Routing-Schnittstelle" mit, denn hier liegt genau der Mix aus internen Adressen (auch der FRITZ!Box selbst) und der externen Adressen vor.
Jetzt nimmst Du nach und nach die Geräte im LAN wieder in Betrieb. Jeder anständige Bot sollte in einem akzeptablen Zeitraum nach dem Start des Gerätes auch wieder Kontakt zu seinem C&C-Server aufnehmen (nicht immer unmittelbar). Wenn Du von der Telekom Zeitangaben zum Kontakt des befallenen Gerätes mit dem Sinkhole hast, müßte sich daraus ja in etwa eine Frequenz der Kontaktaufnahme ableiten lassen und das wäre dann die minimale Aufzeichnungsdauer nach dem Start des letzten Gerätes.
Wenn Du dann erst einmal die aufgezeichneten Netzwerkdaten hast, kannst Du die ja nach Herzenslust analysieren und immer wieder nach anderen Gesichtspunkten erforschen.
Der Nachteil eines LOG-Targets für iptables wäre es, daß Du vorher wissen mußt, welche Zieladressen der Bot verwendet und daher auf die Mitarbeit der Telekom angewiesen bist. Der Nachteil eines "tcpdump" auf der FRITZ!Box (dev dsl) wäre es, daß Du wegen des avm_pa (Packet Accelerator) nicht den gesamten Traffic in der Ausgabe hast. Das Ausschalten des PA ist zwar machbar, über die Nebenwirkungen gibt es aber nur Spekulationen.
Wenn Du also die Sinkhole-Adresse bereits haben solltest, könntest Du nach einem ausreichend langen Mitschnitt (unter der Voraussetzung, der von Dir mit dem Live-System zum Speichern der Daten benutzte PC ist nicht gerade der Schuldige, das wäre der "worst case", da dann natürlich kein Kontakt zum C&C-Server stattfindet) problemlos mit Wireshark und einem passenden ip.dst-Filter den Übeltäter ausfindig machen.
Hast Du sie jedoch nicht und die Telekom gibt sie Dir auch nicht, hilft als erster Schritt die Untersuchung der Daten auf direkte DNS-Abfragen von anderen Geräten als der FRITZ!Box, solche Abfragen sollten eigentlich von keinem Client direkt an irgendeinen Server gehen, solange dieser Client seine IP-Konfiguration von der FRITZ!Box bezieht. Treten solche Abfragen nicht auf (aber wirklich die Geräte "richtig" neu starten, auch Smartphones/Tablets), kannst Du Fall 2 schon mal abhaken.
Im zweiten Schritt dann alle Zieladressen von ausgehenden Verbindungen zu den Ports 80 und 443 ermitteln. Diese dann mit einer Liste der per DNS-Abfrage ermittelten Adressen abgleichen und so alle "festen" IP-Adressen ermitteln. Das werden hoffentlich nicht allzu viele sein (selbst solche Sachen wie NCSI verwenden DNS-Abfragen) und mit einer freundlichen Reverse-DNS-Abfrage lassen sich zumindest sehr ungewöhnliche (oder gar nicht für R-DNS registrierte) Adressen leicht isolieren. Wenn diese Adressen dann auf eine bekannte Domain verweisen und die Vorwärtsauflösung auch auf diese Adresse zeigt, kann man solche Adressen auch ad acta legen. Im besten Fall kristallisiert sich eine Handvoll verdächtiger Adressen heraus, die man dann auf dem jeweiligen Gerät mit der internen IP-Adresse (wenn möglich) einem Prozess zuordnet. Findet sich dabei auch kein Verdächtiger, ist Fall 1 auch erledigt.
Fall 3 wäre dann der aufwendigste Teil, da man alle aufgezeichneten DNS-Abfragen auf ihren Grund abklopfen muß. Hierbei ergibt sich dann zusätzlich das Problem, daß die FRITZ!Box selbst ja bei den externen DNS-Abfragen der Absender ist (sie ist DNS-Proxy) und der bisher aufgezeichnete Verkehr dafür untauglich ist (trotzdem aufheben!). Das wäre jetzt der Zeitpunkt, wo man sich überlegen muß, ob man mit einer passenden VM (z.B. einer Firewall-Appliance) den kompletten Verkehr über diese VM umleitet und direkt auf dieser VM aufzeichnet (womit das "Aufblähen" durch die Aufzeichnung selbst entfällt und i.d.R. sind dort auch die notwendigen Tools vorhanden) oder ob man den gesamten Verkehr auf der "lan"-Schnittstelle (da ist WLAN mit drin) aufzeichnet. Ein wichtiger Aspekt dabei ist sicherlich die Frage, wie schnell und genau man die Kontaktaufnahme des Bots mit dem vermeintlichen C&C-Server reproduzieren kann, denn man müßte an dieser Stelle ja noch einmal mit dem gesamten Prozess von vorne beginnen (also Appliance oder Live-System, dann FRITZ!Box, usw.). Wenn man sich für die Appliance entscheidet, schaltet man den DHCP-Server der FRITZ!Box aus, dann sollte i.d.R. die Appliance diesen Dienst bereitstellen können und somit auch sich selbst als DNS-Server und Gateway per DHCP "verkünden".
Je nachdem, ob man die fragwürdigen DNS-Abfragen aus der ersten Aufzeichnung schon kennt oder nicht, kann man nun entweder gezielt darauf warten oder auch noch einmal den gesamten Verkehr mitschneiden, z.B. mit dumpcap auf stdout und dann mit tee speichern und trotzdem in einer Pipe gleich passend filtern. Jetzt sollte man auch den/die Client(s) finden können, von denen diese Abfragen ausgehen und in der Folge (bei DNS-Abfragen ist die Zuordnung eines konkreten Prozesses zu einer Abfrage vom BS abhängig, bei Windows läuft das alles unter "System") sollte sich auch der Prozess dingfest machen lassen, der die TCP-Verbindung zum Sinkhole aufbaut.
Ich würde also auf die Modifikation der FRITZ!Box verzichten bzw. sie rückgängig machen, wenn ich die IP-Adresse des/der Sinkhole(s) nicht hätte. Ein "tcpdump -i dsl" fängt nicht alle Pakete ein, solange man den PA nicht abschaltet. Der AVM-eigene Mitschnitt deaktiviert den PA nicht, er versetzt ihn in einen zusätzlichen Status "capture" (cat /proc/net/avm_pa/brief). Solange man also den externen Verkehr mitschneiden will, ist die AVM-Variante in meinen Augen klar im Vorteil. Einzig dann, wenn es um das Mitschneiden des Verkehrs auf "dev lan" geht, macht ein "tcpdump" direkt auf der Box mit Speicherung auf einem größeren USB-Stick wieder Sinn, aber auch dafür braucht man kein Freetz, es reicht das passende Binary (und die libpcap.so). Wenn man aber den lokalen Verkehr mitschneiden und analysieren will, ist eine Appliance mit mächtigeren Tools (die man notfalls auch nachinstallieren kann) aber meines Erachtens die bessere Wahl.
Wenn die Sinkhole-Adresse ohnehin bekannt ist, ist einer Verbindung dorthin per Mitschnitt auf der "Routing-Schnittstelle" problemlos die interne IP-Adresse zuzuordnen, dann brauchst Du Freetz überhaupt nicht. Um Mißverständnisse zu vermeiden: Das geht nicht gegen Freetz, das ist in meinen Augen nur das Vermeiden einer weiteren Baustelle, bis die Schadsoftware lokalisiert ist. Was Du anschließend machen willst, kannst Du dann immer noch überlegen.
