Martin, Saku is illuminating how difficult it can be to effectively protected the control plane. If I were to post our production RE filter I would likely be humbled with what I've overlooked as well. Thanks for sharing for commentary and discussion.
Saku's comment about using router-ipv4 in combo with destination address seems obvious to me in hindsight, although I have it configured as well in some terms. I think there is still use for that for things like VRRP, OSPF, LDP, BFD, IGMP and RSVP when matching source-prefix-list however? I guess I should think more. Another comment I would make is that you do not appear to have made provisions for support of GSTM for BGP. For my IPv4 [and IPv6] filters I have six terms dedicated explicitly to trying to deal with BGP. GTSM accept/reject near initiated vs far initiated + same for non GTSM. You have the most important component; the end term is discard. I chose to give up on 'log' on that long ago; too much noise, and only use it when I'm having troubles. I do have a term that looks like this before my final discard however. When these counters are non zero, my curiosity definitely gets piqued. term interesting { from { source-prefix-list { sync_lists_p2p-v4 sync_lists-all-loopbacks-v4; } destination-prefix-list { sync_lists-p2p-v4 sync_lists-all-loopbacks-v4; } } then { count :count:interesting; inactive: log; } } -Michael > -----Original Message----- > From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> On Behalf Of Saku Ytti > via juniper-nsp > Sent: Sunday, April 28, 2024 11:15 AM > To: Martin Tonusoo <mar...@tonusoo.ee> > Cc: adamv0...@netconsultings.com; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of > 'things to > think about'? > > 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://urldefense.com/v3/__https://gist.github.com/tonusoo/efd9ab4fcf2bb5a4 > 5d34d5af5e3f3e0c__;!!Mak6IKo!MQRlf- > 9wNP2iWHZzeeyA7KIambMGev79eux2sjNd7RBXhagscC_PLFWLcG1x7grSrCvJGx > QBrMo03dL_sIehI34dkQE$ > > > > 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://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper- > nsp__;!!Mak6IKo!MQRlf- > 9wNP2iWHZzeeyA7KIambMGev79eux2sjNd7RBXhagscC_PLFWLcG1x7grSrCvJGx > QBrMo03dL_sIehCo8PlQY$ _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp