On 29 March 2016 at 16:05, Mark Tees <markt...@gmail.com> wrote: > There is a very nice example in the Doug Hanks MX book of what a > comprehensive lo0 filter looks like. Complete with instructions on how to > roll it out from memory.
I arrogantly stand behind my statement that all lo filters I've seen are fundamentally broken. It's very hard to read, due to unjustifiiable level of abstraction. I'll only quickly glance through IPv4 and quicker IPv6. 1. example treats internal and external ICMP the same, causing false positives for ICMP monitoring during attack 2. ICMP ND is not limited to TTL 255, meaning anyone from Internet can congest your next-hop resolution, not just connected attacker 3. it treats 'tcp-established' as magic toggle without verifying source-address, allowing anyone to inject potentially 0day packet-of-death parsing bugs abusing packets 4. it does not consistently verify daddr, allowing l3 mpls vpn customer potentially to hammer control-plane 5. it does not discriminate various BFD modes, which have different security posture (singlehop can limit ttl=255, multihop cant, echo and control are different) 6. it uses 'port' match, allowing crafted source port to reach any destination port (bgp peers can reach ssh port) 7. it does not discriminate different OSPF operations, your most likely OSPF will work with TTL==1, which is additional hurdle for attacker 8. it does not limit VRRP to ttl 255 9. it does not limit copy protocols (http, https,...) to connected/establlished state 10. it does not discriminate between basic and extended LDP discovery 11. it uses 'next-header' as discard match, you should only use it as permit match, because it's easy to circumvent That is just 10min look. It's very complicated approach yet not particularly secure one. But at least it's less broken than Cymru secure template. Few basic principles a) never use 'port', all bidir TCP needs 'active' and 'passive' rule separately b) never use prefix-list, always directional source/desination c) if you run l3 mpls vpn, always verify 'destination-address' d) have long list of permit/allow, then single discard at the end e) if standard makes statement about TTL/hop-limit, use it, it's super critical for ICMPv6 ND particularly f) only use 'tcp-established' to make rule more strict, not to have some handy catch-all return traffic permitter g) avoid high level of abstraction, people will need to be able to review it, preferably fast, bitrot is serious problem -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp