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 <mar...@axion-it.net>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:* ossec-list@googlegroups.com 
> [mailto:ossec-list@googlegroups.com<ossec-list@googlegroups.com>]
> *On Behalf Of *Martin Gottlieb
> *Sent:* Sunday, 24 April 2011 3:16 a.m.
> *To:* ossec-list@googlegroups.com
> *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]
>
>
> 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: 118.126.5.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 <mar...@axion-it.net> 
> <mar...@axion-it.net> 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<mar...@axion-it.net> 
> <mar...@axion-it.net>  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 -
>
>
>
>
>

Reply via email to