The following network numbers were pulled from a program called "smurf". The program sends a large amount of spoofed traffic at broadcast addresses, hoping their echo packets will be magnified and sent to the spoofed address. The providers/machines most commonly hit are IRC servers and providers. To prevent from being an intermediary, one must turn off "ip directed broadcasts" on the router's interface. "198.3.101.255", "204.71.177.0", "192.41.177.255", "206.13.28.255", "144.228.20.255", "206.137.184.255", "198.32.186.255", "130.63.236.255", "208.202.14.255", "208.131.162.255", "199.171.6.255", "207.124.104.255", "205.180.58.255", "198.3.98.0", "131.104.96.255", "143.43.32.0", "131.215.48.0", "204.117.214.0", "143.43.32.255", "130.235.20.255", "206.79.254.255", "199.222.42.255", "204.71.242.255", "204.162.80.0", "128.194.103.255", "207.221.53.255", "207.126.113.255", "198.53.145.255", "209.25.21.255", "194.51.83.255", "207.51.48.255", "129.130.12.255", "192.231.221.255", "168.17.197.255", "198.242.55.255", "130.160.224.255", "128.83.40.255", "131.215.48.255", "169.130.10.255", "207.20.7.255", "163.179.1.0", "129.16.1.0", "128.122.27.255", "132.236.230.255", "198.32.146.255", "192.41.177.0", "192.41.177.255", "203.25.25.255", "128.82.4.255", "128.6.5.255", "206.80.169.255" "204.71.154.255" "204.127.236.255", "192.41.177.255", "129.200.193.255" "130.1.200.255", "130.1.91.255", "130.1.87.255" "207.155.93.255", "129.245.110.255", "207.155.121.255" "203.252.5.255", "128.6.5.255", "128.82.4.255" "129.245.75.255", "129.245.5.255", "206.7.114.255" "130.1.200.255", "129.245.17.255", "129.245.15.255"
On Fri, Sep 05, 1997 at 11:12:16AM -0400, Network Administrator wrote:
The following network numbers were pulled from a program called "smurf".
The notice is appreciated. You're new on NANOG, right? Someone else posted this about a month ago. I stuck my foot in my mouth up to about the ankle misinterpreting the attack, as everyone was kind enough to point out to me... :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
What are the implications of turning off "ip directed broadcasts" on our routers? Or is this something that all backbone providers or ISPs automatically do (kind of like "ip classless" and "ip subnet-zero")? Thx...David * David Papp | 4907-99 Street | Phone: +1.403.430.0811 * * Manager | Edmonton, Alberta | Fax: +1.403.436.9963 * * OA Internet Inc. | Canada, T6E 4Y1 | Email: david@oanet.com * On Fri, 5 Sep 1997, Network Administrator wrote:
The following network numbers were pulled from a program called "smurf". The program sends a large amount of spoofed traffic at broadcast addresses, hoping their echo packets will be magnified and sent to the spoofed address. The providers/machines most commonly hit are IRC servers and providers. To prevent from being an intermediary, one must turn off "ip directed broadcasts" on the router's interface.
"198.3.101.255", "204.71.177.0", "192.41.177.255", "206.13.28.255", "144.228.20.255", "206.137.184.255", "198.32.186.255", "130.63.236.255", "208.202.14.255", "208.131.162.255", "199.171.6.255", "207.124.104.255", "205.180.58.255", "198.3.98.0", "131.104.96.255", "143.43.32.0", "131.215.48.0", "204.117.214.0", "143.43.32.255", "130.235.20.255", "206.79.254.255", "199.222.42.255", "204.71.242.255", "204.162.80.0", "128.194.103.255", "207.221.53.255", "207.126.113.255", "198.53.145.255", "209.25.21.255", "194.51.83.255", "207.51.48.255", "129.130.12.255", "192.231.221.255", "168.17.197.255", "198.242.55.255", "130.160.224.255", "128.83.40.255", "131.215.48.255", "169.130.10.255", "207.20.7.255", "163.179.1.0", "129.16.1.0", "128.122.27.255", "132.236.230.255", "198.32.146.255", "192.41.177.0", "192.41.177.255", "203.25.25.255", "128.82.4.255", "128.6.5.255", "206.80.169.255" "204.71.154.255" "204.127.236.255", "192.41.177.255", "129.200.193.255" "130.1.200.255", "130.1.91.255", "130.1.87.255" "207.155.93.255", "129.245.110.255", "207.155.121.255" "203.252.5.255", "128.6.5.255", "128.82.4.255" "129.245.75.255", "129.245.5.255", "206.7.114.255" "130.1.200.255", "129.245.17.255", "129.245.15.255"
At 9:43 AM -0600 9/5/97, David Papp wrote:
What are the implications of turning off "ip directed broadcasts" on our routers? Or is this something that all backbone providers or ISPs automatically do (kind of like "ip classless" and "ip subnet-zero")?
This was covered in some detail about a month ago, so you could check the list's archives. The operational implications of turning off "ip directed broadcasts" seem negligible--there are very few circumstances in which you *need* to send packets to the broadcast address on another network. I would hope that this becomes "automatic" like the other commands you mention. I can think of very few circumstances in which you need directed broadcasts, yet by permitting them, you allow your network to be used in attacks against others. We're also using the following extended access list (along with anti-spoofing filters) to prevent smurf attacks from originating from our network: access-list XXX deny ip any 0.0.0.255 255.255.255.0 But that's just us... Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|
On Fri, 5 Sep 1997 15:24:58 -0400, jordyn@bestweb.net writes:
We're also using the following extended access list (along with anti-spoofing filters) to prevent smurf attacks from originating from our network:
access-list XXX deny ip any 0.0.0.255 255.255.255.0
Folks, this is a bad idea. There are lots of completely valid IP addresses out there that end in .255. True, most of them that end in .255 ARE broadcast addresses, but if people implement this kind of filtering on a large scale, it really breaks classless IP. But that's just IMHO. :) -Jon ----------------------------------------------------------------- * Jon Green * "Life's a dance * * jcgreen@netINS.net * you learn as you go" * * Finger for Geek Code/PGP * * * #include "std_disclaimer.h" * http://www.netins.net/showcase/jcgreen * -------------------------------------------------------------------------
At 2:45 PM -0500 9/5/97, Jon Green wrote:
On Fri, 5 Sep 1997 15:24:58 -0400, jordyn@bestweb.net writes:
We're also using the following extended access list (along with anti-spoofing filters) to prevent smurf attacks from originating from our network:
access-list XXX deny ip any 0.0.0.255 255.255.255.0
Folks, this is a bad idea. There are lots of completely valid IP addresses out there that end in .255. True, most of them that end in .255 ARE broadcast addresses, but if people implement this kind of filtering on a large scale, it really breaks classless IP.
Eep, this is true. (Stupid me). Haven't had any complaints yet from users unable to access anything yet, but so much for making the 'Net slightly safer from this crap. Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|
On Fri, 5 Sep 1997, Jordyn A. Buchanan wrote:
At 2:45 PM -0500 9/5/97, Jon Green wrote:
On Fri, 5 Sep 1997 15:24:58 -0400, jordyn@bestweb.net writes:
We're also using the following extended access list (along with anti-spoofing filters) to prevent smurf attacks from originating from our network:
access-list XXX deny ip any 0.0.0.255 255.255.255.0
Folks, this is a bad idea. There are lots of completely valid IP addresses out there that end in .255. True, most of them that end in .255 ARE broadcast addresses, but if people implement this kind of filtering on a large scale, it really breaks classless IP.
Eep, this is true. (Stupid me).
Haven't had any complaints yet from users unable to access anything yet, but so much for making the 'Net slightly safer from this crap.
Well, I'm not so sure it is a bad idea in all cases. Like anything, you should apply this with a little forthought, however. If you know how your network is configured, if you know how people have carved up their class B's and such, you can eliminate a lot of the problems by doing this kind of thing, especially if your network is not too large. It won't stop a broadcast sent to a network like 129.129.4.0/22 (i.e. 129.129.7.255), and the same is true for smaller networks, but if you have a bunch of class B's and you have carved them up into /24's, then you can catch a lot of the problems by doing just that filter. As a general rule, for everyone, probably not! --Rick -- Rick Summerhill Network administrator, KANREN 5008 Canyon Road The University of Kansas Manhattan, KS 66503 rrsum@kanren.net (785) 539-6796 rrsum@cody.flinthills.com
In message <199709051945.OAA26522@worf.netins.net>, Jon Green writes:
On Fri, 5 Sep 1997 15:24:58 -0400, jordyn@bestweb.net writes:
access-list XXX deny ip any 0.0.0.255 255.255.255.0
Folks, this is a bad idea. There are lots of completely valid IP addresses out there that end in .255. True, most of them that end in .255 ARE broadcast addresses, but if people implement this kind of filtering on a large scale, it really breaks classless IP.
Likewise, not all broadcast adresses necessarily end with .255, so filtering .255 won't help anyway in the presence of something like a /25 with a X.X.X.127 broadcast.
Date: Fri, 05 Sep 1997 14:04:17 -0600 From: "Michael K. Sanders" <msanders@aros.net> Subject: Re: smurf's attack... To: Jon Green <jcgreen@netins.net> Cc: "Jordyn A. Buchanan" <jordyn@bestweb.net>, nanog@merit.edu
In message <199709051945.OAA26522@worf.netins.net>, Jon Green writes:
On Fri, 5 Sep 1997 15:24:58 -0400, jordyn@bestweb.net writes:
access-list XXX deny ip any 0.0.0.255 255.255.255.0
Folks, this is a bad idea. There are lots of completely valid IP addresses out there that end in .255. True, most of them that end in .255 ARE broadcast addresses, but if people implement this kind of filtering on a large scale, it really breaks classless IP.
Likewise, not all broadcast adresses necessarily end with .255, so filtering .255 won't help anyway in the presence of something like a /25 with a X.X.X.127 broadcast.
Agreed but it is not easy for a hacker to determine CIDR masks. It is my impression that the only thing being sent is classfull broadcasts.
Dave Nordlund d-nordlund@ukans.edu University of Kansas 913/864-0450 Computing Services FAX 913/864-0485 Lawrence, KS 66045 KANREN
At 3:41 PM +0000 9/5/97, DAVE NORDLUND wrote:
Likewise, not all broadcast adresses necessarily end with .255, so filtering .255 won't help anyway in the presence of something like a /25 with a X.X.X.127 broadcast.
Agreed but it is not easy for a hacker to determine CIDR masks. It is my impression that the only thing being sent is classfull broadcasts.
Further, smaller networks (which, theoretically speaking at least, have fewer hosts) would be less useful in a smurf attack than larger ones, as there would be less of a multiplying effect. Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|
In message <F8F9425FD8@ccstaff.cc.ukans.edu>, DAVE NORDLUND writes:
Likewise, not all broadcast adresses necessarily end with .255, so filtering .255 won't help anyway in the presence of something like a /25 with a X.X.X.127 broadcast.
Agreed but it is not easy for a hacker to determine CIDR masks. It
I'm sorry, but that's naive. Unless you've taken steps to prevent it, or you're just lucky, it's trivial to find out a lot of things. Your mail server, for example, has a mask of 0xFFFFFF00. Another network at ukans.edu apparently has a mask of 0xFFFFFC00, and another is 0xFFFFF800. :: Mike ::
Welcome to the NANOG mailing list, where North American Network OPerators hold deep weekly debates about the meaning of netmasks, prefixes, CIDR, and the format of IPv4 addresses. If the content of this list is even 20% indicative of the state of operation of the US/CA/MX/GT networks, it is an amazing testimony to the resilience of the internet. randy
Likewise, not all broadcast adresses necessarily end with .255, so filtering .255 won't help anyway in the presence of something like a /25 with a X.X.X.127 broadcast.
Agreed but it is not easy for a hacker to determine CIDR masks. It is my impression that the only thing being sent is classfull broadcasts.
That's unfortunatly not true. My hope is that this will change - I just sent CERT an advisory about this, and they're contacting several vendors whose equipment is misconfigured - but a very large number of systems out there will very cheerfully let you know their broadcast mask in violation of the Host Requirements RFC. It would take a bit more work to code a "smurf" program to first determine the broadcast mask, but since the smurf program uses hardcoded target addresses, all it would take is for someone to probe a few networks adequately, build them in to the next release of the smurf program, and start using it. I agree with the point of the discussion, however - many, many networks are broken in to /24s for various reasons, but blocking packets _outbound_ to what you presume are broadcast addresses is a bad thing. (Btw: If you feel the desire to _not_ let your netmasks hang out in the open, you can use an access list like: access-list blah deny icmp any any mask-request Most sites should have NO need to allow mask requests or replies in and out of their internal network). -Dave Andersen
On Fri, Sep 05, 1997 at 12:55:00PM -0800, Randy Bush wrote:
access-list XXX deny ip any 0.0.0.255 255.255.255.0
You must be kidding. Why not
access-list XXX deny ip any 0.0.0.42 255.255.255.0
In your usual, inimitable, "everyone ought to understand my comment" style, Randy. Because ".255" is very often (I'm tempted to say "almost always" a broadcast address, and ".42" never is. (I haven't run the numbers, but I'm fairly certain that .42 is not the broadcast address of any size network.) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
On Fri, 5 Sep 1997 16:11:48 -0400, "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us> said:
Jay> On Fri, Sep 05, 1997 at 12:55:00PM -0800, Randy Bush wrote:
access-list XXX deny ip any 0.0.0.255 255.255.255.0
You must be kidding. Why not
access-list XXX deny ip any 0.0.0.42 255.255.255.0
Jay> In your usual, inimitable, "everyone ought to understand my comment" Jay> style, Randy. Jay> Because ".255" is very often (I'm tempted to say "almost always" a Jay> broadcast address, and ".42" never is. (I haven't run the numbers, but Jay> I'm fairly certain that .42 is not the broadcast address of any size Jay> network.) But 42 is the ultimate answer to life, the Universe and Everything!
Randy Bush writes...
access-list XXX deny ip any 0.0.0.255 255.255.255.0
You must be kidding. Why not
access-list XXX deny ip any 0.0.0.42 255.255.255.0
I like... access-list XXX deny ip any 0.0.0.1 255.255.255.254 ...better. -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
If you are going to filter, you can just filter ICMP for now, thats the major protocol used in the attack, that way you are only slightly affecting those who might have a .255 address on one of their machines. so access-list xxx deny icmp any 0.0.0.255 255.255.255.0 and access-list xxx deny icmp any 0.0.0.0 255.255.255.0 are pretty safe ones. Oh yes, if you didn't notice already they are using the .0 network address, and from what i've seen the amount of attacks launched using .0 as compared to .255 have been steadily rising. And while turning off ip directed broadcast will mostly take care of this issue, it's only a complete solution if your customers also do it, so filtering is still a good idea IMHO. On Fri, 5 Sep 1997, Phil Howard wrote:
Randy Bush writes...
access-list XXX deny ip any 0.0.0.255 255.255.255.0
You must be kidding. Why not
access-list XXX deny ip any 0.0.0.42 255.255.255.0
I like...
access-list XXX deny ip any 0.0.0.1 255.255.255.254
...better.
-- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
Randy Bush writes...
access-list XXX deny ip any 0.0.0.255 255.255.255.0
You must be kidding. Why not
access-list XXX deny ip any 0.0.0.42 255.255.255.0
I like...
access-list XXX deny ip any 0.0.0.1 255.255.255.254
Okay... trying to access 10.10.10.1.. Oops.. The first example is okay if its "deny icmp" instead of "deny ip". That still allows traffic to reach those hosts, just doesn't let ICMP through. Although 255 is a valid IP address, its use is, in my view, limited. Denying ICMP packets to those hosts may be considered an acceptable sacrafice by many. ---------------------------------------------------------------------- Wayne Bouchard GlobalCenter web@primenet.com Primenet Network Engineering Internet Solutions for (602) 416-6422 800-373-2499 x6422 Growing Businesses FAX: (602) 416-9422 http://www.primenet.com http://www.globalcenter.net ----------------------------------------------------------------------
On Fri, 5 Sep 1997, Network Administrator wrote:
The following network numbers were pulled from a program called "smurf".
As I feared would happen, there seem to be multiple versions of smurf out with different amplifier network lists. FDT was smurfed for about an hour last night, and of the list of broadcast addresses posted very few were used in last night's attack...and a large number of the nets used were not in the posted list. Some of the more heavily populated (and thus nastier) amplification nets used last night follow. If you're on this list, PLEASE FIX YOUR ROUTERS. If you're using Cisco's, its probably as simple as adding "no ip directed-broadcast" to the ethernet interfaces on your routers. Also, what's the deal with Internic allowing registrations with things like nomailbox@NOWHERE? That's an incredibly useful contact. If Kent Percival is in charge of a university's network, surely he has an email address. Maybe it's time for a smurf amplifier blackhole list. If you're used as a smurf amplifier, you get BGP blackholed for say 6 hours, and on each subsequent occurance, the time doubles. I bet that would fix the problem real fast. [85 hosts responding] SURAnet (NET-MAE-EAST) 8400 Baltimore Boulevard College Park, MD 20740 Netname: MAE-EAST Netnumber: 192.41.177.0 Coordinator: SURAnet (SURA-NOC) noc@sura.net hostmaster@sura.net (301) 982-3214 [24 hosts responding] CNet (NETBLK-NETBLK-CNET) 150 Chestnut Street San Francisco, CA 94111 US Netname: NETBLK-CNET Netblock: 204.162.80.0 - 204.162.87.0 Maintainer: RGN Coordinator: Emery, Ken (KE53) ken@CNET.COM (415) 395-7805 x569 [32 hosts responding] Internet Communications of America (NETBLK-UU-208-202-14) 1020 N.W. 163rd Drive Miami, FL 33169 US Netname: UU-208-202-14 Netblock: 208.202.14.0 - 208.202.15.255 Coordinator: Neptune, Mark (MN182) postmaster@ICANET.NET 305-621-9200 [21 hosts responding] LI Net Inc. (NET-LI-NET) 45 Manor Rd. Smithtown, NY 11787 US Netname: LI-NET Netnumber: 199.171.6.0 Maintainer: LI Coordinator: Reilly, Michael (MR113) mpr@LI.NET 516-265-0997 Alternate Contact: Harris, Jon (JH201) jon@LI.NET 516-265-0997 [29 hosts responding] University of Guelph (NET-UOGUELPH) Guelph, Ontario, N1G 2W1 CANADA Netname: UOGUELPH Netnumber: 131.104.0.0 Coordinator: Percival, Kent (KP50) nomailbox@NOWHERE +1 (519) 824-4120 ext. 6397 ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
participants (15)
-
Dave Andersen -
Dave Bergum -
DAVE NORDLUND -
David Papp -
Jay R. Ashworth -
Jon Green -
Jon Lewis -
Jordyn A. Buchanan -
Michael K. Sanders -
Network Administrator -
Phil Howard -
Randy Bush -
Rick Summerhill -
Steve Noble -
Wayne Bouchard