Re: [j-nsp] IPv6 RE protection
Thanks, I will check those out. Do you consider not having IPv6 filter on RE a big security issue? Do you use it on your routers? BR On Sun, Apr 26, 2015 at 4:49 AM, Michael Loftis mlof...@wgops.com wrote: On Saturday, April 25, 2015, Cydon Satyr cydonsa...@gmail.com wrote: Hello, Currently we don't use any IPv6 RE protect filters on our routers (6PE only in network). We do use IPv6 filters on public interfaces, however. Would you recommend deploying IPv6 RE filters on our edge routers at least. What kind of configuration you have in your network? Also, do you know if Juniper still only supports matching on one next-header? Depends on your hardware. MPC can dig a bit more precisely but DPC is limited (hardware) http://www.juniper.net/documentation/en_US/junos14.2/topics/reference/general/firewall-filter-match-conditions-for-ipv6-traffic.html Best Regards community ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 RE protection
On 26/Apr/15 11:32, Cydon Satyr wrote: Thanks, I will check those out. Do you consider not having IPv6 filter on RE a big security issue? Do you use it on your routers? Take IPv6 as seriously as you take IPv4 - is my M.O. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 RE protection
Do you consider not having IPv6 filter on RE a big security issue? Yes. Do you use it on your routers? Yes. As an absolute minimum you want to protect against telnet/ssh login attempts towards the router interface addresses. But there's quite a bit more... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] solution to a firewall question
Hi Vijesh, On 24 Apr 2015, at 1:18 am, Vijesh Chandran vij...@juniper.net wrote: Hi all, I am wondering if we have a solution to this issue. I need two firewall attached to an interface as input-list. e.g.: f1 and f2. Input-list [f1 f2] f1 to match a condition (all tcp port 80) and accept and count that packet. f2 to classify those packets based on code points and push to a forwarding class. Is this possible? -Thanks, Vijesh If f2 is only matching on code-points, is there any reason you can't just use a class-of-service classifier instead for this functionality? Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls question
Hi James, On 27 Apr 2015, at 5:31 am, james list jameslis...@gmail.com wrote: Hi amarjeet Because if PE1 fails there is faster convergence to PE2 due to neighbor already established. Is there a reason you wouldn't consider using an L3VPN instead of a VPLS? It seems odd to me that you would be using L3 adjacencies to an L2 service. If it really is L2 fail-over you are chasing, then Amarjeet is correct - multihoming and site-preference are designed for exactly this purpose. If you customer requires L3 connectivity across your VPLS, you would be better off carrying their OSPF across the VPLS and let their CEs form adjacencies with each other - that way, you can take care of L2 fail-over, and the customer is responsible for L3. Cheers, Ben Cheers James Il 24/apr/2015 13:23, james list jameslis...@gmail.com ha scritto: I have a VPLS multi-homed environment with two MX routers (PE1 and PE2) connected to a single ethernet switch (CE1). I have PE1 configured with site-preference as primary and PE2 as backup. Behind the CE1 there is a router running OSPF with both MX (on irb interface). My goal is to have: 1)Multihoming to prevent loops 2)Let the router run two OSPF neighbor with both PE and not just one with the primary PE. I’m wondering if using: set routing-instances protocols vpls connectivity-type irb instead of the default (connectivity-type ce) could give me the option to reach my goal number 2) and if I can introduce any drawback. Or if there is another solution keeping 1). I don’t have a lab to test… Any help/feedback is really appreciated. Greetings James ___ 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] IPv6 RE protection
On (2015-04-27 02:40 +0800), Amarjeet Singh wrote:
Hello - Security is all or none thing, if something left open risk is
always there.
I would describe it less as binary off/on and more as layers. Each layer
adding budget requirements to the attacker, but also are increasingly
OPEX/CAPEX heavy for you to implement and may cause significant customer
dissatisfaction.
Notion that you have 'all' security, is almost certainly false.
It is probably exponential in its nature, cost increasing and amount of
attackers removed decreasing, so you almost certainly never ever will meet the
long tail of NSA/GCHQ and friends.
Often in commercial application you should just do what regulator mandates and
client contracts require, doing more way be business risk.
You should apply IPv6 filters too.
Juniper MX series book has very nice example for it, have a peek to it.
My top 5 errors people make:
1) use of 'port' (like port bgp, or anything else) - this allows attacker
reach arbitrary port in our device
2) omit 'destination-address', we may not be able to trust source-address in
every L3 MPLS VPN case, but we can trust that we don't provision
infrastructure addreses to L3 VPN customer interfaces
3) for tcp, don't do shortcuts, allow both directions separately unless you
can guarantee direction (bgp passive). Be familiar with your ephemeral port
range to avoid excessive range
4) be familiar with the protocol, does it impose TTL limits, if so, enforce
them. Does it impose source-port limits? If so, enforce them.
5) policing in junos lo0 filters is not useful or practical (due bps only and
due to build-in unconfigurable NPU = LC_CPU policer). Implement
ddos-protection, it's pps based, unfortunately you need to reconfigure every
protocol, so it's lot of cruft in config ('apply-flags omit' is your friend),
usually 'sub' level is useless, turn it off, I'd recommend turning 'ifl' level
statically on (not auto).
--
++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 RE protection
Hello - Security is all or none thing, if something left open risk is always there. You should apply IPv6 filters too. Juniper MX series book has very nice example for it, have a peek to it. Br, Amarjeet Message: 1 Date: Sat, 25 Apr 2015 22:36:47 +0200 From: Cydon Satyr cydonsa...@gmail.com To: juniper-nsp@puck.nether.net Subject: [j-nsp] IPv6 RE protection Message-ID: caf0puwd4wtpxy1xeth0vc2vdh07g0xmvhutmh0n1w7crzre...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Hello, Currently we don't use any IPv6 RE protect filters on our routers (6PE only in network). We do use IPv6 filters on public interfaces, however. Would you recommend deploying IPv6 RE filters on our edge routers at least. What kind of configuration you have in your network? Also, do you know if Juniper still only supports matching on one next-header? Best Regards community ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls question
Hi amarjeet Because if PE1 fails there is faster convergence to PE2 due to neighbor already established. Cheers James Il 24/apr/2015 13:23, james list jameslis...@gmail.com ha scritto: I have a VPLS multi-homed environment with two MX routers (PE1 and PE2) connected to a single ethernet switch (CE1). I have PE1 configured with site-preference as primary and PE2 as backup. Behind the CE1 there is a router running OSPF with both MX (on irb interface). My goal is to have: 1)Multihoming to prevent loops 2)Let the router run two OSPF neighbor with both PE and not just one with the primary PE. I’m wondering if using: set routing-instances protocols vpls connectivity-type irb instead of the default (connectivity-type ce) could give me the option to reach my goal number 2) and if I can introduce any drawback. Or if there is another solution keeping 1). I don’t have a lab to test… Any help/feedback is really appreciated. Greetings James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
