Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Dernière révision Les deux révisions suivantes | ||
|
modsecurity [Le 21/12/2014, 19:23] neoflow [Voir aussi] |
modsecurity [Le 25/07/2022, 16:34] 86.239.127.210 fix typo markdown |
||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| - | {{tag>Ocelot Apache mod}} | + | |
| + | {{tag>Trusty Apache mod}} | ||
| ---- | ---- | ||
| Ligne 14: | Ligne 15: | ||
| - | Pour installer ce logiciel, il suffit d'[[:tutoriel:comment_installer_un_paquet|installer le paquet]] **[[apt>libapache2-modsecurity]]**. | + | Pour installer ce logiciel, il suffit d'[[:tutoriel:comment_installer_un_paquet|installer le paquet]] **[[apt>libapache2-mod-security2]]** |
| Cela aura le résultat de créer: | Cela aura le résultat de créer: | ||
| * Les fichiers //mod-security.conf// et //mod-security.load// dans le dossier ///etc/apache2/mods-available//. Le lien symbolique (correspondant à la commande "a2enmod mod-security" sera automatiquement créé). | * Les fichiers //mod-security.conf// et //mod-security.load// dans le dossier ///etc/apache2/mods-available//. Le lien symbolique (correspondant à la commande "a2enmod mod-security" sera automatiquement créé). | ||
| Ligne 22: | Ligne 23: | ||
| ===== Configuration générale ===== | ===== Configuration générale ===== | ||
| - | Pour fonctionner, ModSecurity a besoin d'une configuration activée, non présente après l'installation du module. Pour ce faire, il est possible de simplement [[:tutoriel:learn_unix_in_10_minutes#deplacer_renommer_et_copier_des_fichiers|renommer le fichier]] ///etc/modsecurity/modsecurity.conf-recommended//, et lui enlever la partie "-recommended" pour qu'il soit reconnu par l'application. | + | Pour fonctionner, ModSecurity a besoin d'une configuration activée, non présente après l'installation du module. Pour ce faire, il est possible de simplement [[:tutoriel:learn_unix_in_10_minutes#deplacer_renommer_et_copier_des_fichiers|renommer le fichier]] ///etc/modsecurity/modsecurity.conf-recommended//, et lui enlever la partie "-recommended" pour qu'il soit reconnu par l'application.... |
| - | Il est nécessaire de comprendre que s'agissant d'un module, la configuration associée est ici séparée dans un dossier à part (/etc/modsecurity/), mais que cela est parfaitement optionnel. Il suffit que la configuration soit lue par le moteur Apache pour que les directives modsecurity soient reconnues. Par exemple, il est possible de placer directement les directives dans les fichiers de [[:tutoriel:virtualhosts_avec_apache2|VirtualHost]], ou alors pouvoir changer certains paramètres un à un selon le VirtualHost voulu. | + | Il est nécessaire de comprendre que s'agissant d'un module, la configuration associée est ici séparée dans un dossier à part (/etc/modsecurity/), mais que cela est parfaitement optionnel. Il suffit que la configuration soit lue par le moteur Apache pour que les directives modsecurity soient reconnues. Par exemple, il est possible de placer directement les directives dans les fichiers de [[:apache2#creation_d_hotes_virtuels|VirtualHost]], ou alors pouvoir changer certains paramètres un à un selon le VirtualHost voulu.... |
| - | La configuration de ce fichier, via la directive "//SecRuleEngine DetectionOnly//", n'aura pas pour action de bloquer une requête. Elle se contentera de journaliser les détections (voir partie suivante). Si, à des fins de tests, ou quand votre configuration vous semble parée, vous pensez être prêt à bloquer les requêtes suspectes, alors il faut passer le paramètre //SecRuleEngine// à// On//. | + | La configuration de ce fichier, via la directive "//SecRuleEngine DetectionOnly//", n'aura pas pour action de bloquer une requête. Elle se contentera de journaliser les détections (voir partie suivante). Si, à des fins de tests, ou quand votre configuration vous semble parée, vous pensez être prêt à bloquer les requêtes suspectes, alors il faut passer le paramètre //SecRuleEngine// à// On//.... |
| ===== Afficher une signature serveur personnalisée ===== | ===== Afficher une signature serveur personnalisée ===== | ||
| Ligne 34: | Ligne 35: | ||
| Exemple : //SecServerSignature "Microsoft IIS7"// | Exemple : //SecServerSignature "Microsoft IIS7"// | ||
| - | Pour que cela fonctionne, il est nécessaire que le paramètre ServerTokens soit mis à "Full" (et non "OS"), dans le fichier de configuration ///etc/apache2/conf.d/security//. S'il n'est pas présent dans la configuration, vous pouvez librement l'ajouter où il vous plaira. | + | Pour que cela fonctionne, il est nécessaire que le paramètre ServerTokens soit mis à "Full" (et non "OS"), dans le fichier de configuration ///etc/apache2/conf-available/security.conf//. S'il n'est pas présent dans la configuration, vous pouvez librement l'ajouter où il vous plaira... |
| Il est aussi nécessaire de tester avec peu de caractères dans la signature, sous peine de rétablissement de l'ancien affichage. Pour faire vos tests, vous pouvez simplement utiliser un nom de page inexistant, qui vous menera vers un code d'erreur 404, ce qui aura pour finalité d'afficher votre signature telle que les pirates la verront. | Il est aussi nécessaire de tester avec peu de caractères dans la signature, sous peine de rétablissement de l'ancien affichage. Pour faire vos tests, vous pouvez simplement utiliser un nom de page inexistant, qui vous menera vers un code d'erreur 404, ce qui aura pour finalité d'afficher votre signature telle que les pirates la verront. | ||
| Ligne 50: | Ligne 51: | ||
| :!: Il faut savoir que les règles ayant été écrites pour l'application avant la version 2.5 sont désormais incompatibles. Ces règles utilisent la directive //SecFilter//, qui a été abandonnée depuis au profit de //SecRule//. Il s'agit là d'un moyen sûr d'estimer la compatibilité des règles trouvables sur la toile. En clair, vous ne pouvez pas utiliser des règles commençant par //SecFilter//. | :!: Il faut savoir que les règles ayant été écrites pour l'application avant la version 2.5 sont désormais incompatibles. Ces règles utilisent la directive //SecFilter//, qui a été abandonnée depuis au profit de //SecRule//. Il s'agit là d'un moyen sûr d'estimer la compatibilité des règles trouvables sur la toile. En clair, vous ne pouvez pas utiliser des règles commençant par //SecFilter//. | ||
| - | Les règles de filtrage utilisent les [[http://doc.ubuntu-fr.org/projets/ecole/scripting/initiation_au_shell#les_expressions_regulieres|expressions régulières avancées]]. Il est ainsi alors possible de gérer énormément de possibilités de détection. | + | Les règles de filtrage utilisent les [[:projets/ecole/scripting/initiation_au_shell#les_expressions_regulieres|expressions régulières avancées]]. Il est ainsi alors possible de gérer énormément de possibilités de détection. |
| Vous pouvez vous inspirer des règles présentes dans les fichiers fournis à l'installation, pour mettre en place vos propres fichiers de configuration correspondant à vos besoins. Les règles sont faites de deux éléments. Tout d'abord, la directive permet de détecter les éléments à bloquer, par le biais d'une expression régulière et un champ d'action. Ensuite, une action à effectuer après détection doit être déterminée. Elle permettra d'expliquer le comportement à adopter (deny, log...), le niveau de criticité (severity), le code d'erreur renvoyé (status) et d'autres actions optionnelles, comme par exemple la redirection à une page après détection (redirect). | Vous pouvez vous inspirer des règles présentes dans les fichiers fournis à l'installation, pour mettre en place vos propres fichiers de configuration correspondant à vos besoins. Les règles sont faites de deux éléments. Tout d'abord, la directive permet de détecter les éléments à bloquer, par le biais d'une expression régulière et un champ d'action. Ensuite, une action à effectuer après détection doit être déterminée. Elle permettra d'expliquer le comportement à adopter (deny, log...), le niveau de criticité (severity), le code d'erreur renvoyé (status) et d'autres actions optionnelles, comme par exemple la redirection à une page après détection (redirect). | ||
| Ligne 79: | Ligne 80: | ||
| ===== Désinstallation ===== | ===== Désinstallation ===== | ||
| - | Il suffit de désinstaller le paquet //libapache2-modsecurity//. Les fichiers de configuration ajoutés par l'utilisateur dans /etc/modsecurity/ seront conservés. | + | Il suffit de désinstaller le paquet. Les fichiers de configuration ajoutés par l'utilisateur dans /etc/modsecurity/ seront conservés. |
| ===== Voir aussi ===== | ===== Voir aussi ===== | ||
| Ligne 86: | Ligne 87: | ||
| * **(en)** [[http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual|Manuel de référence]] | * **(en)** [[http://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual|Manuel de référence]] | ||
| * **(en)** [[http://www.gotroot.com/mod_security+rules|Règles de filtrage à télécharger]] | * **(en)** [[http://www.gotroot.com/mod_security+rules|Règles de filtrage à télécharger]] | ||
| - | * **(fr)** [[http://www.it-connect.fr/installation-de-mod_security-devant-un-serveur-web-apache/|Installation et configuration de mod_security devant Apache ]]sur IT-Connect | + | * **(fr)** [[https://www.it-connect.fr/installation-de-mod_security-devant-un-serveur-web-apache/|Installation et configuration de mod_security devant Apache ]]sur IT-Connect |
| ---- | ---- | ||
| //Contributeurs principaux : [[utilisateurs:Amarokk|Guillaume Fenollar]], et bientôt vous? | //Contributeurs principaux : [[utilisateurs:Amarokk|Guillaume Fenollar]], et bientôt vous? | ||