Re: Scan packets attempting to be sent via default gateway
Ron Gula <[email protected]>
| Newsgroups | gmane.comp.security.nessus.general |
|---|---|
| Message-ID | <[email protected]> |
hi Don, What sort of router/gateway is at 10.0.0.1? Since it replied and said that it owned that particular IP address and other IP addresses, I would start there. You could probably verify this was not Nessus by trying to ping one of the dead IPs from the system running Nessus and doing a similar trace. Ron Gula Tenable Network Security Don Drohman wrote: > I have come across something odd that I can not confirm to be a Nessus > issue (it may be an OS issue), but certainly not how I would expect > Nessus to operate. > > My environment: > > Nessus Scan Server > ---------- > OS: WinXP SP2 > Nessus ver: 3.2.0.343 (nessusd.exe) > IP: 10.0.0.211 /24 (static) > MAC: CompaqCo_2c:6f:c2 > > Nessus Client > --------- > Running on server machine accessing localhost > Nessus ver: 3.2.0 (build 2G281_Q) > > > Default Gateway (router/firewall) > --------------------------------------- > IP: 10.0.0.1 /24 (static) > MAC: Lite-OnC_5d:d1:e5 > > > The client/server machine is a brand new (fresh) install of WinXP Pro > with SP2 slipstreamed into the install media. This machine has a minimal > install of other software (All Microsoft patches up to the release of > SP3, Wireshark 1.0, WinPcap v4.0.2, and OS installed detected drivers) > > > Scanning for 2 hosts. > 10.0.0.2, 10.0.0.6 > > Scan definition used is the provided Microsoft patches scan. > > Neither of these hosts exists as physical machines on the network, nor > (as far as I know) are there any devices out there that would respond to > these IP's. My expectation was that host discovery would fail and the > scan would stop. > > For 10.0.0.2, that is what happens. In a packet trace, I see Nessus > server send out ARP's looking for 10.0.0.2 about 5 or 6 times, and then > with no reply, quits. (no packet trace here, but I can provide if > needed. It's not very interesting) > > For 10.0.0.6, the situation is totally different, and here are a series > of packets I see: > > pkt time Source Destination type/payload > # > ------------------------------------------------------------------------ > ---- > 1 148.201302 CompaqCo_2c:6f:c2 Broadcast ARP Who > has 10.0.0.6? Tell 10.0.0.211 > > 2 148.704152 CompaqCo_2c:6f:c2 Broadcast ARP Who > has 10.0.0.1? Tell 10.0.0.211 > > > 3 148.704406 Lite-OnC_5d:d1:e5 CompaqCo_2c:6f:c2 ARP > 10.0.0.1 is at 00:a0:cc:5d:d1:e5 > > > 4 149.270140 CompaqCo_2c:6f:c2 Broadcast ARP Who > has 10.0.0.6? Tell 10.0.0.211 > > > 5 150.569573 CompaqCo_2c:6f:c2 Broadcast ARP Who > has 10.0.0.6? Tell 10.0.0.211 > > 6 152.600483 10.0.0.211 10.0.0.6 TCP > syscomlan > netbios-ssn [SYN] Seq=0 Win=2048 Len=0 > > > and then what follows (but I have cut from here) is the trace of the > entire set of defined scans selected being sent and reject packets > coming back from the firewall on the default gateway, as if 10.0.0.6 was > detected as UP. > > > Here is a full decode of packet #6. Look at the Ethernet II layer, > destination MAC info. The destination MAC has been taken from the reply > of the ARP to the default gateway (packet 2). Nessus never got a > response from anyone claiming to be 10.0.0.6, but for some reason, it > *appears* like it thinks the address is on a different subnet, and tries > to use the default gateway to get to it (packet 6). > > If this was any other app, I'd suspect the OS (or network > drivers/protocol stack), but since the primary purpose of this app is to > create and send specifically crafted packets, I have to somehow suspect > Nessus could be involved too. > > Frame 6 (54 bytes on wire, 54 bytes captured) > Arrival Time: May 10, 2008 21:22:33.034398000 > Frame Number: 6 > Frame Length: 54 bytes > Capture Length: 54 bytes > [Frame is marked: True] > [Protocols in frame: eth:ip:tcp] > [Coloring Rule Name: TCP SYN/FIN] > [Coloring Rule String: tcp.flags & 0x02 || tcp.flags.fin == 1] > Ethernet II, Src: CompaqCo_2c:6f:c2 (00:08:02:2c:6f:c2), Dst: > Lite-OnC_5d:d1:e5 (00:a0:cc:5d:d1:e5) > Destination: Lite-OnC_5d:d1:e5 (00:a0:cc:5d:d1:e5) > Address: Lite-OnC_5d:d1:e5 (00:a0:cc:5d:d1:e5) > .... ...0 .... .... .... .... = IG bit: Individual address > (unicast) > .... ..0. .... .... .... .... = LG bit: Globally unique address > (factory default) > Source: CompaqCo_2c:6f:c2 (00:08:02:2c:6f:c2) > Address: CompaqCo_2c:6f:c2 (00:08:02:2c:6f:c2) > .... ...0 .... .... .... .... = IG bit: Individual address > (unicast) > .... ..0. .... .... .... .... = LG bit: Globally unique address > (factory default) > Type: IP (0x0800) > Internet Protocol, Src: 10.0.0.211 (10.0.0.211), Dst: 10.0.0.6 > (10.0.0.6) > Version: 4 > Header length: 20 bytes > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) > 0000 00.. = Differentiated Services Codepoint: Default (0x00) > .... ..0. = ECN-Capable Transport (ECT): 0 > .... ...0 = ECN-CE: 0 > Total Length: 40 > Identification: 0x0d44 (3396) > Flags: 0x00 > 0... = Reserved bit: Not set > .0.. = Don't fragment: Not set > ..0. = More fragments: Not set > Fragment offset: 0 > Time to live: 64 > Protocol: TCP (0x06) > Header checksum: 0x58b4 [correct] > [Good: True] > [Bad : False] > Source: 10.0.0.211 (10.0.0.211) > Destination: 10.0.0.6 (10.0.0.6) > Transmission Control Protocol, Src Port: syscomlan (1065), Dst Port: > netbios-ssn (139), Seq: 0, Len: 0 > Source port: syscomlan (1065) > Destination port: netbios-ssn (139) > Sequence number: 0 (relative sequence number) > Header length: 20 bytes > Flags: 0x02 (SYN) > 0... .... = Congestion Window Reduced (CWR): Not set > .0.. .... = ECN-Echo: Not set > ..0. .... = Urgent: Not set > ...0 .... = Acknowledgment: Not set > .... 0... = Push: Not set > .... .0.. = Reset: Not set > .... ..1. = Syn: Set > .... ...0 = Fin: Not set > Window size: 2048 > Checksum: 0x720d [correct] > [Good Checksum: True] > [Bad Checksum: False] > > -- end of packet trace ----------------------------------------------- > > > Why this doesn't occur for 10.0.0.2 (or 10.0.0.3)? I can not say, but it > does occur for a whole lot of other hosts when I scan the 10.0.0.0/24 > subnet. The result of the scan is simply a whole lot of hosts shown as > UP (but nothing else), and a whole lot of traffic rejected and logged on > my router/firewall, and a long time for the scan to complete (many many > hours). > > Oh, here's the routing table on the scanning server, because I'm sure > someone will ask. > > C:\>route print > ======================================================================== > === > Interface List > 0x1 ........................... MS TCP Loopback interface > 0x10003 ...00 08 02 2c 6f c2 ...... Realtek RTL8139 Family PCI Fast > Ethernet NIC - Packet Scheduler Miniport > ======================================================================== > === > ======================================================================== > === > Active Routes: > Network Destination Netmask Gateway Interface > Metric > 0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.211 > 1 > 10.0.0.0 255.255.255.0 10.0.0.211 10.0.0.211 > 20 > 10.0.0.211 255.255.255.255 127.0.0.1 127.0.0.1 > 20 > 10.255.255.255 255.255.255.255 10.0.0.211 10.0.0.211 > 20 > 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 > 1 > 224.0.0.0 240.0.0.0 10.0.0.211 10.0.0.211 > 20 > 255.255.255.255 255.255.255.255 10.0.0.211 10.0.0.211 > 1 > Default Gateway: 10.0.0.1 > ======================================================================== > === > Persistent Routes: > None > > > Don > > _______________________________________________ > Nessus mailing list > [email protected] > http://mail.nessus.org/mailman/listinfo/nessus > _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus