Hi
This is triggering a level 5 alert -- will that actually do anything
on your system? Or do you have another rule for multiple occurrences?
Certainly for mine, I have a level 10 alert for multiple occurrences
(more than 3) which then activates the response on the windows agent
Just a random thought
Andy
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Martin Gottlieb
*Sent:* Thursday, 28 April 2011 1:23 a.m.
*To:* [email protected]
*Subject:* Re: [ossec-list] Re: Active Response on Windows events
Well, I thought I was making progress, but now I'm not so sure. My
MSSQL decoder has triggered a couple
of active responses, so I believe it is working properly. But, I am
not getting any alerts on windows logon
failures (I did previously), much less an active response.
I found the following event in my ossec alert log (identifying info
modified):
** Alert 1303837130.3865847: -
syslog,false_positivesauthentication_failed,
2011 Apr 26 12:58:50 (win3) 2.1.1.2->WinEvtLog
Rule: 100245 (level 5) -> 'User authentication failure.'
Src IP: (none)
User: (none)
WinEvtLog: Security: AUDIT_FAILURE(529): Security: SYSTEM: NT
AUTHORITY: WINSERVER: Logon Failure: Reason: Unknown
user name or bad password User Name: ryan
Domain: WINSERVER Logon Type: 10 Logon
Process: User32 Authentication Package: Negotiate
Workstation Name: WINSERVER Caller User Name:
WINSERVER$ Caller Domain: WINDOMAIN Caller Logon ID:
(0x0,0x3E7) Caller Process ID: 5716 Transited
Services: - Source Network Address: 7.7.7.226
Source Port: 51287
What's strange is that it does not match the SrcIP or User fields.
When I run this log entry through ossec-logtest, I get the
following results:
**Phase 2: Completed decoding.
decoder: 'winevt'
dstuser: 'ryan'
srcip: '7.7.7.226'
**Phase 3: Completed filtering (rules).
Rule id: '100245'
Level: '5'
Description: 'User authentication failure.'
**Alert to be generated.
So clearly the winevt decoder is working correctly. Any ideas as to
why it works in test mode, but not "live"?
Here's the winevt decoder:
<decoder name="winevt">
<prematch>^WinEvtLog:\s*Security:\s*AUDIT_FAILURE\(\d+\):\s*Security\.* Logon
Failure: </prematch>
<regex offset="after_prematch">User Name:\s+(\w+) \.* Source Network
Address:\s+(\d+.\d+.\d+.\d+)</regex>
<order>user,srcip</order>
</decoder>
I did make a few minor changes since my previous posts, mainly
replacing spaces with "\s*" to allow for multiple white-space characters.
Thanks.
Martin
On 4/25/2011 11:43 AM, Martin Gottlieb wrote:
Thanks, my ossec server is a router/firewall, my apologies for
omitting this detail. I was really
just trying to figure out how to get the server to trigger the
script(s) in the first place on the
windows events, since it was clearly getting notified about the events.
With help from Andy, I believe I have found that the issue boils down
to the decoders. I think I
have a fix i place now and will be posting a "RESOLVED" message once I
have verified this (just waiting
for someone to attack the server).
Thanks again to everyone who offered help on this.
Martin
On 4/25/2011 11:23 AM, Scott VR wrote:
It is important to undertstand that firewall-drop.sh script executes
unix/linux commands and the only way that invoking it on the server
will serve any function to protect your windows hosts is if your ossec
server is *also* running as a router/firewall in front of your windows
boxes. If this is the case, it's a pretty major piece of the design
that you left off of your description. If it's not the case, you are
going to need something similar (which I think you alluded to in your
inital email) to the null-route.cmd setup outlined in
http://www.ossec.net/main/manual/manual-active-response-on-windows.
In summary, if your ossec server is also a router for your network,
then running the ipfilters/ipchains/ipsec commands in the
firewall-drop.sh script will work, with the proper regex to obtain
srcip. If it is not, the running this command on the ossec server will
have no effect and you need to run the command on the windows box
through its agent.
Cheers,
On Sat, Apr 23, 2011 at 10:27 PM, Martin Gottlieb <[email protected]
<mailto:[email protected]>> wrote:
Hi Andy,
Thanks again for another great piece of advice. ossec-logtest seems
to confirm that the
regexes are good. The SQL Server decoder triggers rule 2501, level
5. I had to add the
following to my local rules to get the winevt decoder to also trigger
2501:
<rule id="100245" level="5">
<match>Logon Failure</match>
<group>authentication_failed,</group>
<description>User authentication failure.</description>
</rule>
I think this should to the trick. Thanks again for your help.
Martin
On 4/23/2011 5:26 PM, Andy Cockroft (andic) wrote:
Hi
I didn't have that much success with a Regex similar to the one you
wrote, I ended up having to specify everything in a very long-handed
way -- as I said perhaps someone could write the decoder far more
eloquently than I -- especially constructs such as \.* in the middle
of the Regex
However, what I did do, is make my changes to the decoder and run
ossec-logtest -- this makes checking the decoder and rules so much
easier without actually affecting production operation
Best I can do for now -- hope you have your Rules sorted as well --
ossec-logtest will check these at the same time
Andy
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]] *On Behalf Of *Martin Gottlieb
*Sent:* Sunday, 24 April 2011 3:16 a.m.
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [ossec-list] Re: Active Response on Windows events
Awesome, thanks! The events I'm seeing generally take 2 forms:
SQL Server Events:
WinEvtLog: Application: AUDIT_FAILURE(18456): MSSQLSERVER: (no user):
no domain: WINSERVER: Login failed for user 'admin'. [CLIENT:
203.81.30.248 <tel:203.81.30.248>]
And general Windows Events:
WinEvtLog: Security: AUDIT_FAILURE(529): Security: SYSTEM: NT AUTHORITY:
WINSERVER: Logon Failure: Reason: Unknown user name or bad
password User Name: admin Domain: WINSERVER Logon
Type: 10 Logon Process: User32 Authentication Package:
Negotiate Workstation Name: WINSERVER Caller User Name:
WINSERVER$ Caller Domain: WINDOMAIN Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 532 Transi
ted Services: - Source Network Address: 7.7.7.109 Source
Port: 3041
Would these work as the corresponding decoders:
<decoder name="mssql">
<prematch>^WinEvtLog: Application: AUDIT_FAILURE\(\d+\): MSSQLSERVER:
\.* Login failed for user</prematch>
<regex offset="after_prematch">'(\w+)'. [CLIENT:
(\d+.\d+.\d+.\d+)]</regex>
<order>user,srcip</order>
</decoder>
<decoder name="winevt">
<prematch>^WinEvtLog: Security: AUDIT_FAILURE\(\d+\): Security\.*
Logon Failure: </prematch>
<regex offset="after_prematch">User Name: (\w+) \.* Source Network
Address: (\d+.\d+.\d+.\d+)</regex>
<order>user,srcip</order>
</decoder>
Thanks.
Martin
On 4/22/2011 7:28 PM, AndiC wrote:
The problem I found was that the Windows decoder in the server /dev/
ossec/etc/decoder.xml does not extract the "srcip", so you have
nothing to work with to block
Now this is what I replaced mine with:
<decoder name="windows">
<type>windows</type>
<prematch>^WinEvtLog:</prematch>
<regex offset="after_prematch">^\.+: (\w+)\((\d+)\): (\.+):</regex>
<regex>(\.+): \.+: (\S+):</regex>
<regex> \.+: \.+: \.+: \.+: \.+: \.+:</regex>
<regex>\.+: \.+: \.+: \.+: \.+: \.+: \.+: \.+:</regex>
<regex>\.(\S+)</regex>
<order>status, id, extra_data, user, system_name, srcip</order>
<fts>name, location, user, system_name</fts> </decoder>
Then, in /dev/ossec/rules/msauth.xml, I replaced rule 18152 with:
<rule id="181521" level="10" frequency="$MS_FREQ" timeframe="240">
<if_matched_group>win_authentication_failed</if_matched_group>
<same_source_ip />
<description>Multiple Windows Logon Failures Same IP.</
description>
<group>authentication_failures,</group>
</rule>
<rule id="181522" level="10" frequency="$MS_FREQ" timeframe="240">
<if_matched_group>win_authentication_failed</if_matched_group>
<description>Multiple Windows Logon Failures.</description>
<group>authentication_failures,</group>
</rule>
I also dropped $MS_FREQ (start of msauth.xml) to 3
This works for me, and my Windows clients are well protected.
I am sure someone could write a far more eloquent decode Regex - sorry
I'm just coming to grips with that. I'm also uncertain if this will
work against anything other than Server 2003 for which it is written
But this is only the decoder that needs some tuning, the rest seems
fine
Regards
Andy
On Apr 23, 9:08 am, Martin Gottlieb<[email protected]> <mailto:[email protected]> wrote:
Shouldn't this block from the config on the OSSEC server:
<active-response>
<!-- Firewall Drop response. Block the IP for
- 600 seconds on the firewall (iptables,
- ipfilter, etc).
-->
<command>firewall-drop</command>
<location>as</location>
<level>6</level>
<timeout>3600</timeout>
</active-response>
cause the firewall drop script to be run on the server for any event
that is level 6 or higher, regardless of
which agent it came from? That's all I'm trying to accomplish, I don't
need anything to run on the Windows
agent if I can get the firewall drop script to run on the server.
Thanks.
Martin
On 4/22/2011 4:58 PM, dan (ddp) wrote:
Hi Martin,
On Fri, Apr 22, 2011 at 4:37 PM, Martin Gottlieb<[email protected]>
<mailto:[email protected]> wrote:
I guess what I'm trying to understand is this:
When an event is triggered from a Linux agent, the firewall drop
script is
run on the
OSSEC server (in addition to the hosts deny script being called on
the
agent). I don't recall
doing anything special to make this happen when I installed OSSEC,
I assume
it is part of
the default behavior.
The default actions (if I'm reading
https://bitbucket.org/dcid/ossec-hids/src/4908b28513b0/etc/ossec-serv...
correctly) is that the script is run on the system where the log
message originated.
Unless you changed the configurations the scripts shouldn't be running
on both the server and the agents.
When an event is triggered on a Windows agent, the firewall drop
script is
NOT called on the server,
but I would like it to be. I would like the default behavior on
Windows
agents to be the same
as Linux agents, at least as far as what happens on the OSSEC
server. The
Windows agent is
obviously reporting the event to the server as it logs it and
reports it to
me.
Am I understanding the responses so far to mean that I have to
write a
script to make this
happen, and that the script needs to reside on the Windows agent?
Thanks again.
Martin
The script would have to reside on all of the systems you want it to
run on. Having it run on both Windows and Linux systems may be
difficult.- Hide quoted text -
- Show quoted text -
