Network Access Control (NAC): 802.1X, RADIUS, Posture Assessment und Zero-Trust-Integration

Jedes Gerät das sich mit dem Unternehmensnetzwerk verbindet ist ein potentieller Einstiegspunkt für Angreifer. Ein ungemanagte Laptop, ein privates Smartphone, ein IoT-Gerät - alle können Schadcode einschleusen oder als Brückenkopf für Lateral Movement dienen. Network Access Control (NAC) verhindert, dass unkontrollierte Geräte ins Unternehmensnetz gelangen, indem es vor dem Netzwerkzutritt prüft: Wer ist das Gerät? Gehört es uns? Ist es aktuell gepatcht? Ist Antivirus aktiv?

802.1X: Port-basierte Zugangskontrolle

IEEE 802.1X - das Fundament von NAC:

Rollen:
  Supplicant:     Gerät das Zugang will (Windows, Linux, iPhone)
  Authenticator:  Netzwerkgerät (Switch-Port, WLAN Access Point)
  Auth-Server:    RADIUS-Server (prüft Identität)

NAC-Ablauf (802.1X):

  Gerät verbindet sich mit Switch-Port:
  ┌──────────┐  EAPOL-Start   ┌──────────┐  RADIUS   ┌──────────┐
  │  Client  │ ─────────────> │  Switch  │ ─────────> │   ISE    │
  │(Supplicant)│ <── EAP Req ── │(Authenticator)│ <── Policy ── │(Policy)  │
  │          │ ── EAP Resp ─> │          │           │  Server  │
  │          │ <── Success ── │          │           │          │
  └──────────┘                └──────────┘           └──────────┘

  Ablauf:
  1. Gerät verbindet sich mit Switch-Port
  2. Switch: Port gesperrt (nur 802.1X-Traffic erlaubt)
  3. Switch sendet EAP-Request/Identity an Gerät
  4. Gerät sendet EAP-Response/Identity (Username oder Zertifikat)
  5. Switch leitet weiter an RADIUS (RADIUS Access-Request)
  6. RADIUS prüft Identität:
     → Erfolg: RADIUS Access-Accept → Switch öffnet Port → VLAN zugewiesen
     → Fehler: RADIUS Access-Reject → Switch behält Port gesperrt

  Ergebnis:
  → Auth OK + Posture OK: Normal-VLAN (produktiv)
  → Auth OK + Posture Fail: Quarantäne-VLAN (nur Update-Server)
  → Auth Fail: Kein Zugang oder Gast-VLAN
  → Unbekanntes Gerät: MAB (MAC Authentication Bypass) → Gast-VLAN

EAP-Methoden (wichtig!):

  EAP-TLS:
  → Beiderseitige Zertifikat-Authentifizierung (Client + Server)
  → Stärkste Methode! (kein Passwort-Angriff möglich)
  → Voraussetzung: PKI (CA + Client-Zertifikate)
  → Einsatz: Unternehmens-Geräte (Intune/Jamf deployed certs)

  PEAP-MSCHAPv2:
  → Server-Zertifikat + Username/Passwort (AD-Credentials)
  → Einfacher zu deployen als EAP-TLS
  → Schwächer: Passwort-Angriffe möglich (wenn Server-Cert nicht validiert!)
  → WICHTIG: Supplicant muss Server-Cert validieren!
             (Sonst: Man-in-the-Middle möglich!)

  PEAP-EAP-TLS:
  → PEAP-Tunnel + EAP-TLS innen → sehr stark, sehr komplex

  EAP-TTLS:
  → Ähnlich PEAP, mehr Identitätsschutz

RADIUS-Server-Konfiguration

FreeRADIUS (Open Source):

# Installation Ubuntu:
apt install freeradius freeradius-utils

# /etc/freeradius/3.0/clients.conf - Switches/APs registrieren:
client switch-floor1 {
    ipaddr          = 192.168.1.10
    secret          = "StarkesRADIUSSecret123!"
    nastype         = cisco
    shortname       = sw-floor1
}

client wlan-ap-01 {
    ipaddr          = 192.168.1.20
    secret          = "AnderesSicheresSecret!"
    nastype         = cisco_aironet
}

# /etc/freeradius/3.0/mods-available/ldap - AD-Integration:
ldap {
    server          = "ldap://dc01.company.local"
    identity        = "CN=radius-svc,OU=ServiceAccounts,DC=company,DC=local"
    password        = "ServiceAccountPasswort"
    base_dn         = "DC=company,DC=local"
    user {
        base_dn     = "${..base_dn}"
        filter      = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"
    }
    group {
        base_dn     = "${..base_dn}"
        filter      = "(objectClass=groupOfNames)"
        membership_attribute = "memberOf"
    }
}

# VLAN-Zuweisung basierend auf AD-Gruppe:
if (LDAP-Group == "CN=Corp-Network,OU=Groups,DC=company,DC=local") {
    reply:Tunnel-Type := VLAN
    reply:Tunnel-Medium-Type := IEEE-802
    reply:Tunnel-Private-Group-Id := "10"    # VLAN 10 = Corporate
}
elsif (LDAP-Group == "CN=Guest-Network,OU=Groups,DC=company,DC=local") {
    reply:Tunnel-Private-Group-Id := "99"    # VLAN 99 = Guest
}
else {
    reply:Tunnel-Private-Group-Id := "998"   # VLAN 998 = Quarantäne
}

Microsoft NPS (Network Policy Server):
# In Windows Server integriert (kein Extra-Produkt):
# Server Manager → Add Roles → Network Policy and Access Services → NPS

# NPS-Policy für 802.1X:
# Connection Request Policy:
#   → Type: 802.1X (Wired/Wireless)
#   → Auth-Method: PEAP-MSCHAPv2 oder EAP-TLS

# Network Policy:
#   → Condition: Windows Groups = "CORP\Domain Computers"
#   → Permission: Grant Access
#   → Settings: VLAN-Attribute (Tunnel-Type, Tunnel-Medium-Type, VLAN-ID)

Supplicant-Konfiguration

Windows 802.1X-Konfiguration via GPO:

# Group Policy: Computer → Windows Settings → Security Settings →
#               Wired Network (IEEE 802.3) Policies

# Linux wpa_supplicant (EAP-TLS):
# /etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=/run/wpa_supplicant
network={
    ssid="CORP-WLAN"
    scan_ssid=1
    key_mgmt=WPA-EAP
    eap=TLS
    identity="host/laptop01.company.local"
    ca_cert="/etc/ssl/certs/company-ca.crt"
    client_cert="/etc/ssl/certs/laptop01.crt"
    private_key="/etc/ssl/private/laptop01.key"
}

# Intune: EAP-TLS WLAN-Profil (iOS/Android/Windows):
# Device Configuration → Profiles → Wi-Fi → Enterprise
# EAP Type: TLS
# Certificate server names: radius.company.local
# Root certificate: Company Internal CA
# Client certificate: SCEP/PKCS cert from Intune

MAC-Address-Bypass für Legacy-Geräte

MAC Authentication Bypass (MAB) für IoT/Drucker:

Das Problem:
  → Drucker, IP-Telefone, IoT-Sensoren: unterstützen kein 802.1X
  → Müssen trotzdem ins Netz (aber kontrolliert!)

MAB-Lösung:
  → Switch sendet MAC-Adresse des Geräts als RADIUS-Request
  → RADIUS vergleicht MAC mit Whitelist
  → Bei Match: Access-Accept + VLAN-Zuweisung

  # RADIUS MAB Policy (FreeRADIUS):
  # MAC-Whitelist (format: XX-XX-XX-XX-XX-XX in Kleinbuchstaben):
  aa-bb-cc-dd-ee-ff Cleartext-Password := "aa-bb-cc-dd-ee-ff"
      Tunnel-Type = VLAN,
      Tunnel-Medium-Type = IEEE-802,
      Tunnel-Private-Group-Id = "20"   # VLAN 20 = Drucker-VLAN

Sicherheitslimitation von MAB:
  ⚠️ MAC-Adressen sind leicht zu fälschen!
  ⚠️ Angreifer kann beliebige MAC verwenden (MAC-Spoofing)
  → MAB nur für Low-Trust-Geräte + eigenes Sicherheits-VLAN
  → Posture Assessment zusätzlich (wenn möglich)

Posture Assessment - Gerätezustand prüfen

Was NAC beim Gerät prüfen kann:

Posture-Checks (Beispiele, Cisco ISE):

1. Betriebssystem-Konformität:
   □ Windows-Version: min. Windows 10 22H2?
   □ macOS-Version: min. 14.x (Sonoma)?
   → Ältere Versionen → Quarantäne → Update-Seite

2. Patch-Level:
   □ Windows Update: alle kritischen Patches installiert?
   □ Prüft WSUS/SCCM-Status oder WMI direkt
   → Nicht aktuell: Quarantäne + Update-Server erreichbar

3. Antivirus/EDR:
   □ Welche AV-Lösung? Version? Definitionen aktuell?
   □ Defender aktiviert? Real-Time-Protection an?
   □ Konformes EDR-Produkt installiert?
   → Kein AV/EDR: Quarantäne

4. Disk-Encryption:
   □ BitLocker (Windows): aktiv? Escrowed?
   □ FileVault (macOS): aktiv?
   → Nicht verschlüsselt: Quarantäne

5. Firewall:
   □ Windows Firewall aktiviert?
   □ Alle Profile (Domain/Private/Public)?

6. Domänenmitgliedschaft:
   □ Gerät in AD-Domain? → Managed Device
   □ AAD-Join (Entra ID)? → Cloud-Managed
   → Nicht in Domain: BYOD-Behandlung

7. Software-Inventory:
   □ Unzulässige Software installiert? (Torrent, Remote-Tools?)
   → Nicht konforme Software: Warnung oder Quarantäne

Agent-basiert vs. Agentless:

Agent-basiert:
  → NAC-Agent auf Gerät installiert
  → Tiefe Prüfung möglich (alle oben genannten Checks)
  → Problem: Agent-Management, Updates, BYOD akzeptiert keinen Agent

Agentless:
  → Ohne Software auf Gerät
  → Prüft: MAB (MAC-Adresse), DHCP-Fingerprint, mDNS
  → Schwächere Checks (Gerät-Typ erkannt, nicht Patch-Level)
  → Für Drucker, Kameras, IoT-Geräte (kein Agent möglich!)
  → Für BYOD: begrenzte Kontrolle

Posture Workflow:
  1. Gerät verbindet sich → 802.1X Authentication erfolgreich
  2. NAC stellt Client-Agent fest (oder Agent prüft selbst)
  3. Agent prüft Posture-Anforderungen
  4. Ergebnis:
     → Compliant: Full Access VLAN
     → Non-Compliant: Quarantäne-VLAN
     → Unknown: begrenzt. Zugang (für Erstregistrierung)

VLAN-basierte Segmentierung

NAC-VLANs und Zonenmodell:

VLAN-Struktur (typisch):
  VLAN 10 - Corporate:         Managed, konformes Windows/macOS, Domain-Join
  VLAN 20 - BYOD/Mobile:       Personal Device, MDM-Enrollment, eingeschränkt
  VLAN 30 - Gast:              Kein Unternehmenszugang, nur Internet
  VLAN 40 - Quarantäne:        Nicht konform, nur Remediation-Server
  VLAN 50 - IoT:               Drucker, Kameras, Sensoren, isoliert
  VLAN 60 - VoIP:              IP-Telefone, QoS-priorisiert
  VLAN 70 - Server:            Produktions-Server, restriktiver Zugang
  VLAN 98 - Management:        Netzwerk-Admins, Network Devices
  VLAN 998 - Quarantäne:       non-compliant, Remediation

VLAN-Zuweisung durch NAC:
  802.1X-Auth + Posture OK → Corporate VLAN 10
  MDM-Enrollment + BYOD-Policy → BYOD VLAN 20
  Kein Auth / Unknown Device → Gast VLAN 30
  Posture Fail (AV fehlt) → Quarantäne VLAN 40
  MAC von bekanntem Drucker (MAB) → IoT VLAN 50

Quarantäne-VLAN Design:
  → Erlaubt: DHCP, DNS, HTTP/HTTPS (nur interne Remediation-Server)
  → Blockiert: alle anderen Hosts im Netzwerk!
  → Remediation-Seite: erklärt Problem + Lösung
  → Nach Remediation: Posture-Reassessment + korrektes VLAN

Gastnetze:
  → Komplett isoliert von internen Ressourcen
  → Internet-Zugang: eingeschränkt (kein P2P, Bandbreiten-Limit)
  → Captive Portal: AGB-Akzeptanz, Zeitlimit
  → WLAN-SSID: "Guest" (getrennt von Corporate-SSID)
  → Keine VPN-Tunnel in Corporate-Netz vom Gast-VLAN!

BYOD-Integration und Mobile

BYOD (Bring Your Own Device) mit NAC:

Herausforderungen:
  → Private Geräte akzeptieren keinen vollständigen NAC-Agent
  → DSGVO: Arbeitgeber kann private Daten auf privatem Gerät nicht prüfen
  → Compliance: wie sicherstellen ohne vollständige Kontrolle?

BYOD-NAC-Strategien:

Strategie 1 - MDM-Enrollment (Hybrid):
  → Gerät muss in MDM (Intune, Jamf) eingeschrieben sein
  → MDM-Profil: Geräteverschlüsselung, PIN-Anforderung, VPN-Profil
  → NAC prüft MDM-Enrollment-Status via API
  → MDM-Compliance → BYOD-VLAN (eingeschränkt, aber produktiv)
  → Kein MDM → Gast-VLAN oder kein Zugang

  Datenschutz-Kompromiss (MDM auf privaten Geräten):
  → Apple: User Enrollment (MAM only, kein Device Wipe!)
  → Android: Work Profile (trennt privat/beruflich)
  → Arbeitgeber sieht NUR Work-Profil, nicht private Apps/Daten

Strategie 2 - Certificate-basiertes BYOD:
  → Benutzer erhält Client-Zertifikat nach Registrierung
  → Zertifikat auf privatem Gerät (Schlüsselspeicher)
  → 802.1X mit EAP-TLS: Zertifikat als Auth
  → Kein Posture-Check (keine vollständige Compliance)
  → BYOD-VLAN: begrenzte Ressourcen

Strategie 3 - ZTNA statt LAN-Zugang:
  → Privates Gerät: KEIN Netzwerk-Zugang!
  → Nur Anwendungs-Zugang via ZTNA (Zero Trust Network Access)
  → Secure Enclave/Sandbox-App: nur Firmen-Apps in isolierter Umgebung
  → Kein Zugang zu internem Netzwerk → kein Lateral-Movement-Risiko
  → Empfohlen: Cloudflare Access, Zscaler Private Access, Microsoft Entra ID

BYOD-Policy (rechtliche Anforderungen):
  □ Schriftliche Einwilligung: Gerät darf gemanaged werden
  □ Klarer Scope: welche Daten/Apps auf privatem Gerät
  □ Remote-Wipe-Policy: nur Work-Container, nicht ganzes Gerät
  □ Trennung: privat vs. beruflich (Work Profile)
  □ Datenschutzerklärung: was wird über das Gerät gesammelt?

NAC-Lösungen im Vergleich

Führende NAC-Produkte:

Cisco Identity Services Engine (ISE):
  Stärken:
    → Marktführer, tiefe Cisco-Integration
    → Umfangreiches Posture Assessment
    → pxGrid-Integration: Kontext-Sharing mit anderen Sicherheitslösungen
    → TrustSec (SGT): software-defined Segmentierung
    → Profiling: automatische Geräteerkennung (über 7000 Profile!)
  Schwächen:
    → Hohe Lizenzkosten ($$$)
    → Komplexe Implementierung (6-12 Monate typisch!)
    → Hohe Hardware-Anforderungen
  Empfehlung: Für Cisco-zentrierte Enterprises, ab ~$50/Device/Jahr

Aruba ClearPass (HPE):
  Stärken:
    → Herstellerunabhängig (works with Cisco, Juniper, Aruba)
    → Starke BYOD-Workflows
    → OnGuard Agent für tiefes Posture Assessment
    → Gute API für Automatisierung
  Schwächen:
    → Komplex, erfordert Expertise
    → Aruba-Switches für beste Integration
  Empfehlung: Bestes BYOD-Workflow, herstellerunabhängig

Microsoft Network Policy Server (NPS):
  Stärken:
    → Kostenlos (in Windows Server)
    → Native AD-Integration
    → Gut für reine Microsoft-Umgebungen
  Schwächen:
    → Begrenzte Posture-Fähigkeiten (nur Domain-Check)
    → Keine modernen Zero-Trust-Features
    → Legacy-Architektur
  Empfehlung: Als Start/Ergänzung, nicht als primäre NAC

Portnox Cloud:
  Stärken:
    → Cloud-native NAC (kein On-Prem-Server!)
    → Einfachere Implementierung als Cisco ISE
    → BYOD-freundlich
    → Azure AD / Entra ID Integration
  Schwächen:
    → Weniger mächtig als ISE bei komplexen Szenarien
    → Relativ junge Plattform

Forescout Platform:
  Stärken:
    → Agentless: sieht alle Geräte ohne Agent
    → IoT/OT-Spezialist: erkennt industrielle Geräte
    → Keine 802.1X-Voraussetzung (funktioniert mit alten Switches)
  Empfehlung: Für OT/IoT-Umgebungen + Legacy-Netzwerke

Auswahl-Kriterien:
  □ Netzwerk-Hersteller: Cisco → ISE; Aruba → ClearPass; Mix → Forescout/Portnox
  □ Budget: Klein → Microsoft NPS + Portnox; Groß → ISE/ClearPass
  □ IoT-Anteil: Hoch → Forescout (agentless)
  □ Cloud-First: → Portnox oder ZTNA statt klassisches NAC
  □ BYOD-Schwerpunkt: → Aruba ClearPass (bestes BYOD-Workflow)

NAC als Zero-Trust-Baustein

NAC im Zero-Trust-Kontext:

Zero-Trust-Prinzip: "Never trust, always verify"
NAC-Beitrag:
  → Gerät muss sich identifizieren (802.1X / Zertifikat)
  → Gerät muss Compliance nachweisen (Posture)
  → Zugang ist kontext-abhängig (VLAN/Segment je Gerät/Rolle)
  → Kontinuierliche Prüfung (Posture regelmäßig neu bewertet)

NAC + Conditional Access (Microsoft):
  → Intune: markiert Geräte als compliant/non-compliant
  → Azure AD Conditional Access:
    → Gerät must be "Intune compliant" für O365-Zugriff
    → Kombinierbar mit NAC: non-compliant → Quarantäne + kein O365

Implementierungs-Empfehlung:
  Start:      WLAN zuerst (einfacher, weniger Devices)
  Phase 2:    Kabelgebundenes LAN (mehr Komplexität)
  Phase 3:    IoT-Geräte + MAB
  Phase 4:    Posture Assessment
  → Nie alles auf einmal: stufenweiser Rollout!

Implementation-Roadmap

NAC-Rollout-Phasen (12-18 Monate typisch):

Phase 1 (Monate 1-3): Inventory und Design
  □ Alle Netzwerksegmente kartieren
  □ Alle Gerätekategorien identifizieren (PC, Mobile, Drucker, IoT)
  □ VLAN-Konzept entwerfen
  □ Policy-Anforderungen (HR, Legal für BYOD-Policy)
  □ NAC-Produkt auswählen + PoC

Phase 2 (Monate 4-6): Pilotierung
  □ 802.1X auf Pilot-Switches konfigurieren (nicht produktiv!)
  □ 50-100 Pilot-User: Corporate Windows-Geräte
  □ Authentication + Basic Posture testen
  □ Helpdesk-Prozesse definieren (NAC-Probleme → wie lösen?)
  □ Exception-Prozess: wer bekommt Ausnahmen?

Phase 3 (Monate 7-9): BYOD + Mobile
  □ MDM-Enrollment-Workflow
  □ BYOD-VLAN + Richtlinien
  □ Certificate-Distribution für EAP-TLS
  □ Gast-WLAN + Captive Portal

Phase 4 (Monate 10-12): IoT und Legacy
  □ MAB für Drucker, Kameras, Telefone
  □ Profiling: automatische Geräterkennung
  □ IoT-VLAN + Mikrosegmentierung
  □ Legacy-Geräte: Ausnahmen oder Ersatz

Phase 5 (Monate 13-18): Vollrollout + Monitoring
  □ Alle Switches/WLANs umgestellt
  □ Monitoring: NAC-Dashboard + SIEM-Integration
  □ Regelmäßige Policy-Reviews (quartalsweise)
  □ Incident-Playbooks: NAC-Ausfall, false-positives

Erfolgskennzahlen (KPIs):
  → % Geräte unter NAC-Kontrolle (Ziel: >95%)
  → Ungemanagte Geräte erkannt (Ziel: <5%)
  → Quarantäne-Ereignisse/Woche (Trend: abnehmend!)
  → Mean Time to Remediate (Quarantäne → Konformität)
  → NAC-Availability: >99.9%