Ne pas rendre l'interface de Yunohost disponible sur internet

Bonjour,
Je n’ai pas trouvé d’information pertinente sur internet ni en parcourant le forum.
Je viens d’installer Yunohost, surtout pour NextCloud, après on verra pour d’autres applications.

Actuellement, j’ai mon serveur derrière le Freebox Delta:

  • j’ai un nom de domaine en xxx.freeboxos.fr
  • j’ai redirigé les ports 80 et 443 vers mon serveur

Ce qui me surprend, c’est que l’interface utilisateurs et administration de yunohost soit accessible depuis internet. J’aimerai que seules les applications soient accessibles sur Internet, pas la configuration de yunohost.

Est-ce possible ?
Est-ce en utilisant un domaine local lors de l’installation ? Puis enregistré le domaine ouvert sur Internet par la suite ?

Merci pour votre aide

Bonjour,

Tu peux restreindre l’interface d’administration en local:

Ajout: Si tu veux que ce soit automatique et que le diagnostique ne râle pas sans ignorer les modifications apportées par les mises à jour, le mieux est d’utiliser un ‘hook custom’ en créant le fichier /etc/yunohost/hooks.d/conf_regen/16-nginx_local avec le contenu suivant:

#!/bin/bash
network_address=$(awk '{print $1}' <(grep kernel <(ip route)))
action=$1
pending_dir=$4
nginx_dir=$pending_dir/../nginx/etc/nginx
nginx_ynh_admin=$nginx_dir/conf.d/yunohost_admin.conf.inc
nginx_ynh_api=$nginx_dir/conf.d/yunohost_api.conf.inc

[[ $action == "pre" ]] || exit 0
[[ -d $nginx_dir ]] || exit 0
[[ -e $nginx_ynh_admin ]] || exit 0
[[ -e $nginx_ynh_api ]] || exit 0
sed -i "0,/location/!b;//a\    allow $network_address;\n    deny all;" $nginx_ynh_admin
sed -i "0,/location/!b;//a\    allow $network_address;\n    deny all;" $nginx_ynh_api

Et tu passes la commande yunohost tools regen-conf nginx pour que les modifications soient prises en compte. Cette commande est utile que la 1ère fois, ensuite les modifications seront maintenues avec les mises à jour.

Attention, vérifie avant que

 awk '{print $1}' <(grep kernel <(ip route))

te renvois bien l’adresse du réseau, j’ai pas trouvé mieux. Ca fonctionne chez moi mais j’ai un doute queça marche partout. Au pire si cette commande ne marche pas pour toi, tu inscris “en dur” dans le fichier l’adresse sour la forme 192.168.0.0/24 (à adapter à ton cas) à la place de $network_address.

1 Like

Je vais essayer ça dans la journée.
Je vous tiens au courant.

Merci beaucoup !

La tournure de phrase est tout de même curieuse … La “configuration” de ton Yunohost est autant accessible que la configuration du compte twitter de Nicolas Sarkozy, a.k.a : il y a un login/mot de passe, on rentre pas comme dans un moulin

1 Like

C’est sûr que la sécurité repose d’abord et avant tout sur les techniques utilisées pour se protéger.

Mais j’aime bien y ajouter un peu de « sécurité par l’obscurité » en insérant une chaîne aléatoire dans les URLs. Ça ne mange pas de pain, et en cas de zero-day, on peut ainsi être passé sous le radar de tous ces vilains pirates :wink:

Pour l’API d’administration je trouve cela rassurant d’ajouter ce filtrage IP.
L’étape d’après ce serait d’avoir un 2FA sur cet accès.

La tournure de phrase est tout de même curieuse … La “configuration” de ton Yunohost est autant accessible que la configuration du compte twitter de Nicolas Sarkozy, a.k.a : il y a un login/mot de passe, on rentre pas comme dans un moulin

Je préfère administrer en local.
Il est quand même préférable de ne pas laisser une porte ouverte, même sécurisée, si on en a pas besoin.
La perte de contrôle d’un mail ou d’un compte twiter, ca peut-être ennuyeux.
Perdre toutes les données d’un serveur, c’est plutôt le scénario catastrophe.

Personnellement, j’ai cela en retour:

default
192.168.1.0/24

Donc, je rajouterais grep /

 awk '{print $1}' <(grep kernel <(ip route | grep /))

Ah? J’avais essayé sur plusieurs machines avant de poster mais j’avais raison d’avoir un doute vu ta réponse. Oui dans ce cas, le grep supplémentaire permet de filtrer et reste compatible même si il n’y a qu’une réponse (celle sans le default).

Attends, quand j’ai lu cette discussion j’avais un terminal ouvert sur mon Proxmox (donc Debian, j’ai pas cherché plus loins) et sa sortie est celle que j’ai indiquée.
La sortie de ip route est la suivante :

default via monip dev vmbr1 proto kernel onlink 
monip/24 dev vmbr1 proto kernel scope link src iprouteur

Pourquoi, il y a kernel dans avec proxmox et pas avec yunohost ? bonne question, j’ai pas cherché!
Mais pour être sûr je viens d’exécuter la commande sans ma modification sur mon yunohost et la sortie est la suivante:

<monippublique>/24
172.17.0.0/16

Le réseau 172.17.0.0/16est le réseau de Docker… qui est stopé!

172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 

Donc tant à faire je mettrais cela pour ta commande:

 awk '{print $1}' <(grep kernel <(ip route | egrep -v "docker|default"))

Après je ne connaissais pas cette syntaxe <(), la première idée qui me serait venu serait d’utiliser $().

cela fonctionne comment ? On modifie l’URL du panneau d’administration classique ?

Pour l’instant, je ne sais pas faire… :man_shrugging:
Et d’après Aleks, c’est pas recommandé d’aller modifier directement la config nginx :sweat:
Donc je compte sur fail2ban :slight_smile:

D’accord,
Du coup j’ai opté pour une désactivation de l’API graphique du panneau d’administration, avec un script ON/OFF quand j’ai besoin d’y avoir accès.

1 Like

En plus, j’ai l’impression que fail2ban n’est pas utilisé pour l’interface admin… En tout cas, rien n’apparaît dans les logs (alors que pour le SSO, je le vois bien et j’ai déjà réussi à déclencher un bannissement).

Peut-être est-ce dû au fait que ça se fait sous forme de requête XHR ?

Mais ça fait donc une raison de plus pour ne pas laisser l’interface accessible en permanence.

Dans ce cas c’est un bug et il faut le notifier pour qu’on le corrige … personne ne devrait avoir à choisir entre “avoir une webadmin” ou “être exposé à une attaque brute force”

Il y a effectivement une typo simple à corriger dans la regle fail2ban, donc je vais push un correctif …

2 Likes

Disons qu’à ce niveau là de l’histoire, je savais juste que je ne voyais rien. Ça aurait pu être fait autrement… :blush:

J’ai appliqué le patch et effectivement, je vois maintenant l’adresse IP dans les logs !