Chez hadoly, tous les services sont adressés en ipv6 en interne. Lorsqu’une requête en ipv4 arrive sur notre réseau, elle est traduite par un nat46 qui transforme l’adresse en ipv6/96 + l’ipv4/32. (tayga + bird)
Jusqu’à il y a peu, nous n’avions jamais observé de problème (Ça ne veut pas dire qu’il n’y en avait pas).
Récemment, un de nos utilisateurs nous a signalé une différence de traitement entre un accès ipv4 vs un accès ipv6. Une requête en ipv4 met 25 secondes de plus qu’une requête ipv6. Ça correspond au comportement par défaut de la protection anti brute force de nextcloud. Confirmé dans les logs.
Sauf que la blackliste opère un /64. Une erreur de login par un client en ipv4 only a pour conséquence de retarder de 25s toutes les requêtes en ipv4 de tous les clients ipv4 only. C’est brutal.
Nous avons contourné le problème mais ce n’est pas satisfaisant même si cela supprime le faux positif.
De fait, si nous avions choisi une infrastructure interne ipv4 only et un front ipv6|ipv4, nous n’aurions pas ce problème. Mais bon… On ne peut pas non plus blamer Nextcloud de faire un choix par défaut différent du notre. Cependant, on ne peut pas modifier ce comportement car il n’est pas configurable dans nextcloud.
Du coup, des chatons ont-ils été confrontés à ce même comportement, trouvés des solutions ? Je pense à @chapril qui, de mémoire, utilise également nat64 ?
PS Notre machine s’appelle perceval. Mais ça n’a aucun rapport.
If you are behind a reverse proxy or load balancer it is important you make sure it is setup properly. Especially the trusted_proxies and forwarded_for_headers config.php variables need to be set correctly. Otherwise it can happen that Nextcloud actually starts throttling all traffic coming from the reverse proxy or load balancer. For more information see Reverse proxy.
Ça n’est pas à proprement parler une configuraiton de nextcloud, mais au moins en définissant les bons headers http tu évites de ralentir tout le monde
Je ne comprends pas bien, définir correctement le X-Forwarded-For (en y mettant l’ip réelle du client) me semble une très bonne façon de faire (et standard qui plus est) ? Ou bien j’ai loupé quelque chose ?
Ce n’est pas recommandé, le « /64 » d’une ip6 désigne réellement l’équivalent d’une « ip4 » (en plus flexible, mais les 64 derniers bits sont plutôt vus comme « plusieurs ip possibles pour la même machine »). Ça s’en ressent avec les règles de routage standard qui traitent différemment ces /64 par rapport à ce qu’il y a au dessus.
S’il y a un problème qui serait reglé par ça, c’est sans doute qu’il y a un problème à la base pour identifier « réellement » le client au niveau de l’infrastructure
C’est ce qu’il faut faire pour régler ton souci, mais encore une fois je te conseille de bien y réfléchir.
tu vas troquer un blocage trop fort d’ip4 (parce que tu ne sais pas identifier une ip4) contre un blocage trop faible d’ip6 : c’est trivial de créer une ip dans un /64, donc un attaquant qui possède une ip6 aura droit à 2^64 essais avant de se faire bloquer (ajoute à ça la taille de la table de blocage qui va prendre une taille monstrueuse pendant l’attaque)
Une autre solution se trouve quelques lignes plus haut dans la fonction getEmbeddedIpv4 : il faudrait que tu implémentes ta règle de traduction là dedans pour identifier l’ip4 au milieu d’une ip6 (tout en laissant les « vraies » ip6 tranquilles)
Pas forcément. Nous disposons d’un range ipv6 2001:912:3000::/36
Je vois mal comment un attaquant pourrait forger une ipv6 modulo notre range. La seule façon de faire cela signifierait que l’attaquant a en fait utiliser une ipv4 que notre nat46 traduit dans les 32 bit de poids faible de l’ipv6 de notre service. Du coup, il passerait par le bruteforce.
Cependant, tu as raison. à contrario cela signifie qu’un attaquant en ipv6 peut forger 2^64 adresse ipv6 toute considérée comme unique. Là, la table de blocage pourrait enfler. Alors que le comportement par défaut du bruteforce permet d’éviter cela.
Après, j’ai peut-être pas tout compris.
En fait je disais qu’en modifiant pour utiliser un /128 tu allais permettre toute personne ayant une ip6 (donc probablement « au moins » un /64) de forger une attaque contre toi.
Une personne ayant une ip4 ne peut pas faire une telle attaque, vu qu’elle va se retrouver dans ton /36 avec une règle bien définie.
Donc ma solution, c’était d’extraire (en modifiant getEmbeddedIpv4) de 2001:912:3000::123a:5678 l’ip4 (ici 18.58.86.120) et d’utiliser ça plutôt que 2001:912:3000::123a:5678/128. Ainsi si quelqu’un vient de 2a01:4f8:141:53e7::1 (true ip6) il pourra pas utiliser 2a01:4f8:141:53e7::2, créable « trivialement », pour tenter une nouvelle attaque
@stephane chez @chapril on est en dual stack en interne et en externe (excepté pour des cas particuliers). La conf nginx du frontal, en revanche, adresse le service en IPv4 en interne. Je n’ai pas connaissance d’un soucis de la nature que tu décrit, il faudrait faire des tests.
De fait, votre service nextcloud ne doit pas être impacté par le problème que nous avons observé sur notre installation. Dans notre cas, toute notre infra interne est adressée en ipv6 only ce qui introduit les faux positifs de l’anti bruteforce. Ainsi si un user se trompe en s’identifiant en ipv4, cela provoque le blocage de toute la plage ipv4.
Ceci dit, une solution transitoire a été mis en place pour corriger cela. Mais elle n’est pas satisfaisante.
Alors, j’avais commencé à écrire un patch sur les conseils d’ @immae , mais au fur et à mesure de me rendre compte de la complexité de la regex à établir, j’ai abandonné… Reste, la solution de l’entête http. je vais essayer sur une installation martyr.
Je dois pouvoir t’écrire le patch, je n’ai pas l’impression qu’il soit si compliqué que ça à écrire. Peut être que tu as essayé de faire plus compliqué que nécessaire
Est-ce que tu veux que je m’y colle ?
Ah mais grand merci. Cependant, vu qu’il n’y a pas de caractère d’urgence puisque nous avons une solution transitoire, peut-être qu’on peut réflechir avec @tcit à un truc un peu plus ambitieux que juste faire un patch pour nous.
Je veux dire qu’il est quand même temps de favoriser le passage général à ipv6 par défaut… même pour nextcloud. Quand Qu’en pensez-vous ?
