Mise à jour: la réponse actuelle est complètement mise à jour.
Selon cette discussion, j'ai créé un référentiel GitHub nommé WWW Security Assistant . Il y a une branche, appelée ask_ubuntu
, dédiée à cette réponse. Toutes les références, précédemment disponibles ici , sont supprimées en raison de la limite de caractères - elles sont disponibles sur GitHub.
Voici quelques façons, impliquées dans un mécanisme complet, comment augmenter la sécurité d'Apache2 dans Ubuntu 16.04.
Table des matières:
- Script de l'assistant de sécurité WWW (WSAS) ► Iptables
- Iptables - Configuration de base - Enregistrer et restaurer
- ModEvasive pour Apache2
- ModEvasive ► WSAS ► Iptables
- ModSecurity 2.9 pour Apache2
- ModSecurity OWASP Core Rule Set 3.x
- Liste blanche des règles ModSecurity
- Règles de ModSecurity ► WSAS ► Iptables
- Fichiers journaux ModSecurity et Apache
- Fichiers journaux ModSecurity ► Fail2Ban ► Iptables
- ModSecurity GuardianLog ► HTTPD Guardian ► WSAS ► Iptables
- ModSecurity GuardianLog ► Analyse personnalisée HTTPD ► WSAS ► Iptables
De plus, disons qu'il est toujours bon d'utiliser HTTPS:
Script de l'assistant de sécurité WWW ► Iptables
Voici le script présenté www-security-assistant.bash
. Cela pourrait vous aider à gérer les adresses IP malveillantes. Le script a deux modes.
Mode automatique
Lorsqu'un programme externe, comme Apache mod_security
, fournit une $IP
adresse malveillante . Dans ce cas, la syntaxe qui appelle le script doit être:
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
Dans ce mode, le script propose deux étapes d'action et pour chaque action, il enverra un e-mail aux administrateurs.
Première étape: pour les premières «transgressions», la source $IP
sera interdite pendant une durée égale à la valeur de $BAN_TIME
. Ce mode utilise la commande at
.
Deuxième étape: lorsque le nombre de transgressions de certaines $IP
devient égal à la valeur de $LIMIT
, cette $IP
adresse sera définitivement interdite via Iptables et sera ajoutée à la $BAN_LIST
.
Mode manuel
Ce mode accepte les options suivantes:
www-security-assistant.bash <ip-address>
--DROP "log notes"
Crée une entrée dans le fichier /var/www-security-assistant/iptables-DROP.list
et génère une règle comme:
iptables -A GUARDIAN -s $IP -j DROP
www-security-assistant.bash <ip-address>
--DROP-CLEAR "log notes"
Crée une entrée dans le fichier /var/www-security-assistant/iptables-DROP-CLEAR.list
, supprime la certaine règle Iptables, supprime le $IP
de l'historique et du $BAN_LIST
:
iptables -D GUARDIAN -s $IP -j DROP
www-security-assistant.bash <ip-address>
--ACCEPT "log notes"
Crée uniquement une entrée dans le fichier /var/www-security-assistant/iptables-ACCEPT.list
.
www-security-assistant.bash <ip-address>
--ACCEPT-CHAIN "log notes"
Crée une entrée dans le fichier /var/www-security-assistant/iptables-ACCEPT.list
et génère une règle comme:
iptables -A GUARDIAN -s $IP -j ACCEPT
Dépendances
Le script utilise iptables-save.sh
et la iptables
chaîne GUARDIAN
, expliqués dans la section suivante. Il créera et maintiendra quelques fichiers dans $WORK_DIR
:
www-security-assistant.history
- contient les données des transgressions de l'IP précédente.
www-security-assistant.mail
- le contenu du dernier email envoyé par le script.
iptables-ACCEPT.list
; iptables-DROP.list
et iptables-DROP-CLEAR.list
.
Le script a besoin d'une configuration minimale pour envoyer des e-mails:
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@example.com
S'il existe un service HTTPS configuré, son certificat TLS peut être utilisé dans le service Postfix.
En outre , le script utilise at
: sudo apt install at
.
Installation
Créez un répertoire de travail, appelons-le /var/www-security-assistant
. Téléchargez www-security-assistant.bash
et rendez-le exécutable:
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
Rendre www-security-assistant.bash
disponible en tant que commande personnalisée:
sudo ln -s /var/www-security-assistant/www-security-assistant.bash /usr/local/bin/
Accordez l'autorisation d' www-data
exécuter www-security-assistant.bash
sans mot de passe via sudo
. Utilisez la commande suivante pour créer et modifier en toute sécurité un nouveau fichier avec une sudoers
règle ' ' supplémentaire :
sudo visudo -f /etc/sudoers.d/www-security-assistant
Ajoutez la ligne suivante à l'intérieur du fichier - enregistrez le fichier et quittez:
www-data ALL=(ALL) NOPASSWD: /var/www-security-assistant/www-security-assistant.bash
Tweak www-security-assistant.bash
. Modifiez au moins la valeur de la variable $EMAIL_TO
.
Vérification
Représentez-vous en tant que $AGENT
et vérifiez si le MODE automatique fonctionne correctement:
www-security-assistant.bash 192.168.1.177 Guardian
Ensuite, vérifiez votre e-mail, tapez iptables -L GUARDIAN -n
, passez en revue les fichiers www-security-assistant.history
et www-security-assistant.mail
. Exécutez la commande ci-dessus 5 fois et examinez les fichiers iptables-DROP.list
et iptables-CURRENT.conf
.
Vérifiez si le MODE Manuel fonctionne correctement - ajoutez votre hôte local à la Liste Blanche:
www-security-assistant.bash 127.0.0.1 --ACCEPT "Server's localhost IP"
Vérifiez ensuite le fichier iptables-ACCEPT.list
.
La partie restante de ce tutoriel est de savoir comment intégrer www-security-assistant
avec votre système.
Iptables - Configuration de base - Enregistrer et restaurer
Configuration de base
Veuillez lire ce manuel avant d'ajouter les règles suivantes.
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
Avant de faire les actions suivantes, ouvrez une nouvelle connexion SSH et essayez de vous connecter à votre système pour vérifier si tout fonctionne bien!
Enregistrer et restaurer
Cela pourrait être réalisé via des scripts personnalisés, qui enregistreront et restaureront le iptables
cône pendant le processus d'arrêt-démarrage (ou de redémarrage) du système. (Si nous utilisons UFW pour configurer les règles Iptables, cette étape n'est pas nécessaire.)
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
Créer une nouvelle chaîne
Créez une nouvelle chaîne, appelée GUARDIAN
et insérez-la sous le numéro 3 dans la INPUT
chaîne:
sudo iptables -N GUARDIAN
sudo iptables -I INPUT 3 -j GUARDIAN
Vérification
Redémarrez le système et vérifiez la configuration. Veuillez utiliser sudo systemctl reboot
(n'utilisez pas l'option de force reboot -f
). Lorsque le système est de nouveau en ligne, nous pouvons vérifier si la chaîne nouvellement créée existe en:
sudo iptables -L GUARDIAN -n
ModEvasive pour Apache2
ModEvasive est un module de manœuvres évasives pour Apache pour fournir une action évasive en cas d'attaque HTTP DoS ou DDoS ou d'attaque par force brute. Lire la suite...
Installation
Installez et activez le module:
sudo apt install libapache2-mod-evasive
sudo a2enmod evasive
Créez un répertoire de journaux et rendez-le accessible pour www-data
:
sudo mkdir -p /var/log/apache2_mod_evasive
sudo chown www-data /var/log/apache2_mod_evasive
Ajustez la configuration de base - décommentez et éditez certaines directives dans le fichier de configuration:
/etc/apache2/mods-enabled/evasive.conf
Redémarrez Apache: sudo systemctl restart apache2.service
.
Vérification
- Ouvrez une page Web à partir de votre serveur et actualisez la fenêtre du navigateur plusieurs fois de manière intensive (appuyez sur
F5
) - vous devez obtenir le message d'erreur 403 Forbidden . Dans le répertoire des journaux, sera généré un nouveau fichier de verrouillage. Ce fichier doit être supprimé pour une détection ultérieure des transgressions à partir de cette adresse IP.
ModEvasive ► WSAS ► Iptables
Ici, nous allons configurer mod_evasive
pour parler à iptables
travers le www-security-assistant.bash
, créé dans la section ci-dessus.
Modifiez /etc/apache2/mods-available/evasive.conf
de cette manière:
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 9
DOSSiteCount 70
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 10
#DOSEmailNotify your@email.foo
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>
Créez un fichier journal et redémarrez Apache:
sudo touch /var/www-security-assistant/www-security-assistant.execlog && sudo chown www-data /var/www-security-assistant/www-security-assistant.execlog
Pour tester cette configuration , nous pouvons simuler une attaque DDOS par la F5
méthode, mentionné ci - dessus, ou on peut utiliser une commande comme ab
, hping3
, etc.
Attention: soyez prudent car la iptables
règle, utilisée dans WSAS, supprimera toutes les nouvelles connexions de la source $IP
, y compris vos connexions SSH. Il est bon d'avoir un moyen de sauvegarde pour se connecter au serveur pendant les tests. Vous pouvez modifier cette règle pour qu'elle fonctionne uniquement avec les ports HTTP / HTTPS.
ModSecurity 2.9 pour Apache2
ModSecurity est un moteur de pare-feu d'application Web qui offre très peu de protection à lui seul. Pour devenir utile, ModSecurity doit être configuré avec des règles. Afin de permettre aux utilisateurs de tirer pleinement parti de ModSecurity dès la sortie de l'emballage, Trustwave's Spider Labs fournit un ensemble de règles certifié gratuit ... En savoir plus ...
Installation
Installez et activez le module:
sudo apt install libapache2-mod-security2
sudo a2enmod security2
Créer un fichier de configuration:
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
Lisez et modifiez /etc/modsecurity/modsecurity.conf
attentivement! Ajoutez ou modifiez au moins les directives suivantes:
# -- 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
Le fichier /etc/apache2/mods-enabled/security2.conf
implique /etc/modsecurity/modsecurity.conf
dans la configuration d'Apache. À ce stade security2.conf
doit ressembler à ceci:
<IfModule security2_module>
SecDataDir /var/cache/modsecurity
IncludeOptional /etc/modsecurity/*.conf
</IfModule>
Créer un répertoire de journaux:
sudo mkdir -p /var/log/apache2_mod_security
Configurer la rotation des journaux. Créez d'abord le fichier de configuration:
sudo cp /etc/logrotate.d/apache2 /etc/logrotate.d/apache2-modsec
Modifiez ensuite le nouveau fichier de cette manière:
/var/log/apache2_mod_security/*.log { … }
Redémarrez Apache.
Vérification
Créez un fichier de configuration supplémentaire dans /etc/modsecurity
, appelez-le par exemple z-customrules.conf
et ajoutez la règle suivante comme contenu:
# Directory traversal attacks
SecRule REQUEST_URI "../" "t:urlDecodeUni, deny, log, id:109"
Redémarrez le serveur: sudo systemctl restart apache2.service
. Ouvrez votre navigateur et tapez https://example.com/?abc=../
. Le résultat sera de: 403 Interdit . Consultez les fichiers journaux /var/log/apache2_mod_security
pour plus de détails.
Pour rendre les choses plus amusantes, placez le script issues.php
dans un endroit approprié dans votre DocumentRoot
(ici, je suppose que cet endroit est /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
Modifiez ensuite la règle ci-dessus de la manière suivante:
# 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'"
Redémarrez Apache, puis ouvrez votre navigateur et tapez https://example.com/?abc=../
;-) L'idée est empruntée au script du SE BotLovin.cs
.
Modifiez /etc/modsecurity/z-customrules.conf
à nouveau et commentez (désactivez) la règle - ce n'était qu'un exemple de test et il est couvert par OWASP CRS, décrit dans la section suivante.
Voici un autre exemple où nous redirigerons toutes les wp-admin
demandes de page, mais à l'exception de celles provenant de certaines adresses IP (notez le 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"
Ici, nous avons deux actions perturbatrices: (1) deny, status:403
et (2) redirect:'/issues.php'
. En fait, nous n'avons pas besoin de l' deny
action car elle sera remplacée par l' redirect
action.
ModSecurity OWASP Core Rule Set 3.x
Dans Ubuntu 16.04 , vous pouvez installer 2.x CSR: apt install modsecurity-crs
. Ici, nous allons installer CSR 3.x , des instructions détaillées sont fournies dans le manuel d'installation ( git
requis).
Installation
Clonez CSR dans le dossier /usr/share/modsecurity-crs.3
:
sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs /usr/share/modsecurity-crs.3
Mettez à niveau et renouvelez automatiquement la base de données GeoIP. (La base de données GeoIP n'est plus incluse avec le CRS. Au lieu de cela, il est conseillé de la télécharger régulièrement.) Le script util/upgrade.py
apporte cette fonctionnalité. Vous pouvez l'utiliser comme suit dans 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
Créez des fichiers de configuration:
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,}
Lisez et modifiez attentivement ces fichiers! Décommentez au moins la SecGeoLookupDB
directive:
SecGeoLookupDB util/geo-location/GeoIP.dat
Appliquez la configuration d'Apache. Modifiez /etc/apache2/mods-available/security2.conf
de cette manière:
<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>
Enregistrez le fichier, puis redémarrez Apache.
Liste blanche des règles ModSecurity
La liste blanche des règles ModSecurity peut être effectuée via les directives ModSec suivantes, qui peuvent être utilisées à l'échelle du système ou dans la configuration de l'hôte virtuel, également à l'échelle mondiale, pour des répertoires spécifiques ou des correspondances d'emplacement:
SecRuleRemoveById
SecRuleRemoveByMsg
SecRuleRemoveByTag
SecRuleUpdateTargetById
SecRuleUpdateTargetByMsg
SecRuleUpdateTargetByTag
SecRuleUpdateActionById
Désactivez mod_security2
pour PhpMyAdmin. Changez /etc/phpmyadmin/apache.conf
de cette façon:
<Directory /usr/share/phpmyadmin>
<IfModule security2_module>
SecRuleEngine Off
</IfModule>
</Directory>
Désactivez des règles spécifiques pour certains répertoires:
<Directory /var/www/html>
<IfModule security2_module>
SecRuleRemoveById 973301
</IfModule>
</Directory>
Désactivez les règles globalement. Pour cela, nous devons ajouter nos directives quelque part dans les fichiers de configuration d'Apache: /etc/modsecurity/z-customrules.conf
c'est un bon endroit.
Désactivez les règles dans l'ensemble de la configuration d'Apache:
SecRuleRemoveById 973301 950907
Mettez une adresse IP en liste blanche afin qu'elle puisse passer par ModSecurity:
SecRule REMOTE_ADDR "@ipMatch 192.168.110.1" "phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off"
Désactivez les règles dans la correspondance d'annuaire:
<Directory /var/www/mediawiki/core>
SecRuleRemoveById 973301 950907
</Directory>
Mettre à jour l'action de la règle par son ID dans la correspondance d'emplacement:
<LocationMatch "/index.php.*">
SecRuleUpdateActionById 973301 "pass"
SecRuleUpdateActionById 950907 "pass"
</LocationMatch>
Dans les exemples ci - dessus , nous supposons que 973301
et 950907
les identifiants des règles qui entravent le travail normal de nos applications Web. Nous pouvons trouver des règles comme celles-ci par une analyse de modsec_audit.log
.
Règles de ModSecurity ► WSAS ► Iptables
Voici quelques exemples supplémentaires sur la façon de créer des règles personnalisées, ainsi que sur la façon dont nous pouvons appeler le script d'assistant de sécurité WWW (WSAS) à travers eux.
La configuration initiale
Nous avons besoin d'un script de démarrage supplémentaire - modsecurity-assistant.sh
. La raison en est que l' exec
action de ModSecurity a une syntaxe trop simple et limitée.
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
Si vous regardez à l'intérieur du script, vous verrez quelques variables exportées par ModSecurity. Ce sont: $REQUEST_URI
, $ARGS
, $SERVER_NAME
, $REMOTE_ADDR
, $REMOTE_HOST
et $UNIQUE_ID
. Les autres variables sont expliquées dans le script.
Créez une règle personnalisée et appelez nos scripts à travers elle
Créons d'abord une règle qui s'exécutera modsecurity-assistant.sh
(et appellera www-security-assistant.bash
) lorsque l'URI de la demande contient un mot qui est inclus dans notre liste noire. Ouvrez /etc/modsecurity/z-customrules.conf
et ajoutez les lignes suivantes en bas:
# 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
- cette variable contient l'URI complet de la demande en cours. La règle pourrait être plus large:SecRule REQUEST_URI|ARGS|REQUEST_BODY ...
@pmFromFile
lira le fichier modsecurity-uri-black.list
qui contient la liste des phrases, où chaque phrase ou mot spécifique est placé dans une nouvelle ligne. Vous pouvez collecter des mots et des phrases intéressants à partir des fichiers journaux. S'il y a une correspondance particulière entre REQUEST_URI
et notre liste de modèles, la règle sera appliquée. Le fichier peut être vide, mais vous devez le créer ( touch
).
L' log
action créera des entrées de journal dans les fichiers journaux pour cette règle avec id:150
.
drop
, deny
(avec status
) et les redirect
actions appartiennent au groupe perturbateur d'actions, elles doivent être au début de la règle chain
(s'il y a une chaîne). La deuxième action remplacera la première et la troisième remplacera la seconde, vous devez donc choisir celle que vous souhaitez effectuer et pouvez supprimer les autres.
chain
l'action appellera la prochaine règle de la chaîne, notez que la deuxième règle, n'a pas id
.
REMOTE_ADDR
contient l'adresse IP de la demande.
@ipMatchFromFile
sera le fichier modsecurity-ip-white.list
qui contient la liste blanche des adresses IP, séparées à de nouvelles lignes. Les entrées CIDR sont également acceptables. Étant donné que l' action perturbatrice est toujours située dans la règle de tête de la chaîne, elle sera appliquée, mais lorsque certaines IP figurent dans cette liste blanche, l' exec
action ne sera pas appliquée. Le fichier peut être vide, mais vous devez le créer ( touch
).
exec
l'action appellera notre script externe. Cette action n'est pas perturbatrice et sera exécutée lorsque la règle actuelle retournera true. Lorsque cette action est appliquée, l'adresse IP distante sera traitée via nos scripts.
setenv
cette action exportera certaines variables internes en =%{...}
tant qu'envvars, les noms exportés peuvent être différents des internes. Certaines variables doivent être exportées manuellement, d'autres sont exportées automatiquement - il s'agit probablement d'un petit bogue (dans certains cas, l'exportation manuelle avec les mêmes noms, par exemple setenv:REQUEST_URI=%{REQUEST_URI}
, provoquera une valeur vide de la variable exportée).
Vérification
Supposons que vous ne disposez pas de Joomla sur votre serveur, modifiez le fichier modsecurity-uri-black.list
et ajoutez une ligne avec du contenu /joomla
. Tapez ensuite dans votre navigateur https://exemple.com/joomla
. Vous devez être redirigé et bloqué via Iptables. Effacez les enregistrements sudo www-security-assistant.bash <your-ip> --DROP-CLEAR 'some note'
, ajoutez votre adresse IP modsecurity-ip-white.list
et recommencez l'exercice. Vous devez maintenant être redirigé, mais pas bloqué.
Connectez nos scripts avec OWASP Core Rule Set 3.x
Pour ce faire, nous mettrons à jour l'action par défaut des règles de mode d'anomalie (949110 et 959100). Pour cela, éditez le fichier /usr/share/modsecurity-crs.3/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
et ajoutez les lignes suivantes en bas:
# -- 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"
Vérification
N'oubliez pas de redémarrer (ou recharger) Apache pour appliquer les modifications de configuration. N'oubliez pas d'effacer les enregistrements périodiquement pendant les tests, sinon vous pouvez être bloqué définitivement :-)
Simuler une attaque de traversée de répertoire:
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
Simuler une attaque par injection SQL:
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
Fichiers journaux ModSecurity et Apache
Le serveur Web Apache peut être configuré pour donner à l'administrateur du serveur des informations importantes sur son fonctionnement ... Le principal moyen de fournir des commentaires à l'administrateur est l'utilisation de fichiers journaux. Lire la suite...
ModSecurity possède un puissant mécanisme de journalisation. Par la directive, SecGuardianLog
il fournit un flux de journaux spécialement conçu pour fonctionner avec des scripts externes.
Actuellement, le seul outil connu pour fonctionner avec la journalisation du gardien est
httpd-guardian
, qui fait partie du projet d'outils Apache httpd . L' httpd-guardian
outil est conçu pour se défendre contre les attaques par déni de service. Il utilise le blacklist tool
pour interagir avec un pare-feu basé sur iptables, en créant une liste noire dynamique des adresses IP incriminées. Lire la suite...
Fichiers journaux ModSecurity ► Fail2Ban ► Iptables
Il est possible de configurer Fail2Ban pour l'analyse des données des fichiers journaux d'Apache. modsec_audit.log
est probablement le meilleur choix, mais voir aussi les sections dont nous parlons SecGuardianLog
.
Faites attention que SecAuditLogRelevantStatus
dans /etc/modsecurity/modsecurity.conf
est commenté. Sinon, tous ceux qui reçoivent une page d'erreur 404 seraient bloqués par fail2ban.
SecAuditEngine RelevantOnly
#SecAuditLogRelevantStatus "^(?:5|4(?!04))"
Actuellement, Fail2Ban n'est implémenté en aucune façon dans ce projet.
ModSecGuardianLog ► HTTPD-Guardian ► WSAS ► Iptables
httpd-guardian
- détecter les attaques DoS en surveillant les demandes Apache Security, Copyright (C) 2005 Ivan Ristic - est conçu pour surveiller toutes les demandes de serveur Web via le mécanisme de journalisation canalisée. Il garde une trace du nombre de requêtes envoyées depuis chaque adresse IP ... httpd-guardian peut soit émettre un avertissement soit exécuter un script pour bloquer l'adresse IP ...
Ce script peut être utilisé avec le mécanisme de journalisation Apache2 ou avec
ModSecurity (mieux).
Installation et configuration dans les circonstances actuelles
Téléchargez httpd-guardian
et rendez-le exécutable:
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
Lisez les lignes 98-119
pour voir comment le script est connecté à notre script WSAS.
Appliquez la modification suivante dans la configuration d'Apache ( /etc/modsecurity/modsecurity.conf
), puis redémarrez-la:
#SecGuardianLog /var/log/apache2_mod_security/modsec_guardian.log
SecGuardianLog "|/var/www-security-assistant/httpd-guardian.pl"
Vérification
Pour tester le script, désactivez ModEvasive ( sudo a2dismod evasive
n'oubliez pas de l'activer plus tard) et redémarrez Apache. Ensuite, tail
le journal d'exécution:
tail -F /var/www-security-assistant/www-security-assistant.execlog
Et à partir d'une autre instance, effectuez une attaque DoS, par exemple, utilisez ab
de cette manière:
for i in {1..20}; do (ab -n 200 -c 10 https://example.com/ &); done
ModSecGuardianLog ► Analyse personnalisée ► WSAS ► Iptables
Voici un script simple, appelé httpd-custom-analyze.bash
, qui n'a rien de spécial mais qui pourrait être un bel exemple. Ses fonctionnalités sont décrites dans le corps du script.
Installation et configuration
Téléchargez httpd-custom-analyze.bash
et rendez-le exécutable:
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
Appliquez la modification suivante dans la configuration d'Apache ( /etc/modsecurity/modsecurity.conf
) et redémarrez-la:
#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"
Le script appellera WSAS lorsque le seuil est atteint - ligne de lecture 86
et 35
.
Pour que les deux httpd-
scripts fonctionnent simultanément, modifiez-les modsecurity.conf
et dirigez-les SecGuardianLog
vers les deux.
Pour effectuer un test, suivez les conseils de la section ci-dessus.