SSH-Zugang Absichern und Härten

Normalen (nicht root) Benutzer anlegen

Bevor wir uns um das Absichern/Härten des SSH Zugangs kümmer können ist es wichtig einen regulären Benutzer auf dem System anzulegen. Dies erledigt man auf der Kommandozeile mit folgendem Befehl:

adduser fragmichnicht
Adding user `fragmichnicht' ...
Adding new group `fragmichnicht' (1002) ...
Adding new user `fragmichnicht' (1002) with group `fragmichnicht' ...
Creating home directory `/home/fragmichnicht' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for fragmichnicht
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y

SSH Schlüssel erzeugen und einbinden

Als nächsten Schritt legen wir uns einen private und einen public-key an um diesen für die Anmeldung via ssh verwenden zu können. Passwörter sind schon lange nicht mehr wirklich sicher und die Verwendung von solchen keys ist zudem deutlich praktischer als die Verwendung von vermeintlich sicheren Passwörtern. Die Schlüssel erstellen Sie entweder über die Linux Kommandozeile oder über das Windows tool Putty Key Generator.

Den Private-Key schützt man auf seinem lokalen System am besten weiterhin mit einem Passwort und speichert ihn an einem sicheren Ort. Der Schlüssel sollte nach Möglichkeit wirklich privat sein und nicht aus den Händen gegeben werden. Den Public-key zu veröffentlichen ist dagegen kein wirkliches Problem (wie der Name schon impliziert).

cd /home/fragmichnicht/
mkdir .ssh 
chmod 700 .ssh 
chown fragmichnicht:fragmichnicht .ssh 
cd .ssh
vi authorized_keys

Hier fügen wir nun den public key zu dem Schlüsselpaar welches wir gerade erstellt haben ein.
Danach fügen wir den neu angelegten Benutzer der Gruppe sudo hinzu damit dieser sich jederzeit via sudo root Rechte besorgen kann.

usermod -a -G sudo fragmichnicht

Sollte sudo noch nicht installiert sein so erledigt dies ein:

apt-get install sudo

Wenn ihr für die Benutzer der Gruppe sudo nicht wollt, dass diese ein Passwort eingeben müssen um sich root Rechte zu besorgen, dann erreicht man dies über folgende Zeile in der /etc/sudoers (Änderungen an dem file über visudo!)

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL) NOPASSWD: ALL

Härten der SSH-config

An sich sollte sich ein root-Benutzer nie direkt remote an einem System anmelden können und auf einem Server benötigt man auch keine grafische Oberfläche (X11). Ich poste nachfolgend meine sshd-config mit allen Werten (die geänderten fett gedruckt). Je nach System und Version müssen ggf. mehr Werte angepasst werden um zu dieser Konfiguration zu kommen. Die Änderungen an der Konfiguration müssen mit root-Rechten und folgendem Befehl durchgeführt werden:

vi /etc/ssh/sshd-config
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Damit die Einstellungen wirksam werden muss der SSH Dienst neu gestartet werden. Dies erreicht man mit dem Befehl:

/etc/init.d/ssh restart

Damit sind die Grundlagen für einen sicheren SSH-Zugang zu dem eigenen Server gelegt.

iptables – Debian Firewall Regeln für einen Webserver

In diesem Artikel werde ich erklären wie man die Firewall iptables auf einem Debian Linux einrichten um nur Zugriffe auf die erwarteten Dienste (HTTP, HTTPS und SSH) zu erlauben.

Firewall Grundlagen

Iptables bestimmt wie die meisten Firewalls ob ein Packet durch darf oder nicht indem es das eingerichtete Regelwerk von oben noch unten durchgeht. Sobald die erste Regel gefunden wird, die auf das Packet passt, wird diese Angewendet. Wenn unser Regelwerk also wie folgt aussehen würde, dann würden nur SSH Verbindungen zustande kommen und keine HTTP Verbindungen:

  1. Erlaube alle SSH Verbindungen
  2. Verbiete alle Verbindungen
  3. Erlaube HTTP Verbindungen

Es ist also wichtig auf die Reihenfolge der Regeln zu achten und am Schluss sollte immer eine Regel stehen “Verbiete alle Verbindungen” (Deny All).

 IPv4 vs IPv6

Die meisten Webserver sind heute sowohl über eine IPv4 wie auch eine neue IPv6 Adresse erreichbar. Die neue Protokollversion wird jedoch oft sträflich vernachlässigt obwohl diese auf den Systemen aktiv ist. Dies ist bei Firewalls im besonderen ein Problem. Wenn wir bei dem Beispiel oben bleiben und in der Standardkonfiguration von IPtables nun via IPv6 eine HTTP Verbindung öffnen würden, so würden wir bis zu dem Webserver kommen. Da IPv6 die Zukunft ist empfehle ich daher explizit nicht einfach alle solchen Verbindungen zu verbieten sondern die Regeln auch für dieses Protokoll einzurichten. Bei iptables ist dies besonders einfach, da die meisten Befehle in beiden Versionen funktionieren und das einzige was man ändern muss ist der Programmname (von iptables zu ip6tables). In meinem Beispielen führe ich daher jeweils beide Befehlssätze (IPv4 & IPv6) auf.

System Vorbereiten

Viel ist nicht nötig um mit der Konfiguration anfangen zu können. Wir müssen im wesentlichen nur ein Packet installieren (welches häufig schon vorhanden ist):

apt-get install iptables iptables-persistent

Filterregeln erstellen

Es gibt bei iptables im wesentlichen zwei Möglichkeiten Regeln zu erstellen. Man kann diese entweder in eine Datei schreiben und diese vom System automatisch laden lassen oder man schreibt die Regeln in den (flüchtigen) Speicher von iptables und lässt iptables am Ende das File schreiben. Ich bevorzuge und verwende hier letzteren Weg, da man hier bei einem Fehler das System nur neustarten muss um einen Weitere Versuch zu erhalten.

Derzeitiges Regelwerk anschauen

Um sich das aktuell vorhandene Regelwerk anzuschauen genügt ein einfacher Befehl. Im Auslieferungszustand sollte das Ergebnis wie folgt aussehen:

IPv4

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

IPv6

# ip6tables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Regel für SSH Zugang und den Loopback Verkehr einrichten

Die erste Regel sollte immer für den Loopback Verkehr und dann für den Remotezugang verwendet werden. So wird verhindert, dass man sich zu einem späteren Zeitpunkt durch eine falsche Regel aussperrt bzw das System zu viel Zeit verbraucht um z. B. Verbindungen zum lokalen Datenbankserver aufzubauen.

IPv4

# iptables -I INPUT -p tcp --dport 22 -j ACCEPT
# iptables -I INPUT -i lo -j ACCEPT

IPv6

# ip6tables -I INPUT -p tcp --dport 22 -j ACCEPT
# ip6tables -I INPUT -i lo -j ACCEPT

Alle nicht explizit erlaubten Verbindungen ignorieren

Nachdem die SSH Regel gesetzt wurde können wir iptables scharf schalten und in der base policy einstellen, dass nur explizit erlaubte Verbindungen an unseren Server heran kommen dürfen.

IPv4

# iptables -P INPUT DROP

IPv6

# ip6tables -P INPUT DROP

Regeln für den Webserver anhängen

Für unseren Webserver erlauben wir nun noch HTTP und HTTPS Verbindungen auf den Ports 80 und 443:

IPv4

# iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# iptables -A INPUT -p tcp --dport 443 -j ACCEPT

IPv6

# ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT
# ip6tables -A INPUT -p tcp --dport 443 -j ACCEPT

# iptables -L -n
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Im Gegensatz zu dem Befehl den wir zum Anlegen der SSH Regel verwendet haben, haben wir hier den Parameter –I durch den Parameter –A ersetzt. Dies bewirkt, dass die Regel an das Regelwerk angehängt (append) wird.

Etablierte Verbindungen zulassen

Mit dem bestehenden Regelwerk würde der Webserver und der SSH Server wie erwartet funktionieren. Allerdings würdet Ihr vermutlich recht schnell über Fehlermeldungen z. B. von apt fallen, da hier verschiedene Verbindungen nicht durch gehen würden. Es ist daher ratsam noch folgende Regel hinzuzufügen:

IPv4

# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

IPv6

# ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# ip6tables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Filterregeln permanent speichern

Alle Regeln die wir bis jetzt eingerichtet haben wären nach einer Reboot wieder weg. Um diese zu speichern ist ein kurzer Befehl notwendig:

# iptables-save > /etc/iptables/rules.v4
# ip6tables-save > /etc/iptables/rules.v6

Nach einem Reboot werden die Regeln nun automatisch wieder gelesen und geladen. Zur Sicherheit sollte man das System neustarten und prüfen ob dies auch der Fall ist.

Alles in einem Script für Schreibfaule

Um das setzen der Regeln zu vereinfachen habe ich alle Befehle in eine bash Datei geworfen. Ihr müsste diese also nur auf euer System herunter laden, die Datei ausführbar machen (chmod +x [name]) und danach ausführen. Den Schritt um die Regeln zu persistieren habe ich nicht mit aufgenommen um Fehlern vorzubeugen.

Datei herunterladen

Synology mit aktueller Firmware hat Schlafprobleme und geht nicht in den Ruhezustand

Hi,

seit dem Update meiner Synology auf die Firmware DSM 5.2-5565 Update 1 habe ich festgestellt, dass diese nicht mehr in den Ruhezustand geht. Das erweiterte Logging hat dies nach einigen Tagen bestätigt – selbst wenn alle angeschlossenen Geräte offline sind, findet die Box nicht in den Schlaf. Ich habe daher ein Ticket bei Synology eröffnet und nun die Bestätigung bekommen, dass es sich dabei um einen Bug handelt an dem die Entwicklungsabteilung arbeitet und bald einen Fix zur Verfügung stellen wird.

Babybay an (Softside-) Wasserbett befestigen

Ich stand die Tage vor der Aufgabenstellung ein Babybay an ein vorhandenes Softside Wasserbett montieren zu müssen. Der Hersteller sieht grundsätzlich nur eine Montage an einem regulären Bettrahmen durch einhängen eines L-Winkels vor. Bei der Suche nach einer geeigneten Lösung im Internet bin ich dabei über diverse z. T. recht komplexe Lösungen gestolpert die für mich alle samt nicht in Frage kommen. Ich habe mich daher selbst in den Denkteich begeben und bin mit folgender recht einfachen Lösung nun sehr zufrieden.

Benötigtes Material:

  • Montagekleber
  • Dachlatte ca. 1,5 m bis 2 m (maximal jedoch Länge des Wasserbetts)

Montageschritte:montage_babybay_thumb-7948507

1. Eine Seite der Dachlatte mit Montagekleber bestreichen (nicht sparen und bei schnell trocknendem Kleber nicht zu langsam arbeiten!)

2. Die Dachlatte an der Unterkante der Auflagefläche der Wassermatratze befestigen (möglichst bündig mit der Außenkante da die L-Winkel des Babybay nicht sehr lang sind).

3. Entweder die Dachlatte entsprechend der Beschreibung des Klebers für eine gewisse Zeit fest andrücken (dafür sollte man zu zweit sein) oder das ganze durch eine kleine Unterkonstruktion fixieren. Abhängig vom Kleber dauert dieser Vorgang zwischen ein paar Minuten bis zu ein paar Stunden. Hier lohnt sich also das lesen der Beschreibung vor dem Kauf.

babybay_an_wasserbett_02_thumb-12524204. Sobald der Kleber ausgehärtet ist kann die Unterkonstruktion entfernt werden und die eigentliche Montage beginnen. Hierzu schiebt man das Babybay an die zukünftige Position und montiert die L Winke – um diese mit unserer  Konstruktion verbinden zu können muss das kurze Ende des L-Winkels nach oben zeigen und damit hinter die frisch montierte Dachlatte greifen (siehe Abbildung). Damit sollte das Bett fest mit dem Wasserbett verbunden sein.

Die Konstruktion ist zwar mit Sicherheit nicht perfekt (sonst hätte Sie der Hersteller bestimmt aufgeführt) aber bis jetzt hatte ich damit keine Probleme. Die Konstruktion verhindert bei uns bis jetzt auch zuverlässig das weg Rutschen oder Umkippen und ist auf jeden Fall besser als ein frei stehendes BabyBay.

Umstellung von IPv4 auf IPv6 in wenigen Schritten unabhängig vom verwendeten Router

In vielen Foren und Beiträgen im Internet wird darüber diskutiert ob es für Privathaushalte oder Firmen sinnvoll ist, auf IPv6 umzustellen. Die Antwort auf diese Frage ist leider nicht wirklich leicht zu treffen zumal man sich hierfür mit vielen trockenen Netzwerkartikeln herumschlagen muss. Hat man die Entscheidung dann irgendwann getroffen und will tatsächlich auf IPv6 umstellen, so legen einem die gängigen Foren / Berater etc. nahe dafür teure externe Experten einzukaufen. Ich für meinen Teil kann sagen, dass das total überflüssig ist. Meine Umstellung hat nur weniger Sekunden gedauert und ich bin mir sicher, dass jeder dies mit ein wenig Vorbereitung auch hin bekommt.

Hier das kurze Video mit den durchgeführten Schritten: