[j-nsp] Protect router from ssh/telnet DDOS attacks, or unauthorised access.
Huan Pham
drie.huanpham at gmail.com
Mon Jul 29 03:56:17 EDT 2013
Hi Darren,
It is a burden to maintain the interface list updated per router, as we have a lot of routers in our network (100's), and the mgmt & transit interface names are not the sames. This is different from the MGMT IP ranges because this ranges do not usually change and we can keep it standard on all routers.
Btw, we need to apply the FW to all loopback0 units, not just Lo0.0, or customer may not be subject of your FW filter.
Huan
On 29/07/2013, at 4:18 PM, Darren O'Connor <darrenoc at outlook.com> wrote:
> Hi.
>
> Yes add the allowed interfaces to the current filter applied to lo0.0
>
> The interface list itself should not be that much of a burden. How often do you need to allow access from more interfaces? In the interface list you simply configure which interfaces you do want access from. Anything not on the list, including new interfaces/subinterfaces, is not allowed
>
> Thanks
>
> Darren
>
> http://www.mellowd.co.uk/ccie
>
> On 29 Jul 2013, at 03:45, "Huan Pham" <drie.huanpham at gmail.com> wrote:
>
>> 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
>>
More information about the juniper-nsp
mailing list