Security event log

The Joint Interoperability Test Command ( JITC) is a United States military organization that tests technology that pertains to multiple branches of the armed services and government. The JITC requires that access to security logs be provided through security user authentication.


[NOTE: ]

NOTE: The HP 3800 Switch and HP 2920 Switch are currently UC APL certified.


Security user log access

Security user logs are accessible when both the authentication and authorization are local. A default group called the default-security-group is available in manager mode and has the privileges to execute the commands copy security-log, show security-logging and clear security-logging. When a security user is attached to the group, they will only be able to execute the three commands. Any other user will not be able to execute the commands, no matter whether they are an operator or manager.

Creating a security user

Syntax

aaa authentication local-user user1 group default-security-group password plaintext

Security user commands

Syntax

copy security-log sftp | tfp | usb | xmodem user IP-Address <FILENAME-STR>

Syntax

show security-logging

Syntax

clear security-logging

Authentication and Authorization through RADIUS

For RADIUS authentication and authorization, the security user will be able to access to security log by configuring the file located on RADIUS server.

Accessing the security log

/etc/raddb/users
steve Cleartext-Password := "testing"
Service-Type = Administrative-User,
HP-Command-Exception=0,
HP-Command-String="copy security log;show security-logging;clear security-logging”

Authentication and Authorization through TACACS+

For TACACS+ authentication and authorization, the user can access to security log by configuring the file located on TACACS+ server.

Security user access for TACACS authentication and authorization

/etc/tacacs/tac_plus.cfg
group = admin {
# default service = permit
service = exec {
priv-lvl = 15
}
cmd = copy security-log {

permit .*
}
cmd = copy show security-logging {
permit .*
}
cmd = clear security-logging {
permit .*

Restrictions

In the case of local authentication and authorization, the default-security-group group onlyapplies to manager logins for CLI actions; menu interface and Web UI capabilities.

  • There is no WebUI and Menu support for this feature.

  • The same mechanism should be used for authentication and authorization when using this feature. Cross combination is not supported.

    For example: If authentication is local, then the authorization should also be set to local. Similarly, if authentication is RADIUS, authorization should also be set to RADIUS. TACACS authentication works in the same fashion.

  • Security logging is supported via Syslog.

Event log wrap

To add a new log message when the event buffer wraps, a new RMON log is generated when the buffer wrapping is identified.

Configuring concurrent sessions

The following commands configure the max concurrent sessions allowable.

For non-stackable switches

Syntax

console max-sessions 1-6

The default value is 6. The [no] for the command restores the default value.

For non-stackable devices the allocations is as :

1 local console and 5 SSH/Telnet sessions.
Minimum value of 1 is set since 1 local console is always available.

For stackable switches

Syntax

console max-sessions 2-7

Default value is 7

By default the local console session is always enabled. Whenever a telnet/SSH session connection is made the maximum number of allowed session is compared with the currently allocated once. The session allocation is made only if the current allocated number of session is within the max configured session value. Also one remote console session will always be made available in stack devices and in Bolt.

Allocations
1 local console, 1 remote console and 5 SSH/Telnet sessions.
Minimum value of 2 is allocated since 1 local console and 1 remote console is always available.

Configuring concurrent sessions per user

Configures the max concurrent sessions allowable per user. The [no] command restores the default value.

For non-stackable switches

Syntax

console max-sessions 1-6

The default value is 6.

Allocations
1 local console and 5 SSH/Telnet sessions.
Minimum value of 1 is set since 1 local console is always available.

For stackable switches

Syntax

console max-sessions 2-7

By default the local console session is always enabled. Whenever a telnet/SSH session connection is made the maximum number of allowed session is compared with the currently allocated once. The session allocation is made only if the current allocated number of session is within the max configured session value. Also one remote console session will always be made available in stack devices and in the P 5400R series switches.

Allocations
1 local console, 1 remote console and 5 SSH/Telnet sessions.
Minimum value of 2 is allocated since 1 local console and 1 remote console is always available.

Configuring concurrent sessions per user

Configures the max concurrent sessions allowable per user in HP switches. The [no] command restores the default value.

Syntax

console max-sessions 1-7


[NOTE: ]

NOTE: The default value in non-stackable and HP 5400R series switches is 6. The default value for stackable devices is 6.


Maximum session for a manager/operator

Configuring a value of 4 means that the Manager can have a maximum of 4 concurrent sessions and the Operator can also have a maximum of 4 concurrent sessions.

The allocations will be based on the current available free session (since the system as a whole can have only 6 to 7 concurrent sessions by default.

A session is allocated to a Manager or Operator only if the current allocation to the user is within the configured value. The session allocation thus happens based on the user sessions as well the max sessions available in the system.

Failed login attempts delay

Authentication happens by sending authentication request to the Authentication sub system. The Authentication sub system then authenticates and sends back the authentication result. If an authentication failure is identified, a delay is introduced so that the next authentication request is not serviced immediately. This is applicable for console, telnet and ssh sessions.