The Session Smart Router can be configured to maintain a history of several different class of events in its event log , which can subsequently be used to support compliance audits, forensics on network issues related to configuration (misapplied or otherwise), and traceability. This document covers:
- Types of events available on the router
- Enabling the Audit events (using the PCLI or the GUI)
- Using the Event Viewer in the GUI
The events generated by the router are classified into the following categories:
Traffic events are generated as sessions as created on the router. These include details such as the protocol, source address, source port, destination address and destination port. In addition, the success or failure status along with a reason code for failure cases are included in the event.
Various administration actions performed by a user such as SSH login generate this category of events. The events contain the details about the user action, whether or not the action was permitted, and the reason for any failures.
Various system level events such as service and process restarts are generated by this event category. The details include information about the user and details about the underlying action.
All the 128T alarms generate an add event when the alarm is raised and a clear event when the alarm is cleared. The alarm events can be used to view the history of the events associated with the alarms. The alarm events are implicit events and cannot be disabled via configuration. More details on alarms and events can be found here
The provisioning events are generated for software download and upgrades as well as for configuration changes that are processed on the router. For configuration changes the event contains a diff of the configuration change that triggered the event. These are implicit events and cannot be disabled via configuration.
The configuration for audit logging is performed within the
system > audit branch within a
router hierarchy. In most cases, the only configuration required for enabling audit logging is adding it to the
router element for your Authority's conductor. For cases where a 128T router is not managed by a conductor, its audit logging configuration is similarly added to the
system > audit branch of its
128T version 5.1.0 introduces capabilities to provide additional control over persistence and storage duration of the various events listed above. The table below shows the various configuration options and the corresponding behavior pre- and post- 5.1.0 software.
|retention||duration||5.1.0||180 days||How long to persist the events listed above.|
|traffic > enabled||boolean||all||false||Enable/disable the generation of traffic events.|
|traffic > persist||boolean||5.1.0||false||If enabled, whether or not to persist the events to the local storage for the configured retention duration.|
|administration > enabled||boolean||all||true||Enable/disable the generation of administration events.|
|administration > persist||boolean||5.1.0||true||If enabled, whether or not to persist the events to the local storage for the configured retention duration.|
|system > enabled||boolean||all||true||Enable/disable the generation of system events.|
|system > persist||boolean||5.1.0||true||If enabled, whether or not to persist the events to the local storage for the configured retention duration.|
Configuration not related to audit logging has been filtered out for illustrative purposes.
Enable Basic Audit Logging
Storing Events for Short Durations
By default the 128T routers store all events except traffic events for up to six months on the local disk. In some cases it might be desirable to shorten the length of time for these events to minimize the impact on the local disk. This can be accomplished as follows:
In the above example all the events available on the 128T router are only retained for one day. The
retention is of type duration and can take values in hours and days; for example, 24h or 1d.
Sending Traffic Events to a Syslog Server
Traffic events are disabled and not persisted by default because they can produce a large volume of data. However, in situations where the traffic events need to be sent off-box for storage, such as a syslog server, they can be enabled but not persisted to local storage. The following snippet provides an example of that configuration.
For in-depth explanations of how to configure the Monitoring Agent to handle audit events, refer to the 128T Monitoring Agent documentation.
Basic Input and Output Configurations
Use the following information to create basic Input and Output configurations.
- Create an event collector input to capture the traffic events. An example input configuration is shown below.
# It is a best practice to specify a custom index file location
index-file = "/var/lib/128t-monitoring/state/events.index"
topic = "events"
type = ["traffic"]
- Define an output for where the events are to be sent. In this example, the events are sent to a syslog server.
address = "udp://<ip>:514"
default_sdid = "128T"
- The input and output are placed in the input and output directories respectively and tied together by the Monitoring Agent configuration. A sample monitoring agent configuration:
- name: traffic-events
- name: my-syslog
Once these configurations are in place, starting the Monitoring Agent will send events to syslog.
Viewing the Audit Log
To view the contents of the audit log via the GUI (on the Conductor or Router as configured above).
To view the contents of the audit log, navigate to the Tools page and choose Event History. The Event History viewer shows all of the events that this 128T has accumulated, including audit log events. Audit log events are of type ADMIN; use the built-in filtering mechanism to limit the Event History search results to ADMIN type events.