tcpdump und grep

[BiBe]

Hi,
ich würde gerne mit einem Befehl wie

tcpdump -A |grep '1' > test

bestimmte Teile der Ausgabe von tcpdump in eine Datei schreiben. Leider klappt das aber nicht so, wie oben angegeben.

Mit -w könnte ich die komplette Ausgabe in die Datei schreiben, wobei die dann ziemlich groß werden würde. Das würde ich gerne vermeiden.

Wenn ich mit tcpdump selbst filtere, bezieht sich das IMHO nur auf die Header, aber mit -A will ich ja explizit den Inhalt durchsuchen.

Ich würde mich freuen, wenn mir jemand sagen könnte, wieso obiges so nicht funktioniert. Ich habe schon an einen buffer gedacht, der nicht in die Datei geleert wird, weil ich das Programm mittels ^C abbreche. Aber -nl hilft auch nichts und selbst, wenn ich das einige Minuten laufen lasse, kommt kein Zeichen in die Datei.

Wer kann helfen?

Viele Grüße
BiBe

 

[Goodspeed]

Äh ... geht doch ...

Bekommste ohne das ">test" Output?

 

[daedalus]

probier mal:
tcpdump > datei |grep filterwort

 

[BiBe]

Hi,
vielen Dank für die schnellen Antworten.

@Goodspeed:
Also bei mir bleibt die Datei leider leer und, ja, natürlich bekomme ich ohne "> test" Output auf die Konsole. Viele Pakete enthalten eine '1'.
Bei dir funktioniert das? Hast du eine Ahnung, woran das liegen könnte?

@daedalus:
Mit

tcpdump > test |grep '1'

füllt sich die Datei ungefiltert, das grep hat also keine Auswirkungen auf den Inhalt der Datei. So wird mir diese aber zu schnell zu groß.

Viele Grüße
BiBe

 

[daedalus]

stimmt,... nimmt sich nix... da war ich diesmal wohl zu voreilig, sry...
aber vllt. erfüllt bzw. hilft dir ngrep weiter... fällt mir so auf die schnelle ein...

 

[theton]

tcpdump unterstuetzt den Output in eine Pipe nicht. Daher funktioniert schon ein

tcpdump | grep '1'

nicht (habs extra ausprobiert, kein Output). *anmerk*
Meine Empfehlung: Einfach snort benutzen. ('snort -v' sorgt dafuer, dass snort als Paket-Sniffer laeuft. Will man den Datenteil der Pakete auch sehen, benutzt man einfach '-vd' als Option. Sehr ausfuehrlichen Output gibt es mit '-vde'). Ansonsten ist auch tethereal (ethereal fuer die Konsole) eine gute Moeglichkeit tcpdump zu ersetzen.

 

[slasher]

Das Leben ist so leicht, .. mit einem Bier, einer hübschen Frau und einer leckeren Manpage:

tcpdump -l > dat & tail -f dat

Ps.: ich wollte schon immer Dichter werden, habe es aber nie geschafft, wieso? *g*

 

[rikola]

Das Leben ist so leicht, .. mit einem Bier, einer hübschen Frau und einer leckeren Manpage:

tcpdump -l > dat & tail -f dat

Und das verhindert, dass eine Datei angelegt wird? 'tschuldige, tcpdump auf openbsd kennt '-A' nicht, daher kann ich nicht nachgucken.

 

[Havoc][]

tcpdump unterstuetzt den Output in eine Pipe nicht. Daher funktioniert schon ein

tcpdump | grep '1'

nicht (habs extra ausprobiert, kein Output). *anmerk*

Hä? Wie Goodspeed bereits gesagt hat: Es funktioniert. Auch bei mir:

root@rekelen ~# rm test 
root@rekelen ~# tcpdump -A | grep 'tell' > test
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
274 packets captured
548 packets received by filter
0 packets dropped by kernel

root@rekelen ~# cat test | tail
09:01:01.549068 IP custard.intelligentstreaming.com.1192 > 10.88.1.254.43924: . 89777:91225(1448) ack 0 win 5792 <nop,nop,timestamp 2336978343 78008623>
09:01:01.573860 IP custard.intelligentstreaming.com.1192 > 10.88.1.254.43924: . 91225:92673(1448) ack 0 win 5792 <nop,nop,timestamp 2336978346 78008647>
09:01:01.573877 IP 10.88.1.254.43924 > custard.intelligentstreaming.com.1192: . ack 92673 win 1191 <nop,nop,timestamp 78008780 2336978343>
09:01:01.574104 IP custard.intelligentstreaming.com.1192 > 10.88.1.254.43924: . 92673:94121(1448) ack 0 win 5792 <nop,nop,timestamp 2336978346 78008647>
09:01:01.617958 IP 10.88.1.254.43924 > custard.intelligentstreaming.com.1192: . ack 94121 win 1191 <nop,nop,timestamp 78008824 2336978346>
09:01:01.679038 arp who-has 10.88.254.255 tell 10.88.1.206
09:01:01.706880 IP custard.intelligentstreaming.com.1192 > 10.88.1.254.43924: . 94121:95569(1448) ack 0 win 5792 <nop,nop,timestamp 2336978359 78008780>
09:01:01.707036 IP custard.intelligentstreaming.com.1192 > 10.88.1.254.43924: . 95569:97017(1448) ack 0 win 5792 <nop,nop,timestamp 2336978359 78008780>
09:01:01.718948 IP 10.88.1.254.43924 > custard.intelligentstreaming.com.1192: . ack 97017 win 1191 <nop,nop,timestamp 78008925 2336978359>
09:01:01.751003 IP custard.intelli
root@rekelen ~#

Warum es allerdings bei dir nicht tut, BiBe kann ich im Moment auch nicht sagen. Welche Distribution hast du? Goodspeed und ich haben es wahrscheinlich unter Debian getestet. Wobei es auch daran nicht liegen sollte.

 

[BiBe]

Hi,
zunächst vielen Dank für die vielen Antworten!

@theton:
Das hier funktioniert bei mir auf der Konsole aber einwandfrei. Daher gehe ich davon aus, dasa tcpdump durchaus mit grep umgehen kann.

tcpdump | grep '1'

@slasher
Toller Spruch , aber was genau macht

tcpdump -l > dat & tail -f dat

mehr, als mein Versuch? Auch damit bleibt die Datei leider leer.

@Havoc][
Seltsam... Wie brichst du denn das

tcpdump -A | grep 'tell' > test

ab? Ich mache das mit ^C, gibt es eine andere Möglichkeit? Vieleleicht ist meine Varinate zu abrupt, sodass der Buffer nicht mehr in die Datei geleert wird, oder so?
Mein Testsystem dafür ist ein Ubuntu 5.10. Aber das sollte ja eigentlich nicht vom OS abhängen...

Habt ihr noch weitere Idee?

Viele Grüße
BiBe

 

[Wolfgang]

Hallo
Schau dir doch einfach mal das bereits genannte ngrep an, das ist genau für solche Sachen vorgesehen.

Gruß Wolfgang
PS Du bist aber schon als root bzw. bei Ubuntu mit sudo unterwegs?

 

[BiBe]

Hi,
vielen Dank für die Antworten, ich mache das nun so:

ngrep -qld eth0 'imap' > test

Das klappt wunderbar.
Bezüglich tcpdump und grep habe ich auf einem Server (Debian 3.1) mit ein wenig mehr Traffic herumgespielt: Wenn ich zum Beispiel

 tcpdump -lnA | grep '1' > test

ausführe, dann füllt sich die Datei schnell. Suche ich aber nach Phrasen, die weniger oft vorkommen, dauert es eine Weile bis der erste Eintrag in die Datei kommt. Ich vermute also, dass tcpdump einen internen Buffer hat, der erst in die Datei geleert wird, wenn er voll ist. Auf meinem Ubuntu-System herrscht sehr wenig Traffic und so würde es sehr lange dauern, bis der Buffer voll ist. Nur dachte ich eigentlich, das Buffering mittels "-ln" auf ein Minimum reduziert zu haben. Hat dazu noch jemand eine Idee?

@Wolfgang: Ich mache das als root, denn als User bekomme ich unter Ubuntu den Fehler "tcpdump: socket: Operation not permitted" und das Debiansystem sagt mir "tcpdump: command not found".

Viele Grüße
BiBe

 

[slasher]

@Wolfgang: Ich mache das als root, denn als User bekomme ich unter Ubuntu den Fehler "tcpdump: socket: Operation not permitted" und das Debiansystem sagt mir "tcpdump: command not found".

1.) normal
2.) apt-get install tcpdump

.

 

[BiBe]

Hi!

@slasher: Nene, das ist schon installiert. Nur lässt es sich halt nicht als User ausführen, daher der Fehler.

Viele Grüße
BiBe

 

[slasher]

achso .

 

[theton]

Bei mir bringt unter Debian ein

tcpdump | grep '1'

lediglich die Zeilen:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

und erst, wenn ich das Programm mit SIGTERM beende, kommt wieder Output, naemlich die Zusammenfassung von tcpdump:

21 packets captured
21 packets received by filter
0 packets dropped by kernel

Die Pakete werden nicht angezeigt. Ich weiss schon, warum ich lieber zu snort greife. tcpdump macht ja scheinbar nur, was es will und wann es will.

@Havoc][: Wie ich bereits sagte, es funktioniert nicht.

 

[BiBe]

Hi,
also noch eine weitere Variante vom tcpdump-Verhalten. Ich glaub, die Verwendung von Alternativen ist durchaus ratsam - vorallem, wenn es darum geht, Zeichenketten herauszufiltern.

@theton: In welcher Umgebung tritt das denn so auf?

Viele Grüße
BiBe

 

[theton]

Debian Sarge (Default-Einstellungen fuer die Shell)
tcpdump version 3.8.3
libpcap version 0.8.3

Ich jedenfalls finde snort wesentlich brauchbarer, was aber auch damit zusammen haengen mag, dass ich es eh auch als IDS einsetze und daher recht vertraut im Umgang damit bin (ist aber auch exzellent dokumentiert *find*).

 

[Goodspeed]

[B]21[/B] packets captured
21 packets received by filter
0 packets dropped by kernel

Wenn nix über eth0 raus/rein geht bzw. nicht auf den "grep-Filter" passt, kann auch nix angezeigt werden ...
Weder die Version von Sarge nocht von Etch/Sid hat ein "Problem" mit ner Pipe.

Das die Daten erst verspätet in der Datei landen, kann allerdings wirklich am Puffer liegen ... wie man das allerdings abschaltet ... ?

 

[Havoc][]

Wenn nix über eth0 raus/rein geht bzw. nicht auf den "grep-Filter" passt, kann auch nix angezeigt werden ...
Weder die Version von Sarge nocht von Etch/Sid hat ein "Problem" mit ner Pipe.

Das die Daten erst verspätet in der Datei landen, kann allerdings wirklich am Puffer liegen ... wie man das allerdings abschaltet ... ?

Aber wenn man es ein paar Minuten laufen lässt, müsste doch irgendwann schon etwas drin stehen, oder? Er hat (in meinem Beispiel) ja auch eine Zeile (die letzte) abgeschnitten. Wahrscheinlich weil ich in dem Moment auf ^C gedrückt hab.

@theton:
SNORT ist nicht wirklich eine Alternative zu tcpdump. Du sagst es ja selbst: Snort ist ein IDS. TCPDump leistet mir beim Debuggen von Routing oder Firewall Problemen sehr gute Dienste. Ich wüsste nicht was man an TCPDump aussetzten kann/soll. Vielleicht ist es einfach weil du dich noch nicht intensiv mit tcpdump beschäftigt hast ?

btw. mit solchen sachen wie "and port 80" kann man TCPDump ne Menge mitgeben. Ich hab bis jetzt noch nie Grep verwenden müssen. Allerding weiss ich nicht genau was BiBe vor hat. Das ist jetzt nur so ne Anmerkung.

Havoc][