- Test - lists.nanog.org

Re: NANOG Registration
by Brett D. Watson 23 Aug '96

23 Aug '96

i just went back to redo the web form (since i was one that tried using a non-visa/mastercard) and note that the button for credit card selection lists american express as an option. you should probably remove that to avoid any more confusion. -brett > > Please NOTE the only credit cards that we are accepting for NANOG are > VISA & MasterCard. We also are accepting checks made out to the > Universtiy of Michigan. See the registration form on the Merit Web Page. > Pam Ciesla

2 1

Re: Access to the Internic Blocked
by Vadim Antonov 23 Aug '96

23 Aug '96

Curtis Villamizar <curtis(a)ans.net> wrote: >We have traced back such "clever" denial of service attacks before. >Within the last 6 months even. >Have you forgotten that we log and keep track of source/destination >pairs. I sincerely wish you good luck doing that at OC-12. If you know a magic technology which can do that please let me know. Doing that at 10 kpps is not going to be a solution any time soon. I would also wish you luck with logging SA/DA pairs at places like .ICP.NET. where source/destination matrix is about 1-2 millon entries long. >It is really easy for us to spot in incoming path with a set >of sources that were never coming from that direction and start >working backwards. Yeah? Over six backbones? >Other respectable providers cooperate. Nearnet >for example flew out a person and workstation to track an attack >coming through them. Cool. Now, if such a bogon generator becomes someting easily accessible to every newbie (as it is bound to become, sooner or later), that certainly will help. >We have Unix boxes deployed in every POP, even >with our new backbone. These watch over the FDDI rings. That certainly helps to people who already have to use FDDI switches. >Half the time the people doing this hacking are coming in from dialup >lines. Sometimes they break into somewhere better connected. Quote from one friendly sysadmin at very large and prestigeous u here in Bay Area: "Security? We don't have any. We have that special wide-open box so hackers can play with it and leave other machines alone". >An attack capable of any noticable load on a backbone is quite remote. I had two instances where unintentional flooding was saturating the backbone links (both cases with T-3 connected customers, one caused by fautly software, another by broken FDDI adapter). > Ok, with only one intermediate point allowed. _That_ should > take care of all diagnostic needs. >That would be useful. It could still be UDP. Sending something to ports which can be used by applications is not kosher. If anything, traceroute should at least attempt to use UDP "discard" service, not some random high ports. > Should i write a backbone-crasher and post it to USENET just to > make a point about LSRRs? Note that a provider which won't > shut LSRR will be the threat to others... >If we find out you did we would prosectute. I know for sure that the code doing nasty things with TCP resets exists and works. (As for "finding out" -- sorry, there is no concievable way of tracing origins of code if minimal precautions are taken, as any virus writer can attest). In any case, i don't care to do it. I have much more straightforward ways to achieve the same effect, in the very unlikely case that i ever wish or need to do that, ok? >We can very easily detect probes because we don't run any telnet, >rsh/rcp, or RCP services and these are commonly attacked. Any >activity destined to these ports is logged. Of course we log LSRR >to lower port numbers too. Sure. The real security is proactive, not retroactive. Logging only helps you to find out idiots who don't know better than to send sufficient quantities of probes to attract attention. A serious attacker would find a throw-away staging point (about five minutes worth of searching, realistically) and do probes from there. It is _much_ better to eliminate the unnecessary door, than to post guard at it. --vadim

1 0

Credit Cards for NANOG
by Pam Ciesla 23 Aug '96

23 Aug '96

We have added American Express to the accepted credit cards for the NANOG Meeting. If you have already sent your registration with your American Express info DO NOT resend it I will add you to the list of attendees. Thanks Pam Ciesla

1 0

Gaol...nee blacklist
by bmanning＠isi.edu 23 Aug '96

23 Aug '96

Well, AltaVista found a dead pointer... Not sure what happended here. Blacklist of Internet Advertisers Blacklist of Internet Advertisers. ========================================================================= Canter and Siegel acknowledge Blacklist's... http://www.ip.net/BL/blacklist.html - size 48K - 15 Jun 96 -- --bill

2 1

Re: Access to the Internic Blocked
by Vadim Antonov 23 Aug '96

23 Aug '96

Curtis Villamizar wrote: > Not at all. LSRR is a nice tool to mount practically untraceable > flooding attack (hint -- just forge source address and spread > intermediate points evenly across the network). Shutting you > down may be exactly what the attacker wants. >Oh come on. Like they're not going to get caught stuffing an entire >T1 with LSRR packets. Face it. You're grabbing at straws. Ugh. To kill multiple DS-3s you don't even need a full T-1 (you need one LS address for every loop), and you can kill multiple DS-3s and an IXP to boot, with the single stream of bogons routed in a loop with many hops. And there's a lot of big name Us with DS-3 connectivity and no security whatsoever. Now, throw in randomized first hop and forged source address, and i'll wish you good luck catching the perpetrator. A careful attacker would also randomize destinations and make it to look like regular TCP traffic. (And did anybody think of IP stacks which reverse the source routes, just to make things funnier). >Besides the fact that with your suggestion of traceroute using ICMP >echo requests they'd just send a T1s worth of ICMP echo requests with >LSRR and accomplish the same thing. Ok, with only one intermediate point allowed. _That_ should take care of all diagnostic needs. >LSRR is just too useful for diagnosing network problems to shut down >on a backbone. I sometimes wonder if the threat of hackers is exaggregated. They certainly missed a nice opportunity to crash the Internet with TCP resets on iBGPs. Now nobody cares about the creative potential of LSRR-anonymized denial of service attacks. They must be stupid or something. Should i write a backbone-crasher and post it to USENET just to make a point about LSRRs? Note that a provider which won't shut LSRR will be the threat to others... --vadim

3 2

Re: Customer AS
by Chris MacFarland 23 Aug '96

23 Aug '96

Jon Zeeff wrote: > > > Isn't this the provider that says that dual-homing to them (ie, not > to another provider) should always be adequate? > Yep this is sprintlink. Sprint has been having route flapping problems for the past 3 days. Their NOC and engineers have been unable to pinpoint it. The master ticket from customer maintenance 6554885 said the cause was IS-IS routing problems. > > As a sprintlink customer I can say that today was from hell. Couldn't > > reach *any* of the root nameservers for about 2-3 hours, of course before > >I > > discovered it was a sprintlink problem I killed and restarted named thus > > loosing my cache :-( and things still aren't back to normal. NOC said that > > they were having major "route-flapping" problems, and were trying to > > determine the source of the problem. I hope they've figured it out. You were lucky. Looking at my routing table shows the majority of the routes from sprintlink to be about 6 hours old. This is best I have seen in the past few days. Most of the time the routes from them have been less than 20 minutes old. Chris MacFarland CompuNet

1 0

Re: *** MAKE SPAM@INTERRAMP.COM DIE FAST!!! *** (fwd)
by matthew＠scruz.net 23 Aug '96

23 Aug '96

Original message <9608221609.AA21172(a)wisdom.home.vix.com> From: Paul A Vixie <paul(a)vix.com> Date: Aug 22, 9:09 Subject: Re: *** MAKE SPAM(a)INTERRAMP.COM DIE FAST!!! *** (fwd) > > > Even if I wanted to do this, I don't think I could take the performance > > hit running an access list that large on my incoming ports would create. > > Thus the beauty of a Null0 route. The initial SYN from their spam maker > gets through to your SMTP server, but the initial ACK goes into the hole > rather than back out to their spam maker. It costs you a TCP PCB for a > short while on the SMTP server, but there are never enough packets to make > this expensive. And no spam gets through. Try it, you'll like it. >-- End of excerpt from Paul A Vixie Our mail server regularly gets stuck with a full listen queue due to occasional cases of one-way routing out on the net,... deliberately introducing this would kill it. Consider, for instance, that the spammer is probably sending mail to dozens of accounts on your system, and each attempt will generate multiple SYN's, and each one of those wastes a slot for several minutes. Even if you've cranked it up from the default of 5, you'll be hosed for hours. Of course, I suspect that any evidence that multiple providers were filtering mail based on some agreed-upon list would land all of them in court, though I'm not a lawyer. Imagine, for a minute, that some spammer discovers that one of YOUR unix boxes can be used to forward mail for them, some weekend when you're out of town,... and your IP address gets blacklisted. How soon would you call your lawyer to help you recover from what could be a total loss of business? -matthew kaufman matthew(a)scruz.net

4 3

Re: Access to the Internic Blocked
by Vadim Antonov 23 Aug '96

23 Aug '96

> No. They just can't see the forest for the trees. In other words, hackers > focus on the hosts not on the network infrastructure. And since they > depend on the network to carry their attacks to their hosts of interest > they don't have much incentive to attack the net itself. Hm. What about the "Internet Liberation Front"? They certainly did attack the infrastructure. And, then, RTM is their hero. Every weenie out there would love to say something along the lines "Know that '9x Big Internet Outage? Like nothing since The Worm? That's me!". --vadim

1 0

Re: *** MAKE SPAM@INTERRAMP.COM DIE FAST!!! *** (fwd)
by owen＠DeLong.SJ.CA.US 23 Aug '96

23 Aug '96

Even if I wanted to do this, I don't think I could take the performance hit running an access list that large on my incoming ports would create. I think in order to be able to handle that kind of filtration, he must be an insignificant smaller provider. A larger provider doesn't have the spare cycles in the router to handle it. Owen > I see the following kind of message on a regular basis. How long before > this kind of thing starts to cause significant problems? And lest you say > that xmission.com is only a small unimportant provider, I've seen much > larger ones also saying they do this and not everybody is as selective > about only blocking one port. > > Michael Dillon - ISP & Internet Consulting > Memra Software Inc. - Fax: +1-604-546-3049 > http://www.memra.com - E-mail: michael(a)memra.com > > ---------- Forwarded message ---------- > Date: Wed, 21 Aug 1996 15:38:19 -0600 (MDT) > From: Pete Ashdown <pashdown(a)xmission.com> > Reply-To: inet-access(a)earth.com > To: inet-access(a)earth.com > Subject: *** MAKE SPAM(a)INTERRAMP.COM DIE FAST!!! *** > Resent-Date: Wed, 21 Aug 1996 15:39:02 -0600 (MDT) > Resent-From: inet-access(a)earth.com > > We have seen an inordinate amount of spam email sourcing from Interramp.com > and their customers. Despite frequent attempts to notify KEN ANDREWS, PSI, > or any living soul at Interramp, our pleas have gone unanswered. As a > result, *ALL* SMTP mail traffic from Interramp's networks has been blocked at > the router level here. > > I would encourage *EVERY* responsible ISP to do the same. Interramp does not > appear to care about spam problems, and in fact has become a haven for this > type of crap due to their complicity. > > The following is instructions on how to block Interramp SMTP traffic on a > Cisco: > > Make an extended IP access list: > > access-list 120 deny tcp 38.8.23.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.8.31.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.8.45.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.8.65.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.9.51.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.10.1.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.10.2.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.10.3.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.10.4.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.10.5.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.10.220.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.72.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.122.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.183.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.189.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.194.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.207.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.208.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.209.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.210.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.215.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.217.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.224.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.226.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.227.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.229.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.230.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.231.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.237.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.243.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.11.244.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.81.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.93.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.126.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.128.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.138.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.140.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.156.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.157.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.158.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.178.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.179.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.190.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.205.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.206.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.208.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.209.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.234.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.12.243.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.101.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.110.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.126.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.128.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.138.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.140.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.142.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.35.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.36.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.37.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.40.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.45.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.74.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.79.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.14.82.0 0.0.0.255 eq smtp any > access-list 120 deny tcp 38.26.44.0 0.0.0.255 eq smtp any > access-list 120 ip permit all all > > Due to the fact that Interramp's networks are not contiguous in any apparent > way, you have to block each one on a class C basis. If anyone sees any > evidence otherwise, please let me know. Of course, it wouldn't be a bad idea > to block all of 38.0.0.0 because PSI hasn't been cooperative either. > > After the list is created, add it to your incoming interfaces with: > > ip access-group 120 in > > The 120 is arbitrary, it can be anything in the extended IP access-list range. > > ============================== ISP Mailing List ============================== > Email ``unsubscribe'' to inet-access-request(a)earth.com to be removed. > Don't post messages that just say ``me too''. > >

4 3

Re: Access to the Internic Blocked
by Vadim Antonov 23 Aug '96

23 Aug '96

Vince Fuller wrote: >You'll also need to pursuade your router vendor to violate the ICMP spec, >which says that ICMP error messages (i.e. TTL exceeded) are never sent in >response to ICMP messages... >I suspect that this restriction is precisely the reason that "traceroute" uses >high-port UDP packets. That is correct. (There are other reasons, too). However, sending ICMP errors in response on ICMP ECHO Request is safe. Unlike sending random UDP messages to random ports. Maybe ICMP specs should be updated and this is the rare case when Microsoft got it right (in spirit, if not letter). --vadim

1 0