Denyhosts vs fail2ban vs iptables - der beste Weg, um Brute-Force-Anmeldungen zu verhindern?

bester Weg, um Brute-Force-Anmeldungen zu verhindern?

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:

• Erlaube root nicht, sich anzumelden
• SSH-Passwörter nicht zulassen (Authentifizierung mit privatem Schlüssel verwenden)
• Hören Sie nicht auf jede Schnittstelle
• Erstellen Sie eine Netzwerkschnittstelle für SSH (z. B. eth1), die sich von der Schnittstelle unterscheidet, von der aus Sie Anforderungen bedienen (z. B. eth0).
• Verwenden Sie keine gebräuchlichen Benutzernamen
• Verwenden Sie eine Zulassungsliste und erlauben Sie nur Benutzern, die SSH-Zugriff benötigen
• Wenn Sie einen Internetzugang benötigen ... Beschränken Sie den Zugriff auf eine begrenzte Anzahl von IP-Adressen. Eine statische IP ist ideal, jedoch ist das Sperren auf x.x.0.0/16 besser als 0.0.0.0/0
• Wenn möglich, finden Sie eine Möglichkeit, eine Verbindung ohne Internetzugang herzustellen. Auf diese Weise können Sie den gesamten Internetverkehr für SSH verweigern (z. B. können Sie mit AWS eine direkte Verbindung erhalten, die das Internet umgeht und als direkte Verbindung bezeichnet wird).
• Verwenden Sie Software wie fail2ban, um Brute-Force-Angriffe abzuwehren
• Stellen Sie sicher, dass das Betriebssystem immer auf dem neuesten Stand ist, insbesondere Sicherheits- und SSH-Pakete

Anwendung:

• Stellen Sie sicher, dass Ihre Anwendung immer auf dem neuesten Stand ist, insbesondere Sicherheitspakete
• Sperren Sie die Administrationsseiten Ihrer Anwendung. Viele der oben genannten Ratschläge gelten auch für den Administrationsbereich Ihrer Anwendung.
• Passwort Schützen Sie Ihren Administratorbereich. So etwas wie htpasswd für die Webkonsole projiziert alle zugrunde liegenden Anwendungsschwachstellen und schafft eine zusätzliche Eintrittsbarriere
• Sperren Sie Dateiberechtigungen. 'Upload-Ordner' sind bekannt dafür, Einstiegspunkte für alle möglichen bösen Dinge zu sein.
• Stellen Sie Ihre Anwendung möglicherweise hinter ein privates Netzwerk und stellen Sie nur Ihren Front-End-Load-Balancer und eine Jumpbox bereit (dies ist ein typisches Setup in AWS mit VPCs).

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.

SSH PORTKNOCKING

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.