Sorry for my late answer. I was busy with some other stuff... As you can read in my former posts, I am really new to ossec and I'm not sure, how to answer your question. I can say, everything is at default setting. Having an OSSEC Server and some OSSEC agents.
The problem described, I have only at the Server with heavy load. And since the agent on this server is switched off, I had no problems anymore with blocking rules. Here's what I assume: The server and agents are using Port 1514 for communication. This port is also open to the real world. For the agents I assume, there's a deamon running. Why does it only happen at this particular machine? Because, it has a lot of services runnung, it's a favourite target for our bored "friends" with criminal intentions. I assume, there's something wrong in the agent-deamon, which makes it vulnerable over port 1514. Here's what I'll do next: I'll reconfigure our network, that the agent and server is only using our internal network. In addition I will block Port 1514 from the outside World. If then nothing strange happens again, I'm pretty shure, I'm right. If not, I'll give up. Why do I think, this Problem is caused by the agent? First of all, it only happened when OSSEC was running. And because, there are no other active services, related to IPTABLES running! AND - changing a default policy of a chain is - as far as I see - not a thing, what OSSEC should do. Am I right? I'll let you know, as soon as I can go on. On Aug 25, 3:31 pm, "dan (ddp)" <[email protected]> wrote: > What active response triggers are you currently using? Certain SIDs? > Which ones are triggering the AR? > > > > On Wed, Aug 25, 2010 at 3:12 AM, WebWusel <[email protected]> wrote: > > Okay, > > > here's what happened last night. > > > There was a rule in the forward chain "ACCEPT all from all" and the > > default policy for the input chain was DROP. So I was able to reach > > the virtual Hosts on this machine, but couldnt connect to the host > > anyhow. The only way to fix the system was to connect via my KVM over > > IP. > > > Again, this never happened before I used OSSEC, so I fear, it's caused > > by OSSEC in some strange way. The Logfiles are clean, there's nothing > > suspect inside but I havent had a look at the syslog yet. > > > For Information what system we talking about: > > > Two Servers, lets say SrvA and SrvB. Both are holding two DRBD Drives > > while normally SrvA is Holding "R0" and SrvB is holding "R1". They're > > talking via an internal Network, connected via eth1 to each other with > > heartbeat. Both running OpenVZ with about 4 virtual machines > > (containers) on each. > > > If SrvA is invisible for SrvB for two minutes, SrvB has to assume SrvA > > is dead and has then to mount the R0 Partition and start all the > > virtual hosts on it and visa versa. > > > On both servers I have installed OSSEC. While SrvB has a total Traffic > > (to the real world) of about 16 Gig a day, SrvA has about 13 Gig a day > > but no email Server on it. So OSSEC is really relaxed on SrvA but very > > busy at SrvB. > > > So, the default setting DROP for the Input Chain has effect to all > > network-devices. This causes Heartbeat to take over all ressources > > from SrvA to SrvB and mount the DRBD-Partitions. SrvA is also not > > seeing SrvB anymore and does the same with it's ressources. We have a > > split-brain situation. > > > I also have two other servers running in the same mode as SrvA and > > SrvB, also installed OSSEC and no problems so far. But these servers > > have much less stress as the first cluster has. > > > Can it be, that there's a security leak in OSSEC? > > > I finnally run a rkhunter and chkrootkit on my servers but couldn't > > find any thing suspect. > > > I would like to use OSSEC but I am helpless at the moment. For the > > next three days I leave OSSEC stopped on SrvB to see, if any strange > > things appear again. > > > Would be glad for any hint! > > > Thanks, > > > Oskar- Hide quoted text - > > - Show quoted text -
