Business Continuity, DR & Incident Response →hardMultiple Choice

ISC2 CC Business Continuity, DR & Incident Response Practice Question

Exhibit

Refer to the exhibit.

syslog-ng configuration:
@version: 3.35
destination d_remote { syslog("10.0.0.10" transport("tls") port(6514)); };
log { source(s_sys); destination(d_remote); };

Firewall rule on logging server:
permit tcp host 10.0.0.10 eq 6514 host 192.168.1.100

The exhibit shows a syslog-ng client configuration and a firewall rule on the central logging server (IP 10.0.0.10). The client (192.168.1.100) is not sending logs to the server. What is the most likely cause?

⚠ Common exam trap

Many exam-takers assume the firewall rule's source port 6514 is irrelevant or that the client must use the same port as the server, when in fact the client uses an ephemeral source port, making the rule overly restrictive and the cause of the failure.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The firewall rule restricts source port 6514, but the client uses a random ephemeral source port

The firewall rule on the central logging server (10.0.0.10) specifies a source port of 6514. However, syslog-ng clients, when sending over TCP or TLS, typically use a random ephemeral source port (e.g., above 1024) rather than a fixed source port. Since the firewall restricts the source port to exactly 6514, the client's packets are dropped, preventing logs from reaching the server.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The syslog-ng configuration uses TLS, but the firewall rule does not allow TLS traffic
Why it's wrong here
TLS runs over TCP 6514, and the firewall rule already permits that port, so transport encryption is not what blocks delivery. It is tempting because TLS-versus-plaintext port mismatches genuinely break syslog-ng, and adjusting the rule to 6514 would be right if the client were configured for TLS.
✓
The firewall rule restricts source port 6514, but the client uses a random ephemeral source port
Why this is correct
Firewall rules filtering on source port 6514 break syslog-ng's TCP transport, because clients originate connections from random ephemeral ports; only the destination port is 6514. Since the stem's rule constrains the source port, the client's packets are dropped before reaching 10.0.0.10, preventing log delivery.
✗
The syslog-ng client uses UDP by default, but the firewall allows only TCP
Why it's wrong here
The client configuration explicitly uses TCP transport (tls).
✗
The firewall rule does not include the client IP 192.168.1.100
Why it's wrong here
The firewall rule permits the syslog port from the client subnet, so source IP filtering is not the blocking mechanism here. It is tempting because restrictive source-address rules commonly cause silent drops, and narrowing the rule to 192.168.1.100 would be correct if the stem showed a broader deny or an unlisted subnet.

Go deeper

ISC2 CC Business Continuity, DR & Incident Response Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question