Syslog Server Configuration on a Linux System
A secure Junos OS environment requires auditing of events and storing them in a local audit file. The recorded events are simultaneously sent to an external syslog server. A syslog server receives the syslog messages streamed from the device. The syslog server must have an SSH client with NETCONF support configured to receive the streamed syslog messages.
The NDcPP logs capture the events, few of them are listed below:
Committed changes
Login and logout of users
Failure to establish an SSH session
Establishment or termination of an SSH session
Changes to the system time
Configuring Event Logging to a Local File
Configure audit information to be stored in a local file on the device along with the level of detail using the "syslog" statement. The following must be used to ensure all events detailed in the NDcPP are logged and are stored in a local file named Audit_file in the following example:
[edit system] syslog { file Audit_file { any any; } }
Configuring Event Logging to a Remote Server
Configure the export of audit information to a secure, remote server by setting up an event trace monitor that sends event log messages by using NETCONF over SSH to the remote system event logging server. The following procedures show the configuration needed to send system log messages from TOE to a secure external server by using NETCONF over SSH.
Configuring Event Logging to a Remote Server when Initiating the Connection from the Remote Server
The following procedure describes the steps to configure event logging to a remote server when the SSH connection to the TOE is initiated from the remote system log server.
- Generate an RSA public key on the remote syslog server.$ ssh-keygen -b 2048 -t rsa -C 'syslog-monitor key pair' -f ~/.ssh/syslog-monitor
You will be prompted to enter the desired passphrase. The storage location for the syslog-monitor key pair is displayed.
- On the TOE, create a class named monitor that
has permission to trace events.[edit]user@host# set system login class monitor permissions trace
- Create a user named syslog-mon with the class
monitor, and with authentication that uses the syslog-monitor key pair from the key pair file located on the remote syslog server.[edit]user@host# set system login user syslog-mon class monitor authentication ssh-rsa “ssh-rsa xxxxx syslog-monitor key pair”
- Set up NETCONF with SSH.[edit]user@host# set system services netconf ssh
- Configure syslog to log all the messages at /var/log/Audit_file.[edit]user@host# set system syslog file Audit_file any anyuser@host# commit
- On the remote system log server, start up the SSH agent.
The start up is required to simplify the handling of the syslog-monitor
key.$ eval `ssh-agent`
- On the remote syslog server, add the syslog-monitor key pair to the SSH agent.$ ssh-add ~/.ssh/syslog-monitor
You will be prompted to enter the desired passphrase. Enter the same passphrase used in Step 1.
- After logging in to the external_syslog_server session, establish a tunnel to the device and start NETCONF.$ ssh syslog-mon@NDcPP_TOE -s netconf > test.out
- After NETCONF is established, configure a system log
events message stream. This RPC will cause the NETCONF service to
start transmitting messages over the SSH connection that is established.
<rpc><get-syslog-events><stream>messages</stream></get-syslog-events></rpc>
- The examples for syslog messages are listed below. Monitor the event log generated for admin actions on TOE as received on the syslog server. Examine the traffic that passes between the audit server and the TOE, observing that these data are not viewed during this transfer, and that they are successfully received by the audit server. Match the logs between local event and the remote event logged in a syslog server and record the particular software (such as name, version, and so on) used on the audit server during testing.
SSH through remote management interface allowed in the evaluated configuration. If the existing ssh connection is broken unintentionally, for example reboot, re-initiate the connection after the device is up. There is no mechanism to retain an existing or established connection, which is broken. This topic describes how to configure SSH for remote management of TOE. The following algorithms that needs to be configured to validate SSH for NDcPP.
The following output shows test log results for syslog server.
host@ssh-keygen -b 2048 -t rsa -C 'syslog-monitor key pair' -f ~/.ssh/syslog-monitor
Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/host/.ssh/syslog-monitor. Your public key has been saved in /home/host/.ssh/syslog-monitor.pub. The key fingerprint is: ef:75:d7:68:c5:ad:8d:6f:5e:7a:7e:9b:3d:f1:4d:3f syslog-monitor key pair The key's randomart image is: +--[ RSA 2048]----+ | | | | | | | ..| | S +| | . Bo| | . . *.X| | . . o E@| | . .BX| +-----------------+ [host@nms5-vm-linux2 ~]$ cat /home/host/.ssh/syslog-monitor.pub ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCrUREJUBpjwAoIgRrGy9zgt+
D2pikk3Q/Wdf8I5vr+njeqJhCx2bUAkrRbYXNILQQAZbg7kLfi/8TqqL
eon4HOP2e6oCSorKdx/GrOTzLONL4fh0EyuSAk8bs5JuwWNBUokV025
gzpGFsBusGnlj6wqqJ/sjFsMmfxyCkbY+pUWb8m1/A9YjOFT+6esw+9S
tF6Gbg+VpbYYk/Oday4z+z7tQHRFSrxj2G92aoliVDBLJparEMBc8w
LdSUDxmgBTM2oadOmm+kreBUQjrmr6775RJn9H9YwIxKOxGm4SFnX/Vl4
R+lZ9RqmKH2wodIEM34K0wXEHzAzNZ01oLmaAVqT
syslog-monitor key pair [host@nms5-vm-linux2 ~]$ eval `ssh-agent` Agent pid 1453 [host@nms5-vm-linux2 ~]$ ssh-add ~/.ssh/syslog-monitor Enter passphrase for /home/host/.ssh/syslog-monitor: Identity added: /home/host/.ssh/syslog-monitor (/home/host/.ssh/syslog-monitor)
host@nms5-vm-linux2 ~]$ ssh syslog-mon@starfire -s netconf > test.out host@nms5-vm-linux2 ~]$ cat test.out
this is NDcPP test device <!-- No zombies were killed during the creation of this user interface -- <!-- user syslog-mon, class j-monitor -><hello> <capabilities> <capability>urn:ietf:params:xml:ns:netconf:base:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:candidate:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:confirmed-commit:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:validate:1.0</capability> <capability>urn:ietf:params:xml:ns:netconf:capability:url:1.0?protocol=http,ftp,file</capability> <capability>http://xml.juniper.net/netconf/junos/1.0</capability> <capability>http://xml.juniper.net/dmi/system/1.0</capability> </capabilities> <session-id4129/session-id> </hello> ]]>]]>
The following output shows event logs generated on the TOE that are received on the syslog server.
Jan 20 17:04:51 starfire sshd[4182]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
Jan 20 17:04:51 starfire sshd[4182]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Jan 20 17:04:53 starfire sshd[4182]: Accepted password for sec-admin from 10.209.11.24 port 55571 ssh2
Jan 20 17:04:53 starfire mgd[4186]: UI_AUTH_EVENT: Authenticated user 'sec-admin' at permission level 'j-administrator'
Jan 20 17:04:53 starfire mgd[4186]: UI_LOGIN_EVENT: User 'sec-admin' login, class 'j-administrator' [4186], ssh-connection '10.209.11.24 55571 10.209.14.92 22', client-mode 'cli'
The following output shows that the local syslogs and remote syslogs received are similar.
Local : an 20 17:09:30 starfire mgd[4186]: UI_COMMIT_PROGRESS: Commit operation in progress: Redundancy interface management process checking new configuration Jan 20 17:09:30 starfire mgd[4186]: UI_CHILD_START: Starting child '/usr/sbin/rdd' Jan 20 17:09:30 starfire mgd[4186]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/rdd', PID 4317, status 0 Jan 20 17:09:30 starfire mgd[4186]: UI_COMMIT_PROGRESS: Commit operation in progress: Dynamic flow capture service checking new configuration Jan 20 17:09:30 starfire mgd[4186]: UI_CHILD_START: Starting child '/usr/sbin/dfcd' ....................................
Remote : an 20 17:09:30 starfire mgd[4186]: UI_COMMIT_PROGRESS: Commit operation in progress: Redundancy interface management process checking new configuration Jan 20 17:09:30 starfire mgd[4186]: UI_CHILD_START: Starting child '/usr/sbin/rdd' Jan 20 17:09:30 starfire mgd[4186]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/rdd', PID 4317, status 0 Jan 20 17:09:30 starfire mgd[4186]: UI_COMMIT_PROGRESS: Commit operation in progress: Dynamic flow capture service checking new configuration Jan 20 17:09:30 starfire mgd[4186]: UI_CHILD_START: Starting child '/usr/sbin/dfcd' Jan 20 17:09:30 starfire mgd[4186]: UI_CHILD_STATUS: Cleanup child '/usr/sbin/dfcd', PID 4318, status 0 Jan 20 17:09:30 starfire mgd[4186]: UI_COMMIT_PROGRESS: Commit operation in progress: Connectivity fault management process checking new configuration ...............