dckg.net
Blog
Tools
Downloads
Dienstag, 31 Januar 2017 in Linux, Sicherheit
Eingeschränkte User - Portforward und Chroot
Was Portforwarding bedeutet, sollte einem klar sein, ansonsten geht es hier weiter:
SSH Portforwarding: DynDNS Alternative - dckg.net

SFTP Benutzer - Datentausch

Zuerst ein chrooted User - Möchte man z.B. jemandem eine Dateiuploadmöglichkeit geben, bietet sich der eingebaute SFTP Server im SSH Daemon hervorragend an. Unter Windows könnte man hierzu das Programm FileZilla nutzen.

In der sshd_config

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    PermitTunnel no
    X11Forwarding no

groupadd sftponly, sshd neu laden.

Anschließend kann ein User in der sftponly Gruppe angelegt werden.

useradd -m --system --shell /bin/false --gid sftponly test

Das Homeverzeichnis (/home/test) und alles darunter sieht so aus (stat):

Access: (0750/drwxr-x---)  Uid: (    0/    root)   Gid: ( 1000/sftponly)

Falsche Berechtigungen können einem richtig Zeit kosten. Ein Login ist dann nicht möglich.

Uploadverzeichnis:

Access: (0770/drwxrwx---)  Uid: (  999/    test)   Gid: ( 1000/sftponly)

Befehle:

# Allgemein
chown -R root:sftponly /home/$user
chmod -R u+rwX,go+rX,go-w,o-rX /home/$user

# für Uploadverzeichnis
mkdir /home/$user/upload
chmod 770 /home/$user/upload
chown ${user}:sftponly /home/$user/upload

Damit hat der User aktuell nur Leserechte, möchte man Upload erlauben, kann im Homeverzeichnis ein Unterordner erstellt werden, welcher dem User gehört.

Es gibt keine Shell für den User. Bei Login wird false zurückgegeben. Portforwarden kann er auch nicht.
Mit diesem SFTP User könnte problemlos SSHFS genutzt werden, also das Einbinden des Serververzeichnisses unter einer anderen Maschine. SSHFS ist im Userspace, man benötigt keine Root-Rechte dafür.

sshfs test@host.tld:/ /home/myuser/mountpoint -o reconnect,ServerAliveInterval=15,ServerAliveCountMax=3 -o idmap=user -o uid=$(id -u) -o gid=$(id -g)

Von "richtigen" chrooted Shells (z.B. bash) halte ich nichts, Fork Bomb und dergleichen könnten immernoch das System abschießen, zudem könnte der User Schadcode nachladen.

Portforward Nutzer

Portweiterleitungen wird man früher oder später brauchen, es ist sinnvoll, TcpForwarding erst einmal auf no zu stellen.
Braucht nun ein User Portforwards, hier sshtunnel, so kann er per default alles machen -

  • remote portforward bind auf localhost (GatewayPorts no default)
  • local portforward alles
  • dynamic portforward (proxy)

Auch hier gilt es, die Shell auf /bin/false zu setzen.

AllowTcpForwarding no
#
#
# ...
#
Match User sshtunnel
    AllowTcpForwarding yes
Match User root
    AllowTcpForwarding yes
Match User vmtunnel
    AllowTcpForwarding yes
    PermitOpen localhost:1080
    PermitOpen localhost:3306
    PermitOpen localhost:22
Match User sshtunnel2
    AllowTcpForwarding yes
    PermitOpen 192.168.2.123:1080 192.168.2.123:8080

Die Proxy Funktionalität von SSH bietet selbstredend ein großes Missbrauchspotential, der User muss ja nichts böses im Schilde führen, Keys können wie echte Schlüssel auch verloren gehen.
Grundsätzlich gibt man einem User nicht root, stattdessen ausschließlich die minimal notwendigen Rechte.
PermitOpen unterbindet nur die Proxy Option (ssh -D), limitiert gewiss auch die lokalen Portfowards, einzig remote Forwarding ist weiterhin möglich - wenn auch nur ein bind auf einen freien Port auf localhost auf dem Server.
In Verbindung mit einem lokalen Portforward ist eine DOS Attacke möglich, Endlosschleife die alle File Descriptors oder ähnliches aufbraucht, die genaue Quelle hab' ich leider nicht mehr.

tl;dr
Man gibt nicht vertrauenswürdigen Personen keine Zugang zu irgendwas. Layer 8 ist das größte Sicherheitsrisiko.

Test, dass ein PermitOpen User keinen SSH Proxy öffnen kann:

root@client ~ # ssh server.tld -D 1337 -l sshtunnel -N
channel 2: open failed: administratively prohibited: open failed
root@client ~ # curl -I --socks5 localhost:1337 example.com
Failed to receive SOCKS5 connect request ack.

Am Ende bitte nicht vergessen, dass der in SSH eingebaute SOCKS-Server nur TCP unterstützt. UDP tunneln wird umständlich. FIFO.
Als vollwertigen SOCKS-Server kann ich Dante empfehlen: OpenVPN selektiv #3: SOCKS - dckg.net

Siehe auch:
security - How to create a restricted SSH user for port forwarding? - Ask Ubuntu

Update 18.02.2017
SFTP Benutzer Berechtigungen korrigiert, sowie Code-Snippet und SSHFS hinzugefügt.

Site optimised for Google Chrome / Chromium