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 program" on a PFE CLI.
Martin
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
