- Test - lists.nanog.org

Re: Here we go again
by brandon＠rd.bbc.co.uk 11 Mar '00

11 Mar '00

> What can you do? I would say "not much"- Tailor your output, too many requests for same page from same address gets a larger proportion of adverts on the page. May as well make some money off them, choose adverts for whatever it is they're protesting against then you can sell premium highly targeted ads. brandon

6 8

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

10 Mar '00

On Thu, 09 March 2000, Randy Bush wrote: > actually, in working with the other large providers, i have not found this > to be the case. and most smallish folk seem cooperative. it is usually the > middle sized folk who have not scaled to meet the problems, and occasionally > let things fall through the cracks. The key is the ability to reach the right person. In a small provider its easy because the boss answers the phone, or someone who knows the boss answers the phone. In a large provider, you might know a "famous" person. And even though they won't be the right person, they'll know the right person. If AT&T does something stupid, Randy might call Steve Bellovin (the wrong person) who in turn could hit the right manager over the head with the clue-by-four. Replace with the appropriate provider/person UUNET/Mike O'Dell, Verio/Randy Bush, etc. The problem is with providers without famous people and too many people, so they don't know each other. If you don't already know someone at, for example, NTT or BT or Qwest, navigating through their public contacts usually doesn't get you too far. What may be interesting is looking at how other industries handle the problem. In the banking industry, where failure to contact another bank can result in millions of losses, Thompson Publishing has an extensive directory of the security contacts for essentially every bank in the world. Thompson actively verifies the contact information, and banks pay a bunch of money for current copies of the directories. 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.

6 5

Re: Here we go again
by Scott Solmonson 10 Mar '00

10 Mar '00

What can you do? I would say "not much"- Assuming you truly cannot separate out the "legitimate" requests- Your choices are left to these: Bleed off all traffic above the POP's allowed levels- Increase capacity- Employ a distributed caching system- That's about it as far as I can see. "Scott McGrath" wrote: > > What to we need to do to nip this one in the bud > > "Henry R. Linneweh" wrote: >> >> 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 >> month?s Web attacks. >> http://www.msnbc.com/news/380065.asp?cp1=1 -- Scott Solmonson Speedera Networks Inc. -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* scosol(a)speedera.com / 408.970.1591

1 0

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