Neues in der Kategorie FTP

Vor einiger Zeit gab es hier im Undertec-Blog eine Aufstellung zu Möglichkeiten, wie man SSH/SFTP-Zugänge im CHROOT-Gefängnis einsperren kann (siehe dazu http://www.undertec.de/blog/2008/05/sshsftp-im-chrootgefangnis-ein.html).

Heute kommt dazu eine Schritt-für-Schritt-Anleitung wie man mit der eingebauten ChrootDirectory-Option in OpenSSH direkt ein CHROOT-Gefängnis kreieren kann und wie man dies ausnutzen kann um einen sicheren SFTP-Server aufzusetzen, so dass der Benutzer aus dieser Ordnerstruktur nicht ausbrechen kann.

Zuerst müssen wir eine neue Gruppe und einen oder mehrere neue Benutzer anlegen, welche nachher Zugang zu unserem SFTP-Server bekommen sollen. Wie wir später sehen werden, wird diese Gruppe später direkt in den SSH-Servereinstellungen verwendet.

addgroup sftpzugang
useradd -s /bin/false -G sftpzugang sftpbenutzer
passwd sftpbenutzer

Wir legen mit den ersten beiden Befehlen also die Gruppe "sftpzugang" und den Benutzer "sftpbenutzer" in der Gruppe "sftpzugang" an. Mit "-s /bin/false" wird angegeben, dass der Benutzer keine Login-Shell zur Verfügung gestellt bekommt. Mit dem dritten Befehl passwd vergeben wir ein Passwort an den neu geschaffenen Benutzer.

Als nächstes ändern wir die Konfiguration unseres SSH-Servers. In "/etc/ssh/sshd_config" wird nun folgendes geändert:

Zuerst kommentieren wir folgende Zeile mit # aus:

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

Dann fügen wir am Ende der "sshd_config" folgende Zeilen ein:

Subsystem sftp internal-sftp
 
Match Group sftpzugang
        ChrootDirectory /home/SFTP-WURZELVERZEICHNIS
        ForceCommand internal-sftp
        AllowTcpForwarding no

Mit diesen Befehlen sorgen wir dafür, dass der SSH-Server bei einer SFTP-Authentifizierung automatisch auf den internen SFTP-Server umschaltet und dass jeder Benutzer der Gruppe "sftpzugang" in das Verzeichnis "/home/SFTP-WURZELVERZEICHNIS" eingesperrt wird. Gleichzeitig verbieten wir TCP-Forwarding.

Im Prinzip können wir nun den SSH-Server neu starten, sobald wir das "SFTP-WURZELVERZEICHNIS" angelegt haben. Dieses Verzeichnis muss allerdings über spezielle Nutzerrechte verfügen, welche man noch vergeben muss (wie das geht und weitere Infos dazu findet man bei http://madapez.com/it/linux/howto-chroot-sftp-zugang-openssh-ohne-shell-ssh/).

Unter Debian geht das Neustarten des SSH-Servers wie folgt:

/etc/init.d/ssh restart

Wer seinen SSH-Server nun jetzt noch etwas sicherer machen möchte, der sollte zurück in die "sshd_config" gehen. Dort kann man entweder neben Port 22 einen weitere Port eintragen oder einen anderen Port wählen.
Da viele Angreifer wissen, dass Port 22 der SSH-Port ist, ist es ratsam einen Port zu wählen, der weit außerhalb der üblichen Portscanner-Bereiche liegt.

Deshalb kommentieren wir Port 22 aus und wählen einen neuen Port. Das ganze sieht dann wie folgt aus:

# Port 22
Port 54321

Dieser Port wird im Normalfall nicht von Portscannern standardmäßig geprüft.

Als nächste können wir noch verhindern, dass "root" sich von nicht berechtigten Rechnern anmeldet:

AllowUsers BENUTZER root@192.168.1.*

Mit dieser Anweisung kann sich der "BENUTZER" von jedem Rechner mit jeder IP-Adresse aus anmelden. Der "root"-Benutzer kann sich hingegen nur noch mit IP-Adressen aus dem 192.168.1.*-Netz anmelden. Dies schafft zusätzliche Sicherheit, da root sich zwar anmelden darf, aber nicht von überall.

Natürlich muss jetzt erneut der SSH-Server gestartet werden.

Weitere Informationen zu dieser Anleitung und großteile dieser Anleitung findet sich bei:
http://madapez.com/it/linux/howto-chroot-sftp-zugang-openssh-ohne-shell-ssh/

Hier noch ein Artikel zu Wikipedia, der generell erklärt, was CHROOT ist:
http://de.wikipedia.org/wiki/Chroot

Wie man mit ALLOW und DENY den SSH-Server sicherer machen kann, findet sich hier:
http://blog.christianjaeckle.de/2008/01/ssh-mit-allowusers-und-allowgroups-einschraenken/
http://www.cyberciti.biz/tips/openssh-deny-or-restrict-access-to-users-and-groups.html
http://ubuntuforums.org/showthread.php?t=1416730

Wie man den SSH-Server an mehreren Ports betreibt, findet sich hier:
http://www.latenightpc.com/blog/archives/2006/10/11/running-an-ssh-server-on-multiple-ports

Eine andere Möglichkeit eine chroot-Umgebung herzustellen findet sich hier:
http://slackworld.berlios.de/2007/chroot_howto.html

Wie man * Wildcards in SSH benutzt findet sich hier:
http://www.cmdln.org/2008/12/17/ssh-config-wildcards/

Wie Subsysteme in SSH funktionieren findet sich hier:
http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch05_07.htm

Um einen sicheren SSH- oder SFTP-Zugang zu einem Server herzustellen, lohnt es sich manchmal den verbindenden Benutzer in eine sogenannte CHROOT-Umgebung einzusperren. Hierfür gibt es eine Vielzahl von Möglichkeiten, die im folgenden einmal aufgelistet sind. Vor allem in Hinsicht als sichere FTP-Alternative sollte man sich überlegen, ob man nicht eine der untenstehenden Möglichkeit in Betracht zieht.

1. ChrootDirectory-Option ab OpenSSH-Version 4.8p1

Ab dieser Version gibt es eine Option "ChrootDirectory" die es einem erlaubt, den Benutzer sauber in seinem chroot-Verzeichnis einzusperren. Allerdings muss man beachten, dass unterhalb dieses Verzeichnisses alle benötigten Dateien für den User vorhanden sein müssen. Also einige Binaries aus "bin", ein paar Devices aus "dev", etc.

Hierzu auch die Man-Page von OpenSSH:
http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config
Changelog zu OpenSSH 4.8:
http://www.openssh.com/txt/release-4.8
Und noch eine Anleitung wie man das Ganze unter Debian umsetzt:
http://www.debian-administration.org/articles/590
Und hier nochmal eine Kurzanleitung:
http://openbsd.maroufi.net/sshchroot.shtml

2. Frühere OpenSSH-Versionen und Patch-Möglichkeiten

Für frühere OpenSSH-Versionen hatte man die Möglichkeit spezielle gepatchte SSH-Server zu verwenden, so dass ein chroot möglich war. Funktioniert hat dieser Patch ab Version 3.1p1. (siehe auch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=139047 und die Debian-Anleitung G.1.2 in http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.de.html). Letztendlich sollte man aber lieber Variante 1 nehmen und sich das neueste Release des OpenSSH-Servers besorgen, auch wenn er momentan noch nicht in Debian Etch als Stable enthalten ist. Die Problematik, dass man eine saubere CHROOT-Umgebung schaffen muss, ist hier natürlich wie bei Variante 1 gegeben.

Projektseite des nun veralteten gepatchten OpenSSH-Servers:
http://chrootssh.sourceforge.net/index.php
Eine Reihe von Anleitungen zu dem gepatchten SSH-Server:
http://hp.kairaven.de/scpsftp/ssh-rssh-sftp.html#a3
http://howtoforge.com/chroot_ssh_sftp_debian_etch
http://www.howtoforge.com/chrooted_ssh_howto_debian

3. libpam-chroot benutzen

Wer versuchen will ein chroot per libpam-chroot durchzuführen, sollte sich unter G.1.1 in folgender Anleitung einmal umsehen: http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.de.html

4. Das Projekt MySecureShell

Eine andere alternative ist das Projekt "MySecureShell". Hauptsächliche Verwendung findet dieses Programm als SFTP-Server der leicht zu konfigurieren und einzustellen ist. Unter Debian ist dies tatsächlich sehr leicht und es lässt sich auch recht einfach eine Chroot-Umgebung realisieren, wie man es von einem FTP-Server kennt.

Projektseite von MySecureShell:
http://mysecureshell.sourceforge.net/ (Vorsicht die Deutsche Seite wurde sehr schlecht übersetzt)
Und hier noch eine Anleitung für Debian Etch:
http://www.cplinux.de/debian-chrooted-sftp-server.view.html (Deutsch)
Eine andere Anleitung für Debian Etch:
http://howtoforge.com/mysecureshell_sftp_debian_etch (Englisch)

5. Den SSH-Server in ein CHROOT-Gefängnis sperren

Wenn man natürlich den ganzen SSH-Daemon in ein Chroot-Gefängnis sperrt, dann hat man noch ganz andere Möglichkeiten. Beschrieben wird das Ganze unter G.2 in folgender Anleitung:
http://www.debian.org/doc/manuals/securing-debian-howto/ap-chroot-ssh-env.de.html

Appendix

Eine Seite mit nützlichen Infos zum Erstellen eine sauberen chroot-Umgebung findet man hier:
http://wiki.ubuntuusers.de/chroot?highlight=%28chroot%29
Natürlich kann man gerne auch "makejail" für manche Möglichkeiten verwenden:
http://www.floc.net/makejail/

Wer unter Linux (oder Windows) auf die Kommandozeile angewiesen ist, der wird feststellen, dass der normale FTP-Client keine Möglichkeit besitzt, ganze Verzeichnisse oder Verzeichnisbäume hoch- oder runterzuladen. Eine Abhilfe kann hier das Programm "wput" bieten, mit dem man ganze Verzeichnisse hochladen kann.

Unter Debian installiert man das wie folgt:

apt-get install wput

Wer nun ein Verzeichnisbaum hochladen möchte, kann folgenden Befehl benutzen:

wput * ftp://BENUTZER:PASSWORT@192.168.1.1/public/

(Dieser Befehl schiebt alle Dateien und Unterverzeichnisse des aktuellen Verzeichnisse auf den FTP-Server mit der IP "192.168.1.1" und dort in das Unterverzeichnis "public".)

Eine paar kleine Eigenheiten sollte man bei wput allerdings beachten:

1. Für jede Datei die hochgeladen wird, öffnet und schließt wput eine URL-Verbindung. Das bedeutet im Klartext, dass wput langsamer als ein normale SAMBA-Verbindung werden kann.

2. Gibt man zum hochkopieren einen absoluten Pfad an, wie zum Beispiel "/home/ich/, so versucht wput, den führenden Slash mit dem gesamten Pfad ebenfalls auf dem FTP-Server zu erzeugen. Dies führt zu Fehlern, die wput aber teilweise ignoriert.
Die Frage ist, warum ist das so?
Nunja, vom Prinzip her wird nämlich immer eine Datei generiert in die wput schreibt. In diesem Fall muss ein Unterverzeichnis mit den darin liegenden Dateien also erst erzeugt werden. Aufschluß über diese Funktionsweise gibt auch die Dokumentation, die das URL-Konzept erklärt. Umgehen kann man das Problem mit dem Parameter "--basename", welcher den Pfad wegschneidet.

Eine Windows-Version des Programmes wput findet man auf der Projektseite bei sourceforge:
http://wput.sourceforge.net/

Ebenso die Dokumentation:
http://wput.sourceforge.net/wput.1.html

Weiter Beschreibung und Dokumentation auf Linux-fuer-Blinde.de:
http://www.linux-fuer-blinde.de/88-0-ftp-client-wput.html

Wer analog dazu Verzeichnisse herunterladen möchte, der sollte sich mit dem Prorgamm "wget" beschäftigen:
http://de.wikipedia.org/wiki/Wget

Eine interessante, wenn leider auch nicht sehr ausführliche Tabelle mit einem Vergleich der Geschwindigkeiten zwischen FTP und SAMBA findet man auf der Seite http://lug.krems.cc/docu/samba/appb_01.html. (Diese Seite ist ein Auszug aus dem Appendix B des Buches "Using Samba", welches im O'Reilly Verlag erschienen ist.)

Dort kann man deutlich sehen, dass man SAMBA erstmal tunen muss, bevor es mit der Geschwindigkeit von FTP mithalten kann. Somit ist FTP der eindeutige Sieger in der Frage um die Schnelligkeit zwischen den beiden Datenübertragungsdiensten.

Das FTP-Protokoll (File Transfer Protocol) ist eines der ältesten Internetprotokolle die es gibt (Die RFC hierfür ist aus dem Jahre 1985). Mit einem einfachen Satz an Befehlen, lassen sich Dateien herunterladen oder aber auch hochladen.

Wie FTP funktioniert findet man sehr schön beim ELKO (Elektronikkompendium):
http://www.elektronik-kompendium.de/sites/net/0902241.htm

Eine Übersicht der Befehle findet man hier:
http://www.moritzschubel.de/pc_ftp.html (kurze und vollständige Übersicht)
http://www.nsftools.com/tips/RawFTP.htm
http://www.linuxer.onlinehome.de/apps/ftp.htm

Die Original RFC befindet sich hier:
http://tools.ietf.org/html/rfc959

Über dieses Archiv

Diese Seite enthält aktuelle Einträge der Kategorie FTP.

ERP ist die vorherige Kategorie.

Google ist die nächste Kategorie.

Aktuelle Einträge finden Sie auf der Startseite, alle Einträge in den Archiven.

Juli 2013

So Mo Di Mi Do Fr Sa
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
Etter EDV- und IT-Dienstleistungen
Powered by Movable Type 5.04

Google Werbung:

Google Werbung: