Management
Management

Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-24-2019 12:32 PM

Hi all! I'd really appreciate some insight. I'm trying to do something I can do very easily in Cisco IOS but apparently cannot do easily in Junos on this switch.

 

I have an EX2300-C (the compact switch, not the full size 1U model) and need to use in-band management with a public IP instead of OOB management. The trouble I'm having is figuring out how to restrict administrative access to SSH on the control plane. The switch is being used as a L3 switch.

 

Here's how the "outside" uplink port is configured:

sw0> show configuration interfaces ge-0/1/1 
description "Internet uplink to ISP";
enable;
unit 0 {
    family inet {
        filter {
            input uplink_ingress_filter;
        }
        address X.X.X.X/31;
    }
  }

The "uplink_ingress_filter" is my attempt at limiting inbound SSH to the switch but allowing traffic through the switch to reach a subnet behind it on another IP interface:

sw0> show configuration firewall family inet filter uplink_ingress_filter 
term term1 {
    from {
        source-prefix-list {
            admin_access;
        }
        destination-prefix-list {
            ptplink_ipv4;
        }
        protocol tcp;
        ##
        ## Warning: value port ignored: unsupported platform (ex2300-c-12t)
        ##
        port ssh;
    }
    then accept;
}
term term2 {
    from {
        source-address {
            0.0.0.0/0;
        }
        destination-prefix-list {
            ptplink_ipv4;
        }
        protocol tcp;
        destination-port ssh;
    }
    then {
        reject;
    }
}

Notice in term1 the big comment telling me that I can't accept traffic based on specific TCP port 22 on this platform, but term2 is just fine with rejecting using the same. Either way, I'm seeing attempted logins from subnets not defined in that "admin-access" prefix-list, so none of this appears to be working. Is there a way to say "accept SSH connections from anything NOT in prefix-list uplink_ipv4"?

 

Any ideas?

 

 

10 REPLIES 10
Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-24-2019 03:58 PM

Term 2 is using “destination-port” vs “port” on term 1. 

Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-24-2019 04:29 PM

Good catch, but I'm still seeing logins from undesirable sources. The logic seems sound to me, but I'm clearly missing something else.

 

I fixed the "port" to be "destination-port" and now have this:

 

sw0> show configuration firewall family inet filter uplink_ingress_filter    
term term1 {
    from {
        source-prefix-list {
            admin_access;
        }
        destination-prefix-list {
            ptplink_ipv4;
        }
        protocol tcp;
        destination-port 22;
    }
    then accept;
}
term term2 {
    from {
        source-address {
            0.0.0.0/0;
        }
        destination-prefix-list {
            ptplink_ipv4;
        }
        protocol tcp;
        destination-port ssh;
    }
    then {
        reject;
    }
}

Is there anything else I'm missing? Or is this the wrong way to do this?

Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-24-2019 05:12 PM

Hi this is what the filter does,

 

term 1 is evaluating and accepting any ssh connection sourced on any ip of [admin_access] destined to any address in [ptplink_ipv4]

sw0> show configuration firewall family inet filter uplink_ingress_filter    
term term1 {
    from {
        source-prefix-list {
            admin_access;
        }
        destination-prefix-list {
            ptplink_ipv4;
        }
        protocol tcp;
        destination-port 22;
    }
    then accept;
}

term 2 is rejecting anything else that is going to ssh por and that is coming from X ip address to [ptplink_ipv4] addresses

term term2 {
    from {
        source-address {
            0.0.0.0/0;
        }
        destination-prefix-list {
            ptplink_ipv4;
        }
        protocol tcp;
        destination-port ssh;
    }
    then {
        reject;
    }

if there are no more terms everything else will be rejected to avoid that do:

 

term 3 then accept 

 

this will accept all the other traffic that was not evaluated in any way by the filter.

 

do these IPs live in the same 2300-c? or is it transit traffic for the box?

 

if the IP "lives" on the 2300 try applying the filter in the irb or the lo0 instead, 

I help you, you help me... please share a Kudos or accepted solution whenever you feel I have helped with your problem! Smiley Happy
Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-28-2019 02:14 PM

I'm still seeing SSH connection attempts from wild public source IPs that are not members of the "admin-access" prefix list, so this filter seems to be effectively doing nothing useful. By the way, there is a "term 3 then accept" I left out that allows all other traffic through, so at least there's that. The box is just getting brute forced all day long.

 

IP being connected to "lives" on this interface:

 

sw0> show configuration interfaces ge-0/1/1 
description "Internet uplink to PE";
enable;
unit 0 {
    family inet {
        filter {
            input uplink_ingress_filter;
        }
        address x.x.x.x/31;
    }
}

x.x.x.x is a public IP, so this is a definite problem. I've applied "rate-limit 4" to the SSH service to at least slow down the attempts, but it's constant and from new IPs every so often.

 

I'm not using any IPs on the loopback interface. Would applying the filter to lo0 make any difference?

Highlighted
Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-28-2019 02:24 PM
Hi there,

Ok but where do you see the attempts? If you do:

>monitor traffic interface lo0 no-resolve size 1500 matching "port 22"

Do you see the attempts? Or how/where are you seeing them?

BTW if you don't have lo0 just assign it family inet and X ip address so you can monitor it.

What we want to do is not burden the Routing Engine if you see the attempts on the interface but not on the RE it is not burdening the routing engine.

Let me know!


Best Regards,


Carlos Calvo A JNCIE-ENT # 621
carloscalvo@juniper.net
Support Language: English, Spanish
My Office Hours: Monday-Friday 10:00AM-6:00PM USA Pacific Time
For 24x7 support, call +1.888.314.JTAC or contact support<> for the full list of international numbers.
Want instant access to cases, contracts, installed base, EoL information? Visit My Juniper<>
I help you, you help me... please share a Kudos or accepted solution whenever you feel I have helped with your problem! Smiley Happy
Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-28-2019 03:25 PM

This is quite a learning experience. By the way, I really appreciate you bearing with me on this, it's my first real foray into the Juniper world :-)

 

I'm seeing this kind of thing in syslog which I'm currently monitoring to terminal, so if I sit on SSH for a while, I'll see a bunch of this happen after a while:

 

Message from syslogd@sw0 at May 28 13:59:51  ...
sw0 sshd[17019]: Failed password for admin from 37.21.131.128 port 44800 ssh2

Message from syslogd@sw0 at May 28 13:59:51  ...
sw0 sshd: SSHD_LOGIN_FAILED: Login failed for user 'admin' from host '37.21.131.128'

Message from syslogd@sw0 at May 28 20:59:52  ...
sw0 sshd[17020]: Connection closed by 37.21.131.128 port 44800

Message from syslogd@sw0 at May 28 13:59:52  ...
sw0 sshd[17019]: Connection closed by 37.21.131.128 port 44800 [preauth]

Message from syslogd@sw0 at May 28 13:59:54  ...
sw0 sshd: SSHD_LOGIN_FAILED: Login failed for user 'scaner' from host '206.189.188.223'

Message from syslogd@sw0 at May 28 13:59:54  ...
sw0 sshd[17051]: Failed password for scaner from 206.189.188.223 port 48600 ssh2

Message from syslogd@sw0 at May 28 13:59:54  ...
sw0 sshd[17051]: Received disconnect from 206.189.188.223 port 48600:11: Normal Shutdown, Thank you for playing [preauth]

Message from syslogd@sw0 at May 28 20:59:54  ...
sw0 sshd[17052]: Received disconnect from 206.189.188.223 port 48600:11: Normal Shutdown, Thank you for playing

Message from syslogd@sw0 at May 28 13:59:54  ...
sw0 sshd[17051]: Disconnected from 206.189.188.223 port 48600 [preauth]

Based on the text response in those logs, it looks like it's actually sending that back to the source IP rather than just silently dropping the packets.

 

I want to clarify what you mean about monitoring interface lo0 and the impact to the RE (which is a really low duty ARM in this platform, IIRC). Are you saying I could give lo0 any random "dummy" inet address like 10.10.10.10/32 and that would be good enough to allow monitoring of it? Are you saying that monitoring lo0 is less impactful than monitoring a forwarding interface? I'd love to understand these details a bit more.

 

I'll try monitoring lo0 to see what I get.

Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

[ Edited ]
‎05-28-2019 06:57 PM

For what it's worth I duplicated your config on an EX2300-C and it works correctly for me.

 

interfaces {
    ge-0/0/11 {
        unit 0 {
            family inet {
                filter {
                    input uplink_ingress_filter;
                }
                address 192.168.0.1/24;
            }
        }
    }
}
policy-options {
    prefix-list admin_access {
        1.1.1.1/32;
    }
    prefix-list ptplink_ipv4 {
        192.168.0.1/32;
    }
}
firewall {
    family inet {
        filter uplink_ingress_filter {
            term term1 {
                from {
                    source-prefix-list {
                        admin_access;
                    }
                    destination-prefix-list {
                        ptplink_ipv4;
                    }
                    protocol tcp;
                    destination-port 22;
                }
                then accept;
            }
            term term2 {
                from {
                    source-address {
                        0.0.0.0/0;
                    }
                    destination-prefix-list {
                        ptplink_ipv4;
                    }
                    protocol tcp;
                    destination-port ssh;
                }
                then {
                    reject;
                }
            }
            term 3 {
                then accept;
            }
        }
    }
}

With dummy address 1.1.1.1 only in the admin prefix-list I'm unable to ssh from 192.168.0.2

MacBook-Air:~ ps$ ssh -l root 192.168.0.1
ssh: connect to host 192.168.0.1 port 22: Connection refused

Then add 192.168.0.2:

prefix-list admin_access {
    1.1.1.1/32;
    192.168.0.2/32;
}

And I'm in:

MacBook-Air:~ ps$ ssh -l root 192.168.0.1
Password:

This is on 19.1R1. Any chance

a. you're running an early buggy code version? 

b. the ssh traffic is coming in over a different interface?

 

As unintuitive as it sounds, applying the filter to an lo0 interface, even if it does not have an address configured, will also block ssh traffic to the RE. This avoids having to place a filter on all external interfaces, or even specify destination addresses (ptplink_ipv4)

[edit interfaces]
+   lo0 {
+       unit 0 {
+           family inet {
+               filter {
+                   input uplink_ingress_filter;
+               }
+           }
+       }
+   }

 

Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-29-2019 02:49 PM

No problem,

 

I am glad  I can be of help in your learning process Smiley Happy 

 

since the messages are coming from the syslog I am thinking they are trying to attack you yes but truly just filtering on the loopback should do the trick. As smicker suggested this is probably coming in from another interface.

 

let us know how it goes.

 

I help you, you help me... please share a Kudos or accepted solution whenever you feel I have helped with your problem! Smiley Happy
Management
Solution
Accepted by topic author vjbreen
‎06-03-2019 09:40 AM

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎05-30-2019 02:27 PM

One other thing that will give you a better idea is rfc 6192

 

https://tools.ietf.org/html/rfc6192

 

it even has a Juniper example.

 

I help you, you help me... please share a Kudos or accepted solution whenever you feel I have helped with your problem! Smiley Happy
Management

Re: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

‎06-03-2019 09:40 AM

That RFC is absolutely the exact thing I was looking for. It's certainly authoritative, and I love that it was principally written by a Juniper engineer!

 

Thanks so much!