Webadmin : La restriction d'accès ne fonctionne pas

Bonjour,

Veuillez trouver ci-dessous la description de mon problème.

Mon serveur YunoHost

Matériel: Vieil ordinateur à la maison
Version de YunoHost: x.x.x
J’ai accès à mon serveur : En SSH | En direct avec un clavier/écran
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : oui
Si oui, expliquer:

J’ai voulu limiter l’accès à la partie webadmin à seulement deux adresses IP depuis la page “Accueil / Outils / Paramètres de YunoHost” en basculant l’option “Activer la liste des IP autorisées pour l’administration Web” sur “Oui” et en ajoutant les adresses IP retenues.

Depuis j’ai un beau
403 Forbidden
nginx

en lieu et place de la page d’administration.

J’ai vu que l’on pouvait récupérer la page d’administration en modifiant les fichiers ‘/etc/nginx/conf.d/yunohost_admin.conf.inc’ et ‘/etc/nginx/conf.d/yunohost_api.conf.inc’. Ce qui fonctionne très bien au passage.

Par contre, comment doit-on renseigner la page d’administration pour que le blocage des IP fonctionne correctement ?

Description du problème

403 Forbidden
nginx

Merci de m’avoir lu jusqu’ici

Steve

Bonjour,

À défaut de réponse, est-ce que quelqu’un pourrait me partager ses fichiers gérant la restriction d’accès du Webadmin afin que je puisse comprendre ce qui ne va pas et surtout le corriger.

D’avance merci

Steve

Hello @Steve
Je ne suis pas sûr de répondre à ta question :
J’ai laissé la restriction d’accès par défaut et j’ai ceci dans mon fichier 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;

location = /yunohost/admin/index.html {
    etag off;
    expires off;
    more_set_headers "Cache-Control: no-store, no-cache, must-revalidate";
}

location /yunohost/admin/applogos/ {
    alias /usr/share/yunohost/applogos/;
}

more_set_headers "Content-Security-Policy: upgrade-insecure-requests; default-src 'self'; connect-src 'self' https://paste.yunohost.o>
more_set_headers "Content-Security-Policy-Report-Only:";

}

et ceci dans yunohost_api.conf.inc :

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”;
proxy_set_header Host $host;

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

}

Yunohost admin output complete 502 error page, so use only plain text.

location = /yunohost/api/error/502 {
return 502 ‘502 - Bad Gateway’;
add_header Content-Type text/plain;
internal;
}

Salut, quel est ton réglage ? Quelles adresses IP ont été renseignées ?

Ce paramètre fonctionne à merveille chez moi avec la configuration suivante (les IP masquées sont une IPv4 et une IPv6 publiques) :

Bonjour OniriCorpe,

Lors de mon essai, j’avais mis deux IPv4 locales. Depuis il faut que je supprime les lignes contenant ‘allow’ et ‘deny’ des fichiers :

  • /etc/nginx/conf.d/yunohost_admin.conf.inc
  • /etc/nginx/conf.d/yunohost_api.conf.inc

Mais cela empêche, par la suite, tout modification depuis le webadmin qui m’indique à chaque tentative :
Le fichier de configuration ‘/etc/nginx/conf.d/yunohost_admin.conf.inc’ a été modifié manuellement et ne sera pas mis à jour
Le fichier de configuration ‘/etc/nginx/conf.d/yunohost_api.conf.inc’ a été modifié manuellement et ne sera pas mis à jour

Peut-être qu’il existe une solution qui permet de forcer la regénération de ces deux fichiers. Par contre, je n’ai rien trouvé pour le moment en ce sens.

J’utilise les lignes de commandes pour cela

yunohost settings set security.webadmin.allowlist.enabled -v False ou True (False= désactiver True=activer)

Et pour autoriser une ip

yunohost settings set security.webadmin.allowlist -v  <IP_ADDRESS>

Pour connaître l’ip de ma machine
curl ifconfig.me

Pour régénérer la conf nginx tu peux essayer

yunohost tools regen-conf nginx -n -d
yunohost tools regen-conf nginx --force
1 Like

Il faudra certainement aussi mettre les IPv4 privés les IPv6 ou les plages IPv6 privées

Bonjour à tous,

@rodinux: Merci pour les commandes qui permettent de forcer la génération des fichiers de configuration de nginx.

@OniriCorpe: Effectivement, mettre les IPv4 et les IPV6 résout la deuxième partie de mon problème.

@Cyril: Les fichiers m’ont surtout été utiles pour voir qu’hormis les lignes allow et deny, je n’ai pas de différence.

En conclusion, le problème était l’absence d’adresse IP après la directive allow et la désynchronisation qui résultait de mes modifications manuelles.

Merci à tous

Steve

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.