freetz newbie: wegen Telekom Viruswarnung Traffic loggen

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
Da bin ich leider schon wieder :-(

Beim Testen mit:
iptables -A FORWARD -d 147.203.55.2 -j LOG

bekomme ich folgenden Fehler:
modprobe: module ip_tables not found in modules.dep
iptables v1.4.11.1: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Hat jemand einen Tipp?
 

Joe_57

IPPF-Promi
Mitglied seit
5 Mrz 2006
Beiträge
6,783
Punkte für Reaktionen
273
Punkte
83
Warum lässt du nicht einfach mal die kostenlose Malwarebytes-Software auf deinen PCs laufen?
Die findet normalerweise jede Malware/jeden Trojaner und entfernt die auch zuverlässig.

Joe
 

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
whow, PeterPan, danke für die ausführlichen Hinweise.
ich hatte schon mal kurz mit Paketdump der Fritzbox experimentiert, konnte aber nicht wirklich was damit anfangen.
Was muss ich denn da einschalten, damit ich sowohl LAN als auch WLAN sauber protokollieren kann?
Ich werde mich dann jetzt auf diesen Weg machen und die Box auf original zurücksetzen.

@Joe
ich habe nach dieser Anleitung http://www.trojaner-board.de/163975-telekom-abuse-team-e-mail-generic-trojaner.html vier Viren- und Malware-Scanner durchlaufen lassen und zusätzlich von einer AVG-Live-CD gescannt. NICHTS gefunden. Einen Rechner (an dem ich gerade sitze) habe ich komplett formatiert und statt Windows jetzt Ubuntu drauf. Vier Android-Handies und ein Tablet habe ich mit AVG-Apps gescannt - erfolglos.
Alle "unixoiden" Rechner habe ich zwei Wochen lang komplett vom Internet getrennt um sie ausschliessen zu können.
Wenn ich jetzt nicht via Protokollierung etwas finde, muss ich wohl alles neu aufsetzen.
 

thtomate12

IPPF-Promi
Mitglied seit
28 Okt 2010
Beiträge
5,165
Punkte für Reaktionen
6
Punkte
38
wVier Android-Handies und ein Tablet habe ich mit AVG-Apps gescannt - erfolglos.

Virenscanner auf Mobilgeräte können nicht funktionieren, wegen dem ganz tollen "Sicherheit"skonzept.
Richte mal die KiSi ein, auf eine leere Blacklist und HTTPS erlaubt, falls die C&C-Verbindung direkt über die IP-Adresse geht, dies in der Fritzbox im Log aufgeführt und bei den Android-Handies sind die Google-IPs zu ignorieren.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,837
Punkte für Reaktionen
1,579
Punkte
113
Was muss ich denn da einschalten, damit ich sowohl LAN als auch WLAN sauber protokollieren kann?
Irgendwo im sonntäglichen Kuddelmuddel ist der gesamte Beitrag beim Korrekturlesen versehentlich veröffentlicht worden und jetzt ist er komplett verschwunden. Wenn da also irgendwelche Unlogik noch enthalten sein sollte, ist das unabsichtlich. Die E-Mail-Benachrichtigung an Abonnenten ist wohl die einzige Quelle für den vorherigen Text ... aber das ist auch nicht so wichtig, solange Du ihn hast.

Wie geschrieben ... kläre erst einmal, ob Du die Adresse des vermeintlichen C&C-Servers von der Telekom kriegst. Wenn ja, ist ein Mitschnitt auf der "Routingschnittstelle" in entsprechender Länge (auf einem beliebigen LAN-Host mit ausreichendem Speicher) alles, was Du brauchst. Erst wenn die Telekom an dieser Stelle nicht kooperiert (ich weiß nicht, wie sie ggü. Privatpersonen da reagiert), mußt Du Dir weitere Gedanken machen. Aber auch dann ist eine originale Firmware erst einmal der bessere Ausgangspunkt, Freetz kannst Du Dich immer noch widmen, wenn Du das akute Problem gelöst hast.

Wenn Du am Scheideweg (mit Sinkhole-Adresse oder ohne) stehst und eine Richtung gewählt hast, können wir ja weitermachen.
 

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
Irgendwo im sonntäglichen Kuddelmuddel ist der gesamte Beitrag beim Korrekturlesen versehentlich veröffentlicht worden und jetzt ist er komplett verschwunden.
Oh - Mist. Ich hatte den Text zwar gelesen, aber natürlich auch nicht abgespeichert. Falls ihn also noch jemand in der Mail-Benachrichtigung hat, wäre es super toll, wenn der ihn hier wieder reinkopieren würde.

Parallel werde ich jetzt mal die Anfrage an die Telekom rausschicken.
 

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
Perfekt! KunterBunter hatte die Daten noch im Browser-Cache und hat sie mir geschickt. DANKE dafür!

Zur Dokumentation werdee ich sie hier auch gerne nochmal reinhängen, wenn PeterPawn das möchte und zustimmt.
 
Zuletzt bearbeitet:

Theo Tintensich

Aktives Mitglied
Mitglied seit
10 Mrz 2008
Beiträge
2,087
Punkte für Reaktionen
76
Punkte
48
Die Malware, die auf dem Rechner sich installiert hat, baut selber eine Verbindung zum C&C-Server auf und holt sich dann die benötigten Befehle ab.
Wenn es von der Malware und dem C&C-Server möglich ist, kann auch eine permanente Verbindung offen gehalten werden, über die dann die Malware gesteuert werden.

Das ist ein Mechanismus wie bei einer SIP-Verbindung, bei der das Telefon hinter einem NAT-Router die Verbindung zum Registrar offen hält, damit ankommende Anrufe durch den NAT-Router zum Telefon gebracht werden können.


Das Sperren des Verkehrs zu den C&C-Servern ist noicht einfach, da die moderne Malware mit wechselnden C&C-Servern zusammenarbeiten kann.
Auch mit welchen, die hinter NAT-Routern hängen.
Wenn die einen Server im Internet kapern können, der die Befehle weiterleiten kann.

Im Übrigen könnte man solches auch über einen SIP-Registrar machen.
Z.B. mit SIP-Telefon-URIs, die von Anbietern ohne kosten weitergeleitet werden.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,837
Punkte für Reaktionen
1,579
Punkte
113
Zur Dokumentation werdee ich sie hier auch gerne nochmal reinhängen, wenn PeterPawn das möchte und zustimmt.
Kein Problem ... aber ich war - wie gesagt - noch beim Korrekturlesen und daher können da Wiederholungen und auch teilweise Widersprüche enthalten sein, wenn ich beim Schreiben noch eine (meiner Meinung nach) bessere Idee für einen praktikablen Vorschlag hatte.

Wenn ich in dem Text also noch großen Bockmist finden würde, hätte ich gerne die Option, den dann über Dich auch noch auszubügeln ... wenn das kein Problem ist, kannst Du den gerne noch einmal posten. Ich würde ihn zwar lesen, habe aber jetzt auch nicht den Ehrgeiz, ihn selbst noch mal zu redigieren.
 

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
ok, hier nochmal der wie ich finde sehr informative Text von PeterPawn:
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.
 
Zuletzt bearbeitet:

µRaCoLi

Mitglied
Mitglied seit
22 Sep 2005
Beiträge
239
Punkte für Reaktionen
0
Punkte
0
Da bin ich leider schon wieder :-(

Beim Testen mit:
iptables -A FORWARD -d 147.203.55.2 -j LOG

bekomme ich folgenden Fehler:
modprobe: module ip_tables not found in modules.dep
iptables v1.4.11.1: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

Hat jemand einen Tipp?

Du brauchst wohl noch FREETZ_MODULE_iptable_filter

Da die Telekom dich schon auf Port 80/443 hingewiesen hat, kannst du auch gleich diese Zugriffe loggen. Auch praktisch, wenn man die IP des Sinkhole nicht weiss.
Code:
iptables -A FORWARD -p tcp --dport 80 --syn -j LOG
iptables -A FORWARD -p tcp --dport 443 --syn -j LOG
Dies sollte eine ganze Menge loggen, was man am besten auf einen syslog-server weiterleitet. FREETZ_PACKAGE_SYSLOGD_CGI kann das.
Wenn du einen Linux-Server hast, kann rsyslogd oder syslog-ng die Freetz-Logs entgegennehmen.
Die Lösung mit iptables spart dir den Umbau deines Netzwerkes.
Du findest die Freetz-Module in menuconfig ganz einfach, wenn du mit / danach suchst.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,837
Punkte für Reaktionen
1,579
Punkte
113
µRaCoLi schrieb:
Die Lösung mit iptables spart dir den Umbau deines Netzwerkes.
Wo liegt denn - abgesehen von der geringeren Datenmenge bei der Aufzeichnung, zu deren Bewältigung aber leistungsfähige Tools existieren - der Vorteil der Freetz-Lösung mit iptables ggü. einem einfachen Mitschnitt von einem sauberen Rechner mit dem AVM-Packetdump, der nach Recovery und Wiederherstellen der Einstellungen (die der TE hoffentlich vor dem "Freetzen" gesichert hatte) quasi unmittelbar gestartet werden kann und dann sogar denselben Netzwerkzustand vorfindet, in dem der Bot bekanntermaßen schon aktiv war?

Dafür muß er überhaupt nichts umbauen, während für die von Dir vorgeschlagene Lösung noch mindestens die folgenden Schritte notwendig sind:

1. neue Freetz-Image mit den fehlenden iptables-Modulen erstellen und flashen
2. iptables entsprechend konfigurieren
3. Syslog-Server einrichten, Du wirst mir sicherlich zustimmen, daß bei einer FRITZ!Box das Schreiben des Syslog auf einen USB-Stick keine so furchtbar gute Idee ist (Du rätst ja selbst zu einem Server) und eine MemoryBuffer-Lösung wrd mit einiger Sicherheit nicht funktionieren.

Und auch dann erwischt er mit den LOG-Targets nur die SYN-Pakete an die Ports 80 und 443.

Damit hat er hinterher eine sehr lange Liste von IP-Adressen, zu denen seine Clients im Laufe der Zeit so ihre Verbindungen aufgenommen haben. Wie soll er die hinterher nur einigermaßen sinnvoll analysieren?

Da brauchen bloß auf irgendwelchen Clients Programmpakete nach Updates fragen, die über ein CDN ausgeliefert werden (meinetwegen Akamai oder Amazons EC2) ... und schon kannst Du Dir eine Reverse-Auflösung einfach sauer kochen, weil sie keine verwertbaren Ergebnisse bringt.

Wenn Du dann nicht den entsprechenden A/AAAA-Request in den aufgezeichneten DNS-Daten finden kannst, hast Du (meine Meinung, bitte erkläre mir, wie es anders geht) nur einen Wust an IP-Adressen, bei denen Du selbst mit einer automatisierten RDNS-Abfrage und der Konsolidierung der Ergebnisse durch irgendwelche Skripte oder Tools nur geringe Chancen auf Aufklärung hast.

Schon ein HTTPS-Request mit SNI wird von einem "normalen" iptables-LOG-Target nicht erschöpfend behandelt und gerade bei Bot-Netzen ist die Taktik mit einer IP-Adresse für verschiedene SSL-Präsenzen ja nun nicht ungewöhnlich/unwahrscheinlich.

Den Fall der direkten Protokollierung mit der IP-Adresse des Sinkhole (wo dann die Auswertung der Zieladressen nicht mehr notwendig ist) kannst Du ja eigentlich nicht gemeint haben, dafür passen die iptables-Vorschläge nicht ...

EDIT: Ok, die ersten Schritte - Freetz-Image flashen (nicht erstellen, das ist extra) vs. Recovery - heben sich zumindest teilweise vom Aufwand her auf, damit das kein Mißverständnis gibt. Aber schon die Konfiguration von Syslog und iptables (mit den richtigen 'modprobe's usw.) ist ein höherer Aufwand, als einfach die Sicherung wieder einzuspielen und der Vorteil der identischen Umgebung besteht hinterher schon. Die anschließenden Fragen der Auswertung sind ja vom "Umbau-Aufwand" unabhängig.
 
Zuletzt bearbeitet:

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
Mir gefällt die Standard Lösung im Moment auch besser. Trotzdem Danke an µRaCoLi für die vielen Tipps! Ich werde deine Lösung im Anschluss zu Forschungszwecken auch noch mal weiter verfolgen.

Mittlerweile habe ich auch eine Antwort von der Telekom. Leider rücken die die Ziel-IP nicht raus:
Wir wissen in Ihrem Fall nicht einmal, welche Schadsoftware hier tätig ist: Vom Hinweisgeber, einer deutschen Forschungsgesellschaft, wird der Schädling lediglich als 'generic bot-infection' bezeichnet und die zugreifende IP-Adresse und der Zeitpunkt dieses Zugriffs genannt.

Bleibt also nur das loggen des gesamten Traffics mit anschliessender Analyse, wenn der nächste Befund auftritt?

Nur noch mal zur Sicherheit, aktuell logge ich in der Box den Punkt: "Internet - Routing Schnittstelle". Eine erste Anayse mit Wireshark sieht so aus, als ob ich damit jede Menge Infos bekomme. Reicht das, oder sollte ich da noch mehr anklicken?
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
14,837
Punkte für Reaktionen
1,579
Punkte
113
@donny:
Vielleicht haben wir uns da etwas mißverstanden. Ich weiß ja nicht, wieviel Internetverkehr Dein Anschluß im Normalfall so produziert, aber ich kann mir nicht vorstellen, daß es sinnvoll ist, diesen Mitschnitt jetzt einfach so lange laufen zu lassen, bis Du die nächste Nachricht von der Telekom erhältst, das habe ich auch nie geschrieben.

Je nach konkreten Zugriffen auf das Sinkhole - bzw. je nach deren Häufigkeit in der Vergangenheit - mußt Du Dir m.E. eine Laborumgebung schaffen.

Die erste Frage, die Du Dir stellen mußt: Willst Du jetzt eine Aufzeichnung machen, die Du bei der nächsten Meldung seitens der Telekom auswerten kannst oder willst Du selbst aktiv die Suche nach verdächtigen Verbindungen angehen?

Im ersten Fall ist der Vorschlag von µRaCoLi tatsächlich sinnvoller, da Du vermutlich mit der Aufzeichnung des Datenverkehrs über mehrere Tage überfordert wärst. Es gäbe zwar auch noch die Möglichkeit, in diesem Falle eine "kontrollierte Umgebung" zu schaffen, die man anhand eines eigenen Protokolls dann bei der Meldung durch die Telekom analysieren kann, aber wenn die Meldungen erst nach 14 Tagen eintreffen und den exakten Zeitpunkt des Zugriffs bis zur Sekunde enthalten, bist Du mit einer Protokollierung der reinen SYN-Pakete ja trotzdem in der Lage, die exakte Zieladresse in Erfahrung zu bringen, wenn die Clock-Sources halbwegs synchron sind. "Kontrollierte Umgebung" könnte dann eben heißen, daß Du Dir die Zeit nimmst und jeden Client in Deinem Netz (mit laufendem Packetdump - die Routingschnittstelle ist in diesem Fall der richtige Punkt, wobei Du irgendwie einen NTP- oder HTTP-Request (mit dynamischem Inhalt und Zeitstempel) als zeitlichen Referenzpunkt brauchen würdest) nach einem Neustart des Gerätes - damit der Bot sich neu anmelden muß - für bspw. 10 Minuten quasi alleine ins Internet läßt. Das dann noch ordentlich notiert (wer das von wann bis wann war), grenzt es auch dann auf max. 2 Gerate ein, wenn die Zeitangaben eine Abweichung von max. 10 Minuten in beide Richtungen haben. Das wäre dann der "passive" Test, bei dem Du zwar Traffic hast, aber auch auf die nächste Meldung des Providers warten mußt.

Zur aktiven Suche habe ich (fast) alles geschrieben, was mir einfiel. Es ist Aufwand, wenn man das aber ins Verhältnis zu "alles platt machen" setzt, relativiert sich das schnell. Auch hier ist natürlich der Kern, den Bot durch Neustart seines Hosts zur Kontaktaufnahme mit dem C&C-Server zu bewegen und nicht einfach alles mitzuschneiden, bis er irgendwann mal geruht, das von sich aus zu machen.

Und nur noch mal zur Sicherheit, daß wir nicht über verschiedene Dinge reden ... wenn ich mitschneiden müßte, würde ich das auf einem Host machen, auf dem ich schon während der Speicherung auf die Dateiinhalte zugreifen kann (was bei modernem Windows eher nicht funktioniert, wenn es ein "normales" File ist), wenn ich unbedingt den laufenden Verkehr brauche. Eine Aufzeichnung in Intervallen halte ich für weniger sinnvoll, das geht vielleicht noch dann, wenn man auch hier jeweils nur einem kontrollierten Client für eine entsprechende Zeitspanne den Zugang gewährt. Das müßte dann aber wirklich so konsequent umgesetzt werden, daß nach ihrem "slot" auch alle Smartphones/Tablets/Küchenradios/Wecker/usw. wieder konsequent aus dem LAN genommen werden (so wie natürlich vorher auch schon, zur "Restart-Problematik" bei solchen Geräten - wo "aus" auch schon mal "anscheinend" ist - hatte ich schon geschrieben).

Welche Variante für Dich die richtige ist, mußt Du selbst wissen ... ich würde dazu als erstes mal die bisherigen Meldungen untersuchen und die Frequenz der Kontaktaufnahmen des Bots mit dem Sinkhole ermitteln. Wenn der Bot sich von einem Neustart seines Gerätes gar nicht beeindrucken läßt und ohnehin nur jeweils an Dienstag zwischen 4 und 5 Uhr UTC die Kontaktaufnahme versucht, kannst Du meinen Vorschlag der aktiven Suche zu jeder anderen Zeit ja ohnehin knicken.
 
Zuletzt bearbeitet:

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
Na ja, es ist so:

Die Zugriffe erfolgen lt. Telekom so etwa alle ein bis zwei Tage verteilt zwischen 18:00 und 22:00 Uhr.
Das ist die Zeit, wo alle wieder zu Hause sind, die Kinder nehmen ihre Rechner in Betrieb und die Handies sind ins WLAN eingebucht. Bisher gibt es keine Zugriffe vor 18:00 Uhr, obwohl die Kinder oft deutlich früher von der Schule kommen und damit Handies und Computer ins Netz nehmen.

Mir scheint also der Zugriff unabhängig von Rechnerstarts oder WLAN-Logins stattzufinden. Ich denke eher, dass es vielleicht der Aufruf einer bestimmten App auf einem Handy ist. Die Familie hat aber dazu keine Idee.

Mein Plan ist also tatsächlich derzeit, zwischen 18:00 und 22:00 Uhr zu loggen und beim nächsten Befund die aufgezeichneten Pakete nach Datum/Zeit zu filtern.
Das halte ich schon ein paar Tage durch ;-)
 

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
Zwischenbericht:

Seitdem ich die Aufzeichnungen laufen habe, ist nichts mehr aufgetreten. Auch auf Nachfrage bei der Telekom nicht.
Ich hoffe, ich habe die Malware nicht verschreckt ;-)
Aber ich hatte vorher auch schon mal eine Woche lang keine Befunde, deshalb denke ich, es wird schon noch was kommen.

Ich habe die Aufzeichnung mittlerweile per crontab automatisiert. Je nach Nutzung kommen im Zeitraum von 18:00 bis 22:00 Uhr täglich zwischen 20 MB und 250 MB an Dump-Dateien zusammen. Da ich aktuell noch gut 1,5 TB Platz frei habe, kann ich das eine Weile durchhalten.

Sobald was passiert, werde ich hier weiter berichten.
 

donny

Neuer User
Mitglied seit
31 Mai 2006
Beiträge
72
Punkte für Reaktionen
1
Punkte
8
Der Paketmitschnitt läuft nun seit ca vier Wochen. Seitdem habe ich keine Telekom-Meldung mehr bekommen.

Heute habe ich jetzt alle Aufzeichnungen per wireshark gegen eine Bad-IP-Liste von zeustracker gefiltert. Auch dabei sind keine Auffälligkeiten gefunden worden.

Ich gehe deshalb davon aus, dass der Trojaner gestorben ist. Entweder hat eine der vielen Malware-Scans das Problem beseitigt, ohne dass es mir aufgefallen ist. Oder es war tatsächlich eine Android-App, die mittlerweile nicht mehr verwendet wird oder deinstalliert wurde.

Ich werde jetzt den Paketmitschnitt ausplanen und hoffe, dass ich nie wieder Probleme bekomme.

Danke für die viele und konstruktive Hilfe in diesem Forum
Donny
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.