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

[Sean Clarke]

I personally love the "apply path" commands with wildcards

Therefore it ONLY looks for peers in your configuration ....

set policy-options prefix-list bgp-addresses apply-path \"protocols bgp 
group <*> neighbor <*>\"
set policy-options prefix-list dns-addresses apply-path \"system 
name-server <*>\"
set policy-options prefix-list ntp-addresses apply-path \"system ntp 
server <*>\"
set policy-options prefix-list radius-addresses apply-path \"system 
radius-server <*>\"
set policy-options prefix-list tacacs-addresses apply-path \"system 
tacplus-server <*>\"


cheers

Sean



On 28-Apr-24 11:21 AM, Martin Tonusoo via juniper-nsp 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp