Customer support forums for Atomic Protector (formerly Atomic Secured Linux). There is no such thing as a bad question here as long as it pertains to using Atomic Protector. Newbies feel free to get help getting started or asking questions that may be obvious. Regular users are asked to be gentle.
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!
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.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
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.
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.
I don't quite understand what it does. Can you explain in more detail please? What is it shutting down? What is it throttling?
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
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.
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
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..
--------------------------------
<advert>
If you want to rent a UK-based VPS that comes with friendly advice and support from a fellow ART fan, please get in touch.
</advert>
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.
