This is why the government needs to get involved and *demand* that the ability exist via a *protocol* for people in a NOC to initiate and follow these traces automatically, without human intervention by the NOCs in the chain.
Would you and other operators be willing to modify peering agreements to include serious fines for running a smurf amplifier or allowing packets with bogus source addresses to enter the system? Tracking back bogus source addresses seems hard. Would fines on smurf amplifiers be good enough to fix the smurf problem? Or do we need to catch a smurfer to use as an example? Currently, NOCs don't have much financial interest in tracking down a smurfer. Karl's stories of non-cooperation make sense if the NOC is looking at their (short term) bottom line rather than the good of the net. The person on the phone won't get any reward for solving Karl's problem (and might get in trouble for sticking his neck out). Is there a way we can change that? One possibility might be to offer a reward to the NOC that gets the evidence on the first smurfer to get tossed in jail or fined more than $100K. Another might be to setup peering contracts that encourage ISPs/NSPs to track down smurfers. I can't quite come up with the right thing to suggest. Everything I think of has too many possibilities for gaming. I'm fishing for something like each ISP/NSP that works on tracking down a smurfer gets to charge the ISP/NSP closer to the source for the time and costs it spends on the problem, including the costs that get passed to it. How much effort is involved in tracking a smurfer through each router? Any router vendors willing to estimate how much it would cost to implement something like Karl's proposed command?
"trace-smurf <forged-victim-address> <amplifier-address>" <return>
Do smurf attacks always happen late at night and on weekends? Would major NSPs be willing to setup a smurf hotline so trusted smart people, like Karl, could bypass the first several layers of screening and get the data to the right person fast?
Well DoS and smurf are only different in terms of the packet amounts and method to convey them, so in essence A smurf is another form of DoS on A larger scale. An existing law already covers that. If A NOC refuses to obey the law and investigate on behalf of a paying client that DoS has occurred than they become party to a criminal act after the fact and are as guilty as the originator of the attack and can be held accountable and their staff can arrested and you have the right to sue for $4000.00 as do each one of your individual customers. Sometimes you have to look at what you have and realize how to use it for the benefit of the whole. As for smurfs crossing international borders where such attacks generally occur from, A group representation to the FCC needs to be formed and the FCC needs then to communicate with its counterpart on the foreign soil using existing treaties that would make that a violation of non aggression pacts and interference in a foreign government and denial of its citizens to communicate pursuant to their constitution the right of free speech. In A technical sense smurfs from foreign shores are an act of war on networks of the United States by the purposeful intent to disrupt destroy and cripple its computer network infrastructure with A Smurfing mechanism. Henry R. Linneweh Hal Murray wrote:
This is why the government needs to get involved and *demand* that the ability exist via a *protocol* for people in a NOC to initiate and follow these traces automatically, without human intervention by the NOCs in the chain.
Would you and other operators be willing to modify peering agreements to include serious fines for running a smurf amplifier or allowing packets with bogus source addresses to enter the system?
Tracking back bogus source addresses seems hard. Would fines on smurf amplifiers be good enough to fix the smurf problem? Or do we need to catch a smurfer to use as an example?
Currently, NOCs don't have much financial interest in tracking down a smurfer.
Karl's stories of non-cooperation make sense if the NOC is looking at their (short term) bottom line rather than the good of the net. The person on the phone won't get any reward for solving Karl's problem (and might get in trouble for sticking his neck out).
Is there a way we can change that?
One possibility might be to offer a reward to the NOC that gets the evidence on the first smurfer to get tossed in jail or fined more than $100K.
Another might be to setup peering contracts that encourage ISPs/NSPs to track down smurfers.
I can't quite come up with the right thing to suggest. Everything I think of has too many possibilities for gaming.
I'm fishing for something like each ISP/NSP that works on tracking down a smurfer gets to charge the ISP/NSP closer to the source for the time and costs it spends on the problem, including the costs that get passed to it.
How much effort is involved in tracking a smurfer through each router?
Any router vendors willing to estimate how much it would cost to implement something like Karl's proposed command?
"trace-smurf <forged-victim-address> <amplifier-address>" <return>
Do smurf attacks always happen late at night and on weekends?
Would major NSPs be willing to setup a smurf hotline so trusted smart people, like Karl, could bypass the first several layers of screening and get the data to the right person fast?
-- ¢4i1å
On Sat, 20 Jun 1998, Henry Linneweh wrote:
Well DoS and smurf are only different in terms of the packet amounts and method to convey them, so in essence A smurf is another form of DoS on A larger scale. An existing law already covers that.
How do you come up with that? A DoS attack is anything that makes a resource on a host or network unusable. Let's remember that the whole point of the attack is to deny service, whether it be pop3 service with a syn flood or bandwidth with smurf, fraggle, or generic ping flood. A smurf attack is a DoS is a DoS is a DoS.
If A NOC refuses to obey the law and investigate on behalf of a paying client that DoS has occurred than they become party to a criminal act after the fact and are as guilty as the originator of the attack and can be held accountable and their staff can arrested and you have the right to sue for $4000.00 as do each one of your individual customers.
I've never heard a NOC say they wouldn't track it down, although I'm sure it's happened in the past. Mostly I've heard that a NOC was incapable of tracking it down because of router overhead. Not to mention the packets are almost always going to be traced back to the known smurf amplifiers. If it was easy to find people responsible for the operations of those nets and get them on the horn we could have had the smurf problem fixed a long time ago. I would like to see if taking one of those people into court for being an unknowing party to the crime would be effective.
Sometimes you have to look at what you have and realize how to use it for the benefit of the whole.
Indeed, but how many people want to invest the time and money involved in prosecuting a smurf attack? Has anyone successfully done it yet?
As for smurfs crossing international borders where such attacks generally occur from, A group representation to the FCC needs to be formed and the FCC needs then to communicate with its counterpart on the foreign soil using existing treaties that would make that a violation of non aggression pacts and interference in a foreign government and denial of its citizens to communicate pursuant to their constitution the right of free speech.
In A technical sense smurfs from foreign shores are an act of war on networks of the United States by the purposeful intent to disrupt destroy and cripple its computer network infrastructure with A Smurfing mechanism.
Henry R. Linneweh
What needs to happen is things like IPSec, ISAKMP, and Oakley become prime time so authenticating packets becomes a trivial issue. However, the U.S. Crypto Nazis make it impossible for it to be developed in this country because if it is, then it cannot be exported to other countries unless in a weakened state. I don't claim to be a crypto person, but when you think about how the game is played, getting to the real root of the problem may not be an answer you like. I'm as patriotic as the next guy [you can read that however you like], but for crypto authentication solutions to work our government needs to get their hands out of it. Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
Now that we have gotten down to the nitty gritty here. AGAIN the main mechanism for spoofing the smurf attacks is A program call wingate, ban that code and this problem will be cut more than in half. Next there is a rumor that 8000 users have been infected with a tweaked system.exe file that makes that user a smurf amplifier unwittingly. These are things to watch for. I wish there was an easier way to break bad news. Henry Joe Shaw wrote:
On Sat, 20 Jun 1998, Henry Linneweh wrote:
Well DoS and smurf are only different in terms of the packet amounts and method to convey them, so in essence A smurf is another form of DoS on A larger scale. An existing law already covers that.
How do you come up with that? A DoS attack is anything that makes a resource on a host or network unusable. Let's remember that the whole point of the attack is to deny service, whether it be pop3 service with a syn flood or bandwidth with smurf, fraggle, or generic ping flood. A smurf attack is a DoS is a DoS is a DoS.
If A NOC refuses to obey the law and investigate on behalf of a paying client that DoS has occurred than they become party to a criminal act after the fact and are as guilty as the originator of the attack and can be held accountable and their staff can arrested and you have the right to sue for $4000.00 as do each one of your individual customers.
I've never heard a NOC say they wouldn't track it down, although I'm sure it's happened in the past. Mostly I've heard that a NOC was incapable of tracking it down because of router overhead. Not to mention the packets are almost always going to be traced back to the known smurf amplifiers. If it was easy to find people responsible for the operations of those nets and get them on the horn we could have had the smurf problem fixed a long time ago. I would like to see if taking one of those people into court for being an unknowing party to the crime would be effective.
Sometimes you have to look at what you have and realize how to use it for the benefit of the whole.
Indeed, but how many people want to invest the time and money involved in prosecuting a smurf attack? Has anyone successfully done it yet?
As for smurfs crossing international borders where such attacks generally occur from, A group representation to the FCC needs to be formed and the FCC needs then to communicate with its counterpart on the foreign soil using existing treaties that would make that a violation of non aggression pacts and interference in a foreign government and denial of its citizens to communicate pursuant to their constitution the right of free speech.
In A technical sense smurfs from foreign shores are an act of war on networks of the United States by the purposeful intent to disrupt destroy and cripple its computer network infrastructure with A Smurfing mechanism.
Henry R. Linneweh
What needs to happen is things like IPSec, ISAKMP, and Oakley become prime time so authenticating packets becomes a trivial issue. However, the U.S. Crypto Nazis make it impossible for it to be developed in this country because if it is, then it cannot be exported to other countries unless in a weakened state. I don't claim to be a crypto person, but when you think about how the game is played, getting to the real root of the problem may not be an answer you like. I'm as patriotic as the next guy [you can read that however you like], but for crypto authentication solutions to work our government needs to get their hands out of it.
Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
-- ¢4i1å
Henry Linneweh wrote:
Now that we have gotten down to the nitty gritty here.
AGAIN the main mechanism for spoofing the smurf attacks is A program call wingate, ban that code and this problem will be cut more than in half.
Really? Wow - it's truly amazing noone's come up with such a simple solution so far. Watch out for the photographers - you'll inevitably be ambushed. My hero :-) Cheers, Brian -- Brian Wallingford Network Operations Manager Meganet Communications, TCIx, Inc.
At 06:25 6/21/98 -0400, you wrote:
Henry Linneweh wrote:
Now that we have gotten down to the nitty gritty here.
AGAIN the main mechanism for spoofing the smurf attacks is A program call wingate, ban that code and this problem will be cut more than in half.
Really? Wow - it's truly amazing noone's come up with such a simple solution so far. Watch out for the photographers - you'll inevitably be ambushed. My hero :-)
Kewl! "Wingate, thou art banned!". Now, only half as many networks should be smurfed.... </sarcasm></sarcasm> What do spammers and nails have in common? They're both intended for hammering. Dean Robb PC-Easy On-site computer services (757) 495-EASY [3279]
For those who missed or would like to review the proceedings of the most recent NANOG (Dearborn), I've finally managed to cut up the 60kbit live archives of the individual presentations from Monday & Tuesday (including the Monday evening BOF) & put them up on a few servers. There was some great presentations...hit http://www.nanog.org/mtg-9806/agen0698.html to visit the clips. Feel free to share these with friends & colleagues. Jeffrey Payne GM, Broadcast Operations, RealNetworks 206.674.2364
On Sun, 21 Jun 1998, Henry Linneweh wrote:
Now that we have gotten down to the nitty gritty here.
AGAIN the main mechanism for spoofing the smurf attacks is A program call wingate, ban that code and this problem will be cut more than in half.
What does wingate have to do with this? Smurf attack is the term used for an ICMP echo based denial of service attack caused by sending a forged icmp echo request to a brodcast network address. The attacker forges the source address of the icmp echo request to that of his victim, so all ICMP echo replies come back and flood the victim(s). Now, these packets can be hand forged by anyone with a moderate knowledge of C and root on a UN*X workstation. Don't fix the symptom, but fix the reason these attacks work. Packet authentication is the answer down the line, but for now it's getting the twonks with their networks open to fix the problem. This DoS can also be done with UDP echo, and UDP packets are much easier to forge/spoof than TCP.
Next there is a rumor that 8000 users have been infected with a tweaked system.exe file that makes that user a smurf amplifier unwittingly. These are things to watch for. I wish there was an easier way to break bad news.
I fell out of my chair at that statement. One user/host cannot be a smurf amplifier; one network from a /30 and down can with different results. Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services Any spelling mistakes and/or grammar errors are due to lack of sleep...
Henry
:: Joe Shaw writes ::
Next there is a rumor that 8000 users have been infected with a tweaked system.exe file that makes that user a smurf amplifier unwittingly. These are things to watch for. I wish there was an easier way to break bad news.
I fell out of my chair at that statement. One user/host cannot be a smurf amplifier; one network from a /30 and down can with different results.
If I modify my kernel to generate 100 ECHO REPLYs for each ICMP ECHO I recieve, how is my PC signifigantly different than a /24 behind a router that doens't have "no ip directed-boradcast" (or it's equivalent) configured, with 100 devices on it that all respond to ICMP ECHOs addressed to the boracast address? I'm not saying that I believe this rumor (or even that I've heard it before now), nor am I saying that the rumor has as much thought behind it as my previous paragraph does, nor am I saying that if you were going to implement such a thing on a Windows machine that you would implement it in system.exe. (I'm not even saying that system.exe exists.) But I am saying that such a thing is technically feasible. And I am saying that there are people out there who are not above writing a virus that facilitiate the use of other people's machines in DOS attacks. - Brett (brettf@netcom.com) ------------------------------------------------------------------------------ ... Coming soon to a | Brett Frankenberger .sig near you ... a Humorous Quote ... | brettf@netcom.com
On Sun, 21 Jun 1998, Brett Frankenberger wrote:
I fell out of my chair at that statement. One user/host cannot be a smurf amplifier; one network from a /30 and down can with different results.
If I modify my kernel to generate 100 ECHO REPLYs for each ICMP ECHO I recieve, how is my PC signifigantly different than a /24 behind a router that doens't have "no ip directed-boradcast" (or it's equivalent) configured, with 100 devices on it that all respond to ICMP ECHOs addressed to the boracast address?
Point noted. Damn, I get stuck every time I use a blanket statement like that. True, in your case it could be possible, but modifying the kernel of a workstation to behave like that would be somewhat foolish since it would be easily tracked back to that workstations IP address by the traffic log most clued admins would put in place when they found they were under attack. If someone is capable of modifying the kernel of a machine that doesn't belong to them, then smurf is the least of their worries; they've got a compromise to deal with. And I think in the case you've presented, it would be easy to point back to the compromised host, not that it would do you any good if the people responsible wouldn't act on the problem.
I'm not saying that I believe this rumor (or even that I've heard it before now), nor am I saying that the rumor has as much thought behind it as my previous paragraph does, nor am I saying that if you were going to implement such a thing on a Windows machine that you would implement it in system.exe. (I'm not even saying that system.exe exists.)
Hehe... Plausible (sp?) deniability? :)
But I am saying that such a thing is technically feasible. And I am saying that there are people out there who are not above writing a virus that facilitiate the use of other people's machines in DOS attacks.
Agreed. I think to be more accurate, I should say that an instance like that hasn't presented itself yet. But, it's entirely possible someone with half a clue might be able to do it on a windows box, and it's certainly possible on various UN*X platforms. The question is, would someone with that kind of skill be willing to do something with those kind of implications? If they are capable of that then a smurf attack is somewhat trivial. However, I think we're getting off topic for the list, but I'd be more than happy to continue this discussion off-list.
- Brett (brettf@netcom.com)
Regards, Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
On Sun, 21 Jun 1998, Brett Frankenberger wrote:
:: Joe Shaw writes ::
Next there is a rumor that 8000 users have been infected with a tweaked system.exe file that makes that user a smurf amplifier unwittingly. These are things to watch for. I wish there was an easier way to break bad news.
I fell out of my chair at that statement. One user/host cannot be a smurf amplifier; one network from a /30 and down can with different results.
If I modify my kernel to generate 100 ECHO REPLYs for each ICMP ECHO I recieve, how is my PC signifigantly different than a /24 behind a router that doens't have "no ip directed-boradcast" (or it's equivalent) configured, with 100 devices on it that all respond to ICMP ECHOs addressed to the boracast address?
It's certainly different- a standard smurf gets n replies for each packet received, if you have one hundred hosts, that's 100 replys for each echo request. A single host sending out 100 replys is no different than a pingflood, which can't flood more than a serial dialup line. The volume of replys is 100 times greater for the 100 host network. As for a "patched system.exe", if it exists, it could be problematic. There is nothing preventing a workstation from receiving an ICMP echo request and rebroadcasting it on the LAN with a spoofed source address. Egress filters on the originator network would be ineffective because the original packet would have a true source address in it. The destination machine would accept the packet and spoof it onto its local network, which would generate (n) replies, which would not be filtered on their way out of the network to the remote address. The patched system would not log incoming packets, so the only way to track it down would be to find the local machine that is sending broadcasts to the local lan with spoofed source addresses, and sniff for remote-originated packets destined for that machine. The only upside is that you'd have the actual ip of the originator. Brian Pape Computer Resource Services University California Los Angeles pape@mail.ph.ucla.edu x59284
On Sat, Jun 20, 1998 at 02:02:32AM -0700, Hal Murray wrote:
This is why the government needs to get involved and *demand* that the ability exist via a *protocol* for people in a NOC to initiate and follow these traces automatically, without human intervention by the NOCs in the chain.
Would you and other operators be willing to modify peering agreements to include serious fines for running a smurf amplifier or allowing packets with bogus source addresses to enter the system?
It won't happen (try to get that written into one - hah!)
Tracking back bogus source addresses seems hard. Would fines on smurf amplifiers be good enough to fix the smurf problem? Or do we need to catch a smurfer to use as an example?
Preventing bogus source addresses isn't hard. Its not done because people are lazy and don't care about their neighbors - this is a "not in my back yard" problem.
Currently, NOCs don't have much financial interest in tracking down a smurfer.
Actually, some NOCs have a financial incentive to BE amplifiers (consider someone connected on a bit-rate-sensitive billing plan)
Karl's stories of non-cooperation make sense if the NOC is looking at their (short term) bottom line rather than the good of the net.
Yep. Surprise.
Is there a way we can change that?
Bring charges?
I can't quite come up with the right thing to suggest. Everything I think of has too many possibilities for gaming.
I'm fishing for something like each ISP/NSP that works on tracking down a smurfer gets to charge the ISP/NSP closer to the source for the time and costs it spends on the problem, including the costs that get passed to it.
How much effort is involved in tracking a smurfer through each router?
Not a lot, but non-zero. The problem is that you have to catch it while the attack is in process. The REAL solution to this problem is for people to prevent address spoofing on their leaf connections. That is, for leaf connections, if you do not have a route back to the source from which you came, you drop the packet - period. If the LEAF nodes all did this, then the problem would already be gone.
Any router vendors willing to estimate how much it would cost to implement something like Karl's proposed command?
"trace-smurf <forged-victim-address> <amplifier-address>" <return>
Do smurf attacks always happen late at night and on weekends?
No. We just got hit for a few minutes at 9:15 this morning.
Would major NSPs be willing to setup a smurf hotline so trusted smart people, like Karl, could bypass the first several layers of screening and get the data to the right person fast?
That would be a good start. -- -- 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
participants (9)
-
Brett Frankenberger -
Brian Pape -
Brian Wallingford -
Dean Robb -
Hal Murray -
Henry Linneweh -
Jeffrey Payne -
Joe Shaw -
Karl Denninger