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>
<description>Windows DC enforcing new encryption types</
description>
<group></group>
</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.
On Apr 4, 5:56 am, Branimir Pačar <[email protected]> wrote:
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On
> > Behalf Of joshua.gruber
> > Sent: Friday, April 01, 2011 6:14 AM
> > To: ossec-list
> > Subject: [ossec-list] ossec-logtest is performing differently from running
> > ossec
>
> > 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:
> > [email protected] 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/
>
> 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 -
>
> - Show quoted text -
