Secure Firewall Logging Essentials
Secure Firewall can generate syslog alerts for various security events, such as intrusion policies, file and malware policies, discovery policies, and access control policies. It can also send syslog alerts to provide the health status of its various hardware and software components. You can configure a management center to generate and send syslog messages directly to a syslog server. Alternatively, a threat defense device can also send the syslog messages directly to one or more syslog servers. Depending on your use case, which is described later in this chapter, you should select one originator for logging. Configuring both devices—management center and threat defense—for the same syslog messages can be resource intensive.
Secure Firewall can send syslog messages over TCP as well as UDP. When you choose a transport layer protocol, carefully consider its merits and demerits. For example, if TCP is chosen to send syslog messages, Secure Firewall opens multiple connections to the syslog server to ensure that syslog messages are not lost during transmission. In a large deployment, when a syslog server is configured to collect logs from many originators, the volume of TCP connections can be very high; it can introduce excessive overhead to the syslog server. In this case, syslog over UDP may be a more beneficial solution. Keep in mind that UDP may be a low-overhead protocol, but the syslog messages over UDP can be lost due to congestion or any sporadic networking issues. To learn more about the syslog protocol and its implementation over different protocols, you can read the RFC documents listed on Table 21-2.
Table 21-2 RFC Documents Describing Syslog Implementations
RFC | Description |
RFC 5424 | The Syslog Protocol |
RFC 5426 | Transmission of Syslog Messages over UDP |
RFC 6587 | Transmission of Syslog Messages over TCP |
RFC 5425 | Transport Layer Security (TLS) Transport Mapping for Syslog |
Syslog messages can be generated by many processes and subsystems of a computer system, such as the authentication subsystem, networking subsystem, or mail subsystem. Each syslog message is associated with a severity level. As the name implies, a severity level indicates the significance of a message. It enables a system administrator to decide whether and when an action should be taken to address the issue described in a syslog message. The IETF uses the term facility to refer to various subsystems. RFC 5424 describes various severity levels and facilities that can be used by a syslog server. You can find them in Table 21-3 and Table 21-4, respectively.
Table 21-3 Syslog Messages Severity Levels
Severity Level (0–7) | Messages That Describe… |
EMERG | An emergency condition where the system is unusable |
ALERT | A condition where an action must be taken immediately to fix the issue |
CRIT | A critical condition that indicates a failure in the primary system |
ERR | An error condition |
WARNING | A warning condition |
NOTICE | A condition that does not indicate an error but may require special attention |
INFO | An informational message |
DEBUG | Debug-level information to help the developers of an application or system |
Table 21-4 Syslog Messages Facilities
Facility Level (0–23) | Messages That Are Associated With… |
KERN | Kernel |
USER | User-level process |
MAIL | Mail system |
DAEMON | System daemon |
AUTH | Security/authentication subsystem |
SYSLOG | System logging daemon (syslogd) |
LPR | Line printer subsystem |
NEWS | Network news subsystem |
UUCP | Unix-to-Unix copy subsystem |
CRON | Clock/scheduling daemon (Used by Syslog server running on a Linux OS) |
AUTHPRIV | Security/authentication system |
FTP | FTP daemon |
NTP | NTP subsystem |
AUDIT | Audit subsystem (Security log audit) |
ALERT | Alerting subsystem (Console) |
CLOCK | Clock/scheduling daemon (Used by Syslog server running on Windows OS) |
LOCAL0–LOCAL7 | Locally defined facilities |
Leave a Reply