Information Technology Reference
In-Depth Information
3.2.1 Syslog: Transmission Related Problems
As we know,
syslog
relies on UDP to transmit messages. This makes commu-
nication between the two parties unreliable by definition. On top of this, messages
generated during network transmission between the source host and the destination
host may be lost entirely. This can only be solved by using as a transport substrate
a reliable protocol like TCP which uses transmission notification, following an ini-
tial handshake phase. Some implementations of the
syslog
daemon (e.g.,
syslog-ng
)
allow you to choose the underlying communication channel to be used. Another
solution is to use a point-point connection (e.g., serial line) or a dedicated subnet
to collect system logs, but this option is rarely adopted, for obvious reasons. Let's
take an example of a hacker with access to the communication network between
source and destination. The attacker could passively listen to the communication
channel and delete any messages that reveal their presence. This cannot be detected
because there is no notification mechanism or sequential numbering of the messages
sent.
3.2.2 Syslog: Message Integrity Problems
A second intrinsic problem with the protocol is that it does not provide, except
at the IP packet level, any mechanism to safeguard the integrity of the message
produced. This means an attacker can capture, change and reintroduce into the
network a message in transit from the source host to the destination host with-
out leaving any trace. Note that merely adding a field for a checksum or a hash
to the message doesn't solve the problem. Sticking with the same example, all
the hacker needs to do is recalculate the error control code or the message hash
and overwrite the existing one to avoid suspicion on the part of the destination
host.
3.2.3 Syslog: Message Authenticity Problems
Finally, there is no mechanism to verify the source of the messages. In effect the
remote log collector does nothing more than listen to the specific port and write
the messages it receives to disk. This opens the door to a range of problems linked
to the possibility to exploit such 'trust' in the source to cause disservice or intro-
duce false information into the system. One possible scenario might be as follows:
once the hacker has gained access to the system, he generates false alerts and trans-
mits them to the remote host until its disk space is full. Having done that, he could
then operate on the system safe in the knowledge that his activities, though moni-
tored, are not being registered on the remote host. This type of intrusion does not
require any special expertise. We could illustrate a possible program designed to
