LINUX:HTTP - Gestion des accès

---

→ retour au serveur Web

---

But

Un aspect très important a trait à la gestion des accès à vos sites Web en totalité ou partiellement. Il a été abordé partiellement dans d'autres articles.

Nous allons passer en revue différentes approches globales ou particulières.

FireWall - IPTABLES

Un FireWall apporte une approche globale pour toute la machine.

Filtrage de base

Nous utilisons IPTABLES. Voyez l'article sur Firewall ou mur de feu.

Classiquement le port TCP/80 est utilisé pour le service HTTP et le port TCP/443 pour le service HTTPS. Il est possible d'utiliser d'autres ports.00

Dans les configurations qui suivent, nous ne présenterons que la partie strictement concernant le service HTTPD paramétré par défaut en entrée:

• L'ouverture globale permet à tous d'avoir accès à vos sites Web.

---

...
-A INPUT -p tcp -m tcp --dport 80  -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
...
-A INPUT -j DROP

---

• On peut vouloir ne donner l'accès qu'à certaines machines selon les adresses IP. Dans cet exemple, nous ne donnons l'accès qu'aux machines de notre LAN privé "192.168.1.0/24". Dans cette optique, on pourrait donner l'accès qu'à un partenaire de confiance selon son adresse IP publique.

---

...
-A INPUT -p tcp -m tcp --dport 80  -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -s 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
...
-A INPUT -j DROP

---

• On peut vouloir bloquer une machine particulière ("95.214.27.19") car elle nous fait régulièrement des attaques de type DOS mais ouvrir aux autres.

---

...
-A INPUT -p tcp -m tcp --dport 80  -s 95.214.27.19                            -j DROP
-A INPUT -p tcp -m tcp --dport 443 -s 95.214.27.19                            -j DROP
-A INPUT -p tcp -m tcp --dport 80                  -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443                 -m conntrack --ctstate NEW -j ACCEPT
...
-A INPUT -j DROP

---

Ces règles peuvent être démultipliées selon nos besoins.

Attention, l'ordre des règles est important. Par exemple, dans l'exemple précédent, si nos deux premières lignes de type "DROP" sont placées après nos lignes de type "ACCEPT", la machine "95.214.27.19" ne sera jamais bloquée. Car dès qu'une demande d'accès rentre dans les critères d'une règle, cette règle est appliquée et le traitement n'est pas poursuivi.

Filtrage par pays

Il est possible d'ajouter une fonctionnalité de filtrage à IPTABLES en suivant l'article sur XTABLES-ADDONS.

Un de ces filtrages peut se faire sur base du pays d'origine de la requête. Chaque pays a à sa disposition des tranches d'adresses IP; celles-ci sont regroupées dans une base de données. IPTABLES interroge celle-ci qui doit être mise à jour régulièrement.

Voici deux types d'approche:

• Empêcher l'accès de requête provenant de divers pays, dans l'exemple, la Chine et la Russie.

---

...
-A INPUT -p tcp -m tcp --dport 80  -m geoip --src-cc CN,RU    -j DROP
-A INPUT -p tcp -m tcp --dport 443 -m geoip --src-cc CN,RU    -j DROP
-A INPUT -p tcp -m tcp --dport 80  -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
...
-A INPUT -j DROP

---

• Ne permettre l'accès qu'à certains pays, dans l'exemple, la Belgique et ses pays limitrophes.

---

...
-A INPUT -p tcp -m tcp --dport 80  -m geoip --src-cc BE,FR,NL,DE,LU -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m geoip --src-cc BE,FR,NL,DE,LU -m conntrack --ctstate NEW -j ACCEPT
...
-A INPUT -j DROP

---

Remarque

Il ne faut pas oublier de contrôler les accès en sortie. Nombre de sites Web font des accès vers d'autres sites Webs par exemple pour récupérer un script JavaScript ou une image hébergés sur une autre machine publique. Ils peuvent aussi envoyer des informations sur votre machine ou vos clients sans votre accord ou même valider une clé d'utilisation.

HTTPD - Apache

De son côté, Apache possède des contrôles d'accès beaucoup plus fins.

Ces règles peuvent être placées dans les fichiers ".htaccess", pour autant qu'ils soient activés via la directive "AllowOverride All" mais nous préférons les mettre dans les fichiers de configuration d'Apache pour avoir une vue centralisée, facile à sauvegarder.

Accès de base

Nous allons passer en revue quelques fonctions autour de la directive "Require" venant avec la version 2.4 d'Apache. Elles viennent avec les modules "mod_authz_core" et "mod_authz_host". Auparavant il existait une directive semblable que nous n'aborderons pas car elle est déconseillée.

Portée

Les règles doivent se retrouver à l'intérieur des balises:

• <Directory> : Les règles concernent les fichiers et sous-répertoires sous le répertoire spécifié à tous niveaux hiérarchiques.
• <File> : Les règles concernent les fichiers spécifiés.
• <Location> : Les règles ont une portées indépendantes des répertoires et fichiers. Elles concernent les gestionnaires d'Apache (handlers) spécifiés par la directive "SetHandler". On a rencontré quelques cas dans l'article sur les Informations et Activités d'Apache.

Gestion groupée des règles

Il existe trois groupes de balises qui permettent une gestion de type logique des règles; elles peuvent être imbriquées pour un contrôle d'accès complexe:

• <RequireAny> ... </RequireAny> : Au moins une des règles du groupe doit être validée. Elles sont définies par défaut.
• <RequireAll> ... </RequireAll> : Toutes les règles du groupe doit être validée.
• <RequireNone> ... </RequireNone> : Aucune les règles du groupe doit être validée.

Une règle peut donner l'accès ou la refuser.

Exemple 1:

---

Require all denied
Require ip 192.168.1

---

est équivalent à:

---

<RequireAny>
 Require all denied
 Require ip 192.168.1
</RequireAny>

---

Exemple 2:

---

<RequireAll>
 <RequireAny>
   Require ip local
   Require ip 192.168.1
 </RequireAny>
 Require valid-user
</RequireAll>

---

Pour avoir accès, le machine client doit être soit locale ("127.0.0.1" ou "localhost") soit du réseau local "192.168.1.0/24". En outre l'utilisateur auquel on demande une authentification doit être correctement validé par le couple nom d'utilisateur et son mot de passe. Nous avons ici une combinaison d'une logique "ET" et "OU" imbriquées

.

---

→ retour au serveur Web

---