SSH Port (22) schließen

[Gast[200516]]

Hallo Leute,

ich benutze 1&1 Cloud Server, und bin grade dabei, deren Sicherheit zu optimieren. Meine Idee war es nun, statt SSH Keys zu benutzen, einfach den SSH Port zu schließen (Hardware-Firewall). Notwendige Terminal-Aufgaben könnte ich über die KVM-Konsole erledigen, bzw. den SSH "kurzzeitig" freigeben.
Was meint ihr dazu? Würde das zur Sicherheit des Servers beitragen?

Ich benutze Plesk, und benötige SSH grundsätzlich nur für die Updates, welche ich alle 1-2 Tage durchführe. Die KVM-Konsole reicht hier für mich locker aus.

Übersehe ich hier irgendwas, oder ist das einfach etwas "was man nicht tut"?

P.S: Das Telnet geschlossen ist, ist für mich selbstverständlich

Liebe Grüße

 

[Lord Gurke]

Kann man machen, halte ich aber für echt unpraktisch.
Wenn du SSH ohnehin so konfigurierst dass nur Key-Basierte authentifizierung möglich ist, würde ich den SSH-Port höchstens woanders hin verlegen um das Log nicht so vollgemüllt zu bekommen.
Alternativ kann man über VPN nachdenken und den SSH-Port nur per VPN zugänglich machen.

 

[Bachsau]

In einen vernünftig gesicherten SSH kommt niemand rein. Versetz den Port, damit du nicht gefloodet wirst und alles ist gut.

Was die Firewall angeht, macht es eigentlich keinen Sinn, irgendwelche Ports aus Prinzip zu blockieren, auch telnet nicht. Die Ports im unteren Bereich können unter Linux nur von root geöffnet werden. Möchte man einen Dienst nicht nutzen, lässt man den entsprechenden Daemon besser gar nicht erst laufen.

Wenn du SSH aber unbedingt komplett verstecken willst, kannst du auch Portknocking einsetzen.

 

[Lord Gurke]

Was die Firewall angeht, macht es eigentlich keinen Sinn, irgendwelche Ports aus Prinzip zu blockieren, auch telnet nicht.

Ich habe in der Firewall nur Regeln, die explizit nur von mir gewollte Ports öffnen, der Rest wird gedropped.
Dann kann ich auch nicht versehentlich einen Dienst ins Internet stellen ohne es zu wollen.

 

[Gast[200516]]

1&1 Cloud Server schließt grundsätzlich alle Ports. Man muss "gewünschte" Ports öffnen. Ich überlege mir grade auch, vielleicht statt PublicKeys 2-Faktor Auth mit Authy oder Google Authenticator zu machen. Erfahrungen? Wie sieht es da mit der Sicherheit aus?

 

[kannnix]

Ich persönlich verfolge seit einiger Zeit einen Vorschlag eines Users aus dem Heise Forum:

http://www.heise.de/forum/heise-Sec...besser-22-behalten-und/posting-23778972/show/

D.h. SSH Port auf 22 lassen, keys aktivieren und die falsche Passwort Meldung 5 oder 10s verzögern. Dadurch werden die Bots ausgebremst und je mehr Server das so machen, desto unwirtschaftlicher wird es für den Angreifer.

Gruss

 

[d4f]

Notwendige Terminal-Aufgaben könnte ich über die KVM-Konsole erledigen, bzw. den SSH "kurzzeitig" freigeben.

Ohne Details von 1&1 zu kennen oder berücksichtigen: die vKVM-Konsolen sind generell VNC-Verbindungen welche sogar oft ohne jedgliche Verschlüsslung ablaufen. Unabhängig von Verschlüsslung kennt VNC aber nicht mal das Konzept eines Benutzernamens und oft auch kein Bruteforce-Schutz.
Solange der Port nicht erst nach HTTP-Authentisierung geöffnet wird ist die Sicherheit also nicht wirklich verbessert.

falsche Passwort Meldung 5 oder 10s verzögern. Dadurch werden die Bots ausgebremst und je mehr Server das so machen, desto unwirtschaftlicher wird es für den Angreifer.

Ein einzelner Angreifer kann problemlos mehrere zehntausend Verbindungen aufhalten, limitierender Faktor ist immer das Aushandeln der SSH-Verbindungen. Er kann zwar nicht weniger schnell brute forcen, das sollte dank fail2ban o.ä. aber eh vernachlässigbar sein.
Übrigens kann man bei einem Passwort davon ausgehen dass wenn nach bspw 0.5 Sekunden keine Bestätigung kam das Passwort falsch ist. Also einfach Verbindung schliessen...

 

[Bachsau]

Ich überlege mir grade auch, vielleicht statt PublicKeys 2-Faktor Auth mit Authy oder Google Authenticator zu machen. Erfahrungen? Wie sieht es da mit der Sicherheit aus?

Scheint mir nicht als ob du so wirklich weißt was du da eigentlich machst. Etwas sichereres als asynchrone Kryprografie gibt es nach aktuellen stand der Technik kaum. Wenn du einen zweiten Faktor willst, verschlüssel deinen Keyfile mit einem Passwort.

Abgesehen davon, dass das Authenticator-Verfahren auch auf einem Shared Secret basiert, würde es tieferes Know-How benötigen, soetwas einzubauen. Stichwort PAM. Ob es dann überhaupt einen Sicherheitsgewinn brächte ist höchst fragwürdig.

 

[elias5000]

Ich benutze für meine persönlichen Server einen Yubi-Key um Passwort-Auth als Fallback (zu Public-Key-Auth) mit einem zweiten Faktor zusätzlich abzusichern [1]. Dabei verlange ich erst einen gültigen Yubi-Key bevor überhaupt nach einem Passwort gefragt wird.

Allerdings ist das ein Fallback, weil ich Passwort nicht ganz ausschalten will. Ein Fallback, den ich ale Jubeljahre mal benutze. Und einer, der nicht ganz trivial einzurichten ist.
Falls du jedoch der Sache wegen mit 2-Faktor-Auth experimentieren willst, kann ich das Yubi-Key PAM-Modul durchaus empfehlen.

Es gibt auch noch eine zweite Version davon, die die Eingabe lokal validiert. Dabei werden dann jedoch alte Keys nicht an zentraler Stelle invalidiert. (Yubi ist nicht time based sondern basiert auf Zählern (power-up count und keys since last power-up) wobei eine Auth-Request gegen die API jeweils alle Key, die auf niedrigeren Zähler-Werten basieren invalidert.

[1] https://developers.yubico.com/yubico-pam/

 

[danton]

ich benutze 1&1 Cloud Server, und bin grade dabei, deren Sicherheit zu optimieren. Meine Idee war es nun, statt SSH Keys zu benutzen, einfach den SSH Port zu schließen (Hardware-Firewall).

Über den Sinn oder Unsinn dieser Aktion wurde ja schon einiges hier geschrieben, auch bezüglich der Sicherheit der KVM-Verbindung. Wenn du den SSH-Port in der Firewall sperrst, kannst du auch genausogut einfach den SSH-Daemon auf deinem Server stoppen (und bei Bedarf über KVM starten) - da brauchst du nicht mal was in der Firewall zu sperren. Ein Port, auf dem kein Dienst lauscht, ist sowieso zu und muß daher nicht extra per Firewall geschlossen werden.
Statt SSH würde ich im Punkt Sicherheit eher mal wegen anderer unsicherer Protokolle schauen, ob diese noch benötigt werden (z.B. FTP kann in den meisten Fällen durch das auf SSH aufsetzende SFTP ersetzt werden)

 

[Deleted member 11740]

Du kannst das sogenannte Port-Knocking auf deinem Server aktivieren. Dabei wird der Port 22 erstmal geschlossen. Man sucht sich einen beliebigen freien Port aus und sendet an diesen Port x Pakete via UDP. Erst dann wird die Firewall für den Port 22 kurzzeitig geöffnet. Ich selbst finde diese Vorgehensweise aber eher hinderlich.