Mailinglisten-Archive |
Hallo, > ich habe hier schwierigkeiten mit dem Session Management. Einer unserer > Kunden kann unsere Software nicht nutzen, weil er hinter einem Proxy mit Load Balancing > sitzt. Dadurch kommt jeder Request scheinbar von einer anderen IP-Adresse. Ich habe hier drei > verschiedene Programmpakete, die zur Session ID zusätzlich die Request IP checken. Oha, wer macht sowas denn noch? :-> > Wenn die IP nicht zur Session passt, wird sie verworfen und der Kunde muss sich neu > anmelden. Er kommt also über den Anmeldebildschirm nicht hinaus, da der nächste Request wieder > von einer anderen IP kommt... Verständlich und ein bekanntes Problem. Auch Clients an Telekom- DSL-Anschlüsse kommen gern mal öfters mit einer neuen IP auf den Server. > Jetzt zwei Fragen: > * ist das gängige Praxis mit dem IP-Check, oder hab ich grad nur Pech > mit unserer Software? IP-gebundene Sessions sind ... nun ja, wie soll ich sagen ... ziemlicher Unsinn. Die Client-IP ist eine Variable, keine Konstante. Wir haben solche Probleme schon bei Cluster-Management Systemen erlebt, wo uns der Hersteller auf die Frage, wie der Cluster Clients einem bestimmten Webserver eindeutig zuordnen können, sagte: Na ganz einfach: über die IP des Client. Als wir denen die Nachteile dieser Mickey-Mouse-Lösung (entschuldige den Ausdruck) erläutert haben, war Schweigen im Walde. Eine Möglichkeit ist das, was mod_backhand zum Beispiel macht: die Hexwerte der IP, also AA.BB.CC.DD werden als 8 Character an die Sessionid (32 Chars) angehängt. Dadurch kommt eine Sessionid von 40 Zeichen zu Stande, die die IP des zuständigen Servers enthält. Wo auch immer Client Requests aufschlagen, werden sie zuerst auf Länge untersucht: - 32 Chars? Ok, ab jetzt ist der Server zuständig, wo der Request gerade ist. IP kodiert und angehängt. - 40 Chars? Wie lautet die darin enthaltene IP? Weiterleitung an den zuständigen Server. Bei Server-Clustern ist das Mitschleppen der IP in irgendeiner Form notwendig (solange man kein zentrales Session-Repository z.B. in einer DB oder auf einem FibreChannel System hat). Warum man bei Clients die IP prüft ist mir schleierhaft. > * was kann man tun um die Sicherheit nicht zu reduzieren und ihm > trotzdem Zugang zu gewähren? Wieso erhöht das Mitziehen der IP die Sicherheit? Wenn sich im realen Leben hinter einer IP mehrere Rechner verbergen können, hat man nichts gewonnen. Und diese Geschichte mit Round-Robin-Proxies ist ein seit langem bekanntes Phänomen ... > PS: SSL möchte ich ungern nutzen, da kein Geld für Zerifikatkauf da ist. > (Universität eben...) Es gibt mittlerweile diese GeoTrust Schnellzertifikate oder so ähnlich. Das kostet <150 Euro. Vielleicht ist das drin? Andererseits: ist es nun ein Kunde oder ein Institut? :-> Wenn tatsächlich ein Institut sollen die mal im ReZe nachfragen, ob die ihnen nicht ein Zertifikat (für lau oder zu Sonderkonditionen) besorgen können ... Eine andere Frage ist, ob die Applikation wirklich so herzhafte Sicherheitsaspekte rechtfertigt, aber das kann ja nur der Anwender entscheiden. Klar ist ja auch, daß bei einem Man-in-the-middle-Angriff auch das Auslesen der IP nix hilft. Weil der böse Pursche liest die Packages mit. Die sind Klartext und auch da steht die IP incl. Sessionid dann drin. Wen er dann da rein möchte ist das kein Problem mehr. Wirklich helfen kann tatsächlich nur eine Verschlüsselung der gesamten Verbindung. Viele Grüße, Volker Göbbels -- Dr. Volker Göbbels vmg at arachnion.de Arachnion GmbH & Co. KG http://www.arachnion.de Sandkaulbach 4 Tel. ++49 (0) 241 5591106 52062 Aachen Fax ++49 (0) 241 5591107
php::bar PHP Wiki - Listenarchive