Re: [j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?
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] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?
Martin T writes:
>aren't you using grave accent("echo -e "\x60"") character? I was using
>"echo -e "\x27"" character.
Doh! I read apostrophe (even named the script apos.slax) but my
brain turned into backtick.
Yes, this looks like a JUNOS bug:
root@box> op apos char "'"
''':(null):(2) Invalid expression
error: runtime error
error: Evaluating user parameter char failed
The underlaying slax library handles it correctly:
% slaxproc -E -n cs-examples/apos.slax -g -a char "'"
got: '
But it looks like this is explicitly handled in slaxproc.c:
quote = strrchr(pvalue, '\"') ? '\'' : '\"';
tvalue[0] = quote;
memcpy(tvalue + 1, pvalue, plen);
tvalue[plen + 1] = quote;
tvalue[plen + 2] = '\0';
This logic doesn't appear in the JUNOS driver (/usr/libexec/ui/cscript).
I'll open a PR for this.
There is a limitation in XSLT that one can't mix strings with both
single and double quotes. Strange but true.
Thanks,
Phil
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and MX104
On Thu, Jul 12, 2018 at 7:19 PM, Aaron Gould wrote: > I hear some chatter about systems getting old and incapable and allegedly > being end of life or end of serviced... I just saw these links, dated July > 10, 2018 so very recent, they mentioned how this company is using these two > platforms for financial and government critical sectors. > That's normal. Government and financial sectors always use the most outdated solutions because of bureaucracy, compliance, certifications and all those WTF reasons :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?
On Thu, Jul 12, 2018 at 11:20 PM Phil Shafer wrote:
>
> Martin T writes:
> >Is it possible to pass apostrophe character(ASCII dec code 39) as an
> >argument value to SLAX script? I have tried to escape it, but it does
> >not seem to work:
>
> Quote it:
>
> version 1.2;
>
> param $char = "-";
>
> main {
> "got: " _ $char;
> }
>
> root@box> op apos char "`"
> got: `
>
> root@box>
>
> Thanks,
> Phil
Phil,
aren't you using grave accent("echo -e "\x60"") character? I was using
"echo -e "\x27"" character.
thanks,
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'?
> 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'?
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'?
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] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?
Martin T writes:
>Is it possible to pass apostrophe character(ASCII dec code 39) as an
>argument value to SLAX script? I have tried to escape it, but it does
>not seem to work:
Quote it:
version 1.2;
param $char = "-";
main {
"got: " _ $char;
}
root@box> op apos char "`"
got: `
root@box>
Thanks,
Phil
___
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'?
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
[j-nsp] EX4550 and MX104
I hear some chatter about systems getting old and incapable and allegedly being end of life or end of serviced... I just saw these links, dated July 10, 2018 so very recent, they mentioned how this company is using these two platforms for financial and government critical sectors. https://investor.juniper.net/investor-relations/press-releases/press-release-details/2018/ESDS-Selects-Juniper-Networks-to-Power-Future-Ready-Cloud-in-India/default.aspx https://www.google.com/amp/s/www.zacks.com/amp/stock/news/310933/juniper-provides-improved-cloud-application-delivery-to-esds Aaron ___ 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'?
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] Segment Routing Real World Deployment (was: VPC mc-lag)
This is from an industry perspective and not specific to Juniper. BIER won't really happen without hardware support which is coming but will not be compatible with a lot of already deployed hardware. There was some IETF work going on to figure out how to map multicast to SR-MPLS but it kind of died off last year. TreeSID is more of a Cisco solution, and relies on an external PCE to build the multicast tree at every branch point across an SR-enabled network. Near-term mLDP specifically for multicast, without unicast enabled, is a solution. Ingress replication is becoming a bit more popular as multicast as an overall percentage of traffic has continued to drop. Phil On 7/12/18, 6:43 AM, "juniper-nsp on behalf of Jackson, William" wrote: So just to throw a question out there: When I last looked at SR this was a big empty hole when it came to multicast. As we are possibly removing mLDP and RSVP from the network in favour of SR(-TE) what are people doing to fill this void. There were some drafts being worked on last year and if I recall one that seemed more "developed" was "Bit Index Explicit Replication", but I haven't heard anything more about this topic and it hasn't been mentioned in the thread so far. Any comments? Thanks ___ 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'?
> 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'?
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'?
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'?
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] Segment Routing Real World Deployment (was: VPC mc-lag)
I believe you're right, that there isn't really anything there. But I'd love to be wrong. I see no reason why NG-MVPN couldn't have SR tunnel / forwarding-plane. On Thu, 12 Jul 2018 at 13:43, Jackson, William wrote: > > So just to throw a question out there: > > When I last looked at SR this was a big empty hole when it came to multicast. > As we are possibly removing mLDP and RSVP from the network in favour of > SR(-TE) what are people doing to fill this void. > > There were some drafts being worked on last year and if I recall one that > seemed more "developed" was "Bit Index Explicit Replication", but I haven't > heard anything more about this topic and it hasn't been mentioned in the > thread so far. > > Any comments? > > Thanks > > ___ > 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'?
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] Segment Routing Real World Deployment (was: VPC mc-lag)
So just to throw a question out there: When I last looked at SR this was a big empty hole when it came to multicast. As we are possibly removing mLDP and RSVP from the network in favour of SR(-TE) what are people doing to fill this void. There were some drafts being worked on last year and if I recall one that seemed more "developed" was "Bit Index Explicit Replication", but I haven't heard anything more about this topic and it hasn't been mentioned in the thread so far. Any comments? Thanks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?
I thought I had it by being cunning, but, no!
{master}
nward@mx> op test chr \x27
''':(null):(2) Invalid expression
error: runtime error
error: Evaluating user parameter chr failed
{master}
nward@mx> op test chr \\x27
'\'':(null):(3) Invalid expression
error: runtime error
error: Evaluating user parameter chr failed
:-(
> On 12/07/2018, at 8:00 PM, Martin T wrote:
>
> Hi!
>
> Is it possible to pass apostrophe character(ASCII dec code 39) as an
> argument value to SLAX script? I have tried to escape it, but it does
> not seem to work:
>
> root@vmx1> op test chr '
> ''':(null):(2) Invalid expression
> error: runtime error
> error: Evaluating user parameter chr failed
>
> root@vmx1> op test chr "'"
> ''':(null):(2) Invalid expression
> error: runtime error
> error: Evaluating user parameter chr failed
>
> root@vmx1> op test chr \'
> '\'':(null):(3) Invalid expression
> error: runtime error
> error: Evaluating user parameter chr failed
>
> root@vmx1> op test chr '''
> ':(null):(2) Invalid expression
> error: runtime error
> error: Evaluating user parameter chr failed
>
> root@vmx1>
>
>
> Script named test is following:
>
> root@vmx1> file show /var/db/scripts/op/test.slax
> version 1.1;
>
> ns junos = "http://xml.juniper.net/junos/*/junos;;
> ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
> ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
>
> import "../import/junos.xsl";
>
> var $arguments = {
> {
> "chr";
>}
> }
>
> param $chr;
>
> match / {
> {
> "Character: " _ "'" _ $chr _ "'";
>}
> }
>
> root@vmx1>
>
> I guess it is not possible and one needs to use get-input() function?
>
>
> thanks,
> 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
[j-nsp] Is it possible to pass apostrophe character(ASCII dec code 39) as an argument value to SLAX script?
Hi!
Is it possible to pass apostrophe character(ASCII dec code 39) as an
argument value to SLAX script? I have tried to escape it, but it does
not seem to work:
root@vmx1> op test chr '
''':(null):(2) Invalid expression
error: runtime error
error: Evaluating user parameter chr failed
root@vmx1> op test chr "'"
''':(null):(2) Invalid expression
error: runtime error
error: Evaluating user parameter chr failed
root@vmx1> op test chr \'
'\'':(null):(3) Invalid expression
error: runtime error
error: Evaluating user parameter chr failed
root@vmx1> op test chr '''
':(null):(2) Invalid expression
error: runtime error
error: Evaluating user parameter chr failed
root@vmx1>
Script named test is following:
root@vmx1> file show /var/db/scripts/op/test.slax
version 1.1;
ns junos = "http://xml.juniper.net/junos/*/junos;;
ns xnm = "http://xml.juniper.net/xnm/1.1/xnm;;
ns jcs = "http://xml.juniper.net/junos/commit-scripts/1.0;;
import "../import/junos.xsl";
var $arguments = {
{
"chr";
}
}
param $chr;
match / {
{
"Character: " _ "'" _ $chr _ "'";
}
}
root@vmx1>
I guess it is not possible and one needs to use get-input() function?
thanks,
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'?
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'?
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] Segment Routing Real World Deployment (was: VPC mc-lag)
On 10/Jul/18 23:33, adamv0...@netconsultings.com wrote: > Now a robust transport network with appropriate redundancy and failover > mechanisms is responsibility of each operator. > One can use IGP tuning or take the new path computation out of the equation > completely with FRR options: LDP + FRR based on LFA or even rLFA (with > targeted LDP sessions all over the place) or SR with ti-LFA or RSVP-TE FRR. > With FRR there's really no need to tune IGP for fast SPF path computation > -but there might still be need to tune it for fast LSA/LSP propagation (think > BGP-PIC "core"). > With FRR it then all boils down to how fast can link failures be detected > -loss of light will always be the fastest method, but the good practice is to > use some sort of keepalives as well (BFD/CFM/IGP-keepalives). > Then the faster the link down and up detection the faster the link can flap > -that's where one should use dampening features (IP event dampening, bfd > damping or hold-down timers -for getting interface up ) to protect your IGP > (or BGP dampening for nexus users -since nexus platform doesn't have any > other dampening (exception is/was 3548)). Agreed. What we do is IS-IS + BFD (for IS-IS only) + (r)LFA. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
