7
802.1x und Netzwerksicherheit
Moin,
kleine Warnung im Vorfeld: es ist relativ viel Text
Im Zuge einer Einstufung nach den betroffenen Sektoren und Firmengröße, fallen wir unter NIS2 Regelungen. Auch wenn wir schon im Vorfeld viele Maßnahmen umgesetzt, die die IT-Sicherheit enorm erhöht haben, möchte ich weitere Maßnahmen prüfen und testen bevor NIS2 im Oktober in DE "live" geht.
Kurzinfo zur Infrastruktur: wir haben einen NPS und eine eigene interne CA. Alle AD-Userkonten sowie Windows-Client und Server haben entsprechende Zertifikate. Aktuell werden die Computerzertifikate für Wireless-Authentifizierung verwendet, wobei dieses über RADIUS stattfindet.
Meine Überlegung ist das Netzwerk an den Schnittstellen zu den Endgeräten (Access-Switche) mittels 802.1x abzusichern.
Hierbei wird unterschieden zwischen:
Windows-Clients habe ich bereits getestet und mit entsprechender Policy auf dem NPS funktioniert das wie gewünscht. Kopierer können 802.1x und können auch mit Zertifikaten ausgestattet werden. Bei den wenigen Druckern, die kein 802.1x sprechen, würde ich über Port Security gehen und nur die eine MAC des Gerätes zulassen. Abgesehen davon sind die Kopierer/Drucker im eigenen VLAN ohne DHCP, da ist das mögliche Risiko sehr gering.
Bei den Access Points ist es etwas unschön (Sophos), da diese kein 802.1x bzw. EAP-TLS beherrschen. Ein Wechsel auf einen anderen Hersteller kommt (aktuell) nicht in Frage. Hier werde ich vermutlich die APs in ein eigenes VLAN setzen und MAC basierte Port Security nutzen.
Für die IP-Telefone ist das noch ein Stückchen komplexer. Hier gibt es die Möglichkeit MAC-Authentifizierung wie hier beschrieben. Also für jedes IP-Telefon wird ein AD-Userkonto erstellt mit MAC-Adresse als Benutzername und Passwort. Problem ist dabei, dass das Passwort im Klartext übergeben wird. Auf Seiten der AD muss man dann entsprechend die Option "Kennwort mit umkehrbarer Verschlüsselung speichern" aktivieren. Das andere Problem ist auf dem NPS/RADIUS (Microsoft). Hier ist im Standard keine passende unverschlüsselte Authentifizierung für die IP-Telefone vorhanden. Selbst PAP/SPAP klappt nicht, die Meldung ist entsprechend IAS_INVALID_AUTH_TYPE
Nach langer Suche bin ich auf diesen Artikel gestoßen und habe dann die MD5-Registry Einträge hinzugefügt. Nun sehe ich zwar IAS_SUCCESS Meldungen, trotzdem erscheint der Netzwerkport auf dem Switch als Unauthorized. Das muss ich noch weiter prüfen, habe aber die "billigen" Access Switche in Verdacht. Zur Not wird das wie bei den APs umgesetzt ist aber unkritisch, da das Voice-VLAN nur mit der TK-Anlage sprechen darf.
Habe ich irgendwas vergessen oder an einer Stelle verkehrt geplant/gedacht?
Was sind Eure Erfahrungen bei diesem Thema und welche Methoden habt Ihr umgesetzt?
kleine Warnung im Vorfeld: es ist relativ viel Text
Im Zuge einer Einstufung nach den betroffenen Sektoren und Firmengröße, fallen wir unter NIS2 Regelungen. Auch wenn wir schon im Vorfeld viele Maßnahmen umgesetzt, die die IT-Sicherheit enorm erhöht haben, möchte ich weitere Maßnahmen prüfen und testen bevor NIS2 im Oktober in DE "live" geht.
Kurzinfo zur Infrastruktur: wir haben einen NPS und eine eigene interne CA. Alle AD-Userkonten sowie Windows-Client und Server haben entsprechende Zertifikate. Aktuell werden die Computerzertifikate für Wireless-Authentifizierung verwendet, wobei dieses über RADIUS stattfindet.
Meine Überlegung ist das Netzwerk an den Schnittstellen zu den Endgeräten (Access-Switche) mittels 802.1x abzusichern.
Hierbei wird unterschieden zwischen:
- Windows-Client
- Kopierer
- Drucker
- Access-Point
- IP-Telefon
Windows-Clients habe ich bereits getestet und mit entsprechender Policy auf dem NPS funktioniert das wie gewünscht. Kopierer können 802.1x und können auch mit Zertifikaten ausgestattet werden. Bei den wenigen Druckern, die kein 802.1x sprechen, würde ich über Port Security gehen und nur die eine MAC des Gerätes zulassen. Abgesehen davon sind die Kopierer/Drucker im eigenen VLAN ohne DHCP, da ist das mögliche Risiko sehr gering.
Bei den Access Points ist es etwas unschön (Sophos), da diese kein 802.1x bzw. EAP-TLS beherrschen. Ein Wechsel auf einen anderen Hersteller kommt (aktuell) nicht in Frage. Hier werde ich vermutlich die APs in ein eigenes VLAN setzen und MAC basierte Port Security nutzen.
Für die IP-Telefone ist das noch ein Stückchen komplexer. Hier gibt es die Möglichkeit MAC-Authentifizierung wie hier beschrieben. Also für jedes IP-Telefon wird ein AD-Userkonto erstellt mit MAC-Adresse als Benutzername und Passwort. Problem ist dabei, dass das Passwort im Klartext übergeben wird. Auf Seiten der AD muss man dann entsprechend die Option "Kennwort mit umkehrbarer Verschlüsselung speichern" aktivieren. Das andere Problem ist auf dem NPS/RADIUS (Microsoft). Hier ist im Standard keine passende unverschlüsselte Authentifizierung für die IP-Telefone vorhanden. Selbst PAP/SPAP klappt nicht, die Meldung ist entsprechend IAS_INVALID_AUTH_TYPE
Nach langer Suche bin ich auf diesen Artikel gestoßen und habe dann die MD5-Registry Einträge hinzugefügt. Nun sehe ich zwar IAS_SUCCESS Meldungen, trotzdem erscheint der Netzwerkport auf dem Switch als Unauthorized. Das muss ich noch weiter prüfen, habe aber die "billigen" Access Switche in Verdacht. Zur Not wird das wie bei den APs umgesetzt ist aber unkritisch, da das Voice-VLAN nur mit der TK-Anlage sprechen darf.
Habe ich irgendwas vergessen oder an einer Stelle verkehrt geplant/gedacht?
Was sind Eure Erfahrungen bei diesem Thema und welche Methoden habt Ihr umgesetzt?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 63194770065
Url: https://administrator.de/contentid/63194770065
Ausgedruckt am: 21.11.2024 um 13:11 Uhr
7 Kommentare
Neuester Kommentar
Moin @DerMaddin
wäre es nicht angebracht, auch die IP-Telefonie in ein separates VLAN zu legen, als komplett an allen Rechnern vorbei? Die Telefonie hat ja mit dem Computerkram, AD etc. nix zu tun, oder sind das „Windows“-Telefone?
Kreuzberger
wäre es nicht angebracht, auch die IP-Telefonie in ein separates VLAN zu legen, als komplett an allen Rechnern vorbei? Die Telefonie hat ja mit dem Computerkram, AD etc. nix zu tun, oder sind das „Windows“-Telefone?
Kreuzberger
Hallo,
auf jeden Fall mit VLANs und Firewall-Regeln arbeiten. Nichts aus einem VLAN rauslassen, was nicht benötigt wird.
Drucker sind klar.
Bei VOIP-Telefonen ebenso, eigenes VLAN, Firewall-Regel dicht, nur Kommunikation mit der TK.
Bei den APs wird es etwas doofer, da über den Uplink zum Switch ja nicht nur der AP sondern auch alle Clients laufen. Mit Port-Security kommst du da nicht weit.
Wenn du Sophos-APs hast, werden die von einer Sophos-Firewall gemanaged?
Dann hier ein eigenes VLAN erstellen, mit dem die APs zu einem eigenen (VLAN-)Interface der Firewall verbunden sind, Regelwerk dicht machen. Die WLANs dann in ein eigenes VLAN taggen oder Tunnel. Wenn Central-managed ähnlich, dann müssen die halt aber zu Central dürfen.
auf jeden Fall mit VLANs und Firewall-Regeln arbeiten. Nichts aus einem VLAN rauslassen, was nicht benötigt wird.
Drucker sind klar.
Bei VOIP-Telefonen ebenso, eigenes VLAN, Firewall-Regel dicht, nur Kommunikation mit der TK.
Bei den APs wird es etwas doofer, da über den Uplink zum Switch ja nicht nur der AP sondern auch alle Clients laufen. Mit Port-Security kommst du da nicht weit.
Wenn du Sophos-APs hast, werden die von einer Sophos-Firewall gemanaged?
Dann hier ein eigenes VLAN erstellen, mit dem die APs zu einem eigenen (VLAN-)Interface der Firewall verbunden sind, Regelwerk dicht machen. Die WLANs dann in ein eigenes VLAN taggen oder Tunnel. Wenn Central-managed ähnlich, dann müssen die halt aber zu Central dürfen.
Zitat von @kreuzberger:
wäre es nicht angebracht, auch die IP-Telefonie in ein separates VLAN zu legen, als komplett an allen Rechnern vorbei?
wäre es nicht angebracht, auch die IP-Telefonie in ein separates VLAN zu legen, als komplett an allen Rechnern vorbei?
Aktuell bekommen die IP-Telefone via LLDP-MED das Voice-VLAN zugewiesen. Wenn ich das 802.1x Problem nicht lösen kann, dann werden die definitiv in ein Port basiertes (untagged) VLAN gehen. Freie Switch-Ports sind kein Problem.
Zitat von @DerSchorsch
Bei den APs wird es etwas doofer, da über den Uplink zum Switch ja nicht nur der AP sondern auch alle Clients laufen. Mit Port-Security kommst du da nicht weit. Wenn du Sophos-APs hast, werden die von einer Sophos-Firewall gemanaged?
Bei den APs wird es etwas doofer, da über den Uplink zum Switch ja nicht nur der AP sondern auch alle Clients laufen. Mit Port-Security kommst du da nicht weit. Wenn du Sophos-APs hast, werden die von einer Sophos-Firewall gemanaged?
Die Kommunikation zw. AP und Sophos Firewall (dient als WLC) ist sowieso getunnelt und verschlüsselt von daher ist das kein Thema. Auf dem Switch wird nur die MAC-Adresse des APs erkannt. Aktuell sind die APs im Management-VLAN, da würde ich vermutlich ein neues dafür erstellen.
Moin,
bei Benutzername = Passwort scheitert es oft daran, dass dieses nicht der PW-Richtlinie des AD entspricht.
D.h. diese Accounts benötigen eine Ausnahme.
Danach dann, wie andere bereits vorgeschlagen, per Policy in ein eigenes VLAN.
Gruß und viel Erfolg
bei Benutzername = Passwort scheitert es oft daran, dass dieses nicht der PW-Richtlinie des AD entspricht.
D.h. diese Accounts benötigen eine Ausnahme.
Danach dann, wie andere bereits vorgeschlagen, per Policy in ein eigenes VLAN.
Gruß und viel Erfolg
da diese kein 802.1x bzw. EAP-TLS beherrschen.
Du meinst sicher das sie auf dem Kupfer Port keinen 802.1x Client supporten um sich an einem .1x gesicherten Port zu authentisieren, richtig?WPA-Enterprise mit .1x im WLAN sollten sie aber schon supporten, oder? Obwohl bei solchen Exoten im WLAN Bereich weiss man ja nie. Warum nan sich bei einem Firewall Hersteller APs beschafft die keinen .1x Kupfer Client und das bei einem Firewall Hersteller wissen wohl auch nur die selber...
Hier werde ich vermutlich die APs in ein eigenes VLAN setzen und MAC basierte Port Security nutzen.
Was anderes wird dir dann auch nicht übrig bleiben, was dann aber problemlos klappt... 
Die Kommunikation zw. AP und Sophos Firewall (dient als WLC)
Mit der antiken Anbindungsmethode ist das dann aber auch kein Thema. Da du dann keine MSSIDs bzw. VLANs mehr siehst reicht es die AP Mac Adresse per MAB zu authentisieren und gut. Hast ja wie gesagt eh keine Wahl.Für die IP-Telefone ist das noch ein Stückchen komplexer.
Mit anderen Worten deine Telefone supporten auch, wie bereits die APs, keinen .1x Client am Kupfer, ergo können dann auch weder mit .1x User/Pass noch mit Zertifikaten versorgt werden?? Bei solcher Hardware die ebenso schlecht mit Security Features ausgestattet ist wird dir dann, wie analog bei den APs, nur MAB übrig bleiben. Da hast du ja dann keine Wahl.
trotzdem erscheint der Netzwerkport auf dem Switch als Unauthorized.
Kann passieren wenn Endgeräte das nicht supporten weil es mittlerweise als unsicher gilt. Siehe dazu auch HIER.habe aber die "billigen" Access Switche in Verdacht.
Das wäre aber sehr sehr außergewöhnlich wenn die das uralte MD5 benutzen. In den meisten Switches ist das in den .1x Port Settings konfigurierbar wie im obigen Thread bei Cisco. Der Default steht aber seit Jahrzehnten nicht mehr auf MD5.Habe ich irgendwas vergessen oder an einer Stelle verkehrt geplant/gedacht?
Nein alles richtig gedacht...im Rahmen deiner Hardware Limitierungen. Grobe Port Security Grundlagen und weiterführende Links, wie immer, auch HIER.
@aqui Ja klar, geht um AP Ethernet-Verbindungen. WPA2-Enterprise läuft ja bereits mit dot1x. MD5 ist schon lange "raus" aber die Lösung wie im Beitrag beschrieben, scheint ja grundsätzlich zu funktionieren. Immerhin ist ein IAS_SUCCESS vorhanden. Die "Billlig-Switche" (ich trau mich nicht einmal den Hersteller zu nennen) sind sehr rudimentär ausgestattet unter 802.1x, daher haben wir zu Testzwecken was "ordentliches" bestellt und dann teste ich weiter.
Beispiele von "ordentlicher" Hardware findest du u.a. hier.
Wir sind dann mal gespannt was deine "ordentliche" Hardware dann leistet... 😉
Wir sind dann mal gespannt was deine "ordentliche" Hardware dann leistet... 😉
