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.
