DHCP, Security und Netzwerkboot 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 lokal installierten Zertifikat berechtigt Erfordert Unterstützung auf dem Client OS und dem Switch/WLAN-AP Benötigt Radius-Server bei dem die Netzwerk-HW nachfragt
DNS-Updates vs. Sicherheit DHCP-Clients können dynamisch auf dem DNS-Server eingetragen 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 der ein 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 the middle 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 Bootimage filename vmlinux ; Wenn ein anderer Bootserver notwendig ist, diesen angeben next-server 192.168.1.2;
Netzwerkboot Jumpstart Jedes OS mit DHCP und NFS-Server kann Jumpstart Server 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-DHCPd gesetzt werden Aufsetzen des Dateibaumes am einfachsten unter Solaris und 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 = ipaddress; 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 vendorclass-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