download issue 24 here - Help Net Security

Remoted (running on the server) receives the
logs from Agentd (running on the client). Remoted
is running on chroot (user = ossecr)
and Agentd too (user = ossec). Remoted is
responsible for all communications with the
agents.
Monitord is responsible for monitoring the
agents and takes care of the centralized logfiles.
The daily logs are compressed and
signed by this process, too. We have one
process doing analysis, one sending events
and another receiving them. But, we also
need a worker to collect the events, and this
task is performed by the logcollector. This
daemon is running as root, which is required
because it obviously needs access to the logfiles
it will monitor.
The last two daemons are maild and execd.
Maild, running on chroot (user = ossecm)
sends mails on specific alerts if e-mail notification
is enabled (weʼll see later that this is
easily configurable). The final process, which
coincidentally converts the HIDS into a HIPS,
is execd - the process responsible for starting
active responses.
This sums up all the functionality offered by
OSSEC: we collect logs (logcollector), send
them to the server (agentd and remoted), decode
and analyze them (analysisd) and we
act upon the generated alerts (maild and
execd) if so required.
Analysis: when gibberish becomes
language
(pam_unix)$
A log event can contain a lot of information,
but we donʼt need all of it. We are interested
in the parts that we can use to create actionable
alerts. OSSEC does the analysis in three
phases: pre-decoding, decoding and analysis.
In the first phase - pre-decoding - the information
provided by the event source is parsed
and known fields are extracted. The time, the
system name and the application name are of
particular interest here, but the log message
is left untouched and passes on to the next
phase, decoding. Here, the log message is
inspected in depth and information is further
extracted. Usually we want to gather information
like source IP, username, destination IP,
etc.
With a basic understanding of regular expressions
you can create your own decoders.
Letʼs take a look at the default PAM decoder.
The first two decoder rules are:
^pam_unix|^\(pam_unix\)
The first one tells OSSEC to treat any log
message for which the program name is
(pam_unix) as a PAM message, applying
subsequent decoder rules to it. The second
rule is to catch those PAM messages that, for
one reason or the other, get logged with an-
other program name. Those messages that
contain either the string pam_unix or (pam_unix)
are still regarded as PAM messages.
Now, we need to extract information we can
work with from those messages.
pam
^session \w+
^for user (\S+)
user
www.insecuremag.com 59