syscheck rule 550 - logs from ossec server missing hashes

279 views
Skip to first unread message

Martin Kvocka

unread,
Jan 13, 2015, 9:40:26 AM1/13/15
to ossec...@googlegroups.com
Hi,

we have Ossec server/agents (2.7.0) for monitoring file integrity. Both include check_all="yes" in their syscheck configurations. The agents work perfectly and report file changes including their old/current MD5 and SHA1 hashes. However, logs from the Ossec server machine report only file changes, but don't include the hashes. 

Did any of you encounter this issue? How should I debug it?

Thanks

dan (ddp)

unread,
Jan 13, 2015, 9:43:21 AM1/13/15
to ossec...@googlegroups.com
Can you show us an example?
Do the hashes exist in the syscheck db for the manager?

> Thanks
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Martin Kvocka

unread,
Jan 13, 2015, 10:11:09 AM1/13/15
to ossec...@googlegroups.com
Hi,

I'll try to simulate this tomorrow in virtual machines, as I don't have the necessary access to the environment (I only receive the logs from syslog). I'll post the results. 

MK

Martin Kvocka

unread,
Jan 14, 2015, 4:56:27 AM1/14/15
to ossec...@googlegroups.com
Hi,

I managed to get the samples. In manager syscheck queue I found the following:

#++0:33206:0:0:f5679adb3c830f61d8fed1c287d42e62:5546733b9afdb2a403c8e58f85c74af2739ddb58 !1421093166 C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel
#++312832:33206:0:0:f5679adb3c830f61d8fed1c287d42e62:5546733b9afdb2a403c8e58f85c74af2739ddb58 !1421129146 C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel
#!+465920:33206:0:0:f5679adb3c830f61d8fed1c287d42e62:5546733b9afdb2a403c8e58f85c74af2739ddb58 !1421165040 C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel
!!!619520:33206:0:0:f5679adb3c830f61d8fed1c287d42e62:5546733b9afdb2a403c8e58f85c74af2739ddb58 !1421201008 C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel

And in logs:

Jan 13 07:05:46 a.b.c.d ossec: Alert Level: 7; Rule: 550 - Integrity checksum changed.; Location: (hostname) a.b.c.d->syscheck; Integrity checksum changed for: 'C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel'

Jan 13 17:04:00 a.b.c.d ossec: Alert Level: 7; Rule: 550 - Integrity checksum changed.; Location: (hostname) a.b.c.d->syscheck; Integrity checksum changed for: 'C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel'


I just realized that the .xel file seems to be a log file and may change often - may this be the cause?

Thanks,
MK

dan (ddp)

unread,
Jan 14, 2015, 9:57:52 AM1/14/15
to ossec...@googlegroups.com
On Wed, Jan 14, 2015 at 4:56 AM, Martin Kvocka <mkv...@gmail.com> wrote:
> Hi,
>
The hashes are there in the syscheck db, but not in your syslog
messages. I'm guessing that adding the hashes makes the messages too
long so they were trimmed. You can check the alerts.log file for the
original alerts to see if the hashes are there.

Martin Kvocka

unread,
Jan 15, 2015, 5:21:10 AM1/15/15
to ossec...@googlegroups.com
I checked the alerts log and the hashes are not there. There are however longer entries than these (f.e. registry keys) that include hashes.

I will, for now, assume that the hash is not computed as the file changes too often and will observe if other (standard) files report hashes correctly.

Thanks for your help dan.

You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/RVTdJCErFSo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.

dan (ddp)

unread,
Jan 15, 2015, 8:19:26 AM1/15/15
to ossec...@googlegroups.com
On Thu, Jan 15, 2015 at 4:39 AM, Martin Kvocka <mkv...@gmail.com> wrote:
> I checked the alerts log and the hashes are not there. There are however
> longer entries than these (f.e. registry keys) that include hashes.
>

Can you provide an example of an alert that does not include the hash?
I've never seen that before.

> I will, for now, assume that the hash is not computed as the file changes
> too often and will observe if other (standard) files report hashes
> correctly.
>

The examples from the syscheck db have hashes. The hashes are being computed.

Martin Kvocka

unread,
Jan 15, 2015, 9:45:24 AM1/15/15
to ossec...@googlegroups.com
Yes, here are two:

** Alert 1421201008.92848: mail  - ossec,syscheck,
2015 Jan 14 03:03:28 (hostname) a.b.c.d->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
Integrity checksum changed for: 'C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel'
Size changed from '465920' to '619520'

** Alert 1421236975.304052: mail  - ossec,syscheck,
2015 Jan 14 13:02:55 (hostname) a.b.c.d->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
Integrity checksum changed for: 'C:\Program Files/Microsoft SQL Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel'
Size changed from '619520' to '773120'

Alert including hashes:

** Alert 1421237527.307675: mail  - ossec,syscheck,
2015 Jan 14 13:12:07 (hostname) a.b.c.d->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
Integrity checksum changed for: 'C:\Program Files/ESET/ESET File Security/em023_32.dat'
Size changed from '4999753' to '4837924'
Old md5sum was: 'b1cc041394714fa91d79ffb191f86e52'
New md5sum is : '02bae5f0b36acaa39b894111efabb0f3'
Old sha1sum was: '3a02dc803999a7e66304c0bf7d501ed3dad03f75'
New sha1sum is : '99eb652ad7dd9e2c782c5599d1eaa5e3dc2078fb'


dan (ddp)

unread,
Jan 15, 2015, 10:28:09 AM1/15/15
to ossec...@googlegroups.com
On Thu, Jan 15, 2015 at 9:45 AM, Martin Kvocka <mkv...@gmail.com> wrote:
> Yes, here are two:
>
> ** Alert 1421201008.92848: mail - ossec,syscheck,
> 2015 Jan 14 03:03:28 (hostname) a.b.c.d->syscheck
> Rule: 550 (level 7) -> 'Integrity checksum changed.'
> Integrity checksum changed for: 'C:\Program Files/Microsoft SQL
> Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel'
> Size changed from '465920' to '619520'
>
> ** Alert 1421236975.304052: mail - ossec,syscheck,
> 2015 Jan 14 13:02:55 (hostname) a.b.c.d->syscheck
> Rule: 550 (level 7) -> 'Integrity checksum changed.'
> Integrity checksum changed for: 'C:\Program Files/Microsoft SQL
> Server/MSSQL11.APPS/MSSQL/Log/system_health_0_130655447155770000.xel'
> Size changed from '619520' to '773120'
>

Checking the size is a different check than the checksum. If you just
want checksums, look at the check_all option in your <directories>
blocks.

Martin Kvocka

unread,
Jan 16, 2015, 5:10:05 AM1/16/15
to ossec...@googlegroups.com
Ok, I understand it now. I thought size/permission changes would be a different rule, not 550.

Thanks!

dan (ddp)

unread,
Jan 16, 2015, 7:38:38 AM1/16/15
to ossec...@googlegroups.com
On Fri, Jan 16, 2015 at 3:02 AM, Martin Kvocka <mkv...@gmail.com> wrote:
> Ok, I understand it now. I thought size/permission changes would be a
> different rule, not 550.
>

Looks like 592 handles cases where files reduce in size, but I don't
see anything for increases in size.
Reply all
Reply to author
Forward
0 new messages