Secure ssh/rss

tsk

Member
Hallo zusammen,

ich bemühe mich derzeit, einen neuen vServer - noch nicht produktiv - aber dennoch seit dem Einschalten gefährdet, so gut es geht und ohne es zu übertreiben, abzusichern. Der Server läuft unter Ubuntu 8.0.4/Plesk 9.5.4.
Mir ist bewusst, dass es nicht allein um den sicheren Shellzugang geht, sondern ebenso um eine Absicherung des Apache, Mail, MySQL etc. Bevor ich mich dem nächsten Kapitel widme, möchte ich das aktuelle wirklich verstanden haben. Deshalb dieser Post, mit Bitte um Kritik von allen Wissenden. Thema „Sicherer Zugang“.

Ich habe dabei verinnerlicht:

You MUST use a password safe like keepass, like „5R;%Y*ZNmei;3J`Ol2OF „
NEVER use the same password twice

Ich habe also folgende Schritte unternommen:

1)Strong root Password (für sudo und Virtuozzo/VZPP)
2)Neuen User angelegt, für sudo Aktivitäten
(Hard to guess username, strong password, strong passphrase)
3)RSS Key rss2/4096 mit passphrase erzeugt und für diesen User aktiviert.
4)Root Login abgeschaltet, restart ssh, User klappt. Sudo klappt.
5)Separater Plesk/Domain/FTP user hat sein Home directory unter /var/www/vhosts/mydomain.tld,
deshalb hier ein .ssh/authorized_keys (eigener Key für diesen Account) – klappt
6)PasswordAuthentication = no (Jeglicher Zutritt nur noch mit Fahrkarte)
7)Tests mit putty und Filezilla für beide user ok, root Login scheitert, wie gewünscht.
8)Alle Plesk Funktionen getestet - ok

Irgend was muss falsch sein, denn es hat alles auf Anhieb geklappt. Deshalb meine Fragen...

a) Ist das Getane prinzipiell ok?

b) zu 5) etwas Bauchschmerzen durch Ablage von .ssh im FTP-User Root. Hat zwar restriktive Rechte (Dir 700, File 600), aber gibt es vielleicht einen geeigneteren Ablageort?

c) Ich nutze (derzeit) noch den Standardport. Ist es ein MUSS, diesen zu verlegen? Falls ja – und ich habe im Plesk den Firewall noch nicht aktiviert – müsste ich dies tun, um weiterhin an meinen Server zu kommen (Port-Forwarding)? Und wichtiger noch, käme Plesk noch dran?

d)Wäre die Aktivierung des Firewalls generell zu empfehlen? Ich scheue etwas die Last und mein Server-Anbieter empfiehlt es nicht ausdrücklich, bzw. schreibt „ist oft überflüssig“. Die Inhalte der gehosteten Domains alleine würden keinen Einbruch rechtfertigen, i.d.R. Unternehmenswebsites

e) Dann bliebe noch die Frage, ob nicht auch der Plesk Standardport 8443 verlegt werden sollte. Ich greife zwar ausschließlich über https darauf zu, aber alles, was irgendwie gängig ist, bereitet mir immer Sorgen.

f) Was kann ich an dieser Stelle, in vernünftigen Kategorien gedacht, noch tun, um ein Mehr an Sicherheit zu erlangen?

Bin dankbar für alle Kritik und Anregungen,

Thomas
 
Zu 6. schauen, dass auch ChallengeReponseAuthentication = no eingestellt ist, da sonst Passwort-Auth trotzdem noch funktioniert.

Sonst gilt generell: Sicherheit ist kein Zustand sondern ein Prozess. Also immer (Sicherheits)-Updates einspielen, eigene User für VHosts/Domains, Rechtevergabe nach "least Privilege"-Prinzip. Alles, was mit Passwörtern zu tun hat immer über SSL-Verbindungen laufen lassen (Admin-Panel, webmail u.s.w.).
Und bei jedem neuen Dienst als erstes dran denken, wie man den missbrauchen könnte um schlechtes zu tun. Wenn man das im Hinterkopf hat, dann achtet man automatisch auf Fallen. Nach dem Motto: "Ich weiß ich bin paranoid. Aber bin ich paranoid genug?"
 
Den SSH-Port würde ich persönlich (wenn es geht) immer verlegen, um das Grundrauschen in den Logs zu minimieren. Nichts nervt mehr, als sich erstmal durch 1.000.000 Zeilen Müll zu wühlen, u. U. übersieht man etwas schneller.

Die Firewall (nicht der) ist meiner Meinung nach nicht notwendig. Die Dienste als solche sollten dafür sauber konfiguriert sein.

Fail2ban ist noch eine nette Geschichte, um über bestimmte Vorgänge auf dem Laufenden gehalten zu werden.

Brauchst Du Plesk für die User oder arbeitest Du alleine auf dem Server?
 
Die Firewall (nicht der)
Ich sage ab dann _die_ Firewall, wenn alle anderen anfangen, nicht mehr _die_ URL zu sagen. (Ja, schau mal nach gängigen Übersetzungen für "locator" - alle maskulin...)

Bei Verwendung von SSH mit Keys und Verbot des Logins mit Passwörtern finde ich SSH auf alternativem Port nicht sinnvoll. Da man Logs nicht zeilenweise durchgeht (wer hier liest täglich oder wenigstens wöchentlich seine Logs?) sondern z.B. mit Logwatch eine Zusammenfassung erstellen lässt, kann man bei diesem Prozess auch gleich dieses "Grundrauschen" zu einer einzigen Zeile zusammenschrumpfen lassen oder gänzlich ignorieren.

Den Firewall wiederum finde ich persönlich sinnvoll. Sicher kann er eine ordentliche Grundconfig nicht ersetzen, bei der nicht benötigte Dienste abgestellt sind.
Aber ein Firewall kann verhindern, dass ein eingeschleustes Script Portlistener startet um so z.B. Backdoors zu öffnen. Und man kann leicht kontrollieren, ob ein Dienst wirklich nur von intern erreichbar ist. Oder nur von einer bestimmten IP(-Range) aus.
 
Cool - danke für die Tipps.

"ChallengeReponseAuthentication = no" hatte ich schon. Hatte es nur nicht erwähnt. Hinsichtlich "UsePAM = no" habe ich noch Bedenken. Ist es nicht so, dass "ChallengeReponseAuthentication = no" und "PasswordAuthentication no" die Oberklassen bildet? Anmelden mittels Password ist mir mit aktuellen Einstellungen definitiv nicht mehr möglich - und UsePAM steht noch auf yes. Und unter /etc/pam.d steht eine Menge, inkl. Plesk spezifischer Dinge.

Die Portverlegung hatte ich nur wegen Plesk bisher nicht vorgenommen (ich weiß bei Plesk nie, durch welche Aktion man sich irgend einen Zugang verbaut) - werde es aber jetzt mal testen, während ich eine Shell mit altem Port offen halte - und vorher einen Backup fahre.

Plesk nutze ich (auf diesem Server) nur für mich - möchte aber gerade das Verhalten mit Kunden üben. Deshalb wäre die Antwort: ich nutze es als Reseller bzw. will dies tun.

Fail2ban steht schon auf meiner Liste - kommt als nächster Schritt.

Ich danke Euch allen für die Unterstützung,

Thomas

p.s. <klugscheiss_on>Der Firewall vs Die Firewall: Das Geschlecht eines Anglizismus, für den es - außer bei SIEMENS - keinen eigenen deutschen Begriff gibt, wird wahlfrei unter der Grammatik einer wörtlichen Übersetzung (der Brandschutzwall - oder die Brandschutzmauer) bedient. Müsste also beides grammatikalisch statthaft sein</klugscheiss_off>

p.p.s. Und sowas von mir, als praktizierendem Halbholländer :-)
 
/etc/ssh/sshd_config said:
# If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no

So wie ich das verstehe, setzt man UsePAM auf yes, um die PAM-Accounts nutzen zu können und ChallengeResponseAuthentication no, damit die Authentifizierung aber über SSHd-Mechanismen läuft - also z.B. RSA/DSA-Auth.

Bei meinen CentOS-Systemen steht UsePAM per default auf on und ChallengeResponseAuthentication per default auf no.
PAM hat ebenfalls per Default eine eigene Config für SSHd-spezifische Logins.

Daher denke ich mal, dass diese Kombi ok und so vorgesehen ist.
 
Googelt man danach, bekommt man die Krise. 1000de Blogeinträge, zig Widersprüche, kein grüner Faden - aber: Mit "ChallengeReponseAuthentication = no" und "PasswordAuthentication no" soll "UsePAM" auch bei on keine unangenehmen Nebenwirkungen haben. Ich habe es erst mal "on" gelassen, und bislang keine Möglichkeit gefunden, mich noch per PW anzumelden.
 
Meiner Meinung nach ist UsePAM notwendig, um die PAM-Account-Checks/-Module nutzen zu können. Also z.B. LDAP-/Kerberos-Accounts (pam_ldap, pam_krb5), pam_limits, pam_access u.s.w.

Ich sage, du kannst das an lassen und evtl. ist es sogar schädlich, es abzustellen.
 
Back
Top