On Sat, Apr 11, 1998 at 04:53:06PM -0400, Al Reuben wrote:

On Sat, 11 Apr 1998, Karl Denninger wrote:

...

The following networks and masks are banned from our network at the core due to being smurf amplifiers.

I'm going to start posting the blacklist here weekly in the hopes that peer

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 you think they don't already HAVE the list? Where do you think WE got it from? From people smurfing us! The vandals ALREADY HAVE the list. I know this because we were attacked from each of those networks at least once. -- -- 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 Sun, Apr 12, 1998 at 01:20:02AM -0400, Jon Lewis wrote:

On Sun, 12 Apr 1998, Karl Denninger wrote:

...

And you think they don't already HAVE the list?

Where do you think WE got it from? From people smurfing us!

The vandals ALREADY HAVE the list. I know this because we were attacked

But posting the list of blackholed sites publicly gives the attackers a list of sites not to bother trying to use...so they keep coming out with new&improved versions of smurf using networks that actually work.

The goal is to make the number of possible sources ZERO. If ISPs around the world refuse to forward directed broadcasts, it WILL be zero. If a provider loses connectivity to significant parts of the network, they'll fix their fscking routers. I'll note that one of the worst offenders right now, and the biggest sources, is APNIC's netblocks. There are huge, multi-T3-connected, smurf amplifiers on some of those network numbers. You'll find that in 203.64 there are multiple high-bandwidth sources with ENABLED directed broadcasts. Guess what? That entire /16 can't talk to us any more. I've tried talking to APNIC with no response. I've emailed every contact I can think of - nothing. Now I've told them to fsck off. They can either fix the damn thing or they can stuff connectivity to us up their behinds. I did this to huge parts of UUNET's infrastructure a few months ago. It *DID* get their attention, and smartly. At one time, not long back, their entire New York POP was one huge smurf amplifier of the worst kind - multiple MAX TNTs on 100BaseTX, all with directed broadcasts possible into their NICs. Ouch. We saw *sustained* loads in excess of 100Mbps coming from there. I blocked a /16, and two days later their CUSTOMERS started calling us asking why they couldn't talk to us any more. We told them why. Less than a week later it magically "fixed itself", although UUNET denied that they changed anything or that it was ever broken. Yeah, right. At least the problem got solved. Bluntly, I've had enough and so have my customers. Our IRC server is the recipient of daily attacks. Our *customers* DS1s are getting hit as well. While I can fix the IRC server problem by putting it on a Switched 100BaseTX port, that's not really a fix -- that's just making the firehose big enough that the jerks can't fill it. No more Mr. Nice Guy. I don't like getting paged at 3:00 AM because some two-bit punk got Klined off our IRC server for running clonebots and decided to smurf us in retaliation. My fix is to render all connectivity to and from the offending netblocks VOID until the owners fix their routers. These folks, by the way, are NOT clueless - they are DELIBERATELY ignoring the problem. The folks who can source significant smurfs today are NOT Joe's T1 and Grill. They are NATIONAL and INTERNATIONAL ISPs who damn well ought to know how to prevent this and why they should. The guy with a T1 can't hit us hard enough to even show up on our monitors. To make my blacklist you have to hit me with enough bandwidth that we *see* the problem, and that means you're at least mid-fractional-DS3 connected. If they're permitting this kind of behavior to take place *IT IS THEIR FAULT*, and has to be due to either deliberate lack of action or gross negligence. I'll KEEP adding netblocks to that access group as required, and keep posting the list. And I won't remove a single network from there until I've VERIFIED that they can no longer be used for this kind of vandalism. -- -- 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

Sorry, you don't understand. The worst thing in the smurf attack is not the attack itself (small IP flood, what's it? now the hackers have not really big amlifiers at their lists), but the fact the attacker originated source is faded usially. The best way to found the source of such attack is to trace echo-request packets directed to one or more smurf-amplified networks. If some (even some) network anounce _we keep on-line list of smurf-amplified address and control all attempts to send packets to this networks_, do you suppose hackers would work through this network? Any attempt to send smurf cause them to be discovered and disconnected; even if it's only anouncement, not real control, it's enougph to prevent a lot of hackets from the such attempts. The only way to fight against any kind of such attacks is to be sure any intruder should be fixed and disconnected in a few minutes. If I proclaim (anyone who attempt to break CITYLINE.RU ISP here should be killed by the gang of big and gloomy boys) do you think anyone in Moscow attampts to break CITYLINE? Even if he don't believe to this anouncement - but 10% for this to be true is enougph for hacker to be stopped. Just this case. While we are not seing every day _XXX was catched and disconnected due to attempt to run SMURF_ you can found any new ways to defend yourself - no matter, they discover new ways to attack you. If they think they can be catched - it's enougph. Remember, this intruders use small ISP as their service providers, not huge MCI or SPRINT. And you even don't need the full list of such amplified addresses to open some kind of monitoring against the smurfers. Btw, if someone cry here _I am smurfed from XX.XX.XX.XX address, what should you do to help him? I guess you should check (by IP accounting if you have it; by NetFlow accounting if you have it; or close you boredom and go home if you have not any) _are you sure the echo-request packets to this broadcast addresses are not originated from YOUR customer_.

...

May be, someone will maintain such lists? First, it allow to fix smurf source by 'log' option in the CISCO list; second, it'll prefere some attacks.

If Karl will supply us the IP address of a non-critical machine in his network then we only need one list maintained. Anyone can then add new networks to Karl's list simply by smurfing his non-critical machine and it will still meet his criteria of a verified atack.

-- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com

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)

On Sun, Apr 12, 1998 at 12:35:44PM -0700, Craig A. Huegen wrote:

On Sun, 12 Apr 1998, Alex P. Rudnev wrote:

==>Remember, this intruders use small ISP as their service providers, not ==>huge MCI or SPRINT.

Actually, the majority of these people use compromised root accounts in educational institutions, educational residence halls w/ Ethernet, enterprises w/o decent firewalls, and co-location machines.

There are lists which exist of over 200-300 compromised root accounts and access capabilities from which someone can launch an attack.

/cah

Yep. But the point still remains that if you can't get the traffic out of the source network a smurf attempt doesn't work. Those "educational" sites which allow residence hall connections to launch this kind of thing deserve to be permanently black-holed from the Internet until they fix things. And yes, I know this means they'll have to spend money. Tough cookies. This is NOT an unsolvable problem (I can solve it with a $1,000 PC running IPFW between the residence hall Ethernet and the rest of the campus, or a few statements in a CISCO config) so people saying its an intractable problem are lying. Period. -- -- 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

Or, call Cisco.. press 1 and tell them you are being smurfed. They will work with specialists and authorities to track down the attacker and rest assured, they will be dealth with. One thing I like about Cisco, is they don't fsck around!! They get right down to business. On Sun, 12 Apr 1998, Alex P. Rudnev wrote: :Sorry, you don't understand. : :The worst thing in the smurf attack is not the attack itself (small IP :flood, what's it? now the hackers have not really big amlifiers at their :lists), but the fact the attacker originated source is faded usially. The :best way to found the source of such attack is to trace echo-request :packets directed to one or more smurf-amplified networks. : :If some (even some) network anounce _we keep on-line list of :smurf-amplified address and control all attempts to send packets to this :networks_, do you suppose hackers would work through this network? Any :attempt to send smurf cause them to be discovered and disconnected; even :if it's only anouncement, not real control, it's enougph to prevent a lot :of hackets from the such attempts. : :The only way to fight against any kind of such attacks is to be sure any :intruder should be fixed and disconnected in a few minutes. If I proclaim :(anyone who attempt to break CITYLINE.RU ISP here should be killed by the :gang of big and gloomy boys) do you think anyone in Moscow attampts to :break CITYLINE? Even if he don't believe to this anouncement - but 10% :for this to be true is enougph for hacker to be stopped. : :Just this case. While we are not seing every day _XXX was catched and :disconnected due to attempt to run SMURF_ you can found any new ways to :defend yourself - no matter, they discover new ways to attack you. If :they think they can be catched - it's enougph. : :Remember, this intruders use small ISP as their service providers, not :huge MCI or SPRINT. : :And you even don't need the full list of such amplified addresses to open :some kind of monitoring against the smurfers. : :Btw, if someone cry here _I am smurfed from XX.XX.XX.XX address, what :should you do to help him? I guess you should check (by IP accounting if :you have it; by NetFlow accounting if you have it; or close you boredom :and go home if you have not any) _are you sure the echo-request :packets to this broadcast addresses are not originated from YOUR customer_. : : : :> :> > May be, someone will maintain such lists? First, it allow to fix smurf :> > source by 'log' option in the CISCO list; second, it'll prefere some :> > attacks. :> :> If Karl will supply us the IP address of a non-critical machine in his :> network then we only need one list maintained. Anyone can then add new :> networks to Karl's list simply by smurfing his non-critical machine and it :> will still meet his criteria of a verified atack. :> :> -- :> Michael Dillon - Internet & ISP Consulting :> http://www.memra.com - E-mail: michael@memra.com :> :> :> : :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) : -- Regards, Jason A. Lixfeld jlixfeld@idirect.ca System Administrator [L5] 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 just came to realize that there is one big problem with using BGP to blackhole these SMURF-amplifier sites. Put really simply, if you create a BGP blackhole all you do is prevent your packets from getting to their network - not the converse. While being listed on a blackhole list which affects connectivity might be enough to encourage people to set no ip directed-broadcast or equivalent on appropriate interfaces, I'd rather see a real filter set which I can drop the packets at my internet-facing edges. How to update the filter set dynamically is another issue that I'd like to hear about. Am I thinking correctly here or am I missing some convoluted BGP configuration? - 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 Sun, 12 Apr 1998, Forrest W. Christian wrote:

My opinion is that we need to fix some RFC's to help eliminate the SMURF problem and other problems.

Look closely. I already posted this mentioning RFC 2267 If anyone at an educational institution tells you that send them to UCLA http://www.math.ucla.edu/misc/smurf.html or Simon Fraser University http://www.cs.sfu.ca/CC/Hypermail/cmpt-471/0008.html or the RFC archive at USC's Information Sciences Institute ftp://ftp.isi.edu/in-notes/rfc2267.txt or the Computer Emergency Response Team at Carnegie Mellon University http://www.cert.org/advisories/CA-98.01.smurf.html Here's an excerpt from a message I posted to another list with a good URL:

I'm STILL lost. How am I going to "localize the effect" of my downstream - who have not set "no ip directed broadcast" - being used as a SMURF amplifier? As for helping them fix it, how does that relate to "DEMANDING" the upstream fix the upstream's config?

Here is a URL with some info http://www.quadrunner.com/~chuegen/smurf.cgi Here is what I mean. -------------*-*-*-*- * - * - * * the void... :-) | FFF UUUUU OBOBOB | F = Fred's Network FFF----UUUUU---OBOBOB-- P = Patrick's Network FFF UUUUU OBOBOB U = Upstream provider for Fred and Patrick | | OB = Other Backbone provider PPP VVV V = Victim of the Smurf attack PPP VVV PPP VVV Now some mean guy out there in the void decides to attack the poor victim network by sending spoofed source packets to the broadcast address of Fred's network. The spoofed source address is that of the victim so that all the echo replies from the machines on Fred's network go to the victim's network. Now why should Patrick care? Why should he be demanding that his upstream do something about it? Because if the Upstream does nothing, people out there on the net may well start to block all of Upstream's address blocks. So Patrick can demand that his upstream take action to make sure that no SMURF amplifiers are downstream of them. Patrick has no business relationship with Fred but both have a business relationship with the Upstream. The Upstream could remind Fred that he must fix his routers according to their TOS or AUP. Or they could help Fred fix his routers. Or they could disconnect Fred. Or they could block all traffic to ?.?.?.255 in Fred's network. In fact, Upstream could regularly scan all of its address space to find misconfigured routers and help them fix this problem. If you have some time for code hacking maybe you could hack smurf or fraggle to create a program that does this.

Is there a review of the Router and Host requirements RFC's in the works? Specifically, to review those areas which could be changed to fix some of these problems.

RFCs take a long time to change, especially standards track RFCs. But it isn't that hard to get an informational RFC like 2267 published.

For example, the directed broadcast stuff should be written to basically say that the DEFAULT must be for the directed broadcasts to be off.

There are no guns in the IETF. Basically the RFCs should say exactly what they do say because that's the best consensus that people could reach. Maybe you could convince them to revise the RFC but you'll need to fully understand the entire scope of the protocol design, not just current operational issues. But that's something that needs to be discussed elsewhere. http://www.ietf.org Might be worthwhile for someone to spend a half hour explaining the directed broadcast issues at the next NANOG meeting? -- Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael@memra.com

On Sun, Apr 12, 1998 at 01:57:00PM -0500, Karl Denninger wrote:

Well, the kiddies think the IRC server is non-critical :-)

***sjsobol makes a mental note to use irc.cs.cmu.edu instead of irc.mcs.net. -- Steve Sobol, Tech Support Guru, NACS.NET [http://www.nacs.net/support] Visit Shawn Kemp's website... Reignman info, merchandise and more!! http://www.reignman.com