I need rules to drop some malicious Apache connections

Solution 1:

Update: The current answer is completely updated.

According to this discussion I created a GitHub repository named WWW Security Assistant. There is a branch, called ask_ubuntu, dedicated to this answer. All references, previously available here, are removed due to the character limit - they are available on GitHub.

Here are over-viewed few ways, involved into a complete mechanism, how to increase Apache2 security within Ubuntu 16.04.

Table of content:

• WWW Security Assistant Script (WSAS) ► Iptables
• Iptables – Basic Configuration – Save and Restore
• ModEvasive for Apache2
• ModEvasive ► WSAS ► Iptables
• ModSecurity 2.9 for Apache2
• ModSecurity OWASP Core Rule Set 3.x
• ModSecurity Rules Whitelisting
• ModSecurity Rules ► WSAS ► Iptables
• ModSecurity and Apache Log Files
• ModSecurity Log Files ► Fail2Ban ► Iptables
• ModSecurity GuardianLog ► HTTPD Guardian ► WSAS ► Iptables
• ModSecurity GuardianLog ► HTTPD Custom Analyze ► WSAS ► Iptables

In addition let's say it always good to use HTTPS:

• Read HTTPS and Common Apache Security Tips

# WWW Security Assistant Script ► Iptables

Here is presented the script www-security-assistant.bash. It could help you with the handling of the malicious IP addresses. The script has two modes.

Automatic mode

When an external program, as Apache's mod_security, provides a malicious $IP address. In this case, the syntax that invokes the script, should be:

www-security-assistant.bash <ip-address> Guardian
www-security-assistant.bash <ip-address> ModSecurity
www-security-assistant.bash <ip-address> ModEvasive
www-security-assistant.bash <ip-address> a2Analyst

In this mode the script provides two action stages and for every action it will send an email to the administrator(s).

• First stage: for the first few 'transgressions' the source $IP will be banned for a period of time equal to the value of $BAN_TIME. This mode uses the command at.

• Second stage: when the number of the transgressions from certain $IP becomes equal to the value of $LIMIT, this $IP address will be banned permanently through Iptables and will be added to the $BAN_LIST.

Manual mode

This mode accept the following options:

• www-security-assistant.bash <ip-address> --DROP "log notes"

Creates an entry into the file /var/www-security-assistant/iptables-DROP.list and generates a rule as:

    iptables -A GUARDIAN -s $IP -j DROP

• www-security-assistant.bash <ip-address> --DROP-CLEAR "log notes"

Creates an entry into the file /var/www-security-assistant/iptables-DROP-CLEAR.list, remove the certain Iptables rule, removes the $IP from the history and from the $BAN_LIST:

    iptables -D GUARDIAN -s $IP -j DROP

• www-security-assistant.bash <ip-address> --ACCEPT "log notes"

Creates only an entry into the file /var/www-security-assistant/iptables-ACCEPT.list.

• www-security-assistant.bash <ip-address> --ACCEPT-CHAIN "log notes"

Creates an entry into the file /var/www-security-assistant/iptables-ACCEPT.list and generates a rule as:

    iptables -A GUARDIAN -s $IP -j ACCEPT

Dependencies

The script uses iptables-save.sh and the iptables chain GUARDIAN, explained in the next section. It will create and maintain few files within the $WORK_DIR:

• www-security-assistant.history - contains the data for the previous IP's transgressions.
• www-security-assistant.mail - the content of the last email sent by the script.
• iptables-ACCEPT.list; iptables-DROP.list and iptables-DROP-CLEAR.list.

The script needs a minimal configuration to send emails:

sudo apt install s-nail mutt mailutils postfix
sudo dpkg-reconfigure postfix  # For General type: Internet Site
echo 'Test passed.' | mail -s Test-Email [email protected]

If there is any configured HTTPS service its TLS certificate can be used within the Postfix service.

In addition the script uses at: sudo apt install at.

Installation

• Create work directory, let's call it /var/www-security-assistant. Download www-security-assistant.bash and make it executable:

    sudo mkdir /var/www-security-assistant
    sudo wget https://raw.githubusercontent.com/metalevel-tech/wwwsas/ask_ubuntu/www-security-assistant.bash -O /var/www-security-assistant/www-security-assistant.bash
    sudo chmod +x /var/www-security-assistant/www-security-assistant.bash
  

• Make www-security-assistant.bash available as custom command:

    sudo ln -s /var/www-security-assistant/www-security-assistant.bash /usr/local/bin/
  

• Grant permission to www-data to run www-security-assistant.bash without password via sudo. Use the following command to create and edit safely a new file with an additional 'sudoers' rule:

    sudo visudo -f /etc/sudoers.d/www-security-assistant
  

Add the following line inside the file - save the file and exit:

    www-data ALL=(ALL) NOPASSWD: /var/www-security-assistant/www-security-assistant.bash

• Tweak www-security-assistant.bash. Change at least the value of the variable $EMAIL_TO.

Check-up

• Represent yourself as $AGENT and check whether the Automatic MODE works properly:

    www-security-assistant.bash 192.168.1.177 Guardian
  

  Then check your e-mail, type iptables -L GUARDIAN -n, review the files www-security-assistant.history and www-security-assistant.mail. Run the above command 5 times and review the files iptables-DROP.list and iptables-CURRENT.conf.

• Check whether the Manual MODE works properly - add your localhost to the White List:

    www-security-assistant.bash 127.0.0.1 --ACCEPT "Server's localhost IP"
  

Then check the file iptables-ACCEPT.list.

> *The rest part of this tutorial is how to integrate `www-security-assistant` with your system.*
# Iptables – Basic Configuration – Save and Restore

Basic configuration

Please read this manual before adding the following rules.

sudo iptables -F

sudo iptables -I INPUT 1 -i lo -j ACCEPT
sudo iptables -I INPUT 2 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# This rule may lock you out of the system!
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

Before you do the next actions open a new SSH connection and try to login into your system to check whether everything works fine!

Save and Restore

This could be achieved via custom scripts, that will save and restore the iptables coning during system's stop-start (or reboot) process. (If we using UFW to setup Iptables rules this step is not needed.)

printf '#!/bin/sh\n/sbin/iptables-save > /var/www-security-assistant/iptables-CURRENT.conf\nexit 0\n' | sudo tee /var/www-security-assistant/iptables-save.sh
printf '#!/bin/sh\n/sbin/iptables-restore < /var/www-security-assistant/iptables-CURRENT.conf\nexit 0\n' | sudo tee /var/www-security-assistant/iptables-restore.sh
sudo chmod +x /var/www-security-assistant/iptables-restore.sh /var/www-security-assistant/iptables-save.sh

sudo ln -s /var/www-security-assistant/iptables-save.sh /etc/network/if-post-down.d/iptables-save
sudo ln -s /var/www-security-assistant/iptables-restore.sh /etc/network/if-pre-up.d/iptables-restore

Create new chain

Create new chain, called GUARDIAN and insert it as number 3 into the INPUT chain:

sudo iptables -N GUARDIAN
sudo iptables -I INPUT 3 -j GUARDIAN

Check-up

Reboot the system and check the configuration. Please use sudo systemctl reboot (do not use the force option reboot -f). When the system is back online we can check if the newly created chain exists by:

sudo iptables -L GUARDIAN -n

# ModEvasive for Apache2

ModEvasive is an evasive maneuvers module for Apache to provide evasive action in the event of an HTTP DoS or DDoS attack or brute force attack. Read more...

Installation

• Install and enable the module:

    sudo apt install libapache2-mod-evasive
    sudo a2enmod evasive
  

• Create Log Directory and make it accessible for www-data:

    sudo mkdir -p /var/log/apache2_mod_evasive
    sudo chown www-data /var/log/apache2_mod_evasive
  

• Adjust the basic configuration – uncomment and edit certain directives in the configuration file:

    /etc/apache2/mods-enabled/evasive.conf
  

• Restart Apache: sudo systemctl restart apache2.service.

Check-up

• Open a web page from your server and refresh the browser window few times intensively (press F5) - you must get 403 Forbidden error message. Into the log directory, will be generated a new lock file. This file should be deleted for further transgressions detection from this IP address.

# ModEvasive ► WSAS ► Iptables

Here we will configure mod_evasive to talk to iptables through the www-security-assistant.bash, created in the above section.

• Edit /etc/apache2/mods-available/evasive.conf in this way:

    <IfModule mod_evasive20.c>
        DOSHashTableSize    3097
        DOSPageCount        9
        DOSSiteCount        70
        DOSPageInterval     2
        DOSSiteInterval     2
        DOSBlockingPeriod   10
  
        #DOSEmailNotify     [email protected]
        DOSLogDir           "/var/log/apache2_mod_evasive"
        DOSSystemCommand    "sudo /var/www-security-assistant/www-security-assistant.bash %s 'ModEvasive' 'AutoMode' >> /var/www-security-assistant/www-security-assistant.execlog 2>&1"
    </IfModule>
  

• Create log file and Restart Apache:

    sudo touch /var/www-security-assistant/www-security-assistant.execlog && sudo chown www-data /var/www-security-assistant/www-security-assistant.execlog
  

To test this configuration we can simulate DDOS attack via the F5 method, mentioned above, or we can use a commands as ab, hping3, etc.

Attention: Be careful because the iptables rule, used in WSAS, will DROP all new connections from the source $IP, including your SSH connections. It is good to have a backup way to connect to the server during the tests. You can change this rule to work only with the HTTP/HTTPS ports.

# ModSecurity 2.9 for Apache2

ModSecurity is a web application firewall engine that provides very little protection on its own. In order to become useful, ModSecurity must be configured with rules. In order to enable users to take full advantage of ModSecurity out of the box, Trustwave's Spider Labs is providing a free certified rule set... Read more...

Installation

• Install and enable the module:

    sudo apt install libapache2-mod-security2
    sudo a2enmod security2
  

• Create configuration file:

  sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Read and edit /etc/modsecurity/modsecurity.conf carefully! Add or change at least the following directives:

    # -- Rule engine initialization ----------------------------------------------
    SecRuleEngine On

    # -- Debug log configuration -------------------------------------------------
    SecDebugLogLevel 2
    SecDebugLog "/var/log/apache2_mod_security/modsec_debug.log"

    # -- Audit log configuration -------------------------------------------------
    SecAuditLog "/var/log/apache2_mod_security/modsec_audit.log"

    # -- Guardian log configuration -------------------------------------------------
    SecGuardianLog /var/log/apache2_mod_security/modsec_guardian.log

• The file /etc/apache2/mods-enabled/security2.conf involves /etc/modsecurity/modsecurity.conf into Apache's configuration. At this stage security2.conf shall look as this:

    <IfModule security2_module>
        SecDataDir /var/cache/modsecurity
        IncludeOptional /etc/modsecurity/*.conf
    </IfModule>
  

• Create Log Directory:

    sudo mkdir -p /var/log/apache2_mod_security
  

• Setup log rotation. First create config file:

    sudo cp /etc/logrotate.d/apache2 /etc/logrotate.d/apache2-modsec
  

Then edit the new file in this way:

    /var/log/apache2_mod_security/*.log { … }

• Restart Apache.

Check-up

• Create an additional configuration file in /etc/modsecurity, call it for example z-customrules.conf, and add the following rule as its content:

    # Directory traversal attacks
    SecRule REQUEST_URI "../" "t:urlDecodeUni, deny, log, id:109"
  

Restart the server: sudo systemctl restart apache2.service. Open your browser and type https://example.com/?abc=../. The result will be: 403 Forbidden. Check the log files in /var/log/apache2_mod_security for more details.

• To make the things more fun place the script issues.php in an appropriate location within your DocumentRoot (here I'm assuming this place is /var/www/html):

    sudo wget https://raw.githubusercontent.com/metalevel-tech/wwwsas/ask_ubuntu/appendix/var/www/html/issues.php -O /var/www/html/issues.php
  

Then modify the above rule in the following way:

    # Directory traversal attacks with redirection (or use URL instead of URI: redirect:'https://example.com/issues.php')
    SecRule REQUEST_URI "../" "t:urlDecodeUni, deny, log, id:109, redirect:'/issues.php'"

Restart Apache, then open your browser and type https://example.com/?abc=../ ;-) The idea is borrowed from the SE's script BotLovin.cs.

• Edit /etc/modsecurity/z-customrules.conf once again and comment (disable) the rule - this was just test example and it is covered by OWASP CRS, described in the next section.

• Here is another example where we will redirect all wp-admin page requests, but except these from certain IP addresses (note the chain):

    # Block wp-admin access
    SecRule REQUEST_URI "^/wp-admin" "id:108, log, deny, status:403, t:lowercase, chain, redirect:'/issues.php'"
        SecRule REMOTE_ADDR "!@ipMatch 192.168.1.11,99.77.66.12"
  

Here we have two disruptive actions: (1) deny, status:403 and (2) redirect:'/issues.php'. Actually we do not need of the deny action because it will be override by the redirect action.

# ModSecurity OWASP Core Rule Set 3.x

In Ubuntu 16.04 you can install CSR 2.x: apt install modsecurity-crs. Here we will install CSR 3.x, detailed instructions are provided within the Installation manual (git is required).

Installation

• Clone CSR in the folder /usr/share/modsecurity-crs.3:

    sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs /usr/share/modsecurity-crs.3
  

• Upgrade and auto renew the GeoIP database. (The GeoIP DB is no longer included with the CRS. Instead you are advised to download it regularly.) The script util/upgrade.py brings this functionality. You can use it as follows in cron - sudo crontab -e:

    0 2 * * * /usr/share/modsecurity-crs.3/util/upgrade.py --geoip --crs --cron >> /var/log/apache2_mod_security/owasp-crs-upgrade.log 2>&1
  

• Create configuration files:

    sudo cp /usr/share/modsecurity-crs.3/crs-setup.conf{.example,}
    sudo cp /usr/share/modsecurity-crs.3/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf{.example,}
    sudo cp /usr/share/modsecurity-crs.3/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf{.example,}
  

  Read and edit these files carefully! Uncomment at least SecGeoLookupDB directive:

    SecGeoLookupDB util/geo-location/GeoIP.dat
  

• Apply the Apache's configuration. Edit /etc/apache2/mods-available/security2.conf in this way:

    <IfModule security2_module>
        SecDataDir /var/cache/modsecurity
        IncludeOptional /etc/modsecurity/*.conf
        IncludeOptional /usr/share/modsecurity-crs.3/crs-setup.conf
        IncludeOptional /usr/share/modsecurity-crs.3/rules/*.conf
    </IfModule>
  

Save the file and then restart Apache.

# ModSecurity Rules Whitelisting

Whitelisting of ModSecurity Rules could be done via the following ModSec directives, that can be used system wide or within virtual host's configuration, also globally, for specific directories or location matches:

SecRuleRemoveById
SecRuleRemoveByMsg
SecRuleRemoveByTag
SecRuleUpdateTargetById
SecRuleUpdateTargetByMsg
SecRuleUpdateTargetByTag
SecRuleUpdateActionById

Disable mod_security2 for PhpMyAdmin. Change /etc/phpmyadmin/apache.conf in this way:

<Directory /usr/share/phpmyadmin>
    <IfModule security2_module>
        SecRuleEngine Off
    </IfModule>
</Directory>

Disable specific rules for certain directory:

<Directory /var/www/html>
    <IfModule security2_module>
        SecRuleRemoveById 973301
    </IfModule>
</Directory>

Disable rules globally. For this purpose we must add our directives somewhere in Apache's configuration files: /etc/modsecurity/z-customrules.conf is a good place.

• Disable rules within the entire Apache's configuration:

    SecRuleRemoveById 973301 950907
  

• Whitelist an IP address so it can pass through ModSecurity:

    SecRule REMOTE_ADDR "@ipMatch 192.168.110.1" "phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off"
  

• Disable rules within Directory match:

    <Directory /var/www/mediawiki/core>
        SecRuleRemoveById 973301 950907
    </Directory>
  

• Update rule's action by its ID within Location match:

    <LocationMatch "/index.php.*">
        SecRuleUpdateActionById 973301 "pass"
        SecRuleUpdateActionById 950907 "pass"
    </LocationMatch>
  

In the above examples we assume that 973301 and 950907 are rule IDs that obstruct the normal work of our web apps. We can find rules as these by an analyze of modsec_audit.log.

# ModSecurity Rules ► WSAS ► Iptables

Here are given few more examples how to create custom SecRules, also how we can call WWW Security Assistant Script (WSAS) through them.

Initial Setup

We need of an additional startup scrip - modsecurity-assistant.sh. The reason is that, ModSecurity's exec action has too simple and limited syntax.

sudo wget https://raw.githubusercontent.com/metalevel-tech/wwwsas/ask_ubuntu/modsecurity-assistant.sh -O /var/www-security-assistant/modsecurity-assistant.sh
sudo chmod +x /var/www-security-assistant/modsecurity-assistant.sh

If you look inside the script you will see few variables that are exportd by ModSecurity. These are: $REQUEST_URI, $ARGS, $SERVER_NAME, $REMOTE_ADDR, $REMOTE_HOST and $UNIQUE_ID. The other variables are explained inside the script.

Create custom rule and call our scripts through it

First let's create a rule that will execute modsecurity-assistant.sh (and call www-security-assistant.bash) when the request URI contains a word that is included in our blacklist. Open /etc/modsecurity/z-customrules.conf and add the following lines to the bottom:

# REQUEST_URI words blacklist
#
SecRule REQUEST_URI "@pmFromFile /var/www-security-assistant/modsecurity-uri-black.list" \
    "id:150, log, t:lowercase, chain, \
    drop, deny, status:403, redirect:'/issues.php'"
    SecRule REMOTE_ADDR "!@ipMatchFromFile /var/www-security-assistant/modsecurity-ip-white.list" \
        "setenv:REMOTE_HOST=%{REMOTE_HOST}, \
         setenv:ARGS=%{ARGS}, \
         exec:/var/www-security-assistant/modsecurity-assistant.sh"

• REQUEST_URI - this variable contains the full URI from the current request. The rule culd be more wide: SecRule REQUEST_URI|ARGS|REQUEST_BODY ...

• @pmFromFile will read the file modsecurity-uri-black.list that contains list of phrases, where each specific phrase or word is placed into a new line. You can collect interesting words and phrases from the log files. If there is a particular match between REQUEST_URI and our list of patterns the rule will be applied. The file could be empty, but you must create (touch) it.

• The log action will create log entries in the log files for this rule with id:150.

• drop, deny (with status) and redirect actions belong to the disruptive group of actions, they must be in the beginning of the rule chain (if there is a chain). The second action will override the first one and the third will override the second, so you must choice which you want to be performed and can delete the others.

• chain action will call the next rule of of the chain, note that second rule, doesn't have id.

• REMOTE_ADDR contains the IP address of the request.

• @ipMatchFromFile will the file modsecurity-ip-white.list that contains white-list of IP addresses, separated at new lines. CIDR entries are also acceptable. Because the disruptive action is always located in the leading rule of the chain it will be applied, but when certain IP is in this white list the exec action will not be applied. The file could be empty, but you must create (touch) it.

• exec action will call our external script. This action isn't disruptive and will be executed when the current rule return true. When this action is applies the remote IP will be processed through our scripts.

• setenv this action will export certain internal variables =%{...} as envvars, exported names can be different from the internals. Some variables must be exported manually, some other are exported automatically - probably it is a small bug (in some cases the manual export with the same names, for example setenv:REQUEST_URI=%{REQUEST_URI}, will cause a blank value of the exported variable).

Check-up

Let's assume you do not have Joomla on your server, edit the file modsecurity-uri-black.list and add a line with content /joomla. Then type in your browser https://exemple.com/joomla. You should be redirected and blocked through Iptables. Clear the records sudo www-security-assistant.bash <your-ip> --DROP-CLEAR 'some note', add your IP in modsecurity-ip-white.list and do the exercise again. Now you should be redirected, but not blocked.

Connect our scripts with OWASP Core Rule Set 3.x

To do that we will update the default action of the Anomaly Mode Rules (949110 and 959100). For this purpose edit the file /usr/share/modsecurity-crs.3/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf and add the next lines to the bottom:

# -- Anomaly Mode - Update actions by ID -----
#

SecRuleUpdateActionById 949110 "t:none, drop, deny, status:403, redirect:'/issues.php', \
     setenv:REMOTE_HOST=%{REMOTE_HOST}, setenv:ARGS=%{ARGS}, \
     exec:/var/www-security-assistant/modsecurity-assistant.sh"

SecRuleUpdateActionById 959100 "t:none, drop, deny, status:403, redirect:'/issues.php', \
     setenv:REMOTE_HOST=%{REMOTE_HOST}, setenv:ARGS=%{ARGS}, \
     exec:/var/www-security-assistant/modsecurity-assistant.sh"

# -- Anomaly Mode - Whitelist some URI and IP addresses -----
#

SecRule REQUEST_URI "^/wp-admin/admin-ajax.php*|^/index\.php\?title=.*&action=(submit|raw&ctype=text/javascript|raw&ctype=text/css)$" \
    "id:'999010', t:none, phase:1, pass, \
     ctl:ruleRemoveById=949110, \
     ctl:ruleRemoveById=959100"

SecRule REMOTE_ADDR "@ipMatchFromFile /var/www-security-assistant/modsecurity-ip-white.list" \
    "id:'999020', t:none, phase:1, pass, \
     ctl:ruleRemoveById=949110, \
     ctl:ruleRemoveById=959100"

Check-up

Don't forget to restart (or reload) Apache to apply the configuration changes. Don't forget to clear the records periodically during the tests, otherwise you can be blocked permanently :-)

Simulate directory traversal attack:

https://example.com/?abc=../../../                         # This should be redirected and blocked
https://example.com/wp-admin/admin-ajax.php?abc=../../../  # This should pass because of the whitelist rule

Simulate SQL Injection attack:

https://example.com/?username=1'%20or%20'1'%20=%20'1&password=1'%20or%20'1'%20=%20'1
https://example.com/index.php?username=1'%20or%20'1'%20=%20'1'))/*&password=foo

# ModSecurity and Apache Log Files

The Apache web server can be configured to give the server administrator important information about how it is functioning... The main avenue for providing feedback to the administrator is through the use of log files. Read more...

ModSecurity has powerful logging mechanism. By the directive SecGuardianLog it provides a log feed specially designed to work with external scripts.

Currently the only tool known to work with guardian logging is httpd-guardian, which is part of the Apache httpd tools project. The httpd-guardian tool is designed to defend against denial of service attacks. It uses the blacklist tool to interact with an iptables-based... firewall, dynamically blacklisting the offending IP addresses. Read more...

# ModSecurity Log Files ► Fail2Ban ► Iptables

It is possible to setup Fail2Ban for data parsing of Apache's log files. modsec_audit.log is probably the best choice, but see also the sections where we talk about of SecGuardianLog.

Take care that SecAuditLogRelevantStatus in /etc/modsecurity/modsecurity.conf is commented. Otherwise everyone that receives a 404 error page would be blocked by fail2ban.

SecAuditEngine RelevantOnly
#SecAuditLogRelevantStatus "^(?:5|4(?!04))"

Currently Fail2Ban is not implemented in any way in this project.

# ModSecGuardianLog ► HTTPD-Guardian ► WSAS ► Iptables

httpd-guardian - detect DoS attacks by monitoring requests Apache Security, Copyright (C) 2005 Ivan Ristic - is designed to monitor all web server requests through the piped logging mechanism. It keeps track of the number of requests sent from each IP address... httpd-guardian can either emit a warning or execute a script to block the IP address...

This script can be used with Apache2 logging mechanism, or with ModSecurity (better).

Installation and Setup within the Current Circumstances

Download httpd-guardian and make it executable:

sudo wget https://raw.githubusercontent.com/metalevel-tech/wwwsas/ask_ubuntu/httpd-guardian.pl -O /var/www-security-assistant/httpd-guardian.pl
sudo chmod +x /var/www-security-assistant/httpd-guardian.pl

Read lines 98-119 to see how the script is connected with our WSAS script.

Apply the following change within Apache's configuration (/etc/modsecurity/modsecurity.conf), then restart it:

#SecGuardianLog /var/log/apache2_mod_security/modsec_guardian.log
SecGuardianLog "|/var/www-security-assistant/httpd-guardian.pl"

Check-up

To test the script disable ModEvasive (sudo a2dismod evasive don't forget to enable it later) and restart Apache. Then tail the exec log:

tail -F /var/www-security-assistant/www-security-assistant.execlog

And from another instance perform DoS attack, for example use ab in this way:

for i in {1..20}; do (ab -n 200 -c 10 https://example.com/ &); done

# ModSecGuardianLog ► Custom Analyze ► WSAS ► Iptables

Here is presented a simple script, called httpd-custom-analyze.bash, that isn't something special but could be a nice example. Its features are described within the script's body.

Installation and Setup

Download httpd-custom-analyze.bash and make it executable:

sudo wget https://raw.githubusercontent.com/metalevel-tech/wwwsas/ask_ubuntu/httpd-custom-analyze.bash -O /var/www-security-assistant/httpd-custom-analyze.bash
sudo chmod +x /var/www-security-assistant/httpd-custom-analyze.bash

Apply the following change within Apache's configuration (/etc/modsecurity/modsecurity.conf) and restart it:

#SecGuardianLog /var/log/apache2_mod_security/modsec_guardian.log
#SecGuardianLog "|/var/www-security-assistant/httpd-guardian.pl"
SecGuardianLog "|/var/www-security-assistant/httpd-custom-analyze.bash"

• The script will call WSAS when the threshold is reached - read line 86 and 35.

• To get both httpd- scripts to work simultaneously edit modsecurity.conf and pipe SecGuardianLog to both.

• To perform a test follow the tips from the above section.

Solution 2:

I realize pa4080 gave a detailed and probably very helpful response for taking care of this all on your own. While taking care of problems on your own may feel good, this can also take a lot of time.

1. Become familiar with Cloudflare as they provide free DDoS protection.
2. If you currently only use Apache, consider learning how NGINX works to balance your load. NGINX is great for load balancing Apache as showcased here and here.
3. Review Apache's tips for security on their docs.