Hi Greg,
By default ossec will parse the hostame of these events and treat them
differently. For example,
if you run them through log-test:
**Phase 1: Completed pre-decoding.
full event: 'Mar 4 19:02:48 10.0.2.4 useradd[4961]: new group:
name=foobar, GID=501'
hostname: '10.0.2.4'
program_name: 'useradd'
log: 'new group: name=foobar, GID=501'
**Phase 2: Completed decoding.
No decoder matched.
**Phase 3: Completed filtering (rules).
Rule id: '5901'
Level: '8'
Description: 'New group added to the system'
**Alert to be generated.
So, if you want to treat this host differently in a rule, just use the
<hostname> tag for it:
<rule id="1234" level="10">
<if_sid>5901</if_sid>
<hostname>10.0.2.4|10.0.2.2</hostname>
<description>Group added to host 2.4 or 2.2</description>
</rule>
Hope it helps.
--
Daniel B. Cid
dcid ( at ) ossec.net
On Wed, Mar 4, 2009 at 3:21 PM, Gregory Rubin <[email protected]> wrote:
>
> I'm looking into rolling OSSEC out to a decent sized group of
> computers and am doing it in stages. One of the first stages involved
> deploying it to a centralized syslog server that catches all authpriv
> logging from throughout the fleet. However, it seems that OSSEC
> doesn't know how to handle the IP Address in the prefix of the line.
> Instead, it just ignores it, treating all events as if they effect the
> logging server instead of one of the clients.
>
> Is there are way to get OSSEC to understand these for better
> centralized monitoring of the fleet?
>
> Thanks.
>
> Greg
>
> Example (Scrubbed) comes from the logging host 10.0.2.1:
> Mar 4 19:02:48 10.0.2.4 useradd[4961]: new group: name=foobar, GID=501
> Mar 4 19:02:48 10.0.2.4 useradd[4961]: new user: name=foobar,
> UID=501, GID=501, home=/var/foobar/, shell=/bin/true
> Mar 4 20:17:06 10.0.2.2 sshd[28616]:
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> Mar 4 20:17:06 10.0.2.4 sshd[1941]: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> Mar 4 20:17:06 10.0.2.2 sshd[18964]:
> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
