Gately v0.6.5.5 est disponible

11 novembre 2026

Télécharger v0.6.5.5 · GitHub Release

Port Knocking (#80)

Le nouveau module Port Knocking (dans le groupe « Réseau ») fournit une autorisation par paquet unique (SPA) compatible avec le client fwknop : les ports protégés sont injoignables depuis l’extérieur, le client envoie d’abord un paquet de knock chiffré et authentifié, et une fois celui-ci accepté seule cette adresse source est autorisée pendant une durée limitée. Il convient à l’accès SSH direct : scp, le développement à distance depuis un IDE et les autres usages que le terminal Web ne couvre pas peuvent se connecter en sécurité depuis Internet.

• Sécurité : les paquets sont chiffrés en AES et authentifiés par HMAC, et le HMAC est vérifié avant le déchiffrement ; chaque paquet n’est utilisable qu’une fois (anti-rejeu) et les paquets dont l’horodatage sort de la fenêtre de validité (120 secondes par défaut) sont refusés ; une règle peut restreindre le nom d’utilisateur et exiger que le paquet indique l’adresse à ouvrir ;
• Blocage par le pare-feu : les paquets de knock sont reçus par défaut sur UDP 62201 ; une règle peut inscrire les ports protégés dans le pare-feu du système (nftables, ou iptables + ipset quand le noyau n’a pas nf_tables), et une adresse ayant frappé avec succès peut ouvrir de nouvelles connexions pendant la durée d’ouverture (30 secondes par défaut) ; les connexions établies ne sont pas touchées ;
• Pas de verrouillage : « Réseau local sans knock » est activé par défaut, si bien que les adresses privées et les préfixes IPv6 publics des interfaces locales n’ont pas besoin de knock (la plage de NAT opérateur 100.64.0.0/10 n’en fait pas partie), et une liste d’exemption peut être ajoutée ;
• Entrées de Gately autorisées par knock : le contrôle d’accès IP de la redirection de ports, du routage par protocole et du relais intégré de STUN peut choisir « Exiger un knock » ; Gately décide lui-même, sans droits sur le pare-feu, ce qui fonctionne aussi sous Windows, macOS et dans les conteneurs sans NET_ADMIN ;
• Un seul port ouvert : le routage par protocole peut exiger un knock par route et ajoute une route « Port Knocking » (protocole spa) qui reçoit les paquets de knock en TCP (fwknop -P tcp) ; le même port reçoit le knock puis laisse passer SSH et les autres routes ;
• Prévention d’intrusion : les knocks refusés peuvent servir de source d’événements, et le modèle intégré « Échec de knock » bannit pour un jour après 5 échecs en 10 minutes par défaut ; les paquets UDP qui échouent à l’authentification HMAC sont seulement comptés et ne sont pas utilisés, car leur source peut être usurpée ; les knocks réussis et refusés peuvent être suivis dans le centre de notifications ;
• Configuration du client : « Client » sur la carte de la règle génère la ligne de commande fwknop et une section ~/.fwknoprc, avec des clés au même format que fwknop -k.

Voir Port Knocking.

Wake-on-LAN : arrêt à distance par un agent

L’arrêt à distance gagne la méthode « Agent » : installez un agent sous Windows, Linux, macOS ou OpenWrt (comme tâche planifiée, ou comme service systemd / OpenRC, launchd ou procd). L’agent interroge Gately en long polling pour recevoir les commandes : l’appareil n’a aucun port à ouvrir et Gately ne stocke aucun identifiant de connexion de l’appareil.

• L’agent n’exécute que trois actions fixes : éteindre, redémarrer et mettre en veille ; l’API POST /api/wol/devices/{key}/shutdown accepte {"action": "reboot"} ou {"action": "sleep"} pour redémarrer ou mettre en veille ;
• Une commande est valable 10 secondes après son envoi : l’agent l’accuse d’abord et ne l’exécute qu’après la réponse de Gately ; si l’agent est hors ligne, la demande échoue immédiatement et n’est jamais mise en attente jusqu’à sa prochaine connexion ;
• La commande d’installation vérifie d’abord le SHA-256 du script et s’arrête s’il ne correspond pas ; les identifiants passent par le corps de la requête et des variables d’environnement et n’apparaissent jamais dans les URL ni dans les arguments de ligne de commande ;
• La carte de l’appareil indique si l’agent est en ligne, avec le nom d’hôte, le système et l’adresse source qu’il signale ; régénérer l’identifiant déconnecte immédiatement l’ancien agent.

Une nouvelle méthode « Requête HTTP » s’ajoute pour Home Assistant, les prises connectées et les autres services dotés d’une API HTTP : saisissez l’URL, la méthode, les en-têtes et le corps ; un code d’état 2xx vaut succès. Voir Wake-on-LAN · Agent.

Service Web : faire confiance aux utilisateurs connectés (#81)

Les sites gagnent l’option « Faire confiance aux utilisateurs connectés » : les visiteurs authentifiés par l’authentification Gately de ce site contournent le WAF, et leurs requêtes ne sont pas comptées par le sondage de chemins web de la prévention d’intrusion, pour les cas où le WAF ou les règles de chemins leurres bloquent vos propres utilisateurs. Les identifiants de confiance sont les sessions d’authentification Web, les identités de connexion tierce listées une par une dans la liste d’autorisation, l’authentification unique des utilisateurs partagés et l’authentification Basic vérifiée ; les identités autorisées par un joker fournisseur:* comme github:* ne sont pas de confiance. Les bannissements, le contrôle d’accès par IP et par pays et les limites de débit s’appliquent toujours. Voir Pare-feu WAF.

Répartition par utilisateur pour plus de types de sites (#79)

Les sites de redirection, de fichiers statiques, de panneau de navigation et de texte fixe peuvent aussi répartir par utilisateur authentifié : les utilisateurs correspondant à une règle passent par le proxy inverse vers le backend de cette règle, et les autres visiteurs sont traités selon le type de site comme avant, par exemple les administrateurs accèdent à l’administration tandis que les autres utilisateurs connectés sont redirigés vers une page d’information. Voir Service Web · Répartir par utilisateur.

Les requêtes des administrateurs contournent le WAF du site

Quand l’interface d’administration est atteinte via un site avec WAF, les requêtes portant une session administrateur valide de cette instance contournent le WAF du site : enregistrer une configuration contenant des chemins de fichiers, du HTML ou des scripts n’est plus bloqué en 403 par les règles CRS. Les comptes en lecture seule, les visiteurs et les requêtes d’administration d’autres instances restent contrôlés.

Corrections

• Paquets OpenWrt (#82) : l’apk d’OpenWrt 25.12 remplace les fichiers même après l’échec du contrôle d’architecture, si bien qu’un paquet arm64 mêlé au dossier hors ligne lors de l’intégration de paquets dans une image de firmware faisait planter le programme en boucle après le flashage. Désormais, quand apk installe un paquet d’une autre architecture, le programme gately en cours d’exécution est conservé et un message l’indique. Pour intégrer des paquets au firmware ou installer hors ligne, ne placez dans le dossier que le paquet gately correspondant à l’architecture de l’appareil ; voir Installation · OpenWrt.

Autres améliorations

• La documentation de l’API liste les endpoints de modules sans connexion (comme l’interrogation, l’accusé de réception et le téléchargement de scripts de l’agent Wake-on-LAN), précise qu’ils utilisent les identifiants propres au module et ajoute les champs de Port Knocking.

Notes de mise à niveau

• Docker : récupérez la nouvelle image et recréez le conteneur. OpenWrt : installez le nouveau .apk / .ipk par-dessus l’ancien, et installez aussi luci-app-gately de la même version si vous voulez la page LuCI. fnOS : installez manuellement le nouveau .fpk dans le Centre d’applications. Les autres installations peuvent être mises à niveau en ligne dans « Paramètres système ».
• Le blocage par le pare-feu de Port Knocking nécessite root ou CAP_NET_ADMIN ; sous Docker, utilisez le réseau host et cap_add: NET_ADMIN.