ConfigServer Community Forum

Update on this. I made sure all the following have a quarantine directory defined... /etc/cxs/cxs.defaults /etc/cxs/cxsftp.sh /etc/cxs/cxscgi.sh /etc/cxs/cxswatch.sh Yet still... This is the most recent scan: ----------- SCAN REPORT ----------- (/usr/sbin/cxs --allusers --block --clamdsock /var/clam...

Hi Sarah,

Thanks. The first one reported on May 10th did have a quarantine directory defined. The second instance above did not (not yet sure why) and I will look into that to make sure that all my servers have that defined.

Here's another one... ----------- SCAN REPORT ----------- (/usr/sbin/cxs --allusers --block --clamdsock /var/clamd --doptions Mv --exploitscan --filemax 50000 --ignore /etc/cxs/cxs.ignore --logfile /var/log/cxs.log --mail root@xxxxx.xxx --MD5 --options mMOLfSGchexdnwZDR --qoptions Mhv --quarantine -...

Found a new one that you may want to add. Over the weekend had no less than 150 messages that various gif/jpg/php files were uploaded that had suspicious data in it. They were marked as suspicious only and not quarantined. Added this to my cxs.xtra file: regall:quarantine:\$_POST\[\(chr\(112\)\.chr\...

Sergio,

Don't you also have to put the word quarantine in the file to force the quarantine?

regll:quarantine:boogyman\.

This may be a bug... Noticed over the past week that several viruses that are detected by ClamAV as being PHP Shell Exploits are NOT getting quarantined... Here is my default cxs config. /usr/sbin/cxs --allusers --clamdsock /var/clamd --doptions Mv --exploitscan --filemax 10000 --ignore /etc/cxs/cxs...

I like the idea, and perhaps when csf gets the user id (email address) that is compromised, it can change the password for it to some random password. That would stop the spammers pretty much dead in their tracks. Then alert the admin that the password for user xxxx@domain.tld has been changed.

Damn. It looks like on 2 of my servers they have found a way around the rule... They are now coming in from multiple IP's (not just one or two, but hundreds at random) so quickly that the rule can't keep up. I see it triggering, but the load gets to 350+ within seconds... and server becomes unrespon...

Got it!
Changed only the SecRule line to log. The SecAction lines are now at nolog and that seems to be doing the trick.

Thanks!!!

Sergio, Ok, I have confirmed that the rule works. I changed the log back to nolog and those Warnings stopped. Then tested the rule by going to a site that has wordpress and hit refresh 3 times within 30 seconds, and got the "Not Acceptable" message (from the 406 Error Page). But with nolog...