Post on 30-Aug-2019
DHCP, Security undNetzwerkboot
Konstantin Agouros
SLAC 06/Berlin
Übersicht
• DHCP Geschichte• Wie funktioniert DHCP?• Implementierungen• ISC-DHCP-Daemon Details• Sicherheitsaspekte• Netzwerkboot Sun/Jumpstart• PXE• Live-Demo
DHCP-Geschichte
• Am Anfang war die statische Adresse• RARP
– RPC-Bootparam
• Bootp• DHCP
RFCs
• RFC 951 Bootp• RFC 1541 1. DHCP RFC• RFC 1542 DHCP “Klarstellungen”• RFC 2131 aktueller DHCP RFC• RFC 2132 “offizielle” DHCP Optionen und Bootp
Vendoroptionen• RFC 2485 DHCP und Open Group Authentisieung• RFC 2489 Verfahren zur Verabschiedung neuer Optionen• RFC 3670 „Unbenutzte Optionen“
Sinn und Zweck
• Client sucht seine Netzwerkkonfiguration– IP-Adresse– Router– DNS Konfiguration– Bootfile– LDAP-Server– ...
• Server stellt diese bereit– Abhängig vom Teilnetz– Abhängig vom Clienttyp– Abhängig vom Host
Funktionsweise
Discover
Offer
Request
Ack
Funktionsweise 3
• Verkürzter Verlauf (Renewal):– REQUEST– ACK
• Verweigerung des Servers:– DISCOVER/REQUEST– NAK
• Verweigerung des Clients– OFFER– DECLINE
• Ordentliches Herunterfahren– RELEASE
Relaying
Implementierungen
• ISC-DHCP-Daemon• Sun Solaris DHCP Daemon• udhcpd• Windows
ISC-DHCP-Daemon
• Flexibelster Daemon• Bestandteil der meisten Linux Distributionen• Datenhaltung in ASCII• Gruppierung von Clients aufgrund von
– Netz in dem sie stehen– Mitgesendeter VendorID– Hardwaretyp– Frei definierbare Gruppen aufgrund von Hardware Prefixen
• HA-Modus• DNS-Updates• “Authoritative”
Security
• Grundproblem: Wer bekommt eine Adresse und wer darfüberhaupt an das Netzwerk
• Kontrolle im DHCP-Daemon über HW-Whitelist– Problem: MAC-Adressen können gefälscht werden– Hoher Verwaltungsaufwand, da jede MAC-Adresse eingepflegt
werden muss
• Monitoring mit arpwatch– Führt Buch über alle erscheinenden MAC-Adressen– Führt Buch über MAC-zu-IP Bindung– Gibt Warnmeldungen aus oder schickt Emails
Security 2
• DoS durch– Adresspool Erschöpfung– Überlast durch “viele” Request/Release Pakete
• Man in the Middle Angriffe
„Sichere“ Konfiguration im ISC-DHCP-Daemon
subnet 192.168.1.0 netmask 255.255.255.0 { authoritative; pool 192.168.1.10 192.168.1.20; deny unknown clients;}
host host1 { hardware ethernet 00:11:22:33:44:55; fixed-address 192.168.1.10;}…
IEEE 802.1X
• Zugang zum Netz ist Zertifikats Authentisiert• 802.1X beschreibt ein Protokoll, wie auf Ethernet Ebene
der Client seinen Zugang zum (W)LAN mit einem lokalinstallierten Zertifikat berechtigt
• Erfordert Unterstützung auf dem Client OS und demSwitch/WLAN-AP
• Benötigt Radius-Server bei dem die Netzwerk-HWnachfragt
DNS-Updates vs. Sicherheit
• DHCP-Clients können dynamisch auf dem DNS-Servereingetragen werden– Dies geschieht entweder durch den Server oder Client macht dies
selbst– Forward und Reverse RRs werden eingetragen
• Der DNS-Server muß dies erlauben– Durch IP-Adress-basierende ACL unsicher– Durch Shared Secret mit dem “Updater” sicherer
• Sicherste Variante: Updates durch den DHCP-Server derein Shared Secret mit dem DNS-Server teilt.
• Bei Microsoft ADS Umgebungen macht alles der Client
DNS-Updates und Risiken
• Wird ohne Überprüfung überschrieben sind “Man in themiddle” Attacken möglich
• ISC-DHCP-Daemon prüft nur, ob der Name existiert,nicht, ob der erzeugte Eintrag RFC konform ist– Die falschen Sonderzeichen im Hostnamen führen zu einer
illegalen Zone– Beim Restart des Nameservers wird die Zone nicht geladen
ISC-DHCP-Konfiguration für DNS-Update
key DHCP-KEY \{ algorithm hmac-md5; secret "pjGqiQBjQUXELdUyP4lPzA=="; \}
In dhcpd.conf und named.conf
In Forward und Reversezone:
allow-update { key DHCP-KEY; };
ISC-DHCP-Konfiguration für DNS-Update 2
In dhcpd.conf: zone example.com.de { primary 127.0.0.1; key DHCP-KEY; };
zone 1.168.192.in-addr.arpa { primary 127.0.0.1; key DHCP-KEY;; }; ddns-update-style interim;
Weitere Steuerung möglich.
Netzwerkboot allgemein
• Im einfachsten Fall nur das Bootimagefilename “vmlinux”;
• Wenn ein anderer Bootserver notwendig ist, diesenangeben
next-server 192.168.1.2;
Netzwerkboot Jumpstart
• Jedes OS mit DHCP und NFS-Server kann JumpstartServer sein– Linux benötigt einen Kernel-Patch im NFS-Daemon, für
Schreibzugriff auf Char-Device Files
• Die Notwendigen Optionen können auch im ISC-DHCPdgesetzt werden
• Aufsetzen des Dateibaumes am einfachsten unter Solarisund dann kopieren
Netzwerkboot Jumpstart 2
• Benutzt den Vendor-Option-Space SUNW• Sun Zur Erkennung schicken die Systeme eine Vendor-
Client-ID SUNW mit• Jedes SUN-Modell hängt eine Hardwarekennung an
(Ultra1, Ultra30 etc)– uname -i zeigt die richtige Schreibweise
• Standardoptionen die notwendig sind:– filename
– Ggfs. next-server
Netzwerkboot Jumpstart Vendor Options
Definition des Vendorspaces und der Optionen darunter: option space SUNW; option SUNW.root-mount-options code 1 = text; option SUNW.root-server-ip-address code 2 = ip-address; option SUNW.root-server-hostname code 3 = text; option SUNW.root-path-name code 4 = text; option SUNW.boot-file-path code 7 = text; option SUNW.posix-timezone-string code 8 = text; option SUNW.boot-read-size code 9 = unsigned integer 16; option SUNW.install-server-ip-address code 10 = ip-
address; option SUNW.install-server-hostname code 11 = text; option SUNW.install-path code 12 = text; option SUNW.sysid-config-file-server code 13 = text; option SUNW.terminal-name code 15 = text;
Netzwerkboot Jumpstart Vendor Options
Filtern der Clients:Vendor-Client-ID beginnt mit “SUNW”:
class "sun-clients" { match if substring (option vendor-class-identifier,
0, 4) = "SUNW"; vendor-option-space SUNW;
...
Netzwerkboot Jumpstart Vendor Options
Setzen der Werte: option SUNW.sysid-config-file-server
"192.168.1.8:/export/jumpstart/sysidcfg"; option SUNW.install-server-ip-address 192.168.1.8; option SUNW.install-path "/export/jumpstart/install"; option SUNW.root-server-ip-address 192.168.1.8; option SUNW.root-path-name "/export/jumpstart/boot"; option SUNW.posix-timezone-string "MET"; option SUNW.terminal-name "xterm"; next-server 192.168.1.8; if option vendor-class-identifier = "SUNW.Ultra-1" { filename "inetboot.32"; } else { filename "inetboot.64"; }
Netzwerkboot PXE einfach
• filename und next-server genügen• Bootloader möglich• PXEGRUB
– Abhängig von Netzwerkkarte
• PXELINUX– Bootet überall– Erweiterungen vorhanden, um beliebige Floppyimages zu booten– memtest86 lässt sich direkt starten
• Erkennung von PXE-Clients aufgrund der VendorID:PXEClient:Arch:00000:UNDI:002001
Netzwerkboot PXE einfach Beispielconfig
class "PXE-Clients" { match if substring (option vendor-class-identifier, 0, 9) ="PXEClient";
filename “pxelinux.0”; next-server 192.168.1.5;
}
PXE für Fortgeschrittene
• Preboot eXecution Environment• Spezifikation von Intel• Handshakes und Bootmenus möglich• “Proxy-DHCP-Server” auf Port 4011• Erfordert hohe Flexibilität des DHCP-Daemons
PXE Funktionsweise
Discover
Offer
Request
Ack
Boot Service Discover
Boot Service Reply
TFTP
PXE Konfiguration mit Bootmenu
• Benötigt ein Array mit Einträgen die mehrere Typen haben• ISC-DHCP-Daemon kann dies im Prinzip aber nicht beim
Typ String• Daher Konfiguration in HEX-Strings für das Menu
PXE Bootmenu
option vendor-encapsulated-options 06: 01: 06: 08: 1c: 00:00: 01: 0a:0a:FF:FB: 00:03: 01: 0A:0A:FF:FB: 00:01: 01: 0A:0A:FF:FB: 00:02: 01: 0A:01:FF:FB: 09: 29: 00:00: 0a: 4c:6f:63:61:6c:20:62:6f:6f:74: 00:03: 07: 53:6F:6c:61:72:69:73: 00:01: 05: 4c:69:6e:75:78: 00:02: 07: 57:69:6e:64:6f:77:73: 0A: 44: 1E: 50:72:65:73:73:20:3c:46:38:3e:20:6f:72:20:3c:4d: 3e:20:66:6f:72:20:6d:65:6e:75:2e:20:20:50:72:65:
PXE Bootmenu Auswertung
• Die Eingabe des Benutzers muss verarbeitet werden• Darüber erfolgt dann die Angabe des zu bootenden
Images• Daten stehen im Vendor Option Space der vom Client
gesendeten Anfrage• Auswertung in HEX
PXE Bootmenu Auswertung
if option vendor-encapsulated-options =47:04:00:01:00:00:FF {
filename "pxelinux.0"; ...} elsif option vendor-encapsulated-options =
47:04:00:03:00:00:FF { filename "/pxegrub-solaris"; ...}
PXE Bootmenu Probleme
• PXE in Netzwerkkarten ist Buggy• PXEGRUB von Solaris 10 kommt in der Regel nicht damit
zurecht.
Q&A
Live Demo