La sécurité des serveur Web
Problématique http://<monserver>/default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u90 90%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9 090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u0 0=a L’URL plus haut trouvé dans les logs d’un serveur web correspond à une requête envoyée par le ver CodeRed Ce type d’attaque sur les serveurs Web devient de plus en plus fréquent et demande une attention particulière car il peut infecter un serveur Web IIS
Le proxy-inverse Un proxy inverse (appelé encore accélérateur web) accepte les requêtes des clients et les transmet au serveur web. Il peut donc effectuer au passage des tests pour vérifier leur conformité et éliminer les requêtes dangereuses Il permet d’autre part d’améliorer les perfor- mances du serveur Le serveur proxy Squid fonctionne parfaitement bien en proxy-inverse Squid peut protéger n’importe quel serveur Web : Apache ou IIS
Le proxy-inverse – Suite Il est également possible d’utiliser Apache et son module mod_proxy pour effectuer du proxy inverse Le client continue d’utiliser la même adresse, c’est le serveur web qui utilise une autre adresse ou un autre port
Configuration 1 On peut utiliser : Squid et le serveur Web sur la même machine http_port 80 # Port du proxy httpd_accel_host localhost # serveur web httpd_accel_port 81 # Port du serveur web httpd_accel_single_host on # envoi à un serveur web unique httpd_accel_with_proxy on # httpd_accel_uses_host_header off
Configuration – 2 Squid et le serveur Web sur 2 machines différentes http_port 80 # Port du proxy httpd_accel_host 172.16.1.100 # adresse du serveur web httpd_accel_port 80 # Port du serveur web httpd_accel_single_host on # envoi à un serveur web unique httpd_accel_with_proxy on # httpd_accel_uses_host_header off
Configuration suite Blocage de requêtes acl bad_requests urlpath_regex -i cmd.exe \/bin\/sh default\.ida?XXX # ajouter ici les chaines à interdire. http_access deny bad_requests
Le redirecteur La démarche précédente est efficace mais limitée en efficacité Le redirecteur est un programme qui lit les arguments sur l’entrée standard, les modifie et imprime l’url sur la sortie standard. Les arguments en entrée sont les suivants : URL Adresse IP ou fqdn identité methode On dispose alors de la puissance d’un langage de programmation ce qui permet d’effectuer un traitement beaucoup plus sophistiqué Insérer la clause suivante dans squid.conf : redirect_program=/chemin/redirecteur
Le programme redirecteur Exemple basique réalisé en perl : #!/usr/bin/perl $|=1; # vidage tampons E/S. # Lecture entrée standard, une requête par ligne envoyée par squid. while (<>) { # boucle perpétuelle.. $url=(split)[0]; # Lecture URL # Modifie l’URL (recherche et remplacement), $url =~ s/^http:\/\/www.monserver.net/http:\/\/www.vraiserveur.net:8080/ print $url; #Affiche l’URL modifiée sur stdout . }
Une autre solution : Apache mod_security http://www.serveur.net/login.php?username=admin';DROP%2 0TABLE%20users-- La ligne plus haut est caractéristique d’une attaque par injection SQL : elle va permettre de supprimer une table !!! Il est possible de mettre en œuvre un proxy inverse pour lutter contre ce type d’attaque mais ce n’est pas toujours possible. Si l’on ne dispose que d’une seule machine, il est possible de mettre en oeuvre mod_security
Présentation Le module effectue les actions suivantes : Analyse de la requête Remise en forme de la requête Vérification Test des règles d’entrée Exécution des règles de sortie Ecriture dans les journaux de log
Configuration - Exemple <IfModule mod_security.c> SecFilterEngine On # Turn the filtering engine On or Off SecFilterCheckURLEncoding On # Make sure that URL encoding is valid SecFilterCheckUnicodeEncoding Off # Unicode encoding check SecFilterForceByteRange 0 255 # Only allow bytes from this range SecAuditEngine RelevantOnly # Only log suspicious requests SecAuditLog logs/audit_log # The name of the audit log file # Debug level set to a minimum SecFilterDebugLog logs/modsec_debug_log SecFilterDebugLevel 0 SecFilterScanPOST On # Should mod_security inspect POST payloads # By default log and deny suspicious requests with HTTP status 500 SecFilterDefaultAction "deny,log,status:500" </IfModule>
Detection d’attaques classiques # Command execution attacks SecFilter /etc/password SecFilter /bin/ls # Directory traversal attacks SecFilter "\.\./" # XSS attacks SecFilter "<(.|\n)+>" SecFilter "<[[:space:]]*script" # SQL injection attacks SecFilter "delete[[:space:]]+from" SecFilter "insert[[:space:]]+into" SecFilter "select.+from" # MS SQL specific SQL injection attacks SecFilter xp_enumdsn SecFilter xp_filelist SecFilter xp_availablemedia SecFilter xp_cmdshell SecFilter xp_regread SecFilter xp_regwrite SecFilter xp_regdeletekey