Server absichern

[Eric]

Da es doch den ein oder anderen hier gibt, der sich einen Root-Server gemietet hat oder es vielleicht vor hat, habe ich im Wiki mit Unterstützung von mibere einen Eintrag zur Absicherung von einem Root-Server erstellt.
Da ich nur Ubuntu 14.04 auf dem Server laufen habe beziehen sich die Angaben in erster Linie darauf. Vermutlich lassen sie sich ebenso unter Debian anwenden.

So genug der Rede. Hier geht es zu dem Wiki-Eintrag: clickclack

Inhalt:
1 Einleitung
2 Erste Maßnahmen
2.1 Kennwort ändern
2.2 SSH Port ändern
2.3 Das System aktualisieren
2.4 Neuen Benutzer anlegen
2.5 Zugang für root bei SSH verbieten
2.6 SSH über Keyfile
2.6.1 Key erstellen unter Ubuntu
2.6.2 Key erstellen unter Windows
2.6.3 Public key auf Server übertragen
2.6.3.1 Linux
2.6.3.2 Windows
2.6.4 Schotten dicht!
3 Weitere bzw. optionale Maßnamen
3.1 SSH mit fail2ban absichern

Bis Kapitel 3 sind alle Kapitel aus meiner Sicht erst einmal fertig. Wenn es von Euch Anregungen, Kritik, Vorschläge usw. gibt, als her damit oder selbst im Wiki aktiv werden.

[mibere]

Tolle Arbeit, Eric


Eine Anmerkung:

Die beiden Zeilen

chown admin .ssh
chgrp users .ssh

kann man ersetzen durch

chown admin:users .ssh

[Stiwi]

thx werd mir das am wochenende mal anschauen und ein bisschen rumprobieren

[mibere]

Bei Fragen oder Problemen kannst du dich an Eric oder mich wenden. Eric hat sich gut in das Thema eingelesen und die wichtigsten Punkte ausführlich beschrieben.

Wie schon mal geschrieben, vielleicht ganz gut, wenn man es zuerst an einer lokalen, virtuellen Maschine probiert.

[Eric]

Danke mibere. Klar kann man mich da auch jederzeit fragen.
Es gibt eigentlich zwei kritische Stellen, bei den man sich eventuell aussperren kann, wenn man nicht aufpasst. Die kann man aber ganz am Schluß machen, sofern man sowieso alles in einem Rutsch macht.
Ich würde folgende Reihenfolge - mit einer persönlichen Einschätzung in Klammern - empfehlen:

• Kennwort und SSH-Port ändern (unkritisch, solange man nicht den Port und das Kennwort vergisst. Ansonsten gibt es 2^16 = 65tausendkrumme Ports zum probieren)

• System aktualisieren (unkritisch)

• Neuen Benutzer anlegen (unkritisch)

• SSH über Keyfile bis zu dem Punkt: Schotten dicht (bis dahin unkritisch, weil man sich immer noch mit root anmelden kann)

Bis hierhin kann man sich nicht aussperren. Umso wichtiger ist, dass man den Anmeldevorgang über Keyfile gut testet und auch sicher stellt, dass man über diesen User (nach Anmeldung) auch zu root wechseln kann. Ist das getestet, kann man jetzt das System quasi abschließen.
Vergesst dabei nicht euch eine SSH-Verbindung offen zu halten und mit einer neuen SSH-Verbindung zu testen. Die erste SSH-Verbindung ist quasi der Rettungsanker falls was schiefgeht. Dann könnt ihr darüber immer noch die Änderungen des nachfolgenden Schrittes zurück nehmen.
Erst wenn ihr die letzten Änderungen gut getestet habt und die Anmeldung mit keyfile funktioniert, könnt ihr die Verbindungen schließen.

• Zugang für root verbieten und das Kapietel Schotten dicht (hier besteht die Gefahr sich auszusperren! Also konzentriert arbeiten und gut testen!)

[Dj Ninja]

Server absichern

Ich würde ja sagen, 16 Ampere reichen locker.

[Eric]

Nehme ich gleich mit der Namensnennung von Dir in das Wiki auf.

Edit: Zitat eingearbeitet.

[mibere]

Bzgl. Fail2ban und DenyHosts:

Yves-Alexis Perez aus dem Debian-Sicherheitsteam rät den Nutzern des Tools auf Alternativen wie fail2ban umzusteigen, da DenyHosts schon seit 2008 nicht mehr aktiv gewartet wird.

Quelle: http://www.heise.de/security/meldung/An ... 71933.html

On top of that, we really advise anyone still using denyhosts to switch
to a more maintained solution. fail2ban apparently does the same job. I
can't judge the code quality, but at least someone is taking care of it.

Quelle: http://seclists.org/oss-sec/2013/q4/536

=> Fail2ban scheint die bessere Wahl zu sein.

[mibere]

Wer im Internet mit einer festen IP unterwegs ist oder einen SSH-Server im lokalen Netz weiter absichern will, kann dies sehr leicht tun...

Als root die Datei /etc/hosts.deny und /etc/hosts.allow bearbeiten:

Code: Alles auswählen

nano /etc/hosts.deny

Die Datei um

Code: Alles auswählen

sshd: ALL

erweitern, um den Zugriff auf den Daemon sshd grundsätzlich zu verbieten.

Die Ausnahmen werden in der /etc/hosts.allow definiert:

Code: Alles auswählen

nano /etc/hosts.allow

Den Zugriff auf den SSH-Server auf eine feste eingehende IP beschränken:

Code: Alles auswählen

sshd: 100.101.200.202

oder den Zugriff auf Rechner, die aus dem lokalen Netzwerk kommen, beschränken - den Punkt (.) am Ende beachten:

Code: Alles auswählen

sshd: 192.168.

Diese Zeile sollte man zusätzlich zur hosts.allow hinzufügen - den Punkt (.) am Ende beachten:

Code: Alles auswählen

sshd: 127.0.0.

Die Datei /etc/hosts.allow könnte bspw. so ausschauen:

Code: Alles auswählen

sshd: 127.0.0.
sshd: 192.168.
sshd: 147.32.70.41

[Eric]

Super Sache. Für diejenigen mit dynamischen IP könnte ein Script per cronjob deren aktuelle IP von einem dyndns abfragen und in die hosts.allow eintragen.

[mibere]

Fail2ban hat man ebenfalls schnell eingerichtet.

Als root...

Code: Alles auswählen

apt-get update
apt-get install fail2ban

Die Konfigurationsdatei von Fail2ban ist die /etc/fail2ban/jail.conf. Darin finden wir oben den Hinweis

# To avoid merges during upgrades DO NOT MODIFY THIS FILE
# and rather provide your changes in /etc/fail2ban/jail.local

Also von der jail.conf in /etc/fail2ban/ eine Kopie als jail.local erstellen.

Die Datei /etc/fail2ban/jail.local bei Bedarf oder Notwendigkeit anpassen.
In den Standardeinstellungen wird SSH (und nur SSH) bereits überwacht. Ich habe an der Datei keinerlei Änderungen vorgenommen, die Standardeinstellungen sind für mich ok.

Nach einer Änderung der Konfiguration den Daemon neu starten

Code: Alles auswählen

/etc/init.d/fail2ban restart

Fertig.

Die Logdatei ist die /var/log/fail2ban.log

Mit

Code: Alles auswählen

fail2ban-client status ssh

bekommt man eine Statistik für's Jail ssh angezeigt.

Mit

Code: Alles auswählen

fail2ban-client status

eine Übersicht über die aktivierten Jails.

[mibere]

Was ziemlich cool ist...

https://www.digitalocean.com/community/ ... entication
http://www.howtogeek.com/121650/how-to- ... ntication/