ossec-logtest is performing differently from running ossec
85 views
Skip to first unread message
joshua.gruber
Apr 1, 2011, 12:14:07 AM4/1/11
to ossec-list
Okay, per microsoft, when XP and 2008 co-mingle the handshake always
starts with an AUDIT_FAILURE(4769) event, Failure Code 0xe. The old
systems just don't speak the new Kerberos language. This is filling
up my IDS logs as OSSEC doesn't like the big bold FAILURE there. So I
put in some version of this rule into my local_rules.xml:
<rule id="118139" level="1">
<if_sid>18139</if_sid>
<match>Failure Code: 0xE|Failure Code: 0xe|</match>
<match>Failure Code: 0xe</match>
<description>Windows DC enforcing new encryption types</
description>
</rule>
When I pipe the offending archive.log line into ossec-logtest, it
spits out 118139. Happy as a clam. But when it's running live, it
gives me a 18139 result. I have rebooted the ossec server (pretending
it was a Windows machine, you understand.) 118139 NEVER fires in the
live alerts, always 18139. I clipped the lines from archive.log as a
second test, the first time I clipped it from the darned 18139 alert
directly. Here's the line that works in logtest but not live:
WinEvtLog: Security: AUDIT_FAILURE(4769): Microsoft-Windows-Security-
Auditing: (no user): no domain: DC2.CENSORED.com: A Kerberos service
ticket was requested. Account Information: Account Name:
DC2$@CENSORED.COM Account Domain: CENSORED.COM
Logon GUID: {00000000-0000-0000-0000-000000000000} Service
Information: Service Name: krbtgt/CENSORED.COM Service
ID: S-1-0-0 Network Information: Client Address: ::
1 Client Port: 0 Additional Information: Ticket
Options: 0x60810010 Ticket Encryption Type: 0xffffffff
Failure Code: 0xe Transited Services: - This event is
generated every time access is requested to a resource such as a
computer or a Windows service. The service name indicates the
resource to which access was requested. This event can be
correlated with Windows logon events by comparing the Logon GUID
fields in each event. The logon event occurs on the machine that was
accessed, which is often a different machine than the domain
controller which issued the service ticket. Ticket options,
encryption types, and failure codes are defined in RFC 4120.
Thank you in advance for your assistance. I'd also love to submit
this rule for the next version--don't know how that would work.
For reference to Kerberos:
http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/a487286d-bd35-4e5b-8c60-761565fe29b5/
starts with an AUDIT_FAILURE(4769) event, Failure Code 0xe. The old
systems just don't speak the new Kerberos language. This is filling
up my IDS logs as OSSEC doesn't like the big bold FAILURE there. So I
put in some version of this rule into my local_rules.xml:
<rule id="118139" level="1">
<if_sid>18139</if_sid>
<match>Failure Code: 0xE|Failure Code: 0xe|</match>
<match>Failure Code: 0xe</match>
<description>Windows DC enforcing new encryption types</
description>
</rule>
When I pipe the offending archive.log line into ossec-logtest, it
spits out 118139. Happy as a clam. But when it's running live, it
gives me a 18139 result. I have rebooted the ossec server (pretending
it was a Windows machine, you understand.) 118139 NEVER fires in the
live alerts, always 18139. I clipped the lines from archive.log as a
second test, the first time I clipped it from the darned 18139 alert
directly. Here's the line that works in logtest but not live:
WinEvtLog: Security: AUDIT_FAILURE(4769): Microsoft-Windows-Security-
Auditing: (no user): no domain: DC2.CENSORED.com: A Kerberos service
ticket was requested. Account Information: Account Name:
DC2$@CENSORED.COM Account Domain: CENSORED.COM
Logon GUID: {00000000-0000-0000-0000-000000000000} Service
Information: Service Name: krbtgt/CENSORED.COM Service
ID: S-1-0-0 Network Information: Client Address: ::
1 Client Port: 0 Additional Information: Ticket
Options: 0x60810010 Ticket Encryption Type: 0xffffffff
Failure Code: 0xe Transited Services: - This event is
generated every time access is requested to a resource such as a
computer or a Windows service. The service name indicates the
resource to which access was requested. This event can be
correlated with Windows logon events by comparing the Logon GUID
fields in each event. The logon event occurs on the machine that was
accessed, which is often a different machine than the domain
controller which issued the service ticket. Ticket options,
encryption types, and failure codes are defined in RFC 4120.
Thank you in advance for your assistance. I'd also love to submit
this rule for the next version--don't know how that would work.
For reference to Kerberos:
http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/a487286d-bd35-4e5b-8c60-761565fe29b5/
Branimir Pačar
Apr 4, 2011, 7:56:52 AM4/4/11
to ossec...@googlegroups.com
I've tried with your new rule and log you provided and in my case ossec-logtest alerts on this rule. Also i defined localfile and i've cat this log in it from other file (pretending it was live system) and rule also fired.
Try stopping ossec and starting it again.
Regards,
Branimir
joshua.gruber
Apr 6, 2011, 5:08:34 PM4/6/11
to ossec-list
Quick answer: I found a work-around, but I believe that the rules
1817x in msauth_rules.xml do not currently work in the stock rule
sets.
As I mentioned before, I had already tried restarting both client and
agent--services and the whole servers. No luck. Fortunately this
event happens about once every 30 seconds in my organization so it is
easy to re-create. I'm convinced the reason the logtest was behaving
is that what I posted to is (and above) is from the ossec logs and is
therefore pre-processed data. I don't know of a good way to intercept
the data transmitted by the windows agent. (Though I'd love to know
one, I'm new to OSSEC.)
After many trials, the following rule worked:
<rule id="118139" level="1">
<if_sid>18139</if_sid>
<regex>Failure Code:\s\t0xe</regex>
</rule>
As did a match with a space followed by a tab in there (which, I'm
told, is lighter on the CPU.) I'm using this latter one, although I'm
not pasting it here as I don't know if it would be better or worse to
have a rule posted that you might not be able to copy over.
This leads me to believe that the rules for 18170, 18171, and 18172
aren't working, either. The root cause is likely somewhere else, be
that decoder or code for the agents, but I don't believe those rules
work as written.
I'll have a little more information in a day or two: I have an old
thin client at a distant site that needs a new clock battery, every
morning it seems to create a Failure Code 0x25 in my event logs, I'll
see if it triggers a 18172 or a 18139.
> > D...@CENSORED.COM Account Domain: CENSORED.COM
>
> - Show quoted text -
1817x in msauth_rules.xml do not currently work in the stock rule
sets.
As I mentioned before, I had already tried restarting both client and
agent--services and the whole servers. No luck. Fortunately this
event happens about once every 30 seconds in my organization so it is
easy to re-create. I'm convinced the reason the logtest was behaving
is that what I posted to is (and above) is from the ossec logs and is
therefore pre-processed data. I don't know of a good way to intercept
the data transmitted by the windows agent. (Though I'd love to know
one, I'm new to OSSEC.)
After many trials, the following rule worked:
<rule id="118139" level="1">
<if_sid>18139</if_sid>
<description>Windows DC enforcing new encryption types</
description>
<group></group>
description>
</rule>
As did a match with a space followed by a tab in there (which, I'm
told, is lighter on the CPU.) I'm using this latter one, although I'm
not pasting it here as I don't know if it would be better or worse to
have a rule posted that you might not be able to copy over.
This leads me to believe that the rules for 18170, 18171, and 18172
aren't working, either. The root cause is likely somewhere else, be
that decoder or code for the agents, but I don't believe those rules
work as written.
I'll have a little more information in a day or two: I have an old
thin client at a distant site that needs a new clock battery, every
morning it seems to create a Failure Code 0x25 in my event logs, I'll
see if it triggers a 18172 or a 18139.
> > Logon GUID: {00000000-0000-0000-0000-000000000000} Service
> > Information: Service Name: krbtgt/CENSORED.COM Service
> > ID: S-1-0-0 Network Information: Client Address: ::
> > 1 Client Port: 0 Additional Information: Ticket
> > Options: 0x60810010 Ticket Encryption Type: 0xffffffff
> > Failure Code: 0xe Transited Services: - This event is
> > generated every time access is requested to a resource such as a
> > computer or a Windows service. The service name indicates the
> > resource to which access was requested. This event can be
> > correlated with Windows logon events by comparing the Logon GUID
> > fields in each event. The logon event occurs on the machine that was
> > accessed, which is often a different machine than the domain
> > controller which issued the service ticket. Ticket options,
> > encryption types, and failure codes are defined in RFC 4120.
>
> > Thank you in advance for your assistance. I'd also love to submit
> > this rule for the next version--don't know how that would work.
>
> > For reference to Kerberos:
> >http://social.technet.microsoft.com/Forums/en-
> > US/winserversecurity/thread/a487286d-bd35-4e5b-8c60-761565fe29b5/
>
> I've tried with your new rule and log you provided and in my case ossec-logtest alerts on this rule. Also i defined localfile and i've cat this log in it from other file (pretending it was live system) and rule also fired.
>
> Try stopping ossec and starting it again.
>
> Regards,
> Branimir- Hide quoted text -
> > Information: Service Name: krbtgt/CENSORED.COM Service
> > ID: S-1-0-0 Network Information: Client Address: ::
> > 1 Client Port: 0 Additional Information: Ticket
> > Options: 0x60810010 Ticket Encryption Type: 0xffffffff
> > Failure Code: 0xe Transited Services: - This event is
> > generated every time access is requested to a resource such as a
> > computer or a Windows service. The service name indicates the
> > resource to which access was requested. This event can be
> > correlated with Windows logon events by comparing the Logon GUID
> > fields in each event. The logon event occurs on the machine that was
> > accessed, which is often a different machine than the domain
> > controller which issued the service ticket. Ticket options,
> > encryption types, and failure codes are defined in RFC 4120.
>
> > Thank you in advance for your assistance. I'd also love to submit
> > this rule for the next version--don't know how that would work.
>
> > For reference to Kerberos:
> >http://social.technet.microsoft.com/Forums/en-
> > US/winserversecurity/thread/a487286d-bd35-4e5b-8c60-761565fe29b5/
>
> I've tried with your new rule and log you provided and in my case ossec-logtest alerts on this rule. Also i defined localfile and i've cat this log in it from other file (pretending it was live system) and rule also fired.
>
> Try stopping ossec and starting it again.
>
> Regards,
>
> - Show quoted text -
dan (ddp)
Apr 11, 2011, 3:09:05 PM4/11/11
to ossec...@googlegroups.com
Hi Joshua,
2011/4/6 joshua.gruber <joshua...@gmail.com>:
I don't have an AD setup to test with, so if you definitely find any
such issues please let us know.
Reply all
Reply to author
Forward
0 new messages