How IP options work is platform specific.
It used to be that _transited_ IP-options were not subject to the lo0
filter, while still being risk for RE, so you'd implement
forwarding-filter, where you'd police IP-options or drop out right.
In more recent junipers, this behaviour has been changed so
Michael,
got it, thanks.
Lee,
the README of your repository provides an excellent introduction to RE
filtering. Based on your filters, I moved the processing of the IP
Options from edge filters to RE filters:
https://gist.github.com/tonusoo/efd9ab4fcf2bb5a45d34d5af5e3f3e0c#file-junos-re-filter
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
have
o 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
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 sh
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
k.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
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
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 based
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 b
- 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 answer
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 dete
> 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
> > apply-gro
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 po
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
>> th
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 sa
> 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 o
n 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 comprehe
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-prote
tti [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 s
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 abo
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 thin
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-pla
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
> 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
> 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
> "next-head
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 (an
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 c
❦ 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 hav
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 pro
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 tho
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
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, Informa
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,
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
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 next
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 Junipe
42 matches
Mail list logo
