Mailing List Archive

On Thu, 12 Jul 2018, Jason Healy wrote:
> On Jul 12, 2018, at 10:09 AM, Benny Amorsen <benny+usenet@amorsen.dk>
wrote:
> > Saku Ytti <saku@ytti.fi> writes:
> >
> > > I think best compromise would be, that JNPR would offer good filter,
> > > dynamically built based on data available in config and referring to
> > > empty prefix-lists when not possible to infer and customer can fill
> > > those prefix-lists if needed. And also have functional ddos-protection
> > > configuration out-of-the-box. People who want and can could override
> > > and configure themselves.
> >
> > That would be really wonderful. A great start would be if there was a
> > way to get just the /32 (or /128) interface IP addresses in
> > apply-groups.
>
> I started working on a commit script that would harvest all the local
> interface addresses and dump them in a prefix list so
> you could do just this. Never got around to finishing it, but it's on my
> ever-growing todo list.

This type of thing gets most of the way there, depending on what you want it
for:

prefix-list PL-directly-connected-nets-v4 {
apply-path "interfaces <*> unit <*> family inet address <*>";
}
prefix-list PL-directly-connected-nets-v6 {
apply-path "interfaces <*> unit <*> family inet6 address <*>";
}

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford@uiowa.edu, phone: 319-335-5555
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, 12 Jul 2018 16:04:04 -0400,
Jason Healy <jhealy@logn.net> wrote:
>
> On Jul 12, 2018, at 10:09 AM, Benny Amorsen <benny+usenet@amorsen.dk>
> wrote:
> >
> > Saku Ytti <saku@ytti.fi> writes:
> >
> > That would be really wonderful. A great start would be if there was a
> > way to get just the /32 (or /128) interface IP addresses in
> > apply-groups.
>
> I started working on a commit script that would harvest all the
> local interface addresses and dump them in a prefix list so you
> could do just this. Never got around to finishing it, but it's on
> my ever-growing todo list.

i would have tried to do this with an apply-path, does that not work?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> Of Jay Ford
> Sent: Thursday, July 12, 2018 9:26 PM
>
> On Thu, 12 Jul 2018, Jason Healy wrote:
> > On Jul 12, 2018, at 10:09 AM, Benny Amorsen
> <benny+usenet@amorsen.dk>
> wrote:
> > > Saku Ytti <saku@ytti.fi> writes:
> > >
> > > > I think best compromise would be, that JNPR would offer good
> > > > filter, dynamically built based on data available in config and
> > > > referring to empty prefix-lists when not possible to infer and
> > > > customer can fill those prefix-lists if needed. And also have
> > > > functional ddos-protection configuration out-of-the-box. People
> > > > who want and can could override and configure themselves.
> > >
> > > That would be really wonderful. A great start would be if there was
> > > a way to get just the /32 (or /128) interface IP addresses in
> > > apply-groups.
> >
> > I started working on a commit script that would harvest all the local
> > interface addresses and dump them in a prefix list so you could do
> > just this. Never got around to finishing it, but it's on my
> > ever-growing todo list.
>
> This type of thing gets most of the way there, depending on what you want
it
> for:
>
> prefix-list PL-directly-connected-nets-v4 {
> apply-path "interfaces <*> unit <*> family inet address <*>";
> }
> prefix-list PL-directly-connected-nets-v6 {
> apply-path "interfaces <*> unit <*> family inet6 address <*>";
> }
>
This gets you the whole subnet not just the local end /32 /128 that OP is
after.

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi,

----- On 12 Jul, 2018, at 13:54, Saku Ytti saku@ytti.fi wrote:
> c) implement ddos-protection
> - configure _every_ protocol, set 10-100pps aggregate for
> protocols you don't know you need
> - disable sub detection, enable ifl detection

I can see the reasoning behind disabling sub detection, but how would you then protect e.g. in a peering VLAN a single peer from killing also all the other BGP sessions behind that specific ifl?

Antti



--
CSC - Tieteen tietotekniikan keskus Oy:n asiakas- seka sidosryhmarekisterien henkilotietojen kasittely kuvataan tietosuojaselosteissa:
https://www.csc.fi/tietosuoja

CSC - IT Center for Science Ltd processes customer and other stakeholder personal information in the following way:
https://www.csc.fi/privacy


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Fri, 13 Jul 2018 at 06:19, Antti Ristimäki <antti.ristimaki@csc.fi> wrote:

> I can see the reasoning behind disabling sub detection, but how would you then protect e.g. in a peering VLAN a single peer from killing also all the other BGP sessions behind that specific ifl?

I'm sure you were anticipating my answer, you don't.

I don't think there is reasonable way to make shared LAN termination
safe. The sub detection _MIGHT_ work against some unintentional ddos
vectors in shared LAN, but it can't really work for intentional ddos
vectors. MX model I was testing against had about 4k policers for
DDoS, plenty for reasonably protecting protocol*ifl with dynamic
detection (with static policers, not very reasonable even there). But
4k for sub detection? Just use 4k source ports and you congest the
policers, and when that happens they are compressed to next-level
(ifl) anyhow.
But just being able to limit collateral damage to IFL level is huge,
no other vendor can do it AFAIK.

Largely the DDoS protection scheme was inspired by ERX, and the whole
sub thing was related to PPPoE subscriber, where amount of keys is far
more finite than in TCP.

As far as I know, Juniper can be control-plane protected better than
any other platform in the market, by large margin, but it's just lot
way harder than what we can realistically expect operators to be able
to do, Schrödinger's control-plane protection, it's there, but it
really isn't.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

----- On 13 Jul, 2018, at 11:30, Saku Ytti saku@ytti.fi wrote:

> On Fri, 13 Jul 2018 at 06:19, Antti Ristim?ki <antti.ristimaki@csc.fi> wrote:
>
>> I can see the reasoning behind disabling sub detection, but how would you then
>> protect e.g. in a peering VLAN a single peer from killing also all the other
>> BGP sessions behind that specific ifl?
>
> I'm sure you were anticipating my answer, you don't.
>
> I don't think there is reasonable way to make shared LAN termination
> safe. The sub detection _MIGHT_ work against some unintentional ddos
> vectors in shared LAN, but it can't really work for intentional ddos
> vectors. MX model I was testing against had about 4k policers for
> DDoS, plenty for reasonably protecting protocol*ifl with dynamic
> detection (with static policers, not very reasonable even there). But
> 4k for sub detection? Just use 4k source ports and you congest the
> policers, and when that happens they are compressed to next-level
> (ifl) anyhow.
> But just being able to limit collateral damage to IFL level is huge,
> no other vendor can do it AFAIK.

Right. Also if one has a host in a let's say /64 IPv6 subnet, (s)he can send traffic towards the router from quite a many source addresses and thus deplete the policers.

Antti



--
CSC - Tieteen tietotekniikan keskus Oy:n asiakas- seka sidosryhmarekisterien henkilotietojen kasittely kuvataan tietosuojaselosteissa:
https://www.csc.fi/tietosuoja

CSC - IT Center for Science Ltd processes customer and other stakeholder personal information in the following way:
https://www.csc.fi/privacy


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 11 Jul 2018 18:22:36 +0000
Chris Boyd <cboyd@gizmopartners.com> wrote:

> Team Cymru has a “JunOS Secure Template” that I found a good place to start. It quotes version 4 though. I think that means it’s well tested?
>
> http://www.cymru.com/gillsr/documents/junos-template.pdf

That document is old and should be considered unreliable. I'm speaking
with some authority since I contributed major parts to it, including
the now bad advice of UDP rate rate limits (their demise hastened with
the rise of QUIC/SPDY years ago).

I've been redoing a slew of JUNOS configuration standards and am
documenting them as I go. I've not finalized new loopback filters yet,
but you might be interested in others and keeping an eye on this repo.
Loopback filters will soon appear within a few weeks.

<https://github.com/jtkristoff/junos>

John
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Thanks for sharing Martin. As a word of advice, we have a challenge with BGP Session security. It seems that operators are not applying filters like these to protect the router, the control plane, and BGP. They are not common, but we are seeing BGP session attacks. This spurred this post after two types of BGP session attacks were observed in one week in on country:

https://www.senki.org/protect-your-bgp-sessions-from-ddos-attacks/

For those who are pulling down the Shadowserver reports, two new reports were created to let you know of exposed BGP sessions (check for “BGP” in these report list - https://www.shadowserver.org/what-we-do/network-reporting/).

How bad is this? +300,000 BGP sessions visible with no ACL to protect them from external DDoS. https://dashboard.shadowserver.org/statistics/combined/time-series/?date_range=7&source=population&source=population6&tag=bgp&group_by=geo&style=stacked

Recommendation: Check your RE protecting filters. If you don’t know which devices are exposed, sign up to the Shadowserver reports. They are a free public service.

> On Apr 28, 2024, at 02:22, Martin Tonusoo via juniper-nsp <juniper-nsp@puck.nether.net> 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@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

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@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

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@puck.nether.net> On Behalf Of Saku Ytti
> via juniper-nsp
> Sent: Sunday, April 28, 2024 11:15 AM
> To: Martin Tonusoo <martin@tonusoo.ee>
> Cc: adamv0025@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 <martin@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

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@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

Hi.

Thanks for the feedback and remarks. I have updated the RE filters:
https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c

Few comments:

* I used the ephemeral range of 49160 - 65535 based on "sysctl
net.inet.ip.portrange.first" and "sysctl net.inet.ip.portrange.last"
on FreeBSD shell

* the "router-v4" was carried over from inet6 filters as I wanted to
keep the v4 and v6 rules as identical as possible. It also helps to
filter malformed packets addressed
to multicast. For example TCP SYN packets addressed to dport 179 with
destination IP set to 224.0.0.6


Michael,

regarding the GTSM for BGP and related filters. Do you group the BGP
neighbors into different prefix lists based on the expected TTL?
Something like this:

root@vmx1> show configuration firewall family inet filter accept-bgp-v4
term accept-bgp-ttl-255-v4 {
from {
source-prefix-list {
/* adjacent BGP neighbors with TTL set to 255 */
bgp-neighbors-ttl-255-v4;
}
destination-prefix-list {
router-v4;
}
protocol tcp;
ttl 255;
destination-port bgp;
}
then {
count accept-bgp-ttl-255-v4;
accept;
}
}
term accept-bgp-v4 {
from {
source-prefix-list {
/* rest of the BGP neighbors */
bgp-neighbors-v4;
}
destination-prefix-list {
router-v4;
}
protocol tcp;
destination-port bgp;
}
then {
count accept-bgp-v4;
accept;
}
}

root@vmx1>


Martin
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Martin-

Yes, we use the source-prefix-list autogenerated with external scripting based on config parsing of eBGP peers with ttl 255 set. Below is what our BGP RE rules look like on a PE; it probably has its own problems deserving feedback. I show v4 but we have corresponding for v6.

You can also see below I take shortcuts to reuse a single filter for deployment in global vs VPN vs LS, as always, "we could do better here". In my example the source-prefix-lists starting with "^BGP-Peers" are JunOS apply-paths. I think previously Saku [or others] made a case for treating RRs differently since it is known with an RR both ends of the BGP peer are under the same admin domain [ie, RR doesn't need to allow inbound initiation]. So the rules for an RR could be tighter than below.

-Michael

===/===

term BGP-ttl-security-allow-1 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
ttl 255;
source-port bgp;
destination-port 1024-65535;
}
then {
count :accept:tcp:bgp-ttl;
accept;
}
}
term BGP-ttl-security-reject-1 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
}
then {
count :discard:tcp:bgp-ttl;
discard;
}
}
term BGP-ttl-security-allow-2 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
ttl 255;
source-port 1024-65535;
destination-port bgp;
}
then {
count :accept:tcp:bgp-ttl;
accept;
}
}
term BGP-ttl-security-reject-2 {
from {
source-prefix-list {
bgp_ttl_security-v4;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count :discard:tcp:bgp-ttl;
discard;
}
}
term BGP-Allow-1 {
from {
source-prefix-list {
BGP-Peers-v4;
BGP-Peers-v4-VPN;
BGP-Peers-v4-LS;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
}
then {
count :accept:tcp:BGP;
accept;
}
}
term BGP-Allow-2 {
from {
source-prefix-list {
BGP-Peers-v4;
BGP-Peers-v4-VPN;
BGP-Peers-v4-LS;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count :accept:tcp:BGP;
accept;
}
}


> -----Original Message-----
> From: juniper-nsp <juniper-nsp-bounces@puck.nether.net> On Behalf Of Martin
> Tonusoo via juniper-nsp
> Sent: Thursday, May 2, 2024 9:32 AM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to
> think about'?
>
> Hi.
>
> Thanks for the feedback and remarks. I have updated the RE filters:
> https://urldefense.com/v3/__https://gist.github.com/tonusoo/efd9ab4fcf2bb5a4
> 5d34d5af5e3f3e0c__;!!Mak6IKo!N5k2EhZxDwIf5W9ZpqDjz_jriaKLPB2zu5Q4Uv8F
> A80q0_LrJSqI5m95HP0NSSUcqOD1H-xllqhzwfvGwr1ZBq3Tw2I$
>
> Few comments:
>
> * I used the ephemeral range of 49160 - 65535 based on "sysctl
> net.inet.ip.portrange.first" and "sysctl net.inet.ip.portrange.last"
> on FreeBSD shell
>
> * the "router-v4" was carried over from inet6 filters as I wanted to
> keep the v4 and v6 rules as identical as possible. It also helps to
> filter malformed packets addressed
> to multicast. For example TCP SYN packets addressed to dport 179 with
> destination IP set to 224.0.0.6
>
>
> Michael,
>
> regarding the GTSM for BGP and related filters. Do you group the BGP
> neighbors into different prefix lists based on the expected TTL?
> Something like this:
>
> root@vmx1> show configuration firewall family inet filter accept-bgp-v4
> term accept-bgp-ttl-255-v4 {
> from {
> source-prefix-list {
> /* adjacent BGP neighbors with TTL set to 255 */
> bgp-neighbors-ttl-255-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> ttl 255;
> destination-port bgp;
> }
> then {
> count accept-bgp-ttl-255-v4;
> accept;
> }
> }
> term accept-bgp-v4 {
> from {
> source-prefix-list {
> /* rest of the BGP neighbors */
> bgp-neighbors-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> destination-port bgp;
> }
> then {
> count accept-bgp-v4;
> accept;
> }
> }
>
> root@vmx1>
>
>
> Martin
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-
> nsp__;!!Mak6IKo!N5k2EhZxDwIf5W9ZpqDjz_jriaKLPB2zu5Q4Uv8FA80q0_LrJSqI5
> m95HP0NSSUcqOD1H-xllqhzwfvGwr1ZPj6yIMU$
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Hi Martin

I did a bit of work in this subject a couple of years ago, maybe there is
something of use here:

https://github.com/lpedder/junos-re-filters

I think this is an unreasonably complicated topic full of pitfalls, and
there's definitely a lot of misconceptions in my own work too that I
haven't spotted. Even if you sat in a lab for weeks you'd probably still be
missing something dangerous. Juniper should really come up with a better /
automated solution because the level of skill to get this right is insane.

Regards
Lee


On Thu, 2 May 2024, 16:32 Martin Tonusoo via juniper-nsp, <
juniper-nsp@puck.nether.net> wrote:

> Hi.
>
> Thanks for the feedback and remarks. I have updated the RE filters:
> https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c
>
> Few comments:
>
> * I used the ephemeral range of 49160 - 65535 based on "sysctl
> net.inet.ip.portrange.first" and "sysctl net.inet.ip.portrange.last"
> on FreeBSD shell
>
> * the "router-v4" was carried over from inet6 filters as I wanted to
> keep the v4 and v6 rules as identical as possible. It also helps to
> filter malformed packets addressed
> to multicast. For example TCP SYN packets addressed to dport 179 with
> destination IP set to 224.0.0.6
>
>
> Michael,
>
> regarding the GTSM for BGP and related filters. Do you group the BGP
> neighbors into different prefix lists based on the expected TTL?
> Something like this:
>
> root@vmx1> show configuration firewall family inet filter accept-bgp-v4
> term accept-bgp-ttl-255-v4 {
> from {
> source-prefix-list {
> /* adjacent BGP neighbors with TTL set to 255 */
> bgp-neighbors-ttl-255-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> ttl 255;
> destination-port bgp;
> }
> then {
> count accept-bgp-ttl-255-v4;
> accept;
> }
> }
> term accept-bgp-v4 {
> from {
> source-prefix-list {
> /* rest of the BGP neighbors */
> bgp-neighbors-v4;
> }
> destination-prefix-list {
> router-v4;
> }
> protocol tcp;
> destination-port bgp;
> }
> then {
> count accept-bgp-v4;
> accept;
> }
> }
>
> root@vmx1>
>
>
> 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

Michael,

got it, thanks.


Lee,

the README of your repository provides an excellent introduction to RE
filtering. Based on your filters, I moved the processing of the IP
Options from edge filters to RE filters:

https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c#file-junos-re-filters-L574:L585


Martin
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

How IP options work is platform specific.

It used to be that _transited_ IP-options were not subject to the lo0
filter, while still being risk for RE, so you'd implement
forwarding-filter, where you'd police IP-options or drop out right.

In more recent junipers, this behaviour has been changed so that
transited IP-options are subject to lo0 filter, which makes it in
practice impossible to determine if IP-option is transit or punt,
especially if you run L3 MPLS VPN.

I tried to argue that the new behaviour is PR, but didn't have enough
patience to ram it through.

So basically no one knows what their policy regarding transit IP
packets are, and most accidentally change the policy from 'transit
all, unlimited' to 'transit none' by upgrading devices. Of course
generally this is the case for most things.


On Mon, 13 May 2024 at 13:36, Martin Tonusoo via juniper-nsp
<juniper-nsp@puck.nether.net> wrote:
>
> Michael,
>
> got it, thanks.
>
>
> Lee,
>
> the README of your repository provides an excellent introduction to RE
> filtering. Based on your filters, I moved the processing of the IP
> Options from edge filters to RE filters:
>
> https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c#file-junos-re-filters-L574:L585
>
>
> Martin
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp