From owner-freebsd-questions@FreeBSD.ORG Fri Aug 29 07:03:55 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0F0816A4BF for ; Fri, 29 Aug 2003 07:03:55 -0700 (PDT) Received: from pgh.nepinc.com (pgh.nepinc.com [66.207.129.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6189743FAF for ; Fri, 29 Aug 2003 07:03:54 -0700 (PDT) (envelope-from durham@jcdurham.com) Received: from jimslaptop.pitt.nepinc.com (jimslaptop.pitt.nepinc.com [192.100.100.107]) (authenticated) by pgh.nepinc.com (8.11.4/8.11.3) with ESMTP id h7TE2x609845; Fri, 29 Aug 2003 10:02:59 -0400 (EDT) (envelope-from durham@jcdurham.com) From: Jim Durham Organization: JC Durham Consulting To: paul beard , questions Date: Fri, 29 Aug 2003 10:02:58 -0400 User-Agent: KMail/1.5.3 References: <200308282255.30730.durham@jcdurham.com> <200308290047.33808.durham@jcdurham.com> <3F4EE13A.6010807@mac.com> In-Reply-To: <3F4EE13A.6010807@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308291002.59130.durham@jcdurham.com> Subject: Re: Nachi Worm apparently causes "Live Lock" on 4.7 server X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: durham@jcdurham.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2003 14:03:56 -0000 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