Ist es normal, Hunderte von Einbruchsversuchen pro Tag zu erhalten?

Ich habe gerade meinen Server überprüft /var/log/auth.logund festgestellt, dass ich mehr als 500 Benachrichtigungen über fehlgeschlagene Kennwort- / Einbruchsversuche pro Tag erhalte! Meine Website ist klein und ihre URL ist dunkel. Ist das normal? Sollte ich irgendwelche Maßnahmen ergreifen?

Im heutigen Internet ist das leider ganz normal. Es gibt Horden von Botnetzen, die versuchen, sich bei jedem Server anzumelden, den sie in ganzen IP-Netzwerken finden. In der Regel verwenden sie einfache Wörterbuchangriffe auf bekannte Konten (z. B. Root-Konten oder bestimmte Anwendungskonten).

Die Angriffsziele werden nicht über Google- oder DNS-Einträge gefunden, sondern die Angreifer versuchen einfach jede IP-Adresse in einem bestimmten Subnetz (z. B. von bekannten Root-Server-Hosting-Unternehmen). Es spielt also keine Rolle, dass Ihre URL (daher der DNS-Eintrag) ziemlich dunkel ist.

Deshalb ist es so wichtig:

• root-Login in SSH nicht zulassen ( howto )
• Verwenden Sie überall sichere Passwörter (auch in Ihren Webanwendungen)
• Verwenden Sie für SSH nach Möglichkeit die Authentifizierung mit öffentlichem Schlüssel und deaktivieren Sie die Kennwortauthentifizierung vollständig ( howto ).

Zusätzlich können Sie fail2ban installieren, das das Authlog scannt. Wenn es eine bestimmte Anzahl fehlgeschlagener Anmeldeversuche von einer IP-Adresse findet, wird diese IP-Adresse zu /etc/hosts.denyoder iptables / netfilter hinzugefügt, um den Angreifer für einige Minuten zu sperren.

Zusätzlich zu den SSH-Angriffen wird Ihr Webserver immer häufiger nach anfälligen Webanwendungen durchsucht (einige Blogging-Apps, CMSs, phpmyadmin usw.). Halten Sie diese also stets auf dem neuesten Stand und konfigurieren Sie sie auch sicher!

Ein paar 100 sind in Ordnung ... Letzten Monat stellte ich fest, dass einer meiner Server 40.000 fehlgeschlagene Versuche hatte. Ich habe mir die Mühe gemacht, sie zu zeichnen: Karte

Nachdem ich den ssh-Port geändert und Port Knocking implementiert hatte, ging die Zahl auf 0 zurück :-)

Ich benutze zum einen ein "Tarpit" und erlaube nur die Authentifizierung mit öffentlichen Schlüsseln und verbiete Root-Logins.

In netfiltergibt es ein recentModul, das Sie mit ( INPUTchain) verwenden können:

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

Das bedeutet, dass jeder Versuch, eine Verbindung zu Port 22 herzustellen, vom recentModul mit IP und einigen anderen Informationen unter dem Namen "tarpit" aufgelistet wird (wenn Sie neugierig sind, schauen Sie sich das an /proc/net/xt_recent/tarpit). Natürlich können Sie auch andere Namen verwenden.

Um IPs aufzulisten oder zu löschen, verwenden Sie:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

Diese Rate begrenzt die Versuche auf 5 in 300 Sekunden. Bitte beachten Sie, dass Benutzer mit einer bestehenden Verbindung von dieser Beschränkung nicht betroffen sind, da sie bereits über eine bestehende Verbindung verfügen und mehr Verbindungen erstellen dürfen (auch über der Gebührengrenze).

Passen Sie die Regeln nach Ihren Wünschen an, achten Sie jedoch darauf, dass sie in dieser Reihenfolge hinzugefügt werden (dh wenn Sie sie hinzufügen, verwenden Sie sie in dieser Reihenfolge, wenn Sie sie in umgekehrter Reihenfolge einfügen).

Dies reduziert den Lärm ungemein. Es bietet auch tatsächliche Sicherheit (gegen Brute-Forcing) im Gegensatz zur wahrgenommenen Sicherheit beim Ändern des Ports. Ich würde jedoch weiterhin empfehlen, den Port zu ändern, wenn dies in Ihrer Umgebung möglich ist. Es wird auch den Geräuschpegel reduzieren ...

Sie können dies immer noch mit fail2ban kombinieren, obwohl ich ohne es und nur mit den oben genannten Regeln gut lief.

BEARBEITEN:

Auf diese Weise können Sie sich selbst aussperren, sodass Sie Folgendes hinzufügen können, mit dem Sie das Sperren aufheben können, indem Sie an einen bestimmten Port klopfen:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

Sie könnten fail2ban oder ähnliche Methoden wie das Sperren von SSH auf Ihre IP implementieren . Leider versuchen Bots die ganze Zeit bruteforce zuzugreifen, so dass es ganz normal ist, dass Sie sicherstellen müssen, dass Sie ein gutes Passwort haben.

Ja . Das ist heutzutage ganz normal.

Verwenden Sie nach Möglichkeit nur die Authentifizierung mit öffentlichem Schlüssel für Verwaltungszwecke. Generieren Sie einen privaten Schlüssel auf Ihrer Workstation:

$ ssh-keygen -t dsa

Kopieren Sie den Inhalt von ~ / .ssh / id_dsa.pub an Ihre Server ~ / .ssh / authorized_keys (und /root/.ssh/authorized_keys, falls Sie eine direkte Root-Anmeldung benötigen).

Konfigurieren Sie die Server / etc / ssh / sshd_config so , dass nur die Authentifizierung mit öffentlichen Schlüsseln akzeptiert wird:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

Wenn Sie zu viele Server haben, können Sie mit Puppet öffentliche Schlüssel und Konfigurationen für diese ausführen.

Sehen Sie sich Denyhosts und fail2ban an, um wiederholte SSH-Anmeldeversuche zu blockieren, und sehen Sie Snort, wenn Sie vollständige IDS / IPS benötigen.

benutze http://denyhosts.sourceforge.net/

und ja, Sie sollten die Authentifizierung mit öffentlichem Schlüssel verwenden und die Kennwortauthentifizierung deaktivieren.

Die Versuche sind mechanisiert, daher scheinen die Zahlen in Ordnung zu sein (ja, sie sind hoch im Vergleich zu einigen Websites und niedrig im Vergleich zu anderen). Sie sollten die Schritte ausführen, die Sie normalerweise ausführen müssen: Sie betrachten Ihre Websites jeden Tag als Angriffsziele, auch wenn Sie keinen Angriff erkennen. Einen Angriff nicht zu erkennen, bedeutet nicht, dass er nicht existiert .

Ich würde sagen, nur 500 zu bekommen, ist ein bisschen niedrig.

Bei einem früheren Arbeitgeber nannte einer der Computer-Sicherheitsforscher den ständigen Strom von Einbruchsversuchen das "Internet-Äquivalent von kosmischem Rauschen ". Er beschrieb es als einen normalen, kontinuierlichen Fluss böswilligen Verkehrs, der im Internet nach Systemen suchte und automatisch Skripte ausnutzte, um zu versuchen, das System zu entführen. Bot-Netze und andere bösartige Systeme würden das Internet ständig nach anfälligen Systemen wie SETI durchsuchen und diese erneut durchsuchen.

Ja,

das ist üblich, aber das heißt nicht, dass du nicht den guten Kampf führen sollst. Hier sind einige Schritte, wie Sie Ihren Server sicherer machen können.

Vermeiden Sie mit DNS verbundene IP-Adressen

Sie können diese Anzahl in gemeinsam genutzten Umgebungen oder Colocation-Umgebungen erheblich reduzieren, indem Sie den SSH-Zugriff auf IP-Adressen deaktivieren, die mit Domänennamen verknüpft sind. Nicht aufgeführte Nicht-Domain-IP-Adressen erhalten weniger von dieser Art von Datenverkehr. Kaufen Sie daher eine nicht aufgeführte IP und verwenden Sie diese IP nur für den SSH-Zugriff.

Verwenden Sie für alle SSH-Zugriffe ein VPN

Wenn Sie sich in einer Umgebung befinden, in der Sie IPsec / VPN in einem privaten Netzwerk in Ihrer Serverumgebung implementieren können, ist dies ideal. Deaktivieren Sie den gesamten SSH-Internetzugang und stellen Sie sicher, dass Sie über eine integrierte Lights-Out-Lösung verfügen. Richten Sie Ihr VPN ein und erlauben Sie nur den SSH-Zugriff von Ihrem VPN aus.

Implementieren Sie IP-Adressregeln für den SSH-Zugriff

Wenn das VLAN keine Option ist, konfigurieren Sie Ihren Router oder die Firewall-Regeln so, dass nur SSH-Verbindungen aus einem bekannten IP-Adressbereich zugelassen werden.

Wenn Sie diese Schritte ausführen, können Sie nachts viel besser schlafen, da Sie wissen, dass jemand das Netzwerk Ihres Hosting-Unternehmens gefährden muss, um über SSH auf den Server zuzugreifen.

Es ist ganz normal, Hunderte von fehlgeschlagenen SSH-Verbindungen zu sehen.

Wenn Sie die Option haben, ändere ich einfach meinen SSH-Port auf etwas, das nicht dem Standard entspricht. Es macht Ihren Server nicht unbedingt sicherer, bereinigt aber die Protokolle (und lässt Sie sehen, dass jemand absichtlich versucht, einzudringen!)

Zusätzlich zur Verwendung eines automatischen Sperrmechanismus wie fail2ban haben Sie eine weitere Option: Wenden Sie sich tatsächlich an den ISP der Missbrauchsadresse des Angreifers. Es mag völlig sinnlos erscheinen, aber im Falle des Script-Kiddie ist der ISP mehr als bereit, Maßnahmen gegen sie zu ergreifen.

Um die Missbrauchsadresse zu finden, beginnen Sie mit arin.net und suchen Sie die IP-Adresse mit whois. Möglicherweise werden Sie zu einer anderen regionalen Registrierung umgeleitet, aber möglicherweise finden Sie den zuständigen ISP für den IP-Block, der die Adresse enthält. Suchen Sie nach der abuse @ -Adresse oder senden Sie einfach eine E-Mail an den technischen Kontakt.

Senden Sie ihnen eine höfliche Nachricht mit den entsprechenden Einträgen in der Protokolldatei (stellen Sie sicher, dass Sie alle privaten Informationen entfernen) und fordern Sie sie auf, gegen den betreffenden Host vorzugehen.

Ich würde empfehlen, nicht fail2ban zu verwenden, sondern SSH (und andere) auf einem Nicht-Standard-Port auszuführen. Ich glaube nicht an Sicherheit durch Unbekanntheit, aber ich denke, dass dies eine hervorragende Möglichkeit ist, das Rauschen in Ihren Protokollen zu reduzieren.

Fehlgeschlagene Anmeldungen an Nicht-Standard-Ports sind selten und können auch auf gezieltere Angriffe hinweisen.

Sie könnten sogar noch einen Schritt weiter gehen und ein SSH-Honeypot wie Kippo installieren , um die Bruteforcer einzulassen und zu sehen, was sie tun würden, wenn die Chance dazu besteht.

Ja es ist normal Was ich Kunden in Ihrer Situation mit kleinen Websites erzähle.

Sei immer bereit, gehackt zu werden.

Haben Sie eine Kopie Ihrer Website auf einem Entwickler-Server. Dies kann Ihr Windows-Desktop mit XAMPP sein, den Sie kostenlos erhalten können.

Nehmen Sie IMMER Änderungen an Ihrem Entwickler-Server vor und laden Sie sie dann auf Ihre Live-Website hoch. Wenn es sich um ein CMS wie Wordpress handelt, erstellen Sie Ihre Beiträge auf dem Entwickler-Server, kopieren Sie sie und fügen Sie sie in den Live-Server ein.

Laden Sie NIEMALS etwas von Ihrer Live-Website auf Ihren Entwickler-Server herunter.

Überwachen Sie Ihre Webseiten regelmäßig auf Änderungen, die Sie nicht vorgenommen haben. Insbesondere versteckte Links zu Drogen oder "Enhancement" -Produkten. Sie können viele Browser-Add-Ins und Programme finden, die dies für Sie tun.

Wenn Sie kompromittiert sind. Benachrichtigen Sie Ihren Host, löschen Sie alles, ändern Sie alle Passwörter und laden Sie Ihren sauberen Dev-Server auf den jetzt leeren Webserver hoch. Arbeiten Sie mit Ihrem Host zusammen, um eine Wiederholung zu verhindern.

Sie sollten kein Sicherheitsteam für eine kleine Site benötigen. Das soll Ihr Gastgeber bieten. Wenn dies nicht der Fall ist, besorgen Sie sich einen anderen Host, was viel einfacher ist, wenn Sie einen Entwicklungsserver haben, als den Live-Server zu verschieben.

Hoffe das hilft.

Eine andere Möglichkeit, dies zu stoppen (da ich persönlich den SSH-Port nicht gerne verschiebe): Entscheiden Sie, ob Sie alle Netzwerke auflisten können, über die Sie sich jemals anmelden möchten, und lassen Sie dann nur diesen den Zugriff auf Ihren SSH-Port zu.

Mithilfe von WHOIS-Einträgen lokaler ISPs konnte ich die Anzahl der Angriffe auf 1-2 Anmeldeversuche pro Monat reduzieren (damals waren es etwa 1 KB pro Tag). Ich entdeckte sie, indem ich immer noch Denyhosts verwendete .

Zusätzlich zu den anderen hervorragenden Vorschlägen, die Sie bereits erhalten haben, verwende ich gerne die AllowUsers- Direktive, falls dies für den angegebenen Server angemessen ist. Auf diese Weise können sich nur bestimmte Benutzer über SSH anmelden, wodurch die Möglichkeit, über ein nicht sicher konfiguriertes Gast- / Dienst- / Systemkonto Zugriff zu erhalten, erheblich verringert wird.

Beispiel:

AllowUsers admin jsmith jdoe

Die Option AllowUsers gibt an und steuert, welche Benutzer auf ssh-Dienste zugreifen können. Es können mehrere Benutzer angegeben werden, die durch Leerzeichen getrennt sind.

Ja es ist normal Du kannst :

• Reduzieren Sie die Angriffsmöglichkeiten mit fwknop

Fwknop ist eine der besseren Port-Knock-Implementierungen, da es nicht fälschbar ist und tatsächlich authentifiziert, anstatt nur eine Verbindung zu autorisieren.

• Sie können den von Openssh verwendeten Port ändern, die Sicherheit jedoch nicht wirklich verbessern.

• Verstärken Sie die SSH-Authentifizierung mithilfe von Google-Authentifikator oder Wikid

Dies schützt passwortbasierte Angriffe und die Möglichkeit eines entschlossenen Angreifers / gezielten Angriffs, der Ihren Administratorcomputer angreift und Ihre Kombination aus SSH-Schlüssel und Passwort stiehlt.

Schauen Sie sich einfach die neueste pwn2own-Komposition an, um zu sehen, wie einfach es für einen erfahrenen Angreifer ist, Ihre vollständig gepatchte Admin-Box zu kompromittieren.

Leider ist das ganz normal. Sie sollten erwägen , Ihrem System so etwas wie fail2ban hinzuzufügen, um die Angreifer automatisch zu erkennen und zu bannen. Wenn Sie dies noch nicht getan haben, sollten Sie auch in Betracht ziehen, ssh nur mit öffentlichen Schlüsseln zu verwenden und keine Root-Anmeldung über ssh zuzulassen. Wenn Sie FTP zum Übertragen von Dateien auf das System verwenden, sollten Sie stattdessen scp / sftp verwenden.

Ich habe Port-Knocking implementiert und habe ein paar Probes pro Tag. Sie bekommen keine Verbindung, also gehen sie weg. Ich melde und melde alle Zugriffe auf die beteiligten Ports.

Ich habe auch fail2ban mit Shorewall als Firewall ausgeführt, um persistente Angreifer vorübergehend auf die schwarze Liste zu setzen.

Wenn Sie keinen Internetzugang für SSH benötigen, deaktivieren Sie ihn. Wenn Sie einige bekannte Adressen haben, für die Remotezugriff erforderlich ist, beschränken Sie den Zugriff auf diese Adressen.

Das Einschränken des Zugriffs auf autorisierte Schlüssel kann ebenfalls hilfreich sein.

Ich benutze, pam_ablum vorübergehend Brute Forcer auf die schwarze Liste zu setzen, und es funktioniert großartig. Ich denke, es fühlt sich besser an, eine Autorisierung in PAM mithilfe einer eigenen Datenbank zu haben, als von hosts.denyoder abhängig zu sein iptables.

Ein weiteres Plus ist, dass pam_ables nicht darauf ankommt, Protokolldateien zu scannen.

Das ist heutzutage völlig normal.
Sie können ein "Burst" -Limit für die Firewall für eingehende neue Verbindungen auf dem SSH-Port
einrichten oder einen der vielen Protokollparser installieren , um ein Fail2Ban-Problem zu beheben oder den SSH-Port zu ändern.

Der letzte ist der einfachste. Auf stark beladenen Maschinen können solche Einbruchsversuche das gesamte System stark beeinträchtigen.

-
Grüße,
Robert

Ja es ist normal

Ich habe gerade den SSH-Port vom Standard 22 entfernt. Mein Server, meine Regeln :) Bearbeite einfach / etc / ssh / sshd_config, ändere den Port und starte den Dienst neu. Der einzige Nachteil ist, dass Sie daran denken müssen, diesen Port zu jeder Konfiguration für jeden von Ihnen verwendeten ssh-Client hinzuzufügen.

• Root-Anmeldung deaktivieren (In jedem Linux-System existieren Root-Benutzer, so dass Bots den Benutzernamen leicht erraten können.) Nachdem Sie sich als normaler Benutzer angemeldet haben, können Sie entweder über su oder sudo zu root wechseln.

• Ändern Sie den Standardport von 22

• Erlaube ssh-Zugriff nur von bekannten IP-Adressen

• Verwenden Sie ein starkes alphanumerisches Kennwort für den Benutzer mit SSH-Zugriff