Questions: Syslog: Network Logging and Log Aggregation

Question 1

A network administrator configures all routers to send syslog messages to a central server. During a network outage, the syslog server becomes temporarily unreachable. What happens to log messages sent during that time?

• A. They are queued on each router and retransmitted automatically when the server recovers
• B. They are silently dropped — UDP provides no delivery guarantee and syslog does not buffer by default
• C. They are stored locally on each router's flash memory until acknowledged by the server
• D. The routers switch to TCP syslog automatically to ensure delivery during the outage

Answer: (B)

Traditional syslog uses UDP (port 514), which is connectionless and provides no delivery guarantee. If the syslog server is unreachable, UDP datagrams are simply discarded — there is no acknowledgment, no retransmission, and no buffering at the sending device. This is one of syslog's fundamental limitations. Only TCP-based syslog transports (or higher-level log shippers) provide reliable delivery. Administrators who need guaranteed delivery must use syslog over TCP (RFC 6587) or a log agent with local buffering and retry logic.

Question 2

A syslog message is generated by the kernel (facility 0) with severity level 3 (Error). What is the priority value encoded in the message header?

• A. 3
• B. 8
• C. 3
• D. 24

Answer: (A)

The priority value is calculated as (facility × 8) + severity = (0 × 8) + 3 = 3. Facility 0 is the kernel; severity 3 is Error. This compact encoding lets a single small integer encode both dimensions, allowing the receiving syslog server to route and filter messages quickly. For example, a mail system (facility 2) emergency (severity 0) would have priority (2 × 8) + 0 = 16. Understanding this formula is essential for writing syslog filters and routing rules.

Question 3

Syslog guarantees that most log message generated by a network device will be received and stored by the central syslog server.

• T. True
• F. False

Answer: False

Syslog uses UDP by default, which provides no delivery guarantee. Messages can be lost if the network is congested, the syslog server is overloaded or unreachable, or intermediate routers drop packets under load. This is a fundamental design choice — UDP's low overhead allows any device to emit log messages with minimal impact, but at the cost of reliability. For critical security logs where guaranteed delivery is required, syslog over TLS/TCP (RFC 5425/RFC 6587) must be used instead.

Question 4

In a syslog deployment, the timestamp attached to each log message reflects when the central syslog server received the message, not when the originating device generated it.

• T. True
• F. False

Answer: False

Syslog timestamps are generated by the *sending device* and embedded in the message before transmission. The central server records when it receives the packet, but the log message itself contains the originating device's timestamp. This creates a significant problem: if devices have unsynchronized clocks (clock skew), correlating events from multiple sources becomes ambiguous or misleading. A security incident might appear to have events out of order simply because two devices disagree about the current time. This is why NTP synchronization is essential in any multi-device syslog deployment.

Question 5

Why is NTP (Network Time Protocol) synchronization considered essential in a syslog deployment, and what specific analysis capability does it enable?

Model answer: NTP ensures all devices share a common time reference, so syslog timestamps from different sources are comparable. This enables event correlation — reconstructing the sequence of events across multiple devices (firewall, authentication server, application server) during an incident. Without NTP, clock skew between devices can make events appear to happen in the wrong order or at the wrong time, making root-cause analysis of security incidents or outages unreliable or impossible.

The power of centralized log collection is correlation: seeing what happened on device A, then device B, then device C in sequence. If device A's clock is 5 minutes ahead of device B's, log entries from the two sources cannot be reliably sequenced. During a security investigation, this ambiguity can make the difference between identifying an attack chain and missing it entirely. NTP typically achieves millisecond-level synchronization across a network, which is more than sufficient for log correlation. This is why NTP and syslog are almost always deployed together.