Verdächtigen Netzwerkverkehr filtern

[Andreas Lademann]

Hallo zusammen,

ich muss hier aus mehreren Wireshark-Protokollen verdächtigen
Internetverkehr herausfiltern. Im Speziellen geht es um vermutete
Trojaneraktivitäten und Ausspionieraktionen. Da es sich jeweils um VIELE
Pakete pro Protokoll handelt, bin ich dabei in Wireshark einen Filter zu
basteln, um "vertrauenswürdigen" Traffic auszublenden.
Bevor ich mich jetzt aber auf mein (Halb)wissen verlasse, würde ich
gerne von Euch wissen ob meine Gedanken zu der Filterung richtig sind,
oder ob ich damit auch potentiell gefährlichen Verkehr ausblende.

Hier also meine Regeln, die im Filter gleichzeitig angewendet werden:
(a = anzeigen, na = nicht anzeigen)

- a, wenn Quelladresse der untersuchte PC ist (ip.src)
wichtig ist doch nur ausgehender Traffic, oder?

- na, wenn Zieladresse der Router ist (ip.dst)
- na, wenn Zieladresse Broadcastadresse ist (ip.dst)
- na, wenn Protokoll pop ist
- na, wenn Protokoll smtp ist
- na, wenn Protokoll dns ist
- na, wenn Protokoll http ist (gemeint sind wohl die HTTP-Steuerbefehle
wie z.B. get)
- na, wenn Zielport 80, 110 oder 443 (tcp.dstport)
evtl. nicht so schlau wenn der Trojaner so eingestellt ist, dass er
über einen dieser Ports mit seinem Host kommuniziert...aber ist das
realistisch?

Sind die Regeln so sinnvoll? Was sollte man/muss man ändern?
Hoffe sehr, dass mir hier ein paar Leute weiterhelfen können.

Vielen Dank.
Gruß
Andreas

[Andreas Beck]

Post by Andreas Lademann
ich muss hier aus mehreren Wireshark-Protokollen verdächtigen
Internetverkehr herausfiltern. Im Speziellen geht es um vermutete
Trojaneraktivitäten und Ausspionieraktionen. Da es sich jeweils um VIELE
Pakete pro Protokoll handelt, bin ich dabei in Wireshark einen Filter zu
basteln, um "vertrauenswürdigen" Traffic auszublenden.
- a, wenn Quelladresse der untersuchte PC ist (ip.src)
wichtig ist doch nur ausgehender Traffic, oder?

Nein, Vorsicht. Wenn der vermutete Trojaner bei Trost ist, sendet er
u.U. mit anderer MAC/IP.

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)
- na, wenn Zieladresse Broadcastadresse ist (ip.dst)

Hmm - wenn der Router bei Trost ist, kann man das weglassen, ja.

Post by Andreas Lademann
- na, wenn Protokoll pop ist
- na, wenn Protokoll smtp ist
- na, wenn Protokoll dns ist

Warum? Darüber könnte man tunneln. DNS sogar ziemlich heimtückisch, da
übliche Resolver das auch ganz prima für den Angreifer proxyen.

Post by Andreas Lademann
- na, wenn Protokoll http ist (gemeint sind wohl die HTTP-Steuerbefehle
wie z.B. get)

Das wär meine erste Wahl, um Daten irgendwo rauszuschmuggeln. Einfach
weil es im normalen Traffic untergeht.

Post by Andreas Lademann
- na, wenn Zielport 80, 110 oder 443 (tcp.dstport)
evtl. nicht so schlau wenn der Trojaner so eingestellt ist, dass er
über einen dieser Ports mit seinem Host kommuniziert...

Genau.

Post by Andreas Lademann
aber ist das realistisch?

Hängt vom Trojaner ab. Üblich ist sowas wie IRC, oder eben Mail und http.

Ersteres ist besonders beliebt, weil es einen auch gut anonym bleiben
läßt und man ggf. leicht durch ein paar Indirektionen umzubiegen ist.

Post by Andreas Lademann
Sind die Regeln so sinnvoll? Was sollte man/muss man ändern?
Hoffe sehr, dass mir hier ein paar Leute weiterhelfen können.

Ich persönlich würde der Reihe nach Ziele eliminieren, die ich für
vertrauenswürdig halte.

Ich nahme mal an, das ist alles "post mortem" - man kann nicht
versuchen, den Trojaner zu isolieren und zu zerlegen?

Oder sind Daten bekannt, die vermutlich versendet wurden?


CU, Andy

[Thomas Skora]

Post by Andreas Beck
Nein, Vorsicht. Wenn der vermutete Trojaner bei Trost ist, sendet er
u.U. mit anderer MAC/IP.

Halte ich aus Trojanersicht für eine dumme Idee, weils erstens auffällig
ist und zweitens mittlerweile gern von ISPs gefiltert wird.

Thomas

[Andreas Beck]

Post by Thomas Skora

Post by Andreas Beck
Nein, Vorsicht. Wenn der vermutete Trojaner bei Trost ist, sendet er
u.U. mit anderer MAC/IP.

Halte ich aus Trojanersicht für eine dumme Idee, weils erstens auffällig
ist und zweitens mittlerweile gern von ISPs gefiltert wird.

Innerhalb von RFC1918-Netzen würde ich das testen und probieren.
Erschwert die Fehlersuche beträchtlich. Ist außerdem so schön leicht,
gültige Pärchen (wegen den Nasen, die auf WLANs MAC filtern und weil
es dann weniger auffällt) zu kriegen ... arp -n sagt einem alles, was
man wissen will.

Eigene IP direkt am Dialup zu spoofen ist vermutlich eher blöd, ja.
Und MAC spoofen ist auch eher sinnlos außer bei Anbindungen bei denen die
irgendwie festgezurrt ist. Da ist es kontraproduktiv.


CU, Andy

[Daniel Schmidt]

Post by Andreas Lademann
ich muss hier aus mehreren Wireshark-Protokollen verdächtigen
Internetverkehr herausfiltern. Im Speziellen geht es um vermutete
Trojaneraktivitäten und Ausspionieraktionen. Da es sich jeweils um VIELE
Pakete pro Protokoll handelt, bin ich dabei in Wireshark einen Filter zu
basteln, um "vertrauenswürdigen" Traffic auszublenden.

Das ist ja mal eine Herausforderung.

Post by Andreas Lademann
Bevor ich mich jetzt aber auf mein (Halb)wissen verlasse, würde ich
gerne von Euch wissen ob meine Gedanken zu der Filterung richtig sind,
oder ob ich damit auch potentiell gefährlichen Verkehr ausblende.
(a = anzeigen, na = nicht anzeigen)
- a, wenn Quelladresse der untersuchte PC ist (ip.src)
wichtig ist doch nur ausgehender Traffic, oder?

Naja, er könnte auch Anweisungen und Erweiterungen aus dem Internet
nachladen. Ich würde auf alle Pakete filtern, die mit dem zu
untersuchenden PC zusammenhängen.

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)

ok

Post by Andreas Lademann
- na, wenn Zieladresse Broadcastadresse ist (ip.dst)

ok (oder sucht er nach weiteren infizierten Rechnern, um mit denen zu
kommunizieren)

Post by Andreas Lademann
- na, wenn Protokoll pop ist
- na, wenn Protokoll smtp ist
- na, wenn Protokoll dns ist

Wie wird der Rechner genutzt? Wenn ein User normalerweise daran
arbeitet, alle Programme beenden, User abmelden. Das sollte dann
eigentlich nix mehr popen oder smtp sprechen bzw. dns fragen.
Die DNS Abfragen könnten interessant sein.

Post by Andreas Lademann
- na, wenn Protokoll http ist (gemeint sind wohl die HTTP-Steuerbefehle
wie z.B. get)

nachladen von trojaner modulen...

Post by Andreas Lademann
- na, wenn Zielport 80, 110 oder 443 (tcp.dstport)
evtl. nicht so schlau wenn der Trojaner so eingestellt ist, dass er
über einen dieser Ports mit seinem Host kommuniziert...aber ist das
realistisch?

Ich denke schon. Viele Rechner stehen hinter einer Firewall, oft ist
nach draussen nur http(/s), smtp, pop möglich - teilweise nur über
Proxies; Autoren von trojanischen Pferden dürften das i.d.R.
berücksichtigen.

Post by Andreas Lademann
Sind die Regeln so sinnvoll? Was sollte man/muss man ändern?
Hoffe sehr, dass mir hier ein paar Leute weiterhelfen können.

Ich würde zunächst den Kommunikationsbedarf des Rechners so weit
reduzieren, wie es irgendwie möglich ist; Dienste de-aktivieren,
Programme beenden etc. Alles was dann noch von bzw. zu diesem Rechner
kommuniziert wird, gilt es zu untersuchen. Bekannte Server und den
Router kann man dabei sicher ausklammern, um den Infrastrukurkrams
auszublenden.

Das dürfte eine zeitaufwändige Sache werden - ist da eine
Neuinstallation nicht schneller?

mfg.,

-ds-

[Juergen P. Meier]

Post by Andreas Lademann
Hallo zusammen,
ich muss hier aus mehreren Wireshark-Protokollen verdächtigen
Internetverkehr herausfiltern. Im Speziellen geht es um vermutete
Trojaneraktivitäten und Ausspionieraktionen. Da es sich jeweils um VIELE
Pakete pro Protokoll handelt, bin ich dabei in Wireshark einen Filter zu
basteln, um "vertrauenswürdigen" Traffic auszublenden.
Bevor ich mich jetzt aber auf mein (Halb)wissen verlasse, würde ich
gerne von Euch wissen ob meine Gedanken zu der Filterung richtig sind,
oder ob ich damit auch potentiell gefährlichen Verkehr ausblende.
(a = anzeigen, na = nicht anzeigen)
- a, wenn Quelladresse der untersuchte PC ist (ip.src)
wichtig ist doch nur ausgehender Traffic, oder?

Um die Konsistenz eines Anwedungsprotokolls nachvollziehen zu koennen,
brauchst du die bidirektionale Kommunikation im Kontext. Also beide
Richtungen.

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)

Nein. Router werden nur auf Schicht 2 (Ethernet) Addressiert.

Post by Andreas Lademann
- na, wenn Zieladresse Broadcastadresse ist (ip.dst)

Das ist ein Merkmal dummer Windows-wuermer, und kann dir helfen solche
zu identifizeren. ;)

Post by Andreas Lademann
- na, wenn Protokoll pop ist
- na, wenn Protokoll smtp ist
- na, wenn Protokoll dns ist

Die Anlayse von DNS Queries kann durchaus aufschluss ueber die
Aktivitaeten ungwollter Programme bringen, da diese oftmals DNS
verwenden um Hostnamen oder neuerdings Services aufzuloesen.

Post by Andreas Lademann
- na, wenn Protokoll http ist (gemeint sind wohl die HTTP-Steuerbefehle
wie z.B. get)

Die GET Methode von HTTP ist vollkommen ausreichend fuer bidirektionale
Kommunikation. Einen funktionierenden IP-over-HTTP tunnel PoC, der
ausschliesslich GET Methode verwendet, habe ich auch schon mal in
Haenden gehalten (deutlich langsahmer als POST methode, aber es geht).

Post by Andreas Lademann
- na, wenn Zielport 80, 110 oder 443 (tcp.dstport)
evtl. nicht so schlau wenn der Trojaner so eingestellt ist, dass er
über einen dieser Ports mit seinem Host kommuniziert...aber ist das
realistisch?

Die meisten Griechen kommunizieren von deinem Trojanischen Rechner aus
mittels verschiedenster Protokolle. Haeufig sieht man IRC (TCP
irgendein Port, meistens zwischen 6666 und 6670)

Post by Andreas Lademann
Sind die Regeln so sinnvoll? Was sollte man/muss man ändern?
Hoffe sehr, dass mir hier ein paar Leute weiterhelfen können.

Geh systematisch vor: Identifiziere "gute" Kommunikationsstroeme und
filtere diese einen nach dem anderen aus.

Du kannst bei Wireshark dabei (um die Arbeit zu beschluenigen) als
Zwischenschritt nach anwendung eines weiteren Filters das gefilterte
Ergebnis unter neuem Namen als Capturefile abspeichern. Gerade bei
grossen Files dauert das Applizieren eines neuen Filters durchaus
lange.

Juergen

[Heiko Schlenker]

Post by Juergen P. Meier

Post by Andreas Lademann
(a = anzeigen, na = nicht anzeigen)

[...]

Post by Juergen P. Meier

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)

Nein. Router werden nur auf Schicht 2 (Ethernet) Addressiert.

Aus dieser Bemerkung werde ich nicht recht schlau. Es mag z.B. auf
Switches zutreffen, aber Router arbeiten allg. auf der IP-Schicht.

Gruß, Heiko

[Juergen P. Meier]

Post by Heiko Schlenker

Post by Juergen P. Meier

Post by Andreas Lademann
(a = anzeigen, na = nicht anzeigen)

[...]

Post by Juergen P. Meier

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)

Nein. Router werden nur auf Schicht 2 (Ethernet) Addressiert.

Aus dieser Bemerkung werde ich nicht recht schlau. Es mag z.B. auf
Switches zutreffen, aber Router arbeiten allg. auf der IP-Schicht.

Jeder Host, der Ethernet spricht, arbeitet auch auf dieser
Schicht. Wenn du ein Paket an einen entfernten Host schicken
moechtest, schreibst du in den Ethernethaeder die Adresse des
IP-Routers rein, ueber den du diesen Host erreichen kannst, und
schickst deinem Router das Paket auf Schicht 2.

Juergen

[Heiko Schlenker]

Post by Juergen P. Meier

Post by Heiko Schlenker

Post by Juergen P. Meier

Post by Andreas Lademann
(a = anzeigen, na = nicht anzeigen)

[...]

Post by Juergen P. Meier

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)

Nein. Router werden nur auf Schicht 2 (Ethernet) Addressiert.

Aus dieser Bemerkung werde ich nicht recht schlau. Es mag z.B. auf
Switches zutreffen, aber Router arbeiten allg. auf der IP-Schicht.

Jeder Host, der Ethernet spricht, arbeitet auch auf dieser
Schicht.

Und warum sollen Router *nur* auf Schicht 2 adressiert werden? ;-)

Gruß, Heiko

[Denis Jedig]

Post by Heiko Schlenker
Und warum sollen Router *nur* auf Schicht 2 adressiert werden? ;-)

Gemeint ist: wenn ein Paket durchgeroutet wird, dann ist die
Ziel-MAC-Adresse die des Router-Ethernet-Interfaces aber die IP-Adresse
*nicht* die des Router-IP-Interfaces.

[Oliver Schad]

Post by Heiko Schlenker

Post by Juergen P. Meier

Post by Heiko Schlenker

Post by Juergen P. Meier
Nein. Router werden nur auf Schicht 2 (Ethernet) Addressiert.

Aus dieser Bemerkung werde ich nicht recht schlau. Es mag z.B. auf
Switches zutreffen, aber Router arbeiten allg. auf der IP-Schicht.

Jeder Host, der Ethernet spricht, arbeitet auch auf dieser
Schicht.

Und warum sollen Router *nur* auf Schicht 2 adressiert werden? ;-)

Wenn er ein Paket routen soll, geht das so. Ansonsten kann man auch
gerne alle höheren Schichten ansprechen.

mfg
Oli

[Juergen P. Meier]

Post by Heiko Schlenker

Post by Juergen P. Meier

Post by Heiko Schlenker

Post by Juergen P. Meier

Post by Andreas Lademann
(a = anzeigen, na = nicht anzeigen)

[...]

Post by Juergen P. Meier

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)

Nein. Router werden nur auf Schicht 2 (Ethernet) Addressiert.

Aus dieser Bemerkung werde ich nicht recht schlau. Es mag z.B. auf
Switches zutreffen, aber Router arbeiten allg. auf der IP-Schicht.

Jeder Host, der Ethernet spricht, arbeitet auch auf dieser
Schicht.

Und warum sollen Router *nur* auf Schicht 2 adressiert werden? ;-)

"In Der Regel". Und wenn du einen Server auf der Box, die
Routerfunktion implementiert laufen hast, dann solltest du das Teil im
jeweiligen Kontext "Server" nennen, nicht "Router". Eine gewisse
Praezision bei Beschreibungen von technischen Sachverhalten ist
oftmals eher hilfreich.

Und selbst wenn du einen Service auf deinem "Router" direkt
ansprichst, ist bei einem lokalen Netz derselbe ebenso ueber Schicht 2
Addressiert (wie jede andere lokale Gegenstelle). Dass diese
Ethernetaddresse auch das selbe System addressiert wie die IP Addresse
in Schicht 3 ist in diesem Fall ja Sinn des ganzen.

Aber Pakete auf Ethernetkabeln zwischen Rechnern werden ueber das
Schicht-2 Protokoll Ethernet transportiert, mit Ethernetaddressen fuer
Quelle und Ziel.

Strenggenommen. (Ja, solange jeder weis was du bei Verwendung eines
vorbelegten Fachbegriffs in einer Fachlichen Diskussion wirklich
meinst, brauchst du auf die Korrektheit der Begrifflichkeiten
natuerlich keine Ruecksicht nehmen, aber wir sind hier im Usenet in
einer offenen Runde.)

Juergen

[Heiko Schlenker]

Post by Juergen P. Meier

Post by Heiko Schlenker

Post by Juergen P. Meier

Post by Heiko Schlenker

Post by Juergen P. Meier

Post by Andreas Lademann
(a = anzeigen, na = nicht anzeigen)

[...]

Post by Juergen P. Meier

Post by Andreas Lademann
- na, wenn Zieladresse der Router ist (ip.dst)

Nein. Router werden nur auf Schicht 2 (Ethernet) Addressiert.

Aus dieser Bemerkung werde ich nicht recht schlau. Es mag z.B. auf
Switches zutreffen, aber Router arbeiten allg. auf der IP-Schicht.

Jeder Host, der Ethernet spricht, arbeitet auch auf dieser
Schicht.

Und warum sollen Router *nur* auf Schicht 2 adressiert werden? ;-)

"In Der Regel". Und wenn du einen Server auf der Box, die
Routerfunktion implementiert laufen hast, dann solltest du das Teil im
jeweiligen Kontext "Server" nennen, nicht "Router".

Router arbeiten protokollabhängig. Um IP-Pakete weiterleiten zu
können, muss ein Router auf der IP-Schicht (Schicht 3) arbeiten. Er
ist auch auf Schicht 3 adressierbar. Man braucht sich beispielsweise
bloß die Forwarding-Tabelle ("netstat -rn") anzugucken. :-)

Gruß, Heiko

[Juergen P. Meier]

[Heiteres Begrifflichkeitenmikado]

Ich glaube wir sollten diese Fruchtlose Diskussion einstellen und uns
einfach denken, was der andere meinte ;)

Juergen

[Florian Weimer]

Post by Andreas Lademann
Sind die Regeln so sinnvoll?

Nein, HTTP solltest Du nicht ausnehmen.

Post by Andreas Lademann
Was sollte man/muss man ändern?

Wenn Du ein bereits bekanntes Trojanisches Pferd finden willst, ist es
meist einfacher, nach deren Kommunikationsmustern zu suchen. Wenn Du
nach etwas Unbekanntem suchst, kann es, abhängig von der Datenmenge,
sehr schwierig werden.

[Thomas Skora]

Post by Andreas Lademann
- na, wenn Protokoll dns ist

DNS war bei mir mehrmals das Protokoll, dass mich auf "böse Datenströme"
aufmerksam gemacht hat. Es ist nun mal auffällig wenn die Kiste eines

Post by Andreas Lademann
70jährigen, für den das Netz gleich HTTP ist plötzlich jede Sekunde

wissen möchte, welche IP irc.$foobar hat ;-)

Nach Anwendungsprotokollen würde ich gar nicht filtern. Der hier bereits
vorgeschlagene Ansatz, nicht-verdächtigen Verkehr nach und nach
rauszufiltern würde ich auch befürworten.

Thomas

[Philipp E. Letschert]

Post by Andreas Lademann
Hallo zusammen,
ich muss hier aus mehreren Wireshark-Protokollen verdächtigen
Internetverkehr herausfiltern. Im Speziellen geht es um vermutete
Trojaneraktivitäten und Ausspionieraktionen. Da es sich jeweils um VIELE
Pakete pro Protokoll handelt, bin ich dabei in Wireshark einen Filter zu
basteln, um "vertrauenswürdigen" Traffic auszublenden.
Bevor ich mich jetzt aber auf mein (Halb)wissen verlasse, würde ich
gerne von Euch wissen ob meine Gedanken zu der Filterung richtig sind,
oder ob ich damit auch potentiell gefährlichen Verkehr ausblende.

Du könntest auch die Wireshark Dumps in ein Argus [1] Format umwandeln,
dann werden die einzelnen Pakete zu Transaktionen zusammengefasst. Das
würde zumindest die zu untersuchende Datenmenge reduzieren. Das
Argus-File kannst du dann auch via ra(1) mit einer tcpdump-kompatiblen
Filter-Syntax untersuchen.

Ich arbeite auch gerade an einer GUI dafür... [2]


Grüße, Philipp


[1] ftp://qosient.com/dev/argus-3.0/
[2] http://www.datenspionage.de/arguseye/