Frage zur SSH Sicherheit

[iceview]

Hallo,

brauche mal eben Eure Hilfe.

Ich habe für 2 Server einen SSH Zugang ermöglicht.

Da dieser nicht offen im Netz stehen soll habe ich zwei Dinge gemacht:

1.) Port geändert

2.) Der davor stehenden Firewall gesagt, dass nur der IP Range des VPN erlaubt ist diesen Port auf diesen Maschinen zu nutzen.

Also sinngemäß: Allow --> VPN IP Range --> neuer SSH Port auf --> 2 Server


Nun drei Fragen:

1.) Das VPN befindet sich in einem 10.242.2.x Netz --> es ist doch korrekt, dass die Range von 10.242.2.1 - 10.242.2.255 eine /24 Maske hat oder?

2.) Die SSH kann man tatsächlich nicht -wie z.B. eine htaccess- auf eine Range einschränken?

3.) Reicht dies als Sicherheit in Euren Augen aus (also Firewall mit definierter IP Range und Port)? Ich halte einen Zugang mittels SSH-Keyfiles eigentlich nicht mehr für notwendig oder?

Gegenüber der FW kann man sich nicht "mal eben" mit der IP authentifizieren... ich meine dafür gibts die Dinger ja oder?

Danke für Eure Tipps

 

[Vastator]

welchen port für ssh hast Du vergeben >> es sollte der 443 sein :-)
edit: P.S. Manchmal geht ein Kamel auch durch ein Nadelöhr :-) - sry :-)
edit02: Äääh, habe ich da was falsch verstanden? Wenn die server eh nicht im öffentlichen Netz sind - warum dann dieser Aufwand? :-)
edit03: Die Philosphie von ssh ist aber schon klar? - denke ich doch :-) ;-)

 

[marcol1979]

es ist doch korrekt, dass die Range von 10.242.2.1 - 10.242.2.255 eine /24 Maske hat oder?

Wenn du die vergeben hast ja, sonst wäre es eine /8

Die SSH kann man tatsächlich nicht -wie z.B. eine htaccess- auf eine Range einschränken?

Bei der SSH Software sollte man das einstellen können.
Bei freeSSHd zb. siehe Bild.

Reicht dies als Sicherheit in Euren Augen aus (also Firewall mit definierter IP Range und Port)?

Sollte reichen. Brauchst ja nur nach ein paar Tagen mal die Logs der SSH Software durchschauen.

 

[Daaron]

Man kann es auch übertreiben...
Ein hübsch langes, kryptisches Passwort in Kombination mit restriktiv konfiguriertem Fail2Ban sorgt locker flockig dafür, dass die nächsten paar Jahre kein Brute-Force von Erfolg gekrönt sein wird.

 

[Mumpitzelchen]

welchen port für ssh hast Du vergeben >> es sollte der 443 sein :-)

HTTPS != SSH. Deswegen sollte es ganz ganz sicher nicht 443 sein.

Sofern der Server nur auf der IP 10.x.x.x lauscht, kann niemand vom Internet aus darauf zugreifen. Niemand. Falls doch hat dein ISP sein Netzwerk gnadenlos falsch konfiguriert.
Wenn du SSH absichern willst, erlaubst du logins nur mittels Zertifikat.

Statt dich um dein SSH Zugang zu sorgen solltest du dir nur und auschließlich Sorgen um deinen VPN Zugang machen.

 

[andryyy]

Kommt halt darauf an, wie sehr man sich absichern möchte.

Den Port würde ich auf alle Fälle umlegen (/etc/sshd/sshd_config > Port), fail2ban ist eine einfache Lösung, wenn man nicht so fit mit netfilter/iptables ist. Den Zugriff nur von bestimmten IPs zulassen, idealerweise läuft hierbei ein VPN (OpenVPN?), der dann interne IPs vergibt. Dann kannst du noch root das einloggen via sshd verbieten, auch in der sshd_config.
Und wenn wir schon dabei sind () kannst du auch nur noch das einloggen mit Zertifikat PLUS Passwort erlauben.

Das sind alles Einstellungen, die schwer klingen, aber wirklich einfach umzusetzen sind. Google hat da einen Haufen Tutorials.

Achso, zu Frage 2: Einfach mit iptables machen.

/sbin/iptables -A INPUT -s ! 10.242.2.0/24 -p tcp --dport 22 -j DROP

Alles, was NICHT von deiner VPN range kommt, wird gedroppt. Wenn du via iptables von vornherein alles zulässt, außer XY, dann ist das so richtig. Port 22 ist jetzt nur ein Beispiel.

Ansonsten halt:

/sbin/iptables -A INPUT -s 10.242.2.0/24 -p tcp ---dport 22 -j ACCEPT

 

[iceview]

Viele Antworten, danke!

Also den Port 443 zu nutzen wäre ja doch ziemlicher Leichtsinn oder nicht?


Ich nutze die Range 10.242.2.0-10.242.2.254 für das VPN. Das sind doch private Ranges...??
Die Firewalls von Astaro konfigurieren das VPN ja mittels Einwahlclienten selber.

Lediglich das Regelwerk muss man dann noch festlegen. Dieses besagt eben, dass nur wer aus dem VPN kommt und den Port 34222 benutzt, an die Server rankommt.

@andry:
Ich denke die HW-Firewall macht ja nix anderes als genau diese IP Tables zu generieren. Ich weiss nicht ob ich es dann nochmal am Server machen muss.

@marcol1979:
Es gibt ja jeden Tag ein Log der Firewall was an Angriffen stattgefunden hat. Man sieht eben, dass oft auf dem 22 und auf dem 445 angeklopft wird.

Ich hab mal nen Beispiel angehangen, ich denke da kann man recht gut verfolgen was eben passiert.

 

[Vastator]

sorry - ich habe nur kurz über den entree gelesen - deswegen nehme ich den 443 port ntl. zurück - sorry an alle. :-)

 

[andryyy]

Der Server wird dann ja eh nur eine interne IP haben. Ist okay, wenn du das via Firewall so geregelt hast, mehr braucht es dann nicht. Schau halt nur, dass du nicht alles blind an deinen Server weiterleitest.

Und ja, das ist eine private range, eben 10.242.2.0/24. 10.0.0.0/8 ist komplett privat, eben: 10.0.0.0-10.255.255.255.

 

[andy_0]

Wie von andryyy vorgeschlagen, würde ich grundlegend den Zugriff auf die Shell für den root unterbinden. Dazu würde ich den Zugriff nur per Key erlauben. Ist dies geschehen, ist das System schon zweifach "unangreifbar". Jemand müsste nicht nur den dein korrekten Loginnamen kennen sondern auch über den passenden Schlüssel verfügen.

Du kannst den Port zwar ändern, finde ich persönlich aber eher sinnfrei. Es macht Sinn, wenn du den Dienst direkt verstecken willst. In einem privaten Netz ist das aber eigentlich nicht notwendig? Die Limitierung auf eine IP/IP-Range ist für gewöhnlich eine gute Möglichkeit um Sicherheit zu schaffen. Die "Erschleichung" einer IP in einem internen Netzwerk doch eher ein leichtes Spiel oder? Bin mir also nicht sicher ob die Beschränkung auf IPs dir was bringt.

 

[iceview]

@andryyy:

Ja der Server ist nur durch eine interne IP erreichbar.

Sieht so aus:

Domain mit fester IP -> Schnittstelle der FW --> NAT / Reverse Proxy --> LAN IP



@andy_0:

Klar root access ist abgeschaltet. Die feste IP Range von der wir reden ist ja die, welche durch das VPN der Firewall vergeben wird.

10.242.x.x

Die Server selber haben wiederum ja andere interne Subnetze. Die IP des VPN ist eben nicht einfach mal zu beziehen...

 

[mensch183]

Wie von andryyy vorgeschlagen, würde ich grundlegend den Zugriff auf die Shell für den root unterbinden. Dazu würde ich den Zugriff nur per Key erlauben. Ist dies geschehen, ist das System schon zweifach "unangreifbar". Jemand müsste nicht nur den dein korrekten Loginnamen kennen sondern auch über den passenden Schlüssel verfügen.

Falsch. Remote root logins sperren und Mr. Root zum Umweg über einen normalen Account zwingen ist grober Unfug. Warum?

Der remote ssh Zugang als root funktioniert solange zuverlässig, wie auf der Zielkiste kein Angreifer Rootrechte erlangt hatte. (es ist sowieso zu spät)

Der remote Zugang über einen normalen Account + root werden per su o.ä. funktioniert solange zuverlässig, wie auf der Zielkiste kein Angreifer Rootrechte erlangt hatte (=es ist sowieso zu spät) ODER (=zusätzliche Möglichkeit) Zugriff auf den vewendeten normalen Account hatte (wo er z.B. lokal ein anders su installiert, was aussieht wie das echte und das Root-PW abfängt).

Der erzwungende Umweg über eine normalen Account für einen remote root login bringt also keinen Sicherheitsgewinn sondern VERGRÖSSERT die Zahl der Angriffsmöglichkeiten.

 

[andy_0]

Wieso bringt das kein Sicherheitsgewinn? Der Sicherheitsgewinn liegt in der Verschleierung des gültigen Logins. Sämtliche automatisierten Angriffe versuchen Zugriff via root/admin/administrator zu erlangen. Diese Angriffe gehen alleine durch den Wechsel den gültigen Loginnamens ins Leere.

Zur Installation von Paketen auf dem Zielrechner benötigt er das jeweilige Passwort des Logins. Da ich nicht vorschlage den Login über irgendein popligen regulären User d.h. ein alltäglich verwendeter Login (z.B. in einem aktiven Firmennetz) durchzuführen, sondern mit einem "alternativen Admin", ist das Erlangen des Passworts gleichzusetzen mit dem Zugriff auf das Root Kennwort.

Möglich wäre natürlich Spionage über Modifikation spezielle Pakete wie z.B. su. Da kann ich aber auch argumentieren, dass der Angreifer einfach eine modifizierte Version von /bin/bash ausliefern braucht. Beides ist gleich schwer, da man Root Rechte oder lokalen Zugriff auf die Maschine benötigt. Der Austausch der Shell gewährt einem jedoch unbeschränkten Zugriff und ist somit deutlich sinnvoller. Warum also su Angreifen?

 

[iceview]

Auf meinem Server existiert nur ein Benutzer. Dieser gehört dann logischerweise zur Gruppe der Administratoren.

Der eigentliche root ist deaktiviert, somit denke ich, dass ein potentieller Angreifer ja erstmal einige Hürden nehmen muss:

1.) Firewall
2.) geänderter SSL Port
3.) VPN IP Kreis inkl. der Authentifierung gegenüber der Firewall
4.) Interne IP des Servers ermitteln
5.) Login Name des Benutzers
6.) Passwort des Benutzers.

Wenn alles dies erfolgt ist, ja dann... kann er an den Server ran...

 

[iceview]

Ich häng hier nochmal ne Frage rein.

Was bewirkt es, wenn ich in der sshd_config den String "server keybits" von 768 auf 2048 veränder?

 

[andy_0]

Server Keybits: "Defines the number of bits in the server key. The minimum value is 512, and the default is 768."

Du vergrößerst damit die Schlüssellänge. Ich hab mal schnell gegoogelt. Bei einem Eintrag von Cisco (http://www.cisco.com/en/US/docs/app.../v7.40/configuration/security/guide/sshd.html) wurde angemerkt, dass dies offenbar nur bei SSHv1 greift (kA ob das für dich relevant ist).

Insgesamt denke ich nicht, dass du das benötigst.

 

[iceview]

Danke

 

[apt]

Es empfiehlt sich ebenfalls den root-Usernamen den ssh Zugang zu verbieten.
Ein weitere Tipp ist es fehlerhafte Zugriffe zu blacklisten. 3 fehlerhafte Zugriffe einer IP = gesperrt

 

[Marek72]

Auf meinem Server existiert nur ein Benutzer. Dieser gehört dann logischerweise zur Gruppe der Administratoren.

Das ist sicher nicht optimal, den einzigen Nutzer den Du als Login User verwendest noch in die Admin Gruppe zu legen! Hätte den selben Effekt wie sich mit root anzumelden!

Ansonsten sind ja alle Standard Vorgehensweisen genannt worden:

- Root Login unterbinden
- SSH Port ändern
- fail2Ban nutzen
- IP Range für ssh festlegen ist sicher im VPN auch nicht dumm
- Verwendung von Key`s - sofern Du Dich nicht ständig von anderen Maschinen auf den Servern anmelden willst und nicht ständig einen Stick mit dem Key herumschleppen willst!