Verzeichnisschutz im www

[Thomas R.]

Guten Tag,

ich soll für einen Bekannten ein kleines WebFTP-script schreiben. Soweit kein Problem.
Dieses Verzeichnis soll mit dem Best Möglichen Passwortschutz ausgestattet werden, damit diese Dateien relativ sicher sind. So Sicher man halt Daten im Internet ablegen kann.
Er hat in diesem Kontext SSL bzw. HTTPS angesprochen. Auf welcher Art und Weise der Passwortschutz umgesetzt werden soll, ist ihm dabei egal. Ich dachte spontan an eine Sicherung per .htaccess. Ist dieses Verfahren dabei zu empfehlen?

[Felix Riesterer]

Lieber Thomas,

ich soll für einen Bekannten ein kleines WebFTP-script schreiben. Soweit kein Problem.

etwas in dieser Art? [Dateiverwaltung]

Dieses Verzeichnis soll mit dem Best Möglichen Passwortschutz ausgestattet werden

Bla, bla, bla! Wenn Dateien im Web sicher sein sollen, dann darf man sie nicht ins Netz stellen. Alles andere ist - Verzeichung! - relativ und deswegen unsicher.

So Sicher man halt Daten im Internet ablegen kann.

Du sagst es ja selbst.

Er hat in diesem Kontext SSL bzw. HTTPS angesprochen.

Das macht es auch nicht besser. Nimm .htaccess.

Ich dachte spontan an eine Sicherung per .htaccess. Ist dieses Verfahren dabei zu empfehlen?

Ja. Macht meine Dateiverwaltung auch.

Liebe Grüße,

Felix Riesterer.

[Tom]

Hello,

Bla, bla, bla! Wenn Dateien im Web sicher sein sollen, dann darf man sie nicht ins Netz stellen. Alles andere ist - Verzeichung! - relativ und deswegen unsicher.

Das kann ich so nicht nachvollziehen.
MMn ist eine ssl-Verbindung mit secure-ftp immer noch erheblicher sicherer, als eine klassische ftp-Verbindung.

Erstens wird die Verbindung verschlüsselt aufgebaut, also auch User und Passwort für die Anmeldung bereits verschlüsselt übertragen und zweitens werden auch die Daten verschlüsselt übertragen, sind also nicht von jedem Hans oder Franz oder Wolfgang unterwegs direkt mitlesbar.

Wenn man dann auch noch die Schlüssel per anderem Medium austauscht (also z.B. per Diskette [gibts überhaupt noch welche?]), dann sollte auch dieser Schritt vor Wolfgang, Franz & Co. verborgen bleiben können.

Bei Nutzung des klassischen ftp werden immer wieder Pakete ausgetauscht, die lesbare Zugangsdaten enthalten.

Also wäre eine Voraussetzung für eine mMn relativ sichere Filebasis dann mindestens https.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Sven Rautenberg]

Moin!

Bla, bla, bla! Wenn Dateien im Web sicher sein sollen, dann darf man sie nicht ins Netz stellen. Alles andere ist - Verzeichung! - relativ und deswegen unsicher.

Das kann ich so nicht nachvollziehen.
MMn ist eine ssl-Verbindung mit secure-ftp immer noch erheblicher sicherer, als eine klassische ftp-Verbindung.

Die Frage ist, was man hier miteinander vergleicht.

Mal konkret:

FTP übermittelt Daten und Passworte im Klartext - also ungeeignet.
HTTP übermittelt Daten im Klartext, die Passworte bei Basic-Authentifizierung ebenfalls - also ebenfalls ungeeignet.

HTTPS verschlüsselt die gesamte Datenübertragung, deshalb wird, obwohl innerhalb des SSL-Tunnels Klartext durchläuft, die Übertragung sicher.

Es gibt auch FTPS, das ist dasselbe wie HTTPS, nur mit FTP. Das ist aber so selten, dass man es kaum irgendwo findet. Für die Sicherheit gilt aber das bei HTTPS gesagte.

Weiter gibts SFTP. Das ist eine Dateiübertragung auf Basis von Secure Shell (SSH), dementsprechend auch verschlüsselt. Dasselbe in Grün ist SCP.

HTTP und FTP verbieten sich also sowieso.

FTPS ist ungebräuchlich, ich hab noch nicht gehört, dass es dafür Server gibt (soll heißen: Ich hab nicht gesucht, ob es die gibt, ich nehme es an, aber man findet sie nirgends aktiv in Anwendung), und Clients sind auch eher selten.

SFTP und SCP erfordern Shellzugriff, den man, wenn nur Dateitransfer erlaubt werden soll, erst wieder etwas aufwendiger einschränken muss.

HTTPS benötigt in irgendeiner Weise auf dem Webserver einen Mechanismus für Schreibzugriff. Nett ist für sowas die DAV-Erweiterung, wenn man einen passenden Client hat (was prima funktioniert, ist beispielsweise Subversion über HTTPS). Ohne sowas ist man drauf angewiesen, dass POST-Requests ausreichend große Dateien verarbeiten können, man ist aber dadurch eingeschränkt, dass man im Browser eine Verwaltungsoberfläche basteln muß - und das wird nie so komfortabel, wie es mit einem spezialisierten Client werden kann.

Bei Nutzung des klassischen ftp werden immer wieder Pakete ausgetauscht, die lesbare Zugangsdaten enthalten.

Also wäre eine Voraussetzung für eine mMn relativ sichere Filebasis dann mindestens https.

Alles ohne Verschlüsselung verbietet sich halt von selbst, wenn man in die Nähe von "sicher" kommen will.

- Sven Rautenberg

[suit]

Weiter gibts SFTP. Das ist eine Dateiübertragung auf Basis von Secure Shell (SSH), dementsprechend auch verschlüsselt. Dasselbe in Grün ist SCP.

nicht ganz - sftp ist eine etwas moderne variante von scp und kann ein bisschen mehr (in manchen fällen aber auch weniger) - eine gegenüberstellung gibts zb hier

[Tom]

Hello,

Weiter gibts SFTP. Das ist eine Dateiübertragung auf Basis von Secure Shell (SSH), dementsprechend auch verschlüsselt. Dasselbe in Grün ist SCP.
nicht ganz - sftp ist eine etwas moderne variante von scp und kann ein bisschen mehr (in manchen fällen aber auch weniger) - eine gegenüberstellung gibts zb hier

Ja, secure-FTP (also die FTP-Erweiterung im SSH-Protokoll) ist sicherer. Aber ich gebe Sven hier absolut Recht. Es ist ein riesiger Aufwand, seinen Server dafür fit zu machen. Du musst eine spezielle chroot-Umgebung dafür einrichten und hast dadurch keine einheitliche Userverwaltung mehr, da auch innerhalb der chroot-Umgebung etliche Dateien vorhanden sein müssen.

Kann sein, dass sich seit März schon wieder etwas neues ergeben hat in dieser Sache, aber da habe ich mich da durchgekämpft und diverse Lösungsmöglichkeiten getestet. Ich habe von fünf getesteten nur eine gefunden, die keine Löcher hatte, die ich als Halblaie finden konnte. Ok. ich kann auch beim Löchersuchen ziemlich penetrant werden, aber nur, weil ich keine mehr finde, ist das System noch lange nicht dicht.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Ja, secure-FTP (also die FTP-Erweiterung im SSH-Protokoll) ist sicherer. Aber ich gebe Sven hier absolut Recht. Es ist ein riesiger Aufwand, seinen Server dafür fit zu machen. Du musst eine spezielle chroot-Umgebung dafür einrichten und hast dadurch keine einheitliche Userverwaltung mehr, da auch innerhalb der chroot-Umgebung etliche Dateien vorhanden sein müssen.

nein, wie damals schon geschrieben ist chroot

1. kein Sicherheitsmerkmal

2. nicht notwendig.

mfg
Woodfighter

[Tom]

Hello,

nein, wie damals schon geschrieben ist chroot

1. kein Sicherheitsmerkmal

2. nicht notwendig.

Bitte um Entschuldigung. Das ist bei in der Versenkung verschwunden.
Könntest Du bitte mal einen Anker schmeißen oder eine Sicherheitsleine?

Ich habe secure-ftp bisher nicht zum Laufen gebracht, ohne dass sshd läuft auf dem Server.
Oder habe ich da jetzt 'was verkehrt verstanden und mir immer mehr Arbeit gemacht, als nötig?

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

nein, wie damals schon geschrieben ist chroot

1. kein Sicherheitsmerkmal

2. nicht notwendig.

Bitte um Entschuldigung. Das ist bei in der Versenkung verschwunden.
Könntest Du bitte mal einen Anker schmeißen oder eine Sicherheitsleine?

Ich habe secure-ftp bisher nicht zum Laufen gebracht, ohne dass sshd läuft auf dem Server.
Oder habe ich da jetzt 'was verkehrt verstanden und mir immer mehr Arbeit gemacht, als nötig?

ich habe keine Ahnung, was das mit meiner Aussage zu chroot zu tun haben soll. Sftp setzt per Definition ssh voraus.

mfg
Woodfighter

[Tom]

Hello,

Ich habe secure-ftp bisher nicht zum Laufen gebracht, ohne dass sshd läuft auf dem Server.
Oder habe ich da jetzt 'was verkehrt verstanden und mir immer mehr Arbeit gemacht, als nötig?

ich habe keine Ahnung, was das mit meiner Aussage zu chroot zu tun haben soll. Sftp setzt per Definition ssh voraus.

Ja, und mit ssh kannst Du Dich dann auf dem ganzen Server austoben.
Selbstverständlich gibt es da noch die normalen Zugriffsrechte, aber die im Griff zu behalten für "einfache SFTP-Nutzer", das erfordert für jeden einzelnen sehr viel Aufwand.

Da ist es dann doch einfacher, sie alle gemeinsam einzusperren und die Einschränkungen mittels Userrechten dort erst auszuüben.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Ja, und mit ssh kannst Du Dich dann auf dem ganzen Server austoben.

nur wenn ich entsprechnde Rechte habe.

Selbstverständlich gibt es da noch die normalen Zugriffsrechte, aber die im Griff zu behalten für "einfache SFTP-Nutzer", das erfordert für jeden einzelnen sehr viel Aufwand.

Wenn du da für jeden einzelnen etwas tun mußt, machst du definitiv etwas falsch.

Da ist es dann doch einfacher, sie alle gemeinsam einzusperren und die Einschränkungen mittels Userrechten dort erst auszuüben.

Dies ist per Chroot unter Linux nicht möglich ("chroot is not and never has been a security tool" - Quelle).

mfg
Woodfighter

[Tom]

Hello,

Ja, und mit ssh kannst Du Dich dann auf dem ganzen Server austoben.

nur wenn ich entsprechnde Rechte habe.

Di hast Du aber auf einem normalen Linux-Server, weil der offen wist für others.
Anderenfalls müssten sämtliche Rechte umgeändert werden vom gesamten Server.
Das ist nicht so unbedingt erstrebenswert.

Selbstverständlich gibt es da noch die normalen Zugriffsrechte, aber die im Griff zu behalten für "einfache SFTP-Nutzer", das erfordert für jeden einzelnen sehr viel Aufwand.

Wenn du da für jeden einzelnen etwas tun mußt, machst du definitiv etwas falsch.

Wieso? Was mache ich denn falsch? Oder vielmehr: wie muss ich es richtig machen, dass auf einem normalen Linux-Host ein SSH-User (der ja nur SFTP nutzen soll) nur Zugriff auf seine eigenen Directories behält und keinerlei Porgramme starten kann usw.

Da ist es dann doch einfacher, sie alle gemeinsam einzusperren und die Einschränkungen mittels Userrechten dort erst auszuüben.

Dies ist per Chroot unter Linux nicht möglich ("chroot is not and never has been a security tool" - Quelle).

Les ich mir durch.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Di hast Du aber auf einem normalen Linux-Server, weil der offen wist für others.
Anderenfalls müssten sämtliche Rechte umgeändert werden vom gesamten Server.
Das ist nicht so unbedingt erstrebenswert.

Du bis heute nicht damit rausgerückt bist, warum es ein Problem ist, dass die Nutzer des Servers Programme ausführen oder in Verzeichnisse schauen.

Selbstverständlich gibt es da noch die normalen Zugriffsrechte, aber die im Griff zu behalten für "einfache SFTP-Nutzer", das erfordert für jeden einzelnen sehr viel Aufwand.

Wenn du da für jeden einzelnen etwas tun mußt, machst du definitiv etwas falsch.

Wieso? Was mache ich denn falsch? Oder vielmehr: wie muss ich es richtig machen, dass auf einem normalen Linux-Host ein SSH-User (der ja nur SFTP nutzen soll) nur Zugriff auf seine eigenen Directories behält und keinerlei Porgramme starten kann usw.

Nimm ihm die Rechte auf alle anderen Verzeichnisse zuzugreifen, bzw. gib nur der Gruppe priviligierter Nutzer dieses Recht. Ein Sicherheitskonzept, dass darauf aufbaut, dass die User keine Programme ausführen können, ist allerdings fast sicher zum Scheitern verurteilt.

mfg
Woodfighter

[Tom]

Hello,

Nimm ihm die Rechte auf alle anderen Verzeichnisse

Das würde aber bedeuten, die Rechtestruktur des ganzen Servers ändern zu müssen.

Liebe Grüße aus Syburg bei Dortmund

Tom vom Berg

[Jens Holzkämper]

Tach,

Das würde aber bedeuten, die Rechtestruktur des ganzen Servers ändern zu müssen.

ja und? Du möchtest _extreme_ Einschränkungen umsetzen, das wird auch ein wenig Arbeit erfordern.

mfg
Woodfighter

[Sven Rautenberg]

Moin!

Du bis heute nicht damit rausgerückt bist, warum es ein Problem ist, dass die Nutzer des Servers Programme ausführen oder in Verzeichnisse schauen.

Wenn SFTP ein Ersatz für FTP sein soll, muß man erwarten können, dass sich mit SFTP ebenso einfach alle Einschränkungen realisieren lassen, die man bei FTP auch haben kann.

Dazu zählen:
1. Der Benutzer kann nur Dateien transferieren, keine Programme starten.
2. Der Benutzer kann nur in ein definiertes Verzeichnis und dessen Sub-Verzeichnisse gucken, nicht ganz / sehen.
3. Der Benutzer kann unter Umständen sogar nur in bestimmte Verzeichnisse uploaden, und aus allen anderen Verzeichnissen nur downloaden (zur Anlieferung von Dateien, die vom Betreiber erstmal geprüft werden, bevor sie herunterladbar werden).

Solange SFTP diese Features, die FTP seit Jahren auf einfache Weise bietet, nicht hat, ist es kein adäquater Ersatz, obwohl sowas wirklich nötig wäre.

- Sven Rautenberg

[Daniel Thoma]

Hallo Sven,

SFTP und SCP erfordern Shellzugriff, den man, wenn nur Dateitransfer erlaubt werden soll, erst wieder etwas aufwendiger einschränken muss.

So aufwending muss das wohl nicht sein. SFTP und SCP benötigen zwar eine Shell, aber nicht unbedingt eine, die irgend etwas anderes kann, als eben SFTP oder SCP.
Man kann wohl einfach den sftp-server als Shell für einen Benutzer eintragen. Alternativ dazu gibt es noch rssh. Eine Shell, die sich auf SFTP, SCP oder auch anderen Kram wie CVS einschränken lässt.

Damit kann ein Benutzer natürlich immer noch im gesamten System rumschnüffeln und so vielleicht Sicherheitslücken entdecken oder Dateien schreiben, wo rechte falsch gesetzt sind. Bei rsshkann man zwar auch ein chroot-Verzeichnis angeben, das muss man dann aber natürlich immer noch entsprechend einrichten.
Prinzipiell sollte es aber auch möglich sein, eine Shell zu schreiben, die dafür sorgt, dass der Benutzer in seinem Home-Verzeichnis bleibt.

Grüße

Daniel