Bonjour,
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
Up !
Si la question est débile, n’hésitez pas à me le signaler 
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
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;}
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 
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)
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
Pas mal du tout. Voilà ce que ça donne chez moi :
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 !
Bonjour,
Excusez-moi de déterrer ce sujet, mais il m’intéresse particulièrement et me semble important pour la sécurité de Yunohost.
Je souhaite également limiter l’accès à l’interface d’administration web uniquement depuis mon réseau local. Car je ne suis pas encore suffisamment à l’aise avec la ligne de commande…
Si je comprends bien, il faut modifier 2 fichiers:
allow 127.0.0.1;
allow 192.168.1.0/24;
allow 192.168.192.0/24;
deny all;
allow 192.168.1.0/24;
allow 192.168.192.0/24;
deny all;
Est-ce bien ça?
Merci pour vos prochaines réponses et bons messages à tous!
Salut,
Plus ou moins 
En réalité cela serait plutot
Avec, de mémoire et par défaut, adresse_du_lan/CIDR =
Pour vérifier et pour être sure, récupère l’adresse ip d’une machine au sein de ton LAN et si ton masque de sous réseau est bien 255.255.0 ou /24, ce sont deux notations équivalentes, prend compte le 3ème nombre.
adresse machine = 192.168.100.1/24 → sous réseau = 192.168.100.0/24
PS: je n’ai pas testé en soit le paramétrage de nginx (même si il me semble correcte), je t’indique juste le sous réseaux que tu dois renseigner.
Hello,
Je me permets juste de rebondir pour dire que ce filtre marche uniquement en IPv4.
En IPv6, il n’est pas possible à ma connaissance de faire la distinction local/extérieur… En tout cas je n’ai jamais réussi 
Hello!
Merci pour la rapidité de vos réponses! 
OK! Chez moi, la box est au 192.168.1.1, donc 192.168.1.0/24, juste?
Merci pour la précision de l’IPv6. Je suis en IPv4, donc ça devrait fonctionner!
Je teste un de ces 4 et fais un retour ici!
Encore merci et à+!
Ah ? Pourtant il y a aussi un mécanisme similaire aux IP locales d’IPv4 (192.168.x.x et 10.0.x.x) en IPv6 … c.f. Unique local address - Wikipedia et les IP comme fc00, fd00::
Au passage, si ça intéresse des gens, ce serait pertinent d’intégrer ce mécanisme dans Yunohost directement via un paramètre (comme les settings qui gère les ciphers de la conf nginx). C’est quelque chose de pas très compliqué à faire, ça fait une bonne “première contribution” pour quelqu’un.e intéressé.e par contribuer au projet, on peut guider sur comment procéder si besoin.
Effectivement, mais je pense qu’avec une box grand public, on ne peut pas affecter d’adresse IPv6 à un matos (en tout cas, sur ma Freebox je ne sais allouer que de l’IPv4)
Du coup, quand un client se connecte à Yunohost en IPv6, il utilise son adresse «externe» unique automatiquement alloué par la box, qui n’est pas dans les ranges locaux.
Mais si tu sais comment faire, ça m’intéresse parce que je voudrais pouvoir faire ça pour mon package domoticz (pour n’autoriser que des capteurs locaux à se connecter au serveur)
Mouarf ouai je vois … en fait c’est parce que les addresses sont pas NATées … (on a tellement du NAT partout qu’on oublie comment c’est censé fonctionner sans NAT)
Du coup je pense tout de même que ton IPv6 globale fait parti du même prefix … genre ta box à un /56, et c’est lui qu’il faudrait mettre dans le “allow” … Par contre si pour une raison quelconque ton préfixe IPv6 change spontannément ça peut tout bloquer car il faudrait pouvoir mettre à jour la config nginx en conséquence …