[j-nsp] SSH Filter
David Sinn
dsinn at dsinn.com
Fri May 22 17:05:32 EDT 2009
-----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
> <bmannella at teraswitch.com> 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" <sfouant at gmail.com>
>> To: "Brendan Mannella" <bmannella at teraswitch.com>, "juniper-nsp" <juniper-nsp at puck.nether.net
>> >
>> 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 <bmannella at teraswitch.com> 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 juniper-nsp at puck.nether.net
>>> 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 juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkoXE5wACgkQLa9jIE3ZamPGmQCfabeEXcTJApsuhwtYQr4uBa1q
8R8An0mXudVCNt6we4y7bbbWEEsVJuTr
=nqJ6
-----END PGP SIGNATURE-----
More information about the juniper-nsp
mailing list