Krebs on Security booted off Akamai network after DDoS attack proves pricey

Sun Sep 25 22:59:15 UTC 2016

On 09/25/2016 07:32 AM, Jay R. Ashworth wrote:
>> From: "Jay Farrell via NANOG" <nanog at nanog.org>
>> > And of course Brian Krebs has a thing or two to say, not the least is which
>> > to push for BCP38 (good luck with that, right?).
>> >
>> > https://krebsonsecurity.com/2016/09/the-democratization-of-censorship/
> Well, given how few contributions we've gotten at bcp38.info in the last,
> what, 4 years, yeah, I guess so...
>

Yeah, right.  I looked at BCP38.info, and there is very little concrete 
information.  I've been slogging through the two RFCs, 2827 and 3794, 
and find it tough sledding to extract the nuggets to put into my 
firewall and routing table.  One of the more interesting new additions 
to my systems is this, to the routing tables:

ip route add blackhole 0.0.0.0/32	# broadcast (deprecated)
ip route add blackhole 0.0.0.0/8 	# “this”
ip route add blackhole 10.0.0.0/8 	# private network
ip route add blackhole 100.64.0.0/10 	# carrier-grade NAT
ip route add blackhole 127.0.0.0/8 	# loopback
ip route add blackhole 169.254.0.0/16 	# link-local
ip route add blackhole 172.16.0.0/12 	# private network
ip route add blackhole 192.0.0.0/24	# IANA special purpose registry
ip route add blackhole 192.0.2.0/24	# TEST-NET
ip route add blackhole 192.88.99.0/24	# 6to4 anycast relay (optional)
ip route add blackhole 192.168.0.0/16	# private network
ip route add blackhole 198.18.0.0/15	# inter-network testing
ip route add blackhole 198.51.100.0/24	# TEST-NET-2
ip route add blackhole 203.0.113.0/24	# TEST-NET-3
ip route add blackhole 224.0.0.0/4	# Multicast
(all the implied routes from interface definitions that are inserted 
automatically into the routing table by the operating system)
ip route add <downstream-subnet> via <gateway> dev <interface>
ip route add <downstream-subnet> via <gateway> dev <interface>

(Has this been published anywhere before?  I haven't found any yet.)

Notice I've omitted 255.255.255.255, because I have quite a bit of 
software that uses this broadcast address, and it needs to get onto my 
intranets; I just have to be sure that the edge link doesn't let it out 
to the world.  One such program that uses broadcast is Dropbox.

This routing table addition forms the nucleus from which I can derive 
most of the source-address input packet filtering (adding 
255.255.255.255), as well as destination-address output filtering with 
code, instead of having to compile the rules by hand.

Then there are other packet filters:
* TCP “Lamp test/XMAS” et. al.  (mask, set)
     --tcp-flags FIN,SYN,RST,PSH,ACK,URG   NONE
     --tcp-flags FIN,SYN,RST,ACK,URG       FIN,SYN,RST,ACK,URG
     --tcp-flags FIN,SYN,RST,PSH,ACK,URG   FIN,PSH,URG
     --tcp-flags FIN,ACK  FIN
     --tcp-flags PSH,ACK  PSH
     --tcp-flags URG,ACK  URG
     --tcp-flags SYN,FIN  SYN,FIN
     --tcp-flags SYN,RST  SYN,RST
     --tcp-flags FIN,RST  FIN,RST
* DNS flood
* DNS amplification
* NTP flood
* NTP amplification
* ICMP flood
* IGRP flood
* protocol/port “small services” connections

And I'm just getting started.  It helps that I have a few books talking 
about the design of firewalls that discuss some of these filters.

For DNS amplification, I'm using these IPTABLES rules:

> # Limit UDP DNS "root NS" queries (must come before generic stream ACCEPT)
> #                                                                  012000010000000000010000020001
> -A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|012000010000000000010000020001|" --algo bm --from 20 --to 1550 -m recent --set --name dnsrootquery --rsource
> -A INPUT -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|012000010000000000010000020001|" --algo bm --from 20 --to 1550 -m recent --rcheck --seconds 20 --hitcount 3 --name dnsrootquery --rsource -m comment --comment "UDP DNS ROOT flood" -j DROP

(Another possibility would be to read the DNS hints file for all the 
root servers, and impose rate-limiting to those IP addresses...but I 
didn't think of that before and so it's not part of the current DNS 
server firewall.  But the filters above seem to work quite well -- it's 
been a long time since my ISP upstream's uplink has been nailed up solid.)

In short, I have yet to see a "cookbook" for BGP38 filtering, for ANY 
filtering system -- BSD, Linux, Cisco.