Hi. > In practical life IOS-XR control-plane is better protected than JunOS, > as configuring JunOS securely is very involved, considering that MX > book gets it wrong, offering horrible lo0 filter as does Cymru, what > chance the rest of us have?
I recently worked on a RE protection filter based on the examples given in the "Juniper MX Series" book: https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c It's a tight filter for a simple network, e.g MPLS is not in use and thus there are no filters for signaling protocols or MPLS LSP ping/traceroute, routing instances are not in use, authentication for VRRPv3 or OSPF is not in use, etc. Few differences compared to filters in the MX book: * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving the traceroute related filters in front of "accept-icmp" filter * "discard-extension-headers" filter in the book discards certain Next Header values and allows the rest. I changed it in a way that only specified Next Header values are accepted and rest are discarded. Idea is to discard unneeded extension headers as early as possible. * in term "neighbor-discovery-accept" in filter "accept-icmp6-misc" only the packets with Hop Limit value of 255 should be accepted * the "accept-bgp-v6" filter or any other IPv6 related RE filter in the book does not allow the router to initiate BGP sessions with other routers. I added a term named "accept-established-bgp-v6" in filter "accept-established-v6" which addresses this issue. * for the sake of readability and simplicity, I used names instead of numbers if possible. For example "icmp-type router-solicit" instead of "icmp-type 133". * in all occurrences, if it was not possible to match on the source IP address, then I strictly policed the traffic * traffic from management networks is not sharing policers with traffic from untrusted networks The overall structure of the RE filters in "Juniper MX Series" book is in my opinion very good. List of small filters which accept specific traffic and finally discard all the rest. Reason for having separate v4 and v6 prefix-lists is a Junos property to ignore the prefix-list altogether if it's used in a family inet filter while the prefix-list contains only the inet6 networks. Same is true if the prefix-list is used in family inet6 filter and the prefix-list contains only inet networks. For example, if only IPv4 name servers addresses are defined under [edit system name-server] and prefix-list with apply-path "system name-server <*>" is used as a source prefix-list in some family inet6 filter, then actually no source address related restrictions apply. This can be checked with "show filter index <filter-index> program" on a PFE CLI. Martin _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
