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
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).
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 uncommon...@gmail.com wrote:
Has anyone found anything with this - I have the exact same problem -
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
PS - I can packet capture on both ends - what would you want to see???
On May 4, 11:11 am, Kat uncommon...@gmail.com 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
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
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
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
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 doug.bu...@gmail.com wrote:
I experienced the issue with CentOS 5.5, which may be easier to find
than 5.2 or 5.3.
Thanks,
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
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
Finally figured out what was going on with the Windows Event log decoder:
I originally had this:
decoder name=winevt
prematch^WinEvtLog: Security: AUDIT_FAILURE\(\d+\): Security\.* Logon
Failure: /prematch
regex offset=after_prematchUser Name: (\w+) \.* Source Network
Address:
12 matches
Mail list logo
