Mailing List Archive

> On Jul 11, 2018, at 1:17 PM, Drew Weaver <drew.weaver@thenap.com> 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

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 <drew.weaver@thenap.com> 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

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 <cboyd@gizmopartners.com> wrote:
>
>
>
> > On Jul 11, 2018, at 1:17 PM, Drew Weaver <drew.weaver@thenap.com> 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

Have you tried submitting your recommendations to the authors?

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

On Wed, 11 Jul 2018 at 21:23, Chris Boyd <cboyd@gizmopartners.com> wrote:
>
>
>
> > On Jul 11, 2018, at 1:17 PM, Drew Weaver <drew.weaver@thenap.com> 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

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-ford@uiowa.edu, phone: 319-335-5555

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 <drew.weaver@thenap.com> 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

On Wed, 11 Jul 2018 15:06:43 -0400,
Saku Ytti <saku@ytti.fi> 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 <cboyd@gizmopartners.com> wrote:
> >
> >
> >
> > > On Jul 11, 2018, at 1:17 PM, Drew Weaver <drew.weaver@thenap.com> 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 $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
> > _______________________________________________
> > 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

Hey Chris,

On Wed, 11 Jul 2018 at 22:16, Chris Morrow <morrowc@ops-netman.net> 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
<ephemeral>, source-port <bgp,ssh,etc>, 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

On Wed, 11 Jul 2018 15:14:40 -0400,
Jay Ford <jnford@uiowa.net> 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

? 11 juillet 2018 18:17 GMT, Drew Weaver <drew.weaver@thenap.com> :

> 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

On Wed, 11 Jul 2018 15:23:28 -0400,
Saku Ytti <saku@ytti.fi> wrote:
>
> Hey Chris,
>
> On Wed, 11 Jul 2018 at 22:16, Chris Morrow <morrowc@ops-netman.net> 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
> <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.

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

On Wed, 11 Jul 2018 at 22:26, Chris Morrow <morrowc@ops-netman.net> 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

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 <jnford@uiowa.net> 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-ford@uiowa.edu, phone: 319-335-5555
>
> 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 <drew.weaver@thenap.com> 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

> Of Saku Ytti
> Sent: Wednesday, July 11, 2018 8:44 PM
>
> On Wed, 11 Jul 2018 at 22:26, Chris Morrow <morrowc@ops-netman.net>
> 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

> 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

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

Hi,

On Wed, Jul 11, 2018 at 11:50:57PM +0100, adamv0025@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 gert@greenie.muc.de

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 gert@greenie.muc.de

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

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

[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:saku@ytti.fi]
Sent: Thursday, July 12, 2018 6:54 AM
To: Drew Weaver <drew.weaver@thenap.com>
Cc: cboyd@gizmopartners.com; Juniper List <juniper-nsp@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.



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

Saku Ytti <saku@ytti.fi> writes:

> I think best compromise would be, that JNPR would offer good filter,
> dynamically built based on data available in config and referring to
> empty prefix-lists when not possible to infer and customer can fill
> those prefix-lists if needed. And also have functional ddos-protection
> configuration out-of-the-box. People who want and can could override
> and configure themselves.

That would be really wonderful. A great start would be if there was a
way to get just the /32 (or /128) interface IP addresses in
apply-groups.

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

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 <drew.weaver@thenap.com> 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
> PORT STATE 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:saku@ytti.fi]
> Sent: Thursday, July 12, 2018 6:54 AM
> To: Drew Weaver <drew.weaver@thenap.com>
> Cc: cboyd@gizmopartners.com; Juniper List <juniper-nsp@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.
>
>
>
> On Wed, 11 Jul 2018 at 22:09, Drew Weaver <drew.weaver@thenap.com> wrote:
> >
> > Have you tried submitting your recommendations to the authors?
> >
> > -----Original Message-----
> > From: juniper-nsp [mailto:juniper-nsp-bounces@puck.nether.net] On
> > Behalf Of Saku Ytti
> > Sent: Wednesday, July 11, 2018 3:07 PM
> > To: cboyd@gizmopartners.com
> > Cc: Juniper List <juniper-nsp@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.
> >
> > On Wed, 11 Jul 2018 at 21:23, Chris Boyd <cboyd@gizmopartners.com> wrote:
> > >
> > >
> > >
> > > > On Jul 11, 2018, at 1:17 PM, Drew Weaver <drew.weaver@thenap.com> 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



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

> From: Saku Ytti [mailto:saku@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

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

On Jul 12, 2018, at 10:09 AM, Benny Amorsen <benny+usenet@amorsen.dk> wrote:
>
> Saku Ytti <saku@ytti.fi> writes:
>
>> I think best compromise would be, that JNPR would offer good filter,
>> dynamically built based on data available in config and referring to
>> empty prefix-lists when not possible to infer and customer can fill
>> those prefix-lists if needed. And also have functional ddos-protection
>> configuration out-of-the-box. People who want and can could override
>> and configure themselves.
>
> That would be really wonderful. A great start would be if there was a
> way to get just the /32 (or /128) interface IP addresses in
> apply-groups.

I started working on a commit script that would harvest all the local interface addresses and dump them in a prefix list so you could do just this. Never got around to finishing it, but it's on my ever-growing todo list.

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