- NANOG - lists.nanog.org

Re: Worldcom recovery efforts
by Lee Watterworth 20 Sep '01

20 Sep '01

We had problems with a worldcom T1 in Staten Island, which were resolved fairly quickly (no dispatch). Another ticket last week was resolved quickly (no lmi on that same circuit). I have not been able to get an AT&T dispatch (Verizon) to a location near Boston.. Lee -------------------------- Sent from my BlackBerry Wireless Handheld (www.BlackBerry.net) -----Original Message----- From: Sean Donelan <sean(a)donelan.com> To: nanog(a)merit.edu <nanog(a)merit.edu> Sent: Thu Sep 20 03:38:36 2001 Subject: Worldcom recovery efforts How are Worldcom's recovery efforts progressing? I've talked to several people with Worldcom circuits down since last week. While its understandable, I've heard about almost every other carrier restoring circuits except Worldcom. After Tuesday, everyone told me Worldcom has been doing an excellent job answering the phone. But no one seems to know if Worldcom is or isn't restoring customer (i.e non-emergency) circuits yet. One customer called AT&T and had a brand-new circuit installed this week. Their Worldcom circuit is still down. If Worldcom is still operating in emergency mode, I can understand why things are delayed. But a couple of people asked me should they continue to wait for Worldcom to fix the circuits, or did they sustain more damage than has been reported, and they should start making arrangements with other carriers.

1 0

Re: Pattern matching odd HTTP request
by Karsten W. Rohrbach 20 Sep '01

20 Sep '01

Brian Behlendorf(brian@collab.net)@2001.09.18 18:50:56 +0000: > On Wed, 19 Sep 2001, Karsten W. Rohrbach wrote: > > source ip based connection rate limiting would perhaps solve the > > problem. are there any modules available out there to accomplish this > > task? > > http://modules.apache.org/search?id=241 > > is the only one I know of. I've not used it myself, and it's not a part > of the "core" distribution. If people use it and it works, I'd appreciate > knowing, as this comes up frequently enough that I'd agitate for getting > it included. update: mod_throttle/3.1.2 seems to do the thing (as far as i can see from the source) but i cannot get the thing running on my freebsd 4.3 box here, i keeps dumping core all the time. it is designed to already check the source ip address in the fixup handler. _all_ other modules i downloaded do not do this. i tried the following ones: - mod_throttle/3.1.2 dumps core at runtime, dang thing - mod_throttle_access/0.2 starts processing after GET request - mod_bandwidth/2.0.3 starts processing after GET request - mod_bwshare/0.1.2 shmget: invalid argument but SHM is there, i can see it with ipcs(1)! - mod_conn/1999 starts processing after GET request - mod_limitipconn/0.0.3 starts processing after GET request [http://modules.apache.org/search?id=123] is the url to mod_throttle which looks very mature (but runs buggy on my box, whyever). i am pretty tired now from my long uptime hunting that stupid nimda worm and getting rid of it on some of my customers' servers. i hate iis, yuck. mod_throttle looks like it could do it, because it contains the relevant code in the fixup handler. However the policies are pretty weird -- at least for me in my current state. man, it's been a long time since i hacked my last apache module. must be 5 years or so... if somebody gets mod_throttle running on freebsd4, drop me a line how you did it. it's nearly midnight and i'm going to take a looooong nap now. btw, if your log files keep growing and growing, use multilog from daemontools to autorotate them and keep them at a specified maximum size: ErrorLog "|exec setuidgid log multilog s200000 n5 /path/to/errlogdir" daemontools are at [http://cr.yp.to/daemontools.html] you could even do ErrorLog "|exec grep -v '/scripts/' | setuidgid log multilog s200000 n5 /path/to/errlogdir" to get rid of the darn worm-generated errors. lowering the timeout does not make much sense, the best solution would be having the max connections from one ip in the scoreboard structures and connection handler because it _must_ be processed at connection time, not when the request is already in -- there never will be a GET or any other request... i see that this can be doen in the fixup_handler in an module, but i am quite rusty concerning the apache api ;-) brian, i'd appreciate if you would forward this to the core people. thanks. i got an important appointment with my bed now... take care, /k (tired like hell) -- > May the source be with you! KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- catch(a)spam.de GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x

2 1

RE: Trend Micro FIX_NIMDA.EXE - was Re: Virus fix
by Indra PRAMANA 20 Sep '01

20 Sep '01

Andras, At 07:46 PM 9/19/01 -0700, Andras Bellak wrote: >Norton released a definition file yesterday that cleaned everything but >the .eml files and made the systems resistant to re-infection. They >released an update today that got the .eml files as well. Yes, but this requires us to install the antivirus software as well. Do you know any tools like FIX_NIMDA.EXE that can fix the problem automatically without having to use the antivirus software? >I still haven't seen anything that cleans up the htm, html, asp, etc >files, but there are a few utilities that work fine for doing that one. What are the utilities? Where can I get them? Thank you for your help. Cheers.

2 1

Using NBAR to block Nimda
by Matt Martini 20 Sep '01

20 Sep '01

-----BEGIN PGP SIGNED MESSAGE----- Does anyone have a comprehensive filter to stop Nimda using Cisco's NBAR? Matt __________________________ http://www.invision.net/ _______________________ Matthew E. Martini, PE InVision.com, Inc. (631) 543-1000 x104 Chief Technology Officer matt(a)invision.net (631) 864-8896 Fax _______________________________________________________________________pgp_ -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQEVAwUBO6ke4GtXn16/JS7ZAQEUoAgAjvwY/fnoJmtmMke03I8uOIxDNUzGqX+e sP5L9Fcekg4qKF7Jix4dW+Hk+jZuwp0cSHwRsiGswqIHgHZVjRjliMD4QTjDO4FU vYUSKM4nedZhTBjIDlMp3AT9BfLjI1pV1tzYbo2L8otMGdeO3Iv/Ymd+LGZx22Fl eNvIOE+LzfipupFcA12AXstJvTH9QZ4Vuzap7ckxzA5NrTXtWphhjiLX0gKqlTsc aXp/oL/UfzMps7LiF+my2OsKCBIjyA+mLon0qdS5vs8rGtuES3wADmX/sDF8wuhr 9LFpI2VmM5JcrjwwEZIfc5Iq6M4h0so3nfwJDyBh0x5cDlDNimWH6w== =+Ucd -----END PGP SIGNATURE-----

9 8

RE: Trend Micro FIX_NIMDA.EXE - was Re: Virus fix
by Steve Smith 20 Sep '01

20 Sep '01

Don't know, luck for us our file filters are doing the job so we have not had to use it. Just thought it may help people in a bind. regards, Steve -----Original Message----- From: Indra PRAMANA [mailto:indra@webvisions.com] Sent: Wednesday, September 19, 2001 9:08 PM To: Steve Smith Cc: nanog(a)nanog.org Subject: Trend Micro FIX_NIMDA.EXE - was Re: Virus fix Steve, Yes, I think they are the first one. One slight problem, the tool will delete all non-cleanable files without logging or tracking them. Is there any safer way to clean the virus automatically? Cheers. At 04:27 PM 9/19/01 -0500, Steve Smith wrote: Looks like Trend has a cleaning tool now, www.anitivirus.com <http://www.anitivirus.com/> Steve Smith MCSE, CCNA, CCDA Data Networks Technical Manager Freeliant Inc. (901)309-3919 The brave may not live forever, but the cautious never live.

1 0

Trend Micro FIX_NIMDA.EXE - was Re: Virus fix
by Indra PRAMANA 20 Sep '01

20 Sep '01

Steve, Yes, I think they are the first one. One slight problem, the tool will delete all non-cleanable files without logging or tracking them. Is there any safer way to clean the virus automatically? Cheers. At 04:27 PM 9/19/01 -0500, Steve Smith wrote: >Looks like Trend has a cleaning tool now, www.anitivirus.com > >Steve Smith MCSE, CCNA, CCDA >Data Networks Technical Manager >Freeliant Inc. >(901)309-3919 > >The brave may not live forever, but the cautious never live.

1 0

Re: looping traceroutes
by Patrick W. Gilmore 19 Sep '01

19 Sep '01

At 09:31 PM 9/18/2001 -0700, Ratul Mahajan wrote: [SNIP] >28 193.251.133.117 (193.251.133.117) 586.776 ms 584.171 ms 586.944 ms >29 193.251.133.117 (193.251.133.117) 608.677 ms 610.789 ms 618.232 ms >30 193.251.133.117 (193.251.133.117) 641.141 ms 643.149 ms 639.050 ms This sometimes happens when there is a filter on that router. All packets going through get an ICMP administratively denied sent back, and the traceroute host interprets that as an ICMP TTL expired or perhaps does not even notice what type of ICMP it is, just looks at the source IP address. >27 208.63.128.3 (208.63.128.3) 111.475 ms 69.670 ms 69.267 ms >28 208.63.128.1 (208.63.128.1) 68.883 ms 67.147 ms 72.106 ms >29 208.63.128.3 (208.63.128.3) 69.842 ms 67.889 ms 66.944 ms >30 208.63.128.1 (208.63.128.1) 70.986 ms 73.124 ms 68.452 ms This looks exactly like a routing loop to me. Why do you think it is not a routing loop? -- TTFN, patrick

5 4

Question about Dynamic Graphs of the Nimda worm
by Jeff Ogden 19 Sep '01

19 Sep '01

The Dynamic Graphs of the Nimda worm at http://www.caida.org/dynamic/analysis/security/nimda/ are interesting. To what degree do the graphs really tell us how many hosts are infected? Or do they just tell us how many infected hosts are observed every 15 minutes? I guess what I am asking is, is the 15 minute sample period causing the graph to under report the total number of infected sites? How likely is it that the CAIDA monitor will be visited at least once every 15 minutes by an infected system? No matter what the answer to this question is, I do like the fact that the trend is down. -Jeff Ogden Merit

1 0

Virus fix
by Steve Smith 19 Sep '01

19 Sep '01

Looks like Trend has a cleaning tool now, www.anitivirus.com Steve Smith MCSE, CCNA, CCDA Data Networks Technical Manager Freeliant Inc. (901)309-3919 The brave may not live forever, but the cautious never live.

1 0

Blocking nimda probes with a content-layer switch
by Joe Abley 19 Sep '01

19 Sep '01

Has anybody tried to block nimda HTTP GET probes using URL pattern matches in a "layer-4-7"[1] switch? The ideal result is to prevent nimda GET probes from ever reaching the destination address, but causing the session to be reset towards the server after the open handshake but before the GET can be sent to the server would be acceptably useful. Particularly whether it's possible on a cisco/Arrowpoint switch, but it would be interesting to know about other vendors too. Please reply directly, will summarise if there are answers to share. Thanks! [1] substitute phrase-du-jour as appropriate

4 3