[ossec-list] Re: Log format question

["John Lewis" <jnlewis@xxxxxxxxxxxxx>]

Thanks Daniel, I'd be happy to provide log samples.  What is the best way to do
so?  On the wiki?  Via email?

-JL

-----Original Message-----
From: ossec-list@xxxxxxxxxxxxxxxx [mailto:ossec-list@xxxxxxxxxxxxxxxx] On Behalf
Of Daniel Cid
Sent: Monday, April 30, 2007 5:16 PM
To: ossec-list@xxxxxxxxxxxxxxxx
Cc: John Lewis
Subject: [ossec-list] Re: Log format question


Hi John,

I am not very familiar with this Linux distribution, but they are probably using
multilog from dbj which actually breaks the syslog output.

http://cr.yp.to/daemontools/multilog.html

I can make some quick changes on ossec to remove the timestamp from
the beginning of the logs, but that will require you to patch ossec (or wait
for the next version).

Besides that, you will still need to change some of the iptables decoders,
because the program name from iptables was changed to "denylog" instead
of what everyone uses: "kernel" (easy stuff). Btw, if you can provide a few
more logs (from sshd, etc), I can make sure to test them too.

Hope it helps.

--
Daniel B. Cid
dcid ( at ) ossec.net



On 4/27/07, John Lewis <jnlewis@xxxxxxxxxxxxx> wrote:
>
> I'm running several servers using the smeserver linux distro
> (http://wiki.contribs.org/Main_Page) based on centos.  I've noticed many of
the
> log formats are different from what much of the documentation I find details
> standard logs as looking like.
>
> On the smeserver, many logs are dumped to the service name directory, into a
> file called "current".
>
> For example: iptables dumps its logs to /var/log/iptables/current in a format
> that looks like this:
>
> @40000000463246020c2ca16c Apr 27 14:50:32 gluon denylog: IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:15:c5:55:aa:9f:08:00  SRC=216.12.18.89
> DST=255.255.255.255 LEN=29 TOS=00 PREC=0x00 TTL=128 ID=3256 PROTO=UDP SPT=4855
> DPT=1434 LEN=9
> @400000004632460a081ba154 Apr 27 14:50:40 gluon denylog: IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:15:c5:55:aa:9f:08:00  SRC=216.12.18.89
> DST=255.255.255.255 LEN=29 TOS=00 PREC=0x00 TTL=128 ID=3674 PROTO=UDP SPT=4856
> DPT=1434 LEN=9
> @400000004632460b1bb1e994 Apr 27 14:50:41 gluon denylog: IN=eth1 OUT=
> MAC=01:00:5e:00:00:01:00:10:63:71:93:3d:08:00  SRC=216.12.21.176 DST=224.0.0.1
> LEN=28 TOS=00 PREC=0x00 TTL=1 ID=0 PROTO=0
> @400000004632461131929ed4 Apr 27 14:50:47 gluon denylog: IN=eth1 OUT=
> MAC=01:00:5e:00:00:01:00:13:46:40:a7:a3:08:00  SRC=216.12.15.233 DST=224.0.0.1
> LEN=28 TOS=00 PREC=0x00 TTL=1 ID=18840 PROTO=0
> @400000004632461209688be4 Apr 27 14:50:48 gluon denylog: IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:15:c5:55:aa:9f:08:00  SRC=216.12.18.89
> DST=255.255.255.255 LEN=29 TOS=00 PREC=0x00 TTL=128 ID=4105 PROTO=UDP SPT=4857
> DPT=1434 LEN=9
> @400000004632461a0b44ba3c Apr 27 14:50:56 gluon denylog: IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:15:c5:55:aa:9f:08:00  SRC=216.12.18.89
> DST=255.255.255.255 LEN=29 TOS=00 PREC=0x00 TTL=128 ID=4548 PROTO=UDP SPT=4858
> DPT=1434 LEN=9
> @40000000463246220d0a10ec Apr 27 14:51:04 gluon denylog: IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:15:c5:55:aa:9f:08:00  SRC=216.12.18.89
> DST=255.255.255.255 LEN=29 TOS=00 PREC=0x00 TTL=128 ID=4973 PROTO=UDP SPT=4859
> DPT=1434 LEN=9
> @40000000463246231bc1d3cc Apr 27 14:51:05 gluon denylog: IN=eth1 OUT=
> MAC=01:00:5e:00:00:01:00:10:63:71:93:3d:08:00  SRC=216.12.21.176 DST=224.0.0.1
> LEN=28 TOS=00 PREC=0x00 TTL=1 ID=0 PROTO=0
> @40000000463246250b93d054 Apr 27 14:51:07 gluon denylog: IN=eth1 OUT=
> MAC=01:00:5e:00:00:01:00:13:46:40:a7:a3:08:00  SRC=216.12.15.233 DST=224.0.0.1
> LEN=28 TOS=00 PREC=0x00 TTL=1 ID=18841 PROTO=0
> @400000004632462a091bcf5c Apr 27 14:51:12 gluon denylog: IN=eth1 OUT=
> MAC=ff:ff:ff:ff:ff:ff:00:15:c5:55:aa:9f:08:00  SRC=216.12.18.89
> DST=255.255.255.255 LEN=29 TOS=00 PREC=0x00 TTL=128 ID=5403 PROTO=UDP SPT=4860
> DPT=1434 LEN=9
>
> Dhcpd dumps its logs to /var/log/dhcpd/current looking like this:
>
> @400000004631f09637f3537c DHCPACK on 192.168.100.20 to 00:01:e6:31:a0:e5 via
> eth0
> @40000000463240330bb5759c Wrote 0 deleted host decls to leases file.
> @40000000463240330bb594dc Wrote 0 new dynamic host decls to leases file.
> @40000000463240330bb5a864 Wrote 21 leases to leases file.
> @40000000463240330f1dca04 DHCPREQUEST for 192.168.100.243 from
00:0e:7f:62:b3:58
> (hadron) via eth0
> @40000000463240330f1ded2c DHCPACK on 192.168.100.243 to 00:0e:7f:62:b3:58
> (hadron) via eth0
> @400000004632403512a48794 DHCPREQUEST for 192.168.100.243 from
00:0e:7f:62:b3:58
> (hadron) via eth0
> @400000004632403512a4aabc DHCPACK on 192.168.100.243 to 00:0e:7f:62:b3:58
> (hadron) via eth0
> @4000000046324039330c717c DHCPINFORM from 192.168.100.243 via eth0
> @4000000046324039330c90bc DHCPACK to 192.168.100.243
>
> Does anyone recognize this format that could point me in the right direction
as
> to why it is formatted this way?
> Is there any simple way to have OSSEC parse these logs (especially the
iptables
> logs) to get good alerting out of them?  Any other ideas on getting ossec to
> have visibility into iptables logs?
>
> Thanks
>
>