Sicherheitslücke beim Umstieg von einzelnen AP zum WLC

[DirkK]

Hallo,

bis vor kurzem habe ich die vier AccessPoints hier im Haus manuell (teilweise auch mit Gruppenkonfigurationen) gemanaged.
Bei der Umstellung vom zentralen 1724 auf einen 1784VA habe ich auch gleich die WLC-Option dazu genommen, um die AP's dann auch zentral, einheitlich und damit auch sicherer managen zu können.

Ich habe also die Konfiguration, und u.a. auch die Stationentabelle in den WLC eingetragen und hierbei nicht mehr benötigte MAC-Adressen (z.B. von Besuchern) bereinigt, da ich die in Zukunft bei Bedarf mit der PublicSpot Option bedienen möchte.
Diese bereinigte Stationstabelle habe nun in den WLC eingetragen und in allen AP's alle Interfaces von "Basisstation" auf "Managed" umgestellt.
Bei den hausinternen Clients funktioniert soweit auch alles (bis auf sporadische Performance-Probleme mit Apple-Geräten).

Gestern kam dann ein Bekannter zu Besuch, dessen MAC ich eben aus dem WLC gestrichen hatte und der eigentlich einen PublicSpot-Zugang hätte bekommen sollen.
Komischerweise konnte er sich aber sofort an das normale WLAN anmelden. Erst als ich die Stationstabellen in den einzelnen AP's gelöscht hatte, hatte er keinen Zugang zum normalen WLAN mehr.

Ist das so gewollt? Ich halte das für sehr bedenklich, denn nicht umsonst stellt man ja auf ein zentrales WLAN-Management um, um solche Individualkonfigurationen von AP's zu konsolidieren.

Für mich stellt sich nun v.a. die Frage, was ich sonst noch aus der alten Konfiguration der AP's löschen muss, damit ich hier nicht ungewollt offene Türen zurücklasse?
Ich wollte die alte Konfig in den AP's eigentlich nicht anfassen, für den Fall, dass es zu Problemen kommt und ich schnell zurück muss und dachte das Umstellen von "Basisstation" auf "Managed" setzt die gesamte lokale WLAN-Konfiguration außer Kraft.

Beste Grüße
Dirk

[MoinMoin]

Moin, moin!

Eigentlich solltest die die APs komplett zurücksetzen und deren Konfiguration über den WLC ausrollen.

Ob es allerdings gewollt ist, die Zugangsliste vom AP für ein vom Controller verwaltetes WLAN zu verwenden, halte ich zumindest für zweifenhaft.

Ciao, Georg

[alf29]

Moin,

ja, das ist 'works as designed', die Access-Liste des WLCs wird den gemanagten APs per RADIUS untergeschoben, und auch im Standalone-Betrieb kann man sowohl mit einer lokalen Tabelle UND mit RADIUS arbeiten.

Gruß Alfred

[DirkK]

Hallo Alfred,

Danke für die Erklärung! Irgendwie habe ich leider weder in der Dokumentation, noch in dem Konfig-Dialog einen entsprechenden Hinweis gesehen.

Sollte man vielleicht mal anregen! Ich finde es sicherheitstechnisch jedenfalls nicht ganz unproblematisch, wenn das nicht klar herausgestellt wird.

Beste Grüße
Dirk

[DirkK]

Argh!!

Und noch ein sicherheitskritisches Problem:
Bei der Spalte SSID-Muster bei den Stationsregeln scheint es auch nicht sauber nach der Dokumentation zu laufen.
Ich habe z.B. 3 WLAN's

• WLAN
  WLANgast
  WLANpublic

Geräte, denen ich jetzt erlaube sich an WLAN anzumelden werden auch in den beiden anderen WLAN-Netzen akzeptiert.
Jetzt heisst es zwar man könne Wildcards verwenden, wenn ich bei den Stationen jetzt "WLAN*" eingetragen hätte, würde ich das Verhalten ja erwarten, habe ich aber nicht und trotzdem können die sich munter an die anderen beiden WLAN's anmelden.

Finde ich alles andere als gut!

Grüße
Dirk

[ecox]

Hallo Dirk,

kurze Frage, hast du schonmal in Betracht gezogen in der Konstellation mit VLANs zu arbeiten, ich habe mir an solchen Szenarios zwecks DHCP, PublicSpot usw schon die Zähne ausgebissen, seit ich mit VLANs arbeite, stellt das alles kein Problem mehr dar.

Grüße

[alf29]

Lieber Dirk,

bitte nicht hier herumpoltern, sondern Informationen liefern, anhand derer man vielleicht Dein Problem nachvollziehen kann...ich habe auch so schon genug Themen um die Ohren und wenn man so angesprochen wird, dann erhöht das die Wahrscheinlichkeit, daß ich Dein Posting einfach wegdrücke.

Was sagt ein WLAN-ACL-Trace? Damit kannst Du Dir während des Einbuchens des Clients anschauen, welche Regel auf die Kombination von SSID und Client-MAC gematcht hat.

Gruß Alfred

[alf29]

Moin,

ich habe mir jetzt mal die Mühe gemacht und das ausprobiert: Die SSID bei mir lautet 'LCS-EN-AArnold-450Test', definiere ich eine Regel der Form:

MAC-Address-Pattern SSID-Pattern Name WPA-Passphrase Tx-Limit Rx-Limit VLAN-Id Comment
================================================================-----------------------------------------------------------------------------------------------------------------------------------------------------------------
30144a112d68 LCS-EN 0 0 0

dann kommt der Client nicht rein:

[WLAN-ACL] 2016/02/24 09:31:25,030
Client 30:14:4a:11:2d:68 SSID LCS-EN-AArnold-450Test not found in ACL list

Ändere ich das SSID-Pattern auf 'LCS-EN*', dann kommt der Client rein:

[WLAN-ACL] 2016/02/24 09:34:00,688
Client 30:14:4a:11:2d:68 SSID LCS-EN-AArnold-450Test found in ACL list

genauso wie wenn ich das SSID-Pattern auf die voll ausgeschriebene SSID ändere. Was bei Dir passiert, kann ich ohne weitergehende Traces und Informationen zur Konfig nicht sagen. Hast Du eventuell weitere Regeln in der Tabelle, die immer matchen, z.B. eine Regel mit leerem SSID-Pattern, das ist äquivalent zu einem '*'? Ist der MAC-Filter auf der SSID überhaupt angeschaltet?

Gruß Alfred

[DirkK]

Hallo,

war die letzte Woche beruflich unterwegs, deswegen konnte ich nicht antworten.

@ecox: ja VLAN's hatte ich schon mal überlegt, aber irgendwie hatte das mit dem zentralen Switch zusammen nicht funktioniert. Ist aber schon eine Weile her. Da er nun auch quasi ersetzt ist ist das vielleicht nochmal eine Möglichkeit, die ich nochmal prüfen sollte.

@alf: Das war doch kein Herumpoltern ...
Gerne würde ich es nachvollziehbar machen, aber das scheint nicht mehr so einfach zu sein... Nachdem ich zurück gekommen bin konnte sich ein iPhone an einem AP überhaupt nicht mehr am WLAN anmelden daraufhin habe alle AP's und den WLC durchgebootet. Danach ging die Anmeldung dieses iPhones wieder und das Problem, dass sich Clients in andere, als das erlaubte WLAN einbuchen ist aktuell nicht mehr vorhanden.

Nutzer haben während meiner Abwesenheit berichtet, dass Geräte auch eine fehlende Internetverbindung melden und das sowohl bei kabelgebundenen wie auch WLAN-Geräten.
Da scheint noch was anderes im Argen zu liegen. Ich muss mir das glaube ich mal ganzheitlich ansehen.

Danke erst mal für die Tipps und Infos.

Beste Grüße
Dirk

[alf29]

>@alf: Das war doch kein Herumpoltern ...

so war dieses Emoticon bei mir aber angekommen - zusammen mit der 'Feststellung', daß da ein Sicherheitsproblem wäre, ohne weitere Angaben zur Konfig...

Gruß Alfred

[ecox]

Hallo DirkK,

ja, ggf. solltest du dir das Konzept mal anschauen. Ich würde in diesem Szenario alleine schon der Sauberkeit her, mit VLANs arbeiten, hinzu kommt der Sicherheitsaspekt in Zusammenspiel mit ARF-Tags, so trennst du auf Layer 2 und 3, wenn du nun noch eine FW-Regel schreibst die die einzelnen Netze untereinander denyed, biste sicherlich "sicher" unterwegs.

Bzgl. VLANs muss ich sagen, hatte ich bei LANcom anfangs auch so meine Probleme, wenn man nämlich an die CISCO-Konfiguration gewöhnt ist, haste da erstmal nichts zu lachen auf der CLI

Melde dich doch einfach mal oder sag wie du es dir vorstellst, eine Lösung findet man immer.

Das Problem mit den iPhones ist anscheinend eine Neverending-Story, bei jedem neuen Update habe ich Angst und Bange, mal gehts, mal gehts nicht, jedoch konnte ich mit VLANs & Bit-Cluster-Auswertung eine zumindestens für mich 90-94% Erfolgsquote verzeichnen, auch nach einloggen in den PublicSpot und ausbuchen (Netzwerk ignorieren @ iPhone) kann ich danach Problemlos wieder einbuchen (die Anmeldeseite kommt).

Sicherheitstechnisch gesehen kann ich hier auch nur FÜR LANcom sprechen, deshalb sind Alfred seine Anmerkungen durchaus berechtigt und er hat es mit seinem geballten Wissen sogar nochmal nachgestellt

Manchmal herrscht ein rauer Ton, der aber denke von niemanden so gemeint ist, immer eine Anssichtssache

Gute Nacht
ecox