General plugins

@ Ramy and Denis,

I hope that you do know that disabling mod security just makes it more likely that someone will eventually be able to hack into your server! If you don't think someone is trying to do that then you REALLY need to go look at your server security logs. As an example, in the past four days, there have been 40,024 failed log in attempts on my home server.

It has been a really long time since I set my server up, but if you log into your server with a GUI, somewhere on the screen you should see a link to a mod security report that describes what access attempts to files/folders have been made. There will also be directions on where and what to change to allow legitimate access to those files/folders.

To me mod security is like all the door and window locks on my house. Using mod security is like giving my family members a key to get into the house. When you disable mod security, that is like leaving ALL the doors and windows open while going off on vacation with the hope that your normal police protection is going to protect your belongings. Eventually, someone will sneak in a rob you blind.

Note that while writing this, the failed log in attempt count on my server has gone up to 40,170.

I agree with Leon ... don't turn it off, but do work on setting up rules *or* blocking bad actors ...  Your OS is?   What sort of access do you have?   SSH?

The following for CentOS 7

find your mod security config file.
On CentOS 7 that's in: /etc/httpd/conf.d/

There is a line to comment out so it puts it in a listening/logging mode
but won't block or stop.

    # Default recommended configuration
#    SecRuleEngine On

The # in front of SecRuleEngine ON to OFF still logs what's going on in

Then one can watch /var/log/httpd/ssl_error_log
for mod_security entries.

Here's an example:

[Thu Apr 14 13:41:27.717408 2022] [:error] [pid 19469] [client 91.243.44.29:13626] [client 91.243.44.29] ModSec
urity: Warning. Operator LT matched 5 at TX:inbound_anomaly_score. [file "/etc/httpd/modsecurity.d/activated_ru
les/modsecurity_crs_60_correlation.conf"] [line "33"] [id "981203"] [msg "Inbound Anomaly Score (Total Inbound
Score: 2, SQLi=0, XSS=0): Request Missing an Accept Header"] [hostname "myserver.org"] [uri "/.env"] [uni
que_id "Ylhq10RzCCgkk4AI8pjvpwAAAAo"]

The IP: 91.243.44.29 was looking for "/.env" - which doesn't exist - even it if did, that's something that outsiders shouldn't be seeing!

A whois for that IP (clip of shows):

inetnum:        91.243.44.0 - 91.243.44.255
org:            ORG-IL649-RIPE
netname:        vds-range
country:        RU

One could block 91.243.44.0/24 range of IP addresses by
CentOS 7's firewall command:

firewall-cmd --zone=drop --add-source=91.243.44.0/24

No ip on that network will be able to see your web server ... nor any other services
of your server.   But, you could still run nmap scan on that IP!

Now you might also see urls to your Moodle ... those are the ones where you check referrer ... and if that is your own server/code, you might need to add a rule that allows that to happen.

Don't think there is a listing of rules just for Moodle out there for you to use ... that would be handy if someone shared that - knowing they could be incorrect and not really fit your situation.

Anyhoo ... IF you see IP traffic like above example and the IP address involved is not one of your 'normal customers' (teachers/students in your Moodle), if you block them at the network level, they won't get to the application level ... ie, your Moodle.

My 2 cents!

'SoS', Ken