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

[Darren O'Connor]

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