I need rules to drop some malicious Apache connections
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 commandat
.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
andiptables-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
. Downloadwww-security-assistant.bash
and make it executable:sudo mkdir /var/www-security-assistant sudo wget https://raw.githubusercontent.com/pa4080/www-security-assistant/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 runwww-security-assistant.bash
without password viasudo
. 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 fileswww-security-assistant.history
andwww-security-assistant.mail
. Run the above command 5 times and review the filesiptables-DROP.list
andiptables-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 stagesecurity2.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 examplez-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 typehttps://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 yourDocumentRoot
(here I'm assuming this place is/var/www/html
):sudo wget https://raw.githubusercontent.com/pa4080/www-security-assistant/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 scriptBotLovin.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 thechain
):# 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 thedeny
action because it will be override by theredirect
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/pa4080/www-security-assistant/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 filemodsecurity-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 betweenREQUEST_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 withid:150
.drop
,deny
(withstatus
) andredirect
actions belong to the disruptive group of actions, they must be in the beginning of the rulechain
(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 haveid
.REMOTE_ADDR
contains the IP address of the request.@ipMatchFromFile
will the filemodsecurity-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 theexec
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 examplesetenv: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. Thehttpd-guardian
tool is designed to defend against denial of service attacks. It uses theblacklist 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/pa4080/www-security-assistant/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/pa4080/www-security-assistant/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
and35
.To get both
httpd-
scripts to work simultaneously editmodsecurity.conf
and pipeSecGuardianLog
to both.To perform a test follow the tips from the above section.