Invalid IP address in my Logs?

Im using a netgear wireless router DG832GT and have Netgear access points WG602v3. My LAN IP addresses are on the 192.168.254.1 - 255 range. I have 30 student laptop users on the wireless network using WEP to access. One of the port ranges I'm blocking is ports 6346 - 6348 in the firewall rules. One of my access points keep crashing and the logs from DG832GT are indicating a lot of trafic being blocked with a address of 1.0.0.0

Here is a sample from the logs:

Fri, 2005-11-18 03:46:23 - UDP Packet - Source:206.21.162.227,23063 Destination:1.0.0.0,6346 - [gnutella match] Fri, 2005-11-18 03:52:24 - UDP Packet - Source:66.41.141.42,15598, Destination:1.0.0.0,6346 - [gnutella match] Fri, 2005-11-18 03:52:49 - UDP Packet - Source:24.198.87.241,6349 Destination:1.0.0.0,6346 - [gnutella match] Fri, 2005-11-18

This 1.0.0.0.address is not a valid address on my network so where is it coming from? Or how do I trace it and block it? Is this some file sharing user spoofing his address in my logs?

TIA Kieran

Reply to
kierankelly
Loading thread data ...

A sniffer to get the MAC (hardware) address would help.

OAR Net - Columbus Ohio, though their rwhois server seems to be off line. The hostname returns Xavier University in Cincinnati

Comcast - not sure where - possibly Minnesota

Road Runner - someplace in Maine

Not only that, it's not a valid address anywhere, so it CAN'T be routed from the USA to you across the pond - every router en-route would drop it with an ICMP Type 3 Code 0 (you can't get there from here). So, it's got to be on your side of the last intelligently configured router, maybe your link to the ISP.

A packet sniffer - ethereal comes to mind. You're already blocking it.

Wouldn't be the first time.

Old guy

Reply to
Moe Trin

Thanks Old Guy Im not interested in the source as there are so many of them they are probably other peer to peer clients sharing music. Its the destination I need to figure out. I have used packet sniffers but nothing shows up but I'll try Ethereal and see what that throws up.

Thanks Kieran

Reply to
kierankelly

The point I was making was that the packets can not have come from any place _beyond_ your ISP, and depending on your firewall configuration, they could be from your own network. In fact, your ISP has no reason to be sending packets to/from 206.21.162.227 and 1.0.0.0 to you, because you are not the road to either of those addresses. This makes it HIGHLY likely that they originated locally. The only way you'll find this is to use a sniffer of some kind. Your original post said that the logs came from your wireless router. Does that device provide you with an ARP cache you can view (a list of the MAC addresses it's talking to)? It won't help at this exact moment, as the cache expires over a short period of time (RFC1122 section 2.3.2.1 recommends a minute of no activity, but many routers set it to as much as four hours).

Likewise, your log snippet didn't mention which interface the packets were seen on, and that might help narrow down the source.

A point to remember is that the MAC address can be spoofed fairly easy. However, under NORMAL conditions, this is done in the network stack, so ALL packets from "this" interface will have the same MAC address for all IP addresses until the skript kiddie runs his MAC changer program and sets it to something else. A standard trick to catch spoofing by known hosts is to randomly try to talk to the known MAC address. If there is a delay (seconds), or no response from a specific IP address, you've probably got your abuser. That would depend on you knowing what the "normal" MAC address is for each system on your LAN, but this shouldn't be to hard to get. Also, if you see a "non-local" source IP address coming from your hosts, quickly check all known IPs - who is using the same MAC address as the non-local source?

Where I work, we have strong written policies (and warning signs all over) but we also monitor the MAC and IP addresses and the pairing of the two on a continuous basis (we're an R&D facility with company sensitive information floating on the networks). Oh, and we're also a UNIX shop, to 'arpwatch' or 'snmpwatch' probably aren't available for windoze - but you can use something to grab that ARP cache off the router and then process it through 'perl' or similar to catch the interesting bits. We were using telnet to grab the ARP cache and fed that into a perl script before we got arpwatch. The perl mashing was written by a student intern who was taking a class in perl that quarter, so it's not like it's rocket science.

Old guy

Reply to
Moe Trin

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.