Information Technology Reference
In-Depth Information
create a disservice of this type on a remote host log with few lines of pseudo-code
such as:
while (true){
ip.addr = ip.log_host;
udp.dport = 514;
udp.data = random_string();
}
The packet is not even required to contain all the fields it previously contained.
This makes it even easier to produce harmful messages.
Another way of taking advantage of the lack of message authenticity control might
be to forge ad hoc messages to distract the attention of the system administrator from
real threats taking place.
Once collected,
syslog
data must be stored safely to be used as proof in any inves-
tigation of a system violation. However forensic analysis requires that the proof, i.e.,
the logs, satisfies the following criteria:
Admissible: they must conform with certain legal requisites to be valid in court,
Authentic: it must be possible to prove that the logs contain evidence of the
incident in question,
Complete: the logs must represent the entire history of the incident and not just
a part,
Trusted: there must be no doubts about how the data was collected, its authen-
ticity and its subsequent movements,
Credible: they must be easily understandable in court.
To bring the
syslog
system closer into line with the above requirements various
versions have been developed that furnish new implementations regarding both the
secure transmission of the data and its integrity and authenticity.
Currently numerous such implementations exist, including: modular
syslog
,
SDSC
Syslog
,
Syslog Ng
and
Kiwi
. Each of these has its strengths and weaknesses (espe-
cially for implementation in a distributed environment).
Nevertheless they are all vulnerable to attack once the attacker identifies the type
of traffic involved and can then threaten the integrity of the entire system. We will
introduce to those further problems in the following paragraph.
