Hot Diggety! Doug Davis was rumored to have said...
19:56:56.854432 snap 0:0:0:8:0 37.31.237.183.1900 > 206.66.14.112.57039: S 674719801:674719801(0) win 65535 (ttl 21, id 13333)
19:56:56.854432 snap 0:0:0:8:0 76.167.191.100.1900 > 206.66.14.112.57040: S 674719801:674719801(0) win 65535 (ttl 21, id 13334)
19:56:56.854432 snap 0:0:0:8:0 131.254.10.213.1900 > 206.66.14.112.57041: S 674719801:674719801(0) win 65535 (ttl 21, id 13335)
19:56:56.855409 snap 0:0:0:8:0 74.60.41.73.1900 > 206.66.14.112.57042: S 674719801:674719801(0) win 65535 (ttl 21, id 13336)
Ouch...painful. A whole lot of SYNs with forged source address, eh? Hmm...
interesting. Karl, if I might ask - did your attack originate from any specific
port, like 1900 as is listed here?
I'm just curious since I'd like to get a rough idea if there's some program
other than smurf.c out there that makes use of a specific port by default,
or if this is just a one time occurence by a few separate idiots.
And as usual, thanks for the heads up from folks on NANOG.
-Dan Foster
Frontier Internet
Internet: dsf@frontiernet.net
No. This was a transmission of 1K packets and was not in the style of any
previously-seen attack that I'm aware of. Its a new thing.
There was no attempt to SYN flood, or hit broadcast addresses, or use
source-routing. All of that is protected against fairly well here. This
was a simple "the machines are on a 10Mbps pipe, so hit them with 30Mbps of
traffic and flood their NIC ports to the point that they're useless".
That's exactly what we saw here as well, except we did see some broadcast
traffic. They hit us with so much traffic that our 10Mbps link was
useless. The offending sites I got were 192.195.100.1, 128.132.45.105,
167.152.96.78, but according to the customer they believe those to be
forged. I'm almost certain that at least some of these sites had to be
used, as the source routed traffic should have been stopped at the router.
This did stop the traffic from coming through, but it didn't stop it from
killing the link once it got here.
Joe Shaw - jshaw@insync.net
NetAdmin - Insync Internet Services
Our core doesn't pass source-routed traffic at all, nor will it forward
traffic destined for a MAC-layer broadcast address anywhere on our core.
This doesn't make it impossible to forge packets and play games, but it
sure makes it more difficult.
If you have the cooperation of those you interconnect with during an attack
with this configuration, it makes it rather easy to find the source of the
packets, assuming that they continue for some period of time.
I can think of only one way to do this which wouldn't involve sourcing the
streams from the indicated machines *and* generate the kind of volume we
saw. I won't go into it here, because it would be trivial to do, and it
might be what actually happened. But if it *IS* then I'm even more pissed
off, because that points to severe and unconscionable misconfiguration of
hardware within UUNET's core.
If *that* is the case then we're going to block all packets eminating from
address range(s) implicated in this kind of attack, now or in the future,
until the guilty parties fix their configurations.