Nachi Worm apparently causes "Live Lock" on 4.7 server

[Jim Durham]

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