On 09/25/2016 07:32 AM, Jay R. Ashworth wrote:
From: "Jay Farrell via NANOG" <nanog@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.