Modsecurity and cpanel questions

[KevenWJ]

Hi there,

I have a few questions about modsecurity and cpanel.

1) Currently, I can visit domain.com/.env and that will be logged in modsecurity as critical: 2023-08-08_14-34-05 , however the server responds with a 404 error. Is this the expected behavior? Is there a way to change the paranoia level or default blocking options through cpanel? I'd like to deny (403) or even ban offending IPs.

2) Is there an advantage (IE saving resources) to IP banning offending IPs for 24 or 48 hours as opposed to serving them a 403? We've read reports stating that at least half of traffic is from bots. Can we further maximize our server resources by blocking them as opposed to just denying them?

3) A few times, we've seen users banned through CSF and had to whitelilst their IP in CSF. What actions can lead to an IP ban? Is this done through modsecurity / CSF? I don't see mod_evasive installed. We've definitely seen some of our users get IP banned, but I'm not sure exactly why.

4) We are interested in adding the project honeypot API to modsecurity. The behavior we would like to see is to block harvesters and spammers (IP ban). Can you help us do this or provide instructions? I know this can be done with fail2ban, but is there a setting to do this within cpanel?

5) How is the SecAuditLogParts directive being set in cpanel? I noticed the modsec_audit log has different settings than I've seen before when installing modsecurity without cpanel. I'm trying to stick to the available cpanel options but am comfortable modifying config files if necessary.

Any help is appreciated!
Thank you

 

[cPRex]

Hey there!

1) Currently, I can visit domain.com/.env and that will be logged in modsecurity as critical: 2023-08-08_14-34-05 , however the server responds with a 404 error. Is this the expected behavior? Is there a way to change the paranoia level or default blocking options through cpanel? I'd like to deny (403) or even ban offending IPs.

Yes, the 404 is the expected behavior since the file doesn't exist on the server, but ModSec still detects the potentially malicious extension. There are some additional deatisl about blocking the IP addresses here, but it's not a straightforward process: Block IP addresses that trigger repeated ModSecurity warnings?

2) Is there an advantage (IE saving resources) to IP banning offending IPs for 24 or 48 hours as opposed to serving them a 403? We've read reports stating that at least half of traffic is from bots. Can we further maximize our server resources by blocking them as opposed to just denying them?

Probably. I don't really have any data on this, but it would make sense that blocking the IP would be less resource intensive than serving a page.

3) A few times, we've seen users banned through CSF and had to whitelilst their IP in CSF. What actions can lead to an IP ban? Is this done through modsecurity / CSF? I don't see mod_evasive installed. We've definitely seen some of our users get IP banned, but I'm not sure exactly why.

cPanel doesn't make CSF, but the most likely answer is cPHulk

4) We are interested in adding the project honeypot API to modsecurity. The behavior we would like to see is to block harvesters and spammers (IP ban). Can you help us do this or provide instructions? I know this can be done with fail2ban, but is there a setting to do this within cpanel?

We don't have any supported tools for this on our side, but if you need to adjust Apache to handle this you'll want to research the include details here: Modify Apache Virtual Hosts with Include Files | cPanel & WHM Documentation

5) How is the SecAuditLogParts directive being set in cpanel? I noticed the modsec_audit log has different settings than I've seen before when installing modsecurity without cpanel. I'm trying to stick to the available cpanel options but am comfortable modifying config files if necessary.

The actual modsec configuration is located in /etc/apache2/conf.d/modsec.conf. I *think* this is the relevant section you're looking for:

<IfModule security2_module>
    SecAuditLog logs/modsec_audit.log
    SecDebugLog logs/modsec_debug.log
    SecDebugLogLevel 0
    SecDefaultAction "phase:2,deny,log,status:406"
    SecRequestBodyLimitAction ProcessPartial

    # Switch to concurrent logging when Apache is running under a multi-uid
    # environment.  This ensures that each user can successfully log to
    # their own log file.
    <IfModule ruid2_module>
        SecAuditLogStorageDir logs/modsec_audit
        SecAuditLogType Concurrent
    </IfModule>
    <IfModule mpm_itk_module>
        SecAuditLogStorageDir logs/modsec_audit
        SecAuditLogType Concurrent
    </IfModule>

    # user.conf must come before cpanel.conf to allow administrators
    # to selectively disable vendor rules
    Include /etc/apache2/conf.d/modsec/modsec2.user.conf
    Include /etc/apache2/conf.d/modsec/modsec2.cpanel.conf

</IfModule>

 

[KevenWJ]

Under modsecurity configuration, there is a spot to add an api key for project honey pot:

2023-08-22_12-28-20

World's leading screen capture + recorder from Snagit + Screencast by Techsmith. Capture, edit and share professional-quality content seamlessly.

app.screencast.com

Does the following need to be added as a rule?

SecAction "id:900500, phase:1, nolog, pass, t:none, setvar:tx.block_search_ip=0, setvar:tx.block_suspicious_ip=0, setvar:tx.block_harvester_ip=1, setvar:tx.block_spammer_ip=1"

 

[cPRex]

Good catch! Yes, it looks like the rule needs to be manually added per the details here:

How to use Project Honeypot with NGINX and ModSecurity 3.0

Learn how to configure ModSecurity 3.0, for both NGINX and NGINX Plus, to integrate with Project Honeypot and block malicious IP addresses.

www.nginx.com