Indeed when I do check out the cli parameters on the olive after login I see..
user@olive-core> show cli
CLI complete-on-space set to on
CLI idle-timeout disabled
CLI restart-on-upgrade set to on
CLI screen-length set to 51
CLI screen-width set to 136
CLI terminal is 'vt100'
CLI is operating in enhanced mode
CLI timestamp disabled
CLI working directory is '/var/home/user'
And indeed I can confirm that my ssh session to olive-core never times out.
That's fine for the lab but in the real world corporate environment not so good. So what do we do to fix that? Define a login class.
Note first the default class I have before the login class is defined.
login {
user user {
full-name The_User;
uid 2000;
class super-user;
authentication {
encrypted-password "$1$1C1ZcaIe$QTwS8KBmINbEsu55QZ8be."; ## SECRET-DATA
}
}
}
So the new login class will want to be defined with permissions equal to your existing class to maintain the same level of access.
Here is the config with the login class defined.
login {
class ADMINS {
idle-timeout 5;
permissions all;
}
user user {
full-name The_User;
uid 2000;
class ADMINS;
authentication {
encrypted-password "$1$1C1ZcaIe$QTwS8KBmINbEsu55QZ8be."; ## SECRET-DATA
}
}
There is a bunch more controls you can apply to the login class..
user@olive-core# set system login class ADMINS ?
Possible completions:
access-end End time for remote access (hh:mm)
access-start Start time for remote access (hh:mm)
allow-commands Regular expression for commands to allow explicitly
allow-configuration Regular expression for configure to allow explicitly
+ allowed-days Day(s) of week when access is allowed.
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
deny-commands Regular expression for commands to deny explicitly
deny-configuration Regular expression for configure to deny explicitly
idle-timeout Maximum idle time before logout (minutes)
logical-system Logical system associated with login
login-alarms Display system alarms when logging in
login-script Execute this login-script when logging in
login-tip Display tip when logging in
+ permissions Set of permitted operation categories
Note also there is a great deal of granularity under the permissions section itself.
I have gone for permissions "all" to be equivalent to the default class super-user. Note also the timeout for 5 minutes.
So with all that set I can confirm the login session does drop off after 5 minutes and require you to re-authenticate.
As you can see the idle-timeout is now 5 minutes and it does work to log you out.
user@olive-core> show cli
CLI complete-on-space set to on
CLI idle-timeout set to 5 minutes
CLI restart-on-upgrade set to on
CLI screen-length set to 51
CLI screen-width set to 136
CLI terminal is 'vt100'
CLI is operating in enhanced mode
CLI timestamp disabled
CLI working directory is '/var/home/user'
user@olive-core> Warning: session will be closed in 1 minute if there is no activity
Warning: session will be closed in 10 seconds if there is no activity
Idle timeout exceeded: closing session
All of the above is for a permanent change. You can change the idle-timeout for the session your in via the cli directly..
user@olive-core> set cli idle-timeout ?
Possible completions:
<timeout> Maximum idle time (0..100000 minutes)
So that takes care of changing the default idle-timeout behaviour on the olive.
As for the SRX...
On the surface, Juniper's doco states that by default the idle-timout....
The device never automatically disconnects the management users; this is the default behavior of the SRX and J-series. This is because the idle timeout is disabled by default.
http://kb.juniper.net/InfoCenter/index?page=content&id=KB20967&actp=RSS
And indeed if I do the show cli on the SRX it does show..
blogger@RIGHTY> show cli
CLI complete-on-space set to on
CLI idle-timeout disabled
CLI restart-on-upgrade set to on
CLI screen-length set to 51
CLI screen-width set to 136
CLI terminal is 'vt100'
CLI is operating in enhanced mode
CLI timestamp disabled
CLI working directory is '/cf/var/home/blogger'
However in reality, I found that I was being logged out after 30 minutes. As this is a lab environment I don't really want that. Investigating the issue I found this entry in the forums..
http://forums.juniper.net/t5/SRX-Services-Gateway/what-is-the-proper-way-to-setup-cli-timeout-on-SRX/td-p/37175
And so if I issue the same command I see..
blogger@RIGHTY> show security flow session
Session ID: 631, Policy name: self-traffic-policy/1, Timeout: 50, Valid
In: 172.19.213.100/1 --> 224.0.0.5/1;ospf, If: vlan.0, Pkts: 3978, Bytes: 272168
Out: 224.0.0.5/1 --> 172.19.213.100/1;ospfPkts: 0, Bytes: 0
Session ID: 1118, Policy name: self-traffic-policy/1, Timeout: 1800, Valid
In: 192.168.56.50/1095 --> 172.19.213.5/22;tcp, If: vlan.0, Pkts: 202, Bytes: 15179
Out: 172.19.213.5/22 --> 192.168.56.50/1095;tcp, If: .local..0, Pkts: 158, Bytes: 21605
Session ID: 1356, Policy name: self-traffic-policy/1, Timeout: 44, Valid
In: 172.19.213.5/123 --> 192.168.10.1/123;udp, If: .local..0, Pkts: 1, Bytes: 76
Out: 192.168.10.1/123 --> 172.19.213.5/123;udp, If: vlan.0, Pkts: 1, Bytes: 76
Total sessions: 3
3 Sessions, One for OSPF, one for my login and one for NTP. Note the timeout on the login session 1800 - 30 minutes. So regardless of having the idle-timout disabled you are disconnected after 30 minutes and I can confirm that is the case. In this case because we are using the default junos-ssh service. The policy "self-traffic-policy" is not alterable.
Confirm default idle-timouts for system defined junos applications..
blogger@RIGHTY> request pfe execute target fwdd command "show usp app-def tcp"
SENT: Ukern command: show usp app-def tcp
GOT:
GOT: tcp port=0, appl_name=junos-tcp-any, service type=0, alg id=0, timeout=1800
GOT: tcp port=21, appl_name=junos-ftp, service type=1, alg id=1, timeout=1800
GOT: tcp port=22, appl_name=junos-ssh, service type=22, alg id=0, timeout=1800
etc..
The solution..
Check this from the 11.4 release notes..
Security policies for self-traffic—This feature is supported on all branch SRX Series and J Series devices. Users can now configure security policies for the self-traffic (the host inbound traffic or the host outbound traffic) of the device. The user can further apply relevant services to the new self-traffic policy.The security policies for the self-traffic are configured under the new default security zone called junos-host zone.
So after a quick upgrade to 11.4R1.6, let see the new zone..
These are the default zones for an out-of-the-box SRX100. Note the new zone "junos-host"
Hostname: RIGHTY
Model: srx100h
JUNOS Software Release [11.4R1.6]
Model: srx100h
JUNOS Software Release [11.4R1.6]
blogger@RIGHTY> show security zones
Security zone: trust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
vlan.0
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 1
Interfaces:
vlan.0
Security zone: untrust
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Screen: untrust-screen
Interfaces bound: 1
Interfaces:
vlan.1
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Screen: untrust-screen
Interfaces bound: 1
Interfaces:
vlan.1
Security zone: junos-host
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 0
Interfaces:
Juniper says this about this new zone..
Send reset for non-SYN session TCP packets: Off
Policy configurable: Yes
Interfaces bound: 0
Interfaces:
Juniper says this about this new zone..
The security policies for the self traffic are configured under the new default security zone called the junos-host zone. The junos-host zone will be part of the junos-defaults configuration, so users can delete it. The existing zone configurations such as interfaces, screen, tcp-rst, and host-inbound-traffic options are not meaningful to the junos-host zone. Therefore there is no dedicated configuration for the junos-host zone.
http://jnpr.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/security/index.html?topic-61602.html
How to use it..
How to use it..
First define a service with the timeout you want. I will use 60 seconds on ssh just for the test.
blogger@RIGHTY> show configuration applications
application SSH-60s {
protocol tcp;
destination-port ssh;
inactivity-timeout 60;
}
Then define the address you want to login to and attach to the zone junos-host. 172.19.213.5 is the IP of vlan.0 which is assigned to the trust zone.
blogger@RIGHTY> show configuration security address-book
JUNOS-HOST {
address 172.19.213.5/32 172.19.213.5/32;
attach {
zone junos-host;
}
}
Now create the policy. As I am accessing SRX via an interface in the trust zone the policy is as follows:
from-zone trust to-zone junos-host {
policy TRUST-JUNOSHOST {
match {
source-address any;
destination-address 172.19.213.5/32;
application SSH-60s;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
}
Note the use of the custom ssh app.
To test this I will monitor the log. I previously created this log to catch security policy flows:
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file policies-hits {
any any;
match RT_FLOW;
blogger@RIGHTY> monitor start policies-hits
blogger@RIGHTY>
*** policies-hits ***
Feb 6 19:19:03 RIGHTY RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.56.50/1060->172.19.213.5/22 junos-ssh 192.168.56.50/1060->172.19.213.5/22 None None 6 TRUST-JUNOSHOST trust junos-host 1626 N/A(N/A) vlan.0
Feb 6 19:20:04 RIGHTY RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed unset: 192.168.56.50/1060->172.19.213.5/22 junos-ssh 192.168.56.50/1060->172.19.213.5/22 None None 6 TRUST-JUNOSHOST trust junos-host 1626 16(2071) 16(3105) 62 UNKNOWN UNKNOWN N/A(N/A) vlan.0
Look at that! Logged out after 60 seconds (Well ok 61 but who's counting) I note the application mentioned is junos-ssh and I can only assume that must be some bug as the flow is clearly using my custom ssh app by virtue of the 60 second drop off. Also it is using the expected policy TRUST-JUNOSHOST.
The access method in question, ssh here, must still be included under zone/host-inbound-traffic/system-services even with the trust to junos-host policy in place. If you were to remove ssh from zone/host-inbound-traffic/system-services, access would not work.
Functionally there doesn't appear to be an implicit deny at the end of the trust to junos-host policy set as, for example, with only the one policy in place permitting ssh (SSH-60s) telnet is still permitted as its defined in my config under zone/host-inbound-traffic/system-services by virtue of ..
zones {
security-zone trust {
host-inbound-traffic {
system-services {
all;
However that zone defined access can be overridden with a deny policy in the trust to junos-host policy set like so.
from-zone trust to-zone junos-host {
policy TRUST-JUNOSHOST {
match {
source-address any;
destination-address 172.19.213.5/32;
application SSH-60s;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
policy TRUST-JUNOSHOST-DENY {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
With this config we are only permitting SSH access to 172.19.213.5. Telnet (And everything else!) is blocked even though we still have system-services "all" as above.
match {
source-address any;
destination-address 172.19.213.5/32;
application SSH-60s;
}
then {
permit;
log {
session-init;
session-close;
}
}
}
policy TRUST-JUNOSHOST-DENY {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
With this config we are only permitting SSH access to 172.19.213.5. Telnet (And everything else!) is blocked even though we still have system-services "all" as above.
Verified below telnet access blocked..
blogger@RIGHTY>
*** policies-hits ***
Feb 6 19:51:21 RIGHTY RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.56.50/1068->172.19.213.5/23 junos-telnet 6(0) TRUST-JUNOSHOST-DENY trust junos-host UNKNOWN UNKNOWN N/A(N/A) vlan.0
Feb 6 19:51:21 RIGHTY RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.56.50/1068->172.19.213.5/23 junos-telnet 6(0) TRUST-JUNOSHOST-DENY trust junos-host UNKNOWN UNKNOWN N/A(N/A) vlan.0
So ultimately you can see how you can have granular control to (or from) your SRX through security policies using the junos-host zone.
You could achieve a similar outcome already through a (stateless) firewall filter but why wouldn't you choose to do it this new way with security policies if you could? For me using the junos-host zone makes the overall configuration more consistent with the use of the rest of your security policies on yor SRX. Anyway at least now you have more choice (FW filter, junos-host or even both) and that can only be a good thing.
#########
#UPDATE#
#########
I should say that all of the above applies to my SRX100 in non clustered mode. I mention this because I manage several SRX650 clusters at my work and they behave the same way as the olive by default. I.e they will not log you out after a time and they also show the cli-idle timeout to be disabled.
I think the difference is that the clustered SRX650s are manged via fxp0 which is an out-of-band management interface (Doesn't use the forwarding plane). So when accessing that interface there is no triggering of the self-traffic-policy and the associated junos-ssh application with its 30 minute timeout.
Eventually I will cluster my SRX100s and test the above theory. Regardless, even in a cluster, you still might want to consider the use of the junos-host zone as you may not be able to afford the dedication of one of the revenue ports to be out-of-band management.
Model: srx100h
JUNOS Software Release [11.4R1.6]
No comments:
New comments are not allowed.