Date: Fri, 29 Aug 2003 10:02:58 -0400 From: Jim Durham <durham@jcdurham.com> To: paul beard <paulbeard@mac.com>, questions <questions@freebsd.org> Subject: Re: Nachi Worm apparently causes "Live Lock" on 4.7 server Message-ID: <200308291002.59130.durham@jcdurham.com> In-Reply-To: <3F4EE13A.6010807@mac.com> References: <200308282255.30730.durham@jcdurham.com> <200308290047.33808.durham@jcdurham.com> <3F4EE13A.6010807@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 29 August 2003 01:14 am, paul beard wrote: > James C. Durham wrote: > > On Friday 29 August 2003 04:23 am, paul wrote: > >>James C. Durham wrote: > >>>It turned out that we had several Windows boxes in the building > >>> that had been infected with the Nachi worm. This causes some > >>> kind of DOS or ping probe out onto the internet and the local > >>> LAN. > >>> > >>>Removing the inside interface's ethernet cable caused the ping > >>> times on the outside interface to go back to the normal .4 > >>> milliseconds to the router. > >>> > >>>Apparently, the blast of packets coming from the infected boxes > >>> managed to cause a "live lock" condition in the server. I > >>> assume it was interrupt bound servicing the inside interface. > >>> The packets were ICMP requests to various addresses. > >> > >>I could be way off here, but is there any way to isolate machines > >>that send a sudden blast of packets, either by destination > >> address (make a firewall rule that drops those packets) or > >> working out their MAC addresses and dropping their connectivity? > >> Or scan for open ports and block unsecured systems from > >> connecting? > > > > What I did was go in the switch room and look for pulsing lights > > on the switch ports and pull the cables. That fixed it, but after > > much agony. > > well, that's a bit draconian, but effective ;-) > > >>>My questions is.. what, if any, is a technique for preventing > >>> this condition? I know, fix the windows boxes, but I can't > >>> continually check the status of the virus software and patch > >>> level of the Windows boxes. There are 250 plus of them and one > >>> of me. Users won't install upgrades even when warned this worm > >>> thing was coming. But, i'd like to prevent loss of service when > >>> one of Bill's boxes goes nuts! > >> > >>Where I work, at the University of Washington, the network staff > >>were dropping as many as 200 machines *per day* off the network. > >>If a machine was found to have an open RPC port (we run an open > >>network), that was enough to get your network access cut off. > >> > >>I realize these are political solutions more than technical ones, > >>but they may be of some use. > > > > The trouble with that is that my users are largely untechnical > > and wouldn't have a clue what RPC is and cutting them off is not > > an option. Welcome to the world of corporate IT! It ain't a > > pretty job, but it pays the bills... > > been there, done that, the bruises have gone down now . . . > > One guy to 250 users is a bad ratio. > > It seems like there should be some centralized, ie, rule-based > controls you can put in place. And you should have some leverage > to force autoupdates on those client machines. > > > I got the impression from some reading on Google Groups that > > there may be a way to tell the xl driver to use polling. I just > > don't know how. > > Well, this is the right place to ask. The other thing is interrupt priority, maybe ? -Jim -- -Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308291002.59130.durham>