cgmckeever
January 5th, 2004, 16:56
I am trying to analyze some data passing through the network to port 25 (in particaulr a specific IP). When I run tcpdump, it seems that I only get the information that is originating or terminating to the network card that tcpdump is listening on, rather than grabbing all network traffic.

The listening box is in the same switch as the server running the SMTP daemon, so I dont know why I am not getting anything (other than I am not familiar with all the tcpdump switches)

Thanks for any suggestions.


-- I should also note that the same behavious happens with NGREP

thanks

bsdjunkie
January 5th, 2004, 17:06
The listening box is in the same switch as the server running the SMTP daemon

This is your problem. You can not just sniff on switched traffic and see all of it by default, like you could with a HUB. If its a decent switch (liike a cisco), you can setup a span port on it to monitor all traffic going over it, else there are tools that will allow you to spoof the mac address of the switch, capture the traffic, and forward it back out of your pc.

Dug Song's dsniff suite is a great example.

|MiNi0n|
January 5th, 2004, 17:06
If it's a switch you're not going to see much... such is the nature of a switch environment... it's meant to be more "private" :wink:

If you really want to see more, move the host in question onto a hub plugged into the switch. Then use a dump host on the same hub segment, or use the host in question. You'll see a lot more data :)

|MiNi0n|
January 5th, 2004, 17:10
Dug Song's dsniff suite is a great example.

dsniff is great, as is something like ettercap. However, if this is a business type enviro (critical network) I'd suggest the hub option. One simple mistake and you can hose the network with a botched arp spoof :shock:

cgmckeever
January 5th, 2004, 17:18
Thanks for the replies - that is what I thought (regarding the switch)..but couldnt find much confirmation on some of the howto sites.

I had downloaded the arpspoof, but am getting some serious compilations issues (see below if interested). I have posted to that mailing list regarding it as well.




--------compilation issues:

make
gcc -g -O2 -D_BSD_SOURCE -DDSNIFF_LIBDIR=\"/usr/local/lib/\" -I. -I/usr/local/include -I/usr/local/include -I/usr/local/include -I./missing -c ./arpspoof.c
./arpspoof.c:25: warning: `struct ether_addr' declared inside parameter list
./arpspoof.c:25: warning: its scope is only this definition or declaration, which is probably not what you want.
./arpspoof.c:26: warning: `struct ether_addr' declared inside parameter list
./arpspoof.c: In function `arp_send':
./arpspoof.c:60: `ETHERTYPE_ARP' undeclared (first use in this function)
./arpspoof.c:60: (Each undeclared identifier is reported only once
./arpspoof.c:60: for each function it appears in.)
./arpspoof.c:62: `ARPHRD_ETHER' undeclared (first use in this function)
./arpspoof.c:62: `ETHERTYPE_IP' undeclared (first use in this function)
./arpspoof.c:62: `ETHER_ADDR_LEN' undeclared (first use in this function)
./arpspoof.c:64: `ETH_H' undeclared (first use in this function)
./arpspoof.c:67: warning: passing arg 1 of `ether_ntoa' from incompatible pointer type
./arpspoof.c:69: `ARPOP_REQUEST' undeclared (first use in this function)
./arpspoof.c:71: warning: passing arg 1 of `ether_ntoa' from incompatible pointer type
./arpspoof.c:77: warning: passing arg 1 of `ether_ntoa' from incompatible pointer type
./arpspoof.c:80: warning: passing arg 1 of `ether_ntoa' from incompatible pointer type
./arpspoof.c: In function `arp_force':
./arpspoof.c:89: storage size of `sin' isn't known
./arpspoof.c:92: `AF_INET' undeclared (first use in this function)
./arpspoof.c:92: `SOCK_DGRAM' undeclared (first use in this function)
./arpspoof.c:92: `IPPROTO_UDP' undeclared (first use in this function)
./arpspoof.c: In function `arp_find':
./arpspoof.c:114: warning: passing arg 2 of `arp_cache_lookup' from incompatible pointer type
./arpspoof.c: In function `cleanup':
./arpspoof.c:137: `ARPOP_REPLY' undeclared (first use in this function)
./arpspoof.c: In function `main':
./arpspoof.c:159: `optarg' undeclared (first use in this function)
./arpspoof.c:169: `optind' undeclared (first use in this function)
./arpspoof.c:181: warning: assignment makes pointer from integer without a cast
./arpspoof.c:193: `ARPOP_REPLY' undeclared (first use in this function)
./arpspoof.c: At top level:
./arpspoof.c:29: storage size of `spoof_mac' isn't known
./arpspoof.c:29: storage size of `target_mac' isn't known
make: *** [arpspoof.o] Error 1

cgmckeever
January 5th, 2004, 17:20
with a botched arpspoof - does that stop after arpspoof is killed? or can a bad arpspoof linger until switches are reset?

I was wondering about that myself after reading:

http://www.linuxsecurity.com/feature_stories/feature_story-89.html

bsdjunkie
January 5th, 2004, 17:29
can a bad arpspoof linger until switches are reset?


I think this could be dependant on you switches. A cheap switch may very well be hosed until a reset is performed. As minion mentioned above, be careful on a production network, especially if this is the first time youve attempted something like this. Tools like dnsiff/arpspoof can take out a network fairly easily :wink:

cgmckeever
January 5th, 2004, 17:47
I think going with the hub works for the time being....

thanks