-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Only thing you might want to consider adding is the "log" keyword to
your discard term. Just makes things a little quicker when you add a
new protocol that you need the RE to handle that you didn't update
your control-plane filter to support (not that anyone ever runs into
that ;)
Another thing to think about is that if you start doing VRF's, you may
want a filter there. Apply groups can be your friend to insure your
VRF Loopbacks get the same/right protection. So something like the
following might be of interest. If you really want to be tight in
your filtering you can always create a unique filter per VRF...
groups {
ifcs-all-loopback {
interfaces {
lo0 {
unit <*> {
family inet {
filter {
input inet-controlplane-in;
}
}
family inet6 {
filter {
input inet6-controlplane-in;
}
}
}
}
}
}
}
interfaces {
lo0 {
apply-groups ifcs-all-loopback;
description "Loopback Interface";
unit 0 {
description "Native Loopback";
family inet {
address x.x.x.x/32;
}
}
unit 1 {
description "VRF A";
family inet {
address x.x.x.x/32;
}
}
}
}
David
On May 22, 2009, at 8:57 AM, Stefan Fouant wrote:
Yep, you got it. It's only for traffic destined for the RE, not
transit traffic. Here is an example:
policy-options {
prefix-list bgp_peers {
apply-path "protocols bgp group <*> neighbor <*>";
}
}
firewall {
filter router-access {
term ssh {
from {
source-prefix-list {
ssh;
}
protocol tcp;
destination-port ssh;
}
then {
count ssh;
accept;
}
}
term snmp {
from {
source-prefix-list {
corporate;
}
protocol udp;
port snmp;
}
then {
count snmp;
accept;
}
}
term ntp {
from {
source-prefix-list {
corporate;
}
protocol udp;
port ntp;
}
then {
count ntp;
accept;
}
}
term bgp {
from {
source-prefix-list {
bgp_peers;
}
protocol tcp;
port bgp;
}
then {
count bgp;
accept;
}
}
term ospf {
from {
protocol ospf;
}
then {
count ospf;
accept;
}
}
term icmp {
from {
protocol icmp;
}
then {
count icmp;
accept;
}
}
term ike {
from {
protocol udp;
port 500;
}
then {
count ike;
accept;
}
}
term log-ssh {
from {
protocol tcp;
destination-port ssh;
}
then {
log;
syslog;
reject;
}
}
term deny {
then {
count deny;
discard;
}
}
}
}
Notice the bgp_peers prefix-list. Using the apply-path statement with
the wildcards allows you to create a firewall filter to allow BGP
peers from only those whom you have configured under 'protocols bgp'
and the prefix-list is dynamically updated each time you create a new
peer. Also, take a look at the log-ssh term which allows me to log
ssh attempts from non-allowed hosts. You could also couple
rate-limiters with something like the ICMP term in order to prevent
things like ICMP flooding from overtaking your RE.
HTHs.
--
Stefan Fouant
Stay the patient course.
Of little worth is your ire.
The network is down.
On Fri, May 22, 2009 at 11:25 AM, Brendan Mannella
<[email protected]> wrote:
True, i have seen those.
I understand i would need to think of everything needed. So even
OSPF, BGP, basically any protocol i would use. But i dont need to
worry about traffic transiting the switch such as customer
services, like http, ftp, etc. Correct?
Thanks,
Brendan
----- Original Message -----
From: "Stefan Fouant" <[email protected]>
To: "Brendan Mannella" <[email protected]>, "juniper-nsp" <[email protected]
>
Sent: Friday, May 22, 2009 10:57:42 AM GMT -05:00 US/Canada Eastern
Subject: Re: [j-nsp] SSH Filter
That filter would certainly do what you want but I would strongly
advise against using an accept-all term as your last term. If you
truly want to take a hardened control plane security posture, why not
allow that which is specifically required and drop the rest? Team
Cymru has some good control plane filter templates available on their
website.
Regards,
On 5/22/09, Brendan Mannella <[email protected]> wrote:
All, i know this has been covered a million times, but i just
wanted to
check with the list to see if this is the best/recommended way to
restrict
ssh access to a EX switch. I did google this, but noticed people
doing it
different ways.
set firewall family inet filter RE_FILTER term SSH from source-
address
10.0.0.1/32
set firewall family inet filter RE_FILTER term SSH from source-
address
10.0.0.2/32
set firewall family inet filter RE_FILTER term SSH from protocol tcp
set firewall family inet filter RE_FILTER term SSH from
destination-port 22
set firewall family inet filter RE_FILTER term SSH then accept
set firewall family inet filter RE_FILTER term SSH_BLOCK from
protocol tcp
set firewall family inet filter RE_FILTER term SSH_BLOCK from
destination-port 22
set firewall family inet filter RE_FILTER term SSH_BLOCK then
discard
set firewall family inet filter RE_FILTER term everything-else
then accept
set interfaces lo0 unit 0 family inet filter input RE_FILTER
Please Advise.
Thanks,
Brendan Mannella
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Sent from Gmail for mobile | mobile.google.com
Stefan Fouant
Stay the patient course.
Of little worth is your ire.
The network is down.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkoXE5wACgkQLa9jIE3ZamPGmQCfabeEXcTJApsuhwtYQr4uBa1q
8R8An0mXudVCNt6we4y7bbbWEEsVJuTr
=nqJ6
-----END PGP SIGNATURE-----
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
