- Test - lists.nanog.org

Here we go again
by Henry R. Linneweh 10 Mar '00

10 Mar '00

If this is the case then lets kick butt now before they have a chance to start Hactivists plan DDoS Web attack Electrohippies software could be as effective as distributed denial of service tools used in last months Web attacks. http://www.msnbc.com/news/380065.asp?cp1=1 -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

3 2

Network Probes
by Scott McGrath 10 Mar '00

10 Mar '00

Hi, Has anyone else noticed probes against their network with a spoofed source address and Src (80) and Dst(2183) ---Snip. Mar 8 17:40:16: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 1 packet .Mar 8 17:44:28: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 1 packet .Mar 8 17:45:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 216.52.56.50(80) (Ser ial0 *PPP*) -> 216.64.1.198(2183), 3 packets .Mar 8 17:49:45: %SEC-6-IPACCESSLOGP: list 110 denied tcp 208.194.150.10(80) (S erial0 *PPP*) -> 216.64.1.142(2183), 2 packets .Mar 9 07:39:04: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 1 packet .Mar 9 07:44:18: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.143.228.10(80) (S erial0 *PPP*) -> 216.64.1.82(2183), 9 packets .Mar 9 09:53:46: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 1 packet .Mar 9 09:59:24: %SEC-6-IPACCESSLOGP: list 110 denied tcp 209.185.181.10(80) (S erial0 *PPP*) -> 216.64.1.227(2183), 9 packets .Mar 9 12:11:55: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 1 packet .Mar 9 12:17:29: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 8 packets .Mar 9 12:22:30: %SEC-6-IPACCESSLOGP: list 110 denied tcp 10.2.1.6(80) (Serial0 *PPP*) -> 216.64.1.144(1319), 4 packets ---snip Thanks

4 5

Re: Hi, we're from the government and we're here to help
by Hal Murray 10 Mar '00

10 Mar '00

> >In the chemical industry, where failure to respond to a leak can result in > >millions in liability, the chemical manufactures' association maintains a > >24-hour number which will contact the appropriate company's response group. > >Again, the contact information is actively verified. > Sounds like Sean and Ren should go get some funding for this, heck I'd > pay for it. (It would still probably be cheaper than something like IPOPS > or CERT, which is not to completely dismiss those two organizations.) This is something the alternate domain registration vendors could do. I'm thinking of: 1) verify that the contact information they collect is accurate, and 2) publish emergency contact info and/or an indication of when it is operational or what is considered an emergency.

3 2

Re: Network Probes
by Michael Shields 10 Mar '00

10 Mar '00

In article <38C80DF3.6194803E(a)bexair.com>, "Scott McGrath" <s_mcgrath(a)bexair.com> wrote: > Has anyone else noticed probes against their network with a spoofed Sure, all the time. http://www.nfr.net/forum/publications/id-myths.html -- Shields.

2 1

Trojan Alert was: Check this
by Kai Schlichting 10 Mar '00

10 Mar '00

Can someone with a lucky hand in Visual Basic actually tell us what the trojan attachment we saw (LINKS2.VBS) we saw (full mail headers included, in case Shawn hasn't seen them yet) actually does. Seems to cloak itself well, and my Norton AV is *not* detecting anything. On another operational note: I am seeing a vastly swelling number of customers falling victim to the NETWORK.VBS worm: a simple VB script that first scans surrounding network space for open, writable windows shares (and replicates by copying itself into a shared C:\ drive, if such drive is shared), then goes on to randomly scan /24's , where the 3 first octets of the IP number are random: this is generating boatloads of violations in my "no RFC1918 in or out" filters (and this is how this came to my attention). We found a user who had scanned a stunning 9980 /24's this way : there is a C:\network.log (or was it .txt) file showing the scan activity. bye,Kai >Received: from conti.nu (IDENT:root@sonet.conti.nu [208.241.100.25]) > by speedus.com (8.9.3/8.9.3) with ESMTP id PAA23318 > for <kai(a)mail.speedus.net>; Thu, 9 Mar 2000 15:12:02 -0500 (EST) >Received-Date: Thu, 9 Mar 2000 15:12:02 -0500 (EST) >Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) > by conti.nu (8.9.3/8.9.3) with ESMTP id PAA17489 > for <kai(a)pac-rim.net>; Thu, 9 Mar 2000 15:11:50 -0500 (EST) >Received: by segue.merit.edu (Postfix) > id 15D935DDA5; Thu, 9 Mar 2000 15:08:12 -0500 (EST) >Delivered-To: nanog-outgoing(a)merit.edu >Received: by segue.merit.edu (Postfix, from userid 56) > id EE69F5DDE2; Thu, 9 Mar 2000 15:08:11 -0500 (EST) >Received: from astro.smorris.com (astro.smorris.com [157.238.77.132]) > by segue.merit.edu (Postfix) with ESMTP id B9C0D5DDA5 > for <nanog(a)merit.edu>; Thu, 9 Mar 2000 15:08:08 -0500 (EST) >Received: from scooby (scooby.smorris.com [157.238.77.131]) > by astro.smorris.com (8.9.3/8.9.3) with SMTP id OAA04495; > Thu, 9 Mar 2000 14:01:25 -0600 >From: "Shawn Morris" <shawn(a)smorris.com> >To: <shawn(a)smorris.com> >Subject: Check this >Date: Thu, 9 Mar 2000 14:05:58 -0600 >Message-ID: <001f01bf8a02$e2d6d140$834dee9d@scooby> >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_001C_01BF89D0.98395400" >X-Priority: 3 (Normal) >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) >X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 >Importance: Normal >Sender: owner-nanog(a)merit.edu >Precedence: bulk >Errors-To: owner-nanog-outgoing(a)merit.edu >X-Loop: nanog >X-UIDL: a6afd5395e4e1808e17ac7358522b210 > >Have fun with these links. >Bye.

5 4

Re: Provider-local addresses?
by Brian Candler 10 Mar '00

10 Mar '00

On Thu, Mar 09, 2000 at 02:49:03PM -0500, Daniel L. Golding wrote: > I'm not sure I see the point. You can use the existing RFC1918 space for > this kind of application, such as having fixed, non-changing addresses > for DNS. Except that you want to avoid clashes with your customers' own networks, which may already be using RFC1918 behind NAT routers. You could hijack some of this space ("if you connect to me, you may not use this particular subnet of RFC1918") but that's not particularly friendly. > The whole kettle of worms are downstream allocated IP customers - be they > leased line, DSL, etc. This is the renumbering that can and does cost > small providers many customers Yeah, that's pretty inescapable :-) Cheers, Brian.

1 0

Re: Napster and others...
by Michael Shields 09 Mar '00

09 Mar '00

In article <v0422080ab4ed9bb6c397(a)[216.240.40.194]>, "Erik E. Fair" <fair(a)clock.org> wrote: > Precis: they (developers, users) can modify the application to use > spread-spectrum style port numbers that constantly change throughout > the life of a session, which makes it effectively impossible to > filter using existing technology. Filtering such traffic is within the state of the art -- proxy firewalls are not new. But agreed that your Cisco routers cannot stop it. -- Shields.

1 0

Re: Trojan Alert was: Check this
by Kai Schlichting 09 Mar '00

09 Mar '00

At Thursday 03:53 PM 3/9/00 , Hermann Wecke wrote: >At 15:28 09/03/2000 -0500, Kai Schlichting wrote: >>Can someone with a lucky hand in Visual Basic actually tell us what >>the trojan attachment we saw (LINKS2.VBS) we saw (full mail headers >>included, in case Shawn hasn't seen them yet) actually does. > >Check at NAI: > >http://vil.nai.com/vil/vbs10225.asp <http://vil.nai.com/vil/vbs10225.asp> > Note the warning on that page: ensure that scanning for .VBS files is on, unless you have it configured to scan for ALL files. The warning is very applicable to Norton AV as well: My Norton AV is up to date, and the default is NOT to scan for .VBS files (!) How could they miss that. I can't recall changing the scan settings from 'all' to 'some' files either. Looks like we have a real winning worm here that evades detection by lamely configured virus scanners - what the real default scan settings are is YTBD. Meanwhile, NETWORK.VBS is marching on. bye,Kai

1 0

Re: Trojan Alert was: Check this
by Hermann Wecke 09 Mar '00

09 Mar '00

At 15:28 09/03/2000 -0500, Kai Schlichting wrote: >Can someone with a lucky hand in Visual Basic actually tell us what >the trojan attachment we saw (LINKS2.VBS) we saw (full mail headers >included, in case Shawn hasn't seen them yet) actually does. Check at NAI: http://vil.nai.com/vil/vbs10225.asp <http://vil.nai.com/vil/vbs10225.asp>

1 0

Re: Trojan Alert was: Check this
by Steven M. Bellovin 09 Mar '00

09 Mar '00

In message <4.2.2.20000309152159.00d31ea0(a)mail.speedus.net>, Kai Schlichting wr ites: > > Can someone with a lucky hand in Visual Basic actually tell us what > the trojan attachment we saw (LINKS2.VBS) we saw (full mail headers > included, in case Shawn hasn't seen them yet) actually does. > Seems to cloak itself well, and my Norton AV is *not* detecting anything. > There was a report on Bugtraq the other day that some AV programs don't look at .VBS files. You may have to select 'check all files' or at least add .VBS to your list of extensions to scan. --Steve Bellovin

1 0