Security

I had an incident today, where all the ssh connections got filled up by my rancid backup program. Basically, it left hour long sessions open and multiple sessions were called thus filling up the ssh session limit I had set.

Now, I know I can raise the concurent ssh session limit, and yes I know I can go fix the rancid script thats staying active for an hour. However, I wanted to know if there is also a way to have policies applied to individual or a range of remote connections similar to Cisco.

With Cisco, I can allocate a range or an individual vty lines with an ACL policy. I can then allocate a different indivudual or range of vty lines with a different policy. Is that possible with Junos? I turn up nothing in the Junos documents that gives me that ability. If this isn't possible with Junos, is there a similar alternative approach to keep a reserved ssh session?

Thanks

Yes, you can limit logins on a per-network basis, if you're willing to do a little slax scripting.

The general approach is to use a login-script.   (The login script must be assigned to the user's login class in the config, so make sure you cover all likely users,  e.g. "set system login class cli-users login-script my-login-limit.slax")

You can store the allowed networks and per-network limits in the config as apply-macros, sorta like you might on cicso gear..

e.g. 

   Example:
      ps@wf-crabpeople# show group GRP-PTY_ACCESS
      apply-macro MACRO-VIS_NETWORK-01 {
           network 192.168.1.0/24;
           limit 2;
       }
       apply-macro MACRO-VIS_NETWORK-02 {
           network 192.168.100.0/24;
           limit 0;
       }
       apply-macro MACRO-VIS_NETWORK-03 {
           network 172.28.32.0/24;
           limit 2;
       }

That way your login-script doesn't need to change when you add/change networks and limits.

The next step is to code up the "my-login-limit.slax"...   You must be runniing Junos 10.4 or greater, since the solution makes use of the $junos-context user data, which only became available then.

I'll desribe the approach, here.   If after reading this you still want to try this, let me know and I'll help you build it:

The script picks up 2 identifiers from $junos-context: $user and $tty.

We then use <get-system-users-information> rpc  to figure out the remote IP address ($host) for $user. [ $tty is used as the key for this operation so we can differentiate multiple logins for the same value of $user.]

Don't do anything else if $host isn't an IP address. (If it's not an IP address, then that means that $user is either logging in from a local console port or another RE in the chassis -- and we're not trying to limit those logins.)

For all other values of $host (IP addresses),  verify if the value of $host lies inside an "allowed" network.  Allowed networks and their respective max-logins values are stored in the router configuration as a series of apply-macros in the group "GRP-PTY_ACCESS". Each apply-macro contains a list of entries, each of which defines a network range (specified in CIDR notation) and a limit (integer indicating the maximum number of logins from this netblock).

- If the value for $host is not within any allowed netblock, then $user islogged out and we end.

- If the value of $host iswithin one of the allowed netblocks, the script then checks to see if this login causes us to exceed the maximum allowed logins for that netblock.

- If the value of $limit is "-1", this means "unlimited", so it doesn't matter how many previous logins we have from that netblock, the user login process will complete.

Note that if $limit is configured to 0 (zero), that means that NO logins are currently allowed for that netblock. While this has the same net effect as deleting the apply-macro for that netblock completely, it's more appropriate when the zero-limit is a temporary measure, since it doesn't require re-creation of the entire apply-macro. Rather, all that needs to be done is change the limit back to a non-zero number.

If we exceed max-logins, then the user is logged out and we end.

If we are less than the max-login value for that netblock, then the script ends and the user login process is complete.

Fin.

Thanks. I have coded up some production slax scripts, in the past. I will follow your design outline, and see if I can get something going, assuming my colleagues are interested in pursuing this. Of course, It will take me some time to digest this and get something written.  I do like the idea of referencing apply-macros in slax. I'll have to revisit a commit script I wrote that protects configuration areas from changes.

Thank you