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

[Drew Weaver]

Hello,

Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?

I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.

If anyone has seen anything like this let me know, if not no worries will just keep fixing the things one by one =)
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Chris Boyd]

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no worries will just keep fixing the things one by one =)

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

—Chris
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https:

[Saku Ytti]

I'd say the filters are all kind of broken.

Just few issues

a) You can't just limit UDP to 2Mbps on every edge port
b) LO filter matches on 'port'
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest
d) hardcore doesnt permit traceroute

Just very short review, to me just these errors are monumental
misunderstanding of security and goals of filters. To me starting from
nothing is superior than starting from those.

Post by Chris Boyd

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no worries will just keep fixing the things one by one =)

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

[Drew Weaver]

Have you tried submitting your recommendations to the authors?

-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-***@puck.nether.net] On Behalf Of Saku Ytti
Sent: Wednesday, July 11, 2018 3:07 PM
To: ***@gizmopartners.com
Cc: Juniper List <juniper-***@puck.nether.net>
Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

I'd say the filters are all kind of broken.

Just few issues

a) You can't just limit UDP to 2Mbps on every edge port
b) LO filter matches on 'port'
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest
d) hardcore doesnt permit traceroute

Just very short review, to me just these errors are monumental misunderstanding of security and goals of filters. To me starting from nothing is superior than starting from those.

Post by Chris Boyd

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no worries
will just keep fixing the things one by one =)

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

[Saku Ytti]

I have not.

But to answer your question broadly

a) allow in very specific terms what you want to accept
- always match on source IP (except UDP traceroute and ICMP, which
you'll need to accept from world)
- always match on destination IP, if you run any L3 MSPL VPN
- always match on destination port, either service port, BGP, SSH
etc or JunOS ephemeral (49160-65535) (TCP requires 2 terns,
one per direction)
- always match on TTL/hop-count 255 when permitted (VRRP, ND)
- decide your policy on IP options, and ensure lo0 implements that
(transit IP-options are today subject to lo0. they were not in earlier
JunOS, not even on Trio)
- be sure that source IPs you allow, cannot be spooffed. If I want
to DDoS your network, first source address spoofs I'll try are
ftp.juniper.net, ftp.cisco.com etc. Ensure you don't admit anything
like that to control-plane
b) discard rest
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
- set ifl limit to 10th or 5th of aggregate at most (so you need

5 or >10 violating ifl to congest aggregate)

- have three categories 'dont care', 'care, but not customer
impacting', 'customer impacting'. I'd recommend no more than 100pps,
4000pps and 8000pps aggregates per category. There is built-in magic
policer from NPU=>LC_CPU, you can't review its drops nor can you
reconfigure it, but you MUST NOT congest it, as it will drop packets
blindly contract-unaware.

Have you tried submitting your recommendations to the authors?
-----Original Message-----
Sent: Wednesday, July 11, 2018 3:07 PM
Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
I'd say the filters are all kind of broken.
Just few issues
a) You can't just limit UDP to 2Mbps on every edge port
b) LO filter matches on 'port'
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest
d) hardcore doesnt permit traceroute
Just very short review, to me just these errors are monumental misunderstanding of security and goals of filters. To me starting from nothing is superior than starting from those.

Post by Chris Boyd

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no worries
will just keep fixing the things one by one =)

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

--
++ytti
_______________________________________________

[Drew Weaver]

This is probably a silly question but do you have any idea why ftp, http, and https show up as open ports in a port scan on an MX80 even when the services are unconfigured?

Not shown: 997 filtered ports
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
443/tcp open https

[***@nessie drew]# wget http://10.1.25.156
--2018-07-12 09:49:28-- http://10.1.25.156/
Connecting to 10.1.25.156:80... connected.
HTTP request sent, awaiting response...

***@chuck> show configuration system services
ssh {
root-login deny;
}

Thanks,
-Drew

-----Original Message-----
From: Saku Ytti [mailto:***@ytti.fi]
Sent: Thursday, July 12, 2018 6:54 AM
To: Drew Weaver <***@thenap.com>
Cc: ***@gizmopartners.com; Juniper List <juniper-***@puck.nether.net>
Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

I have not.

But to answer your question broadly

a) allow in very specific terms what you want to accept
- always match on source IP (except UDP traceroute and ICMP, which you'll need to accept from world)
- always match on destination IP, if you run any L3 MSPL VPN
- always match on destination port, either service port, BGP, SSH
etc or JunOS ephemeral (49160-65535) (TCP requires 2 terns,
one per direction)
- always match on TTL/hop-count 255 when permitted (VRRP, ND)
- decide your policy on IP options, and ensure lo0 implements that (transit IP-options are today subject to lo0. they were not in earlier JunOS, not even on Trio)
- be sure that source IPs you allow, cannot be spooffed. If I want to DDoS your network, first source address spoofs I'll try are ftp.juniper.net, ftp.cisco.com etc. Ensure you don't admit anything like that to control-plane
b) discard rest
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
- set ifl limit to 10th or 5th of aggregate at most (so you need

5 or >10 violating ifl to congest aggregate)

- have three categories 'dont care', 'care, but not customer impacting', 'customer impacting'. I'd recommend no more than 100pps, 4000pps and 8000pps aggregates per category. There is built-in magic policer from NPU=>LC_CPU, you can't review its drops nor can you reconfigure it, but you MUST NOT congest it, as it will drop packets blindly contract-unaware.

Have you tried submitting your recommendations to the authors?
-----Original Message-----
Sent: Wednesday, July 11, 2018 3:07 PM
Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
I'd say the filters are all kind of broken.
Just few issues
a) You can't just limit UDP to 2Mbps on every edge port
b) LO filter matches on 'port'
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest
d) hardcore doesnt permit traceroute
Just very short review, to me just these errors are monumental misunderstanding of security and goals of filters. To me starting from nothing is superior than starting from those.

Post by Chris Boyd

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no
worries will just keep fixing the things one by one =)

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

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

[Saku Ytti]

Hey Drew,

No idea. There isn't really command in JunOS to ask which PID is
listening on given port. I'm sure it's possible with dtrace, but I'm
not gonna figure out how to do it. I suspect inetd though.

Post by Drew Weaver
This is probably a silly question but do you have any idea why ftp, http, and https show up as open ports in a port scan on an MX80 even when the services are unconfigured?
Not shown: 997 filtered ports
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
443/tcp open https
--2018-07-12 09:49:28-- http://10.1.25.156/
Connecting to 10.1.25.156:80... connected.
HTTP request sent, awaiting response...
ssh {
root-login deny;
}
Thanks,
-Drew
-----Original Message-----
Sent: Thursday, July 12, 2018 6:54 AM
Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
I have not.
But to answer your question broadly
a) allow in very specific terms what you want to accept
- always match on source IP (except UDP traceroute and ICMP, which you'll need to accept from world)
- always match on destination IP, if you run any L3 MSPL VPN
- always match on destination port, either service port, BGP, SSH
etc or JunOS ephemeral (49160-65535) (TCP requires 2 terns,
one per direction)
- always match on TTL/hop-count 255 when permitted (VRRP, ND)
- decide your policy on IP options, and ensure lo0 implements that (transit IP-options are today subject to lo0. they were not in earlier JunOS, not even on Trio)
- be sure that source IPs you allow, cannot be spooffed. If I want to DDoS your network, first source address spoofs I'll try are ftp.juniper.net, ftp.cisco.com etc. Ensure you don't admit anything like that to control-plane
b) discard rest
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
- set ifl limit to 10th or 5th of aggregate at most (so you need

5 or >10 violating ifl to congest aggregate)

- have three categories 'dont care', 'care, but not customer impacting', 'customer impacting'. I'd recommend no more than 100pps, 4000pps and 8000pps aggregates per category. There is built-in magic policer from NPU=>LC_CPU, you can't review its drops nor can you reconfigure it, but you MUST NOT congest it, as it will drop packets blindly contract-unaware.

Have you tried submitting your recommendations to the authors?
-----Original Message-----
Sent: Wednesday, July 11, 2018 3:07 PM
Subject: Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
I'd say the filters are all kind of broken.
Just few issues
a) You can't just limit UDP to 2Mbps on every edge port
b) LO filter matches on 'port'
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest
d) hardcore doesnt permit traceroute
Just very short review, to me just these errors are monumental misunderstanding of security and goals of filters. To me starting from nothing is superior than starting from those.

Post by Chris Boyd

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no
worries will just keep fixing the things one by one =)

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

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

--
++ytti

[Antti Ristimäki]

Hi,

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

[Saku Ytti]

Post by Antti Ristimäki
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.

[Antti Ristimäki]

Post by Saku Ytti

Post by Antti Ristimäki
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-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Chris Morrow]

On Wed, 11 Jul 2018 15:06:43 -0400,

Post by Saku Ytti
I'd say the filters are all kind of broken.
Just few issues
a) You can't just limit UDP to 2Mbps on every edge port

it's really a limit of 2mbps on each PFE, so ... in some cases that's
2mbps on a port, in some cases not. This is a 'problem' because of the
architecture of the MX though, right? not the filter itself... well... :)

Post by Saku Ytti
b) LO filter matches on 'port'

on 'port'.. meaning I can't do:
destination-port ssh
source-port 1024-65535

something like that? or that you wanted to match on:
port xe-1/0/1.0
?

Post by Saku Ytti
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest

how do you mean? doesn't it just permit/deny what you ask in the filter?

Post by Saku Ytti
d) hardcore doesnt permit traceroute

traceroute is permitted TO the box with the right config, and THROUGH
the box on the MX without any holes in the loopback filter.

On the EX platform though :( sadness reigns.

Post by Saku Ytti
Just very short review, to me just these errors are monumental
misunderstanding of security and goals of filters. To me starting from
nothing is superior than starting from those.

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I have found some issue specific examples on Juniper.net thus far that tend to help with some of the issues but if anyone has ever seen a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no worries will just keep fixing the things one by one =)

Team Cymru has a $B!H(BJunOS Secure Template$B!I(B that I found a good place to start. It quotes version 4 though. I think that means it$B!G(Bs well tested?
http://www.cymru.com/gillsr/documents/junos-template.pdf
$B!=(BChris
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

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

[Saku Ytti]

Hey Chris,

Post by Chris Morrow

Post by Saku Ytti
a) You can't just limit UDP to 2Mbps on every edge port

it's really a limit of 2mbps on each PFE, so ... in some cases that's
2mbps on a port, in some cases not. This is a 'problem' because of the
architecture of the MX though, right? not the filter itself... well... :)

They were doing this to transit traffic, high rate of UDP isn't
strange, good portion of youtube streaming is UDP.

Post by Chris Morrow

Post by Saku Ytti
b) LO filter matches on 'port'

destination-port ssh
source-port 1024-65535

You can do that, you can't do 'port X', because then anyone setting
source port to X, allows them to reach any destination port you have.
I don't think source-port 1024-65534 matters, just additional resource
consumption. What does matter, is that you match destination-port
<ephemeral>, source-port <bgp,ssh,etc>, when you want to allow far-end
to respond to connection you opened.

Post by Chris Morrow

Post by Saku Ytti
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest

how do you mean? doesn't it just permit/deny what you ask in the filter?

In the relaxed one, they discard non allowed ssh etc, then have wide
accept. I.e. they don't know what they should accept and what not.

Post by Chris Morrow

Post by Saku Ytti
d) hardcore doesnt permit traceroute

traceroute is permitted TO the box with the right config, and THROUGH
the box on the MX without any holes in the loopback filter.

In this config it is not allowed to the box.

[Chris Morrow]

On Wed, 11 Jul 2018 15:23:28 -0400,

Post by Saku Ytti
Hey Chris,

Post by Chris Morrow

Post by Saku Ytti
a) You can't just limit UDP to 2Mbps on every edge port

it's really a limit of 2mbps on each PFE, so ... in some cases that's
2mbps on a port, in some cases not. This is a 'problem' because of the
architecture of the MX though, right? not the filter itself... well... :)

They were doing this to transit traffic, high rate of UDP isn't
strange, good portion of youtube streaming is UDP.

sorry, i think 'they' here is confusing :( or at least confusing me :)
'they' means: "juniper docs/engineers/etc"
or
'they' means: "team cymru and their docs"

which ? I was answering in the case of the first ;( which may have
lead us astray here...

Post by Saku Ytti

Post by Chris Morrow

Post by Saku Ytti
b) LO filter matches on 'port'

destination-port ssh
source-port 1024-65535

You can do that, you can't do 'port X', because then anyone setting
source port to X, allows them to reach any destination port you have.
I don't think source-port 1024-65534 matters, just additional resource
consumption. What does matter, is that you match destination-port
<ephemeral>, source-port <bgp,ssh,etc>, when you want to allow far-end
to respond to connection you opened.

i think that /port/ is a crutch :( and best avoided in the case of
loopback filters. you know exactly what's ok, permit that, drop all
else.

Post by Saku Ytti

Post by Chris Morrow

Post by Saku Ytti
c) LO filter has wide permit instead of accept 1,2,3,4 drop rest

how do you mean? doesn't it just permit/deny what you ask in the filter?

In the relaxed one, they discard non allowed ssh etc, then have wide
accept. I.e. they don't know what they should accept and what not.

i sense you are talking about the 'they' that is cymru.

Post by Saku Ytti

Post by Chris Morrow

Post by Saku Ytti
d) hardcore doesnt permit traceroute

traceroute is permitted TO the box with the right config, and THROUGH
the box on the MX without any holes in the loopback filter.

In this config it is not allowed to the box.

ah-ha! that's kooky :) (again this is with respect to the cymru doc) I
think the cymru guide is still good, it certainly gives you a leg up
on 'how do I even start?' and PROBABLY is "ok" for an enterprise
deployment. SP deployment will need more .... thought, but the
structure is there to build from.
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Olivier Benghozi]

One thing to think about, in IPv6:
On MX, one can use "match protocol" (with Trio / MPC cards).
But it's not supported on lo0 filters, where you were / probably still are restricted to "match next-header", in order to have a filter working as expected.

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/m

[Jay Ford]

You might want "payload-protocol" for IPv6, except where you really want
"next-header". This is a case where there's not a definite single functional
mapping from IPv4 to IPv6.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242

Post by Olivier Benghozi
On MX, one can use "match protocol" (with Trio / MPC cards).
But it's not supported on lo0 filters, where you were / probably still are restricted to "match next-header", in order to have a filter working as expected.

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?

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

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

[Chris Morrow]

On Wed, 11 Jul 2018 15:14:40 -0400,

Post by Jay Ford
You might want "payload-protocol" for IPv6, except where you really
want "next-header". This is a case where there's not a definite
single functional mapping from IPv4 to IPv6.

unclear why that's important here though? you MAY (and probably do)
have different security requirements between the 2 families, right? so
you're making a policy in ipv4 and you're making one in ipv6.

just use next-header...

(and for a bootstrap the cymru guides really are pretty straightforward)
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[Saku Ytti]

Post by Chris Morrow

Post by Jay Ford
You might want "payload-protocol" for IPv6, except where you really
want "next-header". This is a case where there's not a definite
single functional mapping from IPv4 to IPv6.

unclear why that's important here though? you MAY (and probably do)
have different security requirements between the 2 families, right? so
you're making a policy in ipv4 and you're making one in ipv6.

Point probably is that if filter is as such

a) allow smtp to permitted mx
b) drop all smtp
c) permit rest

Then with 'payload-protocol' it works fine. With 'next-header' this
filter is trivial to by-pass, allowing sender to send email to any MX.

However for lo0 filter it indeed does not matter, as you format should be

a) permit specific thing1
b) permit specific thingN
c) drop rest

No way to bypass c), so immaterial if next-header (cheap) or
payload-protocol (expensive) is used.

[a***@netconsultings.com]

Post by Drew Weaver
Of Saku Ytti
Sent: Wednesday, July 11, 2018 8:44 PM

Post by Chris Morrow

Post by Jay Ford
You might want "payload-protocol" for IPv6, except where you really
want "next-header". This is a case where there's not a definite
single functional mapping from IPv4 to IPv6.

unclear why that's important here though? you MAY (and probably do)
have different security requirements between the 2 families, right? so
you're making a policy in ipv4 and you're making one in ipv6.

Point probably is that if filter is as such
a) allow smtp to permitted mx
b) drop all smtp
c) permit rest
Then with 'payload-protocol' it works fine. With 'next-header' this filter

is

Post by Drew Weaver
trivial to by-pass, allowing sender to send email to any MX.
However for lo0 filter it indeed does not matter, as you format should be
a) permit specific thing1
b) permit specific thingN
c) drop rest
No way to bypass c), so immaterial if next-header (cheap) or payload-
protocol (expensive) is used.
--

Well yes but think about the 1st rule of thermodynamics,
It almost seems like every single time someone looks at the RE filter he can
spot yet another thing that's not quite kosher.

Take the BGP session filter for example,
Yes allowing just destination port 172 and source port ephemeral is safe but
you might not get your session up (not sure what the rule is? higher RID
session is kept?) or configure it on two neighbouring routers and you'll
never get the session up.


adam

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


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

[Olivier Benghozi]

Yes, I was really talking about "payload-protocol", not "protocol" :)
And this is the point, it didn't work on lo0 whereas it works on "physical" interfaces.

You might want "payload-protocol" for IPv6, except where you really want "next-header". This is a case where there's not a definite single functional mapping from IPv4 to IPv6.
________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242

Post by Olivier Benghozi
On MX, one can use "match protocol" (with Trio / MPC cards).
But it's not supported on lo0 filters, where you were / probably still are restricted to "match next-header", in order to have a filter working as expected.

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when constructing a firewall filter for a loopback on an MX series router running version 15 of Junos?

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

[Vincent Bernat]

Post by Drew Weaver
Is there a list of best practices or 'things to think about' when
constructing a firewall filter for a loopback on an MX series router
running version 15 of Junos?
I'm slowly piecing it together by just 'seeing what is broken next'
and I have found some issue specific examples on Juniper.net thus far
that tend to help with some of the issues but if anyone has ever seen
a decent comprehensive guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no worries
will just keep fixing the things one by one =)

There is a "Day One: Securing the Routing Engine" [0] about that. It is
missing IPv6 which is present in the O'Reilly book about the MX.

[0]: http://www.hiphop-resistance.com/juniperdayone/Securing_RouteEngine2.pdf

[a***@netconsultings.com]

Of Drew Weaver
Sent: Wednesday, July 11, 2018 7:17 PM
Hello,
Is there a list of best practices or 'things to think about' when

constructing a

firewall filter for a loopback on an MX series router running version 15

of

Junos?
I'm slowly piecing it together by just 'seeing what is broken next' and I

have

found some issue specific examples on Juniper.net thus far that tend to

help

with some of the issues but if anyone has ever seen a decent comprehensive
guide that would be tremendously useful.
If anyone has seen anything like this let me know, if not no worries will

just

keep fixing the things one by one =)

Regarding management plane,
One important thing to be aware of with virtually all the routers out there
is that in contrast to routing protocols if you enable management protocol
(for some strange reason) by default that protocol listens on all IP
addresses on the box.

And there don't seem to be a way in Junos how to restrict management-plane
protocols only to certain interfaces no matter what RE filter says.
In XR it's as easy as specifying a list of OOB or in-band interfaces against
a list of management protocols,

Yes in RE filter you can associate interface with say your SSH term but any
mistake in any of the preceding terms and all the management protocols wait
for an incoming session wide open.

Pool questions:
1) Are you folks using interfaces or interface groups in your RE filters to
further secure management plane access? (seems that team cymru doesn't)
2) Would you like to have the ability to restrict management plane protocols
only to certain internal interfaces outside of RE filter logic (explicitly
defining source IPs per protocol or XR-like management-plane protection
functionality)?

Thank you

adam

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


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

[Saku Ytti]

Hey,

Post by a***@netconsultings.com
And there don't seem to be a way in Junos how to restrict management-plane
protocols only to certain interfaces no matter what RE filter says.
In XR it's as easy as specifying a list of OOB or in-band interfaces against
a list of management protocols,

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?

But IOS-XR also cannot be configured very securely, JunOS can. Main
problems in IOS-XR:

a) Policers are per protocol, one BGP customer having L2 loop, and all
BGP customers in NPU suffer (excessive flow trap may alleviate, but
it's not turn-key and it can be configured perfectly)

b) LPTS packets are not subject to MQC, so you cannot complement LPTS
with MQC. Imagine one customer congesting specific LPTS policer, and
you want to add MQC policer to interface, to relieve the LPTS policer
from trash generated by this customer, not possible

c) IOS-XR does not guarantee that packets not dropped by LPTS are not
dropped later, JunOS technically does not, but in practice it's
extremely rare to drop packets once punted from NPU. After LPTS punt,
TCP packets are hashed to 8 TCP workers, in lab situation single TCP
worker can handle lot more than what single NPU LPTS protocol policer
can admit, but in production environment TCP worker performance may
degrade so much that your XIPC workers are dropping before there are
any LPTS drops, meaning you'll lose 1/8th of your BGP sessions.

Both A and C are being fixed, thanks CSCO. But I'm not very happy how
they chose to fix it.


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.

Of course this cannot happen, because you can't just randomly kill
people new breaking default configs. Which is another issue I think
vendors should address, so that they could evolve out-of-the-box
defaults over time. I think this would be quite easily solvable, if
in configurations you could declare which standards version you want
to use, and if nothing is declared, it'll use what ever standard the
image defaults to. This way Juniper could keep introducing new
standard config versions, and people could choose to stay in any
specific standard version as long as they want. Keeping backward
compatibility while allowing more sensible defaults.

[Gert Doering]

Hi,

Post by Saku Ytti
Of course this cannot happen, because you can't just randomly kill
people new breaking default configs. Which is another issue I think
vendors should address, so that they could evolve out-of-the-box
defaults over time. I think this would be quite easily solvable, if
in configurations you could declare which standards version you want
to use, and if nothing is declared, it'll use what ever standard the
image defaults to. This way Juniper could keep introducing new
standard config versions, and people could choose to stay in any
specific standard version as long as they want. Keeping backward
compatibility while allowing more sensible defaults.

*like*

gert

[Benny Amorsen]

Post by Saku Ytti
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.

Another great thing would be if you could match, in interface filters
other than lo0, "is destined for the RP" or the opposite. In most cases,
traffic that is destined for the router itself has completely different
security requirements to passthrough-traffic, which is also completely
different from router-generated traffic. It is a pain to use
IP-addresses to guess which category the traffic is.

Linux (and therefore RouterOS) does this by having THREE filters, input,
output, and forward. On router platforms you only get input and output.

In practice JunOS attaches filters to interfaces, so that kind of design
would lead to 4 filters: inputlocal, input, output, outputlocal. Having
"src-local", "dst-local", and "local" as terms instead would keep it at
2 filters.

The challenge might be that the input filter does not yet know whether
it is going to forward the traffic to the RP, since input filtering
necessarily happens before routing. It would definitely work for output
filters.


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

[Jason Healy]

Post by Benny Amorsen

Post by Saku Ytti
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.

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

[Jay Ford]

Post by Jason Healy

Post by Benny Amorsen

Post by Saku Ytti
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-***@uiowa.edu, phone: [phone]
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[a***@netconsultings.com]

Of Jay Ford
Sent: Thursday, July 12, 2018 9:26 PM

On Jul 12, 2018, at 10:09 AM, Benny Amorsen

Post by Benny Amorsen

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

[Chris Morrow]

On Thu, 12 Jul 2018 16:04:04 -0400,

Post by Jason Healy

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

[Jason Healy]

Maintaining scripts is a bit of a pain.
Do you have scripts on most of your devices?

We do, but we're a campus not a provider, so:

- we don't upgrade code versions often
- things are pretty homogenous (except for ELS vs non-ELS switches)

We make a lot of use of groups and templating so that the unique part of the config stays small. We reference the scripts from the group config, and use version numbers in the script names so we can have multiple versions of the same script on the device at the same time and reference them as the config changes.

Finally, I crufted up some perl to help with copying and deploying the script versions to all the REs in the field so we don't have to do it manually on each switch. I believe we could reference the scripts from a central web server, but things don't change often enough and I like having a manual step in the process (for the moment) as this is relatively recent.

Jason


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

[Pavel Lunin]

Maintaining scripts is a bit of a pain.

It's not maintaining scripts which is a bit of pain. It's on-box automaton
which is hell a lot of pain and there is very little reason to use it
nowadays. At least at any larger scale than a SOHO gateway for ten users,
doing something useless.

Well, op-scripts to simplify show-pipe-match for your NOC colleagues —
maybe, if you prefer to bother with this instead of something more modern
and multivendor.

Commit scripts — there is already enough ways to turn your JUNOS config
into unreadable mess of groups of interface ranges of groups with wildcards
with ten levels of spaghetti inheritance within LSYS. Commit scripts are
good to make it even worse, if you wish, but it won't make your network
happier.

Event scripts — just never ever, except you *reeeeaaally* love pain.

--
Pavel
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.ne

[Benny Lyne Amorsen]

Post by Pavel Lunin
It's not maintaining scripts which is a bit of pain. It's on-box automaton
which is hell a lot of pain and there is very little reason to use it
nowadays. At least at any larger scale than a SOHO gateway for ten users,
doing something useless.

That is all the more reason why JunOS should have a way to make an
apply-group out of all local IP addresses without having to resort to
full-blown scripting.

Ideally JunOS should offer another way of distinguishing between forward
traffic and locally-terminated/originated traffic in ACL's, without
having to rely on getting lists of IP addresses correct. The box knows
whether it is terminating the traffic or not. Just let me filter based
on that... (I know, it is not that easy to implement in practice.)


/Benny

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

[Saku Ytti]

On Mon, 16 Jul 2018 at 16:32, Benny Lyne Amorsen

Post by Benny Lyne Amorsen
Ideally JunOS should offer another way of distinguishing between forward
traffic and locally-terminated/originated traffic in ACL's, without
having to rely on getting lists of IP addresses correct. The box knows
whether it is terminating the traffic or not. Just let me filter based
on that... (I know, it is not that easy to implement in practice.)

Generally yes. But then there are some debatable things like IP
options and DHCP snooping. Which are transit, but subject to RE. So
should they be subject to LO0, or should you just police them in
forwarding-filters? I believe latter, Juniper seems to think former.

[Benny Lyne Amorsen]

Post by Saku Ytti
Generally yes. But then there are some debatable things like IP
options and DHCP snooping. Which are transit, but subject to RE. So
should they be subject to LO0, or should you just police them in
forwarding-filters? I believe latter, Juniper seems to think former.

I must admit I don't care much either way. My problem is that RE traffic
is subject to BOTH interface ingress filters AND lo0 ingress filters,
and similarly on egress you have to permit RE traffic outbound.

I often need an ACL that says "this interface cannot talk to/receive
traffic from RFC1918". Easily implemented for ingress traffic in two
terms with something like:

term reject-rfc1918 {
from {
destination-address 10.0.0.0/8;
destination-address 172.16.0.0/12;
destination-address 192.168.0.0/16;
}
then discard;
}
term accept-all {
then accept;
}

(plus the obvious reverse for the egress filter).

Unfortunately that breaks DHCP, ping to the router interfaces, dynamic
routing, and undoubtedly other things, if the interface address is in
RFC1918 space.

This is a needless pain, since it means I have to implement the same
rules twice: Once in lo0, and once in the interface filter. And I cannot
even do it with apply-groups, I have to actually build the appropriate
filter with the right set of interface addresses, and update it when the
list changes.


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

[a***@netconsultings.com]

Sent: Thursday, July 12, 2018 12:21 AM
Hey,

Post by a***@netconsultings.com
And there don't seem to be a way in Junos how to restrict
management-plane protocols only to certain interfaces no matter what RE

filter says.

Post by a***@netconsultings.com
In XR it's as easy as specifying a list of OOB or in-band interfaces
against a list of management protocols,

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?
But IOS-XR also cannot be configured very securely, JunOS can. Main
a) Policers are per protocol, one BGP customer having L2 loop, and all BGP
customers in NPU suffer (excessive flow trap may alleviate, but it's not turn-
key and it can be configured perfectly)

Well yes the granularity is per LC per NPU but not per interface/sub-interface.
If LPTS is using the same TCAM as transit traffic then there should be enough space for this additional granularity.

b) LPTS packets are not subject to MQC, so you cannot complement LPTS
with MQC. Imagine one customer congesting specific LPTS policer, and you
want to add MQC policer to interface, to relieve the LPTS policer from trash
generated by this customer, not possible

Yes if the LPTS would have per sub-interface granularity then or this complexity could have been offloaded onto MQC that would be much better.

c) IOS-XR does not guarantee that packets not dropped by LPTS are not
dropped later, JunOS technically does not, but in practice it's extremely rare
to drop packets once punted from NPU. After LPTS punt, TCP packets are
hashed to 8 TCP workers, in lab situation single TCP worker can handle lot
more than what single NPU LPTS protocol policer can admit, but in production
environment TCP worker performance may degrade so much that your XIPC
workers are dropping before there are any LPTS drops, meaning you'll lose
1/8th of your BGP sessions.

This one I was not aware of actually, so you say that theoretically aggregate from all LPTS policers can be more than what a single worker queue can handle resulting in tail-drops (well assuming that the hashing is imperfect congesting this one worker queue), is that right?
But what is the theoretical probability of that happening in production? I mean the hash and packet keys would need just line up to result in very bad distribution resulting in congestion of one of the 8 queues.

Both A and C are being fixed, thanks CSCO. But I'm not very happy how they
chose to fix it.

How do they plan on fixing that please?

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.

Yeah that's the nice thing about LPTS that it automatically punches holes (or pps rates) into the RSP filters based on protocols configured (sessions established or just configured, etc...)

Thank you

adam

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

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

[Saku Ytti]

Hey,

Post by a***@netconsultings.com
This one I was not aware of actually, so you say that theoretically aggregate from all LPTS policers can be more than what a single worker queue can handle resulting in tail-drops (well assuming that the hashing is imperfect congesting this one worker queue), is that right?

I'm saying in practice traffic from single NPU LPTS admitted can be
more than single XIPC worker can handle. The fix for this is rather
involved/complicated, where as Juniper approach is 'if you punt it,
you shouldn't drop it' and I think Cisco should adopt similar strategy
and investigate why XIPC worker performance is so variant (because it
doesn't have scheduling priority and they do not dare to use kernel
scheduling priorities because they've been hurt before).

Post by a***@netconsultings.com
But what is the theoretical probability of that happening in production? I mean the hash and packet keys would need just line up to result in very bad distribution resulting in congestion of one of the 8 queues.

Happens about twice a month for years.

Post by a***@netconsultings.com

Both A and C are being fixed, thanks CSCO. But I'm not very happy how they
chose to fix it.

How do they plan on fixing that please?

I'm not sure I'm at liberty to tell. But I don't agree with it, but I
understand rationale and rationale applies to all vendors, not just
Cisco. The problem with fixing things correctly is that short term you
break more, and dividends are paid over time. Commercial software is
driven to ever increasing technological debt, because it's safe and
simple to spot fix specific issue's symptoms, rather than to address
the architectural shortcomings that lead to it.
I don't have solution, if I'd provide commercial software, I'd almost
certainly end up in same situation as software is mature enough.

[Gert Doering]

Hi,

Post by a***@netconsultings.com
2) Would you like to have the ability to restrict management plane protocols
only to certain internal interfaces outside of RE filter logic (explicitly
defining source IPs per protocol or XR-like management-plane protection
functionality)?

This would have saved me lots of work over the years... so, yes.

We have fairly strong border ACLs that protect all "backbone links" and
loopback ranges, but customer connections are numbered out of different
address blocks - our PA that also hosts their firewalls/routers, their
PA/PI - so protecting all those by border ACLs is not practical. So,
being able to bind snmp/ssh/ntp/l2tp to "talk this on lo0, do not listen
on anything else" would have saved me quite a bit of annoyance over time.

(I do understand that we could number our customer links differently, and
maybe we can find the time to change *that* one day...)

gert

[John Kristoff]

On Wed, 11 Jul 2018 18:22:36 +0000

Post by Chris Boyd
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-***@puck.nether.net
https://puck.nethe