Restreindre l'accès de l'interface admin au réseau local

fr

#1

Bonjour,

  • Yunohost Stretch à jour (x86, Debian 9.6)

Je souhaiterais restreindre l’accès de l’interface web d’administration au réseau local.

Aujourd’hui je peux y accéder en tapant https://monsite.noho.st/yunohost/admin/#/login
J’aimerais que ça ne soit plus accessible depuis le web mais uniquement via le réseau local, donc https://192.168.1.50/yunohost/admin/#/login

Est-ce possible ou dois-je désactiver l’interface web d’administration ?

Merci


#2

Up !

Si la question est débile, n’hésitez pas à me le signaler :smile:


#3

Sorry pour le manque de réponse,

Je n’avais pas de solution simple à proposer puis en fait je me suis dis qu’il y avait un mécanisme pour faire ça dans nginx.

Tu peux regarder ce post : https://serverfault.com/questions/667798/allow-only-local-users-in-nginx

En gros, il faut rajouter dans la conf nginx correspondantes (un truc comme /etc/nginx/conf.d/yunohost_admin.conf je pense des lignes comme :

    allow 192.168.0.1/24;
    allow 192.168.1.1/24;
    allow 127.0.0.1;
    deny all;

dans le bloc correspondant à la route/location /yunohost/admin.

Il y a peut-être un deuxieme fichier à modifier, celui dans /etc/nginx/conf.d/domaine.principal.tld.d/yunohost_admin.conf (pas sur…)

Après avoir fait les modifs, il faut recharger nginx avec systemctl reload nginx


#4

Je n’ai pas ce fichier (juste un yunohost_local.conf).

J’ai modifié /etc/nginx/conf.d/yunohost_admin.conf comme suit, mais je peux toujours accéder à la page de login pour administrer via un réseau non-local (exemple : en 4G via mon malinphone).
Note : Mon réseau local est en 192.168.2.x

server {
listen 80 default_server;
listen [::]:80 default_server;

location / {
    return 302 https://$http_host/yunohost/admin;
    allow 192.168.0.1/24;
    allow 192.168.2.1/24;
    allow 127.0.0.1;
    deny all;

}

location /yunohost/admin {
    return 301 https://$http_host$request_uri;
    allow 192.168.0.1/24;
    allow 192.168.2.1/24;
    allow 127.0.0.1;
    deny all;

}

}

server {
# Disabling http2 for now as it’s causing weird issues with curl
#listen 443 ssl http2 default_server;
#listen [::]:443 ssl http2 default_server;
listen 443 ssl default_server;
listen [::]:443 ssl default_server;

ssl_certificate /etc/yunohost/certs/yunohost.org/crt.pem;
ssl_certificate_key /etc/yunohost/certs/yunohost.org/key.pem;
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:50m;

# As suggested by Mozilla : https://wiki.mozilla.org/Security/Server_Side_TLS and https://en.wikipedia.org/wiki/Curve25519
# (this doesn't work on jessie though ...?)
# ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

# As suggested by https://cipherli.st/
ssl_ecdh_curve secp384r1;

ssl_prefer_server_ciphers on;

# Ciphers with intermediate compatibility
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.6.2&openssl=1.0.1t&hsts=yes&profile=intermediate
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-$

# Ciphers with modern compatibility
# https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=nginx-1.6.2&openssl=1.0.1t&hsts=yes&profile=modern
# Uncomment the following to use modern ciphers, but remove compatibility with some old clients (android < 5.0, Internet Explorer < 10, ...)
#ssl_protocols TLSv1.2;
#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-S$

# Uncomment the following directive after DH generation
# > openssl dhparam -out /etc/ssl/private/dh2048.pem -outform PEM -2 2048
#ssl_dhparam /etc/ssl/private/dh2048.pem;

# Follows the Web Security Directives from the Mozilla Dev Lab and the Mozilla Obervatory + Partners
# https://wiki.mozilla.org/Security/Guidelines/Web_Security
# https://observatory.mozilla.org/
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header 'Referrer-Policy' 'same-origin';
add_header Content-Security-Policy "upgrade-insecure-requests; object-src 'none'; script-src https: 'unsafe-eval'";
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header X-Frame-Options "SAMEORIGIN";

location / {
    return 302 https://$http_host/yunohost/admin;
    allow 192.168.0.1/24;
    allow 192.168.2.1/24;
    allow 127.0.0.1;
    deny all;

}

location /yunohost {
    # Block crawlers bot
    if ($http_user_agent ~ (crawl|Googlebot|Slurp|spider|bingbot|tracker|click|parser|spider|facebookexternalhit) ) {
        return 403;
    }

    # Redirect most of 404 to maindomain.tld/yunohost/sso
    access_by_lua_file /usr/share/ssowat/access.lua;
}

include conf.d/yunohost_admin.conf.inc;
include conf.d/yunohost_api.conf.inc;

}


#5

Pour ma part, j’ai uniquement bloqué l’API et ça fait le taf.
Le fichier que j’ai modifié est /etc/nginx/conf.d/yunohost_api.conf.inc
Sinon recherche “api” dans le dossier /etc/nginx (grep -ri ‘api’ /etc/nginx)

Il faut modifier la partie qui concerne l’API :
(c’est ma config qui marche en prod actuellement)

location /yunohost/api/ {
    proxy_read_timeout 3600s;
    proxy_pass http://127.0.0.1:6787/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    allow 127.0.0.1;
    allow 192.168.1.0/24;
    allow 192.168.192.0/24;
    deny all;

    # Custom 502 error page
    error_page 502 /yunohost/api/error/502;
}

Et même si Aleks a écrit l’inverse, je crois qu’il est plus propre d’écrire 192.168.2.0/24 et non pas 192.168.2.1/24 :wink:


#6

Hum j’ai aussi bloqué l’interface apparement :

admin@taboulisme:~$ cat /etc/nginx/conf.d/yunohost_admin.conf.inc
# Avoid the nginx path/alias traversal weakness ( #1037 )
rewrite ^/yunohost/admin$ /yunohost/admin/ permanent;

location /yunohost/admin/ {
    alias /usr/share/yunohost/admin/;
    default_type text/html;
    index index.html;
    allow 192.168.1.0/24;
    allow 192.168.192.0/24;
    deny all;

    # Short cache on handlebars templates
    location ~* \.(?:ms)$ {
      expires 5m;
      add_header Cache-Control "public";
    }
}

N’oublie pas de reload nginx (sudo systemctl reload nginx)


#7

C’est une solution intéressante.
Pour ma part j’ai créer deux scripts l’un qui s’appelle ON et l’autre OFF

ON : service yunohost-api start
OFF : service yunohost-api stop

Peut être pas bon de jouer avec sa mais au moins sa coup l’interface administrateur quand je n’en ais pas besoin.
G


#8

Pas mal du tout. Voilà ce que ça donne chez moi :

  • monsite.noho.st/yunohost/admin via :
    - PC du réseau local : API ne répond pas
    - Hors réseau local (exemple : malinphone en 4G) : API ne répond pas
  • adresse-ip-locale/yunohost/admin via :
    - PC du réseau local : répond
    - Hors réseau local : API ne répond pas
  • adresse-ip-publique/yunohost/admin via :
    - PC du réseau local : API ne répond pas
    - Hors réseau local : API ne répond pas

Je n’ai donc un accès à la page web d’administration qu’en utilisant une machine du réseau local et en utilisant l’adresse ip locale du serveur, c’est très bien.

Avant de mettre une coche “résolu”, j’aimerais améliorer le truc en redirigeant vers ou en affichant une page custom plutôt que de voir le petit pacman tenter sa chance 5 secondes avant d’échouer avec “l’API ne répond pas”.

Je présume qu’il faut changer quelque chose dans le bloc “#custom 502…” ?


@Guilermo : Merci, mais je cherche une solution perenne. N’hésite pas cependant à publier ton script, ça servira peut-être à d’autres membres !