Verzeichnisschutz mit php(BB)

[DanielHeinrich]

Hi!

auch wenn der Titel dieses Threads eventuell verwirrend klingt - mir ist leider kein besserer eingefallen - will ich hier das 'Problem' , einige Lösungsansätze vorstellen und anschließend mit anderen an dieser Problematig interessierten Leuten darüber und über Alternativen diskutieren:

Das Problem:

Es existiert ein Verzeichnis(inklusive Unterverzeichnisse ) auf einem Apache-Webserver welches mehr oder weniger große Dateien(bis zu mehreren GiB) enthält.
Der Zugang zu diesen Inhalten sollte allerdings nicht 'plump' sondern vielmehr (im Extremfall) für jeden User, jede Gruppe und jede Datei/jeden Ordner einzeln definierbar sein.
(ich hoffe ich habe das so einigermaßen gut ausgedrückt - wenn nicht einfach nachfragen, ich erkläre dann nochmal was ich meine)

Des weiteren sollen natürlich die Dateien über den Webserver und _nicht_ über einen anderen Dienst verteilt werden (auch wenn FTP hier offensichtlich das bessere Protokoll wäre).


Einige Lösungsansätze:

Generell: Die Verzeichnisnavigation soll weiterhin (aus optischen Gründen) per php und im phpBB erfolgen.

1) Zugangskontrolle via .htaccess:
Eine alte aber bewährte Methode. Per php könnte man die Gruppen bzw. Userfiles auf dem neusten Stand und mit phpBB synchronisiert halten.

Die Rechtevergabe könnte hier über die <Files>- bzw. <Directory>- Direktiven erfolgen.

2) Zugangskontrolle via php und rewrite-Engine:
Klingt verrückt, funktioniert aber:
Generell klickt der User hier nicht direkt die Dateien an sondern erst einmal nur eine php-Datei welche die ID der zu öffnende Datei / des zu öffnenden Ordners enthält, beispielsweise
http://www.example.com/ddl.php?id=4711

Diese php-Datei prüft nun ob der entsprechende User zu dieser Aktion berechtigt ist(die kann man im gegensatz zur .htaccess-Kontrolle dann z.B. noch vom Zeitpunkt oder anderen Dingen abhängig machen...)
Sollte diese Prüfung zu Gunsten des Users ausfallen erstellt nun die php-Datei eine Token-Datei in einem nicht per http zugänglichen Ordner wobei der Name dieser Datei einer (nur als Beispiel) 20-stelligen Zufallszahl entspricht(z.B. 12345678901234567890).

Anschließend wird der User zur eigentlichen Datei weitergeleitet, wobei die entsprechende URL um die gerade genutzte Zufallszahl erweitert wurde(z.B. http://www.example.com/ddl/somedir/eine ... 1234567890).
Hier prüft nun die Rewrite-Engine ob der für die Datei benötigte Token vorhanden ist. Sollte dies nicht der Fall sein wird der User zu einer Fehlerseite weitergeleitet.

Mit solchen Token ist es ausserdem möglich relativ einfach zu überprüfen ob die IP des Users derjenigen entspricht von der die Datei angefordert wurde.

Theoretisch müsste sich dann 'nur' noch ein Cron-Job bzw. die cron.php-Datei um das regelmäßie aufräumen der Token kümmern...

3) Zugangskontrolle via php und Symlinks...
Wie in 2) nur dass hier statt den Token bei einem positiven Resultat nach der Berechtigungsprüfung ein Symlink zur gewünschten Datei erstellt und man anschließend zu diesem Symlink weitergeleitet wird - wobei diese nicht direkt sondern nur über solche Links erreichbar ist.
Diese Symlinks sollten natürlich so wie die Token bei 2) Zufallsgeneriert sein damit ein erraten selbiger fast unmöglich wird.

Mit solchen Symlinks ist es ausserdem möglich relativ einfach zu überprüfen ob die IP des Users derjenigen entspricht von der die Datei angefordert wurde wenn man hier noch die Rewrite-Engine hinzuzieht.

Auch hier müsste wie bei 2) ein Cron-Job bzw. cron.php dafür sorgen dass diese Links regelmäßig aufgeräumt werden...

4) Zugang und download via php...
Man kann allerdings auch - nachdem die Rechteüberprüfung für den User positiv verlaufen ist den Passenden Content-Type senden und anschleßend die vom User angeforderte Datei z.B. per readfile-Funktion auszugeben. Diese Methode würde es zusätzlich erlauben, relativ einfach eine maximale Download-Durschnittsgeschwindigkeit festzulegen.


Die Frage:

Was haltet ihr von den einzelnen Ideen. Wo seht ihr Vor- und wo Nachteile? Welche Methode würdet ihr bevorzugen? Habt ihr andere Ideen wie sich so etwas realisieren lässt?

Auch wenn ich mir schon zu jedem dieser Punkte eigene Gedanken gemacht habe möchte ich diese erst einmal für mich behalten um keinen in seiner Meinung / seinen Ideen zu beeinflussen - auf jeden Fall bin ich schon gespannt was bei dieser Diskussion herauskommt


bis bald

Daniel Heinrich

PS: Wie gesagt: sollte ich irgendetwas schlecht erklärt haben - sagt es einfach - ich erkläre es gerne noch einmal

[Pyramide]

1) ist zumindest bei phpBB3 nicht so einfach möglich, da dieses eine eigene Hash-Funktion nutzt.

Bei 4) läuft auf Serverseite der PHP-Interpreter während des gesamten Downloads mit und auf Clientseite ist z.B. das Fortsetzen von Downloads nicht möglich (außer man baut die entsprechenden Befehle im PHP-Script nach).

2) und 3) sind von der Funktion recht ähnlich - Nachteile kann ich spontan nicht erkennen.

[gn#36]

Ich sehe das ähnlich wie Pyramide.

Punkt 4 würde ich als den ungünstigsten sehen da man hier u.U. zusätzlich zu der unnötigen Serverlast die die Ausführung des Skriptes verursacht anstelle einfach nur eine Datei zur Verügung zu stellen auch noch u.U. an die Skriptlaufzeitgrenze stoßen könnte wonach der Download dann abbricht.

Sofern möglich hat der Symbolische Link natürlich den Vorteil, dass keine Dateien auf dem Server durch die Gegend kopiert werden müssen, trotzdem bleibt die Verwendung relativ einfach serverseitig (grob nicht viel mehr als symlink($quelle, $ziel); header("Redirect: $ziel"); ), dagegen ist die Geschichte mit dem Token schon erheblich aufwändiger (Apache muss die Tokens prüfen, ggf. die richtige Datei darstellen, ...).

Punkt 1 ist wie Pyramide schon gesagt hat schwierig mit den phpBB Userdaten zu realisieren, da es sich um keine reine md5 Verschlüsselung mehr handelt.

[DanielHeinrich]

Hi!

Zu Punkt 1 und 4 muss ich euch definitv Recht geben -
4) ist sehe ich aufgrund der erhöhten Rechenlast als schlechteste der 4 Möglichkeiten an, und
1) lohnt sich auch nur dann wenn man sämtliche Accounterstellungen bzw. Löschungen und Passwortänderungen von Anfang an mitverfolgt - spricht es wäre relativ ungeeignet für ein schon laufendes Forum (mal ganz davon abgesehen dass man wirklich aufpassen muss damit keine Inkonsistenzen entstehen)

Ein weiterer Nachteil den ich bei 1) sehe ist dass es eventuell komisch für den User wäre wenn er obwohl er sich schon gegenüber von phpBB authentifiziert hat nocheinmal zur Passworteingabe aufgefordert wird.

zu 2 und 3:
3) hat den Vorteil dass es relativ unkompliziert ist, allerdings auch den Nachteil dass jedes Dateisystem dass keine Symlinks erlaubt aussen vor bleibt - diesen Nachteil hätte
2) nicht, hier wäre allerdings das Gegenargument dass diese Methode im Vergleich zu 3) mehr Arbeit für den Server bedeutet - wenn auch signifikant weniger als 1) oder 4)


bis bald

Daniel Heinrich