802.1x icm Mac-adressen / Radius

[Rotty]

Om het netwerk wat beter te beschermen ben ik aan het broeden op een aantal maatregelen. In dit geval heb ik het voornamelijk over het voorkomen dan vreemde apparatuur op het netwerk geprikt wordt. Of, als dit beurt dat ze op een seperaat VLAN komen.

Ik zoek de oplossing in de richting van authenticatie via 802.1x. Ik wil een oplossing die het minst mogelijk onderhoud behoeft. Ik wil dus niet met port security gaan werken want telkens als een werkstation of thinclient verhuist moet je op de switch dingen aan gaan passen.

Het mooiste lijkt mij een database in een radius server van alle bekende macadressen en elke switch checkt via radius of het device bekend is.

En ja ik weet mac adressen zijn te spoofen dus e.e.a. kan veiliger (wellicht met certificaten, maar dat kan ik helaas niet gebruiken) en dit is voor mijn situatie in eerste instantie afdoende...

Heeft iemand een dergelijke oplossing ? Welke producten gebruik je ? Ik heb even met een half oog naar Microsoft IAS gekeken maar ik zie niet dat ik daar mac adressen in kwijt kan... ?

[Leon T]

Hoe groot en divers is je netwerk, wat voor een (netwerk)apparatuur heb je er staan en hoe gecentraliseerd is je huidige infrastructuur?

[Kabouterplop01]

in MS IAS kun je mac adressen kwijt hoor; je moet maar eens kijken naar de Radius attributen.
Je kunt ook eens kijken naar Packetfence... of secure ACS

[Rotty]

Leon T schreef op zondag 19 april 2009 @ 11:39:
Hoe groot en divers is je netwerk, wat voor een (netwerk)apparatuur heb je er staan en hoe gecentraliseerd is je huidige infrastructuur?

Momenteel is het behoorlijk versnipperd. zo'n 2400 clients verdeeld over 2 grote en eens stuk of 20 kleinere locaties. De kleinere locaties zijn allemaal met glas verbonden aan de centrale locatie (waar ook de dc's staan). De switches/routers zijn veelal cisco maar af en toe nog wel wat oude 3com die er langzaam uitgaan.

Het hoeft wat mij betreft ook niet in één week helemaal voor elkaar te zijn ik wil langzaam naar deze oplossing toegroeien. Dus switch voor switch zeg maar (mits de switch het ondersteund).

[Leon T]

Dan zou ik eens kijken naar Qmanage. Best wel leuk speelgoed

[Bl@ckbird]

Voor strikt 802.1x authenticatie kun je idd kijken naar Microsoft IAS of Cisco ACS.
Wil je ook antivirus zaken enz. enforcen dan kan je kijken naar Cisco NAC of Microsoft NAP.

[Flyduck]

Als je geen certificaten gaat gebruiken dan wordt het wel wat lastig. Gebruikers moeten dan handmatig een MD5 password invoeren om naar het juiste VLAN te switchen.
Mooiste is toch echt om certificaten te gebruiken. Deze laat je eerst automatisch uitrollen, en later gebruik je ze om automatisch te authenticeren op de switchport.

[alt-92]

Flyduck schreef op dinsdag 21 april 2009 @ 16:05:
Als je geen certificaten gaat gebruiken dan wordt het wel wat lastig. Gebruikers moeten dan handmatig een MD5 password invoeren om naar het juiste VLAN te switchen.

Die MD5 hash kun je ook via je install imaging toevoegen uiteraard.
Of zelfs in je startup scripts binnen je staging netwerk vóórdat je ze op de enduser lokatie neerzet.

[ Voor 13% gewijzigd door alt-92 op 21-04-2009 20:16 ]

[JackBol]

Rotty schreef op zondag 19 april 2009 @ 10:16:
Heeft iemand een dergelijke oplossing ? Welke producten gebruik je ? Ik heb even met een half oog naar Microsoft IAS gekeken maar ik zie niet dat ik daar mac adressen in kwijt kan... ?

Al je apparatuur als computer in de AD registreren met het bijbehorende mac adres. Dat werkt als een zonnetje.

Houd er wel rekening mee dat je voor 802.1x een EAP-TLS tunnel moet opzetten en dat je daarvoor een certificaat nodig hebt. Als je IAS gebruikt kan je met erg veel pijn en moeite een certificaat stand-alone genereren met openssl ofzo, maar veruit het makkelijkste is om een CA uit te rollen. Ik kan je dat dan ook sterk aanraden.

[kell.nl]

Voor PC's die in jouw eigen beheer zijn, kun je inderdaad 802.1X gebruiken. Als je Windows XP of Windows Vista draait, dan kun je ingebouwde 802.1X supplicant gebruiken. Je hebt hier een aantal mogelijkheden: Machine authenticatie, user authenticatie of beide. Machine authenticatie gebruikt de "credentials" van de client zoals die in AD bekend zijn. User authenticatie gebruikt de user credentials.
Beide zijn als "single sign-on" mogelijk, wat betekent dat de gebruiker niet meerdere malen zijn wachtwoord hoeft in te tikken. De user credentials die de gebruiker opgeeft tijdens het inloggen in Windows worden dan gebruikt.

Ook heb je een aantal mogelijkheden voor welk protocol je wilt gebruiken. Het gemakkelijkste is EAP-MD5, maar dat is sinds Windows Vista (en ik geloof ook in XP SP3, maar weet ik niet zeker) en Windows 2008 (dus ook NPS) bij default uitgeschakeld, aangezien het niet zo veilig is als andere methodes. Voor "wired" is het niet zo heel erg, sinds het een stuk moeilijker is om paketten te onderscheppen, maar voor wireless is het erger.
Ook met EAP-MD5 is het nodig om alle wachtwoorden in AD op te slaan met "reversible encryption", wat veiligheids risico's met zich meeneemt. Ook als dit nog niet aanstaat, betekent dat elk wachtwoord ge-reset moet worden.

Een veiligere optie is PEAP of EAP-TTLS. Je hebt dan wel een server-side certificaat nodig, maar geen certificaat op de client. Als al je clients lid zijn van je AD domein, dan is het gemakkelijk genoeg om het certificaat te "installeren" op elke client dmv group policies.

Je kan ook EAP-TLS gebruiken, maar dan hebben je clients ook een certificaat nodig. Aangezien de voordelen van EAP-TLS boven PEAP niet echt groot zijn, haal je je over het algemeen alleen meer werk op de hals.

In de meeste gevallen zou ik persoonlijk PEAP gebruiken in een Microsoft omgeving. "out of the box" ondersteund in de supplicants en in IAS/NPS, makkelijk te implementeren en toch veilig.

Als je Windows XP clients hebt, dan zijn er een aantal dingen waar je op moet letten met de ingebouwde supplicant. Als je alleen user authenticatie (geen machine authenticatie) doet OF als je beide doet, maar je wijst verschillende VLANs toe, dan kun je problemen krijgen met login scripts en roaming profiles. De supplicant wacht namelijk niet op het verkrijgen van een (nieuw) IP adres voordat het de controle teruggeeft aan Windows, die dan probeert het login-script en roaming profile te laden.

Voor clients die geen 802.1X ondersteunen (zoals printers), kun je inderdaad MAC-auth gebruiken (MAC-auth is geen 802.1X). Omdat MAC-auth inderdaad gemakkelijk te spoofen is, zou ik je aanraden die clients in een aparte VLAN te zetten met beperkte mogelijkheden (wat leuke ACL's tussen de VLAN's bijvoorbeeld).
Als je inderdaad de default IAS of NPS gebruikt, dan zul je de MAC adressen als gebruikers moeten aanmaken in AD. Het wachtwoord voor deze "gebruikers" is vaak of de RADIUS shared secret, of ook het MAC adres. Ik weet even niet wat het is bij Cisco spullen.
Als je de MAC adressen aanmaakt in je productie domein/forest, let er dan wel op dat bij default deze gebruikers rechten hebben (zijn lid van "domain users"). Als daarbij het wachtwoord gemakkelijk te raden valt (als het ook het MAC adres is), dan is het voor een kwaadwillend persoon al een stuk gemakkelijker.
Het beste is als de MAC adressen op z'n minst in ander domein, zoniet forest worden aangemaakt. Is dat niet mogelijk, zorg er dan voor dat ze van geen enkele groep lid zijn (of eentje die je expliciet "denied" of belangrijke resources)

[Rotty]

Bedankt voor alle input ik kan even verder met bedenken en testen hoe ik dit ga doen...

[dabutcha76]

Leon T schreef op maandag 20 april 2009 @ 17:12:
Dan zou ik eens kijken naar Qmanage. Best wel leuk speelgoed

Seconded, dat Qmanage kan ook cross-vendor met hardware omgaan, dus zowel je Cisco's als je 3com's vanuit hetzelfde apparaat. Ik zou die gasten es bellen, zitten gewoon in NL.