Apache la directive Require de contrôle d’accès aux répertoires

Le contrôle d’accès concerne  l’accès aux fichiers du serveur. Vous contrôlez les fichiers auxquels on peut avoir accès, et à la source en autorisant les adresse IP qui peuvent voir  tel ou tel fichier.

Vous avez sans doute vu lors de paramétrage de virtual host Allow, Order Deny, à la date de 2017, le site officiel déconseille de les utiliser, ils vont disparaitre dans un avenir proche. Ils sont fournis par le mod_access_compat.

Il faut utiliser la directive Require dorénavant. Donc nous avons Require, mais aussi mod_rewrite qui nous permet de limiter l’accès à certaines parties de notre serveur. Eh oui, ce dernier ne sert pas seulement à réécrire les urls, ce qui est un peu confus. Require quant à lui est fourni par mod_authz_host.

La directive Require

Elle est très souvent utilisée, sa syntaxe est la suivante : vous pouvez contrôler par adresse IP ou nom d’hôte.

Require ip 10.20.15.2
Require ip 10.20.15.2 10.20.15.50

La syntaxe la plus simple se trouve ci-dessus, elle veut dire que seule l’adresse ip mentionnée peut accéder à la section dans laquelle Require se trouve.

Require 10.15
Require 10.15 192.168.0

Ici on donne des IP partielles, pour désigner des groupes d’IP, évitant de tout écrire !

Il y a aussi la notation par masque de sous-réseau, un peut trop technique, se référer à la documentation officielle. J’ai prix des exemples avec adresse IPV4 mais IPV6 est aussi supporté.

Require utilisé avec host au lieu de ip

Require host google.fr example.com
Require .info .biz

Les machines aux noms cités ci-dessus dont le nom se termine par google.fr ou example.com ou .info ou .biz , pourront avoir accès à la section dans laquelle se trouve cette directive. Donc foo.example.com pourra avoir accès aux ressources.

A noter :

Il va effectuer une recherche DNS inverse sur l’adresse IP pour trouver le nom d’hôte associé, puis une recherche DNS directe sur le nom d’hôte pour vérifier qu’il correspond bien à l’adresse IP originale. L’accès ne sera accordé que si le nom d’hôte correspond et si les recherches DNS inverse et directe sont cohérentes.

C’est un peu plus long mais bon pas perceptible pour nous.

Inversion des critères

Require not ip 124.32.11.55
Require not host example.org

Ainsi l’adresse IP ci-dessus sera interdite d’accès. De même les machines du domaine example.org seront interdites d’accès. Vous pouvez combiner host et ip pour affiner le ciblage.

Autoriser tout le monde

Anciennement je vous disais en début, on utilisait Allow pour autoriser tout le monde par exemple. Mais depuis Apache 2.4, des changements on eu lieu, je vous invite à lire la documentation. Et une nouvelle syntaxe à connaître (que vous voyez sans doute un peu partout):

Require all granted
anciennement 
Allow from all

Require ll denied 
replace
Deny from all

Il existe aussi d’autre directives : RequireAll, RequireNone, RequireAny. Appelé conteneurs d’autorisation, ce sont en pratique des tag xml dans lesquels vous allez mettre des directive Require.

<Directory "/www/mydocs">
    <RequireAll>
        <RequireAny>
            Require user superadmin
            <RequireAll>
            Require group admins
            Require ldap-group cn=Administrators,o=Airius
                <RequireAny>
                Require group sales
                Require ldap-attribute dept="sales"
                </RequireAny>
            </RequireAll>
        </RequireAny>
        <RequireNone>
            Require group temps
            Require ldap-group cn=Temporary Employees,o=Airius
        </RequireNone>
    </RequireAll>
</Directory>

J’ai pioché depuis la documentation officielle un exemple non commenté.

Require usage avancé

En plus des méthode de filtrage par IP et hôte, vous pouvez utiliser les variable d’environnement. En effet vous pouvez définir des variables d’environnement dans un fichier de configuration Apache. Ceci grâce au fournisseur d’autorisation générique env.

SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
<Directory "/docroot">
    Require env let_me_in
</Directory>

Dans l’exemple ci-dessus extrait de la documentation officielle, la variable d’environnement est nommée let_me_in, Require env veut dire que si la variable d’environnement est définie, l’accès au répertoire docroot  est autorisé.

Il y a en outre le fournisseur all vu plus haut.

Avec le fournisseur method, vous pouvez agir sur le type de header POST, GET etc.

Require method GET POST OPTIONS

Dans l’exemple ci-dessus seuls GET, POST et OPTIONS sont autorisées.

<RequireAny>
     Require method GET POST OPTIONS
     Require valid-user
</RequireAny>

Ici GET, POST et OPTIONS sont autorisées sans authentification, les autres méthodes sont autorisées à condition de s’authentifier. Mais quelle authentification? En fait dans Linux Apache, il y a un fichier qui contient les mots de passe, htpasswd. Le module mod_authz_user.

On parle d’une authentification au sens Apache du terme et pas PHP.

 

Lien de référence sur les fournisseurs.

J’ai dit que mod_rewrite permettait de limiter à l’accès, mais dans la mesure du possible éviter de l’utiliser et s’en tenir à Require.