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
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.
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.