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
30 matches
Mail list logo
