4
SSH-Tarpit auf Produktivsystem?
Hallo zusammen.
Ich würde mich sehr über eure Einschätzungen im folgenden freuen, ob die Idee in unserer "Abteilung" gut ist.
Zum Hintergrund. Wir betreiben einen Linux-Server, der vom Internet aus erreichbar ist, selbstverständlich nach Best-Practice abgesichert (mit der Ausnahme, dass eine SSH-Authentifizierung mit Benutzername und Passwort erlaubt ist, jedoch werden starke Passwörter gefordert).
Wir sehen natürlich trotz geändertem SSH-Port in den Logs regelmäßig "Angriffe" (sofern man die so bezeichnen kann ;)), bei denen einfach Standard-Kombinationen aus Username und Passwort ausprobiert werden. Nun spielen wir mit dem Gedanken, auf Port 22 eine SSH-Tarpit laufen zu lassen. Der Gedanke ist, dass (hoffentlich) der Standard-Angreifer aufhört, offene SSH-Ports zu suchen, sofern die 22 offen ist und er auch eine Antwort vom Server erhält.
Mich würde nun eure Meinung interessieren: Zahlt sich das von einem Sicherheits-Standpunkt her aus (glaube ja eher nicht, da keine kurzen und unsicheren Passwörter akzeptiert werden)? Bringt es mir andere Security-Benefits oder ist die Gefahr, mir entsprechend eher eine neue Lücke aufzureißen größer?
Schöne Grüße!
Ich würde mich sehr über eure Einschätzungen im folgenden freuen, ob die Idee in unserer "Abteilung" gut ist.
Zum Hintergrund. Wir betreiben einen Linux-Server, der vom Internet aus erreichbar ist, selbstverständlich nach Best-Practice abgesichert (mit der Ausnahme, dass eine SSH-Authentifizierung mit Benutzername und Passwort erlaubt ist, jedoch werden starke Passwörter gefordert).
Wir sehen natürlich trotz geändertem SSH-Port in den Logs regelmäßig "Angriffe" (sofern man die so bezeichnen kann ;)), bei denen einfach Standard-Kombinationen aus Username und Passwort ausprobiert werden. Nun spielen wir mit dem Gedanken, auf Port 22 eine SSH-Tarpit laufen zu lassen. Der Gedanke ist, dass (hoffentlich) der Standard-Angreifer aufhört, offene SSH-Ports zu suchen, sofern die 22 offen ist und er auch eine Antwort vom Server erhält.
Mich würde nun eure Meinung interessieren: Zahlt sich das von einem Sicherheits-Standpunkt her aus (glaube ja eher nicht, da keine kurzen und unsicheren Passwörter akzeptiert werden)? Bringt es mir andere Security-Benefits oder ist die Gefahr, mir entsprechend eher eine neue Lücke aufzureißen größer?
Schöne Grüße!
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: 667053
Url: https://administrator.de/contentid/667053
Printed on: April 27, 2024 at 18:04 o'clock
4 Comments
Latest comment
Ehrlich gesagt - ich habe einfach ban2ip installiert, nach 3 fehlversuchen is für 24h von der IP ruhe... Dabei suche ich mir von Zeit zu Zeit auch immer raus von wo versucht wurde und sperre ganze IP-Ranges komplett via Firewall (z.B. China,...) wenn ich weiss das von da aus eher kein legaler/sinnvoller Zugriff auf meinen Server stattfinden wird.
Damit bin ich bei den SSH-Versuchen von mehreren 1000 auf ne Handvoll runter - und es braucht mich auch nich weiter zu kümmern ob die danach noch andere Dinge versuchen weil eben die IP komplett gesperrt wird. Da ich manuell ausser der Installation keine Arbeit damit hatte/habe reicht das auf jeden Fall schon mal für das meiste aus...
Damit bin ich bei den SSH-Versuchen von mehreren 1000 auf ne Handvoll runter - und es braucht mich auch nich weiter zu kümmern ob die danach noch andere Dinge versuchen weil eben die IP komplett gesperrt wird. Da ich manuell ausser der Installation keine Arbeit damit hatte/habe reicht das auf jeden Fall schon mal für das meiste aus...
1
Moin,
Nein, nicht gut.
Damit habt Ihr aber das Wichtigste der best practice weggelassen. Warum? Was spricht gegen ein Login nur mit key?
Den Port zu ändern bringt genau 0 mehr Sicherheit. Du siehst es ja. Es werden gerne alle Ports gescannt.
Das ist so. Das normale Rauschen im Internet.
Und warum sollte das dazu führen?
imho eher nicht.
Und wie genau verhindert Ihr, dass "M3inP@assw0rt" oder "N@m3M31n3r0m@" geht? Key-only ist imho Pflicht, wenn man das aus dem Internet erreichbar macht.
Eher letzteres. Wie Kollege @maretz schon sagte, ist der richtige Weg, die IPs zu blockieren und black lists zu führen. Noch besser wäre eine white list, die Verbindungen nur von bekannten IPs zulässt.
Liebe Grüße
Erik
Zitat von @peterla:
Ich würde mich sehr über eure Einschätzungen im folgenden freuen, ob die Idee in unserer "Abteilung" gut ist.
Ich würde mich sehr über eure Einschätzungen im folgenden freuen, ob die Idee in unserer "Abteilung" gut ist.
Nein, nicht gut.
Zum Hintergrund. Wir betreiben einen Linux-Server, der vom Internet aus erreichbar ist, selbstverständlich nach Best-Practice abgesichert (mit der Ausnahme, dass eine SSH-Authentifizierung mit Benutzername und Passwort erlaubt ist, jedoch werden starke Passwörter gefordert).
Damit habt Ihr aber das Wichtigste der best practice weggelassen. Warum? Was spricht gegen ein Login nur mit key?
Wir sehen natürlich trotz geändertem SSH-Port
Den Port zu ändern bringt genau 0 mehr Sicherheit. Du siehst es ja. Es werden gerne alle Ports gescannt.
in den Logs regelmäßig "Angriffe" (sofern man die so bezeichnen kann ;)), bei denen einfach Standard-Kombinationen aus Username und Passwort ausprobiert werden.
Das ist so. Das normale Rauschen im Internet.
Nun spielen wir mit dem Gedanken, auf Port 22 eine SSH-Tarpit laufen zu lassen. Der Gedanke ist, dass (hoffentlich) der Standard-Angreifer aufhört, offene SSH-Ports zu suchen, sofern die 22 offen ist und er auch eine Antwort vom Server erhält.
Und warum sollte das dazu führen?
Mich würde nun eure Meinung interessieren: Zahlt sich das von einem Sicherheits-Standpunkt her aus
imho eher nicht.
(glaube ja eher nicht, da keine kurzen und unsicheren Passwörter akzeptiert werden)?
Und wie genau verhindert Ihr, dass "M3inP@assw0rt" oder "N@m3M31n3r0m@" geht? Key-only ist imho Pflicht, wenn man das aus dem Internet erreichbar macht.
Bringt es mir andere Security-Benefits oder ist die Gefahr, mir entsprechend eher eine neue Lücke aufzureißen größer?
Eher letzteres. Wie Kollege @maretz schon sagte, ist der richtige Weg, die IPs zu blockieren und black lists zu führen. Noch besser wäre eine white list, die Verbindungen nur von bekannten IPs zulässt.
Liebe Grüße
Erik
Zum Hintergrund. Wir betreiben einen Linux-Server, der vom Internet aus erreichbar ist, selbstverständlich nach Best-Practice abgesichert (mit der Ausnahme, dass eine SSH-Authentifizierung mit Benutzername und Passwort erlaubt ist, jedoch werden starke Passwörter gefordert).
Keine Zertifikate?
Wir sehen natürlich trotz geändertem SSH-Port in den Logs regelmäßig "Angriffe" (sofern man die so bezeichnen kann ;)), bei denen einfach Standard-Kombinationen aus Username und Passwort ausprobiert werden.
Security by Obscurity mit normalem Grundrauschen.
Nun spielen wir mit dem Gedanken, auf Port 22 eine SSH-Tarpit laufen zu lassen. Der Gedanke ist, dass (hoffentlich) der Standard-Angreifer aufhört, offene SSH-Ports zu suchen, sofern die 22 offen ist und er auch eine Antwort vom Server erhält.
Das kann man natürlich für automatisierte Sperren (Fail2ban) auf der Firewall heranziehen. Wie wäre es mit der expliziten Freigabe bestimmter Wartungssysteme?
Hallo,
die Überlegung ist ja vermutlich, dass wenn der "Angreifer" die Tarpit auf Port 22 findet er sich nur damit beschäftigt und den restlichen Server ignoriert. Das ist aber nicht der Fall.
Der Angreifer ist ein Bot/Skript was eine Liste von IPs und Ports durchgeht und allen die gleiche Aufmerksamkeit widmet.
Diese Liste werden von anderen Bots/Skripten erstellet die nur alle IPs mit allen Ports durchgehen. Es tauchen also beide Ports in dieser Liste auf und beide werden gleichsam überprüft.
Du hast eher sogar den Nachteil, dass der Tarpit-Port eine Sicherheitslücke hat und der Angreifer darüber weiterkommt.
Nicht wahrscheinlich, aber möglich.
Hilfreich ist GeoIP sowie Fail2Ban (wurde ja schon gesagf).
Aber auch nur bedingt.
Angriffe die wir bei Kunden beobachten haben wurden von hunderten IPs ausgeführt.
Mit einer Authentifizierung über Schlüssel statt Datei sichert man diese deutlich ab.
Sicherheitslücken wird man dadurch nicht los.
Deutlich sicherer ist ein VPN oder Sicherheitsgateway welches die Verbindung bereits auf IP-Ebene unterbindet.
Stefan
die Überlegung ist ja vermutlich, dass wenn der "Angreifer" die Tarpit auf Port 22 findet er sich nur damit beschäftigt und den restlichen Server ignoriert. Das ist aber nicht der Fall.
Der Angreifer ist ein Bot/Skript was eine Liste von IPs und Ports durchgeht und allen die gleiche Aufmerksamkeit widmet.
Diese Liste werden von anderen Bots/Skripten erstellet die nur alle IPs mit allen Ports durchgehen. Es tauchen also beide Ports in dieser Liste auf und beide werden gleichsam überprüft.
Du hast eher sogar den Nachteil, dass der Tarpit-Port eine Sicherheitslücke hat und der Angreifer darüber weiterkommt.
Nicht wahrscheinlich, aber möglich.
Hilfreich ist GeoIP sowie Fail2Ban (wurde ja schon gesagf).
Aber auch nur bedingt.
Angriffe die wir bei Kunden beobachten haben wurden von hunderten IPs ausgeführt.
Mit einer Authentifizierung über Schlüssel statt Datei sichert man diese deutlich ab.
Sicherheitslücken wird man dadurch nicht los.
Deutlich sicherer ist ein VPN oder Sicherheitsgateway welches die Verbindung bereits auf IP-Ebene unterbindet.
Stefan