Aufwand NAC (Network Access Control)

[stiff_y]

Hallo zusammen,

wir überlegen uns aktuell ein NAC-"System" einzuführen. Die Funktionen sind mir selbst bekannt und auch die einmalige Einrichtung mit Policies und Profilen etc.

Nun aber die Frage an die, die damit schon arbeiten / Erfahrung haben: Wie gestaltet sich der tagtägliche administrative Aufwand? Was sind tägliche Aufgaben die anstehen und wie viel Zeit nimmt die Verwaltung in Anspruch?

Bin für Meinungen / Erfahrungen sehr dankbar!

Gruß

[Crash2001]

An was für ein NAC-System habt ihr denn gedacht? MAC-basiert (MAB), mit dot1x-Zertifikaten oder beides? Abhängig davon ist natürlich auch der Aufwand.

• MAB:
  • MAC-Adressen ein- oder austragen in der Datenbank (eventuell auch zeitlich beschränkte Einträge)
• dot1x:
  • Gültiges Zertifikat auf neuem Rechner, Telefon oder sonstigem Gerät ausrollen oder aber falls bereits Zertifikate darauf sind, vorhandenen Zertifizierungsstellen vertrauen, so dass z.B. Cisco Phones automatisch immer erfolgreich authentifiziert werden.

Dazu natürlich jeweils noch das Debugging und das eventuelle Auftreten von Bugs. Bei NAC-Systemen treten immer wieder diverse Probleme auf. So z.B. mit unmanaged Switches und eingeschleiften VOIP-Phones, dass sie MAC-Adressen festhalten und so tun als wäre das Gerät noch immer dran, so dass es sich nirgends anders authentifizieren kann. (Gerät wird neu gestartet und das Telefon leitet die Abmeldung nicht weiter, so dass der NAC-Server nichts davon mitbekommt und das Gerät dahinter entweder wieder die alte Session zugeordnet bekommt, oder aber sich nicht mehr authentifizieren kann, bis das Telefon neu gestartet wurde. Wird das Gerät an einen anderen Port gehängt, kann es sich ebenfalls nicht mehr authentifizieren.) Es gibt da diverse Bugs dazu.
Gerne bereiten auch Zeiterfassungssysteme oder irgendwelche nonkonformen Maschinenüberwachungen (Alarmanlage, Sensoren, USVs, ...) Probleme, da sie sich entweder nicht 100% an den Ethernet-Standard halten, oder aber nicht von sich aus "aktiv sprechen", sondern nur auf Anfragen reagieren.

Dazu gibt es auch oftmals Probleme mit der korrekten ZUordnung von VOIP-Phones zum richtigen vlan Kontext (Data / Voice vlan), so dass sich z.B. Telefon und PC dahinter beide auf dem Data vlan melden, jedoch laut Config meist nur ein Gerät pro Port und Kontext erlaubt ist.

Ganz toll sind auch Telefone, die mit 2 Netzwerkleitungen gebrückt (geloopt) sind und auf denen sich dann die MAC-Adressen ansammeln und immer von einem ins andere vlan springen. Eigentlich sollten die Switche derartige Loops erkennen - tun sie aber nicht immer immer problemlos, da es ja das Voice-vlan und das Data-vlan gibt. Besonders mit Avaya Phones hatte ich bisher diese Probleme häufiger. Genauso auch bei unmanaged Miniswitchen, auf denen ein Loop gesteckt wird. Manche Geräte filtern sogar einfach die BPDUs heraus.

Generell sollte man darauf achten, dass sich unmanaged Switche mehr im Netz befinden.

Dann halt noch die Frage, ob man NEAT-Switche einsetzen möchte und ob man statische vlans oder dynamische vlans einsetzen will. Vor allem bei dynamischen vlans wird es dann schon wieder schnell einiges komplexer.

Genauso die Frage, ob man die interne Datenbank des NAC-Servers verwenden möchte (sollte man möglichst vermeiden, da es das gesamte System unnötig verlangsamt), oder ob man externe Datenbankanbindungen und z.B. LDAP-Anbindungen (für MAB) nutzt.

[stiff_y]

Gedacht haben wir an Cisco ISE. Dadurch, dass unsere Netzwerklandschaft grundsätzlich aus Cisco Netzwerkkomponenten (managed und mit ein paar Sonderfällen unmanaged) besteht.

Authentifizierung wird gemischt sein. Das heißt teils MAC und teils .1x. Endgeräte, die eben nicht durch z.B. .1x = Radius/LDAP, Zertifikate/PKI etc. "abgeglichen" werden können, werden dann über MAB angesteuert und verwaltet.

Aktuell sind alle VLANs statisch auf den Switchen konfiguriert. Dies muss dann vermutlich auf dynamisch angepasst werden (sonst hätte ja NAC keinen bzw. nur einen kleinen Nutzen)

Ob wir die interne Datenbank des NAC's nutzen werden ist noch eine offene Frage - aber ein guter Hinweis von dir, dies nicht zu tun.

Was genau meinst du damit?

vor 4 Stunden schrieb Crash2001:

Generell sollte man darauf achten, dass sich unmanaged Switche mehr im Netz befinden.

 

 

[Crash2001]

vor 48 Minuten schrieb stiff_y:

Gedacht haben wir an Cisco ISE. Dadurch, dass unsere Netzwerklandschaft grundsätzlich aus Cisco Netzwerkkomponenten (managed und mit ein paar Sonderfällen unmanaged) besteht.

Also so wie ich es auch kenne.

vor 48 Minuten schrieb stiff_y:

[...]Aktuell sind alle VLANs statisch auf den Switchen konfiguriert. Dies muss dann vermutlich auf dynamisch angepasst werden (sonst hätte ja NAC keinen bzw. nur einen kleinen Nutzen)

Nunja, ist halt die Frage, ob man Geräte anhand der für sie hinterlegten Informationen in ein bestimmtes vlan (eventuell auch noch abhängig vom Standort) stecken will, oder ob man nur die reine Authentifzierung und Authentisierung haben möchte. Ich habe schon beide Varianten mehrfach im Betrieb gesehen.
Mit dynamischen vlans ist es halt wie gesagt schon einiges komplexer und durchaus auch fehleranfälliger. Dafür ist es natürlich dann auch automatisierter.

Die Frage ist halt, was man damit bezweckt - nur fremde Geräte aus dem Netz raushalten, oder aber die vlan-Verwaltung direkt in einem mit.

vor 48 Minuten schrieb stiff_y:

Ob wir die interne Datenbank des NAC's nutzen werden ist noch eine offene Frage - aber ein guter Hinweis von dir, dies nicht zu tun.

Die interne Datenbank ist eigentlich nur für Tests oder übergangsweise gedacht - definitiv aber nicht, um dort zig Geräte auf Dauer einzutragen. Dafür ist sie einfach viel zu langsam und bremst die ISE zudem zusätzlich aus durch ihre Schreib- und Lesezugriffe und den RAM-Verbrauch.

vor 48 Minuten schrieb stiff_y:

Was genau meinst du damit?

Sorry, da war mir ein Wort abhanden gekommen.

Sollte eigentlich heissen:

Generell sollte man darauf achten, dass sich KEINE unmanaged Switche mehr im Netz befinden.

Nicht managebare Geräte bringen einfach oftmals Probleme, die man nur bis zum Port des letzten managebaren Switches diagnostizieren kann. Zudem wird dann an diesem authentifiziert, obwohl danach noch eine Verteilung stattfindet. Und da man unmanaged Switche im Netz auch nicht so einfach sieht, gestaltet sich das Debugging dann schwieriger. Ob der Port des unmanaged Switches z.B. defekt ist, sieht man ja z.B. nicht am managed Switch.

[stiff_y]

Ok alles klar - soweit verstanden!

In Bezug auf dein ersten Post - wenn dann alles soweit läuft, wir auch die VOIP-Geschichten bzw. ganzen anderen Themen wie USVs, Zutritt etc. im Griff haben (und auch die anderen Sachen die bei der Einführung zu bewältigen sind)...

-> aus was besteht dein täglicher administrativer Aufwand und wie groß ist dieser (ich will hier nicht auf Minute raus, aber eher 1-2h/täglich oder 4-5h/täglich?)

Soweit ich das mir selbst bzw. aus deinen Postings lesen kann:

(MAC)-Listen pflegen, Monitoring, Einpflegen von neuen Endgeräten, Debugging (nicht-standard Fälle/Probleme)

[Crash2001]

Funktioniert alles problemlos und sind keine Änderungen einzutragen, sollte es rein theoretisch ohne zusätzliche Arbeiten laufen.

Ansonsten die von dir oben genannten Punkte. Wie viel das jeweils an Aufwand ist, hängt von diversen Faktoren ab.

• von der Größe der Umgebung
• von der Komplexität der Umgebung (je komplexer, um so mehr kann falsch laufen und um so tiefergehend muss debuggt werden)
• von der Fluktuation der Geräte
• von den auftretenden Bugs
• von den Sondergeräten
• von Hardwarekombinationen (es gibt Kombinationen, die mehr Probleme bereiten als andere - das aber auch wieder je nach IOS-Version drauf oftmals - somit auch keine eindeutige Aussage möglich, welche Kombinationen man meiden sollte)

Häufig wird es so gemacht, dass entweder der Servicedesk oder der Client Support (meist die Abteilung, die die Geräte auch installiert) die MAC-Adressen der Geräte einträgt, so dass das Netzwerkteam damit nicht mehr viel zu tun hat, sondern sich aufs Debugging und das Tagesgeschäft konzentrieren kann.