- Test - lists.nanog.org

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

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

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

23 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

NANOG Registration
by Pam Ciesla 22 Aug '96

22 Aug '96

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

1 0

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

22 Aug '96

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

4 3

Re: Access to the Internic Blocked
by John Hawkinson 22 Aug '96

22 Aug '96

> >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? > > Personally I find this an excellent suggestion. So now I need to hack my traceroute to send ICMP_ECHO_REQUESTS instead of high-port udp packets? Oh well, I guess we can put this right next to the patches to have traceroute send TCP SYNs to get through stupid firewalls. --jhawk

1 0

Re: Access to the Internic Blocked
by Geoff Huston 21 Aug '96

21 Aug '96

The number of transit providers who turn off lsrr is growing daily. Quite frankly turning it off it simply makes everyones life harder. The only justification I hear when I question this is a) "this is some kind of proxy security mechanism for our clients" (really!) or b) "whats loose source routing anyway?" Geoff Huston gih(a)telstra.net >To: Michael Dillon <michael(a)memra.com> >cc: nanog(a)merit.edu >Subject: Re: Access to the Internic Blocked >Date: Wed, 21 Aug 1996 13:41:50 -0400 >From: "Jeff Young" <young(a)mci.net> > >perhaps if folks would just take the time to loose source route >in both directions instead of only one... > >was the web page in response to complaints to those who turn off lsrr? > >Jeff Young >young(a)mci.net

2 1

Re: Access to the Internic Blocked
by Geoff Huston 21 Aug '96

21 Aug '96

The number of transit providers who turn off lsrr is growing daily. Quite frankly turning it off it simply makes everyones life harder. The only justification I hear when I question this is a) "this is some kind of proxy security mechanism for our clients" (really!) or b) "whats loose source routing anyway?" Geoff Huston gih(a)telstra.net >To: Michael Dillon <michael(a)memra.com> >cc: nanog(a)merit.edu >Subject: Re: Access to the Internic Blocked >Date: Wed, 21 Aug 1996 13:41:50 -0400 >From: "Jeff Young" <young(a)mci.net> > >perhaps if folks would just take the time to loose source route >in both directions instead of only one... > >was the web page in response to complaints to those who turn off lsrr? > >Jeff Young >young(a)mci.net

1 0