Re: [ossec-list] Re: Active Response on Windows events [RESOLVED]

[Martin Gottlieb]

Finally figured out what was going on with the Windows Event log decoder:

I originally had this:


^WinEvtLog: Security: AUDIT_FAILURE\(\d+\): Security\.* Logon 
Failure: 
User Name: (\w+) \.* Source Network 
Address: (\d+.\d+.\d+.\d+)

user,srcip


When I copied and pasted an event from the alert log (see WinEvtLog in 
thread below) into ossec-logtest, everything matched and
it worked fine.  The problem with that approach is that tabs and other 
characters get converted to spaces.


When I ran the command: sed -n 16741p 
logs/alerts/2011/May/ossec-alerts-04.log | bin/ossec-logtest
from within /var/ossec, the decoder did not extract the user and srcip 
fields.  I then ran:
sed -n 16741p logs/alerts/2011/May/ossec-alerts-04.log | od -a  and 
found that each Name: Value pair was

preceded by a variable number of spaces and then a *TAB *character.

It turns out that *\s* only matches spaces, not any white-space 
character.  So I changed my regex to this:


User\s+Name:\s*(\w+)\s+\.*Source Network 
Address:\s+(\d+.\d+.\d+.\d+)\s+


and it  now works.

Thanks to everyone who offered suggestions, especially Andy who pointed 
me to ossec-logtest.


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] *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: adminDomain: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 Transited Services: -  Source 
Network Address: 118.126.5.109  Source Port: 3041

Would these work as the corresponding decoders:


^WinEvtLog: Application: AUDIT_FAILURE\(\d+\): MSSQLSERVER: 
\.* Login failed for user
'(\w+)'. [CLIENT: 
(\d+.\d+.\d+.\d+)]

user,srcip



^WinEvtLog: Security: AUDIT_FAILURE\(\d+\): Security\.* 
Logon Failure: 
User Name: (\w+) \.* Source Network 
Address: (\d+.\d+.\d+.\d+)

user,srcip


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:
  


   windows
   ^WinEvtLog:
   ^\.+: (\w+)\((\d+)\): (\.+):
   (\.+): \.+: (\S+):
 \.+: \.+: \.+: \.+: \.+: \.+:
   \.+: \.+: \.+: \.+: \.+: \.+: \.+: \.+:
   \.(\S+)
   status, id, extra_data, user, system_name, srcip
   name, location, user, system_name  
  
Then, in /dev/ossec/rules/msauth.xml, I replaced rule 18152 with:
  
   

 win_authentication_failed
 
 Multiple Windows Logon Failures Same IP.
 authentication_failures,
   
   
 win_authentication_failed
 Multiple Windows Logon Failures.
 authentication_failures,
   
  
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    wrote:


Shouldn't this block from the config on the OSSEC server:

  






firewall-drop

as

6

3600



  


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

[ossec-list] Format of OSSEC's syslog output entries is different for OSSEC server

[blacklight]

Hello Folks,


The format of OSSEC's syslog output for OSSEC clients is as typified
in this example:

discosco ossec: Alert Level: 10; Rule: 5712 - SSHD brute force trying
to get access to the system.; Location: (lady-dev.gaga.net)
74.143.171.166->/var/log/secure; srcip: 72.55.156.23;  Apr 12 22:35:40
lady-dev sshd[19838]: Invalid user recruit from 72.55.156.23

Note that the value of the location field is the FQDN of the OSSEC
client host followed by its IP address - this is what we want.


On the other hand, this is the format of the OSSEC syslog output for
the OSSEC server itself as typified in this example:

discosco ossec: Alert Level: 10; Rule: 5712 - SSHD brute force trying
to get access to the system.; Location: discosco->/var/log/secure;
srcip: 72.55.156.23;  Apr 12 22:35:40 cricket-dev sshd[19838]: Invalid
user recruit from 72.55.156.23

Note that the Location field has the relative name of the host rather
than the FQDN and we really want the FQDN. Further, note that the
syslog output record for the OSSEC server host does NOT include the IP
address of the host.


We would very much like the format of the OSSEC syslog output entries
for the OSSEC server host to  have the same structure as the format of
the OSSEC syslog output entries for the OSSEC clients - the reason is
the we are exporting the OSSEC syslog output to a syslog server where
we process this output. For this reason, we need the format of the
OSSEC syslog output to be consistent.


Hopefully, you will make the necessary changes in the OSSEC code but
if there anything I can specify in the OSSEC configuration files in
the meantime?


Thanks,

Re: [ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[Doug Burks]

It's entirely possible you never experienced it on 5.5.  I had a four
or five different servers on RHEL/CentOS 5.5 and only 2 of them
exhibited this behavior.  These 2 were the busiest OSSEC servers I
had, so it could be related to number of agents and/or alerts.  But
again, both of these servers have been upgraded to 5.6 and I haven't
seen the issue since.
-- 
Doug Burks, GSE, CISSP
President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

On Wed, May 4, 2011 at 2:35 PM, dan (ddp)  wrote:
> Thanks for the heads up. I think I may have a copy of 5.5. I don't
> remember having an issue like that, but it's been a while.
>
> On Wed, May 4, 2011 at 2:27 PM, Doug Burks  wrote:
>> I experienced the issue with CentOS 5.5, which may be easier to find
>> than 5.2 or 5.3.
>>
>> Thanks,
>> --
>> Doug Burks, GSE, CISSP
>> President, Greater Augusta ISSA
>> http://augusta.issa.org
>> http://securityonion.blogspot.com
>>
>> On Wed, May 4, 2011 at 2:19 PM, dan (ddp)  wrote:
>>> I'm trying to find a CentOS 5.2 or 5.3 ISO right now to see if I can
>>> reproduce this. No luck so far.
>>>
>>> I don't think it's a packet thing, I think one of the components in
>>> ossec-analysisd is interacting poorly with something in CentOS that
>>> was updated (to a version that doesn't have a problem with what's in
>>> OSSEC) between 5.3 and 5.6.
>>> I haven't had time to track down the CentOS changelogs for clues though.
>>>
>>> On Wed, May 4, 2011 at 1:43 PM, Kat  wrote:
 PS - I can packet capture on both ends - what would you want to see???

 On May 4, 11:11 am, Kat  wrote:
> RHEL 5.3
>
> Only "special" update is PHP 5.3, which would have nothing to do with
> OSSEC, but mentioning it.
>
> I would be happy to supply some debug info.
>
> It was working flawlessly when first installed, then they just started
> dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
> 10
> The only agents that have never exhibited any problems are the Windoze
> boxes.
>
> -k
>
> On May 4, 10:59 am, "dan (ddp)"  wrote:
>
> > What OS/distro/revision are you using on your manager system?
> > Daniel Cid has offered to help track it down, but he needs access to a
> > system showing this issue.
> > dan
>>>
>>
>

Re: [ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[dan (ddp)]

Thanks for the heads up. I think I may have a copy of 5.5. I don't
remember having an issue like that, but it's been a while.

On Wed, May 4, 2011 at 2:27 PM, Doug Burks  wrote:
> I experienced the issue with CentOS 5.5, which may be easier to find
> than 5.2 or 5.3.
>
> Thanks,
> --
> Doug Burks, GSE, CISSP
> President, Greater Augusta ISSA
> http://augusta.issa.org
> http://securityonion.blogspot.com
>
> On Wed, May 4, 2011 at 2:19 PM, dan (ddp)  wrote:
>> I'm trying to find a CentOS 5.2 or 5.3 ISO right now to see if I can
>> reproduce this. No luck so far.
>>
>> I don't think it's a packet thing, I think one of the components in
>> ossec-analysisd is interacting poorly with something in CentOS that
>> was updated (to a version that doesn't have a problem with what's in
>> OSSEC) between 5.3 and 5.6.
>> I haven't had time to track down the CentOS changelogs for clues though.
>>
>> On Wed, May 4, 2011 at 1:43 PM, Kat  wrote:
>>> PS - I can packet capture on both ends - what would you want to see???
>>>
>>> On May 4, 11:11 am, Kat  wrote:
 RHEL 5.3

 Only "special" update is PHP 5.3, which would have nothing to do with
 OSSEC, but mentioning it.

 I would be happy to supply some debug info.

 It was working flawlessly when first installed, then they just started
 dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
 10
 The only agents that have never exhibited any problems are the Windoze
 boxes.

 -k

 On May 4, 10:59 am, "dan (ddp)"  wrote:

 > What OS/distro/revision are you using on your manager system?
 > Daniel Cid has offered to help track it down, but he needs access to a
 > system showing this issue.
 > dan
>>
>

Re: [ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[Doug Burks]

I experienced the issue with CentOS 5.5, which may be easier to find
than 5.2 or 5.3.

Thanks,
-- 
Doug Burks, GSE, CISSP
President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

On Wed, May 4, 2011 at 2:19 PM, dan (ddp)  wrote:
> I'm trying to find a CentOS 5.2 or 5.3 ISO right now to see if I can
> reproduce this. No luck so far.
>
> I don't think it's a packet thing, I think one of the components in
> ossec-analysisd is interacting poorly with something in CentOS that
> was updated (to a version that doesn't have a problem with what's in
> OSSEC) between 5.3 and 5.6.
> I haven't had time to track down the CentOS changelogs for clues though.
>
> On Wed, May 4, 2011 at 1:43 PM, Kat  wrote:
>> PS - I can packet capture on both ends - what would you want to see???
>>
>> On May 4, 11:11 am, Kat  wrote:
>>> RHEL 5.3
>>>
>>> Only "special" update is PHP 5.3, which would have nothing to do with
>>> OSSEC, but mentioning it.
>>>
>>> I would be happy to supply some debug info.
>>>
>>> It was working flawlessly when first installed, then they just started
>>> dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
>>> 10
>>> The only agents that have never exhibited any problems are the Windoze
>>> boxes.
>>>
>>> -k
>>>
>>> On May 4, 10:59 am, "dan (ddp)"  wrote:
>>>
>>> > What OS/distro/revision are you using on your manager system?
>>> > Daniel Cid has offered to help track it down, but he needs access to a
>>> > system showing this issue.
>>> > dan
>

[ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[Kat]

Perhaps this is the kicker to help figure this out:

tcpdump on the ossec-server - watching the system agent attempt to
connect.  But there are no firewalls in place anyway, just a router.
And the weird part is - another box, 10.15.58.62 works - and has been
- but I know if I restart it, it will fail - that is the symptom.
(both Solaris)

# tcpdump -ni bond0 host 10.15.58.60

13:01:37.848570 IP 10.15.58.60.47102 > 10.15.40.45.ossec-agent: UDP,
length 81
13:01:37.848851 IP 10.15.40.100.ossec-agent > 10.15.58.60.47102: UDP,
length 73
13:01:37.849118 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47102 unreachable, length 92
13:01:42.848771 arp who-has 10.15.58.60 tell 10.15.40.100
13:01:42.849372 arp reply 10.15.58.60 is-at 00:00:0c:01:00:40
13:01:43.849593 IP 10.15.58.60.47102 > 10.15.40.45.ossec-agent: UDP,
length 81
13:01:43.849877 IP 10.15.40.100.ossec-agent > 10.15.58.60.47102: UDP,
length 73
13:01:43.850150 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47102 unreachable, length 92
13:01:47.850439 IP 10.15.58.60.47102 > 10.15.40.45.ossec-agent: UDP,
length 81
13:01:47.850695 IP 10.15.40.100.ossec-agent > 10.15.58.60.47102: UDP,
length 73
13:01:47.850955 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47102 unreachable, length 92
13:01:52.851341 IP 10.15.58.60.47102 > 10.15.40.45.ossec-agent: UDP,
length 81
13:01:52.851653 IP 10.15.40.100.ossec-agent > 10.15.58.60.47102: UDP,
length 73
13:01:52.851894 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47102 unreachable, length 92
13:01:58.85 IP 10.15.58.60.47102 > 10.15.40.45.ossec-agent: UDP,
length 81
13:01:58.852477 IP 10.15.40.100.ossec-agent > 10.15.58.60.47102: UDP,
length 73
13:01:58.852644 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47102 unreachable, length 92
13:02:00.853995 IP 10.15.58.60.47103 > 10.15.40.45.ossec-agent: UDP,
length 81
13:02:00.854262 IP 10.15.40.100.ossec-agent > 10.15.58.60.47103: UDP,
length 73
13:02:00.854487 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47103 unreachable, length 92
13:02:05.855020 arp who-has 10.15.58.60 tell 10.15.40.100
13:02:05.855765 arp reply 10.15.58.60 is-at 00:00:0c:01:00:40
13:02:06.855025 IP 10.15.58.60.47103 > 10.15.40.45.ossec-agent: UDP,
length 81
13:02:06.855281 IP 10.15.40.100.ossec-agent > 10.15.58.60.47103: UDP,
length 73
13:02:06.855586 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47103 unreachable, length 92
13:02:10.855908 IP 10.15.58.60.47103 > 10.15.40.45.ossec-agent: UDP,
length 81
13:02:10.856173 IP 10.15.40.100.ossec-agent > 10.15.58.60.47103: UDP,
length 73
13:02:10.856502 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47103 unreachable, length 92
13:02:15.856776 IP 10.15.58.60.47103 > 10.15.40.45.ossec-agent: UDP,
length 81
13:02:15.857057 IP 10.15.40.100.ossec-agent > 10.15.58.60.47103: UDP,
length 73
13:02:15.857359 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47103 unreachable, length 92
13:02:21.857679 IP 10.15.58.60.47103 > 10.15.40.45.ossec-agent: UDP,
length 73
13:02:21.857941 IP 10.15.40.100.ossec-agent > 10.15.58.60.47103: UDP,
length 73
13:02:21.858196 IP 10.15.58.60 > 10.15.40.100: ICMP 10.15.58.60 udp
port 47103 unreachable, length 92


On May 4, 12:43 pm, Kat  wrote:
> PS - I can packet capture on both ends - what would you want to see???
>
> On May 4, 11:11 am, Kat  wrote:
>
> > RHEL 5.3
>
> > Only "special" update is PHP 5.3, which would have nothing to do with
> > OSSEC, but mentioning it.
>
> > I would be happy to supply some debug info.
>
> > It was working flawlessly when first installed, then they just started
> > dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
> > 10
> > The only agents that have never exhibited any problems are the Windoze
> > boxes.
>
> > -k
>
> > On May 4, 10:59 am, "dan (ddp)"  wrote:
>
> > > What OS/distro/revision are you using on your manager system?
> > > Daniel Cid has offered to help track it down, but he needs access to a
> > > system showing this issue.
> > > dan

Re: [ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[dan (ddp)]

I'm trying to find a CentOS 5.2 or 5.3 ISO right now to see if I can
reproduce this. No luck so far.

I don't think it's a packet thing, I think one of the components in
ossec-analysisd is interacting poorly with something in CentOS that
was updated (to a version that doesn't have a problem with what's in
OSSEC) between 5.3 and 5.6.
I haven't had time to track down the CentOS changelogs for clues though.

On Wed, May 4, 2011 at 1:43 PM, Kat  wrote:
> PS - I can packet capture on both ends - what would you want to see???
>
> On May 4, 11:11 am, Kat  wrote:
>> RHEL 5.3
>>
>> Only "special" update is PHP 5.3, which would have nothing to do with
>> OSSEC, but mentioning it.
>>
>> I would be happy to supply some debug info.
>>
>> It was working flawlessly when first installed, then they just started
>> dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
>> 10
>> The only agents that have never exhibited any problems are the Windoze
>> boxes.
>>
>> -k
>>
>> On May 4, 10:59 am, "dan (ddp)"  wrote:
>>
>> > What OS/distro/revision are you using on your manager system?
>> > Daniel Cid has offered to help track it down, but he needs access to a
>> > system showing this issue.
>> > dan

Re: [ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[Doug Burks]

Kat,

Is ossec-analysisd using a high percentage of CPU (more than 5%)?
That was what I experienced.  Since I upgraded to CentOS (RHEL) 5.6, I
haven't seen the issue again.

Thanks,
-- 
Doug Burks, GSE, CISSP
President, Greater Augusta ISSA
http://augusta.issa.org
http://securityonion.blogspot.com

On Wed, May 4, 2011 at 12:11 PM, Kat  wrote:
> RHEL 5.3
>
> Only "special" update is PHP 5.3, which would have nothing to do with
> OSSEC, but mentioning it.
>
> I would be happy to supply some debug info.
>
> It was working flawlessly when first installed, then they just started
> dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
> 10
> The only agents that have never exhibited any problems are the Windoze
> boxes.
>
> -k
>
> On May 4, 10:59 am, "dan (ddp)"  wrote:
>> What OS/distro/revision are you using on your manager system?
>> Daniel Cid has offered to help track it down, but he needs access to a
>> system showing this issue.
>> dan
>

[ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[Kat]

PS - I can packet capture on both ends - what would you want to see???

On May 4, 11:11 am, Kat  wrote:
> RHEL 5.3
>
> Only "special" update is PHP 5.3, which would have nothing to do with
> OSSEC, but mentioning it.
>
> I would be happy to supply some debug info.
>
> It was working flawlessly when first installed, then they just started
> dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
> 10
> The only agents that have never exhibited any problems are the Windoze
> boxes.
>
> -k
>
> On May 4, 10:59 am, "dan (ddp)"  wrote:
>
> > What OS/distro/revision are you using on your manager system?
> > Daniel Cid has offered to help track it down, but he needs access to a
> > system showing this issue.
> > dan

[ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[Kat]

RHEL 5.3

Only "special" update is PHP 5.3, which would have nothing to do with
OSSEC, but mentioning it.

I would be happy to supply some debug info.

It was working flawlessly when first installed, then they just started
dropping off. Agents are a mixture of AIX 6.1 , RHEL 5.3 and Solaris
10
The only agents that have never exhibited any problems are the Windoze
boxes.

-k

On May 4, 10:59 am, "dan (ddp)"  wrote:
> What OS/distro/revision are you using on your manager system?
> Daniel Cid has offered to help track it down, but he needs access to a
> system showing this issue.
> dan

Re: [ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[dan (ddp)]

What OS/distro/revision are you using on your manager system?
Daniel Cid has offered to help track it down, but he needs access to a
system showing this issue.
dan
On May 4, 2011 11:56 AM, "Kat"  wrote:
> Has anyone found anything with this - I have the exact same problem -
> there has got to be something that is known about this. All my Windoze
> agents work fine, but I have lost every single UNIX/Linux agent and
> for no reason other than the same silly
>
> WARN: Waiting for server reply (not started).
>
> Why are we not figuring this out??? :-(
>
> so frustrating

[ossec-list] Re: All UNIX/LINUX agents disconnecting and failing to reconnect

[Kat]

Has anyone found anything with this - I have the exact same problem -
there has got to be something that is known about this. All my Windoze
agents work fine, but I have lost every single UNIX/Linux agent and
for no reason other than the same silly

WARN: Waiting for server reply (not started).

Why are we not figuring this out???  :-(

so frustrating

[ossec-list] again whitelist and dyndns

[Rainer]

Hi security people,

today I realized that whitelisting by hostname doesn't work at
all with OSSEC, at least not with a dyndns hostname, even when
the IP address is the same as to the time when I start OSSEC.

I did some tests, did a -service ossec restart- and then produced 
a level-10-alert 1 minute later, and my office got locked out. bang.

ossec.log states me:
...
2011/05/04 13:10:32 ossec-analysisd: INFO: White listing Hostname:
'localhost.localdomain'
2011/05/04 13:10:32 ossec-analysisd: INFO: White listing Hostname:
'blablabla.dnsuser.de'
2011/05/04 13:10:32 ossec-analysisd: INFO: 2 Hostname(s) in the white
list for active response.
...

How does that white list work when it comes to hostnames?
At least it does not work for me the way I thought it should work.

ossec 2.5.1 local installation
ubuntu 10.04 LTS 64 Bit

greets, Rainer.