Ich richte einen LAMP-Server ein und muss SSH/FTP/etc. Verhindern. Brute-Force-Anmeldeversuche erfolgreich. Ich habe viele Empfehlungen für Denyhosts und Fail2Ban gesehen, aber nur wenige Vergleiche der beiden. Ich habe auch gelesen, dass eine IPTables-Regel dieselbe Funktion erfüllen kann.
Warum sollte ich eine dieser Methoden einer anderen vorziehen? Wie gehen Serverfehler mit diesem Problem um?
IIRC, DenyHosts überwacht nur Ihren SSH-Dienst. Wenn Sie es auch zum Schutz anderer Dienste benötigen, ist Fail2ban definitiv die bessere Wahl. Es ist konfigurierbar, fast jeden Dienst zu überwachen, wenn Sie bereit sind, seine Konfiguration zu optimieren. Dies sollte jedoch nicht erforderlich sein, da die neueren Versionen von Fail2ban Regelsätze enthalten, die für viele gängige Server-Daemons geeignet sind. Die Verwendung von fail2ban über ein einfaches Ratenlimit für iptables hat den Vorteil, dass ein Angreifer für einen bestimmten Zeitraum vollständig blockiert wird, anstatt einfach zu reduzieren, wie schnell er Ihren Server hämmern kann. Ich habe fail2ban mit großartigen Ergebnissen auf einer Reihe von Produktionsservern verwendet und noch nie einen dieser Server gesehen, der durch einen Brute-Force-Angriff verletzt wurde, seit ich ihn verwendet habe.
Lassen Sie sie überhaupt nicht an Ihre Maschine gelangen! Es gibt viele Möglichkeiten, Brute-Force-Versuche zu stoppen, bevor sie zu Ihrem Host oder sogar auf SSH-Ebene gelangen.
Trotzdem ist es eine großartige Idee, Ihr Betriebssystem mit etwas wie fail2ban zu schützen. Fail2ban unterscheidet sich geringfügig von DenyHosts, obwohl sie im selben Bereich spielen. Fail2ban verwendet iptables.
http://en.wikipedia.org/wiki/Fail2ban
Fail2ban ähnelt DenyHosts ... Im Gegensatz zu DenyHosts, das sich auf SSH konzentriert, kann fail2ban so konfiguriert werden, dass jeder Dienst überwacht wird, der Anmeldeversuche in eine Protokolldatei schreibt, und statt /etc/hosts.deny nur IP-Adressen/Hosts blockiert , fail2ban kann Netfilter/iptables und TCP Wrappers /etc/hosts.deny) verwenden.
Es gibt eine Reihe wichtiger Sicherheitstechniken, die Sie berücksichtigen sollten, um Brute-Force-Anmeldungen zu verhindern:
SSH:
Anwendung:
EINE ANDERE GROSSE MÖGLICHKEIT, SSH ZU SCHÜTZEN (Ich habe dies ein Jahrzehnt oder besser verwendet) besteht darin, die neuesten Bibliotheken in iptables nativ zu verwenden (abhängig von Ihrer Distribution).
Grundsätzlich kann es als Port-Knocking verwendet werden, das in iptables eingebaut ist. Dies erspart Ihnen viele Kopfschmerzen. Solange Sie eine TCP-Verbindung herstellen können (Telnet ist eine Möglichkeit. Ich habe auch SSH-Clients verwendet und sie auf den Port gerichtet. Alles, was eine TCP-Verbindung zu einer bestimmten Portnummer herstellt. Ich sehe Sie PuTTY!) Von der Client, der die SSH-Verbindung initiiert, können Sie dies verwenden.
Im Folgenden finden Sie ein Beispiel, bei dem iptables Port 22 für Ihren Host öffnet, wenn Sie von Ihrem Host zum Server an Port 4103 telneten. Anschließend können Sie ein Telnet für Port 4102 oder 4104 verwenden, um die sed-Öffnung zu schließen. Der Grund für 4102 und 4104 besteht darin, zu verhindern, dass ein einfacher TCP-Scan geöffnet wird 22. Nur eine TCP-Verbindung (Telnet) zu Port 4103 ermöglicht Ihnen den Zugriff.
Genießen!
Oh und ich bevorzuge Fail2Ban. Mehr Flexibilität und ich mag es, dass das Verbot eher in iptables als in tcpwrappern stattfindet.
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -m recent --rcheck --name SSH -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4102 -m recent --name SSH --remove -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4103 -m recent --name SSH --set -j DROP
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 4104 -m recent --name SSH --remove -j DROP
Ich verwende iptables-Regeln, um neue Verbindungen von derselben IP-Adresse zu begrenzen (hauptsächlich SSH, aber es würde auch für FTP gut funktionieren). Der Vorteil gegenüber "fail2ban" und anderen solchen Tools besteht meines Erachtens darin, dass die iptables-Route vollständig im Kernelmodus erfolgt und nicht auf Tools im Benutzermodus angewiesen ist, um Protokolldateien zu verfolgen/zu analysieren.
Hunderte von fehlgeschlagenen SSH-Anmeldungen
Wenn Sie dies tun können, hilft natürlich auch die Beschränkung der Quelladressen, die auf die betreffenden Protokolle zugreifen können.
Mit SSH sollten Sie wirklich die Zertifikatauthentifizierung verwenden und ohnehin keine Passwörter akzeptieren.
Ein weiterer Unterschied zwischen Fail2ban und Denyhosts besteht darin, dass Denyhosts die Sperrliste mit anderen Denyhosts-Benutzern teilen können. Mit Fail2ban können Sie nur IPs blockieren, die Ihr Server zuvor gesehen hat. Mit Denyhosts kann ein Brute-Force-Versuch möglicherweise nie auf Ihren Server gelangen, wenn jemand anderes ihn gesehen hat, und die Sperrliste wird vor dem Angreifer auf Ihren Server heruntergeladen gelangt zu Ihrem Computer.
Ein weiterer Unterschied besteht darin, dass Fail2ban iptables verwendet, während Denyhosts tcpwrapper verwendet. Andere haben diesen Unterschied bereits erwähnt, aber es gibt einige erwähnenswerte Randnotizen.
iptables ist in der Anzahl der IP-Adressen begrenzt, die Sie effizient blockieren können. Dies ist wahrscheinlich einer der Gründe, warum Fail2ban keinen Mechanismus zum Freigeben von Blocklisten hat.
Ein weiterer Effekt ist, dass Fail2ban wahrscheinlich nicht mehr funktioniert oder neu geschrieben werden muss, wenn iptables durch nftables ersetzt wird. Denyhosts werden wahrscheinlich weiterarbeiten.
Beide haben also Vor- und Nachteile. Ich mag beides; Für mich selbst verwende ich Denyhosts, weil ich normalerweise nur SSH schützen möchte und die Sperrliste gerne teile.
Eine Sache, die bei Fail2Ban zu beachten ist, ist, dass es ungefähr 10 MB mehr Speicher als DenyHosts zu verbrauchen scheint. Wenn Sie also mit 128 MB VPS arbeiten, sollten Sie sich das ansehen. Out-of-the-Box-Fail2Ban wird nur auf SSH eingerichtet, was bedeutet, dass DenyHosts ohne Änderungen an der Konfiguration dasselbe auf weniger Speicher tut.
denyhosts ist für SSH. fail2ban ist umfassender (HTTP, FTP usw.). Beide verwenden iptables hinter den Kulissen.
Warum nicht die offene Community die ganze Arbeit für Sie erledigen lassen und stattdessen CSF/LFD verwenden, anstatt sich mit langwierigen iptables oder der fail2ban-Konfiguration herumzuschlagen? Ich kann es vor allen anderen genannten Optionen nur empfehlen. Unter http://configserver.com/cp/csf.html erfahren Sie, was es für Ihre Server tun kann. CSF benötigt kein Control Panel, es bietet eine einfache Benutzeroberfläche für diejenigen, die dies nicht mit Shell tun möchten. Und es ist eine Menge stabiler, zuverlässiger, nicht ansässiger Perl-Skripte.
fail2ban scheint keinen Mechanismus zu haben, um eine erfolgreiche SSH-Anmeldung zu erkennen und die Anzahl der Fehler zurückzusetzen.
Der Standardfilter für sshd (zumindest bei meiner Debian-Installation) erfasst eine Fehleranzahl für jeden vom Client präsentierten ssh-Schlüssel, den der Server ablehnt. Einige Benutzer präsentieren bei jedem Login viele Schlüssel und werden regelmäßig gesperrt, obwohl ihre Logins erfolgreich waren, nachdem einige Schlüssel durchlaufen wurden.
Aus diesem Grund denke ich derzeit darüber nach, mich von fail2ban zu entfernen. Zumindest in dieser Hinsicht sind Denyhosts besser. Es ist jedoch anscheinend keine gute Option mehr und wird in neueren Debian-Versionen nicht mehr unterstützt (einige Diskussionen unter https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-) fail2ban-for-debian / )
Ich habe hier keine gute Lösung.
Eigentlich denke ich, dass leugnenHost in der Lage ist, viele andere Dienste außer dem sshd-Dienst zu verhindern. In der Konfigurationsdatei - /etc/denyhosts.conf
Gibt es einige Codezeilen:
# BLOCK_SERVICE: the service name that should be blocked in HOSTS_DENY
#
# man 5 hosts_access for details
#
# eg. sshd: 127.0.0.1 # will block sshd logins from 127.0.0.1
#
# To block all services for the offending Host:
BLOCK_SERVICE = ALL
# To block only sshd:
# BLOCK_SERVICE = sshd
wenn wir also die Variable BLOCK_SERVICE
wie oben auf ALL
setzen, können wir unseren SSH-Dienst beobachten.
Denyhosts Version 3.0: Jedes Mal, wenn eine IP-Adresse in einer Protokolldatei angezeigt wird, öffnet Denyhosts die Datei hosts.deny und liest das Ganze entsprechend der Adresse. Jedes Mal. Nichts wird im Speicher zwischengespeichert. Wenn Sie eine riesige hosts.deny-Datei haben und vielen Tests (vielen Protokolldateieinträgen) ausgesetzt sind, wird Denyhosts zu einem CPU-Hog, der die hosts.deny-Datei für jede angezeigte IP-Adresse liest und erneut liest. Nicht gut.
Wenn Sie die Unterstützung von iptables aktivieren, erstellt Denyhosts große, langsame Listen blockierter IP-Adressen. Denyhosts verwendet weder ipset noch nftables, um effiziente IP-Maps zu erstellen.