Zwar gehören in dieser Sektion nur Beiträge über 802.1x, aber… irgendwo muss man ja auch anfangen, wenn man über die Verwaltung der Netzwerkzugriffe spricht.

Wir werden versuchen der Zugang zum Netz zu erhärten, und gleichzeitig werden wir probieren dieses umzugehen.

Regelt man die Zugriffe über ein Authentifizierungsmechanismus wie 802.1x (Dot1x), dann lassen die Zugangspunkte, in diesem Fall Ports, standardmässig nur bestimmte Pakete (EAPoL) durch. Andere Pakete werden ignoriert/verworfen, bis der Port autorisiert ist oder auf einem anderen Mechanismus gewechselt wird.

Wie das funktioniert erkläre ich Anhand meinem einfachen LAB:

Verwirrung zwischen Authentisierung, Authentifizierung und Autorisierung

Authentisierung ist der erste Schritt bei der Überprüfung einer Identität. Hier wird behauptet jemand oder etwas zu sein.

Hat sich eine Person oder ein Objekt eine Authentisierung unterzogen, nun muss er mit der Authentifizierung weiterfahren. Hierbei wird überprüft, ob die vorgelegte Identifikation auch echt ist.

Über die Autorisierung wird besagt, was die erfolgreiche authentifizierte Person oder Objekt machen darf.

Anhand dieser Beschreibung wird mittels MAB lediglich NUR authentisiert, da wir behaupten nur jemand zu sein. Selbst wenn die ISE die MAC-Adresse findet, kann er nicht mit Sicherheit sagen, dass wirklich die richtige Maschine hinter dieser Adresse steckt.

Was wollen wir erreichen?

Der Rechner (Links) soll der Zugang zum Netz erlaubt werden erst, wenn die MAC-Adresse gegenüber einer Datenbank erfolgreich verglichen werden konnte.

Doch in unserem Beispiel ist unser Client nicht 802.1x fähig. Für diese Problematik greifen wir auf einem Fallbackmechanismus zurück, MAB. Dieser erfolgt einfach aus der Source MAC-Adresse, welche gegenüber eine bestehende Datenbank verglichen wird.

Alle Teilnehmer in diesem Prozess eine Rolle und oder einen Name:

• Client: Supplicant
• Switch: Authenticator
• Switch Port: Port Access Entity
• Cisco ISE: Authentication Server (AS)
• MAC-Adresse Datenbank: Identity Source

Und jetzt die Beschreibung.

Supplicants sind alle Netzwerkgeräte, die, in unserem Fall, eine Authensierung durchführen bevor der Zugriff auf die Netzwerkressourcen erteilt wird.

Authenticator sind alle Netzwerk Geräte die als Mediator zwischen Supplicant und Authentication Server agieren. Ähnlich wie in einer Full-Proxy Architektur, nimmt der Authenticator Pakete vom Supplicant entgegen packt diese in einem neuen Paket und leitet diese an den AS weiter.

Unter Port Access Entity (PAE) verstehen wir die Hoheheit über den Port am Authenticator (Switch). Dieses beherrscht folgende Status:

• Auto: Es wird erwartet, dass sich der Supplicant erfolgreich authentifiziert, um den Zugriff zum Netzwerk zu gewähren.
• Force Authorized: Ob der Supplicant sich erfolgreich authentifiziert/authentisiert oder nicht, der Zugriff zum Netzwerk wird trotzdem gewährt.
• Force Unauthorized: Komplett anders als beim „authorized“. Hierbei ist es egal, ob der Supplicant sich authentisieren kann oder nicht, dieser Zustand am Port wird der Netzwerkzugriff in jeder Situation verweigern.

Wenn man über einen Authenticator Server spricht, dann von einem Server, welcher einen Authentifizierungsdienst im Netzwerk zur Verfügung stellt. Er ist zuständig für das Beantworten der RADIUS-Anfragen von den Authenticators . Er verarbeitet diese und schickt anschliessend eine Entscheidung an dem Switch zurück.

Sobald der Client sich am Netz verlangt der PAE Information für die 802.1x Authentifizierung (1 – 3). Nach einem auf dem Switch vorkonfigurierten Timeout bricht der PAE ab und macht einen Fallback auf MAC-Authentication Bypass (MAB). Hierbei wird lediglich ein Paket aus dem Client erwartet, damit man die Source MAC-Adresse entnehmen kann. Diese wird an dem Authentication Server in form einer RADIUS-Access Request Anfrage geschickt. Verlauft die Authentisierung erfolgreich antwortet der RADIUS-Server mit einem „Access Accept“, konnte es nicht verifiziert werden, dann erhält der Switch vom RADIUS-Server ein „Access Reject“.

Und Zuletzt der Identity Source. Hier ist eine Datenbank, die vom Authentication Server zugänglich ist, um die Anfragen zu verarbeiten. Dieser liegt meistens auf dem selben System wie der Authentication Server.

Wie sieht ein konkretes Beispiel nun aus?

Ein Client (Supplicant) mit der MAC-Adresse 00:22:CC:FF:C3:AB wird auf dem Port GigabitEthernet1/23 (PAE) auf einem Cisco Catalyst Switch (Authenticator) angeschlossen. Der Port Gig1/23 ist als „authentication port-control auto“ konfiguriert und erwartet eine Authentisierung Seiten des Supplicants.

In einem normalen 802.1x Umgebung kommuniziert der Client mit dem Port via EAPoL, die einzige Art von Pakete, die der Port in diesem Zustand entgegen nimmt. Wie vorher erwähnt, kann unser Client die Kommunikation via Dot1x nicht aufnehmen. Nach einiger Sekunden greift der Switch zum nächsten Mechanismus (MAB). Der Switch nimmt Pakete entgegen, entzieht die MAC-Adresse und baut eine Verbindung mit der Cisco ISE Appliance (Authentication Server), via RADIUS, auf. In dieser Verbindung wird der Switch dem Server die MAC-Adresse des Clients präsentieren..

Die MAC-Adresse des Clients, die davor bereits auf der Cisco ISE-Appliance hinterlegt worden ist, wird verglichen und wenn es einen Treffer gibt, dann schickt die ISE, via RADIUS, eine Bestätigung an dem Switch weiter, dass die Authentisierung erfolgreich war. Der Switch nimmt das entgegen und setzt den Port frei für den Verkehr anderen Protokolle.

Um das erfolgreich in die Praxis umsetzen zu können benötigen wir folgende Konfigurationsschritte auf allen vier vorher erwähnte Teilnehmer.

Konfiguration – Switch

Globale Konfiguration

aaa new-model
aaa authentication dot1x default group radius

RADIUS-Server hinzufügen

radius server ISE
address ipv4 192.168.1.207 auth-port 1812 acct-port 1813
key abcd.1234

Konfiguration – Switch Port

interface range gig1/2 - 48
switchport mode access
authentication port-control auto
authentication periodic
authentication timer reauthenticate 300
spanning-tree portfast
mab

Konfiguration – ISE

Zuerst legen wir eine Gruppe an, wo wir später alle vertrauenswürdige MAC-Adressen hinterlegen werden. Danach soll unser Switch erfasst werden. Anschliessend müssen wir eine Richtlinie/Policy erstellen, damit wenn die ISE-Appliance entscheiden kann, ob die MAC-Adresse zur richtingen Gruppe gehört oder nicht.

Client erfassen

Administration -> Groups -> Endpoint Identity Groups -> Add

Name eingeben und auf Submit klicken

Jetzt müssen wir eine neue MAC-Adresse in diese Gruppe hinzufügen.

Context Visibility -> Endpoints -> Authentication -> +

Die MAC-Adresse muss in die vorher erstellte Gruppe „Trusted_Devices“ hinzugefügt.

Policy erstellen

Policies werden auf der Cisco ISE genau wie bei einer Firewall sequentiell abgearbeitet und sobald es einen Treffer gibt, dann wird nur diese Policy bearbeitet und die restlichen ignoriert. Daher sollte man bei der Platzierung der Policy aufpassen, dass es nicht von einer anderen abgefangen wird und ebenfalls sollte man die Bedingungen so wählen, dass bestehende Policies weiterhin funktionieren.

Da auf meiner Appliance noch ganz wenige Richtlinien gibt, hab ich wenig zu beachten. Ich erstelle einen neuen Policy-Set, der erst abgearbeitet wird, wenn eine RADIUS-Anfrage aus einem NAS-Port-Type: Ethernet kommt.

Nun sieht die Policy wie folgt aus

Wie sieht es aus wenn wir einen Client am Netz anschliessen?

Wir werden die RADIUS-Pakete debuggen. Wir können die vorher erwähnte RADIUS-Messages betrachten: Access-Request und, in diesem Fall, Access-Accept.

Im Access-Request Message sehen wir Attributen, die notwendig sind, um auf der ISE diese mit dem Policy-Set zu vergleichen.

%LINK-3-UPDOWN: Interface GigabitEthernet0/4, changed state to down

RADIUS/ENCODE(00000000):Orig. component type = Invalid
RADIUS(00000000): Config NAS IP: 0.0.0.0
RADIUS(00000000): Config NAS IPv6: ::
RADIUS(00000000): sending
RADIUS/ENCODE: Best Local IP-Address 192.168.1.2 for Radius-Server 192.168.1.207
RADIUS: Message Authenticator encoded

RADIUS(00000000): Send Access-Request to 192.168.1.207:1812 onvrf(0) id 1645/4, len 258
RADIUS: authenticator 61 1F B0 24 C7 37 2C F7 - D6 77 51 2F E2 90 91 C0
RADIUS: User-Name [1] 14 "54ee750b7fde"
RADIUS: User-Password [2] 18 *
RADIUS: Service-Type [6] 6 Call Check [10]
RADIUS: Vendor, Cisco [26] 31
RADIUS: Cisco AVpair [1] 25 "service-type=Call Check"
RADIUS: Framed-MTU [12] 6 1500
RADIUS: Called-Station-Id [30] 19 "0C-F5-A4-F6-A2-04"
RADIUS: Calling-Station-Id [31] 19 "54-EE-75-0B-7F-DE"
RADIUS: Message-Authenticato[80] 18
RADIUS: 81 5C 84 69 82 24 2D 36 57 E6 F9 55 7D F1 7B E9 [ \i$-6WU}{]
RADIUS: EAP-Key-Name [102] 2 *
RADIUS: Vendor, Cisco [26] 49
RADIUS: Cisco AVpair [1] 43 "audit-session-id=C0A801020000001000159534"
RADIUS: Vendor, Cisco [26] 18
RADIUS: Cisco AVpair [1] 12 "method=mab"
RADIUS: NAS-IP-Address [4] 6 192.168.1.2
RADIUS: NAS-Port-Id [87] 20 "GigabitEthernet0/4"
RADIUS: NAS-Port-Type [61] 6 Ethernet [15]
RADIUS: NAS-Port [5] 6 50104
RADIUS(00000000): Sending a IPv4 Radius Packet
RADIUS(00000000): Started 5 sec timeout

RADIUS: Received from id 1645/4 192.168.1.207:1812, Access-Accept, len 143
RADIUS: authenticator 9B 0D D2 03 06 A6 AB 4C - 05 C7 82 5D 8A 4D EF C3
RADIUS: User-Name [1] 19 "54-EE-75-0B-7F-DE"
RADIUS: Class [25] 52
RADIUS: 43 41 43 53 3A 43 30 41 38 30 31 30 32 30 30 30 [CACS:C0A80102000]
RADIUS: 30 30 30 31 30 30 30 31 35 39 35 33 34 3A 69 73 [0001000159534:is]
RADIUS: 65 6E 6F 64 65 2F 33 37 35 39 36 34 31 35 30 2F [enode/375964150/]
RADIUS: 33 35 [ 35]
RADIUS: Message-Authenticato[80] 18
RADIUS: 80 99 9B 7C 11 3C E0 56 9F 56 8F 18 AB 1F F6 6C [ |<VVl]
RADIUS: Vendor, Cisco [26] 34
RADIUS: Cisco AVpair [1] 28 "profile-name=Nortel-Device"
RADIUS(00000000): Received from id 1645/4
RADIUS/DECODE: parse unknown cisco vsa "profile-name" - IGNORE

%LINK-3-UPDOWN: Interface GigabitEthernet0/4, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/4, changed state to up

Wenn wir Details zu der bestehenden MAB-Sitzung erhalten möchten, können wir dies mit dem Befehl „show authentication session interface gig0/4 details“ genauer anschauen.

Switch#sh authentication sessions int gig0/4 details
Interface: GigabitEthernet0/4
MAC Address: 54ee.750b.7fde
IPv6 Address: Unknown
IPv4 Address: Unknown
User-Name: 54-EE-75-0B-7F-DE
Status: Authorized
Domain: DATA
Oper host mode: single-host
Oper control dir: both
Session timeout: N/A
Restart timeout: N/A
Periodic Acct timeout: N/A
Session Uptime: 666s
Common Session ID: C0A801020000001000159534
Acct Session ID: Unknown
Handle: 0x99000005
Current Policy: POLICY_Gi0/4

Local Policies:
Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Server Policies:

Method status list:

Method State 
mab Authc Success

Nun haben wir es geschafft der Zugang zu unserem Netz ein wenig mehr zu erhärten. Doch wie sicher ist das? Wir werden versuchen mittels MAC-Address Spoofing uns als einen anderen Rechner im Netz angeben.

MAC-Adresse unter Kali Linux verändern (MAC-Spoofing)

Das Spoofen der MAC-Adresse ist unter Kali Linux sehr einfach. Dafür gibt es einen ganz einfachen Tool „macchanger“

Syntax. Wir werden davon ausgehen, dass wir über „eth0“

macchanger -m MAC-Adresse Device

macchanger -m 24:18:1d:f3:c6:b0 eth0

Somit ersetzen wir unsere bestehende MAC-Adresse 54:ee:75:0b:7f:de durch die MAC-Adresse eines anderen Rechner, welche ebenfalls auf der ISE eingetragen sind.

Resultat

Das Eindringen in das „fremde“ Netz brauchte knappe 30 Sekunden. Somit kann man sicher sein, dass Netzwerkzugriff über MAC-Adressen keine Hürde für einen Hacker ist. Die ISE hat keine Ahnung, dass diese MAC-Adresse nicht zu diesem Client gehört.

Fazit

Wenn wir Sicherheitsmassnahmen implementieren, können wir nicht das Risiko komplett aus der Infrastruktur beseitigen, aber wir können es minimieren, um die Arbeit für den Angreifer zu erschweren. Es ist wahr, dass ein Angreifer mittels eine bestehende MAC-Adresse und einfache Tools in das System kommen kann, aber er muss zuerst eine Reihe an Tätigkeiten vornehmen bevor er die Hardware-Adresse kennt:

• Eine im System gültige MAC-Adresse herausfinden.
• Physikalischen Zugriff zum Gebäude.
• Umbemerkbar bleiben (Und das vielleicht mit einem nicht einheitlichen Gerät wie Firmen Mitarbeiter).

Dass es schwer ist, bedeutet auf keinen Fall, dass es unmöglich ist. Aber…

Es gibt definitiv bessere Variante wie man den Zugriff auf das Netzwerk gewähren können. MAB sollte nur dort eingesetzt werden, wo es keine andere Varianten gibt, wie zum Beispiel bei Einsatz von IoT oder Gebäude Steuerungsgeräte wie Zutrittskontrolle, etc. Diese müssten aber dann in einem bestimmten isolierten Netzwerk landen, wo nur die nötige Verbindungen zugelassen werden.

Vielen Dank und bis zum nächsten Post