Protéger sélectivement des liens avec NPM (Nginx Proxy Manager)

Bonjour,

Nous pouvons protéger sélectivement des liens (ou dossiers) avec NPM (Nginx Proxy Manager).

Quand j’écris nous pouvons, je pense en réalité nous devrions très très fort lorsqu’il s’agit de liens d’accès à des niveaux de privilèges dans les sites ou applications que nous déployons. Les opportunités ne manquent pas d’utiliser ce type d’outil pour protéger nos serveurs, ne passons pas à côté.

J’illustre mon propos avec l’accès à l’administration et à l’administration de domaines dans Mailcow, un serveur de messagerie Internet très complet.

Paramétrage avancé dans Nginx Proxy Manager

#

Cette configuration nécessite de rentrer en paramétrage avancé, c’est-à-dire d’ajouter des lignes de code dans une zone qui apparaît dans l’interface graphique lorsque nous cliquons sur la roue crantée, visible à droite quel que soit l’onglet en cours.

Nous avons alors accès à l’espace Custom Nginx Configuration:

Configuration pour protéger un dossier admin

#

Voici une première configuration simple :

1
2
3
4
5
6

location /admin {
auth_basic "Protected";
auth_basic_user_file /data/access.auth/admin;
proxy_set_header Authorization "";
include conf.d/include/proxy.conf;
}

C’est très simple, et nous nous servons de l’include de NPM (nous n’avons pas à créer ce fichier). ¹

Note : Attention, dans cette configuration, tous les liens commençant par /admin seront inclus dans la règle comme par exemple /administration, /administrer-un-medicament, etc. On peut être plus spécifique avec location = /admin ou encore location ~ ^/admin$…

La ligne proxy_set_header Authorization ""; est importante : elle évite que le proxy envoie les éléments d’authentification à l’application. ²

Protection de deux liens

#

Nous pouvons étendre ce principe avec deux « dossiers » pour protéger par exemple

• l’administration de Mailcow (/admin) et
• l’administration de domaines dans Mailcow (/domainadmin).

1
2
3
4
5
6

location ~ ^/(admin|domainadmin) {
auth_basic "Protected";
auth_basic_user_file /data/access.auth/admin;
proxy_set_header Authorization "";
include conf.d/include/proxy.conf;
}

Autorisation d’une ou plusieurs plage(s) d’adresses IP

#

Durcissement

#

Nous pouvons « blinder » la sécurité en n’autorisant qu’une ou plusieurs adresse(s) IP à se connecter avec authentification.

C’est cette approche que je recommande, quitte à devoir « ouvrir » des plages larges. On limite les risques.

La consigne à utiliser est satisfy all. C’est la consigne par défaut, mais je trouve préférable de l’écrire explicitement lorsque nous l’utilisons.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

location ~ ^/(admin|domainadmin) {
satisfy all;
allow 192.168.1.0/24;
allow 10.0.0.0/8;
deny all;
auth_basic "Protected";
auth_basic_user_file /data/access.auth/admin;
proxy_set_header Authorization "";
include conf.d/include/proxy.conf;
}

Assouplissement

#

Nous pouvons, au contraire, assouplir la règle et autoriser une ou plusieurs adresse(s) à passer sans montrer patte blanche, c’est-à-dire sans avoir besoin de saisir un identifiant et mot de passe de protection.

La consigne est satisfy any (en lieu et place de satisfy all).

Cette approche n’est pas celle que je recommande dans la mesure où un attaquant qui réussirait à passer par une adresse autorisée aurait « porte ouverte » sans avoir besoin de connaître une paire d’identifiant et de mot de passe valide.

Puisque nous avons défini ces paires, autant nous en servir. Tout le temps, sérieusement.

Rappels au sujet de la protection par le proxy (ou le serveur)

#

Cette protection est un premier niveau de sécurité : Elle empêche d’accéder aux pages de connexion.

Elle très utile et fortement recommandée pour limiter les possibilités d’attaque sur des accès critiques. L’administration en fait évidemment partie. L’attaquant ne peut même pas essayer des combinaisons d’identifiants et mots de passe au niveau de l’application.

Utilisation par plusieurs personnes

#

Nous pouvons définir autant d’identifiants et de mots de passe que nous souhaitons.

Comme d’autres niveaux de sécurité s’ajoutent — parmi lesquels l’authentification de l’application elle-même —, nous pouvons nous accorder un petit relâchement en ne définissant qu’un compte commun pour plusieurs personnes.

Dans l’exemple que j’ai pris avec Mailcow, nous pouvons gérer

• un identifiant pour l’accès à l’administration, et
• un pour l’accès à l’administration des domaines.

Nous pouvons alors séparer les deux dossiers ainsi :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

location ^~ /admin {
    satisfy all;
    allow 192.168.1.0/24;
    deny all;
    auth_basic "Protected";
    auth_basic_user_file /data/access.auth/admin_mailcow;
    proxy_set_header Authorization "";
    include conf.d/include/proxy.conf;
}
location ^~ /domainadmin {
    satisfy all;
    allow 192.168.1.0/24;
    allow 10.0.0.0/8;
    deny all;
    auth_basic "Protected";
    auth_basic_user_file /data/access.auth/admin_domains;
    proxy_set_header Authorization "";
    include conf.d/include/proxy.conf;
}

Comment remplir le fichier des identifiants et mots de passe

#

Les fichiers ./data/access.auth/[…] de mes exemples sont à créer, tout comme le dossier ./data/access.auth (avec des noms de votre choix). J’ai choisi access.auth pour qu’il apparaisse à côté du dossier access utilisé par l’interface graphique NPM.

Pour générer les hash des mots de passe, nous pouvons utiliser openssl avec cette syntaxe :

1

openssl passwd -6 'Le_Mot.De@Passe>Que!Tout[Le#Monde+Aime%Saisirµ1000&Fois'

Note : Le -6 signifie que nous utilisons l’algorithme SHA-512.

Il suffit ensuite de coller le hash du mot de passe après l’identifiant et : comme par exemple :

1

admin_mailcow:$6$zUV7UtqsGW4Nuf38$9MKI9HZztEK4J0yyiXetf1DmjtibC8rKuGYdahq1XwuLJcekCkUDu9gr3mCcD79YUxtT4XL8G4PPqoNl6lIOV/

Nous pouvons ajouter autant de paires identifiant / mot de passe que nécessaire : une ligne par paire.

Au plaisir,

Marc JESTIN
https://marcjestin.fr