August 1996 - Test - lists.nanog.org

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

Re: Access to the Internic Blocked -- LSRR, traceroute with ICMP
by owen＠DeLong.SJ.CA.US 22 Aug '96

22 Aug '96

> > Speaking of which, is anyone going to implement traceroute > >for UNIX which using icmp echo requests, instead of (semi-)random > >udp packets, as the ammo? This is one way which I think Microsoft out > >did the old UNIX implementations. > Then how come UNIX traceroute works in so many places where MSloth's traceroute falls flat on it's face? Remember, an ICMP packet doesn't generate TIME EXCEEDED messages in many applications. It's listed as something the system MAY implement, not SHOULD or MUST. Time exceeded messages are a MUST for UDP and TCP packets. > They're not semi (or quasi) random udp packets. They're sequential > packets. > > Secondly, current router vendors' decisions to prioritize ICMP echo > request as dung-level packets means that traceroute's UDP packets > actually get through at times when pings don't. > This is both good and bad. > Third, I'd be happy to implement it... but I'm not sure this would > be a win. I can see the loss (see paragraph 2), but WHAT is the > big win??? > Compatibility with Whine-Doze? :-) > E > p.s. The original question was based on Vadim's rhetorical query > as to router vendors. Learn to differentiate between WISHFUL > THINKING and routing reality. When router vendors pledge to > not drop, and properly route lsrr icmp echo request/reply > that code will be online within 24 hours. > > :-) Owen > > The combination of the above and the below would give us > >the usefulness we want and the security we want. (I don't think > >the below would work with Van Jacobsen's traceroute 1.2) > > >On Wed, 21 Aug 1996, Vadim Antonov wrote: > > >> On itself, LSRR is a godsend to hackers (i can think of about > >> a dozen of very nasty attacks using general LSRR). The only > >> useful application for it is traceroute. > >> > >> Why don't router vendors provide an option to turn it > >> off for everything but ICMP ECHO? > >> > >> --vadim > >

3 2

Re: Access to the Internic Blocked
by Vince Fuller 22 Aug '96

22 Aug '96

So now I need to hack my traceroute to send ICMP_ECHO_REQUESTS instead of high-port udp packets? 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. --Vince

1 0