rheingauner
Goto Top

Monowall Captive Portal Problem https

Der Zugriff über WLAN auf die https-Portalseite von Monowall funktioniert nur, wenn in den Browsereinstellungen der Proxyserver deaktiviert ist. Im Internt surfen kann man aber nur mit aktivierten Proxyservereinstellungen!

Hallo,

kurz zu meiner Situation:
Ich bin Lehrer und administriere nebenbei unser Windowsnetz. Ich plane ein WLAN mit Internetzugang zu Unterrichtszwecken einzuführen.
Das WLAN soll unverschlüsselt funken und über Monowall die Benutzerauthentifizierung laufen. Das hat den Vorteil, dass die Schüler eigene Laptops im Unterricht benutzen können und die Schule kann die hohen Hardwarebeschaffungskosten etwas senken und in andere Bereiche investieren. Idealerweise sollte die Benutzerauthentifizierung verschlüsselt sein und der "normale" Internettraffic kann unverschlüsselt bleiben.

Zuhause habe ich das Szenario mit Monowall so auch schon umgesetzt und es hat funktioniert. Aber nun habe ich bei der Implementierung in der Schule unvorhergesehene Probleme. Der Zugriff über WLAN auf die https-Portalseite von Monowall funktioniert nur, wenn in den Browsereinstellungen der Proxyserver deaktiviert ist. Im Internt surfen kann man aber nur mit aktivierten Proxyservereinstellungen! Das ist ziemlich umständlich und mittlerweile kann ich durch die vielen "Verschlimmbesserungen" schon gar keine verschlüsselter https-Portalseite mehr aufrufen! Das unverschlüsselte Portal funktioniert anstandslos. Auch die Clients im LAN können über die Monowall ins Internet geroutet werden. Allerdings läuft auf der LAN-Schnittstelle kein DCHP sondern DCHP kommt über unserern Windows 2003 DC.


Ich beschreibe mal das nähere Umfeld und im Anschluss die Einstellungen in Monowall:

Standleitung für Internet:
Router ins Stadtnetz 10.0.52.1 / 24
Proxy für Internetzugang: 192.168.10.10:80
DNS für Internet: 192.168.10.10


Einstellungen Monowall:

WAN 10.0.52.10 / 24 (von Netzbetreiber bekommen)

WLAN 192.168.4.1 /24 (nur auf der Schnittstelle läuft DHCP)

DNS (in gereral Setup) 192.168.10.10
192.168.4.1


Ich vermute mal einen Fehler in DNS Umfeld? Die Clients bekommen über DHCP eine korrekte IP-Adresse zugeordnet und wenn ich den DNS-Forwarder deaktivier auch die beiden DNS einträge mit dem Gateway 192.168.4.1 zugeornet!

Was ist denn hier nur falsch?

Vielen Dank im Voraus
A.

Content-Key: 175283

Url: https://administrator.de/contentid/175283

Ausgedruckt am: 29.03.2024 um 14:03 Uhr

Mitglied: aqui
aqui 26.10.2011 um 08:50:31 Uhr
Goto Top
Dieser Umstand ist ein generelles Problem von Captive Portals bzw. Hotspots also nicht ein Monowall oder pfSense spezifisches.
Der Grund ist einfach: Das Triggern der Portalseite zum Login wird durch TCP 80 Traffic also HTTP ausgelöst. Anderer Traffic kann die Portalseite nicht triggern.
Du ahnst was passiert wenn man einen Proxy aktiviert hat der NICHT transparent ist:
Der Proxy Port ist meist TCP 8080, 8081 oder 3128. Pakete mit diesen TCP Ports triggern aber nun das Portal nicht mehr. Es gibt bei einfachen Captive Portals so nicht die Möglichkeit den Triggerport umzuschalten. Und wenn auch, was wäre damit gewonnen ? Dann kann anderer Traffic wiederum nichts mehr aktivieren.
Es bleibt also ein Dilemma in diesem Umfeld.
Es gibt aber einen ganz einfachen Weg daraus indem du sinnvollerweise ein transparenten Proxy installierst. Dann taucht dieses Problem gar nicht mehr auf. Proxys wie der allseits bekannte Squid und andere lassen sich so konfigurieren. Das hat zudem den Vorteil das Benutzer niemals mehr an den Browsersettings fummeln müssen für den Proxybetrieb, deshalb nutzt man heutzutage vermehrt transparente Proxys.
PfSense kann zudem auch noch einen automatischen Redirect dieses Traffics auf den Proxy sofern man einen Proxy nutzt der keinen Transparent Modus supportet.
Mit DNS wie von dir vermutet hat das also gar nichts zu tun. Den Forwarder zu deaktivieren ist auch unklug, denn die Monowall arbeitet als DNS Proxy und reduziert so den Traffic auf die angegebenen DNS Server. Wie gesagt...das ist aber nicht dein Problem !
Mitglied: rheingauner
rheingauner 26.10.2011 um 10:30:35 Uhr
Goto Top
Hallo,

ich fasse dann mal in meinen Worten zusammen. Bitte korrigier mich, wenn ich falsch liege.

Also wenn ich das richtig verstehe, dann wird die unverschlüsselte Loginseite auf dem Port 80 (auch bei nicht transparentem Proxy) getriggert aber die verschlüsselte https-Seite wegen anderem Port nicht?!

Also wäre jetzt mein Lösungsansatz einen transparenten Proxy (z.B. Squid)in unserem Netzwerk zu installieren und den gesamten Traffic darüber laufen zu lassen und Monowall greift auf den transparenten Squid zu. Dass dann die Browsersettings entfallen, wäre wirklich ein Gewinn für die Usability.

Den Forwareder hatte ich deaktiviert, weil ich sonst nicht sehen konnte, ob Monowall die richtigen DNS an die Clients vergibt. Werde ich aber wieder umschalten.

Habe ich das richtig verstanden, dass PFSense auch mit nicht transparenten Proxys arbeitet und auch das meine Lösung sein könnte ohne einen weiteren Proxy? Ich habe nämlich mal versucht PfSense zu installieren aber leider lies sich mein Barebone damit nicht mehr booten. Aber dann beschaffe ich halt ein anderes Gerät.

Vielen Dank für die Infos
A.
Mitglied: dog
dog 26.10.2011 um 21:43:52 Uhr
Goto Top
Das WLAN soll unverschlüsselt funken und über Monowall die Benutzerauthentifizierung laufen.

Das ist ein absolutes No-Go!
Spätestens nach 2 Wochen hat irgendein Schüler alle Passwörter von Lehrern und Mitschülern abgeschnüffelt.
Sowas wird auch kaum mit den Datenschutzvorgaben der Länder vereinbar sein.
Mitglied: rheingauner
rheingauner 26.10.2011 um 22:47:19 Uhr
Goto Top
Hallo,

deshalb ja auch die verschlüsselte Portalseite. Benutzername + Passwort oder Voucher werden verschlüsselt übertragen.

VG
A.
Mitglied: dog
dog 26.10.2011 um 23:11:30 Uhr
Goto Top
Und?

Das hilft dir rein gar nichts.
Jeder mit auch nur einem kleinen Fitzelchen Fachwissen kann sich die Daten trozdem erschleichen.
In einem unverschlüsselten WLAN kann ich alles machen!

Captive Portal Login umgehen ist noch die leichteste Übung.
Die meisten Daten kann man direkt ohne Verbindung zum WLAN abschnüffeln (Datenschutz!) - die Hardware dafür kostet 10-15€
Und ein MITM-Angriff um weitere Daten abzuhören (dazu gehört auch HTTPS!) oder zu manipulieren ist ähnlich trivial.
Mitglied: aqui
aqui 27.10.2011, aktualisiert am 18.10.2012 um 18:48:55 Uhr
Goto Top
Noch eine Korrektur zum obigen Verhalten, da du es nicht ganz verstanden hast:

Die Portalseite wird immer von TCP 80 getriggert ! Also sowie das CP TCP 80 Traffic "sieht" von einem nicht authorisierten Nutzer sendet sie die Portalseite aus.
Im Setup bestimmst du nun ob diese Seite unverschlüsselt oder verschlüsselt vom CP an den User kommt.
Die Grundproblematik ist aber wenn du im Browser einen festen proxy definiert hast gibst du ja auch einen proxy Port an ! Der Browser sendet also gar nicht erst TCP 80 Traffic sondern TCP <ProxyPort> Traffic. Der wiederum triggert aber nicht die Portalseite im CP.
Das Problem ist also NICHT ob das CP die Portalseite verschlüsselt sendet oder nicht sondern da sie durch die festen Proxy Port Einstellungen gar nicht erst kommt, denn ein Proxy Browser erzeugt keinen TCP 80 (HTTP) Traffic mehr !!
DAS also ist dein Problem und nix anderes !
Wie gesagt...umgehe das mit einem transparenten Proxy und alle deine Probleme sind gelöst ! Ob der mit auf dem CP liegt oder extern spielt dabei keinerlei Rolle.
Kollege dog hat natürlich Recht was die Sicherheit anbetrifft bei einer unverschlüsselten Portalseite Man könnte das aber etwas abfedern indem du ausschliesslich nur Voucher Authorisierungen zulässt und die Vouchernutzung im CP Setup nur auf einen einzelnen User limitierst also sog. "concurrent logins" verbietest.
Das sorgt erstmal dafür das kein Schindluder mit der Weitergabe von Vouchers gemacht werden kann. Wenn aber einer dieser Nutzer Internetbanking über diese Verbindung macht oder Emails liest hat der ein Problem da die Verbindung selber nicht verschlüsselt ist und so alles mitgelesen werden kann.
Auf der anderen Seite wenn du einen Preshared WPA Key einsetzt und das WLAN generell verschlüsselst ist so ein statischer Key bei den Schülern ebenso in Windeseile rum und man hat rein gar nichts gewonnen.
Da hilft dann nur ein Zertifikats basierter Zugriff mit 802.1x
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Verkompliziert die Sache aber natürlich wieder und schafft erheblich mehr Verwaltungsoverhead...ist aber zweifelsohne sicherer.
Du musst da also einen Gratwanderung machen. Hängt auch davon ab was die Schüler wirklich machen in dem Netz und welche Sicherheits Relevanz das überhaupt hat ! Wenn sie nur ein bischen bei KiKa.de oder buntekuh.de surfen ist es vermutlich herzlich egal ob du verschlüsselst oder nicht...
Mitglied: aqui
aqui 28.10.2011, aktualisiert am 18.10.2012 um 18:48:56 Uhr
Goto Top
Achso...nochwas.....
Du kannst natürlich die Voucher Abfrage in der pfSense über eine HTTPS Seite machen.
Dazu führst du folgende Schritte aus:
  • In Systems --> Cert Manager ein eigenes Zertifikat für das CP Portal erzeugen (Achtung: Vorher eine CA anlegen !) Beispiel siehe #comment-toc7 HIER
  • Achtung: Für den Common Name VOR Zertifikatsgenerierung die pfSense IP Adresse vom CP Port verwenden wenn du den DNS Namen NICHT auflösen kannst sonst einen Domainnamen den du auf die Interface IP der pfSense auflösen kannst im DNS !!
  • Mit den beiden Pfeiltasten am Ende des Zertifikats, Zertifikat und Key in Datei exportieren und sichern.
  • In die Service --> Captive Portal auf die CP Konfig Seite gehen
  • Unten den Haken bei Use HTTPS aktivieren
  • In die Felder Certificate und intermediate Certificate das Zertifikat cut and pasten. Das ist einen normale ASCII Text Datei die mit dem Editor, Notepad, oder Wordpad geöffnet werden kann.
  • In das Feld "Key" den Inhalt der Key Datei cut and pasten. Auch das ist eine normale ASCII Text Datei die mit dem Editor, Notepad, oder Wordpad geöffnet werden kann.
  • Mit save sichern
Bringt aber nicht viel, da die WLAN Seite ja immer noch offen ist....

Wenns das denn war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen !
Mitglied: rheingauner
rheingauner 28.10.2011 um 18:43:02 Uhr
Goto Top
Hallo,

erstmal vielen Dank für die informativen und konstruktiven Vorschläge und Einwände.

Zum Thema Sicherheit kann ich nur sagen, dass es sich nur um einen reinen Zugang zum WWW handelt.
Die Schüler (Berufsschule mit Schwerpunkt Wirtschaft und Verwaltung) sollen eigene Notebooks mitbringen und das Internet NUR als Recherchequelle nutzen. Das WLAN soll vom restlichen Netz getrennt sein (evlt. schicke ich später dazu nochmals die Firewalleinstellungen). Der Proxyserver liegt im Stadtnetz und wird mit Firewall und Contentfilter abgesichert. Die Sache mit der Verschlüsslung des WLAN-Verkehrs ist natürlich auch überdacht worden.
Um es sicherer zu machen, müssten wir die Verbindung verschlüsseln und geheim halten. Also müssten wir die Laptops selbst einrichten. Damit würden wir uns allerdings die Chance nehmen, auf die Anschaffung von Laptopwagen zu verzichten! Ein gescheiter Laptopwagen kostet ca. 15.000 Euro und müsste durch Lehrer aufwändig administriert werden. Da kommen sehr schnell mal 90.000 Euro zusammen. Deshalb kam die Überlegung mit der https-Verschlüsslung der Anmeldedaten, trozt der Gefahr, dass der Netzverkehr mitgelesen werden kann. Allerdings sollten da sowieso nur Wikiartikel mitlesbar sein! Die Anmeldedaten sollen halt idealerweise nicht mitlesbar sein, da ich angedacht habe, den Lehrern personalisierte Logins zu vergeben und die Logins nicht verfallen sollen. Findet ihr das fahrlässig? Ist ja auch eine rechtliche Frage.

Ich habe jetzt mal einen Rechner organisiert und pfSense installiert und habe das Paket Squid nachgeladen. Er lauscht auf der WLAN-Schnittstelle. Gibt es da noch was zu beachten?

VG
A.
Mitglied: aqui
aqui 28.10.2011, aktualisiert am 18.10.2012 um 18:48:56 Uhr
Goto Top
Da gibt es eine erheblich bessere Lösung:
Besorge dir ESSID fähige WLAN Accesspoints und spanne damit 2 WLANs auf. Eins mit dem Captive Portal für die Schüler und ihre Laptops und eins WPA verschlüsselt für die Lehrer. Über VLANs auf der pfSense führst du die getrennt wieder zusammen. Damit gehst du dann komplett richtig auf Nummer sicher.
Wenn du willst kannst du den Lehrern noch eine zertifikats basierte Authentisierung einrichten, dann ist das richtig wasserdicht was die Leher anbetrifft. Da solltest du schon auf Nummer sicher gehen, denn mann sollte Schüler nicht unterschätzen face-wink
Wie man das einfach mit freien Mitteln und dem pfSense umsetzt kannst du hier nachlesen:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Die sichere Authentisierung ( falls dir WPA2 nicht reicht für die Lehrer) hier:
Sichere 802.1x WLAN-Benutzer Authentisierung über Radius
Mitglied: rheingauner
rheingauner 07.11.2011 um 08:44:48 Uhr
Goto Top
so, es hat ein bisschen gedauert aber ich bin schon einen Schritt weiter gekommen.

Ich habe den Rechner testweise in das Schulnetz integriert. Das Capitve Portal funktionoiert jetzt mit der https-Verschlüsslung in Kombination mit dem transparenten Proxy.
Jetzt kann ich aufgrund des transparenten Modus aber keine https-Seiten aus dem Internet anzeigen lassen. Gibt es da eine unkomplinzierte Einstellung, damit das wieder klappt?
Mitglied: aqui
aqui 08.11.2011 um 15:19:53 Uhr
Goto Top
Das ist eingentlich unsinnig ! Das hat auf HTTPS Seiten keinerlei Einfluss. Wäre ja auch schlimm, denn sonst wäre das CP mit einer HTTPS Authentisierung ja gar nicht nutzbar wenn man damit keine HTTPS Seiten anzeigen könnte.
Wäre dem wirklich so dann würden auch keine HTTP Seiten kommen wenn die Portal Seite mit HTTP kommt was sie per Default ja auch tut.
Vergiss das also....irgendwas hast du da also falsch konfiguriert oder verfummelt !
Ein CP hier rennt mit HTTPS Auth vollkommen fehlerfrei !
Mitglied: rheingauner
rheingauner 08.11.2011 um 18:07:42 Uhr
Goto Top
es scheint aber "normal" zu sein, dass https mit transparenten Proxys nicht funktioniert. Bin auf diversen Seiten auf Hinweise gestoßen.

Habe mal folgenden Auszug kopiert:


SSL funktioniert nie über einen transparenten Proxy. Das liegt daran, dass bei einer SSL-Verbindung der Proxy die Header nicht lesen und damit den Request auch nicht weiter an den richtigen Server schicken kann. Bei normalem Proxy-Betrieb wird SSL mit einer speziellen Methode (CONNECT) durch den Proxy getunnelt; dafür muss der User aber den Proxy in seinem Browser eintragen. Ansonsten müsste der Proxy Server an Stelle des richtigen Webservers die HTTPS-Verbindung annehmen, was im Wesentlichen eine Man in the middle-Attacke ist und daher keine taugliche Lösung darstellt.
Quelle: https://www.tux.ethz.ch/wiki/index.php/Transparenter_Proxy_mit_Squid

Aber es gibt wahrschenlich immer einen Weg.
Mitglied: dog
dog 08.11.2011 um 18:45:40 Uhr
Goto Top
Das ist quatsch.
Also die Argumentation ist korrekt. Deshalb ist es aber trotzdem möglich.

Zugegeben, als ich das letzte mal sowas gebaut habe, habe ich das mit einem SOCKS-Proxy gemacht (mit transocks_ev).
Genauso wäre es aber möglich mit einem ähnlichen Programm den CONNECT-Befehl einzuschieben.
Mitglied: rheingauner
rheingauner 12.11.2011 um 15:30:02 Uhr
Goto Top
Wahrscheinlich ist das aber mit Pfsense nicht so einfach möglich. Ich habe irgendwo gelesen, dass es schon ginge aber die Lösung zielte auf die Neukompilation des Quelltextes ab. Das Ganze scheint mir mit Pfsense ziemlich knifflig zu werden.
Mitglied: aqui
aqui 13.11.2011 um 15:24:43 Uhr
Goto Top
pfSense bietet aber PBR. Damit kannst du TCP 443 Traffic zwangsweise redirecten auf den Proxy. Vielleicht hilft das der Lösung.