Sicherheit: Fremde user per SSH verbinden lassen

[te one]

Hallo,

ich möchte (erstmal als Proof of Concept) eine Anwendung für die Uni im Netz verfügbar machen.
Da das einen Haufen Software drumherum benötigt, möchte ich die Studenten per SSH auf ein Ubuntu verbinden lassen. Jeder Student hat sein eigenenes Benutzerkonto. Der Server steht isoliert und es wird von außen nur der SSH-Port geöffnet. Ausgehende Verbindungen von diesem Server sind nicht erlaubt.

Gibt es hier größere Sicherheitsbedenken?

Anmerkung: Auf dem Server liegt nichts Geheimes. Die Studenten nutzen das eher als kleine Testumgebung.

Ich frage vor allem, weil ich mich mit Linux recht wenig auskenne. Ist ein normaler Nutzer genug beschränkt, um nicht das ganze System umzubauen?


Danke und Gruß

 

[konkretor]

was müssen die Benutzer den auf der shell machen, damit die einen SSH Zugang brauchen?

Ist deine Anwendung nicht per HTTPS zu erreichen?


Kommen die Leute aus dem Uni Netzwerk, dann lasse nur den IP Range der UNI zu

 

[te one]

Die Nutzer starten eine Prolog-Anwendung (SWI-Prolog). Diese wiederrum benutzt lokales Zwischenspeichern von Files, einen Mediaplayer, eine Datenbank, ... Eine schöne Lösung per HTTP/-S steht nicht in Aussicht.

Auch wenn der Großteil der User aus dem Uni-Netz kommt, so gibt es einige Einzelfälle von außerhalb. Um Anfangs ohne Schwierigkeiten starten zu können, möchte ich deshalb keine IP-Range festlegen.

Wie sieht es also ganz allgemein mit Linux-Sicherheit und "fremden/unbekannten" Benutzern aus?
Die Zugangsdaten werden dann übrigens schon benutzerbezogen sein. Jeder Nutzer wird also wohl etwas Respekt an den Tag legen.

 

[Simpson474]

Ein offener SSH-Port ist eine Einladung an die Chinesen, die haben scheinbar nichts anderes zu tun als unsere Server zu hacken. Entweder man verwendet Blocklisten für iptables um IP-Adressen aus China und Russland zu sperren, oder aber man sollte zumindest Tools wie fail2ban benutzen, welche IP-Adressen nach fehlgeschlagenen Logins sperren.

 

[AncapDude]

SSH von Port 22 weglegen, Problem des Vorredners gelöst. Wenn du ganz sicher gehen willst legst du Jails mit chroot an, dann kann kaum was passieren, erfordert aber mehr config.

 

[mkossmann]

Oder keine Authentifizierung per Password zulassen. Stattdessen über public-key des Benutzers wie z.B. hier beschrieben

 

[Piktogramm]

Die Passwortkomplexität muss ausreichend sein und der OpenSSH-Server muss immer aktuell gehalten werden.

Wenn die Nutzer NICHT in der Gruppe sudo / root / admin sind können sie eigentlich kaum Schaden anrichten. Was jeder Nutzer machen kann ist Forkbombs auf den Server loslassen und dann fährt sich die Kiste halt fest. Das simpelste Mittel ist es da die Anzahl der Prozesse die Nutzer gleichzeitig laufen haben können zu limitieren. An meiner Uni wird bei 2.000 Prozessen limitiert und gelegentlich scheint auch mal ein Cron loszuzlaufen, der alle Prozesse von Nutzern killt wenn diese ins Limit gelaufen sind.

 

[te one]

Also an sich scheint meine Idee, euren Aussagen nach, ausreichend sicher zu sein.
Standardport werde ich sowieso nicht verwenden und fail2ban wohl auch aktivieren.

Mit einem extra auth. Key zu arbeiten scheint zwar sinnig, erhöht aber wieder den Ärger/Aufwand mit den Studenten (teils informatikfern).

Über festgefahrene Sitzungen werde ich mir wohl auch Gedanken machen müssen. Hat jemand ein Skript parat um Nachts alle user rauszuwerfen?

 

[andy_m4]

Ich frage vor allem, weil ich mich mit Linux recht wenig auskenne.

Ich finds ja immer wieder faszinierend, wieviele Leute sich mit einem System nicht auskennen aber dann unbedingt einen Server ans Netz bringen wollen.

Ist ein normaler Nutzer genug beschränkt, um nicht das ganze System umzubauen?

Im Prinzip ja.Sie sollten dann aber idealerweise nicht in irgendeiner Benutzer-Gruppe sein.

Ergänzung (11. Mai 2018)

Wenn du ganz sicher gehen willst legst du Jails mit chroot an, dann kann kaum was passieren, erfordert aber mehr config.

Ähm chroot ist nicht als hinreichend sicher anzusehen.
Dann muss man schon Container nehmen wie LXC.
Optimalerweise cgroups, namespaces und Seccomp.

Aber im vorliegenden Fall ("kenn mich kaum mit Linux aus") kann man die ganzen Sachen eigentlich schon wieder vergessen.

 

[te one]

Ich finds ja immer wieder faszinierend, wieviele Leute sich mit einem System nicht auskennen aber dann unbedingt einen Server ans Netz bringen wollen.

Von "wollen" kann hier nicht die Rede sein. Es muss unter Zeitdruck eine Lösung her - und das war der einzige noch mögliche Weg mit Aussicht auf schnellen Erfolg.

Container-Technologie werde ich sowieso auf lange Sicht vorschlagen. Eigentlich gab es auch mal ein Docker-Image für die Software. Das war eigentlich dazu gedacht, dass die Studenten sich das ziehen und (lokal) nutzen. Da jedoch nur ein Bruchteil (vielleicht 10%) ein Linux zur Hand hat, ist das auch mit so viel Komplexität und Overhead verbunden, dass wir das wieder verworfen haben. Wenn wir das jetzt hosten, sieht das natürlich anders aus.

 

[mensch183]

Ist ein normaler Nutzer genug beschränkt, um nicht das ganze System umzubauen?

Kommt aufs Publikum an. Rechnest du mit böswilligen Studenten, die nichts anderes im Sinn haben, als dem Admin oder den anderen Studis das Leben schwer zu machen?

Falls ja:
Dann ist es alles andere als trivial, auf so einem Rechner mit Shell-Logins die Nutzer gegenseitig voreinander zu schützen. Das Problem ist nicht Datenklau o.ä. sondern die 1000 Varianten, den Rechner via Denial of Service unbrauchbar zu machen. Für solche Idioten würde ich an deiner Stelle keinen Rechner zur Verfügung stellen. Mögen sie sich selbst kümmern.

Falls nein:
Dann ist so ein kleiner Server mit Logins für paar Studenten gar kein Problem. Sieh zu, dass du /var, /tmp und /home auf extra Filesysteme legst, damit nicht alle auf einmal volllaufen können. Schau täglich mal nach, ob der Rechner noch "lebt" und wirf vielleicht mal einen Blick in die Logs. Sei für die Studis zeitnah erreichbar! Die merken viel eher als du, wenn was schief läuft. Falls jemand die Kiste offensichtlich mutwillig lahmgelegt hat: Schmeiß den Nutzer raus statt viel Energie zu investieren, wie man den DoS zukünftig verhindern könnte.

Einen Server für nette, vernünftige Leute zu betreiben, ist mit unixoiden Systemen quasi ein Kinderspiel. Server für destruktive Kundschaft zu betreiben ist hingegen _richtig_ stressig. Letzteres tut man nur, wenn man Ahnung davon hat und gut dafür bezahlt wird.

und fail2ban wohl auch aktivieren.

Laß solchen Blödsinn einfach bleiben. Du meintest doch, außer openssh nichts am Netz zu haben. Openssh hat selbst Mechanismen eingebaut, um gegen zu viele Verbindungsversuche gewappnet zu sein. Openssh ist kein Programm von Vollpfosten, die noch nie mit dem Internet zu tun hatten und deren Programm man deshalb nur hinter ekelhaften Krücken wie fail2ban betreiben sollte.

Veranstalte keine """Sicherheits"""-Basteleien, ohne dass es überhaupt ein Problem gab! Und __falls__ es tatsächlich mal ein Problem gibt: Analysieren. Verstehen. Passende Maßnahme ergreifen. In genau dieser Reihenfolge.

Fazit:
Stell den Server zur Verfügung. So lernen bei der Aktion nicht nur die Studis was dazu sondern auch du. Sag den Studis, sie sollen ihre Arbeitsergebnisse noch woanders sichern statt sie nur wochenlang auf diesem Rechner zu sammeln, wo sie ggf. bei einem "Unfall" verloren wären.

 

[te one]

Hallo zurück,
mein (SSH-)Server läuft seit 3 Tagen am Netz. Ich habe zufallsgenerierte Passwörter (Groß/Klein/Zahlen) und den Port umgelegt. Die User dürfen ihr Passwort nicht ändern. Bisher keine fehlgeschlagenen Logins und wohl 2mal von einem Portscanner erkannt worden.

Mit welcher Geschwindigkeit kann man bei einem BruteForce-Angriff denn rechnen? Ein Standard OpenSSH-Server wirft einen nach 3 Attempts ja raus... Außerdem können maximal 10 User gleichzeitig versuchen sich einzuloggen. Jetzt wüsste ich gerne wie lange ein Angreifer im Mittel zum Knacken eines Passworts braucht.

 

[mensch183]

Jetzt wüsste ich gerne wie lange ein Angreifer im Mittel zum Knacken eines Passworts braucht.

Bei vernünftigen Pass"wörtern" so lange, dass du es jedenfalls nicht mehr erleben wirst.

 

[te one]

Für Interessierte:
10 gleichzeitige Angriffe (das ist die maximale Anzahl gleichzeitiger Login-Anfragen), jeweils 2 Sekunden Anmeldeverzögerung: 1,4 Millionen Jahre, bis alle 8-stelligen Passworte mit Groß-/Kleinbuchstaben und Zahlen getestet wurden. Das ist für mich sicher genug