dermaddin
Goto Top

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-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?

Content-Key: 63194770065

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

Printed on: July 19, 2024 at 10:07 o'clock

Member: kreuzberger
kreuzberger Mar 14, 2024 at 09:16:17 (UTC)
Goto Top
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
Member: DerSchorsch
DerSchorsch Mar 14, 2024 at 09:26:22 (UTC)
Goto Top
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.
Member: DerMaddin
DerMaddin Mar 14, 2024 at 09:51:52 (UTC)
Goto Top
Zitat von @kreuzberger:

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?

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.
Member: ElmerAcmeee
ElmerAcmeee Mar 14, 2024 at 09:56:30 (UTC)
Goto Top
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
Member: aqui
aqui Mar 14, 2024 updated at 11:56:54 (UTC)
Goto Top
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... face-sad
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... face-wink
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?? face-sad
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.
Member: DerMaddin
DerMaddin Mar 14, 2024 at 13:06:01 (UTC)
Goto Top
@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.
Member: aqui
aqui Mar 14, 2024 at 14:49:01 (UTC)
Goto Top
Beispiele von "ordentlicher" Hardware findest du u.a. hier.
Wir sind dann mal gespannt was deine "ordentliche" Hardware dann leistet... ­čśë