ip directed-broadcast
This morning Sprint dropped the icmp echo reply filter in their link (t1) to my network in mid "smurf" attack. The link was immediately swamped to the point of multi-hundred ms average transit times, normally 12ms. I removed this link from service (temporarily, I was thinking) and called the Sprint Noc to try to resolve this problem. I was informed of the following, by the manager that indicated that he handles backbone-to-customer filter policy: 1.) they will not continue to try to trace this. (they had made some previous unsuccessful efforts) 2.) they will no longer filter icmp echo reply for me, even though they understand that my link is now useless without that. They do not have cpu cycles to spare for this purpose. 3.) they do not see this type of attack very often and don't consider it much of a problem. I find this rather perplexing to say the least. Comments? This attack is an ongoing problem so I hope it is seen as an operational issue. It is beginning to be a chronic problem (4 day duration). The US Secret Service, Computer Crime Division is apparently having resource problems. I should also commend UUnet and Agis for their excellent assistance in working with me to keep my network operational. Ken Leland Monmouth Internet
On Mon, 29 Dec 1997, Ken Leland wrote:
I was informed of the following, by the manager that indicated that he handles backbone-to-customer filter policy:
1.) they will not continue to try to trace this. (they had made some previous unsuccessful efforts)
Strike 1.
2.) they will no longer filter icmp echo reply for me, even though they understand that my link is now useless without that. They do not have cpu cycles to spare for this purpose.
Somewhat understandable...but perhaps they should have designed their network a little better and not overloaded their routers to point that one or few line filters push the CPU over the edge....Strike 2.
3.) they do not see this type of attack very often and don't consider it much of a problem.
Sure...it causes them very little trouble. Odds are good their NOC gets smurfed very rarely. Strike 3.
I find this rather perplexing to say the least. Comments?
I don't know about Sprint, but UUNET actually has provisions in their T1 customer contracts for refunds for interruption of service. Even if you don't have such provisions in your contract with Sprint, I'd get on the phone to your sales rep and as high a person as you can get to in their NOC and let them know that you consider your T1 to Sprint unusable, and do not intend to pay the next bill...at least no in full.
This attack is an ongoing problem so I hope it is seen as an operational issue. It is beginning to be a chronic problem (4 day duration).
FDT used to have major problems with smurf attacks...I was getting to be on a first name basis with most of UUNET's NOC graveyard shift. They'd usually put in a temporary filter to stop the attack, though sometimes it took longer than other's. What finally stopped the attacks was looking at who/what was being attacked. At least in our case, systems weren't being smurfed just for the heck of it. Generally, there was something going on that was (justifiably or not) pissing someone somewhere off. Make sure your users and systems are behaving, and the smurfing is likely to stop. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
Jon wrote:
about what I wrote:
1.) they will not continue to try to trace this. (they had made some previous unsuccessful efforts)
Strike 1.
2.) they will no longer filter icmp echo reply for me, even though they understand that my link is now useless without that. They do not have cpu cycles to spare for this purpose.
or few line filters push the CPU over the edge....Strike 2.
3.) they do not see this type of attack very often and don't consider it much of a problem.
Sure...it causes them very little trouble. Odds are good their NOC gets smurfed very rarely. Strike 3.
Yep 3 strikes and you're out. Sad, I've gotten excellent service from this provider until this recent policy snafu.
NOC and let them know that you consider your T1 to Sprint unusable, and do not intend to pay the next bill...at least no in full.
calls into the account rep already placed on this issue.
FDT used to have major problems with smurf attacks...I was getting to be on a first name basis with most of UUNET's NOC graveyard shift. They'd usually put in a temporary filter to stop the attack, though sometimes it took longer than other's. What finally stopped the attacks was looking at who/what was being attacked. At least in our case, systems weren't being smurfed just for the heck of it. Generally, there was something going on that was (justifiably or not) pissing someone somewhere off. Make sure your users and systems are behaving, and the smurfing is likely to stop.
Yep, I know right off hand of several possibilities. A possibly disgruntled former employee who just lost a case against us in court the day before the attack started, or a guy that posts rather obnoxious stuff to the local nj newsgroups that a lot of people dislike, etc. With 7000 customers, you will ocasionally find one that is not as polite as he(she) should be. We do respond quickly to abuse/postmaster/sysadmin complaints so I don't believe we are sitting on pentup outrage over our customers abusing other networks/systems with no recourse. Of course, this could be a snit where the other side doesn't particularly want to tell their story to management types. Ken Leland
Jon Lewis put this into my mailbox:
FDT used to have major problems with smurf attacks...I was getting to be on a first name basis with most of UUNET's NOC graveyard shift. They'd usually put in a temporary filter to stop the attack, though sometimes it took longer than other's. What finally stopped the attacks was looking at who/what was being attacked. At least in our case, systems weren't being smurfed just for the heck of it. Generally, there was something going on that was (justifiably or not) pissing someone somewhere off. Make sure your users and systems are behaving, and the smurfing is likely to stop.
I agree with this, to an extent. However, not all cases are like this. We've been dealing with a particular smurfer for a little over a month and a half now. Basically, this person will sit and spam people. If we try to block or disconnect him, he automatically smurfs one of our servers from one of his hacked accounts, of which he has quite a few. We've managed to trace him back to a few Aussie ISPs, and have gotten responses out of some of the people in charge of the machines he's hacked, but at this point I'm getting mighty sick of people ignoring our e-mails and phone calls (one Aussie *dialup* ISP comes to mind), and I'm trying to figure out how best to sum up the situation to the FBI computer crimes division. (I'm planning to go to them with a list of things we can charge this person with, including theft of service, extortion, and blackmail..) The moral is, though, some of your users could just be going about their business normally, and someone who doesn't take 'no' for an answer is using smurfing to get what they want. (This is also why I currently have the attitude that if your network isn't protected against smurf-broadcasting, or it isn't filtering spoofing, or your machines aren't adequately monitored to ensure that accounts don't get hacked, then you don't deserve to be connected to the internet, and should pay the rest of us for the trouble of cleaning up your messes.) -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) I once heard the voice of God. It Founder, the DALnet IRC Network said "Vrrrrrmmmmmm." Unless it was just a lawn mower. e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
On Mon, Dec 29, 1997 at 12:42:50PM -0500, Jon Lewis wrote:
2.) they will no longer filter icmp echo reply for me, even though they understand that my link is now useless without that. They do not have cpu cycles to spare for this purpose.
Somewhat understandable...but perhaps they should have designed their network a little better and not overloaded their routers to point that one or few line filters push the CPU over the edge....Strike 2.
3.) they do not see this type of attack very often and don't consider it much of a problem.
Sure...it causes them very little trouble. Odds are good their NOC gets smurfed very rarely. Strike 3.
We have a T-1 to Sprint, served out of their Ft. Worth POP. If I down the T on our end, does anyone know if the Sprint (or MCI, or UUNET, etc) router will send back ICMP host/network unreachable messages? I ask because if the core routers DO send back ICMP host/network unreachables and a customer that is being smurfed turns down their T, I'd imagine that the core router would generate a heck of a lot of traffic. It might be enough to catch someone's attention. -- Eric, who does not have a lot of patience with companies that don't seem to care about smurfing. -- Eric Wieling (eric@ccti.net), Corporate Communications Technology Sales: 504-585-7303 (sales@ccti.net), Support: 504-525-5449 (support@ccti.net) Paranoia: It's not just for breakfast anymore.
participants (4)
-
Dalvenjah FoxFire -
Eric Wieling -
Jon Lewis -
Ken Leland