Discussion :

[Stéphane le calme]

Renforcement de la sécurité des connexions réseau : OpenSSH introduit des mécanismes punitifs pour contrer les comportements malveillants,
ces mécanismes viennent qui viennent fortifier les options de suivi de l'état

La protection contre les comportements malveillants est une priorité constante. Récemment, OpenSSH a franchi une étape significative dans cette lutte en introduisant de nouvelles options de configuration pour pénaliser les comportements indésirables. OpenSSH, l’outil de référence pour les connexions sécurisées à distance, a ajouté deux nouvelles options à sa configuration : PerSourcePenalties et PerSourcePenaltyExemptList. Ces options permettent à sshd, le démon SSH, de surveiller et de pénaliser les comportements problématiques des clients.

sshd est le démon du protocole SSH (Secure Shell) fourni par OpenSSH. Il écoute les connexions entrantes des clients et démarre un nouveau processus pour chaque nouvelle connexion afin de gérer l’échange de clés, le chiffrement, l’authentification, l’exécution de commandes et l’échange de données.

Dans un commit récent, Damien Miller (djm@) a introduit les nouvelles options de configuration de sshd(8), PerSourcePenalties et PerSourcePenaltyExemptList, afin de fournir une facilité intégrée dans sshd(8) lui-même pour pénaliser un comportement indésirable, et pour protéger des clients spécifiques de la pénalité, respectivement.

Le fonctionnement des nouvelles options est le suivant :

Lorsque PerSourcePenalties est activé, sshd surveille le statut de sortie de ses processus de session pré-authentification. Si un client tente à plusieurs reprises une authentification infructueuse ou provoque un crash de sshd, cela peut indiquer une tentative d’attaque ou d’exploitation. En réponse, sshd enregistrera une pénalité contre l’adresse du client. Si la durée de cette pénalité dépasse un seuil minimum, les connexions provenant de cette adresse seront refusées. Des infractions répétées entraîneront des pénalités plus sévères, jusqu’à un maximum configurable.

Pour sa part, la liste PerSourcePenaltyExemptList permet d’exempter certaines plages d’adresses de toutes pénalités. Bien que ces options soient désactivées par défaut, les développeurs prévoient de les activer automatiquement dans un avenir proche.

Voici le message de Damien Miller :

« Ajout d'une fonctionnalité à sshd(8) pour pénaliser certains comportements problématiques de clients, contrôlée par deux nouvelles options de sshd_config(5) : PerSourcePenalties et PerSourcePenaltyExemptList.

« Lorsque l'option PerSourcePenalties est activée, sshd(8) surveille l'état de sortie de ses processus enfants de session de préauthentification. Grâce à l'état de sortie, il peut observer les situations dans lesquelles la session ne s'est pas authentifiée comme prévu. Ces conditions incluent les tentatives répétées d'authentification du client sans succès (ce qui peut indiquer une attaque contre un ou plusieurs comptes, par exemple en devinant le mot de passe), ou lorsque le comportement du client a provoqué le plantage de sshd (ce qui peut indiquer des tentatives d'exploitation de sshd).

« Lorsqu'une telle situation est observée, sshd enregistre une pénalité d'une certaine durée (par exemple 30 secondes) sur l'adresse du client. Si cette durée est supérieure à un seuil minimal spécifié par les PerSourcePenalties, les connexions à partir de l'adresse du client seront refusées (ainsi que toutes les autres dans la même plage CIDR PerSourceNetBlockSize).

« En cas d'infractions répétées de la part de la même adresse client, les pénalités seront plus importantes, jusqu'à un maximum configurable. Une option PerSourcePenaltyExemptList permet à certaines plages d'adresses d'être exemptées de toute pénalité.

« Nous espérons que ces options rendront beaucoup plus difficile pour les attaquants de trouver des comptes avec des mots de passe faibles ou devinables ou d'exploiter des bogues dans sshd(8) lui-même.

« PerSourcePenalties est désactivé par défaut, mais nous prévoyons de l'activer automatiquement dans un futur proche ».

Cette nouvelle fonctionnalité vient s'ajouter aux options de suivi de l'état

Cette nouvelle fonctionnalité vient s'ajouter aux options de suivi de l'état, déjà bien connues et appréciées, et n'est pour l'instant disponible que dans OpenBSD -current, mais il est presque certain qu'elle sera disponible dans la prochaine version d'OpenBSD 7.6.

Pour mémoire, les options de suivi d’état (Stateful Tracking Options) dans OpenBSD sont une partie intégrante du pare-feu PF (Packet Filter), qui est utilisé pour filtrer le trafic réseau. Ces options permettent à PF de suivre l’état ou la progression d’une connexion réseau, ce qui est essentiel pour la sécurité et la gestion efficace du trafic

Le suivi d’état fait référence à la capacité de PF à suivre l’état d’une connexion réseau en stockant des informations sur chaque connexion dans une table d’état. Cela permet à PF de déterminer rapidement si un paquet qui traverse le pare-feu appartient à une connexion déjà établie. Si c’est le cas, le paquet est autorisé à passer à travers le pare-feu sans subir d’autres contrôles.

Options de suivi d’état

Une série d’options liées au suivi d’état peut être appliquée sur une base par règle. Parmi celles-ci, on trouve keep state, modulate state, ou synproxy state, qui doivent être spécifiées explicitement pour appliquer ces options à une règle :

• keep state: Crée une entrée d’état pour les connexions correspondant à la règle.
• modulate state: Modifie les numéros de séquence initiaux des connexions TCP pour une meilleure sécurité.
• synproxy state: Utilisé pour protéger contre les attaques SYN flood en proxyfiant les connexions TCP initiales.

États Flottants

Les états flottants (floating states) peuvent correspondre à des paquets sur n’importe quelle interface, ce qui est l’opposé des états liés à une interface (if-bound). C’est le comportement par défaut.

En somme, les options de suivi d’état dans OpenBSD PF offrent aux administrateurs système des moyens avancés pour surveiller et contrôler le trafic réseau, assurant ainsi une meilleure sécurité et une gestion optimisée des ressources réseau.

Activation par défaut

Quelques heures plus tard, dans un autre commit, Damien Miller a déclaré :

Message du journal : activation des PerSourcePenalties par défaut.

ok markus

NB. Si vous utilisez un sshd qui accepte des connexions derrière de grands blocs de NAT, des proxies ou toute autre chose qui regroupe de nombreux utilisateurs possibles derrière quelques adresses IP, alors ce changement peut entraîner le refus du trafic légitime.

Veuillez lire les options PerSourcePenalties, PerSourcePenaltyExemptList et PerSourceNetBlockSize dans sshd_config(5) pour savoir comment régler votre sshd(8) en fonction de vos circonstances spécifiques.

Conclusion

Ces nouvelles fonctionnalités d’OpenSSH sont un pas en avant dans la sécurisation des connexions et la prévention des attaques. Elles offrent aux administrateurs système un outil supplémentaire pour protéger leurs serveurs contre les comportements malveillants, renforçant ainsi la robustesse de la sécurité informatique.

Sources : commits (1, 2), Options de suivi d’état

Et vous ?

Quelle est votre opinion sur l’introduction des options PerSourcePenalties et PerSourcePenaltyExemptList par OpenSSH ?
Comment ces nouvelles fonctionnalités pourraient-elles changer la manière dont vous gérez la sécurité de vos serveurs ?
Pensez-vous que la pénalisation des comportements indésirables est une approche efficace pour renforcer la sécurité des systèmes ? Pourquoi ?
Avez-vous déjà rencontré des problèmes de sécurité que ces nouvelles options auraient pu prévenir ?
Quels autres mécanismes de sécurité aimeriez-vous voir implémentés dans OpenSSH ou d’autres outils similaires ?

[kain_tn]

Pensez-vous que la pénalisation des comportements indésirables est une approche efficace pour renforcer la sécurité des systèmes ? Pourquoi ?

Augmenter le temps entre les tentatives d'authentification infructueuses est en général une bonne idée. De ce que j'en comprends, là, c'est lié à l'IP plutôt qu'au compte. En entreprise, ça peut éviter de verrouiller plusieurs comptes. Pourquoi pas. Il faut voir si ça ne peut pas être détourné pour en faire une attaque.

Et pendant ce temps là, les GAFAM affaiblissent la sécurité globale de l'informatique en implémentant des failles comme Recall ou Memory