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ées

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

• <Directory ...> ... </Directory> : Les règles concernent les fichiers et sous-répertoires sous le répertoire spécifié à toute l'arborescence en dessous.
• <Files ...> ... </Files> : Les règles concernent les fichiers spécifiés.
• <Location ...> ... </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. On ne l'abordera pas mais les règles agissent de la même façon.

Dans ces balises, on spécifie un paramètre qui correspond respectivement à un nom de répertoire ou de fichiers.

• Exemples pour "<Directory>":

Dans le fichier "/etc/httpd/conf/httpd.conf", on trouve les lignes suivantes:

---

<Directory />
 Require all denied
</Directory>

---

Elles permettent de protéger, bloquer tout accès à toute l'arborescence de la machine via sa racine ("/"). Elles sont fondamentales.

On peut ouvrir des sous parties de l'arborescence par la suite; par exemple:

---

<Directory /web/wordpress>
 Require all granted
</Directory>

---

on ouvre l'arborescence du sous-répertoire "/web/wordpress".

• Exemple pour "<Files>":

Dans le fichier "/etc/httpd/conf/httpd.conf", on trouve les lignes suivantes:

---

<Files ".ht*">
 Require all denied
</Files>

---

qui protègent principalement les fichiers ".htaccess" qui contiennent des directives de configuration d'Apache; elles ne doivent pas être consultables au travers d'un interface Web.

Règles

Les règles viennent avec la directive "Require" suivie de divers paramètres; nous n'aborderons que les cas les plus courants:

• Require all granted : Elle donne accès à tous.
• Require all denied : Elle bloque l'accès à tous.
• Require ip <adresse IP> : Elle donne l'accès au groupe d'adresses IP.
• Require not ip <adresse IP> : Elle bloque l'accès au groupe d'adresses IP.
• Require local : Elle donne l'accès à la machine locale; elle est équivalente à la règle "Require ip 127.0.0.1".
• Require host <nom de machine> : Elle donne accès à la machine nommée.
• Require not host <nom de machine> : Elle bloque accès à la machine nommée.

Prenons l'exemple simplifié, d'un fichier de configuration pour le CMS WordPress:

• On donne l'accès à tous.

---

DocumentRoot "/web/wordpress"
<Directory /web/wordpress>
  Require all granted
</Directory>

---

• On ne donne l'accès qu'au réseau local ("192.168.1.0/24") et à la machine locale,; les autres sont bloqués.

---

DocumentRoot "/web/wordpress"
 
<Directory /web/wordpress>
  Require all denied
  Require local
  Require ip 192.168.1
</Directory>

---

Notons que la règle:

---

Require ip 192.168.1

---

est équivalente à:

---

Require ip 192.168.1.0/24

---

ou

---

Require ip 192.168.1.0/255.255.255.0

---

• On veut donner l'accès à tous mais restreindre l'accès aux outils d'administration qu'aux machines du réseau local.

---

DocumentRoot "/web/wordpress"
 
<Directory /web/wordpress>
  Require all granted
</Directory>
 
<Directory /web/wordpress/wp-admin>
  Require all denied
  Require ip 192.168.1
</Directory>

---

• On ajoute l'impossibilité de s'authentifier sauf pour ceux du réseau local. Pour y arriver, on filtre l'accès au fichier "wp-login.php".

---

DocumentRoot "/web/wordpress"
 
<Directory /web/wordpress>
  Require all granted
 
  <Files wp-login.php>
    Require all denied
    Require ip 192.168.1
  </Files>
</Directory>
 
<Directory /web/wordpress/wp-admin>
  Require all denied
  Require ip 192.168.1
</Directory>

---

Avec un peut d'habitude, dans un site, il y a beaucoup de sous-répertoires qui ne nécessitent pas un accès direct de l'utilisateur car ils sont seulement utilisés par Apache en interne au travers par exemple du sous-processus PHP.

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 ne 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 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

Authentification

Apache intègre un contrôle d'accès via une authentification d'un utilisateur. Cette approche est élémentaire mais elle peut aider si le site n'inclut pas cette stratégie. Nous allons seulement aborder le cas le plus simple, celle de base.

La première étape consiste à créer un fichier où sont repris les couples "nom d'utilisateur" et son "mot de passe":

htpasswd -c <nom de fichier d'authentification> <utilisateur> <mot de passe>

Exemple:

htpasswd -c /etc/httpd/conf.d/perso.users pdupond BateauIvre

Par la suite l'option "-c" est à remplacer par "-b" pour ajouter d'autres utilisateurs.

Dans le fichier de configuration d'Apache d'un site Web personnel, on ajoute les lignes suivante:

---

DocumentRoot "/web/perso"
 
<Directory /web/perso>
  AuthType Basic
  AuthBasicProvider file
  AuthUserFile /etc/httpd/conf.d/perso.users
  AuthName "Accès au site Perso"
 
  Require valid-user
</Directory>

---

On utilise une authentification de base ("Basic") sur base d'un fichier ("file") dont on donne le nom correspondant à celui créé plus haut. Enfin on utilise une règle qui sert à valider une authentification réussie ("Require valid-user").

---

→ retour au serveur Web

---