Domme vraag? Gastenwifi met voucher zonder WPA veilig?

[Urk]

Misschien een stomme vraag (I know, domme vragen schijnen niet te bestaan ) maar ik kan er toch niet echt duidelijk antwoord op vinden.
Ik heb als IT Pro toch al de nodige WiFi netwerken aangelegd, voornamelijk met Ubiquiti UniFi en Ruckus.
In beide gevallen maak ik vaak een gasten wifi netwerk aan met een Guest Portal met voucher codes.
Dat werkt natuurlijk prima, wat ik me echter al een tijdje afvraag hoe zit dat precies met de beveiliging?

Als je met een beveiligd netwerk verbind krijg je natuurlijk geen veiligheids waarschuwingen. Een gastenwifi met guestportal is meestal (weet dat het ook anders kan) een open netwerk, zodra de juiste code wordt ingevoerd krijg je toegang. Maar is het verkeer tussen WiFi AP en client dan wel versleuteld/beveiligd net zoals dat via WPA/WPA2/WPA3 is beveiligd?
Dat open gasten netwerk krijgt in de meeste besturingssystemen toch een extra waarschuwing omdat het OS het als onveilig netwerk ziet, maar ziet natuurlijk niet dat het erna is beveiligd met een unieke code...
Anyway: jullie snappen wel wat ik bedoel hoop ik

[ Voor 16% gewijzigd door Urk op 13-11-2020 23:34 ]

[dion_b]

Hoe het precies zit hangt af van implementatie. Grof gezegd twee keuzes:

1) Volledig open WiFi, met toegang tot (bedrade) VLAN via code en (vermoedelijk 802.1X).
2) WiFi met WPA(2)-Enterprise en RADIUS (=802.1X) server.

1 is inderdaad volledig open tussen client en AP. Iedereen in de buurt die zin heeft om te luisteren kan iedere datapakket die door de lucht gaat onderscheppen en lezen. Dat er beveiliging is op het bedrade netwerk op basis van unieke code doet daar niets aan af. Volstrekt onveilig voor de gebruiker.

2 is net zo veilig als WPA(2)-PSK, iedere client heeft een unieke wachtwoord waarmee authenticatie gedaan wordt, vervolgens worden steeds tijdelijke keys tussen client en AP uitgewisseld om te zorgen dat het verkeer versleuteld en prive blijft. Veilig voor de gebruiker.

Beide kunnen met portals werken, verschil zie je haarfijn, bij 1 krijg je op je client tegenwoordig waarschuwing voor onbeveiligd netwerk, bij 2 krijg je dat niet en moet je gebruikersnaam en wachtwoord invoeren. Moge duidelijk zijn welke de voorkeur geniet.

[Urk]

dion_b schreef op vrijdag 13 november 2020 @ 23:57:
Hoe het precies zit hangt af van implementatie. Grof gezegd twee keuzes:

1) Volledig open WiFi, met toegang tot (bedrade) VLAN via code en (vermoedelijk 802.1X).
2) WiFi met WPA(2)-Enterprise en RADIUS (=802.1X) server.

1 is inderdaad volledig open tussen client en AP. Iedereen in de buurt die zin heeft om te luisteren kan iedere datapakket die door de lucht gaat onderscheppen en lezen. Dat er beveiliging is op het bedrade netwerk op basis van unieke code doet daar niets aan af. Volstrekt onveilig voor de gebruiker.

2 is net zo veilig als WPA(2)-PSK, iedere client heeft een unieke wachtwoord waarmee authenticatie gedaan wordt, vervolgens worden steeds tijdelijke keys tussen client en AP uitgewisseld om te zorgen dat het verkeer versleuteld en prive blijft. Veilig voor de gebruiker.

Beide kunnen met portals werken, verschil zie je haarfijn, bij 1 krijg je op je client tegenwoordig waarschuwing voor onbeveiligd netwerk, bij 2 krijg je dat niet en moet je gebruikersnaam en wachtwoord invoeren. Moge duidelijk zijn welke de voorkeur geniet.

Bedankt voor je reactie.Optie 2 gebruik ik in een bedrijf meestal voor het veilige "medewerkers" netwerk, ook icm met een RADIUS/NSP server.

Ik weet niet zeker of je met Optie 1 bedoeld wat ik ook veel gebruik. In de WiFi instellingen kies ik voor een Open network maar met een guest portal. Ik genereer voucher codes en met die code krijg je toegang tot het netwerk. Wat je ook vaak in Hotels echter ziet. Ik kan me dus niet voorstellen dat verkeer via dat netwerk niet beveiligd / versleuteld wordt.... Maar jij zegt eigenlijk dat dat niet het geval is??

[dion_b]

Urk schreef op zaterdag 14 november 2020 @ 00:02:
[...]

Bedankt voor je reactie.Optie 2 gebruik ik in een bedrijf meestal voor het veilige "medewerkers" netwerk, ook icm met een RADIUS/NSP server.

Ik weet niet zeker of je met Optie 1 bedoeld wat ik ook veel gebruik. In de WiFi instellingen kies ik voor een Open network maar met een guest portal. Ik genereer voucher codes en met die code krijg je toegang tot het netwerk. Wat je ook vaak in Hotels echter ziet. Ik kan me dus niet voorstellen dat verkeer via dat netwerk niet beveiligd / versleuteld wordt.... Maar jij zegt eigenlijk dat dat niet het geval is??

Als je verbindt met een open netwerk en verbonden blijft met datzelfde netwerk (dus niet opnieuw verbinden als je credentials via portal gekregen hebt), dan is je verbinding met AP volstrekt open en onversleuteld.

Is dat je enige optie als gebruiker, dan raad ik met klem een goede VPN aan om te zorgen dat je kunt werken zonder dat elk pakket* zichtbaar is.

* op hogere protocolniveau's kunnen dingen wel versleuteld zijn, zoals HTTP dmv TLS, oftewel HTTPS. Dan is op WiFi-niveau (layer 2) de boel wel uit te lezen, maar de payload zelf is vanaf layer 4-7 (TLS is niet makkelijk te mappen op OSI) wel veilig. HTTPS is dus niet uit te lezen door een aanvaller, maar alles dat via HTTP of andere onversleutelde protocollen gaat wel.

[ Voor 6% gewijzigd door dion_b op 14-11-2020 00:09 ]

[Will_M]

@Urk Wat is de achterliggende vraag?

Als jij een 'open' netwerk host met (of zonder) capative portal dan ben je aansprakelijk voor al het verkeer wat er over dat netwerk loopt, ongeacht dat wat je in een 'EULA' zet welke je toont middels dat portal.

Als er een keer iets mis gaat, bijvoorbeeld op het moment dat een clubje als BREIN op de stoep staat, .... Je logging loopt waarschijnlijk niet ver genoeg terug.

[Urk]

Will_M schreef op zaterdag 14 november 2020 @ 00:09:
@Urk Wat is de achterliggende vraag?

Als jij een 'open' netwerk host met (of zonder) capative portal dan ben je aansprakelijk voor al het verkeer wat er over dat netwerk loopt, ongeacht dat wat je in een 'EULA' zet welke je toont middels dat portal.

Als er een keer iets mis gaat, bijvoorbeeld op het moment dat een clubje als BREIN op de stoep staat, .... Je logging loopt waarschijnlijk niet ver genoeg terug.

Hmmm, volgens mij vraag ik dit niet. Mijn vraag is niet juridisch maar louter technisch...

Waarom zou ik aansprakelijk zijn? Als ik een een Hotel een netwerk met een guest portal en dus een voucher gebruik en iemand download daar Kinderporno dan kan het toch niet zo zijn dat het Hotel daarvoor aansprakelijk is...

[Urk]

dion_b schreef op zaterdag 14 november 2020 @ 00:07:
[...]

Als je verbindt met een open netwerk en verbonden blijft met datzelfde netwerk (dus niet opnieuw verbinden als je credentials via portal gekregen hebt), dan is je verbinding met AP volstrekt open en onversleuteld.

Is dat je enige optie als gebruiker, dan raad ik met klem een goede VPN aan om te zorgen dat je kunt werken zonder dat elk pakket* zichtbaar is.

* op hogere protocolniveau's kunnen dingen wel versleuteld zijn, zoals HTTP dmv TLS, oftewel HTTPS. Dan is op WiFi-niveau (layer 2) de boel wel uit te lezen, maar de payload zelf is vanaf layer 4-7 (TLS is niet makkelijk te mappen op OSI) wel veilig. HTTPS is dus niet uit te lezen door een aanvaller, maar alles dat via HTTP of andere onversleutelde protocollen gaat wel.

OK, wat je als laatste noemt begrijp ik natuurlijk en lijkt me logisch.

Ik begrijp dat als het een volledig open netwerk betreft zonder guest portal dan snap ik dat al het verkeer onbeveiligd, niet versleuteld en dus inzichtelijk is.

De guest portal die ik noem zie je best vaak en veel in gasten netwerken, ook bij bedrijven. Het kan dan toch niet zo zijn dat al dat verkeer onveilig, niet versleuteld en dus inzichtelijk is voor anderen....?!

[Will_M]

Urk schreef op zaterdag 14 november 2020 @ 00:13:
[...]

Hmmm, volgens mij vraag ik dit niet. Mijn vraag is niet juridisch maar louter technisch...

Waarom zou ik aansprakelijk zijn? Als ik een een Hotel een netwerk met een guest portal en dus een voucher gebruik en iemand download daar Kinderporno dan kan het toch niet zo zijn dat het Hotel daarvoor aansprakelijk is...

Jawel, het is 'jouw' verbinding en jij bent als hoteleigenaar vervolgens verantwoordelijk voor het gedrag van de gasten.

[Urk]

Will_M schreef op zaterdag 14 november 2020 @ 00:16:
[...]


Jawel, het is 'jouw' verbinding en jij bent als hoteleigenaar vervolgens verantwoordelijk voor het gedrag van de gasten.

OK, heb je daar een bron van? En is dat veranderd sinds de AVG?

[ Voor 5% gewijzigd door Urk op 14-11-2020 00:18 ]

[Will_M]

Urk schreef op zaterdag 14 november 2020 @ 00:18:
[...]

OK, heb je daar een bron van? En is dat veranderd sinds de AVG?

Heb je wel eens een abonnement afgesloten bij een provider?

[Urk]

Will_M schreef op zaterdag 14 november 2020 @ 00:19:
[...]


Heb je wel eens een abonnement afgesloten bij een provider?

Uiteraard, wie niet...
Ik heb nog nooit gehoord dat een internet provider verantwoordelijk is en/of vervolgd wordt wanneer een abonnee kinderporno heeft gedownload hoor...

[ Voor 27% gewijzigd door Urk op 14-11-2020 00:21 ]

[dion_b]

Urk schreef op zaterdag 14 november 2020 @ 00:16:
[...]

De guest portal die ik noem zie je best vaak en veel in gasten netwerken, ook bij bedrijven. Het kan dan toch niet zo zijn dat al dat verkeer onveilig, niet versleuteld en dus inzichtelijk is voor anderen....?!

Ja, dat kan zeker.

Vaak is wel Client Isolation (soms AP Isolation) ingesteld, waarmee clients niet met elkaar kunnen praten. Klinkt leuk, maar enige wat je daarmee doet is per ongeluk bij je buurman binnenwandelen tegengaan. Een kwaadwillende zet z'n adapter gewoon in monitor mode, capturet alle verkeer en doet wat dan ook hij wil ermee.

Dat laatste heeft trouwens geen al te bijzondere hard- en software nodig. Ik gebruik een MacBook met Wireshark (open-source, gratis te downloaden) ervoor.

Urk schreef op zaterdag 14 november 2020 @ 00:20:
[...]

Uiteraard, wie niet...
Ik heb nog nooit gehoord dat een internet provider wordt verantwoordelijk is of vervolgd wordt wanneer een abonnee kinderporno heeft gedownload hoor...

Nee, want de provider kan aan z'n verplichting voldoen om op bevel van rechter verkeersgegevens af te geven waarmee ze duidelijk kunnen maken van/naar welke klant verkeer in kwestie kwam/ging. Zo niet heb je als provider een probleem.

Dit is trouwens waar de WiFi ticketsystemen van hotels e.d. voor zijn: niet om het verkeer van de klant te beschermen, maar om de aanbieder juridisch in te dekken.

[ Voor 29% gewijzigd door dion_b op 14-11-2020 00:24 ]

[Will_M]

Urk schreef op zaterdag 14 november 2020 @ 00:20:
[...]

Uiteraard, wie niet...

Goed zo!! Dan lees in die voorwaarden van je provider ook even wie er verantwoordelijk is voor de de data welke er over de verbinding gaat....

[ Voor 14% gewijzigd door Will_M op 14-11-2020 00:27 ]

[Urk]

Will_M schreef op zaterdag 14 november 2020 @ 00:22:
[...]


Goed zo!! Dan lees in die voorwaarden van je provider ook even wie er verantwoordelijk is voor de de data welke er over de verbinding gaat....

Zojuist gedaan. Helden van Nu is mijn provider. Zie artikel 7.2 van hun Algemene Voorwaarden. Daar staat -als ik het goed begrijp- dat ik verantwoordelijk ben...
Ook hun verwerkersovereenkomst lijkt me nergens te zeggen wat jij noemt.

[Will_M]

Urk schreef op zaterdag 14 november 2020 @ 00:27:
[...]

Zojuist gedaan. Helden van Nu is mijn provider. Zie artikel 7.2 van hun Algemene Voorwaarden. Daar staat -als ik het goed begrijp- dat ik verantwoordelijk ben...
Ook hun verwerkersovereenkomst lijkt me nergens te zeggen wat jij noemt.

Mooi wat 'de Helden van Nu' daar in d'r eigen voorwaarden vermelden maar wat is nu eigenlijk je vraag?

[Urk]

dion_b schreef op zaterdag 14 november 2020 @ 00:21:
[...]

Ja, dat kan zeker.

Vaak is wel Client Isolation (soms AP Isolation) ingesteld, waarmee clients niet met elkaar kunnen praten. Klinkt leuk, maar enige wat je daarmee doet is per ongeluk bij je buurman binnenwandelen tegengaan. Een kwaadwillende zet z'n adapter gewoon in monitor mode, capturet alle verkeer en doet wat dan ook hij wil ermee.

Dat laatste heeft trouwens geen al te bijzondere hard- en software nodig. Ik gebruik een MacBook met Wireshark (open-source, gratis te downloaden) ervoor.

[...]
Nee, want de provider kan aan z'n verplichting voldoen om op bevel van rechter verkeersgegevens af te geven waarmee ze duidelijk kunnen maken van/naar welke klant verkeer in kwestie kwam/ging. Zo niet heb je als provider een probleem.

Dit is trouwens waar de WiFi ticketsystemen van hotels e.d. voor zijn: niet om het verkeer van de klant te beschermen, maar om de aanbieder juridisch in te dekken.

Hmmm... ok, dat verbaasd me nogal en was ik me niet van bewust...
Hoe regelen jullie dan bij jullie klanten een veilig gastennetwerk in? Dat doen jullie dus niet met guest portal, of beter zoals jij noemt WiFi Ticketingsystemen?

[ Voor 18% gewijzigd door Urk op 14-11-2020 00:34 ]

[Urk]

Will_M schreef op zaterdag 14 november 2020 @ 00:32:
[...]


Mooi wat 'de Helden van Nu' daar in d'r eigen voorwaarden vermelden maar wat is nu eigenlijk je vraag?

Zie m'n topicstart Lijkt me een duidelijke vraag toch? Graag even ontopic houden, misschien interessant het juridische verhaal maar dat vroeg ik niet...

[johnkeates]

Ik begrijp nog steeds niet wat de vraag is of wat er bedoeld wordt. Het lijkt tot zo ver om de veiligheid van de verbinding te gaan in termen van het wel of niet ongecodeerd versturen van verkeer. Want ongecodeerd is niet veilig en gecodeerd verkeer wel.

Als de vraag is: is een onbeveiligd netwerk beveiligd? Dan is het antwoord: nee.
Als de vraag is: is een voucher een vorm van beveiliging? Dan is het antwoord ook: nee.

Daar kan je dan misschien ook bij stellen dat het een beetje afhangt waar je 'veilig' voor wil zien. "Veilig" om je draadloze verkeer niet leesbaar te hebben voor anderen: zonder WPA2 met AES of beter is het leesbaar te krijgen voor anderen. En als je de PSK deelt, dan ook. Als je met 'anderen' bijvoorbeeld de verstrekker bedoelt: die kan gewoon altijd op de verbinding meekijken, die verstrekt immers het wachtwoord maar kan ook gewoon op de verbinding van de AP zelf meekijken.

[ Voor 36% gewijzigd door johnkeates op 14-11-2020 00:38 ]

[Will_M]

Urk schreef op zaterdag 14 november 2020 @ 00:34:
[...]


Hmmm... ok, dat verbaasd me nogal en was ik me niet van bewust...
Hoe regelen jullie dan bij jullie klanten een veilig gastennetwerk in? Dat doen jullie dus niet met guest portal, of beter zoals jij noemt WiFi Ticketingsystemen?

Het begint met alléén TCP80/443 toe te staan op dat (virtuele) GASTEN netwerk... En daarnaast een beetje DPI (Deep Packet Inspection) waar je als 'gast' toestemming voor geeft door de EULA te accepteren.

[Urk]

johnkeates schreef op zaterdag 14 november 2020 @ 00:36:
Ik begrijp nog steeds niet wat de vraag is of wat er bedoeld wordt. Het lijkt tot zo ver om de veiligheid van de verbinding te gaan in termen van het wel of niet ongecodeerd versturen van verkeer. Want ongecodeerd is niet veilig en gecodeerd verkeer wel.

Als de vraag is: is een onbeveiligd netwerk beveiligd? Dan is het antwoord: nee.
Als de vraag is: is een voucher een vorm van beveiliging? Dan is het antwoord ook: nee.

Ik weet niet of ik de vraag simpeler kan stellen maar ik probeer het: bij een WiFi netwerk met WPA2 is al het verkeer tussen Acces Point en client beveiligd en versleuteld? Eens?
Datzelfde is de vraag bij een WiFi netwerk met een guest portal / WiFi ticketing systeem. Ik was zelf eigenlijk in de veronderstelling dat als iemand de juiste voucher code invoert en dus toegang krijgt het access point dat het access point dan op een ander niveau toch nog zorgt voor beveiliging (encrypted verkeer) tussen het access point en de client, op een vergelijkbare manier zoals dat bijv ook werkt met WPA2.

Edit: UIteraard is de Guest Web Portal wel voorzien van een geldig TLS certificaat...

[ Voor 5% gewijzigd door Urk op 14-11-2020 00:46 ]

[RGAT]

Je vraag is dan: 'Met WPA1/2/3 is het verkeer encrypted, als ik die encryptie uit zet, heb ik dan nog encryptie aan staan?'
Antwoord daarop is dus natuurlijk nee, dat je dan op een webpagina ergens een wachtwoord of voucher-code invoert heeft niets met encryptie te maken, hooguit dat die website via HTTPS aangeboden wordt en dat verkeer dus encrypted is maar de rest niet. Hoe zou dan verkeer encrypted worden door de captive portal? Dat is puur een interface om toegang te krijgen, niet een volledige proxy die alles encrpyt en zelfs als het dat zou doen draait het niet op je eigen laptop maar op het draadloze netwerk en kan het dus niet draadloos verkeer encrypten vanuit een webinterface

[Will_M]

Urk schreef op zaterdag 14 november 2020 @ 00:40:
[...]

Ik weet niet of ik de vraag simpeler kan stellen maar ik probeer het: bij een WiFi netwerk met WPA2 is al het verkeer tussen Acces Point en client beveiligd en versleuteld? Eens?
Datzelfde is de vraag bij een WiFi netwerk met een guest portal / WiFi ticketing systeem. Ik was zelf eigenlijk in de veronderstelling dat als iemand de juiste voucher invoert en dus toegang krijgt het access point dan op een ander niveau toch nog zorgt voor beveiliging (encrypted) tussen het access point en de client, op een vergelijkbare manier zoals dat bijv ook werkt met WPA2.

Het WiFi verkeer is dan inderdaad versleuteld middels WPA tussen je laptop en het AP.... Dat AP hangt echter ook aan een kabeltje wat verbonden is met een (L2) switch en vervolgens weer met een (L3) router...

[dion_b]

Urk schreef op zaterdag 14 november 2020 @ 00:34:
[...]


Hmmm... ok, dat verbaasd me nogal en was ik me niet van bewust...
Hoe regelen jullie dan bij jullie klanten een veilig gastennetwerk in? Dat doen jullie dus niet met guest portal, of beter zoals jij noemt WiFi Ticketingsystemen?

Ik werk bij een wat grotere telco, maar principe is hetzelfde. Ons gastnetwerk gaat met unieke gebruikersnaam+wachtwoord voor iedere klant, waarmee ingelogd kan worden op WPA2-Enterprise systeem. Daar hangt een RADIUS-authenticatieoplossing achter.

Nu, dat klinkt ingewikkeld, en als je het over miljoenen klanten en AP's hebt is dat het ook wel, maar op schaal van een enkele pand is het heel goed te overzien.

- draai een (gratis) RADIUS server op een Raspberry Pi, of als extra proces/VM op willekeurig welke al aanwezige server (bijvoorbeeld server die de electronische sleutels voor hotelkamers beheert)
- stel in je WiFi-oplossing in dat WPA2-Enterprise gebruikt moet worden en geef adres van RADIUS-server voor AAA.
- Genereer per gast een unieke login+wachtwoord combo op die server, met levensduur niet langer dan de gast verwacht wordt te blijven
- geef dat aan gast + SSID waar ze op aan moeten melden.
- klaar
- mocht het ooit nodig zijn, je hebt logging van welke gast op welk moment op welk IP verbonden was met je netwerk.

From scratch met open-source software is het uurtje werk ofzo schat ik in, er zijn uiteraard commerciele pakketten om het idiot-proof te maken, of om het te koppelen aan bestaande administratiesystemen.

[dion_b]

Will_M schreef op zaterdag 14 november 2020 @ 00:45:
[...]


Het WiFi verkeer is dan inderdaad versleuteld middels WPA tussen je laptop en het AP.... Dat AP hangt echter ook aan een kabeltje wat verbonden is met een (L2) switch en vervolgens weer met een (L3) router...

Nee dus, als je een open netwerk + portal hebt, is en blijft het voor het WiFi-stuk open, dus geen WPA(2)

[Will_M]

dion_b schreef op zaterdag 14 november 2020 @ 00:48:
[...]

Nee dus, als je een open netwerk + portal hebt, is en blijft het voor het WiFi-stuk open, dus geen WPA(2)

Eeuh... Ik reageerde daar op de WPA vraag, niet meer op 't OPEN netwerk waar 't eerder over ging

[remco_k]

Een open wifi netwerk zal niet schakelen naar een encrypted netwerk als iemand ergens een code invult. En dus is het mogelijk voor derden om eenvoudig mee te kijken of misschien zelfs een MITM attack doen.

Nou zijn de meeste websites en data transport van apps tegenwoordig SSL/HTTPS dus de data die heen en weer gaat is per definitie versleuteld. Dus daar hoef je je dan geen zorgen over te maken. Maar je moet je wel zorgen maken over dat een groot deel van de URL die de gebruiker bezoekt hierbij alsnog als plaintext door de lucht gaat en dus eenvoudig kan worden gezien wie wat bezoekt. Privacy problemen dus.

Het is nog erger als iemand een HTTP pagina bezoekt. Dat verloopt compleet plain text, en is daardoor kinderlijk eenvoudig in te zien als dat ook nog eens over een open wifi netwerkt verloopt. MITM attacks zijn dan kinderspel.

Heb je een Wifi netwerk mét encryptie dan bestaan alle hierboven genoemde problemen niet.

Oplossing: je open Wifi netwerk beveiligen met een relatief simpel wachtwoord en je portal daarachter gewoon in stand houden voor je toegangscontrole.

Edit: Of doen wat @dion_b zegt. 😀

[dion_b]

Will_M schreef op zaterdag 14 november 2020 @ 00:51:
[...]


Eeuh... Ik reageerde daar op de WPA vraag, niet meer op 't OPEN netwerk waar 't eerder over ging

Toch wel, hij begint weliswaar over WPA-PSK, daarna stelt hij dat een open netwerk met captive portal ook zo beveiligd is zodra je in de portal een wachtwoord invoert. Nope.

[Urk]

dion_b schreef op zaterdag 14 november 2020 @ 00:55:
[...]

Toch wel, hij begint weliswaar over WPA-PSK, daarna stelt hij dat een open netwerk met captive portal ook zo beveiligd is zodra je in de portal een wachtwoord invoert. Nope.

Nee, ik bedoelde wel wat Will_M inderdaad noemt. Dus het klopt wat hij zegt..

[Urk]

RGAT schreef op zaterdag 14 november 2020 @ 00:44:
Je vraag is dan: 'Met WPA1/2/3 is het verkeer encrypted, als ik die encryptie uit zet, heb ik dan nog encryptie aan staan?'
[...]

Toch niet helemaal mee eens, althans: Het zou toch kunnen dat het AP op een ander niveau het verkeer versleuteld tussen client en AP. Zie het net zoals WPA en dan verkeer daarover via HTTPS...

[dion_b]

remco_k schreef op zaterdag 14 november 2020 @ 00:54:
[...]

Maar je moet je wel zorgen maken over dat een groot deel van de URL die de gebruiker bezoekt hierbij alsnog als plaintext door de lucht gaat en dus eenvoudig kan worden gezien wie wat bezoekt. Privacy problemen dus.

Nog erger: diezelfde URL kan ook login credentials bevatten, database references of andere zaken op basis waarvan een kwaadwillende nog een stuk meer kan dan met alleen de info waar je aan het browsen bent.

Genoeg ranzige vulnerabilities op dat vlak de laatste tijd

Urk schreef op zaterdag 14 november 2020 @ 00:56:
[...]

Nee, ik bedoelde wel wat Will_M inderdaad noemt. Dus het klopt wat hij zegt..

Alleen als je dus eerst een PSK-wachtwoord moet invoeren bij aanmelden op het WiFi-netwerk. Geen wachtwoord invoeren bij allereerste aanmelding=onbeveiligd netwerk.

[dion_b]

Urk schreef op zaterdag 14 november 2020 @ 00:59:
[...]

Toch niet helemaal mee eens, althans: Het zou toch kunnen dat het AP op een ander niveau het verkeer versleuteld tussen client en AP. Zie het net zoals WPA en dan verkeer daarover via HTTPS...

Nee. Een AP is een WiFi-apparaat dat op layer 1 en 2 werkt, meer niet. Enige versleuteling daar zit in layer 2 zelf, oftewel de WiFi WPA security protocollen.

[johnkeates]

Laat ik het zo stellen: een portal en/of een voucher heeft geen relatie met de veiligheid of versleuteling van de verbinding.

Met andere woorden: als je geen wachtwoord hoeft in te voeren om bij een portal te komen, of als je computer aangeeft dat het geen veilig netwerk is, dan is dat dus niet gecodeerd, ongeacht wat je daarna doet.

Denk in laagjes:

- WPA is op het laagje van de verbinding (Laag 2 of Layer 2 heet dat, Ethernet is ook Laag 2)
- Boven op die verbinding kan je weer andere dingen doen zoals websites bezoeken, mailen enz. (Laag 3)

Wat je in Laag 3 doet heeft geen effect op Laag 2. Dus je kan zo veel portals en vouchers enz. in Laag 3 stoppen als je maar wil, Laag 2 verandert daar niet door.

Met andere woorden: Tenzij Laag 2 encrypted is (bijv. met WPA) is het niet gecodeerd.

Als je verder gaan dan jouw vraag: je kan encryptie op meerdere lagen toepassen. Dat betekent nog steeds niet dat dat iets is wat een portal kan doen, maar HTTPS is bijvoorbeeld HTTP over TLS. TLS versleutelt de verbinding dan (op Laag 3). Als Laag 2 dan leesbaar is (niet versleuteld) kan je kijken wat er in de volgende laag zit (laag 3). Maar om dat je die laag dan gecodeerd hebt kan je dus alleen de gecodeerde data zien.

Zijn er technologieën om daar wat mee te doen? Uiteraard. Daar kunnen we nog op in gaan als je dat wil.

[ Voor 13% gewijzigd door johnkeates op 14-11-2020 01:03 ]

[remco_k]

dion_b schreef op zaterdag 14 november 2020 @ 01:00:
[...]

Nog erger: diezelfde URL kan ook login credentials bevatten, database references of andere zaken op basis waarvan een kwaadwillende nog een stuk meer kan dan met alleen de info waar je aan het browsen bent.

Eens over die lekken, maar de data die verder in de URL staat is overigens wel encrypted door SSL. Alleen het server adres deel (www.domain.com) gaat plaintext over de lijn.

[Will_M]

@johnkeates Gaan we met ananas spullen spelen?

[johnkeates]

Will_M schreef op zaterdag 14 november 2020 @ 01:08:
@johnkeates Gaan we met ananas spullen spelen?

Ja, of met de cactus variant

[laurens0619]

Je hebt de Wifi laag en je hebt de netwerk laag

Stel je wilt sniffen, wat kun je dan op de wifi laag?

Open - Je kunt eenvoudig het verkeer sniffen
WPA2 Pre Shared Key - Je kunt eenvoudig het verkeer sniffen als je de key weet
WPA2 Enterprise - Dit verkeer is niet zomaar te decrypten

Een Open of PSK guest Wifi is dus net zo onveilig. Bij een PSK guest wifi is de key namelijk bekend, ook voor de aanvaller. Alleen WPA2 enterprise is dus veilig maar dat zie ik op guest wifi echt weinig voorkomen.

Welke optie je ook pakt, je bent hierna met het netwerk verbonden.

Stel je wilt sniffen, wat kun je op de netwerk laag?
Als je op het netwerk zit kun je vaak bv ARP poisening doen, tenzij er controls als AP isolation aan staan.
Na een arp poisening kun je het verkeer via jou laten lopen en er zelfs tussen zitten. Ook bij wpa2 enterprise.

Dus welke optie je pakt, bij een gedeeld (guest) wifi netwerk zijn er dus vaak risico's en mogelijkheden dat je verkeer onderschept wordt. Het meest veilige zit je op een WPA2 enterprise netwerk met AP isolation.

Ga je er risk based over nadenken:
* Hoe groot is de kans dat er een aanvaller op jet netwerk zit
* Hoe groot is de kans dat er onversleuteld verkeer plaatsvind?

Dat antwoord zou laag moeten zijn. Ben je een high value target dan moet je device sowieso zo ingeregeld zijn dat alles bv automatisch over een vpn loopt (wat niet versleuteld is).
Sowieso als ik als hacker je credentials wil stelen dan stuur ik een goede phishing mail. Kost mij veel minder energie, risico en een vele grotere kans op succes.

Kijk maar eens terug: Al die nieuwsberichten over wifi sniffing zijn altijd onderzoek artikelen dat pentester/journalist A aantoont dat het mogelijk is. Kijk je naar de daadwerkelijke hacks, dan lees ik nooit wifi hacking terug maar bijna altijd leaked password. slecht mfa gebruik en phishing.

De wereld zit vol met kwetsbaarheden maar het doel in security is niet om iedere kwetsbaarheid te dichten maar dreigingen te analyseren en het risico hierop op uitbuiting zo laag mogelijk te houden.

[ Voor 26% gewijzigd door laurens0619 op 14-11-2020 05:55 ]

[sylvester79]

dion_b schreef op zaterdag 14 november 2020 @ 00:21:
Nee, want de provider kan aan z'n verplichting voldoen om op bevel van rechter verkeersgegevens af te geven waarmee ze duidelijk kunnen maken van/naar welke klant verkeer in kwestie kwam/ging. Zo niet heb je als provider een probleem.

Je gaat hier wel snel door de bocht. Als iemand via jouw gasten wifi kinderporno download en de politie toevallig die server waarvan wordt gedownload in de gaten houdt dan hebben ze jouw IP adres. De politie kan dan actie ondernemen op basis van die gegevens.

Echter als dit door een gast van jouw is gebeurd en jij kan niet aanleveren wie die gast is heeft geen enkele gevolgen.

De genoemde bepaling bij de providers gaat veelal om abuse zaken. Als een gast jouw internet verbinding gebruikt voor een DDOS, poortscans e.d. kan de ISP besluiten jouw verbinding af te sluiten en je verplichten het probleem op te lossen of zelfs je verbinding definitief afsluiten.

Maar dat jij als contractant van een internet verbinding strafbaar bent als een gast kinderporno download is nergens op gebaseerd.

Ook zijn verkeersgegevens niet zo opvraagbaar bij de rechtbank. Providers leveren wel elke 24 uur een actuele lijst aan met de NAW gegevens die bij een IP adres horen, zodat justitie direct toegang heeft.

[kosternet]

Er is nog iets anders waar je rekening mee moet houden en wat vaak geen aandacht krijgt.

Zodra jij jouw klanten een 'open' netwerk aanbiedt (zelfs als dat met een voucher is), dan is de kans groot dat jouw klant vergeet om het Wifi-netwerk te 'vergeten'.
Ofwel; de laptop/telefoon/tablet van jouw klant zal vanaf dat moment proberen met jouw Wifinetwerk (met bijvoorbeeld SSID GATENWIFI) te verbinden. Op zich zou je verwachten dat dit geen probleem oplevert omdat zijn apparaat in de firewall van jouw wifi-netwerk weer geblokkeerd wordt totdat hij een juiste vouchercode invoert. Voor zover dus niet spannend.

Nadeel is wel dat Wifi-netwerken in het ontwerp als zwakheid hebben dat steeds geprobeerd wordt om met een bekend wifi-netwerk te verbinden wanneer dit binnen bereik is. In het protocol is dus beschreven dat het klantapparaat vanaf dat moment af en toe zal vragen of jouw 'GASTENWIFI' beschikbaar is.

Jouw klant zit de volgende dag ergens lekker een bakje koffie te drinken met zijn telefoon in zijn zak. Daarnaast zit iemand die een HAK5 Pineapple heeft, en dat vernuftige apparaatje luistert continue of er om wifinetwerken wordt gevraagd. De telefoon van jouw klant probeert af en toe nog met jouw GASTENWIFI te verbinden en dit wordt door de Pineapple gehoord.

Hier zit het probleem.. Omdat het GASTENWIFI-netwerk geen wachtwoord heeft, kan de Pineapple door alleen de juiste SSID aan te bieden, jouw GASTENWIFI imiteren. Op dat moment zal de telefoon van jouw klant op de Pineapple aanmelden en is een situatie gecreëerd waarmee de eigenaar van de Pineapple simpel een Man in the middle attack kan uitvoeren. Al het verkeer van het apparaat van de klant gaat immers via zijn Pineapple.

Wanneer een netwerk wel een wachtwoord heeft kan de Pineapple dit niet eenvoudig imiteren. Een stuk veiliger dus.

Het kan overigens nog simpeler zonder pineapple;
Bedenk de naam van een bekend open netwerk zoals wellicht 'Wifi in de trein' of 'Gratis MacDonalds-wifi' oid. Configureer een accesspoint (of jouw hotspot) met deze naam, en de kans is aanwezig dat mensen die in het verleden met deze netwerken hebben verbonden vanaf dat moment via jouw eigen netwerk verbinden. dan hoef je niet eens in de trein te zitten.

Welke oplossingen zijn voor dit probleem?
- Allereerst, maak zo min mogelijk gebruik van 'open' netwerken vanwege de versleutelingsdiscussie hierboven
- Wanneer je wel een open wifi-netwerk hebt gebruikt, VERGEET DAN DIT NETWERK (of zorg dat jouw apparaat er in ieder geval niet automatisch mee verbind)
- Biedt zelf geen open netwerk aan aan jouw klanten zodat je hen behoedt om in deze val te lopen

Concreet hebben wij het op mijn werk opgelost door het volgende in te stellen:
1. We hebben een databaseje gemaakt met daarin een lijst met willekeurige Nederlandse woorden (langer dan 8 tekend, en de ongepaste woorden als bloedgeil eruit gefilterd)
2. We hebben een klein scriptje wat via de Ubiquiti-API dagelijks een nieuw wachtwoord voor het gastenwifi instelt op basis van een willekeurig woord uit de database
3. Ik heb een aantal M5STACK Core's geprogrammeerd om dagelijks hetzelfde wifi-wachtwoord uit de database te halen en deze te tonen op het kleine schermpje.

Die m5stack core's kosten ong. 30-40 euro per stuk en staan bij ons in de kamers waar gasten welkom zijn om wifi te gebruiken. Hiermee moet men dagelijks een nieuw wachtwoord kiezen en is de verbinding versleuteld. We hoeven geen vouchers meer uit te draaien en klanten hebben geen beveiligingslek op hun apparaat in de vorm van een open netwerk.

[CH4OS]

Will_M schreef op zaterdag 14 november 2020 @ 00:16:
Jawel, het is 'jouw' verbinding en jij bent als hoteleigenaar vervolgens verantwoordelijk voor het gedrag van de gasten.

Wat is dit voor kolder? Aan de hand van het IP-adres die de eiser overhandigd aan het hotel, kan het hotel zien welke persoon dat is geweest en vervolgens justitie gewoon doorverwijzen naar de daadwerkelijke downloader?

Zelfde geldt dus ook als je een vergelijkbare situatie thuis hebt, je kan immers aantonen wie het wel geweest is.

Zou mooi zijn, als de hoteleigenaar verantwoordelijk zou zijn voor de daden van zijn gasten...

Ik kan mij een topic herinneren op GoT, van iemand die vanuit een Duits hotel Popcorn Time gebruikte en (dankzij een honeypot van een Duits advocaten kantoor) uiteindelijk een schikkingsvoorstel kreeg.

EDIT:
Gevonden; Aangeklaagd door Popcorn kijken in Duits hotel

[ Voor 36% gewijzigd door CH4OS op 14-11-2020 12:49 ]

[laurens0619]

@kosternet fantastisch knutselproject maar een laptop hoeft maar 1x op een plek verbonden geweest te zijn met een public wifi en je oplossing heeft geen effect meer. Daarbij doen de meeste os systemen niet meer standaard automatisch verbinden met een opgeslagen open wifi profiel dus het probleem is niet meer zo groot.

Waarom gebruik je geen wpa2 enterprise voor je guest wifi? Ook al heb je iedere dag een ander wachtwoord, mensen kunnen nog steeds sniffen als ze dat wachtwoord hebben

[Ryur]

CH4OS schreef op zaterdag 14 november 2020 @ 12:40:
[...]
Wat is dit voor kolder? Aan de hand van het IP-adres die de eiser overhandigd aan het hotel, kan het hotel zien welke persoon dat is geweest en vervolgens justitie gewoon doorverwijzen naar de daadwerkelijke downloader?

Zelfde geldt dus ook als je een vergelijkbare situatie thuis hebt, je kan immers aantonen wie het wel geweest is.

Note: dan moet de hotel dus wel (genoeg) logging hebben om het terug te kunnen leiden naar een klant/persoon

Als ze dat niet hebben, dan denk ik (IMAL!) dat de hotel wel verantwoordelijk (kan) zijn. Sowieso om dan meer logging in te bouwen dat het niet nog een keertje voor kan komen.

[kosternet]

@laurens0619 Je hebt gelijk dat deze aanpassing niet de oplossing van het probleem is

In de praktijk merken we wel dat veel bedrijven met hun gasten-wifi mede-onderdeel van het probleem zijn, en dat willen wij in ieder geval niet.

En zolang iets via de lucht gaat heb je altijd een grotere kans dat er middels sniffing informatie onderschept wordt. Heel wat gemakkelijker dan ongemerkt kabels of zelfs glasvezel aftappen.
Sniffen door WPA2 te hacken lijkt me een kleiner risico omdat je dan echt moet weten wat je doet. Een MiTM met een open wifi-netwerk is al heel wat eenvoudiger om te doen.

Ach... we prutsen maar wat in de hoop dat alle kleine beetjes helpen he

[mash_man02]

Ten aanzien van WPA2 bestaat er tegenwoordig ook PPSK waarbij je niet de WPA2-Enterprise complexiteit hebt maar wel de beveiliging omdat je een sleutel per gebruiker aanmaakt.Afhankelijk van de implementatie zijn er diverse aanvullende features mogelijk zoals.

Bijkomend voordeel is dat je in sommige implementaties ook vlan assignement kan doen op basis van sleutel waardoor je nog meer service segmentatie kunt aanleggen zonder de traditionele scheiding middels het in de lucht brengen van extra ssid's.

[ Voor 9% gewijzigd door mash_man02 op 10-12-2020 09:20 ]

[Frogmen]

Is een ticket systeem niet een beetje ouderwets, ga er in alle opzet vanuit dat een vreemd netwerk onveilig is en zorg voor je eigen veilige verbinding. Voordeel is dat je het gastennetwerk open kan zetten, of met WPA2 en een wachtwoord. Ticket systemen zijn leuk op papier maar de aanvraag meestal een draak en tijdrovend. Nederlanders zijn creatief en zorgen wel voor iets anders.
Enige is dan het zogenaamde juridische vraagstuk, dan is mijn vraag laat maar eens jurisprudentie zien waarbij de aanbieder van een open wifi netwerk verantwoordelijk is gesteld. Tot die tijd stop met onzin uitkramen zorg voor logging van mac adressen en tijden. Volgens mij heb je dan meer dan genoeg gedaan om opsporing te helpen. (Ja ik weet het is niet waterdicht, maar is dat ticket systeem het wel?)