top of page

On vous présente un bon plan, le coud d'Oracle offre des serveurs gratuits :

cloud-vds.png

  • 2 Base de données

  • 2 VPS AMD

  • 4 instances ARM

  • Stockage 100 Go

  • 50k appels API

Voir sur notre blog...

theme-light-dark-white.png
Rechercher

Fortifier votre Serveur Web : Guide de Sécurité pour Nginx et Apache

Dernière mise à jour : 22 sept. 2023


Lors de la configuration d'un VirtualHost sur Apache ou d'un Server Bloc sur Nginx (deux des serveurs web les plus couramment utilisés), il y a plusieurs options de sécurité que vous pouvez envisager.


Voici quelques-unes d'entre elles, bien que les détails spécifiques dépendent du type de serveur web que vous utilisez et des exigences de sécurité spécifiques à votre application.



Sommaire


Configuration de HTTPS


Il s'agit de la première et la plus importante étape. HTTPS chiffre le trafic entre le client et le serveur, le rendant beaucoup plus difficile à intercepter et à lire. Vous aurez besoin d'un certificat SSL pour cela, qui peut être obtenu gratuitement via Let's Encrypt ou acheté auprès de divers fournisseurs. Une fois que vous avez un certificat, vous pouvez configurer votre serveur pour l'utiliser.


Assurez vous de remplacer "exemple.com" et "www.exemple.com" par votre domaine.


< w/ Nginx >


Voici comment vous pouvez installer Certbot et obtenir un certificat SSL pour Nginx sur un système Linux basé sur Debian (comme Ubuntu) :


Installez le logiciel Certbot et le plugin Nginx en exécutant la commande suivante :


sudo apt-get install certbot python3-certbot-nginx

Ensuite, utilisez Certbot pour obtenir un certificat SSL et configurer Nginx :


sudo certbot --nginx -d exemple.com -d www.exemple.com

Suivez les instructions à l'écran. Certbot modifiera automatiquement la configuration de Nginx pour appliquer le certificat SSL.


< w/ Apache >


Voici comment vous pouvez installer Certbot et obtenir un certificat SSL pour Apache sur un système Linux basé sur Debian (comme Ubuntu) :


Installez le logiciel Certbot et le plugin Apache en exécutant la commande suivante :


sudo apt-get install certbot python3-certbot-apache

Ensuite, utilisez Certbot pour obtenir un certificat SSL et configurer Apache :


sudo certbot --apache -d exemple.com -d www.exemple.com

Suivez les instructions à l'écran. Certbot modifiera automatiquement la configuration d'Apache pour utiliser le certificat SSL.


Certbot également tenter de renouveler automatiquement vos certificats avant qu'ils n'expirent. Vous pouvez tester le processus de renouvellement automatique avec la commande suivante :


sudo certbot renew --dry-run

 

Activation de la version 2 de HTTP


HTTP/2 est la deuxième version majeure du protocole HTTP et apporte de nombreuses améliorations en termes de performances par rapport à HTTP/1.1, notamment grâce à la multiplexation des requêtes, ce qui permet d'envoyer plusieurs requêtes en parallèle sur une seule connexion.


< w/ Nginx >


Pour activer HTTP/2 dans Nginx, vous devez simplement ajouter le paramètre http2 à vos directives listen dans la configuration de votre serveur.


Ouvrez le fichier de configuration de Nginx pour votre site. Il est généralement situé dans /etc/nginx/ ou /etc/nginx/sites-available/.


Ajoutez http2 à la directive listen pour les connexions SSL, comme suit :


server {
    listen 443 ssl http2;
    ...
}


< w/ Apache>


Pour Apache, l'activation de HTTP/2 nécessite l'utilisation du module mod_http2.


Assurez vous que le module mod_http2 est activé. Vous pouvez l'activer en exécutant la commande suivante :


sudo a2enmod http2

Ensuite, ouvrez le fichier de configuration pour votre site Apache. Cela se trouve généralement dans le répertoire /etc/apache2/sites-available/.


Ajoutez la directive Protocols pour activer HTTP/2 :


<VirtualHost *:443>
    Protocols h2 http/1.1
    ...
</VirtualHost>

Cela activera HTTP/2 pour votre site web. Notez que HTTP/2 est généralement utilisé avec HTTPS, donc assurez vous que votre site est sécurisé avec.


 

Désactivation des informations de version du serveur


Par défaut, votre serveur peut inclure des informations de version dans ses réponses via les en-têtes HTTP, ce qui peut aider les attaquants à identifier des vulnérabilités potentielles. Bien que cela puisse être utile à des fins de débogage, cela peut également fournir des informations précieuses à un attaquant potentiel. Par exemple, si votre serveur utilise une version de logiciel connue pour avoir des failles de sécurité, un attaquant peut exploiter ces failles pour attaquer votre serveur.


Il est donc préférable de désactiver ces informations de version. Voici comment vous pouvez le faire :


< w/ Nginx >


Dans Nginx vous pouvez modifier la configuration de base qui est située dans /etc/nginx/nginx.conf et utiliser la directive server_tokens pour contrôler si les informations de version du serveur sont envoyées.


Modifier le ficher de configuration par défaut :


sudo nano /etc/nginx/nginx.conf

Puis décommenter la ligne suivante (effacer le #), si elle est présente ou ajouter la.


server_tokens off;

server_tokens off; indique à Nginx de ne pas inclure les informations de version dans les en-têtes HTTP.


Cette directive peut aussi être placée dans un bloc server d'un fichier de configuration de Nginx si vous ne souhaitez pas qu'elle s'applique de façon général.


< w/ Apache >


Dans la configuration de base d'Apache, vous devez modifier le fichier de configuration principal. Le nom et l'emplacement exacts de ce fichier peuvent varier en fonction de votre système d'exploitation et de votre méthode d'installation, mais il est souvent appelé apache2.conf ou httpd.conf et se trouve généralement dans un répertoire tel que ou /etc/apache2/ ou /etc/httpd/.


Modifier le ficher de configuration par défaut :


sudo nano /etc/apache2/apache2.conf

Cherchez les directives ServerTokens et ServerSignature et modifiez-les ou ajoutez-les comme ceci :


ServerTokens Prod
ServerSignature Off

ServerTokens Prod indique à Apache de ne renvoyer que le nom du produit (c'est-à-dire "Apache") sans aucune information de version. ServerSignature Off désactive l'inclusion de l'information de version du serveur dans les pages d'erreur générées par le serveur.


Ces directives peuvent être placées n'importe où à la racine du fichier de configuration, en dehors de tout bloc <VirtualHost> ou <Directory>.


 

Configuration des en-têtes de sécurité HTTP


Il existe plusieurs en-têtes HTTP qui peuvent améliorer la sécurité de votre site web, tels que X-Content-Type-Options: nosniff (qui empêche le navigateur de "deviner" le type de contenu) et Content-Security-Policy (qui limite où le contenu peut être chargé depuis).


< w/ Nginx >


Dans Nginx, les en-têtes de sécurité peuvent être ajoutés en utilisant la directive add_header à l'intérieur d'un bloc server ou location dans le fichier de configuration (habituellement situé à /etc/nginx/nginx.conf ou /etc/nginx/sites-available/default).


Par exemple :



server {
    ...
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-XSS-Protection "1; mode=block";
    add_header Content-Security-Policy "default-src 'self'";
    ...
}

< w/ Apache >


Dans Apache, vous pouvez utiliser le module mod_headers pour ajouter des en-têtes de sécurité. Vous pouvez les ajouter à l'intérieur d'un bloc Directory, Location, ou Files dans le fichier de configuration Apache (habituellement situé dans /etc/apache2/sites-available/000-default.conf ou /etc/httpd/conf/httpd.conf).


Par exemple :


<Directory /var/www/html>
    ...
    Header always set X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"
    Header set X-Content-Type-Options "nosniff"
    Header set Content-Security-Policy "default-src 'self'"
    ...
</Directory>

Après avoir ajouté ces directives, n'oubliez pas de redémarrer ou de recharger votre serveur web pour que les modifications prennent effet.


Ces directives d'en-tête ont le même sens que ce soit pour Nginx ou Apache.


Explications :

  • X-Frame-Options: SAMEORIGIN : Empêche votre site d'être incorporé dans un iframe, ce qui peut aider à prévenir les attaques de type "clickjacking". SAMEORIGIN signifie que la page peut uniquement être affichée dans un cadre sur la même origine que la page elle-même.

  • X-XSS-Protection: 1; mode=block : Cet en-tête active le filtre de scripts intersites (XSS) incorporés dans les navigateurs web. En mode block, il empêche le rendu de la page si une attaque est détectée.

  • X-Content-Type-Options: nosniff : Empêche le navigateur de faire ce qu'on appelle "MIME-type sniffing", ou autrement dit d'essayer de deviner le type MIME des réponses. Si le type MIME n'est pas valide, le navigateur ne doit pas essayer de deviner, il doit simplement rejeter les données.

  • Content-Security-Policy: default-src 'self' : Cet en-tête permet de contrôler les ressources que le navigateur est autorisé à charger pour une page. Avec default-src 'self', vous ne permettez que les sources du même domaine.


 

Désactivation des méthodes HTTP inutilisées


Lorsque vous utilisez un navigateur pour accéder à un site Web, il envoie ce qu'on appelle une requête HTTP au serveur. Cette requête peut être de différents types, ou "méthodes". Les deux méthodes les plus courantes sont "GET" (pour demander des données, comme une page web) et "POST" (pour envoyer des données, comme lorsque vous remplissez un formulaire).


Cependant, il existe d'autres méthodes HTTP, telles que "PUT", "DELETE", "OPTIONS", etc. Dans de nombreux cas, un site web n'a pas besoin de toutes ces méthodes, et certaines peuvent présenter des risques de sécurité si elles ne sont pas correctement contrôlées.


Désactiver les méthodes HTTP inutilisées signifie dire au serveur de ne pas accepter de requêtes de types dont vous n'avez pas besoin. Cela réduit les moyens dont un attaquant pourrait se servir pour causer des dégâts.


< w/ Nginx >


Dans Nginx, vous pouvez utiliser la directive limit_except pour limiter les méthodes autorisées.


Par exemple:


location / {
    limit_except GET POST {
        deny all;
    }
}

Cela signifie que seules les requêtes GET et POST sont autorisées, toutes les autres méthodes seront rejetées.


< w/ Apache >


Dans Apache, vous pouvez utiliser les directives Allow et Order pour contrôler les méthodes autorisées.


Par exemple:


<Directory "/var/www/html">
    AllowOverride None
    Order allow,deny
    Allow from all
    <LimitExcept GET POST>
        Deny from all
    </LimitExcept>
</Directory>

Semblable à l'exemple Nginx, cela permet seulement les requêtes GET et POST et rejette les autres méthodes.


C'est une bonne pratique de désactiver les méthodes HTTP que vous n'avez pas l'intention d'utiliser, car cela réduit la surface d'attaque potentielle.


 

Activation de la protection contre le déni de service


Pour protéger votre site Web contre les attaques par déni de service, vous pouvez limiter le taux de requêtes (rate limiting). Cela permet de limiter le nombre de requêtes qu'un client peut faire dans un certain laps de temps.


Les serveurs web ont généralement des options pour limiter le nombre de connexions simultanées, le temps de connexion, la taille de la requête, etc., qui peuvent tous aider à prévenir les attaques par déni de service.


Voici comment procéder avec Nginx et Apache :


< w/ Nginx >


Dans Nginx, vous pouvez utiliser le module ngx_http_limit_req_module pour limiter le taux de requêtes.


Par exemple :


http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

    server {
        ...
        location /login.html {
            limit_req zone=one;
            ...
        }
        ...
    }
}

Dans cet exemple, limit_req_zone définit une zone de mémoire nommée "one" qui stocke les adresses IP des clients, et limite le taux de requêtes à 10 par seconde. limit_req applique cette limite à une location spécifique, avec une burst rate de 20 et sans aucun délai.


< w/ Apache >


Dans Apache, vous pouvez utiliser le module mod_ratelimit pour limiter le taux de transfert, ou le module mod_evasive pour une protection plus complète contre le déni de service.


Voici un exemple de configuration avec mod_ratelimit:


<VirtualHost *:80>
    ...
    <Location "/login.html">
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 500
    </Location>
    ...
</VirtualHost>

Dans cet exemple, SetOutputFilter RATE_LIMIT active le filtrage du taux pour la location spécifiée, et SetEnv rate-limit 500 limite le taux à 500 bytes par seconde.


Pour utiliser mod_evasive, vous devrez d'abord l'installer, car il n'est pas inclus par défaut avec Apache. 


sudo apt-get install libapache2-mod-evasive

Après l'installation, vous pouvez l'activer et le configurer en ajoutant quelque chose comme ceci à votre configuration :


<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
</IfModule>

Cela définit plusieurs paramètres, tels que le nombre de requêtes autorisées par page et par site dans un certain intervalle de temps, et la période pendant laquelle un client sera bloqué s'il dépasse ces limites.


 


Activation de l'isolation du contenu: Vous pouvez configurer votre serveur pour qu'il utilise des processus ou des threads séparés pour chaque requête, ce qui peut limiter les dommages potentiels si une seule requête est compromise.




  1. Limitation du taux de requêtes (Rate Limiting): Pour prévenir les attaques par force brute ou DDoS, il peut être utile de limiter le nombre de requêtes qu'un client peut faire dans un certain laps de temps.

  2. Mise en place de pare-feu d'application web (WAF): Il s'agit d'une autre couche de sécurité qui peut aider à protéger votre application contre les attaques courantes, comme l'injection de code SQL.

  3. Utilisation de l'authentification: Si votre site contient des sections qui ne doivent pas être accessibles au public, assurez-vous d'utiliser une forme d'authentification. Apache a plusieurs modules pour cela, comme mod_auth_basic ou mod_auth_digest.

Fortifier votre Serveur Web : Guide de Sécurité pour Nginx et Apache


Lors de la configuration d'un VirtualHost sur Apache ou d'un Server Bloc sur Nginx (deux des serveurs web les plus couramment utilisés), il y a plusieurs options de sécurité que vous pouvez envisager.


Voici quelques-unes d'entre elles, bien que les détails spécifiques dépendent du type de serveur web que vous utilisez et des exigences de sécurité spécifiques à votre application.



Sommaire

Configuration de HTTPS avec Certbot

Mise à jour vers les versions HTTP/2 et HTTP/3

Désactivation de l'envoi des informations de version

Configuration des en-têtes de sécurité HTTP

Désactivation des méthodes HTTP inutilisées

Activation de la protection contre le déni de service


Configuration de HTTPS


Il s'agit de la première et la plus importante étape. HTTPS chiffre le trafic entre le client et le serveur, le rendant beaucoup plus difficile à intercepter et à lire. Vous aurez besoin d'un certificat SSL pour cela, qui peut être obtenu gratuitement via Let's Encrypt ou acheté auprès de divers fournisseurs. Une fois que vous avez un certificat, vous pouvez configurer votre serveur pour l'utiliser.


Assurez vous de remplacer "exemple.com" et "www.exemple.com" par votre domaine.


< w/ Nginx >


Voici comment vous pouvez installer Certbot et obtenir un certificat SSL pour Nginx sur un système Linux basé sur Debian (comme Ubuntu) :


Installez le logiciel Certbot et le plugin Nginx en exécutant la commande suivante :


sudo apt-get install certbot python3-certbot-nginx

Ensuite, utilisez Certbot pour obtenir un certificat SSL et configurer Nginx :


sudo certbot --nginx -d exemple.com -d www.exemple.com

Suivez les instructions à l'écran. Certbot modifiera automatiquement la configuration de Nginx pour appliquer le certificat SSL.


< w/ Apache >


Voici comment vous pouvez installer Certbot et obtenir un certificat SSL pour Apache sur un système Linux basé sur Debian (comme Ubuntu) :


Installez le logiciel Certbot et le plugin Apache en exécutant la commande suivante :


sudo apt-get install certbot python3-certbot-apache

Ensuite, utilisez Certbot pour obtenir un certificat SSL et configurer Apache :


sudo certbot --apache -d exemple.com -d www.exemple.com

Suivez les instructions à l'écran. Certbot modifiera automatiquement la configuration d'Apache pour utiliser le certificat SSL.


Certbot également tenter de renouveler automatiquement vos certificats avant qu'ils n'expirent. Vous pouvez tester le processus de renouvellement automatique avec la commande suivante :


sudo certbot renew --dry-run

 

Activation de la version 2 de HTTP


HTTP/2 est la deuxième version majeure du protocole HTTP et apporte de nombreuses améliorations en termes de performances par rapport à HTTP/1.1, notamment grâce à la multiplexation des requêtes, ce qui permet d'envoyer plusieurs requêtes en parallèle sur une seule connexion.


< w/ Nginx >


Pour activer HTTP/2 dans Nginx, vous devez simplement ajouter le paramètre http2 à vos directives listen dans la configuration de votre serveur.


Ouvrez le fichier de configuration de Nginx pour votre site. Il est généralement situé dans /etc/nginx/ ou /etc/nginx/sites-available/.


Ajoutez http2 à la directive listen pour les connexions SSL, comme suit :


server {
    listen 443 ssl http2;
    ...
}


< w/ Apache>


Pour Apache, l'activation de HTTP/2 nécessite l'utilisation du module mod_http2.


Assurez vous que le module mod_http2 est activé. Vous pouvez l'activer en exécutant la commande suivante :


sudo a2enmod http2

Ensuite, ouvrez le fichier de configuration pour votre site Apache. Cela se trouve généralement dans le répertoire /etc/apache2/sites-available/.


Ajoutez la directive Protocols pour activer HTTP/2 :


<VirtualHost *:443>
    Protocols h2 http/1.1
    ...
</VirtualHost>

Cela activera HTTP/2 pour votre site web. Notez que HTTP/2 est généralement utilisé avec HTTPS, donc assurez vous que votre site est sécurisé avec.


 

Désactivation des informations de version du serveur


Par défaut, votre serveur peut inclure des informations de version dans ses réponses via les en-têtes HTTP, ce qui peut aider les attaquants à identifier des vulnérabilités potentielles. Bien que cela puisse être utile à des fins de débogage, cela peut également fournir des informations précieuses à un attaquant potentiel. Par exemple, si votre serveur utilise une version de logiciel connue pour avoir des failles de sécurité, un attaquant peut exploiter ces failles pour attaquer votre serveur.


Il est donc préférable de désactiver ces informations de version. Voici comment vous pouvez le faire :


< w/ Nginx >


Dans Nginx vous pouvez modifier la configuration de base qui est située dans /etc/nginx/nginx.conf et utiliser la directive server_tokens pour contrôler si les informations de version du serveur sont envoyées.


Modifier le ficher de configuration par défaut :


sudo nano /etc/nginx/nginx.conf

Puis décommenter la ligne suivante (effacer le #), si elle est présente ou ajouter la.


server_tokens off;

server_tokens off; indique à Nginx de ne pas inclure les informations de version dans les en-têtes HTTP.


Cette directive peut aussi être placée dans un bloc server d'un fichier de configuration de Nginx si vous ne souhaitez pas qu'elle s'applique de façon général.


< w/ Apache >


Dans la configuration de base d'Apache, vous devez modifier le fichier de configuration principal. Le nom et l'emplacement exacts de ce fichier peuvent varier en fonction de votre système d'exploitation et de votre méthode d'installation, mais il est souvent appelé apache2.conf ou httpd.conf et se trouve généralement dans un répertoire tel que ou /etc/apache2/ ou /etc/httpd/.


Modifier le ficher de configuration par défaut :


sudo nano /etc/apache2/apache2.conf

Cherchez les directives ServerTokens et ServerSignature et modifiez-les ou ajoutez-les comme ceci :


ServerTokens Prod
ServerSignature Off

ServerTokens Prod indique à Apache de ne renvoyer que le nom du produit (c'est-à-dire "Apache") sans aucune information de version. ServerSignature Off désactive l'inclusion de l'information de version du serveur dans les pages d'erreur générées par le serveur.


Ces directives peuvent être placées n'importe où à la racine du fichier de configuration, en dehors de tout bloc <VirtualHost> ou <Directory>.


 

Configuration des en-têtes de sécurité HTTP


Il existe plusieurs en-têtes HTTP qui peuvent améliorer la sécurité de votre site web, tels que X-Content-Type-Options: nosniff (qui empêche le navigateur de "deviner" le type de contenu) et Content-Security-Policy (qui limite où le contenu peut être chargé depuis).


< w/ Nginx >


Dans Nginx, les en-têtes de sécurité peuvent être ajoutés en utilisant la directive add_header à l'intérieur d'un bloc server ou location dans le fichier de configuration (habituellement situé à /etc/nginx/nginx.conf ou /etc/nginx/sites-available/default).


Par exemple :



server {
    ...
    add_header X-Content-Type-Options nosniff;
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-XSS-Protection "1; mode=block";
    add_header Content-Security-Policy "default-src 'self'";
    ...
}

< w/ Apache >


Dans Apache, vous pouvez utiliser le module mod_headers pour ajouter des en-têtes de sécurité. Vous pouvez les ajouter à l'intérieur d'un bloc Directory, Location, ou Files dans le fichier de configuration Apache (habituellement situé dans /etc/apache2/sites-available/000-default.conf ou /etc/httpd/conf/httpd.conf).


Par exemple :


<Directory /var/www/html>
    ...
    Header always set X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"
    Header set X-Content-Type-Options "nosniff"
    Header set Content-Security-Policy "default-src 'self'"
    ...
</Directory>

Après avoir ajouté ces directives, n'oubliez pas de redémarrer ou de recharger votre serveur web pour que les modifications prennent effet.


Ces directives d'en-tête ont le même sens que ce soit pour Nginx ou Apache.


Explications :

  • X-Frame-Options: SAMEORIGIN : Empêche votre site d'être incorporé dans un iframe, ce qui peut aider à prévenir les attaques de type "clickjacking". SAMEORIGIN signifie que la page peut uniquement être affichée dans un cadre sur la même origine que la page elle-même.

  • X-XSS-Protection: 1; mode=block : Cet en-tête active le filtre de scripts intersites (XSS) incorporés dans les navigateurs web. En mode block, il empêche le rendu de la page si une attaque est détectée.

  • X-Content-Type-Options: nosniff : Empêche le navigateur de faire ce qu'on appelle "MIME-type sniffing", ou autrement dit d'essayer de deviner le type MIME des réponses. Si le type MIME n'est pas valide, le navigateur ne doit pas essayer de deviner, il doit simplement rejeter les données.

  • Content-Security-Policy: default-src 'self' : Cet en-tête permet de contrôler les ressources que le navigateur est autorisé à charger pour une page. Avec default-src 'self', vous ne permettez que les sources du même domaine.


 

Désactivation des méthodes HTTP inutilisées


Lorsque vous utilisez un navigateur pour accéder à un site Web, il envoie ce qu'on appelle une requête HTTP au serveur. Cette requête peut être de différents types, ou "méthodes". Les deux méthodes les plus courantes sont "GET" (pour demander des données, comme une page web) et "POST" (pour envoyer des données, comme lorsque vous remplissez un formulaire).


Cependant, il existe d'autres méthodes HTTP, telles que "PUT", "DELETE", "OPTIONS", etc. Dans de nombreux cas, un site web n'a pas besoin de toutes ces méthodes, et certaines peuvent présenter des risques de sécurité si elles ne sont pas correctement contrôlées.


Désactiver les méthodes HTTP inutilisées signifie dire au serveur de ne pas accepter de requêtes de types dont vous n'avez pas besoin. Cela réduit les moyens dont un attaquant pourrait se servir pour causer des dégâts.


< w/ Nginx >


Dans Nginx, vous pouvez utiliser la directive limit_except pour limiter les méthodes autorisées.


Par exemple:


location / {
    limit_except GET POST {
        deny all;
    }
}

Cela signifie que seules les requêtes GET et POST sont autorisées, toutes les autres méthodes seront rejetées.


< w/ Apache >


Dans Apache, vous pouvez utiliser les directives Allow et Order pour contrôler les méthodes autorisées.


Par exemple:


<Directory "/var/www/html">
    AllowOverride None
    Order allow,deny
    Allow from all
    <LimitExcept GET POST>
        Deny from all
    </LimitExcept>
</Directory>

Semblable à l'exemple Nginx, cela permet seulement les requêtes GET et POST et rejette les autres méthodes.


C'est une bonne pratique de désactiver les méthodes HTTP que vous n'avez pas l'intention d'utiliser, car cela réduit la surface d'attaque potentielle.


 

Activation de la protection contre le déni de service


Pour protéger votre site Web contre les attaques par déni de service, vous pouvez limiter le taux de requêtes (rate limiting). Cela permet de limiter le nombre de requêtes qu'un client peut faire dans un certain laps de temps.


Les serveurs web ont généralement des options pour limiter le nombre de connexions simultanées, le temps de connexion, la taille de la requête, etc., qui peuvent tous aider à prévenir les attaques par déni de service.


Voici comment procéder avec Nginx et Apache :


< w/ Nginx >


Dans Nginx, vous pouvez utiliser le module ngx_http_limit_req_module pour limiter le taux de requêtes.


Par exemple :


http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

    server {
        ...
        location /login.html {
            limit_req zone=one;
            ...
        }
        ...
    }
}

Dans cet exemple, limit_req_zone définit une zone de mémoire nommée "one" qui stocke les adresses IP des clients, et limite le taux de requêtes à 10 par seconde. limit_req applique cette limite à une location spécifique, avec une burst rate de 20 et sans aucun délai.


< w/ Apache >


Dans Apache, vous pouvez utiliser le module mod_ratelimit pour limiter le taux de transfert, ou le module mod_evasive pour une protection plus complète contre le déni de service.


Voici un exemple de configuration avec mod_ratelimit:


<VirtualHost *:80>
    ...
    <Location "/login.html">
        SetOutputFilter RATE_LIMIT
        SetEnv rate-limit 500
    </Location>
    ...
</VirtualHost>

Dans cet exemple, SetOutputFilter RATE_LIMIT active le filtrage du taux pour la location spécifiée, et SetEnv rate-limit 500 limite le taux à 500 bytes par seconde.


Pour utiliser mod_evasive, vous devrez d'abord l'installer, car il n'est pas inclus par défaut avec Apache. 


sudo apt-get install libapache2-mod-evasive

Après l'installation, vous pouvez l'activer et le configurer en ajoutant quelque chose comme ceci à votre configuration :


<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10
</IfModule>

Cela définit plusieurs paramètres, tels que le nombre de requêtes autorisées par page et par site dans un certain intervalle de temps, et la période pendant laquelle un client sera bloqué s'il dépasse ces limites.


 


Activation de l'isolation du contenu: Vous pouvez configurer votre serveur pour qu'il utilise des processus ou des threads séparés pour chaque requête, ce qui peut limiter les dommages potentiels si une seule requête est compromise.




  1. Limitation du taux de requêtes (Rate Limiting): Pour prévenir les attaques par force brute ou DDoS, il peut être utile de limiter le nombre de requêtes qu'un client peut faire dans un certain laps de temps.

  2. Mise en place de pare-feu d'application web (WAF): Il s'agit d'une autre couche de sécurité qui peut aider à protéger votre application contre les attaques courantes, comme l'injection de code SQL.

  3. Utilisation de l'authentification: Si votre site contient des sections qui ne doivent pas être accessibles au public, assurez-vous d'utiliser une forme d'authentification. Apache a plusieurs modules pour cela, comme mod_auth_basic ou mod_auth_digest.

Sommaire

Configuration de HTTPS

Activation de la version 2 de HTTP

Désactivation des informations de version du serveur

Configuration des en-têtes de sécurité HTTP

Désactivation des méthodes HTTP inutilisées

Activation de la protection contre le déni de service

bottom of page