[j-nsp] Protect router from ssh/telnet DDOS attacks, or unauthorised access.

[Huan Pham]

Thanks Darren very much.

Did you mean that you just modified the firewall filter to include the
"allowed" incoming interfaces, and you will still apply that firewall
filter to ALL units of the Loopback0 interface (via the group config), in
the inbound direction.

I think this brings an administrative burden (to keep the interface list
updated, as it might change) but that would fix my problem.

Thanks again.



On Sat, Jul 27, 2013 at 11:21 PM, Darren O'Connor <darrenoc at outlook.com>wrote:

>  What I do is limit the ability to SSH in via certain interfaces only.
> i.e. create an interface-set which allows SSH, as long as it comes in on
> certain interfaces (fxp0, one or two transit interfaces)
>
> Any subinterface pointing towards a customer is not added to the list, and
> hence any attempt to SSH in form that interface is denied.
>
> something like this:
>
> term SSH {
>             from {
>                 prefix-list {
>                     MANAGEMENT-RANGE;
>                 }
>                 protocol [ tcp  ];
>                 port [ ssh s ];
>                 interface-set MGMT-INTERFACES;
>             }
>
> interface-set MGMT-INTERFACES {
>     fxp0.0;
>     ae0.372;
> }
>
> etc...
>
> Darren
>
> > Date: Sat, 27 Jul 2013 16:51:31 +1000
> > From: drie.huanpham at gmail.com
> > To: juniper-nsp at puck.nether.net
> > Subject: [j-nsp] Protect router from ssh/telnet DDOS attacks, or
> unauthorised access.
>
> >
> > Hi there,
> >
> > What I want to do is very simple and I am sure everyone has his/her own
> > solution already.
> >
> > I want to limit SSH/Telnet to the router from restricted management
> ranges
> > in the global inet.0 table, and do not want customers in their separate
> > routing instances from being able to SSH/Telnet to the router at all.
> This
> > should be a straight forward configuration, however, I do not find an
> easy
> > way to achieve this. Instead, I find that certain proposed solutions I
> saw
> > may leave security holes that can be exploited. I appreciated your
> pointer
> > to the "best practice" solution to this simple requirement.
> >
> >
> > Solution in "JUNOS Cookbook" Recipe 2.14 proposes to apply a firewall
> > filter in Loopback0.0 which is fine for the enterprise enviroment, where
> we
> > do not have customer routing instances. However, when we have customers
> > instances (in the form of virtual-router, or vrf), things get
> complicated.
> >
> >
> > The following link documents the behavior of firewall filters that are
> > applied on the loopback interfaces in virtual routers (similar behaviour
> is
> > seen in VRF routing instance as well)
> >
> > http://kb.juniper.net/InfoCenter/index?page=content&id=KB21326
> >
> > If we apply the firewall filter to Lo0.0, and customer routing instance
> > does not have a loopback address, then by default, customers might also
> be
> > able to SSH/Telnet to the router if the source address is in the
> "allowable
> > range". The problem is that in customer VRF, they can have the same IP
> > address as the "allowed Mgmt source IP", and might be able to SSH/Telnet
> by
> > "faking the Mgmt IP addresses".
> >
> > So the solution I am thinking that can be done to solve the problem is
> > assign each customer a loopback interface, and use the group
> configuration
> > to explicitly deny all SSH/Telnet from the customer routing instances.
> >
> > Below is a sample configuration. Looking forward to your feedbacks.
> >
> > Regards,
> >
> > Huan
> >
> >
> > groups {
> > PROTECT_RE {
> > interfaces {
> > lo0 {
> > unit <*> {
> > family inet {
> > filter {
> > input Deny_SSH_Telnet;
> > }
> > }
> > }
> > }
> > }
> > }
> > }
> >
> >
> >
> >
> > firewall {
> > family inet {
> > filter Restrict_SSH_Telnet {
> > term Allow_Mgmt_Remote_Access {
> > from {
> > /* Allowed Mgmt Ranges */
> > source-address {
> > 1.1.1.100/32;
> > 2.2.2.200/32;
> > }
> > protocol tcp;
> > destination-port [ telnet ssh ];
> > }
> > then accept;
> > }
> > term Deny_All_Other_Remote_Access {
> > from {
> > destination-port [ telnet ssh ];
> > }
> > then {
> > count Rejected_Mgmt;
> > log;
> > syslog;
> > discard;
> > }
> > }
> > term Allow_All_Others {
> > then accept;
> > }
> > }
> > filter Deny_SSH_Telnet {
> > term Deny_All_SSH_Telnet {
> > from {
> > destination-port [ telnet ssh ];
> > }
> > then {
> > count Rejected_Mgmt;
> > log;
> > syslog;
> > discard;
> > }
> > }
> > term Allow_All_Others {
> > then accept;
> > }
> > }
> > }
> > }
> >
> >
> >
> > interfaces {
> >
> > lo0 {
> > apply-groups PROTECT_RE;
> > /* Management Loopback */
> > unit 0 {
> > apply-groups-except PROTECT_RE;
> > family inet {
> > filter {
> > input Restrict_SSH_Telnet;
> > }
> > address 1.1.1.1/32;
> > }
> > }
> > unit 1 {
> > description "TEST (Customer 1) Routing Instance";
> > }
> > unit 2 {
> > description "Customer 2 Routing Instance";
> > }
> > }
> > }
> >
> >
> >
> > routing-instances {
> > TEST {
> > instance-type virtual-router;
> > /* Interface to customer */
> > interface em2.0;
> > /* Interface to customer */
> > interface em3.0;
> > /* Required for RE PROTECTION */
> > interface lo0.1;
> > }
> > }
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>