Some comments from quick read of just IPv4. - I don't like the level of abstraction, seems it just ensures no one will bother reading it up and reuse of the filters and terms wont happen anyhow. It feels like first time learning OO language, and making everything modular, while adding overhead and abstraction for no value. Instead of having flat list, you have multiple filters in a list (which is internally concatenate in SW anyhow, into single fat list, so no HW benefit), not just that, but filters themselves refer to other filters.
1) You should have two rules for TCP services, like BGP, inbound and outbound, instead just allowing far end to connect, and self-connect is handled by flags This will allow far-end to hit any port they want, while it will not have SYN bit, it's still not safe. You could improve it, by defining DPORT in the connected check as ephemeral range the NOS uses 2) OSPF can be TTL==1, not very important for security, tho 3) traceroute and ping won't work, if router is the target DADDR and TTL > 1 4) useless use of 'router-v4', if it hit lo0, it was for us. You'd need something like this in the edge filter, not lo0 filter. And in the edge filter it's still broken, because this is all LANs, not host/32. 5) use of 'port' in NTP and other, this allows the far end to hit any port, by setting SPORT port to ntp 6) no dport in DNS, every term should have DPORT, if we are connecting, it'll be ephemeral range, otherwise far end can hit any dport, by setting sport Some of these mistakes are straight from the book, like the useless level of abstraction without actual reuse and the insecure use of 'port'. But unlike the book, at least you have ultimate permit and then ultimate deny, which is important. On Sun, 28 Apr 2024 at 12:21, Martin Tonusoo <mar...@tonusoo.ee> wrote: > > 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 -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
