Detections
Analytics

6.12.2 Ensure At Least 2 External SYSLOG Hosts are Set with Any/Info

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Logging data must be sent to at least two external SYSLOG servers.

Rationale:
Log information from a JUNOS Device can be vital in detecting an attack and to allow incidents to be analyzed, investigated and (where appropriate) prosecuted. SYSLOG information is also helpful in diagnosing and resolving non-security related operational issues on the network.
Because of this, one of the first tasks an attacker will attempt to accomplish after gaining access to a Network Device is to alter or delete logs to cover their tracks.
To prevent an attacker or a fault denying you access to log data, it is vital to send logs to at least one External Logging and/or SIEM (Security Incident and Event Manager) Server. JUNOS Devices use the industry standard SYSLOG protocol for this.
SYSLOG entries are generated by a range of sources on a JUNOS Device, such as authorization which reports Authentication and Authorization events or PFE for events encountered by the Packet Forwarding Engine. Each of these sources are referred to as a Facility.
In addition to indicating what facility generated a log message, JUNOS SYSLOG also indicates and allows the administrator to filter based on the Severity Level for each message. There are eight possible levels, which are as follows:
- Emergency (0)
- Alert (1)
- Critical (2)
- Error (3)
- Warning (4)
- Notice (5)
- Informational (6)
- Any (7) (called Debug on many SYSLOG systems)
Each increase in level represents an increase in the detail and number of log messages created. Each level includes the messages from all preceding levels, so Critical includes all messages from both the Alert and Emergency levels.
To ensure that vital messages about the Health and Security of the JUNOS Device are not missed, or lost should an attacker delete local logs, at least two External SYSLOG or SIEM Servers should be configured to receive log messages from any Facility and at least info Severity.
SYSLOG messages are sent in a 'fire and forget' manner over UDP, with no acknowledgement or ability to resend missed messages in the event a server is unable to handle them. Adding a second server significantly reduces the risk that messages are lost in the event of a network or server issue.

Solution

SYSLOG data is recorded locally by default, you can configure external SYSLOG servers by issuing the following commands from the [edit system syslog] hierarchy;
[edit system syslog]
user@host# set host <Server 1> any <Severity>

[edit system syslog]
user@host# set host <Server 2> any <Severity>
Where:
- <Server 1> is the IP Address or Fully Qualified Domain Name of the first Remote SYSLOG or SIEM Server
- <Server 2> is the IP Address or FQDN of a separate second Remote SYSLOG or SIEM Server. For added resilience, you may wish to place the second server on a different network to the first and this is recommended where possible.
- <Severity> should be either any or info
Some SYSLOG or SIEM Servers may require additional configuration items such as explicit-priority or structured-data options to be configured.
It is possible to filter SYSLOG messages to be forwarded to the host using a match or match-string condition. This should not be set for the device's the Remote SYSLOG Hosts configured in meeting this Recommendation.

Impact:
Network Devices, particularly Firewalls, can generate a significant volumes of log data, it is essential that the target SYSLOG servers are suitably resourced to handle the expected volume of messages and it is strongly recommended that robust archiving and retention processes be employed.

Default Value:
Log messages are not sent to remote hosts by default, but are stored locally in files in the /var/log/ folder.

See Also

https://workbench.cisecurity.org/files/2278

Item Details

Category: AUDIT AND ACCOUNTABILITY

References: 800-53|AU-9(2), CSCv7|6.5

Plugin: Juniper

Control ID: c0cacbda9f88099986426dcb1b6cf3e5f2dc26fef5d747881e7cece0d403c3fa