While we're working out problems on the IETF SAVA list, I'd like
to float this here (if you haven't already seen it), and hear some
comments from the NANOG landscape.
Is this relevant?
Thanks,
- ferg
[snip]
Interesting this should come up. I run a small multihomed network in Reno, NV, with a couple /21s and 65 megabits of upstream. For the last few weeks, one of my co-location customers has been attacked with SYN floods with forged source-IP addresses, overloading the SonicWall he has, and when the SonicWall folds under the traffic I get ARP storms in that LAN segment.
Traffic capture shows that the perps are using bogus source packet addresses to hide their activities. This is confirmed by my ingress BOGON filters, whose counters start spinning at an aggregate rate of 6,000 packets per second. The bandwidth impact is fairly low -- this is a SYN flood attack, after all.
When I contacted my upstream, he tells me that the packets were coming in from *every one* of his Tier 1 peers, so the packets were impossible to trace back to their source. That says the injection point was quite a few hops away from his routers, if the traffic was able to spread that widely across multiple Tier 1 networks.
I had to use other means to stop these DDoS attacks.
My own network policy:
* I deny packets from my customers to the Internet whose source address is *not* within my assigned netblocks. Any such attempt is logged and followed up. I also specifically check for network and broadcast addresses, and deny packets with those addresses, too.
* I deny packets from the Internet to my customers whose source address *is* in my netblocks, to prevent secondary attacks. (This filtering also exposes routing mistakes *very* quickly.)
* I deny packets from the Internet to my customers whose source address appears in a BOGON list, manually maintained. My BOGON list includes RFC 1918 netblocks (but see below).
* I null-route packets from my customers to the Internet directed to RFC 1918 private-network netblocks. This is a "belt and suspenders" type action, so there is zero leakage either inbound or outbound.
To implement these policies, I maintain a single copy each of the ingress and egress access lists on a protected TFTP server. All edits of the access list go into these master lists, under version control. Periodically, or when necessary because of update or attack, the master lists are loaded into all edge routers at the same time. This ensures that all routers have the *same* list, that updates are propagated to *all* ingress/egress filters, and it simplifies maintenance.
REQUEST FOR COMMENT: For maintenance reasons, my BOGON rules are limited to full /8s. I'm interested in comments from others on tge effectiveness of building in more rules based on longer prefixes, to /10 or /12 or perhaps even /16, so that /8s with small allocations get better coverage in the ACL list.
TESTIMONIAL: I have had attackers establish themselves on my network, and also attackers from outside try to nail a customer. BCP38 has helped lessen the impact of the inbound attacks, and stopped the outbound attacks cold. Most importantly, though, BCP38 allows the customers not being attacked to be minimally affected during any attack.
Fergie wrote: