Ssh, radvd et systemd

Support Debian
#1

Bonjour,

Je suis en train de construire une passerelle ipv6 avec Debian 9.9.

J’ai installé ssh serveur pour pouvoir accéder à cette passerelle depuis mon PC de bureau et radvd pour distribuer des adresses ULA sur mon réseau local.

Mon problème est le suivant :

Lorsque systemd lance le serveur ssh, le daemon radvd n’a pas été lancé, ce qui fait qu’a priori, l’interface réseau n’a pas encore d’adresse ipv6. Le serveur ssh qui est configuré pour ne répondre qu’en ipv6 ne part pas.

Pour l’instant, j’ai trouvé une solution de secours en programmant l’adresse ipv6 de mon interface réseau local sur la passerelle dans le fichier :etc/network/interfaces et ça fonctionne.

cependant, ça ne me plaît pas car il y a deux mécanismes qui se marchent un peu sur les pieds pour attribuer l’adresse ipv6 à mon interface réseau et si, par exemple, je veux changer le préfixe du réseau local dans radvd et que j’oublie de faire la même chose dans /etc/network/interfaces, ça va planter (déjà qu’il faut que je programme aussi cette adresse en dur dans /etc/sshd_config).

L’idée qui m’est venue est d’ajouter “radvd.service” à la ligne :
After=network.target auditd.service
du fichier /etc/systemd/system/sshd.service

Sauf que ce fichier contient la ligne :
WantedBy=multi-user.target
et que le fichier radvd.service est contenu dans le répertoire /etc/systemd/system/multi-user.target.wants

J’ai donc peur de créer un deadlock (multi-user.target attend sshd qui lui-même attend radvd…).

Quelqu’un a une idée ?

Amicalement.

Jean-Marie

#2

L’interface d’un routeur sur laquelle radvd émet des annonces devrait être configurée en statique de toute façon (avec une adresse “simple” pour faciliter la configuration statique des machines du réseau si besoin). D’autre part l’activation de la fonction routeur IPv6 (net.ipv6.conf.all.forwarding=1) désactive l’auto-configuration d’adresse sans état (SLAAC) sur toutes les interfaces de la machine (il fut un temps où radvd forçait forwarding=1 ou refusait de se lancer si forwarding=0). Certes avec les noyaux assez récents une nouvelle valeur [EDIT] accept_ra=2 a été introduite pour pouvoir activer le routage sans désactiver l’auto-configuration. Mais je trouve anormal qu’un routeur auto-configure les adresses de ses interfaces avec ses propres annonces. Cette configuration sera plutôt utilisée sur une interface qui fait face à l’extérieur et ne diffuse pas d’annonces de routeur. [/EDIT]

Ben oui, c’est comme ça. C’est pareil avec un démon serveur DHCP.

Il suffit de configurer sshd_config pour écouter sur toute adresse IPv6 locale, et pas seulement celle qui doit être affectée à l’interface. Fixer une adresse en dur dans un service alors qu’elle est configurée dynamiquement sur l’interface n’est pas cohérent. En règle générale, l’adresse d’un serveur ne devrait jamais être configurée dynamiquement.

#3

Bonjour Pascal et merci pour ta réponse.

En ipv4, effectivement, il faut fixer l’adresse de l’interface de manière statique. Cela ne souffre aucune contestation.

En ipv6, sur un serveur (ou une passerelle), la partie basse de l’adresse est connue (un mélange de l’adresse mac, de “fffe” et d’un bit forcé à 1). Par contre, la partie haute (le préfixe), en particulier sur le réseau local, est fixée par le daemon radvd.

Et si je fais abstraction du problème de démarrage du serveur ssh, ça fonctionne très bien. Je ne vois donc pas pourquoi je devrais m’embêter à fixer le préfixe une fois dans /etc/network/interfaces et une autre fois dans /etc/radvd.conf

Enfin, dans sshd_config, la seule directive que j’ai trouvée pour dire au serveur où écouter est ListenAddresses qui réclame une adresse ip.

Alors, je peux toujours lui dire
ListenAdresses ::
et ensuite n’autoriser via ip6tables le port 22 QUE sur l’adresse ULA de l’interface du réseau local mais je ne trouve pas ça très propre.

Amicalement.

Jean-Marie

#4

IPv4 ou IPv6, c’est pareil : dans la mesure du possible, un serveur ou un routeur devraient avoir des adresses IP configurées de façon statique. La seule exception concerne l’adresse IP de l’interface faisant face à l’extérieur lorsque celle-ci est obligatoirement attribuée dynamiquement par le réseau amont (le FAI en général).

Le mécanisme d’auto-configuration d’adresse IPv6 sans état (SLAAC) à partir des annonces d’un routeur (RA) est facultatif, et normalement il ne s’applique pas aux interfaces d’un routeur (qui émet lui-même des annonces, et ne doit pas être affecté par les annonces d’un autre routeur).

La partie basse d’une adresse IPv6 auto-configurée n’est pas forcément fixe. D’une part elle ne se base pas forcément sur l’adresse MAC de l’interface (cf. les adresses temporaires aléatoires des “privacy extensions”) et d’autre part l’adresse MAC elle-même n’est pas forcément fixe : certaines plates-formes (notamment des cartes à base de SoC style ARM) n’ont pas d’adresse MAC attribuée et en génèrent une aléatoirement à chaque démarrage.

Si tu veux fixer une adresse dans sshd_config, tu dois fixer cette adresse “en dur” sur l’interface. Il faut être cohérent. Si tu veux garantir cette cohérence, tu peux écrire un script qui va écrire le préfixe et l’adresse dans tous les fichiers de configuration à partir d’une source unique.

Mais pourquoi veux-tu restreindre sshd à l’adresse ULA de l’interface faisant face au réseau local ? Si ton but est de n’autoriser les connexions SSH que depuis le réseau local, alors ce n’est pas la bonne méthode car l’adresse est joignable des deux côtés. La bonne méthode consiste à utiliser ip6tables en se basant sur l’interface et non l’adresse.

#5

Ben…, c’est le cas sur ma passerelle (au moins pour la partie basse de l’adresse qui est fixe).

Et admettons que je fixe la partie basse de l’adresse ipv6 ULA dans un fichier de conf lié à l’interface, il n’y a aucune raison que je le fasse pour le préfixe.

Là, je suis d’accord avec toi sur le bien fondé de ne définir les choses qu’à un seul endroit. Je vais réfléchir à un script “coherence_reseau” qui pourrait être lancé par systemd tout au début et qui mettrait à jour les fichiers de configuration avant le lancement des daemons.

ssh, c’est la porte grande ouverte vers la passerelle. S’il n’y a qu’une chose à protéger, c’est bien ça.
L’adresse ULA de l’interface réseau local n’est bien évidemment pas joignable via l’interface réseau qui donne accès à internet (c’est fait pour).
De toutes manières, les règles ip6tables que j’ai mises en place filtrent déjà sur les interfaces et les adresses réseau (adresse complète ou préfixe).
Je vais donc “ouvrir” ssh au niveau de son fichier de config et on n’en parlera plus.

Amicalement.

Jean-Marie

#6

“Grande ouverte”, il ne faut pas exagérer. SSH est censé être sécurisé et utilisable à travers l’internet public.

Bien sûr que si. N’importe quelle adresse du routeur est joignable via n’importe laquelle de ses interfaces, selon le modèle “weak host” appliqué par le noyau Linux. Cela ne veut pas forcément dire qu’elle est joignable depuis tout l’internet public car normalement l’adresse ULA n’est pas routée sur l’internet public, mais baser sa sécurité sur les réglages faits par d’autres (qui contrôlent les tables de routage des routeurs amont) n’est pas une bonne pratique, et l’adresse est en tout cas joignable depuis une machine connectée directement au réseau amont.

#7

J’ai dû mal m’exprimer.
Ce que j’ai voulu dire, c’est qu’en tant qu’attaquant, si tu as réussi à te connecter en ssh sur une machine, tu en fais ce que tu en veux. Ce qui ne veut pas dire que ssh est une passoire (quoi que, mal configuré…).

Pour ce qui est de l’adresse ULA de mon routeur, j’ai vérifié : injoignable à partir de l’interface de mon routeur côté internet. Le parefeu y est peut-être aussi pour quelque chose (/sbin/ip6tables -A forward-internet-local ! -d $prefix_UGA -j DROP).

Amicalement.

Jean-Marie

#8

Comment as-tu vérifié concrètement ? Depuis une machine connectée directement au même réseau local que l’interface côté internet et configurée correctement (adresse IPv6 dans le préfixe de ce réseau externe et route vers le préfixe ULA via l’adresse du routeur dans le préfixe externe) ?

Si la chaîne forward-internet-local est appelée depuis la chaîne FORWARD comme son nom le laisse supposer, alors elle n’a aucun effet sur les paquets entrants destinés aux adresses de la machine, qui sont traités par la chaîne INPUT.

#9

J’ai eu un doute sur la chaîne ip6tables concernée.

J’ai aussi cette ligne : /sbin/ip6tables -A input-internet ! -d $ip_interface_internet_UGA -j DROP

Et il est à noter que cette adresse, construite à partir du préfixe fourni par ma box et l’adresse MAC de la carte réseau est fixe.

Amicalement.

Jean-Marie

#10

Si la chaîne input-internet est appelée depuis la chaîne INPUT pour les paquets reçus par l’interface externe, alors elle bloque effectivement les paquets destinés à une autre adresse que $ip_interface_internet_UGA que je suppose être l’adresse globale de l’interface externe.

Notes :

  • Pour le bon fonctionnement du protocole IPv6 il faut accepter certains paquets reçus par cette interface destinés à d’autres adresses (adresse link local en fe80:: de l’interface, adresses multicast link local) pour le protocole NDP. Ces paquets doivent donc être acceptés par d’autres règles placées avant celle-ci.

  • Si le rôle du routeur est de faire communiquer le réseau local avec l’internet via une box internet, l’utilisation d’un préfixe ULA sur le réseau local impose de faire du NAT sur le routeur, comme avec les adresses privées en IPv4. Dans ce cas pourquoi utiliser un préfixe ULA ? Un des principaux objectifs d’IPv6 était d’étendre l’espace d’adressage et disposer de suffisamment d’adresses globales de façon à ne plus devoir utiliser des adresses privées ou locales et du NAT sur tout réseau ayant besoin d’une connectivité internet globale…

#11

Ben…, non.
Sur mon réseau local, les machines ont trois types d’adresses :

  • leur adresse link local (fe80:…),
  • une adresse unicast local address (fd…:…) dynamique,
  • une adresse unicast global address dynamique.

L’adresse LL (link local) sert pour les échanges de bas niveau (découverte de voisins notamment).

L’adresse ULA sert pour le traffic local de haut niveau (ssh, ipp, imap, smtp ; j’ai un serveur mail local).

L’adresse UGA sert à aller sur internet. Et ma passerelle ne fait pas de NAT ipv6.

Tu poses la question “pourquoi utiliser un préfixe ULA ?” ; je pense qu’il faudrait plutôt que tu te poses la question “pourquoi ont-ils inventé ces adresses ULA ?”

Amicalement.

Jean-Marie

#12

Oui. Le préfixe global peut très bien servir pour le trafic local.

Ne détourne pas la question. Je sais très bien pourquoi on a inventé les ULA : précisément quand on n’a pas d’adresses globales.

#13

Bonsoir PascalHambourg,

Je suis d’accord avec toi : Dans les faits, une adresse UGA peut très bien servir pour du trafic local. Ce n’est pas forcement pour cela que c’est une bonne chose (on peut réussir à visser une vis avec la pointe d’un couteau ; ce n’est pas pour cela que c’est une bonne chose et ça va beaucoup mieux avec un tourne-vis adapté). Je suis pour la séparation des mondes (informatiques et réseau) et je pencherais plutôt pour ne pas utiliser ces adresses pour du trafic qui ne réclame pas de posséder une adresse avec une portée planétaire (genre mon PC qui discute avec le serveur d’impression local).

Cela dit, je n’ai pas une religion bien établie à ce sujet et je suis complètement ouvert à la discussion (mais faut venir avec des arguments).

Pour ce qui est de l’usage des adresses ULA, j’ai lu ça :

https://tools.ietf.org/html/rfc4193

http://livre.g6.asso.fr/index.php/ULA

https://www.22decembre.eu/fr/2016/12/02/ula/

Nulle part il y est question de l’usage des adresses ULA UNIQUEMENT quand on ne peut obtenir une adresse UGA. D’ailleurs, il est explicitement prévu dans le protocole ipv6 qu’une interface peut (doit) avoir plusieurs adresses.

Alors, je n’ai vraiment pas l’impression de botter en touche, et si tu as des arguments pour me faire comprendre pourquoi j’ai tort, je serai ravi de les entendre.

Amicalement.

Jean-Marie