- Test - lists.nanog.org

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 22 Aug '96

22 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 22 Aug '96

22 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

Re: Trial accounts (Re: MAKE SPAM ...etc...)
by Vadim Antonov 22 Aug '96

22 Aug '96

Paul Vixie wrote: >(1) a Null0 route works fine, and costs no additional CPU. Ugh, did cisco fix that already? (Switching to null0 used to be done by CPU, not SSE). --vadim

1 0

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

22 Aug '96

Thre reason why traceroute uses UDP instead of ICMP is very simple -- there are a lot of broken-as-designed unices which either do not provide non-superuser access to harmless ICMP facilities, or cannot trace replies back to originating process. I'd rather fix operating systems than leaving a nice big vulnerability in the network. --vadim

1 0

*** MAKE SPAM@INTERRAMP.COM DIE FAST!!! *** (fwd)
by Michael Dillon 22 Aug '96

22 Aug '96

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''.

9 10