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

[Lee Pedder via 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

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

[Michael Hare via 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  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$

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

[Martin Tonusoo via 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

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

[Sean Clarke via 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  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

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

[Michael Hare via 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  On Behalf Of Saku Ytti
> via juniper-nsp
> Sent: Sunday, April 28, 2024 11:15 AM
> To: Martin Tonusoo 
> Cc: adamv0...@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  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
> > 

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

[Saku Ytti via 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  wrote:
>
> Hi.
>
> > In practical life IOS-XR control-plane is better protected than JunOS,
> > as configuring JunOS securely is very involved, considering that MX
> > book gets it wrong, offering horrible lo0 filter as does Cymru, what
> > chance the rest of us have?
>
> I recently worked on a RE protection filter based on the examples
> given in the "Juniper MX Series" book:
> https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c
>
> It's a tight filter for a simple network, e.g MPLS is not in use and
> thus there are no filters for signaling protocols or MPLS LSP
> ping/traceroute, routing instances are not in use, authentication for
> VRRPv3 or OSPF is not in use, etc.
>
> Few differences compared to filters in the MX book:
>
> * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
> the traceroute related filters in front of "accept-icmp" filter
>
> * "discard-extension-headers" filter in the book discards certain Next
> Header values and allows the rest. I changed it in a way that only
> specified Next Header values are accepted and rest are discarded. Idea
> is to discard unneeded extension headers as early as possible.
>
> * in term "neighbor-discovery-accept" in filter "accept-icmp6-misc"
> only the packets with Hop Limit value of 255 should be accepted
>
> * the "accept-bgp-v6" filter or any other IPv6 related RE filter in
> the book does not allow the router to initiate BGP sessions with other
> routers. I added a term named "accept-established-bgp-v6" in filter
> "accept-established-v6" which addresses this issue.
>
> * for the sake of readability and simplicity, I used names instead of
> numbers if possible. For example "icmp-type router-solicit" instead of
> "icmp-type 133".
>
> * in all occurrences, if it was not possible to match on the source IP
> address, then I strictly policed the traffic
>
> * traffic from management networks is not sharing policers with
> traffic from untrusted networks
>
>
> The overall structure of the RE filters in "Juniper MX Series" book is
> in my opinion very good. List of small filters which accept specific
> traffic and finally discard all the rest.
>
> Reason for having separate v4 and v6 prefix-lists is a Junos property
> to ignore the prefix-list altogether if it's used in a family inet
> filter while the prefix-list contains only the inet6 networks. Same is
> true if the prefix-list is used in family inet6 filter and the
> prefix-list contains only inet networks. For example, if only IPv4
> name servers addresses are defined under [edit system name-server] and
> prefix-list with apply-path "system name-server <*>" is used as a
> source prefix-list in some family inet6 filter, then actually no
> source address related restrictions apply. This can be checked with
> "show filter index  program" on a PFE CLI.
>
>
> Martin



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

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

[Barry Raveendran Greene via 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=population=population6=bgp_by=geo=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 
>  wrote:
> 
> Hi.
> 
>> In practical life IOS-XR control-plane is better protected than JunOS,
>> as configuring JunOS securely is very involved, considering that MX
>> book gets it wrong, offering horrible lo0 filter as does Cymru, what
>> chance the rest of us have?
> 
> I recently worked on a RE protection filter based on the examples
> given in the "Juniper MX Series" book:
> https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c
> 
> It's a tight filter for a simple network, e.g MPLS is not in use and
> thus there are no filters for signaling protocols or MPLS LSP
> ping/traceroute, routing instances are not in use, authentication for
> VRRPv3 or OSPF is not in use, etc.
> 
> Few differences compared to filters in the MX book:
> 
> * "ttl-except 1" in "accept-icmp" filter was avoided by simply moving
> the traceroute related filters in front of "accept-icmp" filter
> 
> * "discard-extension-headers" filter in the book discards certain Next
> Header values and allows the rest. I changed it in a way that only
> specified Next Header values are accepted and rest are discarded. Idea
> is to discard unneeded extension headers as early as possible.
> 
> * in term "neighbor-discovery-accept" in filter "accept-icmp6-misc"
> only the packets with Hop Limit value of 255 should be accepted
> 
> * the "accept-bgp-v6" filter or any other IPv6 related RE filter in
> the book does not allow the router to initiate BGP sessions with other
> routers. I added a term named "accept-established-bgp-v6" in filter
> "accept-established-v6" which addresses this issue.
> 
> * for the sake of readability and simplicity, I used names instead of
> numbers if possible. For example "icmp-type router-solicit" instead of
> "icmp-type 133".
> 
> * in all occurrences, if it was not possible to match on the source IP
> address, then I strictly policed the traffic
> 
> * traffic from management networks is not sharing policers with
> traffic from untrusted networks
> 
> 
> The overall structure of the RE filters in "Juniper MX Series" book is
> in my opinion very good. List of small filters which accept specific
> traffic and finally discard all the rest.
> 
> Reason for having separate v4 and v6 prefix-lists is a Junos property
> to ignore the prefix-list altogether if it's used in a family inet
> filter while the prefix-list contains only the inet6 networks. Same is
> true if the prefix-list is used in family inet6 filter and the
> prefix-list contains only inet networks. For example, if only IPv4
> name servers addresses are defined under [edit system name-server] and
> prefix-list with apply-path "system name-server <*>" is used as a
> source prefix-list in some family inet6 filter, then actually no
> source address related restrictions apply. This can be checked with
> "show filter index  program" on a PFE CLI.
> 
> 
> Martin
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Martin Tonusoo via 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  program" on a PFE CLI.


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

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

[John Kristoff]

On Wed, 11 Jul 2018 18:22:36 +
Chris Boyd  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.

  

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

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

[Antti Ristimäki]

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

> On Fri, 13 Jul 2018 at 06:19, Antti Ristimäki  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

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

[Saku Ytti]

On Fri, 13 Jul 2018 at 06:19, Antti Ristimäki  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

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

[Antti Ristimäki]

Hi,

- On 12 Jul, 2018, at 13:54, Saku Ytti s...@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

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

[adamv0025]

> 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
> 
> wrote:
> > > Saku Ytti  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

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

[Chris Morrow]

On Thu, 12 Jul 2018 16:04:04 -0400,
Jason Healy  wrote:
> 
> On Jul 12, 2018, at 10:09 AM, Benny Amorsen 
> wrote:
> > 
> > Saku Ytti  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

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

[Jay Ford]

On Thu, 12 Jul 2018, Jason Healy wrote:
On Jul 12, 2018, at 10:09 AM, Benny Amorsen  

wrote:

> Saku Ytti  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-f...@uiowa.edu, phone: 319-335-
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Jason Healy]

On Jul 12, 2018, at 10:09 AM, Benny Amorsen  wrote:
> 
> Saku Ytti  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.

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

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

[Saku Ytti]

Hey,

> 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).

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

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

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

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

[adamv0025]

> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, July 12, 2018 12:21 AM
> 
> Hey,
> 
> > 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)
> 
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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[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.
On Thu, 12 Jul 2018 at 16:51, Drew Weaver  wrote:
>
> 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
> PORTSTATE SERVICE
> 21/tcp  open  ftp
> 80/tcp  open  http
> 443/tcp open  https
>
> [drew@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...
>
> drew@chuck> show configuration system services
> ssh {
> root-login deny;
> }
>
> Thanks,
> -Drew
>
> -Original Message-
> From: Saku Ytti [mailto:s...@ytti.fi]
> Sent: Thursday, July 12, 2018 6:54 AM
> To: Drew Weaver 
> Cc: cb...@gizmopartners.com; Juniper List 
> 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.
>
>
>
> On Wed, 11 Jul 2018 at 22:09, Drew Weaver  wrote:
> >
> > Have you tried submitting your recommendations to the authors?
> >
> > -Original Message-
> > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On
> > Behalf Of Saku Ytti
> > Sent: Wednesday, July 11, 2018 3:07 PM
> > To: cb...@gizmopartners.com
> > Cc: Juniper List 
> > 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.
> >
> > On Wed, 11 Jul 2018 at 21:23, Chris Boyd  wrote:
> > >
> > >
> > >
> > > > On Jul 11, 2018, at 1:17 PM, Drew Weaver  wrote:
> > > >
> > > > 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-nsp@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> >
> >
> > --
> >   ++ytti
> > ___
> > 

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

[Benny Amorsen]

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

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

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

[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
PORTSTATE SERVICE
21/tcp  open  ftp
80/tcp  open  http
443/tcp open  https

[drew@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...

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

Thanks,
-Drew

-Original Message-
From: Saku Ytti [mailto:s...@ytti.fi] 
Sent: Thursday, July 12, 2018 6:54 AM
To: Drew Weaver 
Cc: cb...@gizmopartners.com; Juniper List 
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.



On Wed, 11 Jul 2018 at 22:09, Drew Weaver  wrote:
>
> Have you tried submitting your recommendations to the authors?
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On 
> Behalf Of Saku Ytti
> Sent: Wednesday, July 11, 2018 3:07 PM
> To: cb...@gizmopartners.com
> Cc: Juniper List 
> 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.
>
> On Wed, 11 Jul 2018 at 21:23, Chris Boyd  wrote:
> >
> >
> >
> > > On Jul 11, 2018, at 1:17 PM, Drew Weaver  wrote:
> > >
> > > 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-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



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

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

[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.



On Wed, 11 Jul 2018 at 22:09, Drew Weaver  wrote:
>
> Have you tried submitting your recommendations to the authors?
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
> Saku Ytti
> Sent: Wednesday, July 11, 2018 3:07 PM
> To: cb...@gizmopartners.com
> Cc: Juniper List 
> 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.
>
> On Wed, 11 Jul 2018 at 21:23, Chris Boyd  wrote:
> >
> >
> >
> > > On Jul 11, 2018, at 1:17 PM, Drew Weaver  wrote:
> > >
> > > 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-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



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

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

[Gert Doering]

Hi,

On Thu, Jul 12, 2018 at 02:20:42AM +0300, Saku Ytti wrote:
> 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
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Gert Doering]

Hi,

On Wed, Jul 11, 2018 at 11:50:57PM +0100, adamv0...@netconsultings.com wrote:
> 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

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Saku Ytti]

Hey,

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




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

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

[adamv0025]

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

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

[adamv0025]

> Of Saku Ytti
> Sent: Wednesday, July 11, 2018 8:44 PM
> 
> On Wed, 11 Jul 2018 at 22:26, Chris Morrow 
> wrote:
> 
> > > 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.
> --
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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[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.

> Le 11 juil. 2018 à 21:14, Jay Ford  a écrit :
> 
> 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
> email: jay-f...@uiowa.edu, phone: 319-335-
> 
> On Wed, 11 Jul 2018, Olivier Benghozi wrote:
>> 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.
>> 
>>> Le 11 juil. 2018 à 20:17, Drew Weaver  a écrit :
>>> 
>>> 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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Saku Ytti]

On Wed, 11 Jul 2018 at 22:26, Chris Morrow  wrote:

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

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

[Chris Morrow]

On Wed, 11 Jul 2018 15:23:28 -0400,
Saku Ytti  wrote:
> 
> Hey Chris,
> 
> On Wed, 11 Jul 2018 at 22:16, Chris Morrow  wrote:
> 
> > > 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...

> 
> > > b) LO filter matches on 'port'
> >
> > on 'port'.. meaning I can't do:
> >   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
> , source-port , 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.

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

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

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

[Vincent Bernat]

 ❦ 11 juillet 2018 18:17 GMT, 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
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chris Morrow]

On Wed, 11 Jul 2018 15:14:40 -0400,
Jay Ford  wrote:
> 
> 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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Saku Ytti]

Hey Chris,

On Wed, 11 Jul 2018 at 22:16, Chris Morrow  wrote:

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

> > b) LO filter matches on 'port'
>
> on 'port'.. meaning I can't do:
>   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
, source-port , when you want to allow far-end
to respond to connection you opened.

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

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

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

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

[Chris Morrow]

On Wed, 11 Jul 2018 15:06:43 -0400,
Saku Ytti  wrote:
> 
> 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... :)

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

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

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

> 
> 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.
> 
> On Wed, 11 Jul 2018 at 21:23, Chris Boyd  wrote:
> >
> >
> >
> > > On Jul 11, 2018, at 1:17 PM, Drew Weaver  wrote:
> > >
> > > 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-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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[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
email: jay-f...@uiowa.edu, phone: 319-335-

On Wed, 11 Jul 2018, Olivier Benghozi wrote:

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.


Le 11 juil. 2018 à 20:17, Drew Weaver  a écrit :

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

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

[Drew Weaver]

Have you tried submitting your recommendations to the authors?

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Saku Ytti
Sent: Wednesday, July 11, 2018 3:07 PM
To: cb...@gizmopartners.com
Cc: Juniper List 
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.

On Wed, 11 Jul 2018 at 21:23, Chris Boyd  wrote:
>
>
>
> > On Jul 11, 2018, at 1:17 PM, Drew Weaver  wrote:
> >
> > 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-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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[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.

> Le 11 juil. 2018 à 20:17, Drew Weaver  a écrit :
> 
> 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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Chris Boyd]

> On Jul 11, 2018, at 1:17 PM, Drew Weaver  wrote:
> 
> 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-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp