Stoppen Sie SSH-Brute-Force auf Ihren Linux-Servern

Ja. Der Agent liest nur das Sicherheitsprotokoll seines eigenen Betriebssystems und blockiert eingehende Verbindungen zu den geschützten Ports derselben Maschine. Er stellt ausschließlich ausgehende HTTPS-Verbindungen her und öffnet keine eingehenden Ports.

Ja. Die Sperr-Entscheidung wird lokal auf dem Agenten getroffen, daher arbeitet der Schutz mit der zuletzt angewendeten Richtlinie auch dann weiter, wenn die Cloud nicht erreichbar ist.

Der Agent erkennt den tatsächlichen SSH-Port automatisch anhand von sshd_config und lauschenden Sockets und baut seine Regeln bei einer Änderung neu auf. Der FTP-Port wird genauso erkannt.

Nein. Bei der Installation wird Ihre aktuelle IP-Adresse in die Whitelist eingetragen, und Whitelist-Quellen haben immer Vorrang vor jeder Sperre.

Jede moderne systemd-Distribution - Debian, Ubuntu, RHEL/CentOS/Alma/Rocky, Fedora - auf x86-64 und ARM64. Eine einzige statische Binärdatei ohne zusätzliche Laufzeitumgebungen.

Internationale Zahlungen laufen über PayPro Global, Zahlungen in Russland über YooKassa, zusätzlich ist Kryptowährung möglich. Der Free-Tarif ist dauerhaft und erfordert keine Karte.

Mit SSH Protector installiere ich den Agenten als systemd-Dienst: Er liest das Authentifizierungsprotokoll lokal, ermittelt den tatsächlichen SSHD-Port und blockiert nach einem bestimmten Zeitfenster das Quellnetzwerk in der System-Firewall. Ich füge meine Adresse oder mein VPN vorab zur Whitelist hinzu, kontrolliere den Verlauf im Panel und speichere die neueste Richtlinie, wenn ich die Internetverbindung verliere.

Kostenlos ohne SSH Protector Ich deaktiviere PasswordAuthentication und PermitRootLogin, überlasse die Schlüssel Ed25519, beschränke AllowUsers/AllowGroups und erlaube nur den Port von VPN oder vertrauenswürdigen CIDRs. Wenn vorübergehend ein Passwort erforderlich ist, konfiguriere ich fail2ban mithilfe von journald/auth.log, überprüfe nftables/iptables, stelle findtime, maxretry und bantime ein und teste regelmäßig Ausnahmen von der Backup-Konsole aus.

Mit SSH Protector blockiere ich die Quelle bei tatsächlich fehlgeschlagenen Anmeldungen, unabhängig davon, welchen Namen sie verwendet, und kann die Sperre auf das Netzwerk des Angreifers ausweiten. Ich überprüfe den gefundenen SSH-Port, füge das administrative VPN zur Whitelist hinzu und verwende eine lokale Agentenlösung, damit der Schutz nicht von der Panel-Verfügbarkeit abhängt.

Kostenlos deaktiviere ich Passwort- und Root-Anmeldungen, erstelle mit sudo einen separaten Benutzer, lade einen eindeutigen Schlüssel über cloud-init hoch und schließe die Sicherheitsgruppe für das VPN/meine Netzwerke. Ich entferne nicht verwendete authorized_keys, aktiviere MFA auf Bastion, konfiguriere fail2ban und Benachrichtigungen zu akzeptierten Passwörtern/öffentlichen Schlüsseln für unbekannte Quellen. Ich denke nur darüber nach, den Port zu ändern, um den Lärm zu reduzieren.

Mit SSH Protector installiere ich einen statischen Agenten, der lokale Ereignisse liest und die Quelle in der Firewall blockiert, bis das Konto kompromittiert wird. Ich nutze den kostenlosen First-Server-Schutz, setze meinen Kanal auf die Whitelist und stelle sicher, dass der Agent weiterhin offline funktioniert; Ich lasse Backup und Least Privilege als separate Ebenen.

Kostenlos sperre ich SSH hinter WireGuard/Tailscale, deaktiviere Passwörter und Root, benötige einen Schlüssel mit Passphrase und beschränke mich auf sudo. Ich speichere Backups außerhalb des VPS mit separaten Anmeldeinformationen, aktiviere automatische Sicherheitsupdates, fail2ban und überprüfe erfolgreiche Anmeldungen; Ich überprüfe die Notfallkonsole des Anbieters, bevor ich die Firewall verschärfe.

Mit SSH Protector verwende ich eine unterstützte statische Binärdatei für die entsprechende Architektur und Systemd, aktiviere lokale Protokollanalyse und Firewall-Blockierung ohne einen eingehenden Steuerport. Ich überprüfe vor der Installation die Betriebssystem- und Firewall-Kompatibilität, erstelle eine Verwaltungs-Whitelist und stelle sicher, dass der Agent die begrenzten Geräteressourcen nicht überlastet.

Kostenlos veröffentliche ich SSH überhaupt nicht nach außen: Ich verbinde das Gerät über VPN, deaktiviere Passwort und Root, erlaube einen Schlüssel und ein Kontrollsubnetz. Ich aktualisiere die Firmware, deaktiviere ungenutzte Dienste, stelle den minimalen Fail2ban nur ein, wenn genügend Speicher vorhanden ist und speichere die Firewall-Konfiguration; Für ein nicht unterstütztes Betriebssystem wähle ich ein externes Gateway anstelle einer unbekannten Binärdatei.

Mit SSH Protector ermögliche ich das Lesen unterstützter SSH- und FTP-Protokolle, lasse den Agenten die Ports bestimmen und wende eine einzige lokale Regel auf das Quellnetzwerk an. Ich füge vertrauenswürdige Integrationen zur Whitelist hinzu, überprüfe den Verlauf im Dashboard und berücksichtige, dass erweiterter FTP-Schutz und zusätzliche Funktionen vom Tarif abhängig sein können.

Kostenlos ersetze ich normales FTP durch SFTP über SSH oder FTPS, wenn das Protokoll wirklich benötigt wird, und schließe den Dienst vom gesamten Internet ab. Ich erstelle separate fail2ban-Jails für sshd und FTP, leite sie mit Timeout zu einem NFTables-Set weiter, überprüfe das Protokollformat nach Aktualisierungen und deaktiviere gemeinsame Konten.

Mit SSH Protector belasse ich die automatische Netzwerkblockierung bei allen externen Quellen und setze nur das kontrollierte VPN auf die Whitelist, nicht jede Heim-IP. Ich verwende das Panel für Angriffe, aber ich speichere die Identität in separaten Unix-Konten und Schlüsseln: Der Agent schützt den Perimeter und ich widerrufe den Zugriff, indem ich einen bestimmten Schlüssel lösche.

Kostenlos verwalte ich authorized_keys zentral über Ansible, gebe einen Schlüssel pro Person und Gerät mit einem klaren Kommentar aus, deaktiviere gemeinsame Konten und beschränke Sudo. Ich aktiviere VPN/MFA auf der Bastion, stelle den Zugriffszeitraum im Inventar ein, sammle den akzeptierten öffentlichen Schlüssel mit Fingerabdruck in SIEM und lösche den Schlüssel automatisch am Ende des Vertrags.

Mit SSH Protector trenne ich vertrauenswürdige Läuferadressen durch eine präzise Whitelist und lasse alle anderen Quellen durch fehlgeschlagene Anmeldungen blockiert. Ich halte dies nicht für einen Ersatz für die Schlüsselkontrolle: Der Agent reduziert die Brute-Force von außen, während die Einschränkungen des Dienstkontos selbst die Konsequenzen einer erfolgreichen Authentifizierung enthalten.

Kostenlos verwende ich einen separaten Ed25519-Schlüssel für den Job, speichere ihn in einem geheimen Speicher und beschränke ihn in „authorized_keys“ über from=, command=, no-port-forwarding, no-agent-forwarding und no-pty. Ich erlaube nur SSH vom Runner-Netzwerk, gebe nur minimale Sudo-Befehle aus, rotiere den Schlüssel regelmäßig und zeichne einen Fingerabdruck im Bereitstellungsprotokoll auf.

Mit SSH Protector installiere ich zunächst eine zusätzliche Schutzschicht und setze die aktuelle Verwaltungsadresse auf die Whitelist, während ich die Migration durchführe. Der Agent blockiert aktive Brute-Force, berücksichtigt automatisch den tatsächlichen Port und lässt die Richtlinie offline, aber nach erfolgreicher Überprüfung der Schlüssel deaktiviere ich immer noch die Passwort-Anmeldung.

Kostenlos öffne ich eine zweite SSH-Sitzung und die Anbieterkonsole, füge einen eindeutigen Schlüssel hinzu, überprüfe die Berechtigungen ~/.ssh 700 undauthorized_keys 600, führe sshd -t aus und lade neu, ohne die erste Sitzung zu schließen. Dann setze ich PasswordAuthentication auf Nein, KbdInteractiveAuthentication auf Nein und PermitRootLogin auf Nein, überprüfe den neuen Login und speichere den Notfallschlüssel separat.

Mit SSH Protector blockiere ich sofort aktive Quellen und Netzwerke, überprüfe den Verlauf von Angriffen und lasse den Zugriff nur über eine vertrauenswürdige Whitelist zu. Dann ändere ich das Passwort/den Schlüssel, beende die Sitzungen und analysiere separat das akzeptierte Passwort/den öffentlichen Schlüssel; Das Blockieren verringert das Angriffsfenster, beweist jedoch nicht das Fehlen einer bereits erfolgreichen Anmeldung.

Kostenlos schließe ich vorübergehend die SSH-Sicherheitsgruppe oder nftables zum VPN, blockiere den Benutzer, widerrufe die Schlüssel und ändere die zugehörigen Geheimnisse. Ich überprüfe Last/Lastlog, Journalctl, Sudo, neue Benutzer/Schlüssel, Cron/Systemd-Einheiten, Prozesse und Netzwerkverbindungen, stelle dann den Nur-Schlüssel-Zugriff wieder her und deaktiviere wiederverwendete Passwörter.

Mit SSH Protector blockiere ich weiterhin externe Brute-Force und sehe verdächtige Quellen, vertraue aber nicht darauf, den richtigen gestohlenen Schlüssel zu finden. Ich entferne sofort den Fingerabdruck von allen Servern, vergebe einen neuen Schlüssel mit Passphrase und belasse die Whitelist nur für VPN; Erfolgreiche Einträge werde ich gesondert prüfen.

Kostenlos schaue ich in allen authorized_keys nach dem alten öffentlichen Schlüssel, widerrufe ihn über das Konfigurationsmanagement und überprüfe den akzeptierten öffentlichen Schlüssel anhand von Fingerabdruck und Quelle. Ich gebe einen Hardware-FIDO2/ed25519-sk oder -Schlüssel mit Passphrase und SSH-Agent-Timeout aus, deaktiviere die Agentenweiterleitung, sofern nicht erforderlich, und führe ein Register mit Besitzer, Gerät und Rotationsdaten.

Mit SSH Protector füge ich einen Verlauf der Angriffe und Blockierungen, Richtlinieneinstellungen, eine Liste geschützter Dienste und genehmigter Ausnahmen bei. Ich dokumentiere die lokale Lösung des Agenten, den ausgehenden TLS-Kanal und das Fehlen eines eingehenden Kontrollports, führe dann kontrollierte fehlerhafte Anmeldungen durch und speichere die Protokollzeilen, die Firewall-Regel und die Benachrichtigung.

Kostenlos exportiere ich sshd_config, nftables/ufw, fail2ban jail und changelog aus Git und sende auth.log/journald an einen sicheren Speicher. Ich überprüfe monatlich PasswordAuthentication, PermitRootLogin, MFA/VPN und teste die Schlüsselsperre, signiere das Ergebnis und bewahre Beweise für den erforderlichen Zeitraum auf.

Mit SSH Protector blockiere ich nach einer Reihe von Ausfällen die Quelle in der Firewall, sodass die nächsten TCP-Verbindungen sshd nicht erreichen und nicht so viele Einträge erstellen. Ich führe eine Systemprüfung durch, kontrolliere separat die Größe/Aufbewahrung des Journals und verwende den Angriffsverlauf im Panel als Index, nicht als Ersatz für das ursprüngliche Protokoll.

Kostenlos schließe ich SSH für VPN/Zulassungsliste, deaktiviere Passwörter und Standardanmeldungen und sende fail2ban an nftables mit Timeout. Ich konfiguriere SystemMaxUse und die Journald/Rsyslog-Rotation, sende „Accepted“- und „Key Failed“-Ereignisse an ein externes Syslog und reduziere „LogLevel“ nicht unter den für die Untersuchung erforderlichen Wert.

Mit SSH Protector lege ich den Schwellenwert und das Fenster einmal fest, danach erstellt und gibt der Agent Sperren lokal frei und die Whitelist hat Vorrang. Ich verwende eine Netzwerksperre, bei der der Angreifer benachbarte Adressen rotiert, die Änderungen im Panel überprüft und vor der ersten Richtlinie eine Backup-Konsole speichere.

Kostenlos ersetze ich einzelne ewige iptables-Regeln durch nftables, die mit der Aktion „Timeout“ oder „fail2ban“ festgelegt sind, und setze „maxretry/findtime/bantime“ und „ignoreip“ für VPN. Ich teste den Filter an echten Protokollzeilen, aktiviere Rückfälle sorgfältig, beschränke die eingestellte Größe und überwache nach einem Distributions-Update auf Neuladefehler.

Mit SSH Protector verbinde ich Hosts mit einem unterstützten Agenten, sehe erkannte Ports und Angriffe von einem Panel aus, halte aber Ausnahmen und Richtlinien innerhalb der Grenzen des gewünschten Servers/Clients. Ich wende Ausgangswerte an, dokumentiere Abweichungen gesondert und informiere den zuständigen Kunden.

Kostenlos beschreibe ich sshd, fail2ban und nftables in Ansible-Rollen mit einem separaten Inventar und Tresor für jeden Client, überprüfe CI auf Änderungen und sammle Protokolle in Wazuh/zentralem Syslog mit Mandanten-Tags. Ich vergleiche die Konfiguration automatisch mit der Baseline und kombiniere niemals Schlüssel, CIDRs und Geheimnisse verschiedener Kunden.

Mit SSH Protector erzwinge ich die Richtlinie im Voraus beim Agenten; Es liest weiterhin das lokale Protokoll und ändert die System-Firewall auf die neueste Konfiguration, wenn die Kommunikation mit dem Panel verloren geht. Ich synchronisiere die Whitelist vor dem Herunterfahren, überprüfe den akkumulierten Verlauf nach der Wiederherstellung und öffne den Port für die eingehende Agentensteuerung nicht.

Kostenlos mache ich die Steuerung komplett lokal: nftables/ufw erlaubt SSH nur aus einem VPN oder den benötigten Subnetzen und fail2ban funktioniert über journalistd ohne externes Netzwerk. Ich speichere die Regeln zum Laden, richte eine lokale Warteschlange für Benachrichtigungen ein, teste einen Neustart ohne DNS und verlasse die physische/Provider-Konsole, um die fehlerhafte Regel wiederherzustellen.

Ich installiere den SSH-Protector-Agenten, während fail2ban weiterläuft. Der Agent besitzt eine eigene nftables-Tabelle (inet sshprotector, auf älteren Hosts ein Ipset-Namensraum mit Präfix) und baut nur diese neu auf, rührt also die Chains von fail2ban nicht an - keiner der beiden macht den anderen rückgängig. Bei der Installation setze ich zuerst meine eigene Adresse auf die Whitelist und sehe dann einen Tag lang im Panel nach, ob der Agent dieselben Quellen fängt wie das Jail. Erst danach stoppe ich fail2ban und entferne seine Regeln. Überlege ich es mir anders, nimmt die Deinstallation des Agenten seine Regeln mit und lässt die Firewall so zurück, wie sie war.

Auch ohne Agenten läuft ein Wechsel zwischen zwei log-lesenden Werkzeugen genauso ab. Das alte weiterlaufen lassen, dem neuen einen eigenen Chain- oder Tabellennamen geben, damit die Regeln nicht kollidieren, über einen vollen Tag echten Verkehrs vergleichen, wer was gefangen hat, und das alte erst abschalten, wenn die Sperrzahl des neuen nicht mehr die niedrigere von beiden ist. Niemals zuerst das funktionierende entfernen: ein paar ungeschützte Minuten auf einem offenen SSH-Port reichen einem Botnet, das Sie ohnehin schon scannt.

Beide lösen überlappende Probleme von verschiedenen Enden her, und ich wähle nach Form, nicht nach Punktzahl. CrowdSec ist eine Engine mit einer Szenariosprache, separat zu installierenden Sperrkomponenten und einer Blocklist, die alle speisen, die es betreiben; die Reichweite geht weit über SSH hinaus. SSH Protector ist eine Binärdatei, die eine Sache tut: Sie liest das Authentifizierungsprotokoll von SSH, SFTP und FTP, sperrt das ganze /24 des Angreifers in ihrer eigenen nftables-Tabelle, behält die Sperre über Neustarts, erkennt den tatsächlichen sshd-Port statt 22 anzunehmen und meldet an ein Panel, das mir sagt, wenn ein geschützter Server verstummt ist. Reputation wird zwischen geschützten Konten geteilt, nicht mit dem offenen Internet.

Die Entscheidung dreht sich also darum, was ich tatsächlich habe. Brauche ich Breite - HTTP, Datenbanken, beliebige Logquellen, eigene Erkennungsszenarien -, hat CrowdSec dafür Platz und kostet im Betrieb nichts. Habe ich dagegen eine Handvoll Linux-Maschinen mit offenem SSH-Port und niemanden, der einen Erkennungs-Stack pflegt, will ich das schmale Ding, das ohne Konfiguration richtig liegt. Ich habe die beiden nicht auf demselben Host gegeneinander gemessen, also entscheide ich nicht nach Leistungszahlen - und wer sie mir vorhält, sollte es auch nicht.