- Test - lists.nanog.org

RE: source filtering
by Scott McGrath 14 Jan '99

14 Jan '99

I only spoke from my own experience with both carriers no offense intended > -----Original Message----- > From: Tony Tauber [SMTP:ttauber@bbnplanet.com] > Sent: Wednesday, January 13, 1999 10:38 PM > To: Scott McGrath; Jared Mauch; nanog(a)merit.edu > Subject: Re: source filtering > > On Jan 13, 3:41pm, Scott McGrath wrote: > > Subject: RE: source filtering > > GTE and ATT both filter via access lists on the customers CPE routers IF > > they provide the routers to the customer > > > > It'd be nice if this information came from one of the entities > named above. Here's a refinement for our part. > > GTE does not impose mandatory source address filtering via > access-lists on customers' CPE routers. However, we have recently > implemented Cisco's "ip verify unicast reverse-path". > > Tony Tauber > GTE Network Engineering

1 0

RE: Smurfing and IP filtering
by Scott McGrath 14 Jan '99

14 Jan '99

Both would be a good idea as it would cover all the bases for most network operators > -----Original Message----- > From: Steven J. Sobol [SMTP:sjsobol@nacs.net] > Sent: Wednesday, January 13, 1999 9:50 PM > To: Scott McGrath > Cc: Chris Cook; nanog(a)merit.edu > Subject: Re: Smurfing and IP filtering > > On Wed, Jan 13, 1999 at 02:19:47PM -0500, Scott McGrath wrote: > > That would be a good starting point for the more sophisticated users > however > > most small networks have very uneven > > clue distribution so I believe something in a FAQ format would be more > > approachable to the small ISP/Network operator > > ...why not both? > > Cover configuration for, say, the top 5 brands of routers (which, > realistically, should cover the majority of ISP's out there...) > > -- > Steve Sobol [sjsobol(a)nacs.net] > Part-time Support Droid [support(a)nacs.net] > NACS Spaminator [abuse(a)nacs.net] > > Proud resident of Cleveland Heights, Ohio, the coolest place on earth. > http://www.ClevelandHeights.com

1 0

Re: Solution: Re: Huge smurf attack
by Dean Anderson 14 Jan '99

14 Jan '99

Actually, I think all major providers use automatic provisioning systems which generate router configs. They don't need to rely on router vendors to set particular defaults. If all major providers made sure their provisioning systems turned off directed broadcast, a lot of the problem would go away. So "Router defaults" is a lame excuse for ISP's. Even little ISP's have a list of things they have to setup, (eg ip classless, subnet zero, etc) which have "legacy" or otherwise inappropriate defaults. And yes, some customers may in fact want or need directed broadcasts on. For example, if they are subnetting. In that case, you change it for them. I tell our customers certain things are turned off by default, and if they really want it on, they will need to ask. Of course, the problem remains that some smurfers are undoubtedly on this list, possibly working for major providers. (This is my guess as to source of the 10.x smurf amps.) --Dean At 02:05 AM 1/12/1999 -0500, Brandon Ross wrote: >On Mon, 11 Jan 1999, Daniel Senie wrote: > >> The proper answer to this is to disable directed broadcasts on the >> routers themselves. It'd be helpful if routers came out of the box with >> this feature disabled by default. Perhaps folks should talk with their >> router vendors of choice and ask for this change. I have submitted a >> draft into the IETF process to require this change, updating RFC 1812 >> (router requirements). > >I'm happy to say that progress is being made in this area. When a vendor >comes to us for the first time, one of things I tell them is that we will >not buy their hardware until they ship with directed broadcast disabled by >default. We've had a lot of success in this area, we'd have even more if >others would do the same. > >Brandon Ross Network Engineering 404-815-0770 800-719-4664 >Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com > ICQ: 2269442 > >Stop Smurf attacks! Configure your router interfaces to block directed >broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details. > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 6

Re: Huge smurf attack
by Dean Anderson 14 Jan '99

14 Jan '99

At 09:48 AM 1/12/1999 -0800, Dalvenjah FoxFire wrote: >On Tue, Jan 12, 1999 at 05:12:22PM +0000, Michael Shields put this into my mailbox: > >> In article <19990111101351.04195(a)dragonlair.dal.net>, >> Dalvenjah FoxFire <dalvenjah(a)DAL.NET> wrote: >> > Much as I hate to say it, this seems to be one area where industry >> > self-regulation has utterly failed. I don't know what would be a better >> > solution; I hate to suggest government regulation. But I'm at a loss here. >> >> Civil liability? > >Possibly. I don't know of anyone who's tried suing over a smurf attack. >If I could afford the lawyer and the court time I'd do it myself. >All we really need is one or two good cases to establish some case law; >then the rest of us can have some legal precedent to point to and say >"If you don't fix your networks, you're screwed." Criminal. DOS attacks are covered by 18 USC 1030. And I think there might even be smurf included in the Kevin Mitnick case, but I'm not sure about that. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: Huge smurf attack
by Brandon Ross 14 Jan '99

14 Jan '99

Doh! That should have read: ftp://ftp.mindspring.net/users/bross/smurfsources On Sat, 9 Jan 1999, Quan Nguyen wrote: > On Sat, 9 Jan 1999, Brandon Ross wrote: > > > Since a couple folks have asked for it, and I think the list is a bit > > large to send to the entire list, I've put the list up for anonymous ftp > > at: > > > > ftp://www.mindspring.net/users/bross/smurfsources > > I got this. My network is 132.206.0.0/26. > > % ftp www.mindspring.net > ftp: connect to address 207.69.200.96: Connection refused > Trying 207.69.200.97... > ftp: connect: Connection refused > ftp> quit > > > Quan, > > Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info(a)mindspring.com ICQ: 2269442 Stop Smurf attacks! Configure your router interfaces to block directed broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.

14 25

Re: Solution: Re: Huge smurf attack
by danderson＠lycos.com 14 Jan '99

14 Jan '99

I should have been more careful when stating 'filtering icmp' in my previous messages. I use something similar to this: >access-list 101 deny icmp any any echo >access-list 101 deny icmp any any echo-reply >access-list 101 permit icmp any any Only I'm allowing the echo-reply so I can ping/traceroute out for my troubleshooting needs. However, I don't buy the 'it breaks testing methods' because there are other ways to test that using icmp for incoming stuff. Plus, if you use named access lists (in new code releases), you can throw in a permit statement then delete it without taking out the whole list. (That is done with the 'ip access-list extended <name>' subset- very nice, check it out) Of course this doesn't do anything for your upstream links, but what can you do about that anyway? Get on your tier 1 provider for that! Plus, you STILL have directed broadcasts turned off in my scenario so the access list is almost futile. And if you are worried about excess CPU utilization, so what? Look into stuff like the netflow switching commands rather than the optimal setting. That can make a tremendous difference. Or you can always buy better gear! How important is your service?? later- devin "Craig A. Huegen" <chuegen(a)quadrunner.com> on 01/12/99 02:01:04 PM To: Steve Gibbard <scg(a)wwnet.net>, Devin Anderson/Lycos cc: nanog(a)merit.edu Subject: Re: Solution: Re: Huge smurf attack On Tue, Jan 12, 1999 at 01:11:09PM -0500, Steve Gibbard wrote: ==>On Tue, 12 Jan 1999 danderson(a)lycos.com wrote: ==> ==>> I'm not sure what the big issue here is with the smurf attacks. If you set ==>> up some kind of access list that disables incoming icmp traffic, then turn ==> ==>That breaks path MTU discovery (see RFC 1435 for more info on that), among ==>other things. Two choices: access-list 101 deny icmp any any echo access-list 101 deny icmp any any echo-reply access-list 101 permit icmp any any -or- access-list 101 permit icmp any any packet-too-big access-list 101 deny icmp any any Neither of these is a particularly elegant solution because they block troubleshooting tools such as ping and traceroute. CAR works well to provide these troubleshooting services during normal operations and to help suppress attacks. /cah

4 3

MCI Fiber Cut in VA
by Martin, Christian 13 Jan '99

13 Jan '99

MCI is reporting a cut in the Danville, VA area. MCI reports 175 DS3s down. Cause: Homeowner building a new driveway. Splicers have been on site since 4:00 PM EST. Seems like traffic in the area is taking the scenic route, as we are seeing 30 ms response times across SMDS T1 lines... Chris

1 0

RE: latency vs. packet loss
by Martin, Christian 13 Jan '99

13 Jan '99

The question you pose cannot be answered as succinctly as you may think. Various factors contribute to packet loss and latency - many of which are completely unrelated. For example, if you purchase ATM CBR connectivity from NY to Australia, you will see high latency, but (assuming you are within your trffic contract) no packet loss. Here the latency is due to propogation delay. Then again, you may have GigE connectivity across the data center floor to a switching cluster supporting a group of application servers that cannot handle the load being delivered by the network. Here, there isn't much latency, but there may be significant packet loss. Also note that the traditional Poisson distribution that early queueing theory was founded on is not always the best model for todays Internet. Traffic patterns at exchange points are becoming more and more fractal in nature, and new queuing technologies such as WRED coupled with rate limiting technologies such as CAR, take your assumptions about available bandwidth, switching latency, and queue/buffer depth and flush them down the drain. The point is, this is a difficult question to answer. If I were to make a VERY general assumption, however, I may be persuaded to agree with your proposed correlation, although many would find objection to this with evidence to substantiate their claim. Regards, Chris -----Original Message----- From: jzeeff(a)whs.verio.net [mailto:jzeeff@whs.verio.net] Sent: Wednesday, January 13, 1999 4:18 PM To: nanog(a)merit.edu Subject: latency vs. packet loss How well does latency correlate to packet loss on the Internet? For example, if one were to pick one of several randomly placed sites on the net based on lowest latency to/from point x, what percentage of this time would this also yield the site with the lowest packet loss to/from point x? My guess is that the correlation is high (due to typical buffer sizes).

1 0

RE: source filtering
by Scott McGrath 13 Jan '99

13 Jan '99

GTE and ATT both filter via access lists on the customers CPE routers IF they provide the routers to the customer > -----Original Message----- > From: Jared Mauch [SMTP:jared@puck.nether.net] > Sent: Tuesday, January 12, 1999 12:31 PM > To: nanog(a)merit.edu > Subject: source filtering > > > I'm interested in what providers actually do source > filtering of their customers. > > Including: > > 1) Using access-lists to filter your customers > 2) Using the "ip verifiy unicast reverse-path" Cisco feature > (it's in 11.1CC images when you use CEF, so I don't get a flood > of e-mails) > 3) Using other router vendors and features you have to > filter source addresses. > > I'd like to summarize this all and start a quest to fix > providers that don't source filter (as people quest against spam, and > against smurfable network blocks). > > jared > > -- > Jared Mauch | pgp key available via finger from jared(a)puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only > mine.

1 0

h.root-servers.net returning false negatives (fwd)
by Marc Slemko 13 Jan '99

13 Jan '99

FYI, below is a copy of a message I sent to the appropriate people. I guess that this time it isn't as bad since it is at least possible that there were automated scripts that didn't detect this, since it is only happening for certain domains. Expect sporadic difficulties resolving names for domains that are impacted if you happen to talk to h.root-servers.net. ---------- Forwarded message ---------- Date: Wed, 13 Jan 1999 09:58:50 -0800 (PST) From: Marc Slemko <marcs(a)znep.com> Subject: h.root-servers.net returning false negatives for some .com domains, and possibly others. eg. marcs@alive:~$ dig stocksite.com ns @h.root-servers.net ; <<>> DiG 8.1 <<>> stocksite.com ns @h.root-servers.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; stocksite.com, type = NS, class = IN ;; AUTHORITY SECTION: COM. 1D IN SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( 1999011105 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum ;; Total query time: 144 msec ;; FROM: alive.znep.com to SERVER: h.root-servers.net 128.63.2.53 ;; WHEN: Wed Jan 13 09:54:54 1999 ;; MSG SIZE sent: 31 rcvd: 108 Other examples include worldgate.com, znep.com, yahoo.com, etc. Not all domains are impacted. h.root-servers.net needs to be taken down ASAP since it is causing any queries for those domains that hit those servers to be given a false nxdomain. Also note that many or most of the root nameservers have a zone file a few days out of date (as does this one...) which may or may not be related.

1 1