Thanks for the excellent feedback.... I learned that the -o flag is the perfect solution for me. I don't care about the hosts so much, I want to see traffic per IP, so that flag seams to be the right thing...
Thomas Pagel Senior Consultant Business Intelligence Software4You Planungssysteme GmbH Niederlassung Paderborn Hauptstra�e 35 33178 Borchen (Germany) tel.: +49 (5251) 54009-11 mob.: +49 (172) 8423035 fax.: +49 (5251) 54009-99 home: http://www.software4you.com 4PLAN� - The Art of Budgeting. Disclaimer: This email may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is prohibited. If you are not the intended recipient please contact the sender and delete all copies. -----Urspr�ngliche Nachricht----- Von: Burton M. Strauss III [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 3. April 2003 20:30 An: [EMAIL PROTECTED] Betreff: RE: [Ntop] Wrong association IP <-> MAC That's the old mark one, model one eyeball (Human eye)... OK, gang time to teach Ethernet & TCP/IP basics one more time. With pictures... Suppose you have this: (ext) 288.1.1.1 (int) 288.2.2.1 +-----+ World+Dog ------------ + ISA + ------- LAN ----- WS 288.2.2.2 | +-----+ | |(dmz) 277.1.1.1 me 299.0.0.1 \----------- DMZ ----- MAIL 277.1.1.2 \-- WEB 277.1.1.3 ISA can be acting solely as a router or it can be acting as a NAT device. That's irrelevant, so we assume it's not. I send you a packet. It travels the Internet and arrives at your 288.1.1.1 the ISA(router) with src=299.0.0.1, dst=288.2.2.2. Like every router along the way, ISA(router) looks at the destination address and realizes it has to route the packet on to 288.2.2.2. So the ISA(router) sends the packet on, out the best interface to reach 288.2.2.2. Remember, however, the TCP/IP packet is wrapped in a lower level (Ethernet) packet at the wire level. Read your TCP/IP and Ethernet standards - the actual delivery of packets over links is this Ethernet level and it uses the 48 bit MAC address. This "Ethernet" packet is actually what travels hop to hop to hop (you can even see these headers if you have visibility to the traffic - it's called the link level header by tcpdump and you'll see the 48 bit MAC addresses if you use the -e parameter). In order to be able to handle the Ethernet level signaling, each router rewrites the packet so that the 48 bit source MAC address it it's own (from-router that is) and the destination MAC address is the one that from-router has in it's tables for to-router (the next hop). So the packet looks like this, where the srcMAC and dstMAC get rewritten each hop, so that the routers on both ends of the link know whom it's addressed to: Hop1 (srcMAC=00:00:00:aa:aa:aa dstMAC=00:00:00:bbbbb:bb frame=IP data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!") Hop2 (srcMAC=00:00:00:bb:bb:bb dstMAC=00:00:00:cc:cc:cc frame=IP data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!") Hop3 (srcMAC=00:00:00:cc:cc:cc dstMAC=00:00:00:dd:dd:dd frame=IP data=(src=299.1.1.1 dst=288.2.2.2 data="Hi!") Notice how the TCP/IP stuff isn't changed. But the MAC address is. At each hop, the NIC card, operating at the Ethernet level, sees its own MAC address and knows to accept the packet. It passes it up the protocol stack, where the next layer (TCP/IP) realizes it needs to be routed further on... Ultimately, the packet gets delivered to some service listening on your WS. Here's a few packet captures to show you: # tcpdump -Xx -c1 -i eth0 -e tcpdump: listening on eth0 11:49:10.809890 0:3:47:b1:xx:xx 0:e0:18:b4:yy:yy ip 118: tigger.ssh > zebra.2714: P 1824243567:1824243631(64) ack 2328789523 win 11792 (DF) [tos 0x10] 0x0000 4510 0068 b305 4000 4006 b1e4 c0a8 2a24 [EMAIL PROTECTED]@.....*$ 0x0010 c0a8 2a21 0016 0a9a 6cbb bf6f 8ace 8213 ..*!....l..o.... 0x0020 5018 2e10 ee1a 0000 469a 3e34 eda7 549e P.......F.>4..T. 0x0030 0ec4 4847 8983 fb4f 65ea 5c3e 0bbe c325 ..HG...Oe.\>...% 0x0040 7db8 9954 dae1 55b6 54f9 cdfd ac07 a2b5 }..T..U.T....... 0x0050 ce4f So this says, the packet came from tigger (MAC address 0:3:47:b1:xx:xx) -> zebra (MAC address 0:e0:18:b4:yy:yy) Within that is the tcp/ip packet, from c0a82a24 -> c0ae2a21 (192.168.42.36 -> 192.168.42.33) Here's another one, from tigger -> router. # tcpdump -Xx -c1 -i eth0 -e host 192.168.42.1 tcpdump: listening on eth0 11:52:48.712750 0:3:47:b1:aa:aa 0:d0:9e:6:bb:bb ip 72: tigger.32782 > homeportal.gateway.2wire.net.domain: 41356+ A? cvs.ntop.org. (30) (DF) 0x0000 4500 003a bf7e 4000 4011 a5be c0a8 2a24 E..:[EMAIL PROTECTED]@.....*$ 0x0010 c0a8 2a01 800e 0035 0026 ce2e a18c 0100 ..*....5.&...... 0x0020 0001 0000 0000 0000 0363 7673 046e 746f .........cvs.nto 0x0030 7003 6f72 6700 0001 0001 p.org..... (0035 = port 53, so it's a dns query) And one more, from cvs.ntop.org -> tigger (which has to have passed through the router) # tcpdump -Xx -c1 -i eth0 -e "not src net 192.168.42.0/24" tcpdump: listening on eth0 11:53:39.688806 0:d0:9e:6:bb:bb 0:3:47:b1:aa:aa ip 69: 195.31.151.66.cvspserver > tigger.42964: P 2566885448:2566885451(3) ack 2903504154 win 24616 <nop,nop,timestamp 389837493 85533859> (DF) 0x0000 4500 0037 5f3c 4000 2906 ad56 c31f 9742 E..7_<@.)..V...B 0x0010 c0a8 2a24 0961 a7d4 98ff 9048 ad0f f51a ..*$.a.....H.... 0x0020 8018 6028 279a 0000 0101 080a 173c 72b5 ..`('........<r. 0x0030 0519 24a3 6f6b 0a ..$.ok. See the MAC address? It's the routers, not cvs.ntop.org's And that's probably the problem you're having with ntop. See ntop is nosy, so it puts the interface into promiscuous mode, where every packet - addressed to the ntop host or not - is processed. Now the next layer up, the tcp/ip layer will throw away any 'junk' (You can just hear it going tisk, tisk, tisk). But libpcap can intercept them at the Ethernet level and feed them to ntop... For REMOTE hosts, ntop uses the IP address as it's the only valid data. But for LOCAL hosts, ntop prefers to use the MAC address as a way of resolving multi-homed or multiply addressed hosts. See if you have two IP addresses assigned to the same host on your local network, say 192.168.42.42 and 192.168.42.43, how is ntop to tell they're the same host? Well, the MAC addresses are the same... (for some manufacturers, e.g. Sun, ALL of the interfaces on a host use the same MAC address). read getHostInfo() in hash.c. /* This is a local address hence this is a potential multihomed host. */ if((el->hostIpAddress.s_addr != 0x0) && (el->hostIpAddress.s_addr != hostIpAddress->s_addr)) { isMultihomed = 1; FD_SET(FLAG_HOST_TYPE_MULTIHOMED, &el->flags); } i.e. if the address we've stored for this host doesn't match this one, it's multihomed. } else if((hostIpAddress != NULL) && (el->hostIpAddress.s_addr == hostIpAddress->s_addr)) { /* Spoofing or duplicated MAC address: two hosts with the same IP address and different MAC addresses */ if(!hasDuplicatedMac(el)) { FD_SET(FLAG_HOST_DUPLICATED_MAC, &el->flags); ... } setSpoofingFlag = 1; hostFound = 1; break; } If the addresses DO match, we've had two MAC addresses, so this is being spoofed. etc. So why are you getting bad output? If, somehow, you've confused ntop - for example telling it that 277.1.1.0/24 is local in the ascii art example, then it's going to believe you. And it will see a packet with the 277.1.1.1 IP and a MAC address. And use that. Only it's not the MAC address of the MAIL host, it's ISA's... No matter, ntop doesn't know this -- all it sees is the packets and the data you gave it. So later on, when it sees a packet with the same MAC address, but a different IP, well, it will assume that it's the same host... and they'll all be lumped together. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas Pagel Sent: Thursday, April 03, 2003 10:22 AM To: [EMAIL PROTECTED] Subject: AW: [Ntop] Wrong association IP <-> MAC I fetched up some traffic with windump. Sorry for asking, but what did you mean with "and run the Mark One eye over them"? I guess that should be some tool showing the packets, but I don't know it... I loaded the dump in ntop, restartet ntop some times, I get various IPs for the same MAC each time I start ntop. Perhaps there's something with our firewall which "confuses" ntop... The mac address belongs to our Microsoft ISA server. It is multihomed since it "publishes" some services. It's also the router for the DMZ. The IP adresses ntop associates with the MAC are from "published" services (smtp, http, ...) and DMZ hosts. Thanks, Thomas Pagel Senior Consultant Business Intelligence Software4You Planungssysteme GmbH Niederlassung Paderborn Hauptstra�e 35 33178 Borchen (Germany) tel.: +49 (5251) 54009-11 mob.: +49 (172) 8423035 fax.: +49 (5251) 54009-99 home: http://www.software4you.com 4PLAN� - The Art of Budgeting. Disclaimer: This email may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is prohibited. If you are not the intended recipient please contact the sender and delete all copies. -----Urspr�ngliche Nachricht----- Von: Burton M. Strauss III [mailto:[EMAIL PROTECTED] Gesendet: Montag, 31. M�rz 2003 19:45 An: [EMAIL PROTECTED] Betreff: RE: [Ntop] Wrong association IP <-> MAC Remember - it only takes one packet, not even an ack, for ntop to create a host record. If that's wrong, it will carry forward - you'll probably see the host tagged as 'Multihomed'. Host 1: IP 192.168.1.1 MAC 00:00:00:aa:aa:aa Host 3: IP 192.168.1.3 MAC 00:00:00:cc:cc:cc If somebody has the incorrect hosts table, dns, cached, whatever info that Host 1 is 192.168.1.3 and is on the same subnet, then it will send a packet where the Ethernet layer and the ip are nonsense. But because it's on the same wire, the ip is ignored: (Ethernet from:00:00:00:dd:dd:dd to:00:00:00:aa:aa:aa)(tcp s=192.168.1.4 d=192.168.1.3) ntop will read both out of the packet and create the association 192.168.1.3=00:00:00:aa:aa:aa Since it doesn't know better. Then when it sees (Ethernet from:00:00:00:ee:ee:ee to:00:00:00:cc:cc:cc)(tcp s=192.168.1.5 d=192.168.1.3) It will create the multihomed association... Best bet would be to capture some packets using a sniffer like tcpdump (which is available for windows, see http://windump.polito.it/) and run the Mark One eye over them. You can even feed the capture into ntop via the -r parameter. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Burton M. Strauss III Sent: Monday, March 31, 2003 9:00 AM To: [EMAIL PROTECTED] Subject: RE: [Ntop] Wrong association IP <-> MAC I would suspect a dns problem... Look at the data in info.html on dns - see where it's getting the resolution (sniffing vs. queries) and try to do your own nslookups... Also check your switches - some of them rewrite the monitor port data with their own MAC address, which confuses ntop - You could turn on --no-mac -- (make it IP only), but that won't fix a dns problem. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas Pagel Sent: Monday, March 31, 2003 8:45 AM To: [EMAIL PROTECTED] Subject: AW: [Ntop] Wrong association IP <-> MAC Sorry, my fault.... That's why I have an odd MAC for the Cisco... But all the other issues are not affected by this... In my example Host1 and Host3 are still mixed up... Thomas Pagel Senior Consultant Business Intelligence Software4You Planungssysteme GmbH Niederlassung Paderborn Hauptstra�e 35 33178 Borchen (Germany) tel.: +49 (5251) 54009-11 mob.: +49 (172) 8423035 fax.: +49 (5251) 54009-99 home: http://www.software4you.com 4PLAN� - The Art of Budgeting. Disclaimer: This email may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is prohibited. If you are not the intended recipient please contact the sender and delete all copies. -----Urspr�ngliche Nachricht----- Von: Burton M. Strauss III [mailto:[EMAIL PROTECTED] Gesendet: Montag, 31. M�rz 2003 15:58 An: [EMAIL PROTECTED] Betreff: RE: [Ntop] Wrong association IP <-> MAC That's right, isn't it? The 01: is the multicast bit and 01:00:0c:cc:cc:cc is listed in most lists as Cisco CDPD/VTP... It's one of those odd, pre-IANA pre-IEEE assignments, where companies picked what they wanted and there weren't enough in the market to cause problems, but not all of them were codified later on. Make building the specialMac.txt file a brass plated b*tch. STFW... http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_7_1/conf_gd/e _trunk.htm and lots of others -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Thomas Pagel Sent: Monday, March 31, 2003 5:04 AM To: [EMAIL PROTECTED] Subject: AW: [Ntop] Wrong association IP <-> MAC correction: Host2 is only listed as "Cisco CDPD/VTP" without any IP Thomas Pagel Senior Consultant Business Intelligence Software4You Planungssysteme GmbH Niederlassung Paderborn Hauptstra�e 35 33178 Borchen (Germany) tel.: +49 (5251) 54009-11 mob.: +49 (172) 8423035 fax.: +49 (5251) 54009-99 home: http://www.software4you.com 4PLAN� - The Art of Budgeting. Disclaimer: This email may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is prohibited. If you are not the intended recipient please contact the sender and delete all copies. -----Urspr�ngliche Nachricht----- Von: Thomas Pagel Gesendet: Montag, 31. M�rz 2003 12:54 An: [EMAIL PROTECTED] Betreff: [Ntop] Wrong association IP <-> MAC Hi, I'm running ntop Version 2.1.90 on Windows 2000. Looking at statistics/hosts I find some hosts which are listed incorrectly (or at least I don't understand that....) Host1: Microsoft ISA Server Host2: Our Cisco Internet router Host3: Windows 2000 Server The IP of Host3 has the MAC Address of Host1 and all the Service-Icons of Host1 The IP of Host3 is there a second time with the MAC Address of Host2 and the Router Service-Icon The IP of Host2 has the MAC Address of 01:00:0C:CC:CC:CC, no idea where this is comming from The IP of Host1 isn't listed at all I really don't understand that... Thanks, Thomas Pagel Senior Consultant Business Intelligence Software4You Planungssysteme GmbH Niederlassung Paderborn Hauptstra�e 35 33178 Borchen (Germany) tel.: +49 (5251) 54009-11 mob.: +49 (172) 8423035 fax.: +49 (5251) 54009-99 home: http://www.software4you.com 4PLAN� - The Art of Budgeting. Disclaimer: This email may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is prohibited. If you are not the intended recipient please contact the sender and delete all copies. _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
