Re: [j-nsp] SQL*Net and firewalls..
Thanks for sharing Derick... Good stuff! Stefan Fouant Technical Trainer, Juniper Networks JNCIE-ER #70, JNCIE-M #513, JNCI http://www.shortestpathfirst.net http://www.twitter.com/sfouant Sent from my iPad On Jun 30, 2011, at 8:36 PM, Derick Winkworth wrote: > New blog post I hope others find helpful... > > > http://blinking-network.blogspot.com/2011/06/sqlnet-aka-oracle-tns-and-firewalls.html > ___ > 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 'protect-re' sanity check
On Thu, 30 Jun 2011, Rafael Rodriguez wrote:
> Hello List,
>
> I need some help with a sanity check on a couple routing engine filters for
> IPv6; specifically on the ICMPv6 section. The router will connect to
> routers only, no end hosts (not allowing RA and RS). Filters based off the
> Juniper Day One ebook Securing the Routing Engine. Should anything be added
> or removed? How are others doing this? Thanks in advanced.
>
[snip..]
> filter accept-icmpv6 {
> apply-flags omit;
> term accept-icmp {
> from {
> destination-prefix-list {
> router-ipv6;
> router-ipv6-logical-systems;
> }
> next-header icmpv6;
> icmp-type [ echo-reply echo-request time-exceeded unreachable
> source-quench parameter-problem neighbor-advertisement neighbor-solicit
> packet-too-big ];
> }
> then {
> policer management-5m;
> count accept-icmpv6;
> accept;
> }
> }
> }
[snip..]
Rafael,
I'll address your ICMPv6 section. With out knowing the contents of
your router-ipv6 & router-ipv6-logical-systems prefix lists I can only
guess, but it looks like you're allowing both too much and not enough.
ICMPv6 is a more important beast than ICMPv4 because of it's larger
role (EG it replaces ARP, and the lack of v6 broadcasts make proper
multicast handling more important).
Specifically, you should differenciate between local scope traffic and
global scope traffic. Some ICMPv6 messages should only be acceped from
local scope addresses, others should be both local & global scoped.
EG: RS/RA & NS/NA messages should only be acceped when sourced from
a local-scope address & sent to a local-scope or multi-cast addr.
Same goes for the Multicast varients of those messages
(EG Multicast Router Discovery/MRA & Listner Query/Listner Report).
So for this type of message, your destination-prefix-list needs
to contain fe80::/10 & ff00::/8 as well as making sure that the
source address is fe80::/10.
A good source of info on this topic is the NIST IPv6 deployment
guidelines. They have specific chapters dealing with handling
ICMPv6 and multicast traffic. See:
http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf
In chapter 3 they have a nice table that lists recommended ICMPv6
filtering actions: "must not drop", "should not drop" and should
not transit a router for various message types.
Be aware that each v6 router interface needs both a global-scope
and local-scope address. If you only specify a global-scope address
the router will SLAAC a local-scope address. For debugging & logging
purposes, it's better to specify both so they're deterministic.
EG:
xe-1/0/0 {
mtu 9192;
unit 0 {
family inet {
mtu 9178;
filter {
input world-input;
}
address 129.255.21.50/30;
}
family inet6 {
mtu 9178;
filter {
input world-input-v6;
}
address 2611:0:e50:7016::1/64 {
primary;
}
address fe80::e50:7016:0:1/64;
}
}
}
I chose the bottom 64 bits of that LinkLocal addr to partially reflect the
global-scope subnet addr so to make it easier to identify packets from the
router when trying to debug problems on clients.
Note that if you're talking to any Microsoft Windows clients be sure that
the top 64 bits of that LinkLocal addr are fe80:: otherwise due to a bug
in their firewall filters they won't hear you. ;(
IE: fe80:0:e50:7016::1 is a legal LinkLocal addr but windows clients
won't 'hear' it (found this out the hard way).
IPv6, it's a whole new challenge.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SQL*Net and firewalls..
New blog post I hope others find helpful... http://blinking-network.blogspot.com/2011/06/sqlnet-aka-oracle-tns-and-firewalls.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] New J-net publications: Secure the routing engine and Useful tips/tricks
You are right in that it may present too great a risk for some people
to feel comfortable adopting. Still a nice rule, if even to just use
and activate when needed. YMMV.
-M
On Wed, Jun 22, 2011 at 1:08 AM, Daniel Verlouw wrote:
> Hi,
>
> On Wed, Jun 22, 2011 at 02:01, Harry Reynolds wrote:
>> Hey all, Please pardon the wide distribution. I recall seeing postings on
>> this list regarding current best practices for securing Juniper Networks
>> Routing Engines via firewall filters.
>
> just briefly skimmed over it, good stuff!
>
> Perhaps I'm nitpicking here, but my first thought when seeing the
> following term was; this will allow anyone to access all open TCP
> ports, simply by modifying their host outbound TTL so that the packets
> arrive with TTL=1 at the router.
>
> term accept-traceroute-tcp {
> from {
> destination-prefix-list {
> router-ipv4;
> router-ipv4-logical-systms;
> }
> protocol tcp;
> ttl 1;
> }
> then {
> policer management-1m;
> count accept-traceroute-tcp;
> accept;
> }
> }
>
> Perhaps I misread the rest of the config or maybe I'm being paranoid,
> but this something I would definitely not recommend :-)
>
> BR, Daniel.
> ___
> 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] IPv6 'protect-re' sanity check
Hello List,
I need some help with a sanity check on a couple routing engine filters for
IPv6; specifically on the ICMPv6 section. The router will connect to
routers only, no end hosts (not allowing RA and RS). Filters based off the
Juniper Day One ebook Securing the Routing Engine. Should anything be added
or removed? How are others doing this? Thanks in advanced.
prefix-list router-ipv6 {
apply-path "interfaces <*> unit <*> family inet6 address <*:*>";
}
prefix-list router-ipv6-logical-systems {
apply-path "logical-systems <*> interfaces <*> unit <*> family inet6
address <*:*>";
}
policer management-1m {
apply-flags omit;
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 625k;
}
then discard;
}
policer management-5m {
apply-flags omit;
if-exceeding {
bandwidth-limit 5m;
burst-size-limit 625k;
}
then discard;
}
filter accept-icmpv6 {
apply-flags omit;
term accept-icmp {
from {
destination-prefix-list {
router-ipv6;
router-ipv6-logical-systems;
}
next-header icmpv6;
icmp-type [ echo-reply echo-request time-exceeded unreachable
source-quench parameter-problem neighbor-advertisement neighbor-solicit
packet-too-big ];
}
then {
policer management-5m;
count accept-icmpv6;
accept;
}
}
}
filter accept-traceroute {
apply-flags omit;
term accept-traceroute-udp {
from {
destination-prefix-list {
router-ipv6;
router-ipv6-logical-systems;
}
next-header udp;
destination-port 33435-33450;
}
then {
policer management-1m;
count accept-traceroute-udp;
accept;
}
}
term accept-traceroute-icmpv6 {
from {
destination-prefix-list {
router-ipv6;
router-ipv6-logical-systems;
}
next-header icmpv6;
icmp-type [ echo-request timestamp time-exceeded ];
}
then {
policer management-1m;
count accept-traceroute-icmpv6;
accept;
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OAM on logical router
On 6/30/2011 1:25 AM, MSusiva wrote: Hi Experts, Does logical router on MX support CFM? As far as I know these are simply interface specific settings, so it shouldn't make a difference if they are running within a logical system, virtual router construct, or simply within the default instance. -- Stefan Fouant JNCIE-ER #70, JNCIE-M #513, JNCI http://www.shortestpathfirst.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
