LAN-aansluiting op publieke plek beveiligen tegen indringers

[Qlimaxxx]

Hallo mede-tweakers,

Ik ben nog aan het leren als het op netwerken aan kan. Nu heb ik echter een vraag.
Even een voorbeeldsituatie:
Op een publieke plek hangt een apparaat(bijvoorbeeld een AP) die actief is in 2 of meer VLAN's. Op dit apparaat zit een bridgepoort waarop een ander apparaat zit dat in ieder geval internet access moet hebben. Echter is dit een onbeheerde plek en is er dus de kans dat iemand het AP loskoppelt om via de LAN-kabel het netwerk binnen te dringen.

Mijn plan was om 2 SSID's op hun eigen VLAN te taggen en vervolgens een extra VLAN untagged naar het AP te sturen dat met firewall regels geïsoleerd is van alle overige netwerken. Dit met een eigen DHCP server in een totaal andere range. Daarnaast leek het me ook handig om alle verkeer op dit untagged VLAN te blokkeren behalve dat van het apparaat dat via bridge aangesloten is(MAC address whitelist).

Is dit een goede manier om deze kwetsbare plek te beveiligen of dienen er nog meer maatregelen genomen te worden?

[Snake]

802.1x protection.

MAC address is waardeloos. Zeker omdat de MAC address achter op de AP staat.

Enige probleem: dit gaat niet zomaar met ieder AP.

Je moet een AP hebben die een Management VLAN ondersteunt (en dus niet alleen untagged), en dan zit je al bij de dure.

Ik weet in ieder geval dat met OpenWRT ik de Management VLAN kon instellen (i.e. de AP was alleen bereikbaar via VLAN 10), maar of er RADIUS authentication bij kon weet ik niet meer.

Even gekeken naar Ubiquiti, en daarmee kunnen de APs enkel werken met een untagged Management VLAN (zucht...) wat dus wil zeggen dat iedereen die er verbindt op z'n minst contact kan maken met andere APs.

Nu kan je natuurlijk deze VLAN volledig afsluiten van het internet.

[Qlimaxxx]

Snake schreef op donderdag 9 februari 2017 @ 18:08:
802.1x protection.

MAC address is waardeloos. Zeker omdat de MAC address achter op de AP staat.

Enige probleem: dit gaat niet zomaar met ieder AP.

Je moet een AP hebben die een Management VLAN ondersteunt (en dus niet alleen untagged), en dan zit je al bij de dure.

Ik weet in ieder geval dat met OpenWRT ik de Management VLAN kon instellen (i.e. de AP was alleen bereikbaar via VLAN 10), maar of er RADIUS authentication bij kon weet ik niet meer.

Even gekeken naar Ubiquiti, en daarmee kunnen de APs enkel werken met een untagged Management VLAN (zucht...) wat dus wil zeggen dat iedereen die er verbindt op z'n minst contact kan maken met andere APs.

Nu kan je natuurlijk deze VLAN volledig afsluiten van het internet.

Even uitgaande van ubiquiti AP's. Het MAC address dat ik zou willen whitelisten was dan van het apparaat dat op de bridgepoort zit. Niet die van het AP zelf(die zou eerder vanuit een van de tagged VLAN's gemanaged moeten worden). Dit omdat enkele situaties die ik kan bedenken het apparaat dat via het AP aangesloten zou zitten dan misschien niet VLAN aware is.

[JackBol]

Qlimaxxx schreef op donderdag 9 februari 2017 @ 18:11:
[...]


Even uitgaande van ubiquiti AP's. Het MAC address dat ik zou willen whitelisten was dan van het apparaat dat op de bridgepoort zit. Niet die van het AP zelf(die zou eerder vanuit een van de tagged VLAN's gemanaged moeten worden). Dit omdat enkele situaties die ik kan bedenken het apparaat dat via het AP aangesloten zou zitten dan misschien niet VLAN aware is.

MAC whitelisting is geen security. Als iemand kwaad in de zin heeft, kan hij z'n MAC adres spoofen.
Hij kan het device dat hij los trekt even aan zijn laptop hangen en hij weet direct het MAC adres dat is gewhitelist.

De enige oplossing is 802.1x met certificaten configureren op de switchpoort waar het AP aan hangt.

Edit: overigens is tagging ook geen security. Met scapy kan je binnen 1 seconde op alle 4096 VLANs een frame sturen om te zien welke VLANs active zijn en daar lekker op doorhacken.

[ Voor 11% gewijzigd door JackBol op 09-02-2017 19:08 ]

[Qlimaxxx]

JackBol schreef op donderdag 9 februari 2017 @ 19:05:
[...]


MAC whitelisting is geen security. Als iemand kwaad in de zin heeft, kan hij z'n MAC adres spoofen.
Hij kan het device dat hij los trekt even aan zijn laptop hangen en hij weet direct het MAC adres dat is gewhitelist.

De enige oplossing is 802.1x met certificaten configureren op de switchpoort waar het AP aan hangt.

Edit: overigens is tagging ook geen security. Met scapy kan je binnen 1 seconde op alle 4096 VLANs een frame sturen om te zien welke VLANs active zijn en daar lekker op doorhacken.

OK, 802.1x is the way to go. Ik ga me er eens op inlezen.

Wat ben je daar precies voor nodig? Voldoet een OpenWRT router en een Unifi accesspoint?

In de usecase waar ik over na dacht hoeft het apparaat dat op het untagged VLAN zit enkel en alleen internet access te hebben. Het kan niet met VLAN's overweg. Het is een apparaat dat wel een vertrouwd apparaat is. Ik wil alleen voorkomen dat iemand in dit geval de LAN kabel uit het AP zou kunnen halen en via een untagged VLAN direct toegang heeft tot een van de andere netwerken.

Uiteraard zou dat ook het geval zijn indien je de LAN-adapter van je laptop met de juiste tagged VLAN's instelt. Ik heb echter geen idee of in dit geval dit ook op een of andere manier gesnift kan worden? Ik begeef me pas net in de wereld van netwerken en VLAN's.

Edit: Ik zie nu je edit pas. Ik begrijp dus dat in dit geval ook op de andere VLAN's meer security vereist is? Hoe moet ik dat voor me zien?

[ Voor 4% gewijzigd door Qlimaxxx op 09-02-2017 19:19 ]

[JackBol]

Qlimaxxx schreef op donderdag 9 februari 2017 @ 19:17:
[...]


OK, 802.1x is the way to go. Ik ga me er eens op inlezen.

Wat ben je daar precies voor nodig? Voldoet een OpenWRT router en een Unifi accesspoint?

OpenWRT ondersteunt het wel. Unifi weet ik niet. (nooit mee gewerkt).

In de usecase waar ik over na dacht hoeft het apparaat dat op het untagged VLAN zit enkel en alleen internet access te hebben. Het kan niet met VLAN's overweg. Het is een apparaat dat wel een vertrouwd apparaat is. Ik wil alleen voorkomen dat iemand in dit geval de LAN kabel uit het AP zou kunnen halen en via een untagged VLAN direct toegang heeft tot een van de andere netwerken.

Uiteraard zou dat ook het geval zijn indien je de LAN-adapter van je laptop met de juiste tagged VLAN's instelt. Ik heb echter geen idee of in dit geval dit ook op een of andere manier gesnift kan worden? Ik begeef me pas net in de wereld van netwerken en VLAN's.

Edit: Ik zie nu je edit pas. Ik begrijp dus dat in dit geval ook op de andere VLAN's meer security vereist is? Hoe moet ik dat voor me zien?

802.1x is VLAN onafhankelijk. Via 802.1x authenticeer je jezelf aan de switch voordat je het netwerk op mag, ongeacht het VLAN.

Je moet op je WRT een poort configureren met 802.1x. Begin maar even met MAC authenticatie (al is dat niet veilig), omdat je dat snel voor elkaar hebt. Als dat werkt zou ik overschakelen naar PEAP of EAP-TLS als de Unifi dat ondersteunt.

[Qlimaxxx]

JackBol schreef op donderdag 9 februari 2017 @ 19:39:
[...]

OpenWRT ondersteunt het wel. Unifi weet ik niet. (nooit mee gewerkt).

[...]


802.1x is VLAN onafhankelijk. Via 802.1x authenticeer je jezelf aan de switch voordat je het netwerk op mag, ongeacht het VLAN.

Je moet op je WRT een poort configureren met 802.1x. Begin maar even met MAC authenticatie (al is dat niet veilig), omdat je dat snel voor elkaar hebt. Als dat werkt zou ik overschakelen naar PEAP of EAP-TLS als de Unifi dat ondersteunt.

Is in dit geval de OpenWRT router ook de radius server of is hier aparte hardware voor nodig?

Zijn er ook veilige methodes voor 802.1x zonder dat iets daarvan op de client bekend moet zijn? In wat ik tot dusver tegengekomen ben zou ik speciale software op de client moeten installeren. Het gaat hier bijvoorbeeld om domotica met een LAN aansluiting en een touchscreen oid.

Begrijp ik het trouwens goed dat alle managed switches ook ondersteuning voor 802.1x moeten hebben?

[JackBol]

Qlimaxxx schreef op donderdag 9 februari 2017 @ 19:47:
[...]


Is in dit geval de OpenWRT router ook de radius server of is hier aparte hardware voor nodig?

Ik weet niet of er een radius server in OpenWRT zit. Je moet een beetje in de GUI rondklikken of er lokale authenticatie mogelijkheden zijn.

Zijn er ook veilige methodes voor 802.1x zonder dat iets daarvan op de client bekend moet zijn? In wat ik tot dusver tegengekomen ben zou ik speciale software op de client moeten installeren. Het gaat hier bijvoorbeeld om domotica met een LAN aansluiting en een touchscreen oid.

Er zijn zeer veel varianten, maar over het algemeen werkt 802.1x op een van de volgende 3 manieren:
MAC: onveilig, kan namelijk makkelijk achterhaald worden
PEAP: username/password redelijk veilig
EAP-TLS: met certificaat, meest complex maar meest veilig

Begrijp ik het trouwens goed dat alle managed switches ook ondersteuning voor 802.1x moeten hebben?

Je hoeft alleen 802.1x ondersteuning te hebben op de poorten die potentieel publiek toegankelijk zijn.
De meeste managed switches ondersteunen tegenwoordig 802.1x.

[Qlimaxxx]

JackBol schreef op donderdag 9 februari 2017 @ 21:06:
[...]

Ik weet niet of er een radius server in OpenWRT zit. Je moet een beetje in de GUI rondklikken of er lokale authenticatie mogelijkheden zijn.

[...]

Er zijn zeer veel varianten, maar over het algemeen werkt 802.1x op een van de volgende 3 manieren:
MAC: onveilig, kan namelijk makkelijk achterhaald worden
PEAP: username/password redelijk veilig
EAP-TLS: met certificaat, meest complex maar meest veilig

[...]

Je hoeft alleen 802.1x ondersteuning te hebben op de poorten die potentieel publiek toegankelijk zijn.
De meeste managed switches ondersteunen tegenwoordig 802.1x.

Thanks voor de duidelijkheid.

Even check/dubbelcheck:
Als ik een simpel apparaat via lan aansluit op een poort die geconfigureerd is met 802.1x dan hoeft dit apparaat niet te snappen wat 802.1x is of wel? Zoals ik het begrijp is het namelijk alleen mogelijk dmv MAC address en dan zijn we weer terug bij af... Of zou ik dan in ieder geval de VLAN's kunnen beschermen op het AP? Dat dat speciale untagged VLAN(internet only) wel te bereiken is zou me niet zoveel uitmaken.

[ Voor 4% gewijzigd door Qlimaxxx op 09-02-2017 21:13 ]

[Glashelder]

Dat hoeft alleen niet als je gebruik maakt van alleen een op MAC adressen gebaseerde beveiliging.

Als je PEAP of EAP-TLS gebruikt dan staat de switch toe dat de client een met TLS beveiligd kanaal opent met een RADIUS server voor authenticatie. Daar is wel support voor nodig op een client ja. Zolang de RADIUS server niet aan de switch terugkoppelt dat de poort op 'forwarding' gezet mag worden (en op welk VLAN dan wel etc) - oftewel, de authenticatie is gelukt - komt het device het netwerk niet op.

Wat jij eigenlijk wilt is een AP met EAP-TLS ondersteuning. De meeste doen dit wel voor wireless clients, maar of ze het ook doen voor hun eigen ethernet kanaal, geen idee eigenlijk. Veel goedkope switches zullen dit denk ik ook niet ondersteunen: die zullen geen alternatief VLAN kunnen configureren voor een poort waarvan de EAP-TLS authenticatie is mislukt vermoed ik (ik heb thans nooit dat soort mogelijkheden gezien in goedkope switches).

[ Voor 30% gewijzigd door Glashelder op 09-02-2017 21:27 ]

[Qlimaxxx]

Glashelder schreef op donderdag 9 februari 2017 @ 21:25:
Dat hoeft alleen niet als je gebruik maakt van alleen een op MAC adressen gebaseerde beveiliging.

Als je PEAP of EAP-TLS gebruikt dan staat de switch toe dat de client een met TLS beveiligd kanaal opent met een RADIUS server voor authenticatie. Daar is wel support voor nodig op een client ja. Zolang de RADIUS server niet aan de switch terugkoppelt dat de poort op 'forwarding' gezet mag worden (en op welk VLAN dan wel etc) - oftewel, de authenticatie is gelukt - komt het device het netwerk niet op.

Wat jij eigenlijk wilt is een AP met EAP-TLS ondersteuning. De meeste doen dit wel voor wireless clients, maar of ze het ook doen voor hun eigen ethernet kanaal, geen idee eigenlijk. Veel goedkope switches zullen dit denk ik ook niet ondersteunen: die zullen geen alternatief VLAN kunnen configureren voor een poort waarvan de EAP-TLS authenticatie is mislukt vermoed ik (ik heb thans nooit dat soort mogelijkheden gezien in goedkope switches).

Dus als ik het goed begrijp dan kan ik een niet VLAN aware apparaat in een publieke ruimte alleen veilig aansluiten als ik er een apart netwerk(met VLAN's) van maak en deze untagged als enige op de kabel zet?

Het lijkt me dat ik dit alleen werkend krijg als ik zo'n apparaat via bridge aansluit op een AP op een manier waarop de bridgepoort eenvoudig misbruikt kan worden?

Thanks voor de hulp in ieder geval, heb ik weer wat geleerd

Edit: Of is het ook mogelijk om 802.1x alleen op 2 van de 3 VLAN's te activeren(zodat de untagged VLAN met internet only access danwel te bereiken valt maar dit alleen om te internetten)?

[ Voor 5% gewijzigd door Qlimaxxx op 11-02-2017 10:16 ]

[dion_b]

JackBol schreef op donderdag 9 februari 2017 @ 21:06:
[...]

Ik weet niet of er een radius server in OpenWRT zit. Je moet een beetje in de GUI rondklikken of er lokale authenticatie mogelijkheden zijn.

Yep, er is een RADIUS package voor OpenWRT.

* dion_b heeft hem tijdje terug geinstalleerd maar bij gebrek aan tijd nog niet in gebruik genomen

[...]

Er zijn zeer veel varianten, maar over het algemeen werkt 802.1x op een van de volgende 3 manieren:
MAC: onveilig, kan namelijk makkelijk achterhaald worden
PEAP: username/password redelijk veilig
EAP-TLS: met certificaat, meest complex maar meest veilig

EAP-SIM is ws nog iets veiliger, maar dan moet je wel SIM-kaarten hebben

Maar idd eens dat (P)EAP-TLS op dit moment veiligste is in dit soort situatie, met PEAP-MSCHAPv2 als tweede keus. Let wel op device/OS support. Klasseker is dat Windows XP geen TLS ondersteunt, ondertussen ondersteunen moderne OSsen het wel allemaal - maar double-check als je embedded zooi gebruikt ("simpele devices") wat het dus ondersteunt.

[...]

Je hoeft alleen 802.1x ondersteuning te hebben op de poorten die potentieel publiek toegankelijk zijn.
De meeste managed switches ondersteunen tegenwoordig 802.1x.

Mier neuken: 802.1X

[Rolfie]

Qlimaxxx schreef op zaterdag 11 februari 2017 @ 10:14:
Edit: Of is het ook mogelijk om 802.1x alleen op 2 van de 3 VLAN's te activeren(zodat de untagged VLAN met internet only access danwel te bereiken valt maar dit alleen om te internetten)?

Vaak kan je regelen dat als 802.1x authenticatie mislukt, je in VLAN xxx komt. En dat kan een gasten VLAN zijn, met alleen Internet toegang, als dan niet met een captive protal er voor.

Juist een eigenschap van 802.1x authenticatie is dat je de security enorm verhoogt. Je switch bied na de authenticatie alleen maar bepaalde VLAN's (tagged of native) aanbied.

[Frogmen]

Zorg er om te beginnen voor dat het in eerste instantie wegvallen van het device wordt gesignaleerd door een stuk netwerk monitoring. Hiermee verhoog je de pakkans van de indringer en dat is nog veel belangrijker dan wat erna komt. Als reactie uitblijft of te lang duurt geeft dat een indringer meer tijd en gelegenheid.
Heb ooit een techneut gehad die head VLAN waarin hij wel mocht, begon te scannen. Werd gebeld door netwerk beheer en ik heb de betreffende techneut duidelijk gemaakt dat hij dat nooit meer mag doen. Daarmee geef je een heel duidelijk signaal af.

[JackBol]

Frogmen schreef op zaterdag 11 februari 2017 @ 12:41:
Zorg er om te beginnen voor dat het in eerste instantie wegvallen van het device wordt gesignaleerd door een stuk netwerk monitoring. Hiermee verhoog je de pakkans van de indringer en dat is nog veel belangrijker dan wat erna komt.

Dingen kunnen ook kapot gaan. Niet alles is een hacker.

Als reactie uitblijft of te lang duurt geeft dat een indringer meer tijd en gelegenheid.

Als er niets te halen valt is er nog minder gelegenheid.

Beveiligen blijft primair.

[Frogmen]

JackBol schreef op zaterdag 11 februari 2017 @ 13:44:
[...]

Dingen kunnen ook kapot gaan. Niet alles is een hacker.

[...]

Als er niets te halen valt is er nog minder gelegenheid.

Beveiligen blijft primair.

Als iets kapot gaat moet je het ook signaleren lijkt mij. Als er niets te halen is hoef je het ook niet te beveiligingen. Sorry maar beetje erg simpel commentaar.

[laurens0619]

Je clientmoet 802.x praten, anders gaat t niet werken. Als dit niet lukt met het domotica spul dan zou ik de utp aansluiting afschermen (slot/kastje?) of helemaal weghalen en jet spul via wifi laten communiceren

[dion_b]

laurens0619 schreef op zaterdag 11 februari 2017 @ 13:51:
Je clientmoet 802.x praten, anders gaat t niet werken. Als dit niet lukt met het domotica spul dan zou ik de utp aansluiting afschermen (slot/kastje?) of helemaal weghalen en jet spul via wifi laten communiceren

Nee WiFi is veiliger

802.1X werkt natuurlijk ook via WiFi, maar kans dat een device dat het niet over Ethernet ondersteunt het wel over WiFi doet is klein, en zonder 802.1X val je terug op niveau van "iedereen die in kan pluggen kan meeluisteren" behalve dat je vrolijk van op de parkeerplaats of anderszins op unsecured locatie mee kan luisteren.

Natuurlijk is WPA2-PSK met voldoende sterke password nog niet gekraakt, maar je kunt nog altijd een vrolijke DoS doen op zelfde de meest potdichte WiFi-netwerk (MAC van AP spoofen, deauth messages sturen...), maar nog riskanter bij dit soort domme client is een rogue honeypot AP opzetten. Dat gaat heel simpel: zet een AP op met zelfde SSID als netwerk waar IoT-device op verbindt, maar geen beveiliging. Geef het een lagere beacon interval. Stuur dan een deauthenticate naar de device, laat het aanmelden op jouw AP (bij voldoende lage beacon interval >50% kans dat het raak is) en vang alle verkeer op. Je weet dan in ieder geval waar het zich aanmeldt en mogelijk nog een stuk meer. Oh, en zolang het met jouw rogue AP verbonden is, is het niet met het netwerk verbonden, ook niet als het een camera is...

Dus nee, dan is een onbeveiligde draadje nog altijd stukken beter

[laurens0619]

dion_b schreef op zaterdag 11 februari 2017 @ 14:44:
[...]

Nee WiFi is veiliger

802.1X werkt natuurlijk ook via WiFi, maar kans dat een device dat het niet over Ethernet ondersteunt het wel over WiFi doet is klein, en zonder 802.1X val je terug op niveau van "iedereen die in kan pluggen kan meeluisteren" behalve dat je vrolijk van op de parkeerplaats of anderszins op unsecured locatie mee kan luisteren.

Natuurlijk is WPA2-PSK met voldoende sterke password nog niet gekraakt, maar je kunt nog altijd een vrolijke DoS doen op zelfde de meest potdichte WiFi-netwerk (MAC van AP spoofen, deauth messages sturen...), maar nog riskanter bij dit soort domme client is een rogue honeypot AP opzetten. Dat gaat heel simpel: zet een AP op met zelfde SSID als netwerk waar IoT-device op verbindt, maar geen beveiliging. Geef het een lagere beacon interval. Stuur dan een deauthenticate naar de device, laat het aanmelden op jouw AP (bij voldoende lage beacon interval >50% kans dat het raak is) en vang alle verkeer op. Je weet dan in ieder geval waar het zich aanmeldt en mogelijk nog een stuk meer. Oh, en zolang het met jouw rogue AP verbonden is, is het niet met het netwerk verbonden, ook niet als het een camera is...

Dus nee, dan is een onbeveiligde draadje nog altijd stukken beter

Sorry Dion ben het toch echt niet met je eens Ik ken je voorkeur voor kabels (en helemaal eens!) maar qua beveiliging binnen deze vraagstelling denk ik toch dat WiFi veiliger is dan non-802.1X utp verbinding.

- Een WiFi WPA2-PSK netwerk "plug" je niet zomaar in, een bereikbare utp poort wel.
- Of je 802.1X of WPA2-PSK over wifi doet maakt praktisch geen verschil qua beveiliging.
- DOS: Je kunt wel iets makkelijker het WiFi signaal verstoren van afstand ja maar tegelijkertijd is de plek publiek dus kunnen mensen ook de kabel eruit trekken. Het was de vraagstelling niet maar ik denk dat het more likely is dat iemand een kabel eruit trekt dan dat mensen deauth signalen gaan sturen.
- Rogue Honeypots zijn geen risico bij beveiligde netwerken. Zolang dat IoT apparaat alleen met een WPA-2 secured SSID verbinding heeft gehad, gaat hij een unsecured Honeypot SSID negeren. Dan nog, als je dit zou lukken dan heb je netwerk toegang tot het apparaat, niet het lan netwerk. Als je netwerk toegang wilt tot het apparaat kun je beter het apparaat van de muur trekken (want hangt publiek) en de SD kaart(?) uitlezen/utp kabel erin stoppen

Dus samengevat, nee een Wifi WPA2-PSK netwerk is qua beveiliging van toegang tot je LAN netwerk STUKKEN veiliger dan een unsecured utp poortje aanbieden.

[ Voor 3% gewijzigd door laurens0619 op 11-02-2017 15:09 ]

[dion_b]

laurens0619 schreef op zaterdag 11 februari 2017 @ 15:06:
[...]


Sorry Dion ben het toch echt niet met je eens Ik ken je voorkeur voor kabels (en helemaal eens!) maar qua beveiliging binnen deze vraagstelling denk ik toch dat WiFi veiliger is dan non-802.1X utp verbinding.

- Een WiFi WPA2-PSK netwerk "plug" je niet zomaar in, een bereikbare utp poort wel.
- Of je 802.1X of WPA2-PSK over wifi doet maakt praktisch geen verschil qua beveiliging.

Jawel: als je de key bij PSK weet, heb je gelijk volledige toegang die alleen herroepen kan worden door de PSK te veranderen.

- DOS: Je kunt wel iets makkelijker het WiFi signaal verstoren van afstand ja maar tegelijkertijd is de plek publiek dus kunnen mensen ook de kabel eruit trekken. Het was de vraagstelling niet maar ik denk dat het more likely is dat iemand een kabel eruit trekt dan dat mensen deauth signalen gaan sturen.

Hangt helemaal af van aard van risico. Vraagstelling leek te gaan om actief kwaadwillenden met netwerkvaardigheden. Die kunnen prima overweg met default tools van een Kali Linux install.

- Rogue Honeypots zijn geen risico bij beveiligde netwerken. Zolang dat IoT apparaat alleen met een WPA-2 secured SSID verbinding heeft gehad, gaat hij een unsecured Honeypot SSID negeren.

Oh nee? Probeer het eens

Een client stuurt een probe request naar een SSID en gaat bij succesvolle respons auth/ass doen, evt encryption komt pas na association om de hoek kijken. Of niet zoals in dit geval.

Dan nog, als je dit zou lukken dan heb je netwerk toegang tot het apparaat, niet het lan netwerk. Als je netwerk toegang wilt tot het apparaat kun je beter het apparaat van de muur trekken (want hangt publiek) en de SD kaart(?) uitlezen/utp kabel erin stoppen

1) je hebt het apparaat van het netwerk af. Als het iets met beveiliging of beheer te maken is dat op zich waardevol.
2) domme IoT-apparaten doen niet veel aan beveiliging of encryptie. Mogelijk kun je toegang to het apparaat krijgen en ofwel z'n functionaliteit overnemen (hee, beveiligingscamera in hotelkamer...) danwel credentials voor het WiFi-netwerk of andere zaken eruit ontfutselen.
3) als je een goed gemonitord netwerk hebt, heb je nu een alarm gegenereerd waar iemand aandacht op gaat richten. Waardoor hij afgeleid is en ander ongein meer kans maakt om onopgemerkt te blijven.

Dus samengevat, nee een Wifi WPA2-PSK netwerk is qua beveiliging van toegang tot je LAN netwerk STUKKEN veiliger dan een unsecured utp poortje aanbieden.

Iets wat je op je luie gemak van buiten de locatie kunt aanvallen is altijd stukken minder veilig dan iets waar je fysiek voor aanwezig moet zijn. Zelfs de minst tech-savvy beveiliger kan aan de bel trekken als iemand zit te kloten aan je kabels. Natuurlijk kun je social engineering toepassen, maar dan kun je net zo goed de WiFi-credentials ontfutselen.

[Qlimaxxx]

Ik lees de ontstane discussie met interesse.

Ondertussen ben ik me wat in gaan lezen over het opzetten van een Radius server in OpenWRT. Toegegeven, wel een stapje hoger dan ik tot nu toe heb gedaan maar met geduld en aandacht moet dat wel lukken lijkt me.

Echter zie ik bij bijna alle tutorials en guides dat het gebruikt wordt om een Radius server te draaien op OpenWrt en/of WPA2 Enterprise security toe te passen. Ik zie nergens hoe ik in OpenWrt portsecurity aan een radius server kan koppelen(alleen een tuto gevonden voor als je een router als supplicant wilt gebruiken). Ben ik hier een aparte switch nodig als authenticator?

Links naar handleidingen zijn uiteraard welkom. Ik gok van niet, maar is het misschien ook mogelijk om dit via web GUI te doen? Klein beetje CLI hier en daar heb ik me wel aan gewaagd, maar ik zie er wel tegenop om zoiets ingewikkelds meteen volledig via CLI in te programmeren.

edit: Mijn doel is dan ook voornamelijk om bij een mislukte authenticatie dynamisch door te routeren naar een VLAN(des noods zonder access of met internet only access). Aangezien het "domme" apparaat in mijn voorbeeldsituatie alleen maar wat gegevens naar internet zou moeten uploaden.

edit2: Ik hoop dat dit dan wel begrepen wordt door een Unifi AP, anders is dit weer een doodlopend weggetje. Ofwel die Unifi moet zelf toegang hebben tot een VLAN en bij bepaalde SSID's ook toegang tot VLAN's geven(liefst met PSK authenticatie) maar bij ontkoppelen of aansluiten op de bridgepoort moet met een mislukte authenticatie dus een daarvoor bestemd VLAN toegewezen worden.

[ Voor 26% gewijzigd door Qlimaxxx op 11-02-2017 16:10 ]

[laurens0619]

dion_b schreef op zaterdag 11 februari 2017 @ 15:38:

Jawel: als je de key bij PSK weet, heb je gelijk volledige toegang die alleen herroepen kan worden door de PSK te veranderen.

Ik zag deze nuance aankomen dus daarom ook het woord praktisch erin
In dit geval ga je waarsch 1 client verbinden met een PSK dus gebruik je de PSK maar op 1 plek. 1 PSK of 1 username/password ontloopt elkaar nauwelijks. Maar ik denk dat we het doel voorbij schieten

Hangt helemaal af van aard van risico. Vraagstelling leek te gaan om actief kwaadwillenden met netwerkvaardigheden. Die kunnen prima overweg met default tools van een Kali Linux install.

De vraagstelling is "Lan-Aansluiting op publieke plek beveiligen" waarmee met LAN een utp aansluiting wordt bedoeld.

Oh nee? Probeer het eens

Een client stuurt een probe request naar een SSID en gaat bij succesvolle respons auth/ass doen, evt encryption komt pas na association om de hoek kijken. Of niet zoals in dit geval.

Incorrect, er zullen vast devices zijn die zich niet netjes gedragen maar over het algemeen zal dit niet werken. Lees ook hier:

Unlike public networks, private networks offer mutual authentication through pre-shared keys, ensuring the user that the AP also knows the key without disclosing the key. An attacker can only attack private networks with an Evil Twin attack based on social engineering.
Social engineering tricks the user instead of his device. In this case the device is tricked to disconnect from the actual AP. The name of the rogue AP might trick the user into connecting with the rogue AP.

1) je hebt het apparaat van het netwerk af. Als het iets met beveiliging of beheer te maken is dat op zich waardevol.
2) domme IoT-apparaten doen niet veel aan beveiliging of encryptie. Mogelijk kun je toegang to het apparaat krijgen en ofwel z'n functionaliteit overnemen (hee, beveiligingscamera in hotelkamer...) danwel credentials voor het WiFi-netwerk of andere zaken eruit ontfutselen.
3) als je een goed gemonitord netwerk hebt, heb je nu een alarm gegenereerd waar iemand aandacht op gaat richten. Waardoor hij afgeleid is en ander ongein meer kans maakt om onopgemerkt te blijven.

[...]

Iets wat je op je luie gemak van buiten de locatie kunt aanvallen is altijd stukken minder veilig dan iets waar je fysiek voor aanwezig moet zijn. Zelfs de minst tech-savvy beveiliger kan aan de bel trekken als iemand zit te kloten aan je kabels. Natuurlijk kun je social engineering toepassen, maar dan kun je net zo goed de WiFi-credentials ontfutselen.

Ik zie nog steeds niet in waarom een onbeveiligde UTP poort op een publieke toegankelijke locatie veiliger is dan een secured WPA2 netwerk. Zat de UTP aansluiting op een beveiligde omgeving (achter toegangspoort oid?) dan was het inderdaad een ander verhaal.

@Qlimaxxx
De switch waar de open utp aansluiting op uitkomt moet 802.1x ondersteunen. Radius server is onderdeel (maakt de switch gebruik van) maar zonder de 802.1x switch kun je geen kant op.

De Unifi kan 802.1x, voor zijn clients. Daarmee beveilig je dus niet de utp kabel die de unifi in/uit gaat. Het stuk daarachter moet je met 802.1x beveiligen.
Ik vraag mij nu trouwens wel af hoe het accesspoint zelf zich dan gaat aanmelden bij het netwerk. AFAIK kan een unifi namelijk zichzelf niet authenticeren maar slechts doorgeefluik voor clients.


Welk apparaat zou je als switch willen inzetten?

[ Voor 9% gewijzigd door laurens0619 op 11-02-2017 16:52 ]

[dion_b]

laurens0619 schreef op zaterdag 11 februari 2017 @ 16:37:
[...]

Ik zag deze nuance aankomen dus daarom ook het woord praktisch erin
In dit geval ga je waarsch 1 client verbinden met een PSK dus gebruik je de PSK maar op 1 plek. 1 PSK of 1 username/password ontloopt elkaar nauwelijks. Maar ik denk dat we het doel voorbij schieten

Eh, een AP voor een dedicated PtP verbinding naar een of ander legacy apparaat... ja idd

[...]
[...]

Incorrect, er zullen vast devices zijn die zich niet netjes gedragen maar over het algemeen zal dit niet werken. Lees ook hier:

Een up-to-date apparaat met mainstream OS doet dit idd niet, maar wie zegt dat $dom_embedded_ding ook zo snugger? Heb hier even getest met twee telefoons. Mijn huidige Android 6 vertikt het idd om te verbinden met netwerk dat andere security heeft dan wat hij verwacht, maar een oudje met Android 2.1 erop deed dat wel vrolijk. Nu is kans dat TS een oude Android telefoon eraan gaat hangen klein, maar veel embedded meuk draait software van ongeveer die leeftijd. Ik zou het minimaal controleren voor ik iets eraan hing. En dit is nog maar de meest voor de hand liggende vulnerability...

[...]

Ik zie nog steeds niet in waarom een onbeveiligde UTP poort op een publieke toegankelijke locatie veiliger is dan een secured WPA2 netwerk. Zat de UTP aansluiting op een beveiligde omgeving (achter toegangspoort oid?) dan was het inderdaad een ander verhaal.

Daar hebben ze dit soort ding voor uitgevonden:
http://www.rjlockdown.com/jacklockpage.html


Verder is WiFi een veel uitgebreider protocol met een veel grotere attack surface, met wederom belangrijkste punt dat je niet eens physical access nodig hebt om erop los te gaan. Het is gemakkelijk en het is aanzienlijk veiliger dan het ooit was, maar het is nadrukkelijk niet iets waar je vanuit security voor kiest.

@Qlimaxxx
De switch waar de open utp aansluiting op uitkomt moet 802.1x ondersteunen. Radius server is onderdeel (maakt de switch gebruik van) maar zonder de 802.1x switch kun je geen kant op.

De Unifi kan 802.1x, voor zijn clients. Daarmee beveilig je dus niet de utp kabel die de unifi in/uit gaat. Het stuk daarachter moet je met 802.1x beveiligen.
Ik vraag mij nu trouwens wel af hoe het accesspoint zelf zich dan gaat aanmelden bij het netwerk. AFAIK kan een unifi namelijk zichzelf niet authenticeren maar slechts doorgeefluik voor clients.

Ben nu thuis en zit in mijn UniFi (5.0.7.3093) config te rommelen - ik zie inderdaad geen 802.1X mogelijkheden om de AP's zelf over Ethernet te laten authenticeren. Enige wat in de buurt komt is de "Remote User VPN"-optie, maar dat lijkt me veel te complex voor de simpele use case hier.

Ik vind trouwens ook een - onbeantwoorde - feature request hiervoor, dus heb er redelijk hard hoofd in dat dit op korte termijn geimplementeerd gaat worden
https://community.ubnt.co...-the-Switch/idi-p/1545865

[Thralas]

802.1X is een grote wassen neus is in het geschetste scenario, want 'klassiek' 802.1X(-2003,2004 volgens het internet) authenticeert de client slechts eenmalig om het poortje (en/of VLAN) te enablen, verder is er geen per-frame authentication of encryption.

Ofwel, de superhacker uit het scenario (ga nog even na hoe realistisch dat is, en of je niet veel reëelere risico's hebt) hangt er een transparante bridge tussen en weg is de 'security'.

Dat is blijkbaar verholpen met 802.1AE/MACsec (bonus: een versleutelde link), maar bv. Linux ondersteunt het pas vanaf 4.6. Laat zich dan wel raden in hoeverre dat in allerlei andere apparatuur is geimplementeerd.

Met andere woorden, ik denk dat laurens0619 gelijk heeft dat WPA2-PSK (of WPA2-Enterprise) een 'betere' keus is tov. 802.1X. En de kabel fysiek afschermen lijkt me een pragmatischere oplossing dan alles volhangen met 802.1X met IPsec bolted-on (of MACsec als je mazzel hebt).

[laurens0619]

@dion Bah niet netjes van android 2.1 , maar eens dat je je iot client dan daar wel even op wil testen want dat spul is idd niet altijd even ontwikkeld.

De attack surface van wifi is wel groter maar de publieke lan poort die er tegenover staat is gewoon een nare "vulnerabity"

Overigens vrij aannemelijk dat de TS sowieso al een WIfi netwerk opzet (want hij ging een unifi ophangen?) dus de kwetsbaarheid is er al, die zal nauwelijks groter worden.

@thrales wist ik niet, tijd om het spul thuis eens te implementeren

[dion_b]

laurens0619 schreef op zondag 12 februari 2017 @ 03:44:
[...]

Overigens vrij aannemelijk dat de TS sowieso al een WIfi netwerk opzet (want hij ging een unifi ophangen?) dus de kwetsbaarheid is er al, die zal nauwelijks groter worden.

Hij ging een UniFi ophangen en use case was juist om draadje voor die UniFi te beschermen

@thrales wist ik niet, tijd om het spul thuis eens te implementeren

Idd. Als ik toch die RADIUS-server in gebruik ga nemen zou het kleine moeite moeten zijn