Stoppez le brute-force SSH sur vos serveurs Linux

Oui. L'agent ne fait que lire le journal de sécurité de son propre système et bloquer les connexions entrantes vers les ports protégés de cette même machine. Il n'effectue que des requêtes HTTPS sortantes et n'ouvre aucun port entrant.

Oui. La décision de blocage est prise localement sur l'agent : la protection continue avec la dernière politique appliquée même si le cloud est injoignable.

L'agent détecte automatiquement le port SSH réel via sshd_config et les sockets en écoute, et reconstruit ses règles en cas de changement. Le port FTP est détecté de la même manière.

Non. Lors de l'installation, votre adresse IP actuelle est ajoutée à la liste blanche, et les sources de la liste blanche ont toujours priorité sur tout blocage.

Toute distribution moderne basée sur systemd - Debian, Ubuntu, RHEL/CentOS/Alma/Rocky, Fedora - sur x86-64 et ARM64. Un seul binaire statique, sans dépendances supplémentaires.

Les paiements internationaux passent par PayPro Global, les paiements en Russie par YooKassa, et la cryptomonnaie est disponible en solution de repli. Le forfait Free est permanent et ne demande pas de carte.

Avec SSH Protector, j'installe l'agent en tant que service systemd : il lit le journal d'authentification localement, détermine le port sshd réel et après un seuil d'une fenêtre de temps, bloque le réseau source dans le pare-feu système. J'ajoute à l'avance mon adresse ou mon VPN à la liste blanche, je contrôle l'historique dans le panneau et j'enregistre la dernière politique lorsque je perds Internet.

Gratuit sans SSH Protector Je désactive PasswordAuthentication et PermitRootLogin, laisse les clés sur Ed25519, limite AllowUsers/AllowGroups et autorise uniquement le port depuis VPN ou CIDR de confiance. Si un mot de passe est temporairement requis, je configure fail2ban à l'aide de journald/auth.log, vérifie nftables/iptables, définit findtime, maxretry et bantime, et teste régulièrement les exceptions à partir de la console de sauvegarde.

Avec SSH Protector, je bloque la source sur les échecs de connexion, quel que soit le nom essayé, et je peux étendre l'interdiction au réseau de l'attaquant. Je vérifie le port SSH trouvé, ajoute le VPN administratif à la liste blanche et utilise une solution d'agent local pour que la protection ne dépende pas de la disponibilité du panel.

Gratuitement, je désactive le mot de passe et les connexions root, crée un utilisateur distinct avec sudo, télécharge une clé unique via cloud-init et ferme le groupe de sécurité sur le VPN/mes réseaux. Je supprime les authorized_keys inutilisées, active MFA sur le bastion, configure les alertes fail2ban et de mot de passe/clé publique acceptés pour les sources inconnues ; J'envisage de changer le port uniquement pour réduire le bruit.

Avec SSH Protector, j'installe un agent statique qui lit les événements locaux et bloque la source dans le pare-feu jusqu'à ce que le compte soit compromis. J'utilise la protection gratuite du premier serveur, je mets ma chaîne sur liste blanche et je m'assure que l'agent continue de fonctionner hors ligne ; Je laisse la sauvegarde et le moindre privilège en tant que couches distinctes.

Gratuitement, je verrouille SSH derrière WireGuard/Tailscale, désactive les mots de passe et root, exige une clé avec une phrase secrète et me limite à sudo. Je stocke les sauvegardes en dehors du VPS avec des informations d'identification distinctes, j'active les mises à jour de sécurité automatiques, fail2ban et l'audit des connexions réussies ; Je vérifie la console d'urgence du fournisseur avant de resserrer le pare-feu.

Avec SSH Protector, j'utilise un binaire statique pris en charge pour l'architecture et systemd appropriés, j'active l'analyse des journaux locaux et le blocage du pare-feu sans port de contrôle entrant. Je vérifie la compatibilité du système d'exploitation et du pare-feu avant l'installation, je configure une liste blanche de gestion et je m'assure que l'agent ne surcharge pas les ressources limitées de l'appareil.

Gratuitement, je ne publie pas du tout SSH en externe : je connecte l'appareil via VPN, désactive le mot de passe et le root, autorise une clé et un sous-réseau de contrôle. Je mets à jour le firmware, désactive les services inutilisés, définis le fail2ban minimum uniquement s'il y a suffisamment de mémoire et enregistre la configuration du pare-feu ; Pour un système d'exploitation non pris en charge, je choisis une passerelle externe plutôt qu'un binaire inconnu.

Avec SSH Protector, j'active la lecture des journaux SSH et FTP pris en charge, je laisse l'agent déterminer les ports et j'applique une règle locale unique au réseau source. J'ajoute des intégrations fiables à la liste blanche, vérifie l'historique dans le tableau de bord et prends en compte le fait que la protection FTP avancée et les fonctionnalités supplémentaires peuvent dépendre du tarif.

Gratuitement, je remplace le FTP classique par SFTP sur SSH ou FTPS, si le protocole est vraiment nécessaire, et je ferme le service sur tout Internet. Je crée des prisons fail2ban distinctes pour sshd et FTP, je les dirige vers un nftables défini avec un délai d'attente, je vérifie le format du journal après les mises à jour et je désactive les comptes partagés.

Avec SSH Protector, je laisse le blocage automatique du réseau sur toutes les sources externes et je mets sur liste blanche uniquement le VPN contrôlé, et non toutes les adresses IP domestiques. J'utilise le panneau pour les attaques, mais je sauvegarde l'identité dans des comptes et des clés Unix séparés : l'agent protège le périmètre et je révoque l'accès en supprimant une clé spécifique.

Gratuitement, je gère les authorized_keys de manière centralisée via Ansible, j'émets une clé par personne et par appareil avec un commentaire clair, je désactive les comptes partagés et je limite sudo. J'active VPN/MFA sur le bastion, fixe la période d'accès dans l'inventaire, collecte la clé publique acceptée avec empreinte digitale dans SIEM et supprime automatiquement la clé à la fin du contrat.

Avec SSH Protector, je sépare les adresses des coureurs de confiance via une liste blanche précise et laisse toutes les autres sources bloquées en cas d'échec de connexion. Je ne considère pas que cela remplace le contrôle des clés : l'agent réduit la force brute de l'extérieur tandis que les restrictions du compte de service lui-même contiennent les conséquences d'une authentification réussie.

Gratuitement, j'utilise une clé Ed25519 distincte pour le travail, je la stocke dans un magasin secret, je la limite dans authorised_keys via from=, command=, no-port-forwarding, no-agent-forwarding et no-pty. J'autorise uniquement SSH à partir du réseau d'exécution, j'émets un minimum de commandes sudo, je fais régulièrement pivoter la clé et j'enregistre une empreinte digitale dans le journal de déploiement.

Avec SSH Protector, j'installe d'abord une couche de protection supplémentaire et mets en liste blanche l'adresse administrative actuelle pendant que j'effectue la migration. L'agent bloque la force brute active, prend automatiquement en compte le port réel et laisse la stratégie hors ligne, mais après avoir vérifié avec succès les clés, je désactive toujours la connexion par mot de passe.

Gratuitement, j'ouvre une deuxième session SSH et la console du fournisseur, j'ajoute une clé unique, je vérifie les autorisations ~/.ssh 700 et authorised_keys 600, j'exécute sshd -t et je recharge sans fermer la première session. Ensuite, je définis le numéro de PasswordAuthentication, le numéro de KbdInteractiveAuthentication et le numéro de PermitRootLogin, vérifie la nouvelle connexion et enregistre la clé d'urgence séparément.

Avec SSH Protector, je bloque immédiatement les sources et les réseaux actifs, vérifie l'historique des attaques et laisse l'accès uniquement via une liste blanche de confiance. Ensuite, je change le mot de passe/clé publique, mets fin aux sessions et analyse séparément le mot de passe/clé publique accepté ; le blocage réduit la fenêtre d'attaque, mais ne prouve pas l'absence d'une connexion déjà réussie.

Gratuitement, je ferme temporairement le groupe de sécurité SSH ou nftables au VPN, bloque l'utilisateur, révoque les clés et modifie les secrets associés. Je vérifie last/lastlog, journalctl, sudo, les nouveaux utilisateurs/clés, les unités cron/systemd, les processus et les connexions réseau, puis restaure l'accès par clé uniquement et désactive les mots de passe réutilisés.

Avec SSH Protector, je continue de bloquer la force brute externe et de détecter les sources suspectes, mais je ne m'y fie pas pour trouver la bonne clé volée. Je supprime immédiatement l'empreinte digitale de tous les serveurs, émets une nouvelle clé avec une phrase secrète et laisse la liste blanche uniquement pour le VPN ; J'examinerai séparément les entrées réussies.

Gratuitement, je recherche l'ancienne clé publique sur toutes les authorized_keys, la révoque par gestion de la configuration et vérifie la clé publique acceptée par empreinte digitale et source. J'émets un matériel FIDO2/ed25519-sk ou une clé avec une phrase secrète et un délai d'expiration de l'agent ssh, je désactive le transfert d'agent sauf si nécessaire et je tiens un registre du propriétaire, de l'appareil et des dates de rotation.

Avec SSH Protector, je joins un historique des attaques et des blocages, des paramètres de politique, une liste des services protégés et des exceptions approuvées. Je documente la solution locale de l'agent, le canal TLS sortant et l'absence de port de contrôle entrant, puis j'effectue de mauvaises connexions contrôlées et j'enregistre les lignes de journal, la règle de pare-feu et la notification.

Gratuitement, j'exporte sshd_config, nftables/ufw, fail2ban jail et changelog depuis Git, et j'envoie auth.log/journald vers un stockage sécurisé. Je vérifie chaque mois l'authentification par mot de passe, PermitRootLogin, MFA/VPN et teste la révocation des clés, signe le résultat et stocke les preuves pendant la période requise.

Avec SSH Protector je bloque la source dans le pare-feu après une série d'échecs, donc les prochaines connexions TCP n'atteignent pas sshd et ne créent pas autant d'entrées. Je conserve un audit du système, contrôle séparément la taille/conservation du journal et utilise l'historique des attaques dans le panneau comme index, et non comme remplacement du journal d'origine.

Gratuitement, je ferme SSH au VPN/liste autorisée, désactive les mots de passe et les connexions standard et envoie fail2ban aux nftables définis avec un délai d'attente. Je configure SystemMaxUse et la rotation journald/rsyslog, j'envoie les événements Accepted et Key Failed à un syslog externe et je ne réduis pas LogLevel en dessous de la valeur nécessaire à l'enquête.

Avec SSH Protector, je définis le seuil et la fenêtre une fois, après quoi l'agent crée et libère les verrous localement et la liste blanche est prioritaire. J'utilise une interdiction de réseau où l'attaquant fait alterner les adresses voisines, vérifie les modifications dans le panneau et enregistre une console de sauvegarde avant la première politique.

Gratuitement, je remplace les règles iptables éternelles individuelles par nftables définies avec une action timeout ou fail2ban, je définis maxretry/findtime/bantime et ignoreip pour VPN. Je teste le filtre sur de vraies lignes de journal, j'active soigneusement la récidive, je limite la taille définie et je surveille les erreurs de rechargement après une mise à jour de la distribution.

Avec SSH Protector, je connecte les hôtes avec un agent pris en charge, je vois les ports et les attaques détectés à partir d'un seul panneau, mais je conserve les exceptions et les politiques dans les limites du serveur/client souhaité. J'applique les valeurs de référence, documente les écarts séparément et en informe le client responsable.

Gratuitement, je décris sshd, fail2ban et nftables dans des rôles Ansible avec un inventaire et un coffre-fort séparés pour chaque client, vérifie les modifications dans CI et collecte les journaux dans Wazuh/central syslog avec les balises de locataire. Je compare automatiquement la configuration avec la ligne de base et je ne combine jamais les clés, les CIDR et les secrets de différents clients.

Avec SSH Protector, j'applique la politique à l'agent à l'avance ; il continue de lire le journal local et de modifier le pare-feu du système vers la dernière configuration lorsque la communication avec le panneau est perdue. Je synchronise la liste blanche avant l'arrêt, vérifie l'historique accumulé après la restauration et n'ouvre pas le port de contrôle de l'agent entrant.

Gratuitement, je rends le contrôle entièrement local : nftables/ufw autorise SSH uniquement à partir d'un VPN ou des sous-réseaux requis, et fail2ban fonctionne via journald sans réseau externe. J'enregistre les règles de chargement, mets en place une file d'attente locale pour les notifications, teste un redémarrage sans DNS et quitte la console physique/fournisseur pour restaurer la règle erronée.

J'installe l'agent SSH Protector pendant que fail2ban continue de tourner. L'agent possède sa propre table nftables (inet sshprotector, ou un espace de noms ipset préfixé sur les hôtes plus anciens) et ne reconstruit que celle-là : il ne touche donc jamais aux chaînes de fail2ban et aucun des deux n'annule l'autre. À l'installation je mets d'abord ma propre adresse en liste blanche, puis je regarde le panneau pendant une journée pour vérifier que l'agent attrape les mêmes sources que la jail. Ce n'est qu'ensuite que j'arrête fail2ban et retire ses règles. Si je change d'avis, désinstaller l'agent emporte ses propres règles et laisse le pare-feu tel qu'il était.

Sans aucun agent, le passage entre deux outils qui lisent un journal se fait de la même façon. Laissez l'ancien tourner, donnez au nouveau son propre nom de chaîne ou de table pour que les règles ne se heurtent pas, comparez sur une journée complète de trafic réel ce que chacun a attrapé, et ne désactivez l'ancien qu'une fois que le compteur de bannissements du nouveau a cessé d'être le plus bas des deux. Ne retirez jamais l'outil qui marche en premier : quelques minutes sans protection sur un port SSH exposé suffisent à un botnet qui vous scanne déjà.

Les deux résolvent des problèmes qui se recouvrent, mais par des bouts différents, et je choisis sur la forme plutôt que sur une note. CrowdSec est un moteur : un langage de scénarios, des composants de blocage à installer et raccorder soi-même, et une blocklist alimentée par tous ceux qui le font tourner ; sa portée dépasse largement SSH. SSH Protector est un binaire qui fait une chose : il lit le journal d'authentification SSH, SFTP et FTP, bannit tout le /24 de l'attaquant dans sa propre table nftables, garde ce bannissement après un redémarrage, détecte le vrai port sshd au lieu de supposer 22, et rend compte à un panneau qui me prévient quand un serveur protégé se tait. La réputation se partage entre comptes protégés, pas avec l'internet public.

La décision porte donc sur ce que j'ai réellement. S'il me faut de l'étendue - HTTP, bases de données, sources de journaux arbitraires, mes propres scénarios de détection -, CrowdSec a la place pour ça et ne coûte rien à faire tourner. Si ce que j'ai est une poignée de machines Linux avec un port SSH exposé et personne pour entretenir une pile de détection, je veux la chose étroite qui est juste sans configuration. Je n'ai pas mesuré les deux l'un contre l'autre sur le même hôte, donc je ne choisis pas sur des chiffres de performance - et ceux qui m'en citent ne devraient pas non plus.