Firewalls send syslog across a WAN to a central collector over UDP. Auditors note that messages can be lost without any indication and can be read or altered in transit. Which change addresses both concerns?
Select an answer to reveal the explanation.
Short Explanation
UDP syslog is like dropping postcards in a mailbox: nobody confirms they arrived, and anyone handling them can read the back. TCP gives you the delivery receipt and TLS seals the envelope. Watch for half-fixes that address loss or privacy, but not both.
Full Explanation
Classic syslog runs over UDP, which provides no acknowledgment, retransmission or encryption. Messages lost to congestion simply disappear, and anyone on the path can read them or inject altered ones. Moving the transport to TCP adds ordered, acknowledged delivery so the sender knows when the collector is unreachable, and wrapping that in TLS, as standardized for syslog, adds encryption and integrity protection, with certificates allowing the sender to authenticate the collector. That one change addresses loss as well as confidentiality and tampering. Raising the logging level generates more messages but does not make any of them more likely to arrive, and it increases load and noise on the same insecure channel. A second UDP collector adds redundancy that may reduce loss, but both copies remain unacknowledged and unencrypted, so the confidentiality and integrity concerns remain. SNMPv2c traps are also typically carried over UDP and the community string is sent in clear text; it is neither encryption nor a delivery guarantee. Exam caveat: some platforms block traffic when a TCP syslog server becomes unreachable unless configured otherwise, so plan collector availability. Operational check: verify the TLS session to the collector is established, confirm the collector's certificate is trusted by the firewall, and test that an interruption raises an alert.