| Posting it here weekly only provides a mechanism for the littele fsckers | that smurf to gain an up to date list of sites to bounce from. And consequently increases the liklihood that more networks will refuse traffic to or from these networks, which in turn increases the pressure on these sites to wonder what is happening to their connectivity and how to repair it. Which may just solve the problem. This is a monumental admission: I think Karl is doing the right thing. Sean.
At 2:31 PM -0700 4/11/98, Sean M. Doran wrote:
And consequently increases the liklihood that more networks will refuse traffic to or from these networks, which in turn increases the pressure on these sites to wonder what is happening to their connectivity and how to repair it. Which may just solve the problem.
This is a monumental admission: I think Karl is doing the right thing.
Sean.
and i totally agree. from my perspective, most of the damage has come to irc servers, but it is also being used as a personal DoS, and i've heard rumors of attacks on webservers, etc. craig has done a very admirable thing writing the paper on smurf and it's udp cousin, and making the url available to all who are willing to hear it. those who ARE willing and HAVE heard it have already fixed their routers. now we are dealing with the ones that either don't know any better or don't care. if they start getting treated like the spammers, maybe they will wake up and fix it. i hope others follow karl in his lead. we all know that this won't be FIXED til essentially every network in the world is patched. the free time for fixing it is over. now it is time for there to be some consequences if one will not fix. melinda b thompson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ life is a constant stream of people coming into and out of your life... sometimes you get to grab hold of one or two of them for a while... ima@badhabit.org http://www.ircd.com/meldatlist.html PGP Fingerprint: 5E9F 31EF DF11 A3EF F3E4 CB3C 9F42 2EC8 BCD0 C607 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On Sat, 11 Apr 1998, Sean M. Doran wrote:
This is a monumental admission: I think Karl is doing the right thing.
However there are a couple of minor flaws that could be fixed. One is to sort the list by IP address to make it easier for folks to scan through and see if they recognize any addresses of companies that they have some contact with. Even better would be to include the netblock names from whois.arin.net. And the other is to include the URL of a website that explains how to fix the problem. This makes it a whole lot easier to explain to people. P.S. maybe there is a 3rd flaw.... Maybe the list should be posted to alt.2600 as well? >:-> -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
On Sat, 11 Apr 1998, Michael Dillon wrote:
On Sat, 11 Apr 1998, Sean M. Doran wrote:
This is a monumental admission: I think Karl is doing the right thing.
However there are a couple of minor flaws that could be fixed.
One is to sort the list by IP address to make it easier for folks to scan through and see if they recognize any addresses of companies that they have some contact with. Even better would be to include the netblock names from whois.arin.net.
And the other is to include the URL of a website that explains how to fix the problem. This makes it a whole lot easier to explain to people.
P.S. maybe there is a 3rd flaw.... Maybe the list should be posted to alt.2600 as well? >:->
Another problem. Say I (and others) use this list. How do I know when the perpetrators fix it? They may contact Karl. Karl may or may not keep the blacklist alive on nanog 2 years from now. Bad sites gone good are still blocked from my site. Is there a easy way to independently verify if it's been fixed? Even better if someone kept a central list with accountability. Perhaps you could pay for verified updated access-lists.. prevent SMURF attacks, emergency DoS attack swat teams for hire, etc.. a 1-2 man consulting operation. Stb
In message <Pine.LNX.3.95.980411203415.26653D-100000@bisco.clark.net>, Stephen Balbach writes:
On Sat, 11 Apr 1998, Michael Dillon wrote:
On Sat, 11 Apr 1998, Sean M. Doran wrote:
This is a monumental admission: I think Karl is doing the right thing.
However there are a couple of minor flaws that could be fixed.
One is to sort the list by IP address to make it easier for folks to scan through and see if they recognize any addresses of companies that they have some contact with. Even better would be to include the netblock names from whois.arin.net.
And the other is to include the URL of a website that explains how to fix the problem. This makes it a whole lot easier to explain to people.
P.S. maybe there is a 3rd flaw.... Maybe the list should be posted to alt.2600 as well? >:->
Another problem. Say I (and others) use this list. How do I know when the perpetrators fix it? They may contact Karl. Karl may or may not keep the blacklist alive on nanog 2 years from now. Bad sites gone good are still blocked from my site. Is there a easy way to independently verify if it's been fixed?
Uh, ping the broadcast address?
Even better if someone kept a central list with accountability. Perhaps you could pay for verified updated access-lists.. prevent SMURF attacks, emergency DoS attack swat teams for hire, etc.. a 1-2 man consulting operation.
I think this is a bad idea and has been run into the ground previously. --- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 512-458-9810 http://www.fc.net
Heh - since Carl has wasted alot of his time providing a brief list of sites that he has identified as smurf amplifiers, - and since you brought up a very good point of creating a more "searchab;e" list with perhaps some contact information - why don't you apply the needed changes (as you see the need) - I think Carl has done enough - and i bet whois.arin.net works just as well for you... just a thought mind you On Sat, 11 Apr 1998, Michael Dillon wrote:
On Sat, 11 Apr 1998, Sean M. Doran wrote:
This is a monumental admission: I think Karl is doing the right thing.
However there are a couple of minor flaws that could be fixed.
One is to sort the list by IP address to make it easier for folks to scan through and see if they recognize any addresses of companies that they have some contact with. Even better would be to include the netblock names from whois.arin.net.
And the other is to include the URL of a website that explains how to fix the problem. This makes it a whole lot easier to explain to people.
P.S. maybe there is a 3rd flaw.... Maybe the list should be posted to alt.2600 as well? >:->
-- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
-- I am nothing if not net-Q! - ras@poppa.clubrich.tiac.net
On Sat, 11 Apr 1998, Sean M. Doran wrote:
And consequently increases the liklihood that more networks will refuse traffic to or from these networks, which in turn increases the pressure on these sites to wonder what is happening to their connectivity and how to repair it. Which may just solve the problem.
This is a monumental admission: I think Karl is doing the right thing.
Would the vix people have any interest in just adding "being a smurf amp" to the possible causes for entry in the BGP version of RBL? That way, it would be harder for the smurf d00dz to get up to date lists. I suggested this sort of thing a while ago, but don't currently have time to implement it. The vix people already have everything in place. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | http://noagent.com/?jl1 for cheap Network Administrator | life insurance over the net. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
Would the vix people have any interest in just adding "being a smurf amp" to the possible causes for entry in the BGP version of RBL? That way, it would be harder for the smurf d00dz to get up to date lists.
Sadly, no. The existing RBL has a great deal of strength (measured by the number of people who subscribe to it) but that strength comes primarily due to the limited focus of the weapon. We're about mail abuse. Mail abuse is something that everybody can understand and everybody agrees is a bad thing. SMURF amplification is something that not everybody can understand and so not everybody agrees that it's a bad thing. I would ordinarily be willing to set up a second RBL-like feed, which due to the nature of the attacks (SMURF vs SPAM) would only be available via BGP (denying only mail transport from or to a SMURF amplifier network seems like a round hole / square peg kind of thing), but I simply do not have the time or money or people to do it. MAPS is an unfunded activity (with the notable exception of donations from a few of you on NANOG) and I think we ought to try to do a better job stopping SPAM before we try to use some of the same overworked volunteers to take on something like SMURF amplifiers.
I suggested this sort of thing a while ago, but don't currently have time to implement it. The vix people already have everything in place.
Perhaps we should just start a company called "@net.police"? :-) x 1000.
On Sat, 11 Apr 1998, Paul A Vixie wrote:
Perhaps we should just start a company called "@net.police"? :-) x 1000.
Why should net policing be centralized. Wouldn't it be better if we had 1000 different net police groups all focussed on one specific problem. Like the RBL, perhaps ;-) -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
Hurray for Karl! Dirk On Sat, Apr 11, 1998 at 02:31:22PM -0700, Sean M. Doran wrote:
| Posting it here weekly only provides a mechanism for the littele fsckers | that smurf to gain an up to date list of sites to bounce from.
And consequently increases the liklihood that more networks will refuse traffic to or from these networks, which in turn increases the pressure on these sites to wonder what is happening to their connectivity and how to repair it. Which may just solve the problem.
This is a monumental admission: I think Karl is doing the right thing.
Sean.
On Sat, Apr 11, 1998 at 02:31:22PM -0700, Sean M. Doran wrote:
| Posting it here weekly only provides a mechanism for the littele fsckers | that smurf to gain an up to date list of sites to bounce from.
And consequently increases the liklihood that more networks will refuse traffic to or from these networks, which in turn increases the pressure on these sites to wonder what is happening to their connectivity and how to repair it. Which may just solve the problem.
This is a monumental admission: I think Karl is doing the right thing.
Sean.
Correct. Note that the way you GET ON THIS LIST is to have BEEN a smurf amplifier. That is, not a "suspected" one, not one we probed, but a PROVEN source of a smurf amplification. And guess how I know that? I'll tell you - one or more of our customer or internal machines was rendered useless until I identified and blocked EACH of the networks on the list. That is, all of these are PROVEN guilty, not suspected guilty. This also means that any claim that I'm "helping the bad guys" is baloney - the bad guys, by definition, ALREADY USED THESE NETWORKS to hit us or one of our customers - that's how they got on the list in the first place! The only effective means I have to stop this is to start refusing transit to packets with a source address in the amplifier network(s). Our core circuits can handle even a dedicated smurfer - there are few who can hit us with enough punch to melt our core circuits (multiple DS3s are like that). Our customers, most of whom are on T1s, aren't so lucky - they can be rendered disconnected quite easily, as can an internal machine on a 10Mbps switched port. Blocking these at ingress to our core is enough; not only do we stay operational with minimal impact, but the intended target suffers no ill effects - and as a consequence, the people doing this move on to more "juicy" targets where they can actually cause some damage. If any significant number of providers start blocking these networks, the people who own them will have to fix the configuration problems if they want to continue to be able to talk to the Internet as a whole. THAT is the intent of the blacklisting around here. Our NOC crew has been instructed that any complaint from these address ranges is to be referred directly to me, and that the standard answer is "you're a smurf amplifier and while Karl will talk to you, if you're calling for any purpose other than to tell us that you've fixed it you're wasting your dimes". -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
On Sat, Apr 11, 1998 at 02:31:22PM -0700, Sean M. Doran wrote:
And consequently increases the liklihood that more networks will refuse traffic to or from these networks, which in turn increases the pressure on these sites to wonder what is happening to their connectivity and how to repair it. Which may just solve the problem.
This is a monumental admission: I think Karl is doing the right thing.
Concur. Anyone want to write a script to back-whois the network contacts, and set up a web page? I'd do it, but the webserver isn't mine. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
Ok, I'll offer web hosting for it, and BGP feed (using gated). What domain name? smurfpolice.net isn't taken. --Dean
This is a monumental admission: I think Karl is doing the right thing.
Concur.
Anyone want to write a script to back-whois the network contacts, and set up a web page? I'd do it, but the webserver isn't mine.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Uh, a BGP feed doesn't do you any good folks. You want to block INGRESS, not outbound packet flow. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Mon, Apr 13, 1998 at 06:46:32PM -0400, Dean Anderson wrote:
Ok, I'll offer web hosting for it, and BGP feed (using gated). What domain name? smurfpolice.net isn't taken.
--Dean
This is a monumental admission: I think Karl is doing the right thing.
Concur.
Anyone want to write a script to back-whois the network contacts, and set up a web page? I'd do it, but the webserver isn't mine.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Uh, a BGP feed doesn't do you any good folks. You want to block INGRESS, not outbound packet flow.
I thought I heard BGP mentioned about 25 messages back as a means to put more pressure on these networks, by shutting off connectivity to them. It is also a means to distribute throttling to others during a smurf attack, say if someone upstream has the feed. I can see that using it might create more problems, but its also a decision that can be made by the network provider. I'll just offer a site to run the gated and coordinate changes. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Karl Denninger wrote:
Uh, a BGP feed doesn't do you any good folks. You want to block INGRESS, not outbound packet flow.
Uh. Just modify BGP routes from that feed to have a next hop pointing to a black hole. route-maps are sometimes useful. --vadim
On Mon, Apr 13, 1998 at 05:43:33PM -0700, Vadim Antonov wrote:
Karl Denninger wrote:
Uh, a BGP feed doesn't do you any good folks. You want to block INGRESS, not outbound packet flow.
Uh. Just modify BGP routes from that feed to have a next hop pointing to a black hole. route-maps are sometimes useful.
--vadim
Hmmm.. that would work :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
i suspect that they're discussing blocking inbound packets from faked sources of smurf attacks. in this case, protection from outbound routing info is too late. once the smurf packets gets in your local net, you've been smurfed. of course, the idea of blocking smurf spoof sites is pretty specious. how many folk will go through the effort and burden on the routers to put an access list in the packet path and yet not be clueful enough to just say 'no ip directed-broadcast' on the same damn edge router insead? wait a sec. on second thought, don't answer that question. randy
of course, the idea of blocking smurf spoof sites is pretty specious. how many folk will go through the effort and burden on the routers to put an access list in the packet path and yet not be clueful enough to just say 'no ip directed-broadcast' on the same damn edge router insead?
the same ones that'll spend an entire day discussing it.
wait a sec. on second thought, don't answer that question.
and the ones who never read directions until its too late. -- Jason Weisberger Chief of Network Operations SoftAware, Inc. - 310/305-0275 "You may be whatever you resolve to be." -Thomas Jonathan "Stonewall" Jackson
You right that all BGP would do is block traffic to that network. But it does block *all* traffic to that network. Once the attack is started, it must either be stopped at the source, or by inbound packet filters. Not that I'm defending it as completely effective method, but presumably some of the customers of the smurfable network have the off-hours access numbers to the noc of the smurfing network, once they notice their connectivity to elsewhere is lost. Adding a route to a route filter at a high enough level ought to get some quick attention from the smurfing network operator. Especially if its their upstream that blocked them. Things actually break for them, as opposed to just higher network load. It also prevents your own disgruntled users from launching a smurf attack against other users on your net, since they won't be able to reach those networks. At least, not from your machines. Also, it will prevent a person from launching an attack if someone is filtering between them and the network. And it has the advantage of being automatically updated, once a change is made to the master list. And I think a route blackhole is probably faster than a permission list. Not positive, though. Anyway, I'll offer a site to host the list, and redistribute the list in hopefully convenient forms. Several people have already volunteered to help, so its up to you folks to ask for and/or implement convenient forms of distribution. Whether you want to block all ingress by hand, or just general connectivity by BGP or some other method is up to you. It is possible to do both, or neither. The important thing is to get a list and maintain it. I think we can dump the list into several different forms for distribution. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Mon, 13 Apr 1998, Vadim Antonov wrote:
Uh. Just modify BGP routes from that feed to have a next hop pointing to a black hole. route-maps are sometimes useful.
Could someone PLEASE explain to me how this is accomplished? Let's assume that you do use a route-map to set next hop to a null interface or a black hole or something for a prefix. AND set local pref appropriately so that route gets preferred. You now have a routing entry which essentially says: "forward packets DESTINED FOR the evil network to the black hole". What you really want is a routing entry which says: "forward packets FROM the evil network to the black hole". Now, if someone could enlighten me to a way which you can get BGP to make a routing/filter entry to do this second one, I'd be most grateful. BTW, I know you can do this with PERL or config scripts or whatever. The point is that I don't think that a RBL-like blackhole feed will fix a smurf attack from the "attacked" perspective, unless I have missed some knob somewhere. - Forrest W. Christian (forrestc@imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
:: Forrest W. Christian writes ::
On Mon, 13 Apr 1998, Vadim Antonov wrote:
Uh. Just modify BGP routes from that feed to have a next hop pointing to a black hole. route-maps are sometimes useful.
Could someone PLEASE explain to me how this is accomplished?
Let's clarify this: -- If you take the "black hole" feed, you probably route-map so that you end up forwarding packets to the black-hole'd addresses nowhere, instead of back towards "black-hole-route-server". This (1) In no way protects your network from being smurfed (unless you are being attacked by your customers), (2) Has a punitive impact on the amplifier networks, in that their customers can no longer get to whatever resources you offer (so their end-user customers get pissed), and you're customers can't visit sites at the amplifier networks (so their information/service provider customers get pissed). This may lead to the situation being corrected. (It may also lead to some of your customers being pissed.), (3) Prevents your customers from smurfing someone else via the black-holed amplifier networks (you may or may not care). -- You can use the information obtained from such a blackhole feed to protect your network, by creating access lists, or (why would you do it this way?) creating route maps that route to a black-hole based on source-address. This cannot be done automatically in a cisco router[1]. Something would have to alter the configuration based on the blackhole data received. This could be a human being. This could be automated code (running on something other than a Cisco router). (This also assumes that your connections to your peers/upstreams are large enough that they are not signifigantly impacted by the load of a smurf attack.) [1] Specifically, there is no configuration command to vary the contents of an access list based on received BGP routing information, which means there is no way to route-map with a "match" that adapts to information from BGP. I think that (1) Public shame is a good method of attack on this problem, and (2) A realtime BGP feed is probably a waste. - Brett (brettf@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com
The whole idea was to block attempts to make SMURF atatck originated from your network, and this case the black list of addresses to be blocked (it's the list of broadcast addresses used to amplify ICMP) joined with the logging such attempts is quite usefull.
Date: Mon, 13 Apr 1998 19:46:29 -0600 (MDT) From: Forrest W. Christian <forrestc@iMach.com> To: Vadim Antonov <avg@pluris.com> Cc: Karl Denninger <karl@mcs.net>, Dean Anderson <dean@av8.com>, "Jay R. Ashworth" <jra@scfn.thpl.lib.fl.us>, nanog@merit.edu Subject: Re: SMURF amplifier block list
On Mon, 13 Apr 1998, Vadim Antonov wrote:
Uh. Just modify BGP routes from that feed to have a next hop pointing to a black hole. route-maps are sometimes useful.
Could someone PLEASE explain to me how this is accomplished? ....
On Tue, 14 Apr 1998, Alex P. Rudnev wrote:
The whole idea was to block attempts to make SMURF atatck originated from your network, and this case the black list of addresses to be blocked (it's the list of broadcast addresses used to amplify ICMP) joined with the logging such attempts is quite usefull.
Ok, this I may agree with. However, I contend that with appropriately configured filters along your customer borders, that an attack wouldn't be possible by a customer except to attack himself or another address which matches the hole in the source address filter for the customer -> net direction. Hopefully those holes are as small as possible. On another note, could someone please mention again which IOS has the cool "drop all packets from an interface which we don't have a matching route pointing the other direction" feature? - Forrest W. Christian (forrestc@imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
On the contrary; while it won't have the effect of ingress filters, it will prevent downstreams of anyone receiving the feed from USING those smurf sites, and it will disrupt connectivity to them in general. If enough people adopted the feed, it would have a reasonable effect. Then again, filtering any packets to or from x.x.x.255 would have a similar but more profound effect. Anyone who actually uses a .255 address for a host is asking for trouble anyways. Stephen Karl Denninger wrote:
Uh, a BGP feed doesn't do you any good folks. You want to block INGRESS, not outbound packet flow.
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
On Mon, 13 Apr 1998, Stephen Sprunk wrote:
Then again, filtering any packets to or from x.x.x.255 would have a similar but more profound effect. Anyone who actually uses a .255 address for a host is asking for trouble anyways.
the problem with that thinking, of course, is going to crop up when you encounter /23's and greater. -- Aaron
On Tue, Apr 14, 1998 at 08:49:04AM -0700, Aaron Beck wrote:
On Mon, 13 Apr 1998, Stephen Sprunk wrote:
Then again, filtering any packets to or from x.x.x.255 would have a similar but more profound effect. Anyone who actually uses a .255 address for a host is asking for trouble anyways.
the problem with that thinking, of course, is going to crop up when you encounter /23's and greater.
-- Aaron
Not often. Few people are actually supernetting within a given broadcast domain. There's still an awful lot of hardware that doesn't work right in that environment. The larger problem is that subnetted /24s still are wide open. This kind of filter won't block anything from their broadcast addresses, since they're not the .255 address. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
In message <19980414111503.06128@mcs.net>, you wrote:
Not often. Few people are actually supernetting within a given broadcast domain. There's still an awful lot of hardware that doesn't work right in that environment.
But subnets of class B's may be larger than /24 and have host numbers of .255 and .0 in them. That's true all over this campus. It may be reasonable to filter x.x.x.255 addresses from class C's or /24 blocks, but you cannot filter all addresses that end in .255 without filtering out a number of completely legitimate hosts.
The larger problem is that subnetted /24s still are wide open. This kind of filter won't block anything from their broadcast addresses, since they're not the .255 address.
Indeed yes! There are also many subnets smaller than /24 where the broadcast address does not end in .255 that would still be open for smurfing even in the presence of this .255 filter. The x.x.x.255 filter is an extremely bad idea. /cvk
Just because the host addresses are theoretically valid doesn't mean that using them is a good idea. Those two addresses constitute less than 1% of a network's addresses, and are very simple to configure out of your DHCP servers, etc. Again, the likelihood that these addresses will cause problems or experience connectivity issues is a far greater concern than the gain of less than 1% of usable address space. Sorry Charley :) Stephen Charley Kline wrote:
But subnets of class B's may be larger than /24 and have host numbers of .255 and .0 in them. That's true all over this campus.
It may be reasonable to filter x.x.x.255 addresses from class C's or /24 blocks, but you cannot filter all addresses that end in .255 without filtering out a number of completely legitimate hosts.
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
Are we really concerned about being smurfed by a /30, or even a /27? The essential problem is backbone class-C's, especially those in NAPs where coordination is nearly impossible. Smaller subnets tend to be in small ISPs' or customers' networks, which don't pose a threat since they lack the bandwidth for an effective attack. Stephen Karl Denninger wrote:
The larger problem is that subnetted /24s still are wide open. This kind of filter won't block anything from their broadcast addresses, since they're not the .255 address.
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
Good point. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Tue, Apr 14, 1998 at 03:25:34PM -0500, Stephen Sprunk wrote:
Are we really concerned about being smurfed by a /30, or even a /27?
The essential problem is backbone class-C's, especially those in NAPs where coordination is nearly impossible. Smaller subnets tend to be in small ISPs' or customers' networks, which don't pose a threat since they lack the bandwidth for an effective attack.
Stephen
Karl Denninger wrote:
The larger problem is that subnetted /24s still are wide open. This kind of filter won't block anything from their broadcast addresses, since they're not the .255 address.
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
On Tue, 14 Apr 1998, Stephen Sprunk wrote:
Are we really concerned about being smurfed by a /30, or even a /27?
The essential problem is backbone class-C's, especially those in NAPs where coordination is nearly impossible. Smaller subnets tend to be in small ISPs' or customers' networks, which don't pose a threat since they lack the bandwidth for an effective attack.
Im kind of under the impression that we're (ok, just me, but anyone else is welcome to jump on this bandwagon) trying to point out that class based thinking.. or even "well, most of the net is this" thinking is probably a bad idea. Kludges n' hacks may work most of the time, but kludges and hacks are just that.. kludgey and hackish. Hard coded defines, precompiled bins, etc have proven to be a less elegant method in other areas of the computing world... why should we repeat the same kind of mistake in the networking field? A smurf attack is just that, a smurf attack. Wouldnt the overall goal include removing the attack possibility in its entirety, not just a temporary solution that may solve some of the problems, but definetly not all of them? Assuming that most of the net is based on /24s, and that smaller subnets are generally internal to those /24's may be a safe assumption, but once again its probably not the best way to think about this problem (not that I have any hints on what the best way should be, but im fairly certain that applying a stereotypical ideology to this is "not a good thing"). just my two bits and a lot of run on sentences. -- Aaron
Aaron Beck wrote:
Im kind of under the impression that we're (ok, just me, but anyone else is welcome to jump on this bandwagon) trying to point out that class based thinking.. or even "well, most of the net is this" thinking is probably a bad idea.
The fact is that a /24 is far more dangerous as a smurf amplifier than a /30. Simple math tells you that there's 127 times as many possible hosts hitting you.
Kludges n' hacks may work most of the time, but kludges and hacks are just that.. kludgey and hackish. Hard coded defines, precompiled bins, etc have proven to be a less elegant method in other areas of the computing world... why should we repeat the same kind of mistake in the networking field?
Who suggested putting a x.x.x.255 filter into IOS itself? An access-list in a config is hardly hard-coding.
A smurf attack is just that, a smurf attack. Wouldnt the overall goal include removing the attack possibility in its entirety, not just a temporary solution that may solve some of the problems, but definetly not all of them?
If you have a suggestion for "removing the attack possibility in its entirety," please tell us. So far, nobody's come up with one. In the meantime, I'd rather solve 99% of the problem and deal with the remaining 1% than sit around arguing about "class based thinking" and "stereotypical ideologies" in between smurf attacks.
Assuming that most of the net is based on /24s, and that smaller subnets are generally internal to those /24's may be a safe assumption, but once again its probably not the best way to think about this problem (not that I have any hints on what the best way should be, but im fairly certain that applying a stereotypical ideology to this is "not a good thing").
Look at the list of IP addresses used in any smurf attack, and they will almost always be class C or class B broadcast addresses, usually the address of a NAP or well-connected ISP. There's no sense targeting a solution for a problem which doesn't exist. Solve the general case and buy time for the more specialized ones.
just my two bits and a lot of run on sentences.
Stephen -- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
Uh, folks, blocking the broadcast address will NOT help you in the case of a smurf POUNDING ON YOU. It will ONLY prevent your customers launching a smurf against someone ELSE. A FAR more effective means of doing THAT is to prohibit source address forgery on your connections. What a smurf does is this: 1) The SMURFER sends a FORGED packet to the amplifier. It is: source destination type victim-addr amplifier-broadcast ICMP ECHO Example: 192.160.127.97 xxx.yyy.zzz.255 ICMP ECHO The amplifier NETWORK ENTRANCE ROUTER, IF it accepts directed broadcasts, will route this to the broadcast address of the shared media network (ie: CSMA/CD FastEthernet). ALL the devices on that network respond to the victim's address. The reason this works is because (1) you don't need to be able to get replies back from the real source (since the source is forged anyway) and (2) the ICMP echo will be replied to (its a ping, silly). Now, what you do is use a LARGE packet size - say, 1Kb. So I send one packet over my ISDN line, and the amplifier sends 200 copies of it to the victim. I can effectively multiply the bandwidth of my 128kbps circuit 200-fold, which is TWENTY FIVE MEGABITS of bandwidth (!) Now, since I am smart, I use an ICMP ECHO with a payload of all zeros. STAC compresses this 1024-byte packet about 10:1, since its all one byte. I can now source ~90Mbps from an ISDN connection! This makes even a modem dial connection quite dangerous in that with compression and careful selection of the payload you can source ~10-20Mbps of smurf from a MODEM. A T1 connected person launching a smurf can burn down an OC-12 if they can find amplifiers with enough outbound capacity. Now, what are the problems for the person trying to prevent this from melting their network and/or their customers? 1. If you can't actually accept and process the inbound traffic, you're dead. Period. This means that a small ISP, say one connected by a couple of T1s, can't defend against a Smurf. They MUST go to their upstream provider and have THEM defend against it. 2. If you CAN accept the traffic, then you have several defenses. But some of them won't work. The ones which don't work include: a) Blocking traffic from broadcast addresses - none of the smurf traffic will be from a broadcast address. b) Blocking OUTBOUND traffic - the problem isn't outbound, 3. The only EFFECTIVE defense is to block ALL addresses within any netblock which is identified as being a smurf amplifier to ANY inbound traffic. You want to place this filter on your INBOUND links from other providers and exchanges. That is, if you peer with someone over a HSSI line, or buy transit over a HSSI line, you want the filter to be: inter h 1/0 ip access-group xxx in where the "access-group xxx" list contains things like: access-group 2 deny 128.0.0.0 0.0.255.255 ..... access-group 2 permit all DO NOT use extended access lists. They are wasteful in that they force more comparisons that are needed, and may cause you to degenerate into process switching at your borders (which will murder your CPU utilization). 4. By doing (3), you do not prevent the traffic from touching you; you will absorb it instead. To keep the traffic off you entirely, you need to have your *UPSTREAM* providers place the same filter on the OUTBOUND side of the interface that points towards your network. Good luck getting a *PEER* to do this - you might be able to get a *TRANSIT* provider to do it if you bitch loudly enough. 5. However, providing that you have the bandwidth on your interconnects and/or transit connections to absorb the smurfs without knocking you out, (3) is effective. It keeps your machines up, and it keeps your T1 and slower connected customers from being smurfed off the network. The *ONLY* long-term fix for smurfing is to prohibit directed broadcasts, so that amplification of the attack cannot be done. The only means available for prohibiting anything on the Internet is "shunning", much as it is with spammers. Therefore, the only way to force people to correctly configure their routers so smurfs won't work is to snub them and implement (3), either in your network or at your upstream connection's network. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Tue, Apr 14, 1998 at 04:37:20PM -0500, Stephen Sprunk wrote:
Aaron Beck wrote:
Im kind of under the impression that we're (ok, just me, but anyone else is welcome to jump on this bandwagon) trying to point out that class based thinking.. or even "well, most of the net is this" thinking is probably a bad idea.
The fact is that a /24 is far more dangerous as a smurf amplifier than a /30. Simple math tells you that there's 127 times as many possible hosts hitting you.
Kludges n' hacks may work most of the time, but kludges and hacks are just that.. kludgey and hackish. Hard coded defines, precompiled bins, etc have proven to be a less elegant method in other areas of the computing world... why should we repeat the same kind of mistake in the networking field?
Who suggested putting a x.x.x.255 filter into IOS itself? An access-list in a config is hardly hard-coding.
A smurf attack is just that, a smurf attack. Wouldnt the overall goal include removing the attack possibility in its entirety, not just a temporary solution that may solve some of the problems, but definetly not all of them?
If you have a suggestion for "removing the attack possibility in its entirety," please tell us. So far, nobody's come up with one.
In the meantime, I'd rather solve 99% of the problem and deal with the remaining 1% than sit around arguing about "class based thinking" and "stereotypical ideologies" in between smurf attacks.
Assuming that most of the net is based on /24s, and that smaller subnets are generally internal to those /24's may be a safe assumption, but once again its probably not the best way to think about this problem (not that I have any hints on what the best way should be, but im fairly certain that applying a stereotypical ideology to this is "not a good thing").
Look at the list of IP addresses used in any smurf attack, and they will almost always be class C or class B broadcast addresses, usually the address of a NAP or well-connected ISP. There's no sense targeting a solution for a problem which doesn't exist. Solve the general case and buy time for the more specialized ones.
just my two bits and a lot of run on sentences.
Stephen
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
On Tue, Apr 14, 1998 at 05:22:42PM -0500, Karl Denninger wrote:
Uh, folks, blocking the broadcast address will NOT help you in the case of a smurf POUNDING ON YOU. It will ONLY prevent your customers launching a smurf against someone ELSE. A FAR more effective means of doing THAT is to prohibit source address forgery on your connections.
Um, Karl? That's not what we were talking about. What we were talking about was forbidding external connections to the class-C broadcast addresses on a net, and why that useful process made addressing hosts on .255 boundaries A Bad Idea. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
Karl Denninger writes:
A T1 connected person launching a smurf can burn down an OC-12 if they can find amplifiers with enough outbound capacity.
Which is to say a dozen well connected DS-3 networks -- not that hard to find at all. Thankfully that number seems to be dwindling rapidly. This will eventually degenerate to attackers searching for many dozens of DS-1 networks that are open, so small providers/customers should be educated as well.
The *ONLY* long-term fix for smurfing is to prohibit directed broadcasts,
I believe it has to include ingress source address validation. The overall problem remains, getting others to deny spoofing and directed broadcast responses can only be done though communication -- and sometimes excommunication is all that can be heard.
On Tue, 14 Apr 1998, Mark Milhollan wrote:
The overall problem remains, getting others to deny spoofing and directed broadcast responses can only be done though communication --
I just submitted my weekly column to Internet World a couple of days ago on just this topic. It will appear on Monday I believe. I believe in communication ;-) -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
On Tue, 14 Apr 1998, Karl Denninger wrote:
So I send one packet over my ISDN line, and the amplifier sends 200 copies of it to the victim. I can effectively multiply the bandwidth of my 128kbps circuit 200-fold, which is TWENTY FIVE MEGABITS of bandwidth (!)
Now, since I am smart, I use an ICMP ECHO with a payload of all zeros. STAC compresses this 1024-byte packet about 10:1, since its all one byte. I can now source ~90Mbps from an ISDN connection! This makes even a modem dial connection quite dangerous in that with compression and careful selection of the payload you can source ~10-20Mbps of smurf from a MODEM.
This isn't quite as bad as it sounds, because in nearly all cases, the *OUTGOING* bandwidth from the amplification network will be *MUCH* less then the aggregate traffic produced by all the devices on the amplification LAN. So what ends up happening in most cases, is that 20-90Mpbs of traffic slams into the router interface capable of only 1.5/3/6/9Mbps of outgoing traffic. Still, though a modem or ISDN connection being able to summon 1.5-9Mpbs is quite a problem.
The *ONLY* long-term fix for smurfing is to prohibit directed broadcasts, so that amplification of the attack cannot be done. The only means available
This is not the *ONLY* long-term fix. There has been very little mention of anti-SPOOF measures in this thread which is surprising. Granted, blocking directed broadcasts from entering your network prevents you from being the "mid-point" of the attack. The fact is that the SMURF attack couldn't even get off the ground if the ISP for the "evil d00d" validated *OUTGOING* traffic, effectively blocking IP SPOOFing. I would say that the scope of the IP SPOOFing problem is greater then any other problem. IP SPOOFing is *THE SOURCE* of all the major problems: SYN-FLOOD TEARDROP and variants SMURF What's Next??? Solutions: Validate all traffic leaving your networks to be sure the IP source is from one of your networks. Everyone from the tier 1 providers on down should write that requirement into all their connection agreements. Further, the fact is that nearly *ALL* such attacks (attacks that use IP-SPOOFing as a requirement) are launched from dial-up connections. If would be relatively easy to have a *DRAMATIC* reduction in attacks if the dialup equipment vendors would release software updates with *DEFAULT* anti-spoof filters applied to dialup connections. Put some pressure on your vendors, nearly all dialup ports are made by either Lucent/Livingston, Ascend, and 3COM/USR. I've been asking Livingston for two years for this feature. Dax Kelson Internet Connect, Inc.
On Wed, Apr 15, 1998 at 01:04:19PM -0600, Dax Kelson wrote:
This isn't quite as bad as it sounds, because in nearly all cases, the *OUTGOING* bandwidth from the amplification network will be *MUCH* less then the aggregate traffic produced by all the devices on the amplification LAN.
So what ends up happening in most cases, is that 20-90Mpbs of traffic slams into the router interface capable of only 1.5/3/6/9Mbps of outgoing traffic. Still, though a modem or ISDN connection being able to summon 1.5-9Mpbs is quite a problem.
Well, most of the real "problem" smurf sites are DS-3 connected or better. The little ones don't bother us.
There has been very little mention of anti-SPOOF measures in this thread which is surprising.
Try to get people to do that.... we have, its pointless.
IP SPOOFing is *THE SOURCE* of all the major problems:
SYN-FLOOD TEARDROP and variants SMURF What's Next???
Solutions:
Validate all traffic leaving your networks to be sure the IP source is from one of your networks.
Everyone from the tier 1 providers on down should write that requirement into all their connection agreements.
Further, the fact is that nearly *ALL* such attacks (attacks that use IP-SPOOFing as a requirement) are launched from dial-up connections.
If would be relatively easy to have a *DRAMATIC* reduction in attacks if the dialup equipment vendors would release software updates with *DEFAULT* anti-spoof filters applied to dialup connections.
Put some pressure on your vendors, nearly all dialup ports are made by either Lucent/Livingston, Ascend, and 3COM/USR.
I've been asking Livingston for two years for this feature.
Dax Kelson Internet Connect, Inc.
Yeah, well, why not find a way to ram it down UUNET, SPRINT, MCI's, and the rest of the national's throats first? We already do this - its not a perfect filter, but it will only let you transmit packets with sources that COULD possibly come from us. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
Karl Denninger said once upon a time:
We already do this - its not a perfect filter, but it will only let you transmit packets with sources that COULD possibly come from us.
The puzzling thing is why anyone would want to transmit packets over their for-cost links with an address that wasn't from their network. Proper filters have other benefits aside from the obvious attack issues.
On Wed, Apr 15, 1998 at 01:52:43PM -0600, Pete Ashdown wrote:
Karl Denninger said once upon a time:
We already do this - its not a perfect filter, but it will only let you transmit packets with sources that COULD possibly come from us.
The puzzling thing is why anyone would want to transmit packets over their for-cost links with an address that wasn't from their network. Proper filters have other benefits aside from the obvious attack issues.
To create havoc on other people's networks? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
Karl Denninger said once upon a time:
On Wed, Apr 15, 1998 at 01:52:43PM -0600, Pete Ashdown wrote:
Karl Denninger said once upon a time:
We already do this - its not a perfect filter, but it will only let you transmit packets with sources that COULD possibly come from us.
The puzzling thing is why anyone would want to transmit packets over their for-cost links with an address that wasn't from their network. Proper filters have other benefits aside from the obvious attack issues.
To create havoc on other people's networks?
"aside from the obvious attack issues" I'm speaking from the admin's standpoint and not the perps. There is more than one benefit to using proper filters. Most people look at them as just a security problem, and not their problem at that.
Sorry for yet another Smurf amplifier posting, but this looks like a useful site. It's called the Smurf Amplifier Registry. Has a cgi to probe suspected netblocks and if they meet the criteria, are added to the list of known amplifiers. The listing can be output in either a plaintext format or cisco acl format. The site is at: http://www.powertech.no/smurf/ -Chris -- \\\|||/// \ Chris Parker: Systems Administration and Development \ ~ ~ / \ cparker@starnetusa.net \ cparker@megapop.net | @ @ | \ www.starnetusa.net \ www.megapop.net oOo---(_)---oOo--\------------------------------------------------------ \ Without C we would have 'obol', 'basi', and 'pasal'
Stephen Sprunk writes:
If you have a suggestion for "removing the attack possibility in its entirety," please tell us. So far, nobody's come up with one.
SMURF'ing depends on spoofed source addresses, so the appropriate filter is customer (and if your can afford it peer) ingress, not network egress. Anyone willing to install a *.255 filter should instead eliminate directed-broadcast response, and validate packets they will accept.
On Tue, 14 Apr 1998, Stephen Sprunk wrote:
Are we really concerned about being smurfed by a /30, or even a /27?
You should be. If I didn't have directed broadcasts turned off on my network, it would be a very effective smurf amplifier. Because ARIN keeps us on a very short leash, we use the smallest subnet we can get away with for our POPs. Some such sites are very well connected. As far as .0 and .255 addresses go, I'm no more "asking for trouble" by using those than I'm asking for trouble by running an IRC server. They are completely valid addresses. Perhaps those making such comments are better at getting IP space than we are, but we need to squeeze every IP we possibly can into use just to provide enough addresses to our customers. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Chief Network Engineer MindSpring Enterprises, Inc info@mindspring.com Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job.
As far as .0 and .255 addresses go, I'm no more "asking for trouble" by using those than I'm asking for trouble by running an IRC server. They are completely valid addresses. Perhaps those making such comments are better at getting IP space than we are, but we need to squeeze every IP we possibly can into use just to provide enough addresses to our customers.
Not to make this note a total flame ... but are you really honestly trying to say that ARIN won't give you more addresses if you don't use .0 and .255 addresses on all /23 and larger prefixes? Out of all the /17-/23 prefixes out there on the net, what percentage would people say are truely used on a network in "classful supernet" configurations. Out of that percentage, what percent of those are in such a dire situation with their past network allocation history that their future allocations depend on actually allocating and using, in a production environment, 510 addresses out of a /23 instead of a mere 508? --------------------------------------------------------------------------- ** Andrew W. Smith ** awsmith@neosoft.com ** Chief Network Engineer ** ** http://www.neosoft.com/neosoft/staff/andrew ** 1-888-NEOSOFT ** ** "Opportunities multiply as they are seized" - Sun Tzu ** ---------------------------------------------------------------------------
Brandon Ross said once upon a time:
On Tue, 14 Apr 1998, Stephen Sprunk wrote:
Are we really concerned about being smurfed by a /30, or even a /27?
You should be. If I didn't have directed broadcasts turned off on my network, it would be a very effective smurf amplifier. Because ARIN keeps us on a very short leash, we use the smallest subnet we can get away with for our POPs. Some such sites are very well connected.
We should be concerned about receiving pings floods from two single addresses? The the IP size of the network also figures into the nature of the attack. Smurfing is made easier by large subnets without directed-broadcast turned off. It is a lot more work to get the same results from networks smaller than a /27.
On Wed, 15 Apr 1998, Pete Ashdown wrote:
Are we really concerned about being smurfed by a /30, or even a /27?
We should be concerned about receiving pings floods from two single addresses? The the IP size of the network also figures into the nature of the attack. Smurfing is made easier by large subnets without directed-broadcast turned off. It is a lot more work to get the same results from networks smaller than a /27.
Sorry, I should have been more clear. I took that earlier statement to mean that we shouldn't be concerned about amplification networks smaller than /24. I felt that was implied by the discussion about filtering addresses ending in .255. The point I was trying to make is that I have many networks with masks longer than /24 (the majority of which are shorter than /27) that would make very effective smurf amplifiers if I didn't have directed broadcasts turned off. In my experience I've found that many networks use /24's, not because they necessarily need 254 hosts on that network, but because it's convienent since the network/host number falls on an octet boundry. Most of these networks I've seen have significantly less than 254 hosts on them. My networks with longer masks are much denser than what I've seen is the average /24, and therefore possibly more dangerous as amplifiers. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Chief Network Engineer MindSpring Enterprises, Inc info@mindspring.com Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job.
On Wed, 15 Apr 1998, Pete Ashdown wrote:
We should be concerned about receiving pings floods from two single addresses? The the IP size of the network also figures into the nature of the attack. Smurfing is made easier by large subnets without directed-broadcast turned off. It is a lot more work to get the same results from networks smaller than a /27.
This is directed towards everyone who's been fortunate enough to take part in this discussion, not necessarily you Mr. Ashdown. If you've got an ISDN line or better, you can successfully ping flood a /30 broadcast address with larger than normal packets and take down a smaller link (ISDN or modem). It wouldn't be as effective as a /27, /24 or greater, but enough /27's and you'd have the same effect, though it'd me more resource intensive on the attackers end than just going after a /24 or greater broadcast address. Regardless, it doesn't matter what broadcast they ping, as they have varying degrees of effectiveness. What really matters is if we've put the same amount of effort into fixing our networks as we have arguing about who's responsibility it is to fix it and what the best course of action is. If you've got filters on your network to keep you from being a smurf amplifier, then great. If you've got filters on your router to keep your customers from starting smurf attacks, then great. But if you've only got one and not the other, then you're just doing a half assed job. I agree that IP directed broadcasts should be turned off on everyone's routers, and those that ignore the problem or refuse to fix it should be made to deal with it for the greater good of the Internet at large. But if my customers can smurf out, I'm just as guilty as the people who don't fix IP directed broadcasts. As stated earlier, spoofed traffic is the #1 cause of most denial of service attacks released in the last 6-12 months. It doesn't make any sense why most people who consider themselves responsible admins would rather bicker over responsibility than fix their networks and be done with it. If everyone but the few networks that allow directed broadcasts fixed spoofing packets from their customers leaving through their network, it would seem that smurf/fraggle/teardrop/land/etc. would have all been only mildly effective, and must easier to trace back. My $0.02 Regards, Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services Fortune: 43rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped
On Tue, Apr 14, 1998 at 08:49:04AM -0700, Aaron Beck wrote:
On Mon, 13 Apr 1998, Stephen Sprunk wrote:
Then again, filtering any packets to or from x.x.x.255 would have a similar but more profound effect. Anyone who actually uses a .255 address for a host is asking for trouble anyways.
the problem with that thinking, of course, is going to crop up when you encounter /23's and greater.
No, IMHO, the comment stands: no matter _what_ size your network is, if you assign host addresses with a .0 or .255 final octet, things may break, and you deserve what you get. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
No, IMHO, the comment stands: no matter _what_ size your network is, if you assign host addresses with a .0 or .255 final octet, things may break, and you deserve what you get.
Again, the likelihood that these addresses will cause problems or experience connectivity issues is a far greater concern than the gain of less than 1% of usable address space.
What bullshit. Am I hearing people advocating deliberately breaking perfectly valid addresses in order to not have to tax our poor brains for a proper solution? Filtering out all x.x.x.255 addresses is a very bad idea. It's a quick-and-dirty, poorly-thought-out hack. There are lots of .0 and .255 addresses in use in variously sized net blocks. We don't get to simply say "well too bad." Especially coming from the same people who advocated classless addressing to begin with. The byte boundaries are meaningless. We all said so. Dissapointed, /cvk
On Tue, Apr 14, 1998 at 04:00:33PM -0400, Charley Kline wrote:
No, IMHO, the comment stands: no matter _what_ size your network is, if you assign host addresses with a .0 or .255 final octet, things may break, and you deserve what you get.
Again, the likelihood that these addresses will cause problems or experience connectivity issues is a far greater concern than the gain of less than 1% of usable address space.
Watch your quoting, Charley; I said the first thing; someone else the latter.
What bullshit. Am I hearing people advocating deliberately breaking perfectly valid addresses in order to not have to tax our poor brains for a proper solution?
The problem is one of leverage, Charley. If I do assign .255 to a host, then I'm at the mercey of the entire friggin Internet. If I _don't_... then I'm in control. Yes, it's ugly, but (as they used to say in the navy) "that's fine sonny, but this here's the Fleet."
Filtering out all x.x.x.255 addresses is a very bad idea. It's a quick-and-dirty, poorly-thought-out hack. There are lots of .0 and .255 addresses in use in variously sized net blocks. We don't get to simply say "well too bad." Especially coming from the same people who advocated classless addressing to begin with. The byte boundaries are meaningless. We all said so.
Welcome to the real world. Not everyone has those "you must be this tall to ride this ride" signs on their downlinks. Sorry. Cheers, -- jr "it's rarely productive to argue with the weather" a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
What bullshit. Am I hearing people advocating deliberately breaking perfectly valid addresses in order to not have to tax our poor brains for a proper solution?
Assuming that the loudest voices on NANOG represent concensus or majority or any such thing is probably a really poor plan. Many of the noisiest people on the list are the least knowledgeable. I would imagine that most sane people on the list are ignoring this particular discussion, given the unlikelyhood of it producing anything useful. I don't think there's any danger of any serious fraction of the Internet filtering out .255-addresses. --jhawk
I don't think there's any danger of any serious fraction of the Internet filtering out .255-addresses.
but if the idiots babbling about it here start to, then we can quickly renumber our critical hosts into those immediately valuable addresses. randy
And isn't it amazing that some of the people on this list who contribute nothing but complaints are themselves guilty of being smurf amplifiers? I won't point to particular people, as I've done some quick pings and it seems over half the people participating in this very thread haven't bothered turning off directed broadcasts themselves. (I can provide a summary of testing to interested parties I recognize) Seriously folks, if you can't even turn this stuff off yourselves, how can you expect anyone else to? And how do you expect people to take you seriously? Stephen someone wrote:
Many of the noisiest people on the list are the least knowledgeable.
-- Stephen Sprunk "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
Then how do you effectivly protect your networks form being used as amplifiers? Does no ip directed broadcast really work? On Tue, 14 Apr 1998, Charley Kline wrote: :> No, IMHO, the comment stands: no matter _what_ size your network is, if :> you assign host addresses with a .0 or .255 final octet, things may :> break, and you deserve what you get. : :> Again, the likelihood that these addresses will cause problems or :> experience connectivity issues is a far greater concern than the gain of :> less than 1% of usable address space. : : :What bullshit. Am I hearing people advocating deliberately breaking :perfectly valid addresses in order to not have to tax our poor brains :for a proper solution? : :Filtering out all x.x.x.255 addresses is a very bad idea. It's a :quick-and-dirty, poorly-thought-out hack. There are lots of .0 and .255 :addresses in use in variously sized net blocks. We don't get to simply :say "well too bad." Especially coming from the same people who advocated :classless addressing to begin with. The byte boundaries are meaningless. :We all said so. : :Dissapointed, : :/cvk : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
Does no ip directed broadcast really work?
Yes. It works. And it works for whatever your particular netmask or broadcast address happens to be, which is what's important. The only time you shouldn't do it globally is when some other network really needs to see broadcasts. For example, If we manage a client's network with HP OpenView over the internet, we need to be able to send them directed broadcasts, so that OpenView host discovery will work. Patrol works the same way, as do other products. In this case you can't use the "no ip directed broadcast" switch, but you can still set up access rules which do the same thing except for the permitted network. Bottom line is that you should protect your network from people who would either abuse it via smurfing, or simply have no business looking for hosts on your network. You have the tools to do it. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Fri, 17 Apr 1998, Dean Anderson wrote:
Does no ip directed broadcast really work?
Yes. It works.
It is important (and obvious, I hope) to realise that this does not 'fix' smurfing; it fixes you from being a smurf amplifier. In no way does it protect you from being smurfed. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex@nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Why don't use the filter deny icmp any 0.0.0.255 255.255.255.0 echo-request on the incoming lines? It just block 99.999% of this smurf amplifiers; and I hardly think someone eve sence this restriction for the real PING tests. ??? On Fri, 17 Apr 1998, Dean Anderson wrote:
Date: Fri, 17 Apr 1998 18:09:08 -0400 From: Dean Anderson <dean@av8.com> To: jlixfeld@idirect.ca Cc: nanog@merit.edu Subject: Re: SMURF amplifier block list
Does no ip directed broadcast really work?
Yes. It works.
And it works for whatever your particular netmask or broadcast address happens to be, which is what's important.
The only time you shouldn't do it globally is when some other network really needs to see broadcasts. For example, If we manage a client's network with HP OpenView over the internet, we need to be able to send them directed broadcasts, so that OpenView host discovery will work. Patrol works the same way, as do other products. In this case you can't use the "no ip directed broadcast" switch, but you can still set up access rules which do the same thing except for the permitted network.
Bottom line is that you should protect your network from people who would either abuse it via smurfing, or simply have no business looking for hosts on your network. You have the tools to do it.
--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
What about people who didn't subnet their class B on the eight bit boundry, but made larger subnets instead? What about the class B that doesn't appear to be subnetted at all? What about supernetted class C networks? A trailing .255 can be a valid host. On Sat, 18 Apr 1998, Alex P. Rudnev wrote:
Why don't use the filter
deny icmp any 0.0.0.255 255.255.255.0 echo-request
on the incoming lines? It just block 99.999% of this smurf amplifiers; and I hardly think someone eve sence this restriction for the real PING tests.
???
On Fri, 17 Apr 1998, Dean Anderson wrote:
Date: Fri, 17 Apr 1998 18:09:08 -0400 From: Dean Anderson <dean@av8.com> To: jlixfeld@idirect.ca Cc: nanog@merit.edu Subject: Re: SMURF amplifier block list
Does no ip directed broadcast really work?
Yes. It works.
And it works for whatever your particular netmask or broadcast address happens to be, which is what's important.
The only time you shouldn't do it globally is when some other network really needs to see broadcasts. For example, If we manage a client's network with HP OpenView over the internet, we need to be able to send them directed broadcasts, so that OpenView host discovery will work. Patrol works the same way, as do other products. In this case you can't use the "no ip directed broadcast" switch, but you can still set up access rules which do the same thing except for the permitted network.
Bottom line is that you should protect your network from people who would either abuse it via smurfing, or simply have no business looking for hosts on your network. You have the tools to do it.
--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
-- Dan Boehlke, Senior Network Engineer M R N e t Internet: dboehlke@mr.net A MEANS Telcom Company Phone: 612-362-5814 2829 SE University Ave. Suite 200 WWW: http://www.mr.net/~dboehlke/ Minneapolis, MN 55414
At 1:39 PM -0400 4/18/98, Dan Boehlke wrote:
What about people who didn't subnet their class B on the eight bit boundry, but made larger subnets instead? What about the class B that doesn't appear to be subnetted at all? What about supernetted class C networks? A trailing .255 can be a valid host.
Indeed. I think that MIT uses /16 netmasks in some places, and uses numbers like 18.43.0.77, and would expect to use 18.43.0.255. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
What about people who didn't subnet their class B on the eight bit boundry, but made larger subnets instead? What about the class B that doesn't appear to be subnetted at all? What about supernetted class C networks? A trailing .255 can be a valid host. And what's worng? If they di nit subnet their B network, the tail of address should be .255 too.
Why don't use the filter
deny icmp any 0.0.0.255 255.255.255.0 echo-request Just now, USA's ISP seems to be absolutely helpless facing SMURF. A lot of networks do not block aroadcast echo-request's; no one even know how to trace thos 'echo-request' packets by their network... may be I am wrong, and it's because there is _a lot of ISP_ there, and even a few af
If someone have particular .255 host - OK, you should not be able to ping it, not more. The small fee for the free-of-smurfing-from-your-network. them who do not know how to fight against SMURF compose a good backet - I do not know. Really; does anyone know any sucsessfull attempts to search for the smurfer? What penalty was provided for this hackers? Does exist some legitimate way to establish a lawsuite against them (when they'll be located - last is the only matter of qualification for their nearest ISP, not more).
On Sat, 18 Apr 1998, Alex P. Rudnev wrote:
What about people who didn't subnet their class B on the eight bit boundry, but made larger subnets instead? What about the class B that doesn't appear to be subnetted at all? What about supernetted class C networks? A trailing .255 can be a valid host. And what's worng? If they di nit subnet their B network, the tail of address should be .255 too.
If someone have particular .255 host - OK, you should not be able to ping it, not more. The small fee for the free-of-smurfing-from-your-network.
Why don't use the filter
deny icmp any 0.0.0.255 255.255.255.0 echo-request Just now, USA's ISP seems to be absolutely helpless facing SMURF. A lot of networks do not block aroadcast echo-request's; no one even know how to trace thos 'echo-request' packets by their network... may be I am wrong, and it's because there is _a lot of ISP_ there, and even a few af them who do not know how to fight against SMURF compose a good backet - I do not know.
Really; does anyone know any sucsessfull attempts to search for the smurfer? What penalty was provided for this hackers? Does exist some legitimate way to establish a lawsuite against them (when they'll be located - last is the only matter of qualification for their nearest ISP, not more).
I agree that ISPs are at the mercy of the smurfers. At MRNet we have been fighting an internal battle to get our customers to do the right things to block their ability to be used as a multiplier. Its not just ignorance that keeps our customers from acting, it in some cases is their equipment. We have written SMURF detection software that uses cisco netflow exports to let us know when a SMURF is going on, either inbound or outbound. Before we had this, we didn't know how bad it was, we never saw the majority of the attacks or where our customer nets were being used as a multiplier. We hope to automate a block. Cisco is working on features to help with this problem. They need to be given time to do it right. We have implimented a filter that blocks broadcasts on our NSP border routers. However this list only blocks the broadcast addresses in our CIDR blocks and on assigment boundries. It has helped alot. We can, as network administrators, clamp down this net so hard only the hackers would be able to use it. Blocking all .255 traffic even just ICMP is a step too close to that. Remember the distain for routers and hosts that made classfull assumptions when they were given an address? -- Dan Boehlke, Senior Network Engineer M R N e t Internet: dboehlke@mr.net A MEANS Telcom Company Phone: 612-362-5814 2829 SE University Ave. Suite 200 WWW: http://www.mr.net/~dboehlke/ Minneapolis, MN 55414
On Sat, 18 Apr 1998, Alex P. Rudnev wrote:
Really; does anyone know any sucsessfull attempts to search for the smurfer? What penalty was provided for this hackers? Does exist some legitimate way to establish a lawsuite against them (when they'll be located - last is the only matter of qualification for their nearest ISP, not more).
I know that this week there was a smurf attack that was tracked to the source. I'm not sure what will happen to him. Hopefully someone from the NOC that caught him will let us know. Jeremiah Jeremiah Kristal Senior Network Engineer ICon CMT Corporation jeremiah@iconnet.net 201-319-5764 x284 internal
On Sun, 19 Apr 1998, Jeremiah Kristal wrote:
On Sat, 18 Apr 1998, Alex P. Rudnev wrote: >
I know that this week there was a smurf attack that was tracked to the source. I'm not sure what will happen to him. Hopefully someone from the NOC that caught him will let us know.
That was us, and we do plan on prosecuting. We're in the process of collecting information now. Something that happened during this attack should be a great concern to all of us. In addition to the usual broadcast addresses being used as amplifiers for this smurf attack, the attacker also used network addresses. It seems that many stacks and routers will respond to a packet with a network address in the same way as a broadcast address. Luckily Cisco's "no ip directed-broadcast" already took that into account and blocks those packets, however, if you don't have a Cisco and are having to configure manual filters to avoid being an amplifier site, you _must_ filter out network addresses as well as broadcast addresses. Please, spread the word. P.S. I'd like to publicly thank Icon, Digex, and BBN as well as the EPA (yes folks, the Environmental Protection Agency, they were being used as an amplifier in this attack) for their help in tracing this attack to the source. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job.
This isn't really so surprising, because 0 used to be the broadcast address before being changed to 255. (~1986 or so, I think, right around the time 4.3 BSD came out if I remember correctly.) Many systems still respond to 0 as a broadcast address. Older Sun systems still default the broadcast address to 0. It's an anachronism that could be dropped. But it is interesting that the person would have thought to use it in a smurf attack... If they know that much, they really should have known better than to smurf. I hope they throw the whole bookcase at them... --Dean At 3:02 PM -0400 4/20/98, Brandon Ross wrote:
On Sun, 19 Apr 1998, Jeremiah Kristal wrote:
On Sat, 18 Apr 1998, Alex P. Rudnev wrote: >
I know that this week there was a smurf attack that was tracked to the source. I'm not sure what will happen to him. Hopefully someone from the NOC that caught him will let us know.
That was us, and we do plan on prosecuting. We're in the process of collecting information now.
Something that happened during this attack should be a great concern to all of us. In addition to the usual broadcast addresses being used as amplifiers for this smurf attack, the attacker also used network addresses. It seems that many stacks and routers will respond to a packet with a network address in the same way as a broadcast address.
Luckily Cisco's "no ip directed-broadcast" already took that into account and blocks those packets, however, if you don't have a Cisco and are having to configure manual filters to avoid being an amplifier site, you _must_ filter out network addresses as well as broadcast addresses.
Please, spread the word.
P.S. I'd like to publicly thank Icon, Digex, and BBN as well as the EPA (yes folks, the Environmental Protection Agency, they were being used as an amplifier in this attack) for their help in tracing this attack to the source.
Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Mon, 20 Apr 1998, Dean Anderson wrote:
This isn't really so surprising, because 0 used to be the broadcast address before being changed to 255. (~1986 or so, I think, right around the time 4.3 BSD came out if I remember correctly.) Many systems still respond to 0 as a broadcast address. Older Sun systems still default the broadcast address to 0. It's an anachronism that could be dropped.
Not surprising, but also not mentioned on NANOG until now, at least not as far as I remember.
But it is interesting that the person would have thought to use it in a smurf attack... If they know that much, they really should have known better than to smurf. I hope they throw the whole bookcase at them...
Hopefully, we will. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job.
Lo and behold, Dean Anderson once said:
[Discussion about the use of .0 as broadcast deleted]
But it is interesting that the person would have thought to use it in a smurf attack... If they know that much, they really should have known better than to smurf. I hope they throw the whole bookcase at them...
Not really. The lists of smurfable addresses on the net have contained network numbers for a while now, or so goes the rumor on other lists. It could have come through someone scanning addresses sequentially to find a broadcast address (mm, exciting job), or it could have come from a clueful cracker somewhere else. It doesn't take too many brains to use the prepackaged hacking/crashing programs people can download off Bugtraq. (OTOH, there are quite a few clueful crackers out there, who've found that reading the RFCs is a good thing. Crackers reading RFCs may not be a good thing. :-) -Dave
In message <199804210004.SAA02213@meowy.angio.net>, Dave Andersen writes:
Not really. The lists of smurfable addresses on the net have contained network numbers for a while now, or so goes the rumor on other lists. It could have come through someone scanning addresses sequentially to find a broadcast address (mm, exciting job), or it could have come from a clueful cracker somewhere else. It doesn't take too many brains to use the prepackaged hacking/crashing programs people can download off Bugtraq.
(OTOH, there are quite a few clueful crackers out there, who've found that reading the RFCs is a good thing. Crackers reading RFCs may not be a good thing. :-)
If these attackers had been reading the RFCs years ago, these problems would have been fixed on a much smaller network, causing less total disruption. But of course they were exploiting other security holes at the time. Security holes DON'T get fixed until they are exploited on a large scale, this applies to gaping lapses in Internet design, due to its origin of "cooperative" networks, things like sendmail and bind defaulting to "trust everyone", i.e. sendmail relaying, and bind additional RR poisoning. There simply are too many things broken for someone to considering fixing all the known issues before they are abused. But eventually we will see source filtering and "no ip directed broadcast", but if sendmail relaying is any indication, it will be another year and 1/2 before the first 90% of the problem is fixed. --- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 512-458-9810 http://www.fc.net
Whew. I actaully did the right think when I put up my filter and did the network addresses aswell. Yippie!! I was proactive! =) On Mon, 20 Apr 1998, Brandon Ross wrote: :On Sun, 19 Apr 1998, Jeremiah Kristal wrote: : :> On Sat, 18 Apr 1998, Alex P. Rudnev wrote: > :> :> I know that this week there was a smurf attack that was tracked to the :> source. I'm not sure what will happen to him. Hopefully someone from the :> NOC that caught him will let us know. : :That was us, and we do plan on prosecuting. We're in the process of :collecting information now. : :Something that happened during this attack should be a great concern to :all of us. In addition to the usual broadcast addresses being used as :amplifiers for this smurf attack, the attacker also used network :addresses. It seems that many stacks and routers will respond to a :packet with a network address in the same way as a broadcast address. : :Luckily Cisco's "no ip directed-broadcast" already took that into account :and blocks those packets, however, if you don't have a Cisco and are :having to configure manual filters to avoid being an amplifier site, you :_must_ filter out network addresses as well as broadcast addresses. : :Please, spread the word. : :P.S. I'd like to publicly thank Icon, Digex, and BBN as well as the EPA :(yes folks, the Environmental Protection Agency, they were being used as :an amplifier in this attack) for their help in tracing this attack to the :source. : :Brandon Ross Network Engineering 404-815-0770 800-719-4664 :Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com :Mosher's Law of Software Engineering: Don't worry if it doesn't work :right. If everything did, you'd be out of a job. : : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
Cisco has a method of tracing SMuRF, do they not? Anyone know how they do it?! Is it some imbedded thing, or do they call the owners of each network and pray that they have Ciscos? On Sat, 18 Apr 1998, Alex P. Rudnev wrote: :> What about people who didn't subnet their class B on the eight bit :> boundry, but made larger subnets instead? What about the class B that :> doesn't appear to be subnetted at all? What about supernetted class C :> networks? A trailing .255 can be a valid host. :And what's worng? If they di nit subnet their B network, the tail of :address should be .255 too. : :If someone have particular .255 host - OK, you should not be able to ping :it, not more. The small fee for the free-of-smurfing-from-your-network. : :> > Why don't use the filter :> > :> > deny icmp any 0.0.0.255 255.255.255.0 echo-request :Just now, USA's ISP seems to be absolutely helpless facing SMURF. A lot :of networks do not block aroadcast echo-request's; no one even know how :to trace thos 'echo-request' packets by their network... may be I am :wrong, and it's because there is _a lot of ISP_ there, and even a few af :them who do not know how to fight against SMURF compose a good backet - I :do not know. : :Really; does anyone know any sucsessfull attempts to search for the :smurfer? What penalty was provided for this hackers? Does exist some :legitimate way to establish a lawsuite against them (when they'll be :located - last is the only matter of qualification for their nearest ISP, :not more). : : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
I do not know. I think it's urgent nessecaty to create some method to back-trace any SRC address, realised (at least) by CISCO, because it's clean we are not ready (we - hw. vendors, CEF is too new and unchecked futore and do not work at middle-class routers and access-servers where it's place for the SRC filtering) to make strict src-filtering at the customer-links level. On Sun, 19 Apr 1998 jlixfeld@idirect.ca wrote:
Date: Sun, 19 Apr 1998 18:48:32 -0400 (EDT) From: jlixfeld@idirect.ca To: "Alex P. Rudnev" <alex@Relcom.EU.net> Cc: Dan Boehlke <dboehlke@mr.net>, Dean Anderson <dean@av8.com>, nanog@merit.edu Subject: Re: SMURF amplifier block list
Cisco has a method of tracing SMuRF, do they not? Anyone know how they do it?! Is it some imbedded thing, or do they call the owners of each network and pray that they have Ciscos?
On Sat, 18 Apr 1998, Alex P. Rudnev wrote:
:> What about people who didn't subnet their class B on the eight bit :> boundry, but made larger subnets instead? What about the class B that :> doesn't appear to be subnetted at all? What about supernetted class C :> networks? A trailing .255 can be a valid host. :And what's worng? If they di nit subnet their B network, the tail of :address should be .255 too. : :If someone have particular .255 host - OK, you should not be able to ping :it, not more. The small fee for the free-of-smurfing-from-your-network. : :> > Why don't use the filter :> > :> > deny icmp any 0.0.0.255 255.255.255.0 echo-request :Just now, USA's ISP seems to be absolutely helpless facing SMURF. A lot :of networks do not block aroadcast echo-request's; no one even know how :to trace thos 'echo-request' packets by their network... may be I am :wrong, and it's because there is _a lot of ISP_ there, and even a few af :them who do not know how to fight against SMURF compose a good backet - I :do not know. : :Really; does anyone know any sucsessfull attempts to search for the :smurfer? What penalty was provided for this hackers? Does exist some :legitimate way to establish a lawsuite against them (when they'll be :located - last is the only matter of qualification for their nearest ISP, :not more). : :
-- Regards,
Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net
--------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
MCI has a tool to track spoofed packets, which is the orgin of any DoS today. You can get it from ftp.mci.net:/pub/security/dostrack742812.tar That will trace it to the edge of your network, then you need to work with the other providers to track it past that point. If it's within your network, you should filter it either by using ip verify unicast reverse-path on the serial interfaces or via acls. ip verify unicast reverse-path is a feature in the fib images by cisco. Most large nsp's run these images, and they're now mainline, so fire up your cco accounts and grab them. It drops packets that don't have the same return path, which works for most customers that are single homed. - Jared On a dark and stormy night, jlixfeld@idirect.ca said:
Cisco has a method of tracing SMuRF, do they not? Anyone know how they do it?! Is it some imbedded thing, or do they call the owners of each network and pray that they have Ciscos?
If you do it on your cores as opposed to your border routes, it should know. Your core routers probably created the aggregated B that the border routers get from the cores and in turn advertise out. If you want to filter at the borders (which would stop traffic from hitting your core in the first place) that is probably the way to do it, but if you are in a situation where you didn't subnet at the 8bit boundary, or something else, then you may need to run with it, let the traffic hit your core, and filter it from there. On Sat, 18 Apr 1998, Dan Boehlke wrote: :What about people who didn't subnet their class B on the eight bit :boundry, but made larger subnets instead? What about the class B that :doesn't appear to be subnetted at all? What about supernetted class C :networks? A trailing .255 can be a valid host. : :On Sat, 18 Apr 1998, Alex P. Rudnev wrote: : :> Why don't use the filter :> :> deny icmp any 0.0.0.255 255.255.255.0 echo-request :> :> on the incoming lines? It just block 99.999% of this smurf amplifiers; :> and I hardly think someone eve sence this restriction for the real PING :> tests. :> :> ??? :> :> :> :> On Fri, 17 Apr 1998, Dean Anderson wrote: :> :> > Date: Fri, 17 Apr 1998 18:09:08 -0400 :> > From: Dean Anderson <dean@av8.com> :> > To: jlixfeld@idirect.ca :> > Cc: nanog@merit.edu :> > Subject: Re: SMURF amplifier block list :> > :> > > Does no ip directed broadcast really work? :> > :> > Yes. It works. :> > :> > And it works for whatever your particular netmask or broadcast address :> > happens to be, which is what's important. :> > :> > The only time you shouldn't do it globally is when some other network :> > really needs to see broadcasts. For example, If we manage a client's :> > network with HP OpenView over the internet, we need to be able to send them :> > directed broadcasts, so that OpenView host discovery will work. Patrol :> > works the same way, as do other products. In this case you can't use the :> > "no ip directed broadcast" switch, but you can still set up access rules :> > which do the same thing except for the permitted network. :> > :> > Bottom line is that you should protect your network from people who would :> > either abuse it via smurfing, or simply have no business looking for hosts :> > on your network. You have the tools to do it. :> > :> > --Dean :> > :> > :> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ :> > Plain Aviation, Inc dean@av8.com :> > LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com :> > We Make IT Fly! (617)242-3091 x246 :> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ :> > :> > :> > :> :> Aleksei Roudnev, Network Operations Center, Relcom, Moscow :> (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) :> (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) :> : :-- :Dan Boehlke, Senior Network Engineer M R N e t :Internet: dboehlke@mr.net A MEANS Telcom Company :Phone: 612-362-5814 2829 SE University Ave. Suite 200 :WWW: http://www.mr.net/~dboehlke/ Minneapolis, MN 55414 : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
On Sat, Apr 18, 1998 at 12:39:29PM -0500, Dan Boehlke wrote:
On Sat, 18 Apr 1998, Alex P. Rudnev wrote:
Why don't use the filter deny icmp any 0.0.0.255 255.255.255.0 echo-request on the incoming lines? It just block 99.999% of this smurf amplifiers; and I hardly think someone eve sence this restriction for the real PING tests. What about people who didn't subnet their class B on the eight bit boundry, but made larger subnets instead? What about the class B that doesn't appear to be subnetted at all? What about supernetted class C networks? A trailing .255 can be a valid host.
Yes, Dan, but any potential smurf-_amplifier_ who might need to do this _knows_ this about _their own network_, and can adjust accordingly. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
Umm, I think this has already been hashed out. This is not the only netmask on the planet, and you don't know what other networks netmasks are under CIDR. Trying to guess the netmask just leads to breakage. All you want to do is stop packets coming in to your broadcast address. For example, for your network x.y.z/n (n=24) with your broadcast address of x.y.z.255: (I presume everyone can translate between CIDR notation and dotted decimal ;-) deny ip any x.y.z.255 255.255.255.255 no ip directed broadcast basically puts in the same rule, but it does it automatically by looking at the netmasks on the interfaces. --Dean
Why don't use the filter
deny icmp any 0.0.0.255 255.255.255.0 echo-request
on the incoming lines? It just block 99.999% of this smurf amplifiers; and I hardly think someone eve sence this restriction for the real PING tests.
???
On Fri, 17 Apr 1998, Dean Anderson wrote:
Date: Fri, 17 Apr 1998 18:09:08 -0400 From: Dean Anderson <dean@av8.com> To: jlixfeld@idirect.ca Cc: nanog@merit.edu Subject: Re: SMURF amplifier block list
Does no ip directed broadcast really work?
Yes. It works.
And it works for whatever your particular netmask or broadcast address happens to be, which is what's important.
The only time you shouldn't do it globally is when some other network really needs to see broadcasts. For example, If we manage a client's network with HP OpenView over the internet, we need to be able to send them directed broadcasts, so that OpenView host discovery will work. Patrol works the same way, as do other products. In this case you can't use the "no ip directed broadcast" switch, but you can still set up access rules which do the same thing except for the permitted network.
Bottom line is that you should protect your network from people who would either abuse it via smurfing, or simply have no business looking for hosts on your network. You have the tools to do it.
--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I am talking about boths blocking exterior smurfers from usage your networks as amplifier, and blocking your smurfers from sending such packets by your network. Second task allow you to cutch any smurfer in your own network in a 5 minutes. Just now the only thing big ISP can do in case of SMURF is to block ECHO_REPLY packets to some attacked networks; it results from preventing any PING tests from this networks. Why don't sacrify some addresses (*.255, really) from be pinged at all, but save your from be the source or amplifier of the SMURF? And then, if you should not block by 'log' such packets you'll have the log records about your own smurfers withouth loosing any ICMP capabilities at all.
Umm, I think this has already been hashed out. This is not the only netmask on the planet, and you don't know what other networks netmasks are under CIDR. Trying to guess the netmask just leads to breakage.
All you want to do is stop packets coming in to your broadcast address. For example, for your network x.y.z/n (n=24) with your broadcast address of x.y.z.255: (I presume everyone can translate between CIDR notation and dotted decimal ;-)
deny ip any x.y.z.255 255.255.255.255
no ip directed broadcast basically puts in the same rule, but it does it automatically by looking at the netmasks on the interfaces.
--Dean
Why don't use the filter
deny icmp any 0.0.0.255 255.255.255.0 echo-request
on the incoming lines? It just block 99.999% of this smurf amplifiers; and I hardly think someone eve sence this restriction for the real PING tests.
???
On Fri, 17 Apr 1998, Dean Anderson wrote:
Date: Fri, 17 Apr 1998 18:09:08 -0400 From: Dean Anderson <dean@av8.com> To: jlixfeld@idirect.ca Cc: nanog@merit.edu Subject: Re: SMURF amplifier block list
Does no ip directed broadcast really work?
Yes. It works.
And it works for whatever your particular netmask or broadcast address happens to be, which is what's important.
The only time you shouldn't do it globally is when some other network really needs to see broadcasts. For example, If we manage a client's network with HP OpenView over the internet, we need to be able to send them directed broadcasts, so that OpenView host discovery will work. Patrol works the same way, as do other products. In this case you can't use the "no ip directed broadcast" switch, but you can still set up access rules which do the same thing except for the permitted network.
Bottom line is that you should protect your network from people who would either abuse it via smurfing, or simply have no business looking for hosts on your network. You have the tools to do it.
--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
During an in progress attack, you probably have to take extreme measures, but they shouldn't be generally applied. No one wants to lose addresses that *might* be a broadcast address in some possible netmask. /24 is maybe common, but is not the only netmask. And the people who don't use it won't want you to break their customers networks. --Dean At 2:51 PM -0400 4/18/98, Alex P. Rudnev wrote:
I am talking about boths blocking exterior smurfers from usage your networks as amplifier, and blocking your smurfers from sending such packets by your network. Second task allow you to cutch any smurfer in your own network in a 5 minutes.
Just now the only thing big ISP can do in case of SMURF is to block ECHO_REPLY packets to some attacked networks; it results from preventing any PING tests from this networks. Why don't sacrify some addresses (*.255, really) from be pinged at all, but save your from be the source or amplifier of the SMURF?
And then, if you should not block by 'log' such packets you'll have the log records about your own smurfers withouth loosing any ICMP capabilities at all.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
During an in progress attack, you probably have to take extreme measures, Do you remember - it's not attack against you or attack by some of your customer's networks used as amplifier, but the attack initiated from your own network. You never note such thing withouth some permanent measurement.
It's why we saw this 100% helpless against the SMURF's.
but they shouldn't be generally applied. No one wants to lose addresses that *might* be a broadcast address in some possible netmask. /24 is maybe common, but is not the only netmask. And the people who don't use it won't want you to break their customers networks.
--Dean
At 2:51 PM -0400 4/18/98, Alex P. Rudnev wrote:
I am talking about boths blocking exterior smurfers from usage your networks as amplifier, and blocking your smurfers from sending such packets by your network. Second task allow you to cutch any smurfer in your own network in a 5 minutes.
Just now the only thing big ISP can do in case of SMURF is to block ECHO_REPLY packets to some attacked networks; it results from preventing any PING tests from this networks. Why don't sacrify some addresses (*.255, really) from be pinged at all, but save your from be the source or amplifier of the SMURF?
And then, if you should not block by 'log' such packets you'll have the log records about your own smurfers withouth loosing any ICMP capabilities at all.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
At 3:21 PM -0400 4/18/98, Alex P. Rudnev wrote:
During an in progress attack, you probably have to take extreme measures, Do you remember - it's not attack against you or attack by some of your customer's networks used as amplifier, but the attack initiated from your own network. You never note such thing withouth some permanent measurement.
It's why we saw this 100% helpless against the SMURF's.
But to protect your own network, all you need is the access rule I gave. You know your own broadcast address and netmask, and can put in a rule to block. You just can't block the presumed broadcast address used by other peoples networks. Logging attempted attacks which are blocked can't really be done with a cisco. You need something to monitor the line coming in. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on your cores. Deny ICMP from critical portions of your network. Create a little script which tail -fs the log, parses it, sorts it and counts it. If the script counts more then xxx hits on a certain IP or a certain number of IPs on your network from the same source or a multiple sources on the same network, you have your upstream. Once you have them, you can call them and ask them to do the same until you find the real source. This will not protect against someone smurfing your dialup users and they can do just as much damamge as the former, but they are more likely to bitch if they can't ping so it's a toss up. On Sat, 18 Apr 1998, Dean Anderson wrote: :At 3:21 PM -0400 4/18/98, Alex P. Rudnev wrote: :>> During an in progress attack, you probably have to take extreme measures, :>Do you remember - it's not attack against you or attack by some of your :>customer's networks used as amplifier, but the attack initiated from your :>own network. You never note such thing withouth some permanent :>measurement. :> :>It's why we saw this 100% helpless against the SMURF's. : :But to protect your own network, all you need is the access rule I gave. :You know your own broadcast address and netmask, and can put in a rule to :block. : :You just can't block the presumed broadcast address used by other peoples :networks. : :Logging attempted attacks which are blocked can't really be done with a :cisco. You need something to monitor the line coming in. : : --Dean : : :++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : Plain Aviation, Inc dean@av8.com : LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com : We Make IT Fly! (617)242-3091 x246 :++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
jlixfeld@idirect.ca said once upon a time:
You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on your cores. Deny ICMP from critical portions of your network. Create a little script which tail -fs the log, parses it, sorts it and counts it. If the script counts more then xxx hits on a certain IP or a certain number of IPs on your network from the same source or a multiple sources on the same network, you have your upstream. Once you have them, you can call them and ask them to do the same until you find the real source.
You might want to stick in an "echo-reply" before the log. This will specifically block the smurf, but won't affect any of the other ICMP which does have a useful purpose. This of course will stop any of the blocked addresses from doing outside pings or traceroutes as well.
What's the difference? If you do echo-reply, whoever initiated the ping will never see a response because it is filtered by the echo-reply in the first place. Or am I missing something with the echo-reply?! (it's late, forgive my ignorance) =) On Mon, 20 Apr 1998, Pete Ashdown wrote: :jlixfeld@idirect.ca said once upon a time: :> :>You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on :>your cores. Deny ICMP from critical portions of your network. Create a :>little script which tail -fs the log, parses it, sorts it and counts it. :>If the script counts more then xxx hits on a certain IP or a certain :>number of IPs on your network from the same source or a multiple sources :>on the same network, you have your upstream. Once you have them, you can :>call them and ask them to do the same until you find the real source. : :You might want to stick in an "echo-reply" before the log. This will :specifically block the smurf, but won't affect any of the other ICMP which :does have a useful purpose. This of course will stop any of the blocked :addresses from doing outside pings or traceroutes as well. : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
On Sun, 19 Apr 1998 jlixfeld@idirect.ca wrote:
You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
Using "deny icmp" as anything other than an extremely temporary measure while you (or your customers) are actively under DoS attack and focused only on the affected hosts/nets (the systems under attack and/or the smurf amplifiers if it is a smurf attack) is downright irresponsible. Even then, it will cause problems but they may be less than those caused by the DoS attack. Most ICMP traffic is necessary to the correct operation of the net. Filtering ICMP not only breaks ping, it breaks path mtu discovery which can cause much grief which is hard for the people affected to diagnose. Breaking PMTU discovery has the effect that connections between any two hosts that have an MTU greater than that of the smallest MTU hop on the path will not be able to communicate. Packets will be dropped, consistently enough to prevent communications even though some small part of each flow will frequently get through (generally the same part). This is a pattern (packet size) sensitive packet loss not a random one so TCP retransmission does not recover. For SMTP, the HELO, MAIL, RCPT dialog will happen and then the connection will hang on the message DATA (unless the message is very short) tying up the servers at both ends until they timeout. Normally all attempts to resend the message will also fail. For HTTP, the browser will probably be able to do a "HEAD" (short response) but a "GET" will fail. The symptom to the user is that they are consistently unable to get through to certain web sites with the connection stalling at the same place each time. On very rare ocassions, I have seen a connection actually succeed to one of these unreachable servers when it was sufficiently loaded that it transmitted the data in smaller chunks. If this happens to you, a workaround is to set the Max MTU to 576 on each of your clients (to fix outbound connections) and servers (to fix inbound ones). Setting the Mtu on your router does not seem to work (it might help in one direction (of data flow), by sending ICMP too bigs to your inside hosts at a threshold lower than the lost ICMP too bigs, but not the other direction in which both sets of "too bigs" get dropped. This does put a higher packet load on the backbone (more smaller packets have to be routed). The cause is usually because a router somewhere drops packets which are too large but have the DF (don't fragment) bit set without generating the required ICMP too big message (there is some defective hardware out there) or, more likely, that some cluelesss network operator filtered all ICMP traffic, usually as a naive attempt to protect against real or anticipated DoS attacks. This is made much worse by filtering software which does not allow you to filter specific ICMP types and (unfragmented) packet sizes. A much better way to handle most of the DoS attacks (except smurf) is to force fragment reassasembly on a router which is not sucseptible before forwarding the packets; this puts a significant load on the router so it is best done on a router/firewall close to the systems being protected (which is also desireable because it gives more protection). As an aside on the original topic, filtering on 0.0.0.255 mask 0.0.0.255 is also irresponsible and never should have been suggested here. The lame arguments that anyone who has a host in that range is asking for trouble are specious; just because they may be adversely affected by some clueless individual somewhere does not justify your being clueless as well. Yes, personally, I would avoid putting a (externally accessable) host at .255 because of the general clue deficit. --------------------------------------------------------------------------- --- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- ---------------------------------------------------------------------------
On Mon, 20 Apr 1998, Mark Whitis wrote:
On Sun, 19 Apr 1998 jlixfeld@idirect.ca wrote:
You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
Using "deny icmp" as anything other than an extremely temporary measure while you (or your customers) are actively under DoS attack and focused only on the affected hosts/nets (the systems under attack and/or the smurf amplifiers if it is a smurf attack) is downright irresponsible. Even then, it will cause problems but they may be less than those caused by the DoS attack. Most ICMP traffic is necessary to the correct operation of the net.
Filtering ICMP not only breaks ping, it breaks path mtu discovery which can cause much grief which is hard for the people affected to diagnose.
Agreed. It is amazing how clueless so many people are about this problem, even major backbone providers that just don't seem to be able to understand it. http://www.worldgate.com/~marcs/mtu/ for newbie-level details on PMTU-D and why it needs functioning ICMP. [...]
This is made much worse by filtering software which does not allow you to filter specific ICMP types and (unfragmented) packet sizes. A much better way to handle most of the DoS attacks (except smurf) is to force fragment reassasembly on a router which is not sucseptible before forwarding the packets; this puts a significant load on the router so it is best done on a router/firewall close to the systems being protected (which is also desireable because it gives more protection).
If it reassembles fragments then it isn't a router.
On Mon, 20 Apr 1998, Mark Whitis wrote:
As an aside on the original topic, filtering on 0.0.0.255 mask 0.0.0.255 is also irresponsible and never should have been suggested here. The lame arguments that anyone who has a host in that range is asking for trouble are specious; just because they may be adversely affected by some clueless individual somewhere does not justify your being clueless as well.
Wholesale filtering of ?.?.?.255 is irresponsible but if you have downstream networks who are unable to block directed broadcasts then it is a reasonable stopgap measure to block ?.?.?.255 traffic in those downstream network blocks only. But at the same time you should *DEMAND* that the downstream customer's router vendor fix their broken equipment or else advertise that it is suitable only for use on networks that are not interconnected with the Internet. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
On Mon, 20 Apr 1998, Michael Dillon wrote:
Wholesale filtering of ?.?.?.255 is irresponsible but if you have downstream networks who are unable to block directed broadcasts then it is a reasonable stopgap measure to block ?.?.?.255 traffic in those
Only if the downstream networks are no bigger than a class C and/or you have the permission of all customers affected by that filter and the filter only affects packets destined to your customers (not outbound packets to the net). If you have any downstreams larger than a /24, you should allow those through. Even then, your netmask should have 1s on the left and right (i.e. 255.255.0.255) for a /16 subnetted at /8. Really, you should filter the known broadcast addresses of your downstream networks with the cooperation of those networks. What I was objecting to was the idea that some ISP would get the idea that it was a good idea to filter all .255 destined traffic passing through their network and the general idea that it was ok for an ISP to assume that .255 was a broadcast address when they should actually know their downstream networks in more detail than that (although they might not know about subnetting). Actually, even if they don't know the subnet structure before hand, they will discover this, as far as is relevent to smurfing, when they perform a smurf scan on their own CIDR blocks. Any address that results in multiple smurf type echo replies from different addresses would be considered a broadcast address; any that didn't, wouldn't. And, of course, any ISP should always inform their downstream contacts of any filtering which affects packets to/from their downstream network (no matter how standard) and this information should be propagated downward (possibly excluding details of the firewall protecting the ISPs servers provided that that firewall is not inline for packets between the downstream and either upstream, peers, or other downstreams).
downstream network blocks only. But at the same time you should *DEMAND* that the downstream customer's router vendor fix their broken equipment or else advertise that it is suitable only for use on networks that are not interconnected with the Internet.
Indeed. In the following comments, "firewall" will refer to a packet filtering box, not a proxy box. In a separate message, in private email, another participant, Marc Slemco, pointed out that IP fragment reassembly by a router is contrary to RFC 1812 and dangerous in some situations because the fragments could take separate routes. So, I would consider the following conditions to be necessary before one used fragment reassembly: - The firewall in question is the only route in or out of a network (i.e. if there are multiple links they all come to the same box). - An exception to the above rule could, perhaps, be granted, if all the firewalls protecting a multiply connected leaf network were programmed to behave in such a way that fragments which took multiple routes were sent to the same box to be reassembled. One still needs to consider what happens when one of the boxes is down. One also needs to be careful, from a security perspective, that the method of relaying fragments does not cause them to be mistaken for traffic originating inside; simply "routing" all fragments which arrive at firewall1 and firewall2 to firewall0 (or using a hash) would not be acceptable (unless you had a dedicated fragment network), some form of encapsulation would be needed. - And the deviation from RFC-1812 was well documented, preferably somewhere readily accessable from both inside and outside the protected network. Actually, I would like to see a RFC for using DNS to associate (perhaps using text records) a URL to a WEB page which documents any ideosyncracies of any given router with the canonical forward DNS entry for that router. That way, there would be a consistent way to document broken hardware or hardware which had to, for some reason, deviate from the RFC's. I.e., you MUST not do this, but if you do it anyway, you MUST confess :-). And confession should not be confused with absolution. [Another pet peeve: people who fail to include reverse address DNS records for their router addresses. It is so easy to do (http://www.dbd.com/~whitis/temp/dns/makerev.c) ]. It is also possible, I suspect, if you have multiple links, for some packets to be consistenly fragmented and the fragments routed consistently over multiple routes (based on size or some other criteria) including one which was down so that you received (consistently) some but not all fragments for a while. Combination of retransmission, fragmentation, and multiple routes could conceivably even conspire to produce hostile DoS style improperly fragmented packets entirely by accident (i.e. the overlapping fragment style); this is regardless of whether you reassemble packets at your firewall(s). But if you are protecting a leaf network with a firewall, I still do think you should normally reassemble packets at the firewall; you simply cannot trust all the different stacks inside the firewall in most situations. But conformance with RFC-1812 is likely to mean you have to have a single firewall (a single point of failure, possibly with an offline backup) between the protected organization and all outside connections or that some new code be written. --------------------------------------------------------------------------- --- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- ---------------------------------------------------------------------------
On Tue, 21 Apr 1998, Mark Whitis wrote:
Really, you should filter the known broadcast addresses of your downstream networks with the cooperation of those networks.
Exactly! You can run your own tests for likely broadcast addresses and if you find an open broadcast address you should contact the downstream network and ask if they can block directed broadcasts and if they can't then you should get their permission to filter traffic to the open broadcast address and regardless of their permission you should contact the vendor of their equipment to inquire why the equipment is broken and unsuitable for use on the Internet. And it would be nice to forward any vendor info to Craig Huegen chuegen@quadrunner.com so he can update his SMURF document and submit it for publication as an informational RFC with all the vendor info in place.
What I was objecting to was the idea that some ISP would get the idea that it was a good idea to filter all .255 destined traffic passing through their network
Yuk!
Actually, even if they don't know the subnet structure before hand, they will discover this, as far as is relevent to smurfing, when they perform a smurf scan on their own CIDR blocks. Any address that results in multiple smurf type echo replies from different addresses would be considered a broadcast address; any that didn't, wouldn't.
Exactly! And by cleaning up your downstream vulnerabilities you reduce the chances that your entire address space will be blocked by other network operators. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
Sorry, I do not know who wrote original message, but it should be corrected as:: deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-request log to prevent smurf originating, or deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-reply to prevent smurf flooding into your network. No important ICMP are affected this case. On Mon, 20 Apr 1998, Mark Whitis wrote:
Date: Mon, 20 Apr 1998 16:02:52 -0400 (EDT) From: Mark Whitis <whitis@dbd.com> To: jlixfeld@idirect.ca Cc: nanog@merit.edu Subject: Filtering ICMP (Was Re: SMURF amplifier block list)
On Sun, 19 Apr 1998 jlixfeld@idirect.ca wrote:
You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
Using "deny icmp" as anything other than an extremely temporary measure while you (or your customers) are actively under DoS attack and focused only on the affected hosts/nets (the systems under attack and/or the smurf amplifiers if it is a smurf attack) is downright irresponsible. Even then, it will cause problems but they may be less than those caused by the DoS attack. Most ICMP traffic is necessary to the correct operation of the net.
Filtering ICMP not only breaks ping, it breaks path mtu discovery which can cause much grief which is hard for the people affected to diagnose.
Breaking PMTU discovery has the effect that connections between any two hosts that have an MTU greater than that of the smallest MTU hop on the path will not be able to communicate. Packets will be dropped, consistently enough to prevent communications even though some small part of each flow will frequently get through (generally the same part). This is a pattern (packet size) sensitive packet loss not a random one so TCP retransmission does not recover. For SMTP, the HELO, MAIL, RCPT dialog will happen and then the connection will hang on the message DATA (unless the message is very short) tying up the servers at both ends until they timeout. Normally all attempts to resend the message will also fail.
For HTTP, the browser will probably be able to do a "HEAD" (short response) but a "GET" will fail. The symptom to the user is that they are consistently unable to get through to certain web sites with the connection stalling at the same place each time. On very rare ocassions, I have seen a connection actually succeed to one of these unreachable servers when it was sufficiently loaded that it transmitted the data in smaller chunks.
If this happens to you, a workaround is to set the Max MTU to 576 on each of your clients (to fix outbound connections) and servers (to fix inbound ones). Setting the Mtu on your router does not seem to work (it might help in one direction (of data flow), by sending ICMP too bigs to your inside hosts at a threshold lower than the lost ICMP too bigs, but not the other direction in which both sets of "too bigs" get dropped. This does put a higher packet load on the backbone (more smaller packets have to be routed). The cause is usually because a router somewhere drops packets which are too large but have the DF (don't fragment) bit set without generating the required ICMP too big message (there is some defective hardware out there) or, more likely, that some cluelesss network operator filtered all ICMP traffic, usually as a naive attempt to protect against real or anticipated DoS attacks.
This is made much worse by filtering software which does not allow you to filter specific ICMP types and (unfragmented) packet sizes. A much better way to handle most of the DoS attacks (except smurf) is to force fragment reassasembly on a router which is not sucseptible before forwarding the packets; this puts a significant load on the router so it is best done on a router/firewall close to the systems being protected (which is also desireable because it gives more protection).
As an aside on the original topic, filtering on 0.0.0.255 mask 0.0.0.255 is also irresponsible and never should have been suggested here. The lame arguments that anyone who has a host in that range is asking for trouble are specious; just because they may be adversely affected by some clueless individual somewhere does not justify your being clueless as well. Yes, personally, I would avoid putting a (externally accessable) host at .255 because of the general clue deficit.
--------------------------------------------------------------------------- --- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- ---------------------------------------------------------------------------
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Thus spake Alex P. Rudnev
deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-request log
to prevent smurf originating, or
deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-reply
to prevent smurf flooding into your network.
No important ICMP are affected this case.
Depends what you (or your users) consider important. Consider that users think that they understand networking because they know how to ping or traceroute and your support lines will be busy explaining that you aren't really down just because they can't traceroute to you. We have a little script that looks at network usage and when it sees a spike in traffic it temporarily blocks echo-reply in. It isn't perfect but it helps. We know what our normal traffic is and when it goes much higher we kick the filter into place. If the script makes a mistake and blocks when it isn't really an attack then we haven't actually cut anyone off but we don't flood our downstreams when there is an actual attack. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
1) Traceroute is not affected by this filter; 2) ICMP is really blocked at many different places of Internet; we answer every day _no matter you can't ping www.XXX.com, it's becuase they refuse PING's to their network_. 3) Please, found any sugnificant host at *.255 address. No doubt this is not 100% correct method; but it's worst to allow smurfers to send their packets withouth any punishment.
Thus spake Alex P. Rudnev
deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-request log
to prevent smurf originating, or
deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm echo-reply
to prevent smurf flooding into your network.
No important ICMP are affected this case.
Depends what you (or your users) consider important. Consider that users think that they understand networking because they know how to ping or traceroute and your support lines will be busy explaining that you aren't really down just because they can't traceroute to you.
We have a little script that looks at network usage and when it sees a spike in traffic it temporarily blocks echo-reply in. It isn't It's good way to prevent SMURF attack against your customers; we have SMURF detecting (at the same principle) and I though abiut such auto-blocking. Not bad idea.
But the real question is _how to trace smurfers at 50% cases at least_, not how to prevent existing attack from been successfull... Last task is solved a lot of times, but what's about the first one?
perfect but it helps. We know what our normal traffic is and when it goes much higher we kick the filter into place. If the script makes a mistake and blocks when it isn't really an attack then we haven't actually cut anyone off but we don't flood our downstreams when there is an actual attack.
-- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Then how do you propose to effectively block smurf coming IN? You are totally asking for it if you need to rely on your upstreams to protect you. I agree with you. If we all deny ICMP, yeah it will fuck up the Internet -- Good. I hope we all suffer. Maybe then people will start to listen and actually do something instead of sitting back laughing at everyone else who is getting attacked because they are convinced that it will never happen to them. Seriously.. what do you recommend? I'm totally open. I'm using deny icmp to protect myself. I'm up to an alternative. On Mon, 20 Apr 1998, Mark Whitis wrote: :On Sun, 19 Apr 1998 jlixfeld@idirect.ca wrote: :> You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on : :Using "deny icmp" as anything other than an extremely temporary measure :while you (or your customers) are actively under DoS attack and focused :only on the affected hosts/nets (the systems under attack and/or the smurf :amplifiers if it is a smurf attack) is downright irresponsible. Even :then, it will cause problems but they may be less than those caused by the :DoS attack. Most ICMP traffic is necessary to the correct operation of :the net. : :Filtering ICMP not only breaks ping, it breaks path mtu discovery which :can cause much grief which is hard for the people affected to diagnose. : :Breaking PMTU discovery has the effect that connections between any two :hosts that have an MTU greater than that of the smallest MTU hop on the :path will not be able to communicate. Packets will be dropped, :consistently enough to prevent communications even though some small part :of each flow will frequently get through (generally the same part). This :is a pattern (packet size) sensitive packet loss not a random one so TCP :retransmission does not recover. For SMTP, the HELO, MAIL, RCPT dialog :will happen and then the connection will hang on the message DATA (unless :the message is very short) tying up the servers at both ends until they :timeout. Normally all attempts to resend the message will also fail. : :For HTTP, the browser will probably be able to do a "HEAD" (short :response) but a "GET" will fail. The symptom to the user is that :they are consistently unable to get through to certain web sites :with the connection stalling at the same place each time. On very rare :ocassions, I have seen a connection actually succeed to one of these :unreachable servers when it was sufficiently loaded that it transmitted :the data in smaller chunks. : :If this happens to you, a workaround is to set the Max MTU to 576 on each :of your clients (to fix outbound connections) and servers (to fix inbound :ones). Setting the Mtu on your router does not seem to work (it might :help in one direction (of data flow), by sending ICMP too bigs to your :inside hosts at a threshold lower than the lost ICMP too bigs, but not the :other direction in which both sets of "too bigs" get dropped. This does :put a higher packet load on the backbone (more smaller packets have to be :routed). The cause is usually because a router somewhere drops packets :which are too large but have the DF (don't fragment) bit set without :generating the required ICMP too big message (there is some defective :hardware out there) or, more likely, that some cluelesss network operator :filtered all ICMP traffic, usually as a naive attempt to protect against :real or anticipated DoS attacks. : :This is made much worse by filtering software which does not allow :you to filter specific ICMP types and (unfragmented) packet sizes. :A much better way to handle most of the DoS attacks (except smurf) :is to force fragment reassasembly on a router which is not sucseptible :before forwarding the packets; this puts a significant load on the :router so it is best done on a router/firewall close to the :systems being protected (which is also desireable because it :gives more protection). : :As an aside on the original topic, filtering on 0.0.0.255 mask 0.0.0.255 :is also irresponsible and never should have been suggested here. :The lame arguments that anyone who has a host in that range is :asking for trouble are specious; just because they may be adversely :affected by some clueless individual somewhere does not justify :your being clueless as well. Yes, personally, I would avoid putting :a (externally accessable) host at .255 because of the general clue :deficit. : :--------------------------------------------------------------------------- :--- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ --- :--- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- :--------------------------------------------------------------------------- : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
Jason Lixfeld said once upon a time:
Seriously.. what do you recommend? I'm totally open. I'm using deny icmp to protect myself. I'm up to an alternative.
:> You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
There apparently is a bit of misunderstanding when it comes to how a smurf attack works. To understand a smurf attack you need to understand a standard ping request. Say we have a remote ping destination, named "target" and a originator of the ping request named "source". In the first step of a ping request, "source" sends an ICMP request of "echo" to "target": "source" --- ICMP echo ---> "target" When "target" receives the ICMP echo, it sends back an ICMP echo-reply to "source" "source" <--- ICMP echo-reply --- "target" Upon reception of the "echo-reply" "source" realizes a good ping and coughs you back the statistics on how long the whole interaction was. With a smurf attack you have a perpetrator forging the "source" address, which in this case could also be known as victim. The perp takes advantage of open directed-broadcast networks to get lots of addresses responding back to the "source" (victim) with "echo-reply". Thus the original request looks like this: perp (forged "source") --- ICMP echo ---> "target" (directed-broadcast) and the reply looks like this: "source" (victim) <==== ICMP echo-reply x "target" addresses listening to the broadcast request for ping echo You can easily see how the broadcast size of "target" and whether it is open to "directed-broadcast" is the fundamental exploit in the smurf attack. The larger the subnet, the better. However, it is also easy to see that by blocking just "echo-reply" to certain addresses (IRC servers, Quake servers, etc), you can at least minimize the effects of the attack. The sad part is, the en masse echo-replies will still travel over your pipe to get to your filter and will still consume a significant portion of your bandwidth. Note, my understanding of the function of "directed-broadcast" is limited by the fact that I've never used it in a useful function.
Ok. You know how I always ask the obvious... So, here I go again.. This is only slightly off topic.. If you have no amplifiers greater than 2x-4x, is there really a need to turn off ip directed broadcasts? And if this is true, doesn't designing your network with minimized amplifier space sort of negate all this ? Enlighten me .... Richard Pete Ashdown wrote:
Jason Lixfeld said once upon a time:
Seriously.. what do you recommend? I'm totally open. I'm using deny icmp to protect myself. I'm up to an alternative.
:> You could always "deny icmp any aaa.bbb.ccc.ddd www.ccc.nnn.mmm log" on
There apparently is a bit of misunderstanding when it comes to how a smurf attack works. To understand a smurf attack you need to understand a standard ping request.
Say we have a remote ping destination, named "target" and a originator of the ping request named "source". In the first step of a ping request, "source" sends an ICMP request of "echo" to "target":
"source" --- ICMP echo ---> "target"
When "target" receives the ICMP echo, it sends back an ICMP echo-reply to "source"
"source" <--- ICMP echo-reply --- "target"
Upon reception of the "echo-reply" "source" realizes a good ping and coughs you back the statistics on how long the whole interaction was.
With a smurf attack you have a perpetrator forging the "source" address, which in this case could also be known as victim. The perp takes advantage of open directed-broadcast networks to get lots of addresses responding back to the "source" (victim) with "echo-reply". Thus the original request looks like this:
perp (forged "source") --- ICMP echo ---> "target" (directed-broadcast)
and the reply looks like this:
"source" (victim) <==== ICMP echo-reply x "target" addresses listening to the broadcast request for ping echo
You can easily see how the broadcast size of "target" and whether it is open to "directed-broadcast" is the fundamental exploit in the smurf attack. The larger the subnet, the better. However, it is also easy to see that by blocking just "echo-reply" to certain addresses (IRC servers, Quake servers, etc), you can at least minimize the effects of the attack. The sad part is, the en masse echo-replies will still travel over your pipe to get to your filter and will still consume a significant portion of your bandwidth.
Note, my understanding of the function of "directed-broadcast" is limited by the fact that I've never used it in a useful function.
On Fri, 24 Apr 1998, Richard Irving wrote:
Ok. You know how I always ask the obvious... So, here I go again..
This is only slightly off topic.. If you have no amplifiers greater than 2x-4x, is there really a need to turn off ip directed broadcasts?
My feelings there are "why not?". If you are running on a platform (such as Cisco) that makes it easy to turn off directed broadcast you can only help by turning it off. In the attacks that have come our way, the attackers have used almost every size of amplifier. I also suspect that as network managers become more clueful (a slow painful process) that the attackers will eventually have to resort to less efficient means of attack.
And if this is true, doesn't designing your network with minimized amplifier space sort of negate all this ?
In some applications that wouldn't be a hard thing to do, but for most it's nearly impossible. Brandon Ross Network Engineering 404-815-0770 800-719-4664 Director, Network Engineering, MindSpring Ent., Inc. info@mindspring.com Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job.
On Thu, 23 Apr 1998, Jason Lixfeld wrote:
Then how do you propose to effectively block smurf coming IN? You are totally asking for it if you need to rely on your upstreams to protect you.
You cannot block SMURF coming in. Once it has travelled down your DS3 to your router it has already done damage to your connectivity. Only your upstream can prevent the SMURF packets from coming down your DS3. The solution for the victim is to work with their upstream to rapidly block *AND* *TRACE* the perps. -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
On Thu, 23 Apr 1998, Jason Lixfeld wrote:
Then how do you propose to effectively block smurf coming IN? You are totally asking for it if you need to rely on your upstreams to protect you. I agree with you. If we all deny ICMP, yeah it will fuck up the Internet -- Good. I hope we all suffer. Maybe then people will
Go back to the message that started the original thread. The people you adversely affect by your actions will be totally innocent victims. If, on the othere hand, you block the networks which are amplifying the smurf you will affect those orginizations who are guilty of contributory negligence and their employees/customers. 1) installing a router under your control on the upstream end of your uplink is a good idea if you want to minimize the load on your upstream end (this may result in two routers directly connected). 2) install your detection software to detect attacks, and semi-automatically (with approval from your 24 hour NOC staff) configures the countermeasures (below) 2) Filter out everything to/from the offending amplifier networks (not just icmp) on your upstream router (if you have it, downstream otherwise), except http: (if you can implement the next countermeasure) 3) If you have the capability (you can do this with a linux box and probably a *BSD box as well), redirect http traffic to the amplifier network or from the amplifier network to your "access denied" "web server" which simply responds to all http: queries with a temporary redirect to a non-cacheable page which explains why access was denied and gives the contact email and phone number for the offending networks NOC (possibly automatically extracted from whois). 4) when the amplifier network blocks the smurf and traces it to the originating network (and sends you the trace), unblock them and block the originating network (or the next negligent network). 5) unblock the originating network when they terminate the offending partie and install filters to prevent recurrence. Announce any blocks. At the moment, nanog might be the most appropriate forum. This isn't the cheapest solution but it would be far more effective at stamping out smurf. And the tools used put you in a much better situation to deal with similar attacks. If you don't have the resources to do this, get your upstream to do this; if you don't have an upstream, then there is little excuse for your network not having the resources to deal with stuff like this. On a separate but related matter, I have thrown together a web page which details many common ISP/network administrator mistakes which cause others lots of grief, including the kinds discussed in these threads http://www.dbd.com/~whitis/isp_mistakes.html If you have additions, particularly those, which are: - pervasive mistakes, or - not necessarily obvious send me email off list. Links to relevent or similar pages are appropriate. --------------------------------------------------------------------------- --- Mark Whitis <whitis@dbd.com> WWW: http://www.dbd.com/~whitis/ --- --- 428-B Moseley Drive; Charlottesville, VA 22903 804-962-4268 --- ---------------------------------------------------------------------------
During an in progress attack, you probably have to take extreme measures, Do you remember - it's not attack against you or attack by some of your customer's networks used as amplifier, but the attack initiated from your own network. You never note such thing withouth some permanent measurement.
Oops. I misunderstood this first time round. I don't think you can easily detect smurf initiations, because you have to guess at the broadcast address. I think it is much easier to detect and block forged source addresses, which are also necessary for the hacker who is operating out of your network. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Dean Anderson writes...
During an in progress attack, you probably have to take extreme measures, Do you remember - it's not attack against you or attack by some of your customer's networks used as amplifier, but the attack initiated from your own network. You never note such thing withouth some permanent measurement.
Oops. I misunderstood this first time round. I don't think you can easily detect smurf initiations, because you have to guess at the broadcast address.
I think it is much easier to detect and block forged source addresses, which are also necessary for the hacker who is operating out of your network.
A combination of ... 1. blocking outbound packets with sources not in your own networks 2. blocking inbound packets addressed to broadcast addresses you know you have in your subnetting topology 3. blocking inbound echo_request 4. blocking outbound echo_reply ... would be a good start. It breaks things like outsiders pinging your network, but many find this an acceptable compromise. I've done #1, #3 and #4 for over 4 years. I plan to add #2 shortly, not only at the main gateways, but also for all RADIUS based dialups, whether LAN or not. I already block outbound packets to port 25, except allow them to my mail servers, for all but customers who run their own mail servers, via RADIUS, for purposes of blocking spam relaying. Of course that won't stop it all, but it does stop most, including the naive. I have no plans to block outbound packets to addresses ending in .255. I'd love to be able to: 5. block inbound packets with sources I have no routes for 6. block inbound packets with sources that came in over an interface that such a source could not route to if it were a destination -- Phil Howard | blow2me7@no4place.net a6b5c4d9@s1p0a0m4.net eat6this@noplace6.com phil | stop5it8@spammer6.edu no9way48@dumbads1.net blow1me9@s0p0a9m2.edu at | suck3it2@anywhere.net crash528@nowhere5.edu end7it11@lame7ads.com milepost | stop6ads@no1where.org no59ads8@s6p5a1m6.org ads5suck@s8p8a3m8.edu dot | no9way53@no37ads3.net eat25me5@s9p8a1m1.edu die8spam@spammer1.com com | eat59me0@spammer5.org stop4181@dumbads9.net eat2this@spammer6.net
What would be the benefit of doing 3 AND 4?! They both effectively do the same thing and you can't do one if the other is being blocked. Is their a pro to doing both of them? :A combination of ... : :1. blocking outbound packets with sources not in your own networks : :2. blocking inbound packets addressed to broadcast addresses you know : you have in your subnetting topology : :3. blocking inbound echo_request : :4. blocking outbound echo_reply : :... would be a good start. It breaks things like outsiders pinging your :network, but many find this an acceptable compromise. I've done #1, #3 :and #4 for over 4 years. I plan to add #2 shortly, not only at the main :gateways, but also for all RADIUS based dialups, whether LAN or not. I :already block outbound packets to port 25, except allow them to my mail :servers, for all but customers who run their own mail servers, via RADIUS, :for purposes of blocking spam relaying. Of course that won't stop it all, :but it does stop most, including the naive. : :I have no plans to block outbound packets to addresses ending in .255. : :I'd love to be able to: : :5. block inbound packets with sources I have no routes for : :6. block inbound packets with sources that came in over an interface that : such a source could not route to if it were a destination : :-- :Phil Howard | blow2me7@no4place.net a6b5c4d9@s1p0a0m4.net eat6this@noplace6.com : phil | stop5it8@spammer6.edu no9way48@dumbads1.net blow1me9@s0p0a9m2.edu : at | suck3it2@anywhere.net crash528@nowhere5.edu end7it11@lame7ads.com : milepost | stop6ads@no1where.org no59ads8@s6p5a1m6.org ads5suck@s8p8a3m8.edu : dot | no9way53@no37ads3.net eat25me5@s9p8a1m1.edu die8spam@spammer1.com : com | eat59me0@spammer5.org stop4181@dumbads9.net eat2this@spammer6.net : -- Regards, Jason A. Lixfeld Network Engineer, iDirect Network Operations --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) --------------------------------------------------------------------- jlixfeld@idirect.ca | jlixfeld@torontointernetxchange.net ---------------------------------------------------------------------
On Sat, Apr 18, 1998 at 03:48:57PM -0400, Dean Anderson wrote: but it doesn't matter: Again folks: Two things will cut 99.44% of the smurf: Get as many net-ops as you can to 1) turn no ip-directed broadcast (if they have a knob (or bitch long and loud)) and 2) filter outbound packets with forged source addresses (or bitch long and loud if you don't have a knob). It's said that a problem changes in type when it chanegs _enough_ in magnitude. I suspect that it won't be another 12 months before a router with both those knobs is _required_ to meet the (new version of the) Router Requirements RFC, much less to actually _get_ a connection. If you can't filter the appropriate stuff, get the hell off _my_ Internet. :-) Cheers, -- jr 'wanna see the Bill of Sale? ;-)' a -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
measurement.
Oops. I misunderstood this first time round. I don't think you can easily detect smurf initiations, because you have to guess at the broadcast address. It's not difficult to detect SMURF initiators belongs to your own customers. For us, it's easy because we have IP accounting at the core routers and have some anti-smurf monitoring;
If you saw ICMP-request packets with the DST address looks as broadcast, it's the bell for your noc _let's check where are this packets originated_ - and this trace you to the SMURFer at 90% of the cases. And this 0.0.0.255 255.255.255.0 address/wildcard_bits assumption makes a great approximation for the broadcast addresses.
I think it is much easier to detect and block forged source addresses, which are also necessary for the hacker who is operating out of your network.
--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
Uhmm, would the 255.255.255.255 wildcard not be 255.255.255.0? On Sat, 18 Apr 1998, Dean Anderson wrote: :Umm, I think this has already been hashed out. This is not the only netmask :on the planet, and you don't know what other networks netmasks are under :CIDR. Trying to guess the netmask just leads to breakage. : :All you want to do is stop packets coming in to your broadcast address. :For example, for your network x.y.z/n (n=24) with your broadcast address :of x.y.z.255: (I presume everyone can translate between CIDR notation and :dotted decimal ;-) : :deny ip any x.y.z.255 255.255.255.255 : :no ip directed broadcast basically puts in the same rule, but it does it :automatically by looking at the netmasks on the interfaces. : : --Dean : :>Why don't use the filter :> :> deny icmp any 0.0.0.255 255.255.255.0 echo-request :> :>on the incoming lines? It just block 99.999% of this smurf amplifiers; :>and I hardly think someone eve sence this restriction for the real PING :>tests. :> :>??? :> :> :> :>On Fri, 17 Apr 1998, Dean Anderson wrote: :> :>> Date: Fri, 17 Apr 1998 18:09:08 -0400 :>> From: Dean Anderson <dean@av8.com> :>> To: jlixfeld@idirect.ca :>> Cc: nanog@merit.edu :>> Subject: Re: SMURF amplifier block list :>> :>> > Does no ip directed broadcast really work? :>> :>> Yes. It works. :>> :>> And it works for whatever your particular netmask or broadcast address :>> happens to be, which is what's important. :>> :>> The only time you shouldn't do it globally is when some other network :>> really needs to see broadcasts. For example, If we manage a client's :>> network with HP OpenView over the internet, we need to be able to send them :>> directed broadcasts, so that OpenView host discovery will work. Patrol :>> works the same way, as do other products. In this case you can't use the :>> "no ip directed broadcast" switch, but you can still set up access rules :>> which do the same thing except for the permitted network. :>> :>> Bottom line is that you should protect your network from people who would :>> either abuse it via smurfing, or simply have no business looking for hosts :>> on your network. You have the tools to do it. :>> :>> --Dean :>> :>> :>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ :>> Plain Aviation, Inc dean@av8.com :>> LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com :>> We Make IT Fly! (617)242-3091 x246 :>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ :>> :>> :>> :> :>Aleksei Roudnev, Network Operations Center, Relcom, Moscow :>(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) :>239-10-10, N 13729 (pager) :>(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) : : : :++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : Plain Aviation, Inc dean@av8.com : LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com : We Make IT Fly! (617)242-3091 x246 :++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
No, because you only want to stop the packets coming into the broadcast address, not the entire network. (You may want to block the entire network, say for security reasons, but that's a slightly different issue). I suspect that you are confused with the wildcarding. The second parameter is a mask for the first. All ones on the mask mean it matches exactly the first address. Leaving the last octet of the mask 0 means it matches all ip addresses that begin with x.y.z, including the broadcast address. --Dean At 6:46 PM -0400 4/19/98, jlixfeld@idirect.ca wrote:
Uhmm, would the 255.255.255.255 wildcard not be 255.255.255.0?
On Sat, 18 Apr 1998, Dean Anderson wrote:
:Umm, I think this has already been hashed out. This is not the only netmask :on the planet, and you don't know what other networks netmasks are under :CIDR. Trying to guess the netmask just leads to breakage. : :All you want to do is stop packets coming in to your broadcast address. :For example, for your network x.y.z/n (n=24) with your broadcast address :of x.y.z.255: (I presume everyone can translate between CIDR notation and :dotted decimal ;-) : :deny ip any x.y.z.255 255.255.255.255 : :no ip directed broadcast basically puts in the same rule, but it does it :automatically by looking at the netmasks on the interfaces.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Really? I thought that extended access-lists needed wildcard masks which is why I said 255.255.255.0. If an inbound access-list on a hssi says: access-list 101 deny icmp any 0.0.0.255 255.255.255.0 It is denying only packets with a destination to any.any.any.255. In the example below, he is actually denying anything from anywhere, not the broadcasts: <snip> deny ip any x.y.z.255 255.255.255.255 </snip> If he wanted to deny ip to broadcasts on a specific network, he would: deny ip any x.y.z.255 0.0.0.0 or deny ip any host x.y.z.255 Am I lost here?! =P On Sun, 19 Apr 1998, Dean Anderson wrote: :No, because you only want to stop the packets coming into the broadcast :address, not the entire network. (You may want to block the entire network, :say for security reasons, but that's a slightly different issue). : :I suspect that you are confused with the wildcarding. The second parameter :is a mask for the first. All ones on the mask mean it matches exactly the :first address. Leaving the last octet of the mask 0 means it matches all ip :addresses that begin with x.y.z, including the broadcast address. : : --Dean : :At 6:46 PM -0400 4/19/98, jlixfeld@idirect.ca wrote: :>Uhmm, would the 255.255.255.255 wildcard not be 255.255.255.0? :> :>On Sat, 18 Apr 1998, Dean Anderson wrote: :> :>:Umm, I think this has already been hashed out. This is not the only netmask :>:on the planet, and you don't know what other networks netmasks are under :>:CIDR. Trying to guess the netmask just leads to breakage. :>: :>:All you want to do is stop packets coming in to your broadcast address. :>:For example, for your network x.y.z/n (n=24) with your broadcast address :>:of x.y.z.255: (I presume everyone can translate between CIDR notation and :>:dotted decimal ;-) :>: :>:deny ip any x.y.z.255 255.255.255.255 :>: :>:no ip directed broadcast basically puts in the same rule, but it does it :>:automatically by looking at the netmasks on the interfaces. : : :++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : Plain Aviation, Inc dean@av8.com : LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com : We Make IT Fly! (617)242-3091 x246 :++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ : : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca iDirect Network Operations jlixfeld@torontointernetxchange.net --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) ---------------------------------------------------------------------
At 10:36 PM -0400 4/23/98, Jason Lixfeld wrote:
deny ip any x.y.z.255 255.255.255.255
This is the wrong mask. Sorry about that. It should be all 0's rather than all 1's.
If he wanted to deny ip to broadcasts on a specific network, he would:
You are correct. I should have said:
deny ip any x.y.z.255 0.0.0.0
--Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP/DCE http://www.av8.com We Make IT Fly! (617)242-3091 x246 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yes, it works very well. Stephen jlixfeld@idirect.ca wrote:
Then how do you effectivly protect your networks form being used as amplifiers? Does no ip directed broadcast really work?
-- Stephen Sprunk, KD5DWP "Oops." Email: sprunk@paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W
On Fri, 17 Apr 1998 jlixfeld@idirect.ca wrote:
Then how do you effectivly protect your networks form being used as amplifiers? Does no ip directed broadcast really work?
Yes. http://www.quadrunner.com/~chuegen/smurf.cgi ftp://ftp.isi.edu/in-notes/rfc2267.txt -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com
Jay, I have a B assignment. I have switched infrastructure segments with /22 masking. Do you mean to say that the host number range on each /22 masked segment is not continuous 1 through 1022, but has several holes instead.? The network seems to be working properly. I may be in big trouble! None of my TCP/IP courses or books or Cisco CDs have prepared me for such a surprise. Please point me to a text which will explain this. Thanks for your help. JimC At 3:36 PM -0400 4/14/98, Jay R. Ashworth wrote:
On Tue, Apr 14, 1998 at 08:49:04AM -0700, Aaron Beck wrote:
On Mon, 13 Apr 1998, Stephen Sprunk wrote:
Then again, filtering any packets to or from x.x.x.255 would have a similar but more profound effect. Anyone who actually uses a .255 address for a host is asking for trouble anyways.
the problem with that thinking, of course, is going to crop up when you encounter /23's and greater.
No, IMHO, the comment stands: no matter _what_ size your network is, if you assign host addresses with a .0 or .255 final octet, things may break, and you deserve what you get.
Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592
Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
- James R. Cutler EDS , 800 Tower Drive, Troy, MI 48098 Phone: +1 248 265 7514 FAX: +1 248 265 7514 EDS Internal Web: <http://www.iscg.eds.com/cutler/> World Wide Web: <http://www.ltu.edu/midecus/dechtm/cutler/cutler.htm>
On Tue, Apr 14, 1998 at 04:52:06PM -0400, James R. Cutler wrote:
I have a B assignment. I have switched infrastructure segments with /22 masking. Do you mean to say that the host number range on each /22 masked segment is not continuous 1 through 1022, but has several holes instead.? The network seems to be working properly. I may be in big trouble!
None of my TCP/IP courses or books or Cisco CDs have prepared me for such a surprise. Please point me to a text which will explain this.
I'm posting this answer to the list just on the off chance I've misunderstood the world, instead of you. I'd set followups to nodlist@nodewarrior.net, but I think the reflector would strip it off anyway, so any further traffic on this can drop off NANOG. IP address octets stop at .255. Period. They can't go up to "1022", and it's probably a less than good idea to write them that way, or even think of them that way, because no one and no software will know what to do with them. The assertion that Steve Sprunk and I, amongst others, were making is that any host address that ends in .255 is probably a poor address to assign, and yes, that means that in any network larger than a /24 (IE: subnetted B's, or /23-/8's, to phrase it another way) that you're going to lose more than one address per subnet. My opinion is: this is a lot easier to live with than the possible problems that can arise from numbering a host X.X.X.255, which are problems that you _cannot_ correct yourself. You _can_, however, control whether you address hosts that way or not. Your choice. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
On Tue, Apr 14, 1998 at 04:52:06PM -0400, James R. Cutler wrote:
None of my TCP/IP courses or books or Cisco CDs have prepared me for such a surprise. Please point me to a text which will explain this.
Reply taken off list. I was afraid of this. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com
:: Jay R. Ashworth writes ::
No, IMHO, the comment stands: no matter _what_ size your network is, if you assign host addresses with a .0 or .255 final octet, things may break, and you deserve what you get.
.255 and .0 are prefectly valid on /23 and shorter-prefixed subnets. But many people have made that argument, so I'll get to a much more important point: There's no benefit at all to filtering .255 if your network is properly configured. (1) Let's suppose I block packets coming in to my network that have a source address of X.X.X.255. This does nothing for me. Specifically, it doesn't prevent amplified ECHO REPLYs from coming in. Why? Because those packets don't have the source address of the broadcast address that was used to get the amplification effect. They have the unicast source address of the individual machines that answeres the ECHO REQUESTS. That is, let's suppose your Web Server is 200.200.5.5. Let's suppose that 100.100.100/24 is a viable amplification subnet. If I send ECHO REQUESTS with Source=200.200.5.5, Destination=100.100.100.255, you will see lots of ECHO REPLYs coming at your Web Server. None will have Source Address 100.100.100.255. Instead, they will have Source Address 100.100.100.X, with 1<=X<=254. (2) Let's suppose I block packets leaving my network with a destination address of X.X.X.255. This would tend to prevent users on my network from initiating smurf attacks (in the above example, they would be unable to send packets to the 100.100.100.255 amplifier). But this is an incredibly suboptimal way of preventing my users from launching smurf attacks. What I actually implement is filters that prevent packets from leaving my network with a source address that isn't in my address space. This makes it impossible for my users to smurf anyone but me (because, using the above example again, they can't get the packets with Source Address 200.200.5.5 out of my network). In other words, blocking Source Address=X.X.X.255 inbound does absolutely nothing to prevent your network from being smurfed, and as long as you properly configure to prevent source-address forgery, blocking Destination Address=X.X.X.255 from leaving your network is superfluous. (Of course, blocking Destination Address=X.X.X.255 from coming in is strictly a personal decision. If you know all your networks are at least as big as a /24, and you know that you don't use X.X.X.255 and X.X.X.0, then blocking inbound packets to X.X.X.255 is a perfectly valid way to configure your router to prevent yourself from being used as an amplifier. But that doesn't require that *other people* refrain from using X.X.X.{0|255}, only that you do.) - Brett (brettf@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com
participants (43)
-
Aaron Beck -
Al Reuben -
Alex P. Rudnev -
Andrew Smith -
Brandon Ross -
Brett Frankenberger -
Chris Parker -
Dan Boehlke -
darcy＠druid.net -
Dave Andersen -
Dax Kelson -
Dean Anderson -
dirk＠power.net -
Forrest W. Christian -
James R. Cutler -
Jared Mauch -
Jason L. Weisberger -
Jason Lixfeld -
Jay R. Ashworth -
Jeremiah Kristal -
Jeremy Porter -
jlixfeld＠idirect.ca
-
Joe Shaw -
John Hawkinson -
Jon Lewis -
Karl Denninger -
Karl Denninger
-
kline＠uiuc.edu -
Marc Slemko -
Mark Milhollan -
Mark Whitis -
melinda b. thompson -
Michael Dillon -
Paul A Vixie -
Pete Ashdown -
Phil Howard -
Randy Bush -
Rich Sena -
Richard Irving -
Sean M. Doran -
Stephen Balbach -
Stephen Sprunk -
Vadim Antonov