Re: arp table overflow due to windows worm (resolved)
Thank you guys so much. It's resolved. The problem was indeed that my default route was via the external IP of my firewall so that it tried to resolve all 134.102.0.0/16 IPs to mac addresses. Raising the arp cache to 2^16 worked as a hot fix. In my defense: When I started working here I did inquire about the gateway to use and I was told I don't need one. I thought that odd back then but didn't realize the implications of this. And it did work for quite a while. Until now that is. Now I've got a proper gateway entry that's outside of my net in a neighbouring /24 subnet and I reduced the arp cache size to 1024 again. And even though I can see 5 infected machine blasting through the network right now everything works fine. Cheers, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: arp table overflow due to windows worm
Kurt Roeckx wrote: On Sat, Oct 16, 2004 at 01:39:29PM +0200, Benjamin Goedeke wrote: My net has netmask /24 and the firewall is connected to an upstream router which sits in 134.102.0.0/16. The other gateway sits between my site and two /24 nets but this gateway doesn't seem to be affected. So the gateway with the problem is the only one with a connection to the outside world and they other is just to 2 other internal nets? That's right. The net looks something like this: (excuse my pittyful ascii art skills) Internet Internet | | | the overflowing firewall | | | (bridge) | | | | other lansfirewallmy lan I could use the other lans as a gateway but I usually don't. The only reason it should do ARP is in case it wants to resolv an address which he thinks is directly connected. Which should mean all your internal IP addresses (or atleast those he tried to send something to) your gateway. Hmm. That gives me an idea: Destination Gateway Flags Metric Ref Use Iface 134.102.0.0/16 0.0.0.0 UG 0 0 0 eth1 With such a routing entry the firewall will try and resolve mac addresses when the worm is scanning 134.102.xxx.0 subnets, right? I off to the site to do some experimenting. Thanks, a lot so far. I'll post my findings. ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
arp table overflow due to windows worm
Hi list This might be a bit offtopic since there's nothing debian specific about the problem I'm having. If you feel this has no place on this list please point me to a more appropriate list for this question. Starting last week I noticed random network outages on the lan I'm administering. There are 5 debian servers for some 100 windows workstations. The network topology is pretty straight-forward with two gateways to the internet and an affiliated site respectively. Now what happens is this: There's a worm or virus on some of the windows machines that uses tcp port 135 to distribute itself. Infected machines systematically scan neighbouring networks at a rate of a few hundred connection attempts/s for machines listening on port 135. Oddly enough the local scanners (Norton Antivirus) don't find anything. But this mail is not about what to do with the windows machines but rather what to do on the firewall. Obviously port 135 is closed in both directions. However, I get the message Neighbour table overflow on the firewall (debian stable w/ kernel 2.4.27) and the entire network comes to a standstill. The cpu load isn't even close to a worrying level so I guess there are plenty of resources left and still I can't make any network connection through the firewall when there's an infected machine plugged in to the network. The arp cache overflow happens even though I just drop packets in the iptables FORWARD chain. So I set up a transparent bridge between the firewall and the lan and tried filtering ethernet frames using ebtables from the infected machines. This did work and the arp cache overflow on the firewall no longer happened but still the network was pretty much useless and connections to any server outside of the lan are extremely slow and unreliable. Should it really be possible for a single infected windows machine to dos a linux firewall? Please tell me it's not true and there's just something I'm overlooking. I'm at my wits end here and don't even know what to try next. So any pointers are much appreciated. Thanks, Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
