Dann wird der Support aber von "Anfängern" vollgeheult werden, die einfach nur ein Passwort wollten... Also nur mehr Arbeit
Kein Argument!
Dann wird der Support aber von "Anfängern" vollgeheult werden, die einfach nur ein Passwort wollten... Also nur mehr Arbeit
Kein Argument!
Kein Argument!
Ich meinte, das netcup das wohl eher nicht machen wird (also key only), da dann jeder unwissende den Support anschreibt, was natürlich (für den Support) mehr Arbeit macht. Ich meinte damit nicht den Aufwand für Kunden.
Man könnte ja im CCP/SCP ein einfaches Textfeld einbauen um den Public Key abzufragen. Der muss ja dann nur in die authorized_keys geschrieben werden.
Genau. Ähnlich wie das ja derzeit auch schon im WCP ("SSH Keys Manager") gemacht wird.
Ich denke, es würde bereits genügen, den Server im abgeschalteten Zustand und ohne Autostart auszuliefern.
Gleichzeitig würde ich nur ein wirklich getestetes Minimalsystem als Default setzen. Oder Zumindest bei den Vorinstallationen eine richtige Anleitung anbieten.
Diese preinstall Dinger sind schön für die "ahnungslose Masse, die sich mal gerade einen Server mietet, weil er ja so billig ist und ja schon alles läuft"; mit allen (im Forum zu lesenden) Konsequenzen.
Preinstalled Images haben für mich auch was von einem ALDI Rechner.
Da iss ne Meeeeenge drauf, damit für jeden was dabei ist, aber 90% davon wird von kaum jemandem benutzt, oder man weiß garnicht, daß das drauf ist und was es macht.
Man könnte ja im CCP/SCP ein einfaches Textfeld einbauen um den Public Key abzufragen. Der muss ja dann nur in die authorized_keys geschrieben werden.
so lange das Format von authorized_keys f. den Serverteil des KEYS unabhängig von der Distro/vom Release ist ...
(RFC4716-Format? OpenSSH-Format?)
Hallo,
indeed.
Ich wollte nur nochmal betonen, daß das auch Angeraten ist.
Server haben bei mir grundsätzlich gar keinen Passwort Zugriff. Das Erste ist das Aufspielen meines Key und das Sperren aller Passwortlogins.
es ging hier um das root Passwort, welches schon vorhanden sein sollte allerdings erst nachdem SSH für root verboten wurde.
Eckhard
es ging hier um das root Passwort, welches schon vorhanden sein sollte allerdings erst nachdem SSH für root verboten wurde
Das solltest du dann aber auch dazuschreiben.
Moin!
Ich bin noch relativ "frisch" was das eigene Administrieren von Servern - in meinem Fall einen V-Server - angeht. Bevor ihr jetzt die Hand auf die Augen legt, sicherlich eine häufige Geste, ich habe das ganze tatsächlich mal im Master-Studium gehabt, aber lange ist es her. Nachdem der Server aufgesetzt wurde, habe ich Ubuntu 18.04.3 LTS mit Docker aus den NetCup-Images gewählt und folgendes getan:
Eine Überprüfung des Servers eben mit dem tool rkhunter ergab erstmal keine "Treffer", der log für fail2ban ist auch relativ überschaubar.
Kann ich noch etwas tun, um den Server mehr abzusichern?
Viele Grüße *smily*
Kann ich noch etwas tun, um den Server mehr abzusichern?
Dieses hier verinnerlichen: Das sichere Betreiben eines Servers ist eine niemals endende Aufgabe, welche regelmäßig viel Zeit in Anspruch nimmt.
Als Einstieg: InfoSec Handbook: Web server security series durchlesen, einschlägige RSS-Feeds (Beispiel) abonnieren.
Alleine bei Betreiben eines Webservers sollten "Stichworte" wie mod_security, OWASP, ... dem Administrator etwas sagen.
Speziell Port 22 muss nicht zwingend dauerhaft geöffnet sein, dafür gibt es beispielsweise knock.
Jegliche Administrationsschnittstellen/nicht-öffentliche Dienste lassen sich (lies: sind) mittels 2FA ab(zu)sichern, und sei es initial durch Beschränkung des Zugriffes auf den lokalen Host, über welchen man nur mittels SSH (port forwarding) herankommt.
Protokolle über sicherheitsrelevante Ereignisse sind zum Lesen da. tenshi o.ä. kann helfen, diese vorzufiltern, aber man will immer alle Informationen im Zugriff haben.
[...] Ubuntu 18.04.3 LTS mit Docker [...]Setzen von iptabeles (22, 80, 443 erlaubt als IN, Out erstmal alles) [...]
Achtung, Docker schreibt eigene Regeln in iptables, sodass die eigene Firewall meist nicht für Docker wirkt!
Ein paar Links (ufw = nettes Frontend für iptables):
https://docs.docker.com/network/iptables/
What is the best practice of docker + ufw under Ubuntu
How to fix the Docker and UFW security flaw
Und eine kleine Anmerkung noch: in Zukunft wird wohl nftables das in die Jahre gekommene iptables ablösen.
Hallo,
vielen Dank für die ganzen Hilfreichen Links und Hinweise. Ich habe jetzt mal noch einiges von dem, was ihr Drei (julian-w, m_ueberall, & vmk) umgesetzt. Inbesondere das übersichtlichere Logging mit lnav werde ich mir als nächstes anschauen und mit Lynis habe ich auch mal das System getestet und einige Dinge umgesetzt.
Im Zuge einer SSH-Portneusetzung habe ich auch gemerkt, dass Fail2Ban gar nicht richtig konfiguriert war, weil SSH-DDOS-Jails wohl in SSH-Jails integriert wurden.
Achtung, Docker schreibt eigene Regeln in iptables, sodass die eigene Firewall meist nicht für Docker wirkt!
Solche Hinweise sind Gold wert, ich scheine aber "Glück" gehabt zu haben. Ich hatte, bevor ich den Hinweis mit DOCKER_OPTS="--iptables=false" gelesen habe, den Zugriff auf ein Programm im Docker getestet. Es ging kein Fernzugriff, solange ich in der IP-V4-Table nicht den Port freigegeben hatte.
Dein Post hat mir aber nochmal vor Augen geführt, dass ich IPv6 völlig ignoriert hatte - gleich mal weitere Regeln erstellt. Mit nftables wird das wohl etwas komfortabler.
Ich denke, es würde bereits genügen, den Server im abgeschalteten Zustand und ohne Autostart auszuliefern.
Gleichzeitig würde ich nur ein wirklich getestetes Minimalsystem als Default setzen. Oder Zumindest bei den Vorinstallationen eine richtige Anleitung anbieten.
Sehe ich genauso. Ich würde definitiv nur den rohen Server zur Verfügung stellen und die Installation dem Kunden überlassen. Zum eigentlichen Thema dem Absichern, fehlt es mir.
Da gibt mit Shorewall ein sehr gutes Programm, mit dem IPTables-Firewalls generiert werden können. Als Nächstes muss in der /etc/ssh/sshd.conf "PermitRootLogin no" gesetzt werden und der SSH neugestartet werden. Alle unnötigen Ports sollten über Shorewall ins Net geschlossen sein. Dann kann erstmal nichts passieren.
Aber einen Rootserver gleich massenkonfiguriert zum sofortigen Einsatz bereitzustellen, finde ich von den Verantwortlichen hier auch fahrlässig. Zielgruppe sollten weniger Hobby-Administratoren sein, sondern die die Linux seit Jahren kennen.
Grüße
BrotherJ
Kann ich noch etwas tun, um den Server mehr abzusichern?
Ja, das könnest Du durchaus. Enable mal SELinux auf Deiner Maschine https://wiki.ubuntu.com/SELinux. Vor allem aber erst einmal definieren, wozu soll der Rootserver dienen? Gibt das einen Mail-/Exchange-Server, einen Webserver, einen Applicationsever, einen Datenbank-Server oder einen DNS-Server? Jede dieser Rollen implizit eine ganz eigene Absicherung. Eben weil unterschiedliche Services unterschiedlich zur Verfügung gestellt werden müssen.
[…] Enable mal SELinux auf Deiner Maschine https://wiki.ubuntu.com/SELinux […]
C-132 hat erwähnt, dass er Ubuntu 18.04 einsetzt – hier ist die Verwendung von AppArmor deutlich "gängiger" als SELinux. In Verbindung mit AppArmor oder einer generischer Einführung in "Härtungsansätze" ist unter anderem die Artikelreihe von Mike Kuketz empfehlenswert: