12
Täglich tausende unbekannte Anmeldeversuche
Guten Tag allerseits!
Wir haben einige VMs (Ubuntu Server und Windows Server) die auf ESXi laufen und offen mit einer öffentlichen IP im Internet stehen.
Wir bekommen auf diesen Maschinen täglich mehrere tausend fehlgeschlagene Login Versuche.
Wir wissen nicht wer dahinter steckt, wollen aber die Login Versuche minimieren.
Könnt Ihr mir empfehlen wie ich am besten vorgehe um die Login Versuche zu minimieren?
Wir haben überlegt eine Proxy vorzuschalten. (z.B. HAProxy)
Bisher hat der Angreifer zum Glück kein PW erraten was er wahrscheinlich auch nicht wird da die PWs gut gewählt sind.
Aber wir wollen die Login Versuche minimieren.
Freue mich über Antworten, bedanke mich schon mal für Antworten und verbleibe
mit freundlichen Grüßen
Goodfred
Wir haben einige VMs (Ubuntu Server und Windows Server) die auf ESXi laufen und offen mit einer öffentlichen IP im Internet stehen.
Wir bekommen auf diesen Maschinen täglich mehrere tausend fehlgeschlagene Login Versuche.
Wir wissen nicht wer dahinter steckt, wollen aber die Login Versuche minimieren.
Könnt Ihr mir empfehlen wie ich am besten vorgehe um die Login Versuche zu minimieren?
Wir haben überlegt eine Proxy vorzuschalten. (z.B. HAProxy)
Bisher hat der Angreifer zum Glück kein PW erraten was er wahrscheinlich auch nicht wird da die PWs gut gewählt sind.
Aber wir wollen die Login Versuche minimieren.
Freue mich über Antworten, bedanke mich schon mal für Antworten und verbleibe
mit freundlichen Grüßen
Goodfred
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1164031146
Url: https://administrator.de/contentid/1164031146
Printed on: April 27, 2024 at 03:04 o'clock
12 Comments
Latest comment
Das sind die üblichen normalen Bots, die auf allen IPs alle bekannten Ports durchsuchen und Dankenbanken mit bekannt gewordenen Passwörtern durchprobieren.
Wenn du von Loginversuchen sprichst, gehe ich als erstes von SSH aus. Port 22 sollte niemals in der Öffentlichkeit antworten. Dafür werden VPN Verbindungen gemacht.
Es dürfen nur Ports für öffentliche Dienste erreichbar sein, z.B. Webserver und Mailserver.
Bei Ports, wo es sich nicht vermeiden lässt (z.B. FTP), müssen deswegen die Passwörter extrem kompliziert sein, damit sie nicht erraten werden können. FAIL2BAN ist auch ein nettes Tool, das eine IP nach wenigen Fehlversuchen einfach aussperrt.
Wenn du von Loginversuchen sprichst, gehe ich als erstes von SSH aus. Port 22 sollte niemals in der Öffentlichkeit antworten. Dafür werden VPN Verbindungen gemacht.
Es dürfen nur Ports für öffentliche Dienste erreichbar sein, z.B. Webserver und Mailserver.
Bei Ports, wo es sich nicht vermeiden lässt (z.B. FTP), müssen deswegen die Passwörter extrem kompliziert sein, damit sie nicht erraten werden können. FAIL2BAN ist auch ein nettes Tool, das eine IP nach wenigen Fehlversuchen einfach aussperrt.
1
Wie habt ihr die VMs im Internet stehen?
Ich hoffe mal nicht die ESXi Web Gui.
Ich hoffe mal nicht die ESXi Web Gui.
1
Zitat von @Goodfred:
Guten Tag allerseits!
Wir haben einige VMs (Ubuntu Server und Windows Server) die auf ESXi laufen und offen mit einer öffentlichen IP im Internet stehen.
Wir bekommen auf diesen Maschinen täglich mehrere tausend fehlgeschlagene Login Versuche.
das ist "normal".Guten Tag allerseits!
Wir haben einige VMs (Ubuntu Server und Windows Server) die auf ESXi laufen und offen mit einer öffentlichen IP im Internet stehen.
Wir bekommen auf diesen Maschinen täglich mehrere tausend fehlgeschlagene Login Versuche.
Nicht anderes passiert auf Webservern, welche irgendwo beim Hoster stehen.
Wir wissen nicht wer dahinter steckt, wollen aber die Login Versuche minimieren.
Könnt Ihr mir empfehlen wie ich am besten vorgehe um die Login Versuche zu minimieren?
Was du / ihr auf jeden Fall machen könnt ist, nach 3 oder 5 Fehlversuchen die IP für Zeit X zu sperren. Beispiel mit Fail2BANKönnt Ihr mir empfehlen wie ich am besten vorgehe um die Login Versuche zu minimieren?
Die DMZ steht doch bestimmt in einer DMZ oder? Davor ist doch sicherlich eine Firewall. Gebt nur die Ports frei, welche wirklich öffentlich zugänglich sein müssen.
Bisher hat der Angreifer zum Glück kein PW erraten was er wahrscheinlich auch nicht wird da die PWs gut gewählt sind.
PW erraten von? SSH? Dann ist hoffentlich der direkte Root zugriff gesperrt. Bestenfalls arbeitet ihr mit einer Public Key Authentifizierung1
Zitat von @Goodfred:
Guten Tag allerseits!
Wir haben einige VMs (Ubuntu Server und Windows Server) die auf ESXi laufen und offen mit einer öffentlichen IP im Internet stehen.
Wir bekommen auf diesen Maschinen täglich mehrere tausend fehlgeschlagene Login Versuche.
Wir wissen nicht wer dahinter steckt, wollen aber die Login Versuche minimieren.
Könnt Ihr mir empfehlen wie ich am besten vorgehe um die Login Versuche zu minimieren?
Wir haben überlegt eine Proxy vorzuschalten. (z.B. HAProxy)
Du könntest ...Guten Tag allerseits!
Wir haben einige VMs (Ubuntu Server und Windows Server) die auf ESXi laufen und offen mit einer öffentlichen IP im Internet stehen.
Wir bekommen auf diesen Maschinen täglich mehrere tausend fehlgeschlagene Login Versuche.
Wir wissen nicht wer dahinter steckt, wollen aber die Login Versuche minimieren.
Könnt Ihr mir empfehlen wie ich am besten vorgehe um die Login Versuche zu minimieren?
Wir haben überlegt eine Proxy vorzuschalten. (z.B. HAProxy)
- vom Standardport weg auf einen hohen Port legen.
- Port-Knocking verwenden
- Nur Verbindungen von bestimmten IPs erlauben. (Stichwort Firewall)
Bisher hat der Angreifer zum Glück kein PW erraten was er wahrscheinlich auch nicht wird da die PWs gut gewählt sind.
Aber wir wollen die Login Versuche minimieren.
1. Root-Login darf nicht möglich seinAber wir wollen die Login Versuche minimieren.
2. Passwort-Auth auf SSH-Key umstellen
3. Fail2Ban einsetzen
1
Moin,
Das ist normal. Da klopfen nur irgendwelche Bots die Systeme ab, ob jemand vergessen hat, abzuschließen.
Abhilfe gibt prinzipiell keine, wenn die Systeme so im Netz stehen.
Was Du aber machen kannst und was man immer generell machen sollte, ist eine Firewall davorzuklenmen und nur das durchzulassen, was benötigt wird.
Dazu vielleicht noch ein fail2ban auf die Kisten, damit die Angreifer nach einigen Fehlversuchen blockiert werden.
lks
Das ist normal. Da klopfen nur irgendwelche Bots die Systeme ab, ob jemand vergessen hat, abzuschließen.
Abhilfe gibt prinzipiell keine, wenn die Systeme so im Netz stehen.
Was Du aber machen kannst und was man immer generell machen sollte, ist eine Firewall davorzuklenmen und nur das durchzulassen, was benötigt wird.
Dazu vielleicht noch ein fail2ban auf die Kisten, damit die Angreifer nach einigen Fehlversuchen blockiert werden.
lks
1
Danke für eure Antworten! 
Kurz eine Frage bzgl. das Ändern des RDP Ports
- wenn ich mstsc.exe ausführe - kann ich dann nach der IP Adresse den Port angeben (z.B. xx.xx.xx.xx:1337) um den manuell geänderten Port zu verwenden? (bei SSH mit Putty ist es mir klar)
Ich werde mir wohl die Firewall Einstellungen auf den einzelnen Maschinen anschauen,
fail2ban auf Linux und für Windows eine alternative einrichten,
Ports ändern (SSH/RDP),
Mail Benachrichtigung beim Login einrichten.
Was haltet Ihr von der Idee eine extra Firewall oder Proxy vor den Maschinen zu schalten? Nötig/unnötig? Ich denke die OS der Maschinen haben alle eigene eigene Software Firewall (+fail2ban) das ich keine extra brauche.
P.S.: Es wurde gefragt wie die Server im Netz stehen - alle haben eine öffentliche IP bekommen
P.P.S.: Für die ESXi Weboberflächen muss ich mir noch was überlegen :D
P.P.P.S.: Es wurde VPN als Lösung erwähnt. Wie funktioniert das? (ein 2. internes privates Netz mit einem Server der von außen erreichbar ist und im internen Netz die Server adressiert?)
Kurz eine Frage bzgl. das Ändern des RDP Ports
- wenn ich mstsc.exe ausführe - kann ich dann nach der IP Adresse den Port angeben (z.B. xx.xx.xx.xx:1337) um den manuell geänderten Port zu verwenden? (bei SSH mit Putty ist es mir klar)
Ich werde mir wohl die Firewall Einstellungen auf den einzelnen Maschinen anschauen,
fail2ban auf Linux und für Windows eine alternative einrichten,
Ports ändern (SSH/RDP),
Mail Benachrichtigung beim Login einrichten.
Was haltet Ihr von der Idee eine extra Firewall oder Proxy vor den Maschinen zu schalten? Nötig/unnötig? Ich denke die OS der Maschinen haben alle eigene eigene Software Firewall (+fail2ban) das ich keine extra brauche.
P.S.: Es wurde gefragt wie die Server im Netz stehen - alle haben eine öffentliche IP bekommen
P.P.S.: Für die ESXi Weboberflächen muss ich mir noch was überlegen :D
P.P.P.S.: Es wurde VPN als Lösung erwähnt. Wie funktioniert das? (ein 2. internes privates Netz mit einem Server der von außen erreichbar ist und im internen Netz die Server adressiert?)
Fail2ban reicht mit sehr strikten Regeln. Max. 2 Fehlerversuche und dann bannen für mindestens einen Monat.
https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban ...
Fail2ban nutzt ja aktiv die iptables Firewall in sofern ist es überflüssig da zusätzlich nochwas zu machen.
Merkzettel: VPN Installation mit Wireguard
Merkzettel: VPN Installation mit OpenVPN
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Wireguard, OpenVPN oder Strongswan sind deine besten Freunde dafür unter Ubuntu ! Wenn du eh einen Hypervisor rennen hast macht es Sinn dort in einer VM eine pfSense oder OPNsense Firewall laufen zu lassen, was dir den ESXi wasserdicht sichert und auch sehr einfach des VPN für den Fernzugriff realisieren lässt. Siehe oben...
https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-esxi.html
https://docs.opnsense.org/manual/virtuals.html
https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban ...
Fail2ban nutzt ja aktiv die iptables Firewall in sofern ist es überflüssig da zusätzlich nochwas zu machen.
Es wurde VPN als Lösung erwähnt. Wie funktioniert das?
Einfach mal die Suchfunktion benutzen:Merkzettel: VPN Installation mit Wireguard
Merkzettel: VPN Installation mit OpenVPN
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Wireguard, OpenVPN oder Strongswan sind deine besten Freunde dafür unter Ubuntu ! Wenn du eh einen Hypervisor rennen hast macht es Sinn dort in einer VM eine pfSense oder OPNsense Firewall laufen zu lassen, was dir den ESXi wasserdicht sichert und auch sehr einfach des VPN für den Fernzugriff realisieren lässt. Siehe oben...
https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-esxi.html
https://docs.opnsense.org/manual/virtuals.html
Sorge dafür, dass sie nicht von überall aus aufrufbar ist. Beispielsweise nur die IP der Firma zulassen. Oder sichere es mit einem Client-Zertifikat ab, falls möglich. Zur Not eine ReverseProxy davor schalten mit dem du das mit dem Client-Zertifikat machen kannst.
Zitat von @NordicMike:
Wenn du von Loginversuchen sprichst, gehe ich als erstes von SSH aus. Port 22 sollte niemals in der Öffentlichkeit antworten. Dafür werden VPN Verbindungen gemacht.
Wenn du von Loginversuchen sprichst, gehe ich als erstes von SSH aus. Port 22 sollte niemals in der Öffentlichkeit antworten. Dafür werden VPN Verbindungen gemacht.
Da bin ich anderer Ansicht. Ob man Port 22 und ssh von außen erreichbar macht oder nicht, hängt imho vom konkreten Anwendungsfall ab. Sofern man das ordentlich durch zertifikate absichert und root-Login udn auch Login mit User/Paßwort abschaltet, kann man das druchaus errecihbar lassen, sogar auf Port 22. Man sollte nur mit fail2ban oder Firewall-regeln dafür sorgen, daß sich nicht Hinz und Kunz auf diesen Port verbinden können.
Den Port auf einen andern zu verlegen ist imho Geschmackssache, aber meiner Meinung nach nicht notwendig. Insbesodnere bei größerer Anzahl hosts ist es eher mehr verwaltungsaufwand, sich überall die Ports zu "merken", als alles auf dem Standardport zu lassen.
lks
ich würde mir keine Gedanken machen wegen den erfolglosen Anmeldeversuchen. Durchprobieren von Benutzernamen und Kennwörtern ist Skritkiddie-Nivea Ende der Achtziger. Trotzdem nicht ganz ungefährlich... wenns gut gemacht ist, als verteilte Kennwortattacke aus einer Flotte aus tausenden von gehackten Geräten die oft jeden Tag eine neue IP haben, da sie hinter einem privaten Internetmodem stehen 
Da ist mit klasssichen Quell-IP Blocking eher kein Blumentopf mehr zu gewinnen.
Hacker im Jahr 2021 nutzen entweder DDOS (auffällig) oder Zeroday-Angriffe (meist unauffällig). Vermutlich hats schon längst einer geschafft oder machen das mit Spear Fishing. z.B. mit Anrufen mit gefakter Telefonnummer, "hallo hier ist die IT, wir brauchen mal eben ihr Kennwort" oder per Chat rausgeleiert...
Ein erfolgreicher exploit-Versuch bei mir mal bei einer ungehärteten Window 2016 VM bei aktuellem Patch-Stand gerade mal 4 Tage gedauert bis die VM auffiel, mit 100% CPU Last und Anmeldung per RDP schlecht bis ganz unmöglich. Da das nur eine Testumgebung war, hab ich den Kram umgehend plattgemacht und neu mit VPN Gateway erstellt. (war eine AWS VPC)
Die VPN Gateways von AWs sind meines Wissens nach noch nie gecrackt worden, außer durch Diebstahl aller für ein MFA nötigen Informationen.
Da ist mit klasssichen Quell-IP Blocking eher kein Blumentopf mehr zu gewinnen.Hacker im Jahr 2021 nutzen entweder DDOS (auffällig) oder Zeroday-Angriffe (meist unauffällig). Vermutlich hats schon längst einer geschafft oder machen das mit Spear Fishing. z.B. mit Anrufen mit gefakter Telefonnummer, "hallo hier ist die IT, wir brauchen mal eben ihr Kennwort" oder per Chat rausgeleiert...
Ein erfolgreicher exploit-Versuch bei mir mal bei einer ungehärteten Window 2016 VM bei aktuellem Patch-Stand gerade mal 4 Tage gedauert bis die VM auffiel, mit 100% CPU Last und Anmeldung per RDP schlecht bis ganz unmöglich. Da das nur eine Testumgebung war, hab ich den Kram umgehend plattgemacht und neu mit VPN Gateway erstellt. (war eine AWS VPC)
Die VPN Gateways von AWs sind meines Wissens nach noch nie gecrackt worden, außer durch Diebstahl aller für ein MFA nötigen Informationen.
Ich würde wenn möglich alle Dienste, die nicht öffentlich gebraucht werden, auf der öffentlichen IP abstellen und das über ein VPN machen. So hat man da die Versuche schonmal weg.
Eine FW mit drop einzurichten kann man machen Stichwort Teergrube, muss aber nicht sein, bei TCP schickt der eh nen Reset und bei UDP kommt nichts, es kommt dann ein ICMP port unreachable.
Eine FW mit drop einzurichten kann man machen Stichwort Teergrube, muss aber nicht sein, bei TCP schickt der eh nen Reset und bei UDP kommt nichts, es kommt dann ein ICMP port unreachable.
Hallo!
Falls euch die Lösung interessiert, wir werden eine neue Firewall installieren und Zugriff mit VPN und VLAN beschränken.
(außer natürlich die Services die unsere Kunden benötigen)
Danke noch mal!
mfG Goodfred
Falls euch die Lösung interessiert, wir werden eine neue Firewall installieren und Zugriff mit VPN und VLAN beschränken.
(außer natürlich die Services die unsere Kunden benötigen)
Danke noch mal!
mfG Goodfred