adf 2009 apache : modsecurity2cesar.resinfo.org/cours-prive/adf-012009/adf2009_modsecurity.pdf · 1...

1

ADF 2009Apache : ModSecurity 2.x

Thierry DOSTES

[email protected]

2

Plan

Le module ModSecurity :

• Présentation.

• Les 5 phases d’intervention.

• Les règles de filtrage.

• Configuration.

• Les « ModSecurity Core Rules ».

• Conclusions.

Journées Thématiques SIARS - ADF 2009

3

Le contexte

• Les applications Web sont devenus des florilèges de vulnérabilités :

• multiplication des attaques, sur le PHP en particulier (mais pas seulement !).

• attaques visant à faire exécuter des commandes via des failles de sécurité.

• Que faire ?!

• dans un monde idéal :

• sécuriser le code.

• appliquer systématiquement les correctifs de sécurité.

• dans le monde réel : mettre en œuvre un pare-feu applicatif.


Le pare-feu applicatif apportera un début de réponse à nos problèmes de sécurité. Il s’agit d’une rustine qui va apporter seulement une réponse partielle.

Elle ne dispense pas de sécuriser correctement le code. Elle présente toutefois l’avantage de protéger dans une certaine mesure des applications Web sur lesquelles nous ne pouvons intervenir.

Les pratiques de développement doivent veiller à minimiser la surface d’attaque des applications. Un pare-feu applicatif ne se substituera jamais aux développeurs d’une application. Seuls ces derniers en comprennent tous les rouages et sont en mesure de palier à ces failles.

4

Le pare-feu applicatif

• Il intercepte les requêtes et les réponses.

• Il applique la politique de filtrage applicative en vigueur.

• Deux approches possibles :

• liste blanche : seules les requêtes et réponses expressément autorisées peuvent passer.

• liste noire : les attaques connues sont bloquées àpartir d’une liste de signatures comportant des motifs réputés dangereux.

• Dans la pratique : l’approche par liste noire est plus adaptée à la réalité du terrain.


L’ approche de type liste blanche est à réserver à des applications dont on maîtrise tous les rouages et qui évoluent très peu dans le temps.

Faute de quoi, on aboutit très vite à des règles de faible granularité, donc trop permissives.

L’approche de type liste noire est plus adaptée à la réalité du terrain, même si, de prime abord, elle peut paraître inadaptée pour les plus paranoïaques d’entre nous.

5

Présentation deModSecurity

6

Présentation

• Il s’agit d’un module Apache2.

• Il est né en 2002.

• Il est disponible sous licence GPLv2.

• Il travaille au niveau de la couche application, sur le protocole http.

• Il comporte un moteur de détection et de prévention pour les applications Web.

• Ce moteur se base sur des règles de filtrage et des signatures.

• Il fournit en standard un jeu de règles basésur une approche de type « liste noire ».


ModSecurity a connu un succès grandissant, relayé par une communauté d’utilisateurs compétente. Il a fini par supplanter certaines solutions commerciales.

Il est disponible sous licence GPLv2 ainsi que sous licence commerciale, notamment pour fournir un support à ces utilisateurs.

7

Fonctionnalités (1)

• Depuis ses versions 2.x, ModSecurity offre les fonctionnalités suivantes :

• 5 phases (ou niveaux) d’intervention possibles.

• des fonctions de transformation adaptables àchaque règle de filtrage :

• décodage/encodage des données en base64.

• décodage des entités HTML.

• normalisation des données avant traitement.

• support du filtrage XML (ex : validation des flux par rapport à une DTD).

• possibilité d’attribuer un score à chaque anomalie.

• collecte d’informations à des fins de corrélation.


Nous allons étudier plus en détails ces 5 phases dans les prochaines diapos.

Le score attribué à une anomalie pourra servir de déclencheur pour journaliser et/ou rejeter une requête/réponse.

ModSecurity peut désormais collecter des données de manière persistante pour corréler les événements générés depuis certaines adresses IP, des sessions ou par des utilisateurs.

8

Fonctionnalités (2)

• Ainsi, ModSecurity est capable :

• de filtrer des requêtes ou des réponses.

• d’inspecter les flux HTTPS.

• de fouiller les données compressées.

• d’analyser le contenu lors de l’utilisation de la méthode POST.

• d’intercepter des requêtes suspectes avant qu’elles n’atteignent une application PHP.

• de journaliser des anomalies pour une analyse ultérieure.

• Pour cela, il travaille sur une copie en mémoire de la requête ou de la réponse.


ModSecurity effectue une copie en mémoire de la requête ou de la réponse. Il travaille sur cette copie grâce aux différentes fonctions de transformations (cf diapositive précédente).

ModSecurity « transforme » les valeurs des variables avant de les tester à l’aide des règles.

9

Les 5 phases deModSecurity

10

Phases de filtrage de ModSecurity


Le filtrage peut intervenir non seulement sur les entêtes et corps de requête, mais aussi sur les entêtes et les corps des réponses.

Toutes ces « interventions » peuvent être journalisées.

L’administrateur peut créer des règles et les faire s’appliquer au niveau qu’il souhaite.

La priorité d’application d’une règle est fonction d’une phase. Une règle de phase n est prioritaire par rapport à une règle de phase n+1.

11

Phase 1 : entête de la requête

• Apache vient de lire l’entête de la requête.

• Il n’a pas encore lu son contenu.

• Il ne connaît pas encore les arguments contenus dans la requête.

• Toute règle s’exécutant en phase 1 intervient avant qu’Apache soit en mesure de faire quelque chose.

Exemples de règles en phase 1:

• décider si le corps de la requête doit être traité plus en détail.

• définir comment le corps doit être traité (en XML ?)

• Attention : les règles de phase 1 ne peuvent s’appuyer sur les directives de portée d’Apache (Directory, Location, etc.).


Pour utiliser des règles ModSecurity en corrélation avec des espaces Web définis par Apache, celles-ci doivent être définies en phase 2.

12

Phase 2 : corps de la requête

• Nous disposons désormais des argumentsde la requête.

• Les règles de filtrage ou de rejets liéesà des applications doivent intervenir à ce niveau .

• ModSecurity connaît trois types d’encodage pour analyser le contenu du corps d’une requête.

• application/x-www-form-urlencoded

• multipart/form-data

• text/xml

• Les autres types sont rarement utilisés par les applications Web.


13

Phase 3 : entête de la réponse

• Cette phase intervient juste avant queque les entêtes des réponses parviennent au client.

• Les règles de filtrage permettent de définir ce qu’il doit advenir de la « future » réponse.

• On décide si l’on veut analyser le contenu/corps de la réponse ou la bloquer.

• A ce niveau, nous ne savons pas encore ce que le serveur Apache va retourner.


14

Phase 4 : corps de la réponse

• A ce niveau, ModSecurity analyse lesinformations renvoyées à destination du client.

• Le contenu HTML est analysé pour détecter :

• des fuites d’informations.

• des messages d’erreurs.

• des traces d’authentifications ayant échouées.

• etc.


15

Phase 5 : journalisation

• Les règles déclarées à ce niveau interviennent seulement sur la manière dont la journalisation doit s’opérer.

• Cette phase peut être utilisée pour analyser les messages d’erreur enregistrés par Apache.

• Elle permet également d’inspecter des entêtes de réponse qui n’étaient pas accessibles en phases 3 et 4.

• Il est trop tard pour interdire ou bloquer des connexions.


16

Les règles selonModSecurity

17

Le principe

• Nous pouvons créer des règles et définir àquelle phase elles interviendront.

• Il est également possible de définir des comportements par défaut.

ex : définir l’action par défaut si aucune règle ne s’applique

• Pour exprimer ces règles, nous disposons de variables et d’actions.

ex : mettre une machine cliente en liste blanche.


SecRule REMOTE_ADDR "^10\.126\.100\.85$" phase:1,log,allow,ctl:ruleEngine=Off

SecDefaultAction "phase:2,log,pass,status:500"

18

Quelques exemples de variables

• ARGS : traite l’ensemble des arguments, ou l’argument spécifié en paramètre, ou tous les arguments sauf un.

• AUTH_TYPE : renvoie le type d’authentification utilisé.

• HTTP_REFERER : indique le site de provenance d’une requête.

• REMOTE_ADDR : l’adresse IP de la machine cliente.

• REMOTE_HOST : retourne le nom DNS de la machine cliente si l’option HostnameLookUp est activée.

• REQUEST_HEADERS : permet de travailler sur l’entête de la requête (ex : champ Host).

• REQUEST_BODY : accède aux données contenues dans le corps de la requête.

• REQUEST_FILENAME : retourne le nom du fichier appelé, sans les éventuels paramètres.

• REQUEST_URI : retourne le chemin d’accès au fichier appelé et les éventuels paramètres.


19

Les actions

• Chaque action appartient à l’un des 5 groupes suivants :

• actions perturbatrices : ModSecurity interceptera les données (ex : allow).

• actions non perturbatrices (ex : auditlog).

• actions de traitement du flux (ex : chain).

• actions périphériques (ex : id, msg, severity).

• actions sur les données : elles sont utilisées pour acheminer les informations traitées par d’autres types d’actions.


chain permet de concaténer plusieurs règles afin d’être en mesure de créer des filtres complexes prenant en compte plusieurs variables.

id permet d’attribuer un identifiant numérique à une règle.

msg lui attribue un message qui sera affiché dans les fichiers de traces.

20

Quelques exemples d’actions (1)

• allow : interrompt le traitement et autorise la transaction lorsque une règle s’applique.

• auditlog : journalise la transaction dans le fichier d’audit.

• capture : déclenche la sauvegarde d’une transaction lorsqu’un modèle défini apparaît (10 captures possibles).

• ctl : permet de surcharger la configuration par défaut pour la règle courante :



SecRule REMOTE_ADDR "^192\.168\.1\.100$" auditlog,phase:1,allow

SecRule REQUEST_BODY "^username=(\w{25,})" phase:2,capture,t:none,chain SecRuleTX:1 "(?:(?:a(dmin|nonymous)))"


21


• deny : interrompt le traitement et intercepte la transaction.

• drop : coupe immédiatement la connexion TCP.

• exec : exécute un script externe.


SecRule REQUEST_HEADERS:User-Agent "nikto" "log,deny,msg:'Nikto Scanners Identified'"

SecAction initcol:ip=%{REMOTE_ADDR},nologSecRule ARGS:login "!^$" \

nolog,phase:1,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=20/120 SecRule IP:AUTH_ATTEMPT "@gt 25" \

log,drop,phase:1,msg:'Possible Brute Force Attack"

SecRule REQUEST_URI "^/cgi-bin/script\.pl" \"log,exec:/usr/local/apache/bin/test.sh,phase:1"

Voici un exemple d’utilisation de la commande drop pour se protéger d’attaque en force brute. Nous enregistrons les tentatives d’authentifications auprès de notre serveur. Si le client distant essaye de se connecter plus de 25 en fois en moins de 2 minutes, ModSecurity rejettera toute nouvelle tentative de connexion.

Il est impossible de passer des paramètres aux scripts appelés par l’intermédiaire de la fonction exec. En revanche, l’ensemble des variables d’environnement CGI seront accessibles au programme externe. Celui-ci doit retourner quelque chose sur la sortie standard (stdout), faute de quoi ModSecurity considèrera que l’exécution a échoué.

22


• log : journalise la transaction dans le fichier de traces.

• phase : précise la phase pour laquelle la règle devra s’appliquer.

• proxy : redirige la requête vers un autre serveur grâce au module proxy d’Apache.

• severity : définit la gravité d’une alerte.

• status : spécifie le status HTTP retourné au client.



SecRule REQUEST_HEADERS:User-Agent "Test" log,proxy:http://www.nowhere.com/

SecRule REQUEST_METHOD "^PUT$" "id:340002,rev:1,severity:2,msg:'Restricted HTTP function'"

SecDefaultAction log,deny,status:403,phase:1

Les niveaux de gravité possibles pour severity sont :

0 = EMERGENCY

1 = ALERT

2 = CRITICAL

3 = ERROR

4 = WARNING

5 = NOTICE

6 = INFO

7 = DEBUG

Le code erreur HTTP 403 correspond à une action interdite. Le serveur HTTP a compris la requête, mais refuse de la traiter.Ce code est généralement utilisé lorsqu'un serveur ne souhaite pas indiquer pourquoi la requête a été rejetée.

23

La construction des règles

• Les règles sont écrites dans un langage propre à ModSecurity.

• SecRule est la principale directive utilisée.

• Le format d’une règle est le suivant :

• VARIABLES spécifie les variables qui doivent être testées.

• OPERATOR précise l’opérateur utilisé en le faisant précéder du symbole @ (ex : lt, gt, !; etc.).

• ACTIONS indique ce que l’on veut faire. Cet argument est optionnel.


SecRule VARIABLES OPERATOR [ACTIONS]

SecRule REQUEST_URI dirtySecRule REQUEST_URI "@rx dirty"

Si aucun opérateur n’est spécifié, c’est l’opérateur rx qui est utilisé par défaut. Il permet de déclarer une expression régulière.

Dans l’exemple ci-dessus, nous avons utilisé des guillemets pour la déclaration du second paramètre (OPERATOR) car il contient un espace. Dans le cas contraire, ModSecurityconsidèrerait que « dirty » est le troisième argument de la directive SecRule, donc une action.

24

Les expressions régulières

• Les expressions régulières sont gérées par la librairie PCRE.

• ModSecurity les interprète de la manière suivante :

• les paramètres fournis en entrée sont traitées comme une seule ligne.

• les retours chariots sont « ignorés ».

• la casse importe (fonction lowercase disponible).

• le « . » se substitue à n’importe quel caractère, y compris le retour chariot.


SecRule IP:AUTH_ATTEMPT "@gt 25" \log,drop,phase:1,msg:'Possible Brute Force Attack"

PCRE considère que le « . » se substitue à tout caractère, à l’exception du retour chariot.

25

La configuration de ModSecurity

26

Configuration de ModSecurity (1)

• Le fichier modsecurity_crs_10_config.conf définit le comportement par défaut de l’outil :

• SecRuleEngine :

• On : interception des échanges et application des règles de filtrage.

• DetectionOnly : application des règles sans interception.

• Off : désactivation de la surveillance.

• SecRequestBodyAccess On : activation des règles permettant l’inspection du corps des requêtes.

• SecResponseBodyAccess On : même chose pour le corps des réponses.

• SetDefaultAction : permet de déterminer l’action par défaut si aucune règle ne s’applique.


27


• Nous pouvons spécifier plusieurs actions par défaut :

• log : toute transaction est enregistrée dans le fichier de traces.

• auditlog : toute transaction est conservée dans le fichier d’audit de ModSecurity.

• deny : intercepte la transaction.

• status:403 : précise le code HTTP retourné au client dès qu’une règle correspond.

• phase:2 : indique la phase lors de laquelle s’applique cette règle par défaut.

• t:lowercase : active la transformation de tous les caractères d’une requête en minuscules.


SecDefaultAction log,auditlog,deny,status:403,phase:2,t:lowercase

28


• Il est possible de préciser les informations d’audit conservées :

• SecAuditEngine :

• On : enregistre toutes les transactions par défaut.

• Off : n’enregistre aucune transaction.

• RelevantOnly : conserve seulement les transactions àl’origine d’une alerte ou d’une erreur.

• SecAuditLog : définit l’emplacement du fichier de traces.

• SecAuditLogPart : spécifie quelles parties des échanges sont enregistrées :

• A : informations spécifiques aux journaux d’événements.

• B : les entêtes de la requête.

• I : le corps de la requête (à l’exception des fichiers).

• F : les entêtes de la réponse.

• Z : les informations signifiant la fin de l’entrée dans les journaux.


ModSecurity permet d’enregistrer beaucoup plus d’informations que le serveur Apache dans les fichiers de traces. Nous disposons ainsi d’informations d’audit beaucoup plus détaillées. Voyons comment définir ce que nous souhaitons conserver.

29


• D’autres directives :

• Modification de la signature renvoyée par le serveur :

• SecServerSignature

• Définition de limites sur les volumes de données traités :

• SecResponseBodyLimit

• SecRequestBodyInMemoryLimit

• Définition du niveau de logs : SecDebugLogLevel

• 0 : aucun enregistrement.

• 1 : enregistrement des erreurs.

• 2 : alertes.

• 3 : notifications (valeur par défaut sous Debian).

• 4 : détails dans le traitement de la transaction.

• 5 : équivalent au niveau 4 en plus détaillé.

• 9 : tout est enregistré.


Un outil de prise d’empreinte n’aura aucun mal à retrouver la véritable signature du serveur.

SecResponseBodyLimit : taille maximale autorisée (en bytes) pour le corps d’une réponse.

SecResponseBodyInMemoryLimit : taille maximale autorisée pour stocker en mémoire le corps d’une requête.

30

Les règles de basede ModSecurity

ModSecurity est désormais prêt à protéger nos applications Web. Pour cela, un kit de règles de base (ModSecurity Core Rules) nous est fourni. Il est régulièrement mis à jour et testé par l’éditeur.

31

ModSecurity Core Rules (1)

• ModSecurity propose des règles par défaut.

• Elles sont basées sur une approche de type liste noire.

• Elles offrent une protection honorable contre les attaques les plus connues :

• détection de l’activité de certains scanners ou bots.

• interception de tentatives d’accès à des cheveauxde Troie.

• recherche les irrégularités dans l’utilisation du protocole HTTP (en entrée et en sortie).

• Elles permettent de modifier les messages d’erreurs renvoyés par le serveur.


32


• Les règles sont organisées en fonction du type d’attaque ou de protection.

• Elles sont stockées dans plusieurs fichiers :

• L’ordre d’application des règles importe.


modsecurity_crs_10_config.confmodsecurity_crs_20_protocol_violations.confmodsecurity_crs_21_protocol_anomalies.confmodsecurity_crs_23_request_limits.confmodsecurity_crs_30_http_policy.confmodsecurity_crs_35_bad_robots.confmodsecurity_crs_40_generic_attacks.confmodsecurity_crs_45_trojans.confmodsecurity_crs_50_outbound.conf

Passons en revue la fonction de chacun de ces fichiers.

33


• mod_security_crs_10_config :

• fichier de configuration du moteur.

• définition des comportements généraux.

• mod_security_crs_20_protocol_violations :

• règles vérifiant que les requêtes sont conformes au protocole HTTP.

• intervention en phase 2 du cycle de vie de ModSecurity.

• élimination d’un grand nombre d’attaques automatisées.

• mod_security_crs_21_protocol_anomalies :

• recherche de motifs synonymes d’attaques HTTP.

• intervention en phase 2.

• rejet des transactions concernées.


Exemple de motif synonyme d’une attaque : des requêtes à destination du serveur « localhost ».

34


• mod_security_crs_23_request_limits :

• limitation du nombre et de la taille des arguments soumis lors d’une requête HTTP.


• protection contre les attaques de type buffer overflow ou manipulation des paramètres.

• mod_security_crs_30_http_policy :

• règles restreignant l’utilisation du protocole HTTP par les clients :

• blocage de méthodes (CONNECT, DEBUG, TRACE).

• refus du protocole HTTP 0.9.

• interdiction de fichiers dont l’extension est synonyme de contenus dangereux (.ini, .key, .old).



35


• mod_security_crs_35_bad_robots :

• limitation des nuisances générées par des robots d’indexation qui n’en seraient pas.

• enregistrements des transactions, mais pas de blocage.


• détection des scanners de sécurité.

• mod_security_crs_40_generic_attacks :

• mise en place de règles contre des attaques connues :

• protection des sessions.

• injections de code SQL.

• attaques de type Cross Site Scripting (XSS).

• accès ou injection de commandes.

• injections diverses (PHP, LDAP, SSI, etc.).

• intervention en phase 2.Journées Thématiques SIARS - ADF 2009

36


• mod_security_crs_45_trojans :

• détection des tentatives d’accès aux troyens et portes dérobées déjà installées sur le système.


• la mise à jour régulière des ces règles est indispensable.

• attention : contournement possible de ces filtres.

• mod_security_crs_50_outbound :

• détection et interception de codes erreurs trop explicites renvoyées par une application (ex : erreurs SQL ou PHP).


• renvoie le code erreur HTTP 501 (opération non supportée par le serveur).

• protection contre la fuite d’informations utilisables pour initier des actions malveillantes.


Puisque ModSecurity est un produit libre, les pirates et autres personnes mal intentionnées ont accès au contenu des règles. Il leur est donc possible de mettre en œuvre de nouvelles attaques pour les contourner.

37


• mod_security_crs_55_marketing :

• journalisation des transactions initiées par les moteurs de recherches.


• utilisation à des fins statistiques.

• mod_security_crs_60_custom_rules :

• définition de nouvelles règles utilisateur.

• cf TP.


38

Conclusions

39

Limitations de ModSecurity

• Les règles de base peuvent bloquer le fonctionnement de certaines applications.

• ModSecurity nécessite donc un important travail de mise au point pour personnaliser les règles.

• L’analyse des transactions HTTP peut surcharger le serveur selon son dimensionnement initial :

• consommation mémoire (copie des transactions).

• consommation CPU (expressions régulières).

• Une utilisation en corrélation avec un reverse proxy préviendra les risques de surcharge du serveur.

• ModSecurity n’est pas un outil infaillible.


ModSecurity bénéficie d’un très bon support de la part des équipes de développement. Si vous rencontrez des problèmes de type « faux positifs » avec les règles de base, vous pouvez soumettre ce cas, à l’adresse [email protected], pour qu’il soit résolu.

40

Outils complémentaires (1)

• ModSecurity Console permet de centraliser et de surveiller les événements de ModSecurity en réel :

• elle est développée en Java.

• elle peut être installée sur une machine indépendante.

• une version gratuite permet d’analyser les traces de 3 instances de ModSecurity.

• elle propose des fonctions de « reporting ».


41

Outils complémentaires (2)

• REMO est un outil graphique de création de règles de filtrage pour ModSecurity :

• REMO : Rule Editor for MOdSecurity.

• il est développé en langage Ruby et il utilise le frameworkRails.

• l’outil est en cours de développement.


adf 2009 apache : modsecurity2cesar.resinfo.org/cours-prive/adf-012009/adf2009_modsecurity.pdf · 1...

Documents