[j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Michael Hare]

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-bounces at puck.nether.net> On Behalf Of Saku Ytti
> via juniper-nsp
> Sent: Sunday, April 28, 2024 11:15 AM
> To: Martin Tonusoo <martin at tonusoo.ee>
> Cc: adamv0025 at netconsultings.com; juniper-nsp at 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 <martin at 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 at puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-
> nsp__;!!Mak6IKo!MQRlf-
> 9wNP2iWHZzeeyA7KIambMGev79eux2sjNd7RBXhagscC_PLFWLcG1x7grSrCvJGx
> QBrMo03dL_sIehCo8PlQY$