Page 1 of 1

which solution is recommended?

Posted: Fri Sep 05, 2014 5:06 pm
by optimanet
hello,

i have a plesk 12 debian 7 node with mod_security2 installed. i am searching for modsecurity rules, especially against web application brute force attacks and malicious (php) file uploads. which solution is recommended? does 'Atomic ModSecurity rule set' scan file uploads (eg. against clamdscan), natively?

i just tried to install "Atomic ModSecurity rule set" (trial) through plesk 12 GUI, but got

Failed to install the ModSecurity rule set: SecReadStateLimit is depricated, use SecConnReadStateLimit instead. Syntax error on line 40 of /etc/apache2/modsecurity.d/rules/atomic/modsec/01_asl_domain_blocks.conf: Error creating rule: Could not open phrase file "/etc/asl/custom-domain-blocks": No such file or directory

:-(


regards,
andi

Re: which solution is recommended?

Posted: Fri Sep 05, 2014 9:30 pm
by mikeshinn
Definitely report this as a bug to Parallels, they arent installing the rules correctly. You're getting those that error because Plesk is incorrectly installing this rule file:

/etc/apache2/modsecurity.d/rules/atomic/modsec/01_asl_domain_blocks.conf

And not this one:

/etc/asl/custom-domain-blocks

As documented here:

https://www.atomicorp.com/wiki/index.ph ... locks.conf

So, if you just touch that file, this error will go away:

Syntax error on line 40 of /etc/apache2/modsecurity.d/rules/atomic/modsec/01_asl_domain_blocks.conf: Error creating rule: Could not open phrase file "/etc/asl/custom-domain-blocks": No such file or directory

This is happening because theres some kind of bug in Plesk that causes it to bypass our rule installer altogether. So definitely report this as a bug to them as unfortunately Plesk itself is causing your broken configuration and maybe they have a fix for this.

Re: which solution is recommended?

Posted: Sat Sep 06, 2014 2:01 am
by optimanet
thank you!
i'll just pass this post tu parallel's support.

is there a way to scan file uploadads (eg. malicious php uploads from joomla, wordpress etc.) with modsecurity ruleset from atomicorp?
if there is no 'native integration', how do you think abouot clamscan.pl-solution with 'SecRule FILES_TMPNAMES "@inspectFile..'?
i just did some tries with this, but detected issues together with typo3 web application :-(

regards,
andi

Re: which solution is recommended?

Posted: Sat Sep 06, 2014 5:20 am
by faris
But to be honest I think you want the full ASL suite, not just the mod_sec rules.

mod_sec, with some good rules, is great, but the full ASL provides to much more! Specifically, you do get a hardened kernel, clamav scanning of files uploaded via FTP, clamav scanning of files uploaded via the file manager, amazing brute-force protection (much better than just Plesk 12's fail2ban) and a zillion other things.

Unfortunately Debian isn't supported by the full ASL suite. So if you've not chosen Debian for any specific reason (and I know a lot of people like it for very good reasons), you might want to consider one of the supported OSes (Centos is typically the most straightforward) for your next Plesk install in order to be able to use the full ASL.

Of course for all I know, Debian may be on the roadmap to be supported in a future version of ASL...?

Re: which solution is recommended?

Posted: Sat Sep 06, 2014 10:02 am
by optimanet
hi,
thank you for reply.

well, ASL is, i am sure, best solution, actually.
we will test it on a test server very soon.

but first, i'd like to know atomic modsecurity ruleset better.
is it true, that there is no web application brute force protection included (eg. after 5 invalid login attempts against wp-login.php, return 403 instead of 200)?

hm.. i am just trying to cover my needs with rule id 377360 and fail2ban.
is there a way to get the rule-id in the first line of such an entry in modsec_audit log or to get the HOST in de line with the rule id (you know, what i want to reach.. :wink: )?
oh.. i just see, that rule 377360 triggers an entry in modsec_audit.log, although i set "SecAuditLogRelevantStatus "^(403)""... do i see that correctly? if yes, i think, my needs are covered :)
above, you wrote "Debian isn't supported by the full ASL suite":
does ASL actually not work with debian or my i just not use the hardened kernel?


regards,
andi

Re: which solution is recommended?

Posted: Thu Sep 11, 2014 7:45 am
by optimanet
hi,
can anyone say something to my latest questions, above?

regards,
andi

Re: which solution is recommended?

Posted: Thu Sep 11, 2014 7:56 am
by prupert
Debian is NOT supported by ASL.
See https://www.atomicorp.com/wiki/index.ph ... support.3F

Re: which solution is recommended?

Posted: Thu Sep 11, 2014 2:07 pm
by mikeshinn
Debian is supported with our rules, and it is supported with aum. Debian is not currently supported with ASL.

Re: which solution is recommended?

Posted: Thu Sep 11, 2014 2:28 pm
by mikeshinn
thank you for reply.
You're very welcome.
is it true, that there is no web application brute force protection included (eg. after 5 invalid login attempts against wp-login.php, return 403 instead of 200)?
You need ASL for that. The rules will detect login failures, but they will not block them.
is there a way to get the rule-id in the first line of such an entry in modsec_audit log or to get the HOST in de line with the rule id (you know, what i want to reach.. :wink: )?
Not sure what you want to do here, can you elaborate?
above, you wrote "Debian isn't supported by the full ASL suite": does ASL actually not work with debian or my i just not use the hardened kernel?
ASL is not supported with Debian at this time.

Re: which solution is recommended?

Posted: Fri Sep 12, 2014 9:32 am
by optimanet
is there a way to get the rule-id in the first line of such an entry in modsec_audit log or to get the HOST in de line with the rule id (you know, what i want to reach.. :wink: )?

Not sure what you want to do here, can you elaborate?
well, i let fail2ban read from modsec_audit.log and i do block, if the same IP is listed in this log for several times within specific timeframe.
the problem is, although i have set

Code: Select all

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(403)"
i get also other entries here. as well, errors 403 not caused by modsecurity rules (eg. forbidden errors if default document is missing and directory listing is not allowed etc.).
furthermore, fail2ban is not able to detect with multiline regex. so if i had any sign, in the first line of each log entry, which shows explicit, that a WAF rule did create the entry, the thing with fail2ban would work better.


regards,
andi