Security Management

Expand all | Collapse all

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

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

    Posted 05-24-2019 12:32

    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?

     

     


    #ssh


  • 2.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

     
    Posted 05-24-2019 15:59

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



  • 3.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

    Posted 05-24-2019 16:30

    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?



  • 4.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

    Posted 05-24-2019 17:12

    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, 



  • 5.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

    Posted 05-28-2019 14:15

    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?



  • 6.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

    Posted 05-28-2019 14:25
    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<carloscalvo>
    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<></carloscalvo>


  • 7.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

    Posted 05-28-2019 15:26

    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.



  • 8.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

     
    Posted 05-28-2019 18:58

    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;
    +               }
    +           }
    +       }
    +   }
    

     



  • 9.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

    Posted 05-29-2019 14:49

    No problem,

     

    I am glad  I can be of help in your learning process 🙂 

     

    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.

     



  • 10.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"
    Best Answer

    Posted 05-30-2019 14:28

    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.

     



  • 11.  RE: Restricting access to in-band SSH on EX2300-C based on a prefix-list as a "whitelist"

    Posted 06-03-2019 09:40

    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!