How IP options work is platform specific.
It used to be that _transited_ IP-options were not subject to the lo0
filter, while still being risk for RE, so you'd implement
forwarding-filter, where you'd police IP-options or drop out right.
In more recent junipers, this behaviour has been changed
Michael,
got it, thanks.
Lee,
the README of your repository provides an excellent introduction to RE
filtering. Based on your filters, I moved the processing of the IP
Options from edge filters to RE filters:
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
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
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
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
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
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
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
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
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
- 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
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
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
> 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 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
> >
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
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
>>
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
> 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
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
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
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
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
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
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
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
> 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
> 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
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
>
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
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
❦ 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
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
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
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
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,
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
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
> 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
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
41 matches
Mail list logo
