Atomicorp

mikeshinn wrote:Yeah, its definitely there
[...]
ossec.conf: <directories realtime="yes" check_all="yes" report_changes="yes" >/var/ossec</directories>

Go ahead and remove those from your file integrity checks.

They were not listed in ossec-server.conf, the file you asked us to grep.
Can we remove them from the file integrity checks without having to use the ASL web gui?

Glad to hear that this bug will be fixed in the next release!

Can we remove them from the file integrity checks without having to use the ASL web gui?

Yep, just go into file integrity checks and that directory.

They were not listed in ossec-server.conf, the file you asked us to grep.

ossec.conf should be a symlink to ossec-server.conf.

Just a small heads-up - I manually removed the line in ossec.conf, but it seems it automagically re-appeared at some point afterwards.

Chris has now removed it via GUI and for now it seems to be staying removed.

mikeshinn wrote:

Can we remove them from the file integrity checks without having to use the ASL web gui?

Yep, just go into file integrity checks and that directory.

I mean, *without* using the ASL web gui (see faris' comment above). I hope that would be possible?

They were not listed in ossec-server.conf, the file you asked us to grep.

ossec.conf should be a symlink to ossec-server.conf.

It is not a symbolic link on the servers we mentioned having problems with.
/var/ossec/etc/ossec.conf and /var/ossec/etc/ossec-server.conf are separate and different files.

For those of you experiencing active brute force attacks, we have a test build with a throttling active response system to try out:

yum --enablerepo=asl-4.0-testing upgrade ossec-hids

This should primarily throttle on shutdown, so it will take longer to stop the service but have minimal effect on high-frequency adds. What I'd like to get is a sample of this in action over a week or two of high activity blocking to see if it indeed will make an impact on what you are experiencing.

Thanks Scott.

I don't quite understand what it does. Can you explain in more detail please? What is it shutting down? What is it throttling?

I think this thread flew off into an unrelated tangent. The issue you reported has to do with the load caused by unblocking from an extremely fast brute force attack when the AR's expire. What this does change does is throttle that part, so you dont end up with hundreds or thousands of those happening concurrently.

Ah! Got you. OK. Makes sense.

Did you get a chance to try it?

Unfortunately the I/O (or whatever) affected machines are not mine. I was just looking after them at the time.

It is up to Chris, who is watching this topic..

Sorry - just got this.

I had removed the watch list configuration, as requested - which has stopped all issues with the attacks.
I've never seen it get out of control again, so never been alerted to know if/when an attack is in progress unfortunately.

I'm getting hit by this one again today. Over 22,000 events being logged for rule 392301 today alone. I have active response disabled for the rule so it hasn't really been a huge problem, but it does still have an impact on my server load.

One thing that I have noticed after going through 3 or 4 waves of these attacks is that in my particular case, Geo-blocking Israel (IL), Indonesia (ID), Pakistan (PK) and Romania (RO) appears to block a significant majority of the offending IP addresses lowers my server load by a considerable amount. I know many people can't just block entire countries, but hopefully this may help somebody.

I'm getting hit by this one again today. Over 22,000 events being logged for rule 392301 today alone. I have active response disabled for the rule so it hasn't really been a huge problem, but it does still have an impact on my server load.

You dont need to disable active response for this rule anymore its disable by default now. Its also been rewritten, and now uses a different method that drops the connection immediately and does not shun the attacker or provide any response. So the load on the system should be considerably lower with these rules.

We are also finishing the Threat Intelligence system for ASL which will use the the collaborative reporting aspects of ASL to automatically report attackers to the RBL, and then everyones boxes will drop connections from these malicious IPs in realtime, and do so without a firewall rule.

Awesome, Mike!

We're planning to release the first version this week. We wont enable it by default so you can opt in and let us know how its working for you.