Microsoft-Betriebssysteme hinter Firewalls "sicher" betreiben 17. DV-Treffen der Max-Planck-Institute Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 2 10/2000 Andreas Ißleiber Inhalt: • Kriterien für den Einsatz einer Firewall • Aufteilung der internen- und öffentlichen Dienste • Betrieb eines Windows-Mailserver • Betrieb eines DNS(ervers) • Betrieb eines Windows-Webservers (IIS) • Betrieb eines Windows-Terminalservers (TS) • Scenario • VPN (IPSec) • Benutzung von "privaten" Netzadressen • Lokale Filter unter Windows NT mit "Boardmitteln" • Personal Firewalls auf Windows-Systemen • Einige Regeln, Windows-Systeme sicherer zu betreiben • Firewall (Beispiel: SonicWall PRO) • Windows Analysetools • Monitoring Tools und Programme zum Aufspüren von Sicherheitslücken Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 3 10/2000 Andreas Ißleiber Kriterien für den Einsatz einer Firewall • Transparente FW: Internet Vorteil: Die bisherige Netzstruktur kann beibehalten bleiben Eine transparente FW kann bei Ausfall schnell aus dem Netz entfernt werden Die FW stellt häufig ein "single point of failure" dar. Lösung: Redundanz schaffen • DMZ Router 134.76.10.254 Die FW sollte über eine DMZ verfügen, damit Zugriffe auf öffentliche Dienste nicht in das geschützte LAN erfolgen müssen • FW mit NAT/PAT: Verwendet die FW NAT, so können im LAN-Bereich "private network"-Adressen benutzt werden. Vorteil: Ein direkter Zugriff von Außen auf "private network"-Adressen ist allein aufgrund des verwendeten Adressbereiches nicht möglich. Die Anzahl der "realen" im Internet sichtbaren IP-Adressen reduziert sich auf eine IP-Adresse Nachteil: Fällt die FW aus, ist ein Zugriff vom LAN auf das Internet nicht möglich. Firewall 134.76.10.253 192.168.1.254 NAT NAT& IP Umsetung • NAT<->IP Umsetzung: FW mit direkter Umsetzung NAT<>IP haben Vorteile. Dadurch ist ein Zugriff von Außen auf Rechner, trotz Verwendung von NAT(private networks), möglich. DMZ LAN IP: IP:134.76.10.1 192.168.1.1 GW: GW:134.76.10.254 192.168.1.254 • FW mit DHCP: Vorteil: Die Adressvergabe im LAN ist dynamisch und dadurch einfach (keine doppelten IP-Adressen, zentrales Management) Nachteil: Fällt die FW aus, so ist auch ein interner Netzwerkbetrieb nicht mehr möglich. Lösung: Redundanter DHCP-Server unter NT. • VPN: (IPSec, 3DES) um Zugriff auf das interne LAN von Außen zu ermöglichen, sollte die FW VPN-Kanäle "terminieren" können IP: 134.76.10.2 GW: 134.76.10.254 Öffentliche Server Web,Mail,DNS, etc. Server Lokaler ist vom Server: Internet Lokaler Server: erreichbar IP: 134.76.10.3 IP: 192.168.1.2 IP: 192.168.1.2 GW: 134.76.10.254 Externe 134.76.10.3 GW:IP:192.168.1.254 GW: 192.168.1.254 Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen 4 Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 10/2000 Andreas Ißleiber Aufteilung der internen- und öffentlichen Dienste 1) Öffentliche Server, in der DMZ(one), sollten keine sicherheitsrelevanten Daten halten, da diese Server häufig das primäre Ziel für Angriffe darstellen Internet 2) File- sowie Web/FTP/Mailserver sollten nicht auf dem gleichen Rechner laufen 3) Ein erfolgreicher Angriff auf Server in der DMZ darf sich nicht auf sicherheitsrelevante Bereiche des LAN´s ausdehnen 4) Strikte Trennung zwischen DMZ und LAN ist das Ziel. Abhängigkeiten zwischen NTServern in DMZ und LAN sind nach Möglichkeit aufzulösen. -> keine Vertrauensstellung zwischen NT-Domänen in DMZ und LAN Bereich -> NTLM (oder gar LM) Authentifizierung vom DMZ in den LAN Bereich ist zu vermeiden 5) RAS-Server nicht! im LAN betrieben werden. Der Nutzen eines RAS-Servers ist mit den daraus resultierenden Sicherheitslücken abzuwägen -> Alternative: Fremde Provider Firewall DMZ ! 6) Ein RAS-Server im LAN reduziert die Gesamtsicherheit auf das Niveau des RAS-Servers. 7) Ist der Zugriff via Einwahl auf interne Netzwerkresourcen erforderlich, ist der Einsatz eines VPN-Clients sinnvoll. Die Einwahlanlage kann dann in der DMZ installiert sein, oder es wird zur Einwahl ein fremder Provider genutzt öffentliche Server (Achtung mit NAT bei Providern). Web,Mail,DNS, etc. 8) Ist ein Einwahlservers unumgänglich, so sollte als Grundregeln auf der FW: Authentifizierungsverfahren ausschließlich CHAP(MS-CHAP) Quelle Dienst allow / reject verwendet werden. Bei Einsatz eines RADIUS-Servers ist darauf DMZ alle P zu achten, daß die Paßwörter gegen die SAM-DB des NT-Servers LAN alle P LAN alle P (verschlüsselt) übetragen werden 9) DMZ ist, selbst bei "offenen "Filtern, gegen IP-Spoofing, DoS Attacken geschützt Internet Internet DMZ alle alle/einige alle O O O Firewall LAN internes Netz Ziel Internet Internet DMZ LAN DMZ LAN Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen 5 Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben Betrieb eines Windows-Mailserver 1 Internet 1) "öffentliche" Server (Web, Mail, etc.) sollten nicht die zentrale Userdatenbank (z.B. SAM, bei Windows NT) halten, welche Zugriffe auf Bereiche des geschützte LAN´s ermöglichen 2 Wichtig beides derstetigen Mailboxsynchronisation 2) Aufgrund Datenaustauschs zwischen den DC ist eine Verbindung zwischen zwischen Outlook undLAN<->DMZ Exchangezu vermeiden Mailserver Exchange: Für die Mailsynchronisation zwischen(z.B. Outlook und da Problematisch wird dies, bei Mailservern Exchange), hierbei häufig Zugriff auf die zentrale Userdatenbank Exchange sindder über die IMAP,POP3, SMTP Ports zur Anmeldung erforderlich ist. hinaus, auch die Ports... Konflikt: Mailserver bieten Dienste nach Außen an, müssen 1071 (TCP), 1062 (TCP),des 1054 (TCP), 1042sein. (TCP), 135 zugleich auch innerhalb LAN erreichbar Lösung: Aufbau einer zweiten Domäne für "public Server" in der (TCP), 445 (TCP), bei LDAP 389(TCP) DMZ mit Vertrauensstellung zur "Haupt"-Domäne. ...zu aktivieren. Eine Synchronisation dem NTLM Paßwörter werden von der Domäneaus (B) im LAN verifiziert. Rechner im LANist in nicht LMHOST des da Internet aufGgf. densind Exchangeserver sinnvoll, einzutragen WINS Zugriff insdadurch LAN) dieMailservers FW zu weit geöffnet(kein werden muß und DC der Domäne B muß trotz seines Standortes im einfacheres Ziel für Attacken darstellt sicheren LAN gesondert abgesichert sein, da über die Netbios Ports aus VPN der DMZ(one) zugegriffen werden kann Auch hier wäre eine Lösung! 4 Benutzer ruft seine Mail ab. (Anmelden an Domäne A) Domainserver A übrprüft bei zentraler Domäne B das Paßwort. Domäne B vertraut Domäne A 3 Dom.Server B bestätigt das Paßwort 4 Benutzerzugriff auf Mail (Domäne A) Firewall Firewall 1 2 3 DMZ LAN 6 7 3) Alternative Betriebsart des Mailservers in DMZ: Mailserver auf PDC Server in der DMZ bildet als PDC eine eigene Domäne. der Domäne A Benutzerkonten werden redundant eingetragen vertraute Domäne Vorteil: Höhere Sicherheit. Wird im Mailserver eingebrochen und Paßwörter ausgespäht, so ist der Zugang zu Daten im LAN immer noch nicht möglich Nachteil: Verwaltungsaufwand (doppelte Benutzerführung)Erforderliche Regeln auf der FW : Quelle Dienst allow / reject Der Mailabruf aus dem LAN belastet die FW (LAN DMZ) (6) 137..139 P LAN 10/2000 Andreas Ißleiber 137..139 P Zentraler PDC der Domäne B vertrauende Domäne Ziel (7) (6) Bemerkung Netbios, SMB Netbios, SMB Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen 6 Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben Betrieb eines DNS(ervers) 10/2000 Andreas Ißleiber 1 Zonentransfer vom übergerordneten DNS 2 DNS Anfrage vom Client 3 DNS Anfrage, wenn nicht lokal aufgelöst wird 4 DNS Antwort zum Client "übergeordneter" DNS 1) Ein Nameserver sollte in der DMZ placiert werden Vorteil: Für den erforderlichen Zonentransfer ist nicht der Port (53, TCP & UDP) in das LAN zu öffnen Nachteil: Die DNS-Requests im LAN laufen durch die Firewall Internet 6 2) Ein im LAN betriebener DNS muß durch entsprechende Filter der FW für etwaige Zonentransfers berücksichtigt werden Hierbei wäre ein Filter zum "übergeordneten" DNS für die UDP/TCP! Ports 53 erforderlich 3) DNS-Server sollten nicht Mitglied einer NT-Domäne sein, oder 3 aus dem Internet über SMB erreicht werden können 4) Alternativ kann auch ein weiterer DNS "cache-only" im LAN placiert werden, der die Anfragen der LAN Clients an den DNS in der DMZ weiterleitet Dieser Server ist aus dem Internet nicht direkt erreichbar DMZ Der Zonentransfer findet lediglich zwischen DMZ (DNS) und übergeordnetem DNS statt Dieser LAN(DNS) kann auf einem DC betrieben werden Erforderliche Regeln auf der FW wenn DNS in der DMZ steht: Quelle Dienst allow / reject Ziel Bemerkung (6) DNS(53) P (8) Zonentransfer (TCP & UDP) LAN DNS(53) P (2) DNS Request (UDP) ... Die zweite Regel kann entfallen, wenn der DNS im LAN betrieben wird Firewall 1 4 2 LAN 8 DNS Server als "stand alone" Server zweiter DNS im LAN (cache only) Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen 7 Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben Betrieb eines Windows-Webservers (IIS) 1) Ein Webserver sollte in der DMZ placiert sein Vorteil: Er ermöglicht bei erfolgreichen Attacken, kein Zugriff auf das geschützte LAN Nachteil: Der Zugriff auf Webseiten aus dem LAN laufen über die FW und belasten diese zusätzlich 10/2000 Andreas Ißleiber 1 Webrequest aus dem Internet 2 Webrequest aus dem LAN Internet 2) Werden Webinhalte mit Daten aus dem LAN angeboten (SQL-Server, ODBC, etc.), sind entspr. Filterregeln zwischen DMZ und LAN erforderlich 3) Diese Seiten sollten ausschließlich über SSL erreichbar sein (Port 443/tcp) Alternativ können auch Ports <> 80 für die Webseiten genutzt werden 4) Webserver sollte nicht Mitglied einer NT-Domäne sein, oder über SMB Zugriffe aus dem Internet zulassen Firewall 1 5) Managementzugriff über das "Microsoft Management Interface" aus dem Internet auf den Webservers (IIS) ist zu verhindern 6) Wenn nicht erforderlich, sollten die Rechte für das Ausführen von Scripten in den HTML-Verzeichnissen deaktiviert werden 2 DMZ 7) Das Management sollte über VPN erfolgen Erforderliche Regeln auf der FW : Quelle Dienst allow / reject Ziel Internet HTTP(80) P (3) LAN HTTP(80) P (3) Internet HTTPS(443) P (3) LAN HTTPS(443) P (3) 3 Bemerkung Web Web Web (SSL, TCP) Web (SSL, TCP) Firewall WEB-Server als "stand alone" Server LAN Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 8 10/2000 Andreas Ißleiber Betrieb eines Windows-Terminalservers (TS) • Windows NT Terminalserver können in der DMZ, sowie auch im LAN placiert werden • Terminalserver in DMZ: Vorteil: Ist ein Zugriff von Außen erforderlich, so müssen keine Portfilter ins LAN konfiguriert werden Nachteil: Wird häufig aus dem LAN auf den TS zugegriffen, belastet das erheblich die FW TS ist weniger vor Angriffen geschützt als im LAN ICAClient Client mit ICA VPN Client 1 VPN-Tunnel • Terminalserver im LAN Vorteil: Der Zugrif der Client im LAN kann "schnell" erfolgen ohne die FW zu belasten Nachteil: Entsprechende Filterreglen für den Zugriff von Außen müssen auf der FW eingerichtet sein • Optimaler Einsatz eines TS: DMZ Das beste Ergebnis wird erreicht, wenn externe ICAClient über VPN auf den TS zugreifen Hierbei kann der TS im LAN angeschlossen sein, ohne durch zusätzliche Filter die FW zu öffnen Erforderliche Regeln auf der FW: Quelle Dienst allow / reject (6) ICA(1604) P (6) ICA(1494) P LAN ICA(1604,1494) P Ziel (2) o. (3) (2) o. (3) (2) Internet Bemerkung icabrowser (UDP) ICA (TCP) wenn TS in DMZ steht Werden VPN-Clients eingesetzt, sind keine Filterregeln erforderlich! Firewall LAN 2 3 Windows Terminal Server Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben Scenario 10/2000 Andreas Ißleiber Übergeordneter DNS Internet 6 DMZ RAS-Server greift auf die Paßwörter des PDC (1) zurück 5 9 LAN Firewall 3 2 1 Zentraler PDC der Domäne B RAS-Server als Mitglied der Domäne A DNS und Webserver Mailserver und PDC der Domäne A Erforderliche Regeln auf der FW: Quelle Dienst allow / reject Ziel Internet SMTP(25) P (1) (6) DNS(53) P (2) Internet http(80) P (2) LAN alle P Internet DMZ alle P Internet LAN alle O DMZ Internet alle O LAN Internet alle O DMZ DMZ alle O LAN Zentraler Terminalserver (Zugriff nur mit VPN) Domäne B Bemerkung Mailgateway Zonentransfer (TCP & UDP) Webzugriff 1 Mailserver (PDC) in DMZ 2 DNS & Webserver in DMZ 3 PDC im LAN (geschützt) 4 Clients im LAN (geschützt) 5 RAS-Server in DMZ 4 Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben VPN (IPSec) 10 10/2000 Andreas Ißleiber Internetrouter 1) VPN (IPSec) ist ein geeignetes Verfahren, Verbindungen in das gesicherte LAN über unsichere Netze (Internet) zu führen VPN-Tunnel 2) IPSec arbeitet transparent, sodass die IP-Anwendungen den verschlüsselten Datenaustausch nicht bemerken 3) Einige FW sind gleichzeitig in der Lage, VPN zu tunneln (VPN-Gateway) VPN Clients aus dem Internet oder Fremd-Provider VPN-fähige Firewall DMZ LAN 4) VPN erfordert erheblichen Rechenaufwand in der FW (je nach Art der Veschlüsselung) 5) Als Verschlüsselunbgstiefe sollte 3DES (nicht mehr DES) eingesetzt werden RAS, Einwahl- 6) Immer dann, wenn administrative Zugriffe, aber Server, CHAP auch Clients, auf lokale Ressourcen im geschützten VPN-Tunnel LAN zugreifen, ist die Benutzung von VPN eine ideale Lösung 7) Die schlechtere Alternative ist das Öffnen der Firewall durch erweiterte Filterregeln oder die Einschränkung der Dienste der Server VPN Clients über ein Einwahlserver Internes Netz Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen 11 Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 10/2000 Andreas Ißleiber Benutzung von "privaten" Netzadressen 1 • Windows NT erlaubt die gleichzeitige Verwendung mehrer IPAdressen • Dies kann die Sicherheit erhöhen, wenn keine FW installiert ist 2 3 Internet • "private networks" ersetzten jedoch nicht eine FW • Bei NT wird lediglich die erste vergebene IP-Adresse für NetBIOS verwendet Rechner mit Internetzugang Rechner ohne Internetzugang 4 (public) Server mit Internetzugang 4 Router Gateway (gw): 134.76.10.254 • Diese erste IP-Adresse kann aus dem Bereich eines "private networks" stammen • Alle Rechner mit "private network"-Adressen sind lokal erreichbar, aber im Internet unsichtbar • Alle weiteren IP-Adressen (2..n) sind für NetBIOS-Dienste nicht zugänglich • Dieser Umstand kann bewußt ausgenutzt werden, um ein lokales- vom öffentlichen Netz zu trennen Privates Netz: 192.168.1.0 Öffentliches Netz: 134.76.10.0 3 1 IP(1): 192.168.1.1 IP(2): 134.76.10.11 Gw: 134.76.10.254 2 IP(1): 192.168.1.2 Webserver IP(1): 192.168.1.3 IP(2): 134.76.10.13 Gw: 134.76.10.254 Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 12 10/2000 Andreas Ißleiber Lokale Filter unter Windows NT mit "Boardmitteln" • Windows NT/Windows 2000 erlaubt die Einrichtung einfacher, lokaler Portfilter • Zugriff läßt sich für den Rechner auf bestimmte Ports beschränken ! • Filter können eingesetzt werden um sich innerhalb des LAN vor Hackerangriffen zu schützen • Ersetzt keine FW (kein IP-Spoofing Schutz, etc.) Soll der Rechner über SMB erreicht werden, so sind auch die Ports 137,138 (UDP) sowie 139 (TCP) auf dem Filter "freizuschalten" Filter für UDP-Ports IP-Protokolle Filter für TCPPorts Liste der Ports: ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 13 10/2000 Andreas Ißleiber Personal Firewalls auf Windows-Systemen • Vorteil: Günstiger Preis, wenn wenige Rechner geschützt werden müssen Kein "single point of failure" im Vergleich zur zentralen FW • Nachteil: Jeder einzelne Rechner wird durch die "Software" Firewall belastet Keine(bzw. selten) einheitliche Policies Teilweise unzureichender Schutz vor Angriffen Kombination aus zentraler- und personal FW nicht sinnvoll FW ist nicht ohne "tiefere" Kenntnisse des Benutzers konfigurierbar Hoher Verwaltungsaufwand Betriebsystemabhängig Fazit • Personal Firewalls ersetzen keine zentrale FW • Sie bieten, i.d.R.nur bei fachgerechter ! Konfiguration einen Schutz vor Angriffen Quellen: c't 20/00, Seite 126, c't 17/00, Seite 77 http://www.tecchannel.de/software/405/0.html Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 14 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 1.) Eine FW befreit nicht von der zusätzlichen Absicherung der Betriebssysteme Insbesondere wenn öffentliche Dienste angeboten werden 2.) Niemals als Administrator, oder vergleichbarer Benutzer, im Internet "surfen" So verbreiten sich Trojaner etc. über die weitreichenden Rechte des Administrator schnell auf das gesamte Netz Über Java, ActiveX, (andere Scripts) gelangen Komponenten schnell auf den lokalen Rechner Viele FW erlauben die Filterung von Java/Javascript/ActiveX Komponenten. Dadurch sind allerdings viele Webseiten nicht mehr lesbar. Hinweis: http://www.heise.de/ct/browsercheck/ 3.) Auf Windows NT Rechnern ist das Routing zu deaktivieren auf dem NT-Rechner ist das Routing zu deaktivieren Während einer Internetverbindung könnten so „Angreifer“ über den NT Rechner auf andere Systeme gelangen 4.) Die Einwahl zu anderen Providern vom LAN aus vermeiden 5.) Administratoraccountnamen umbenennen Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 15 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 6.) Die Bindung zwischen dem Serverdienst und dem WAN-Interface trennen, • wenn kein SMB-Zugriff auf den Rechner über das WAN erfolgen soll Bei der Einwahl über Provider ist der Zugriff auf lokale Freigaben nicht mehr möglich 7.) Einsatz von "passfilt.dll" ab SP3 auf NT-Rechnern • Die passfilt.dll ermöglicht die Überprüfung von Passwörtern nach erweiterten Regeln - mind. 6 Buchstaben Passwortlänge - Vor- Nach und Username dürfen nicht Bestandteil des Passwortes sein - Das Passwort muß! aus allen drei Gruppen mindestens ein Zeichen enthalten: Groß, Kleinschreibung, Zahlen, Sonderzeichen HKLM\SYSTEM\CurrentControlSet\Control\LSA\NotificationPackages\passfilt.dll siehe: http://www.microsoft.com/technet/support/kb.asp?ID=151082 Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 16 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 8.) Zugriffe auf die Registry begrenzen • • Die Gruppe "Everyone" kann Registry-Einträge unter „Run“ und „RunOnce“ vornehmen Unter folgenden Keys sollten die Zugriffsrechte eingeschränkt werden: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall siehe: http://support.microsoft.com/support/kb/articles/Q126/7/13.asp 9.) "unencrypted" Passwords verhindern • • Verhindert die Übertragung von "Klartextpaßwörtern" Ist ab SP3 deaktiviert HKLM\System\CurrentControlSet\Services\RDR\parameters\ EnablePlainTextPassword (REG_DWORD) auf 0 Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 17 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 10.) Default-Screensaver über den folgenden Registryeintrag festgelegen • HKEY_USERS\DEFAULT\Control Panel\Desktop\ScreenSaveActive auf 1 (Scrnsave.exe) auf z.B. "black16.scr" (ScreenSaveTimeOut) "300" (Zeit in Sekunden) Wichtig: Die Rechte dieser Key´s sollten nur auf "Administratoren" gesetzt sein, da sonst ein fremder Screensave in Betrieb genommern werden kann, der unter Admin-Rechten läuft 11.) IPC$ Nulluserverbindung verhindern • • Sog. NullSessions (net use \\rechner\ipc$) erlauben über TCP-Port 139 den Zugriff auf Windows Rechner. Dadurch können Listen der User/Gruppen, Namen, Eventlog (Application sowie Systemlog) eingesehen werden. Ab SP3 kann dieser Zugriff eingeschränkt werden. HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous (RED_DWORD) auf 1 • Nullsessions sind weiterhin möglich (allerdings nun eingeschränkt) Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 18 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 12.) Lan Manager (LM) Paßwörter • • • LAN-Managerpasswörter werden nur als Großbuchstaben übertragen Einsatz ist erforderlich wenn im Netz Win9x Rechner integriert sind Bei einer reinen NT Umgebung sind LM-Passwörter zu deaktivieren • Durch ... HKLM\System\CurrentControlSet\Control\LSA\LMcompatibilityLevel (REG_DWORD) Level Level Level Level Level Level 0 - Send LM response and NTLM response 1 - Use NTLMv2 session security if negotiated 2 - Send NTLM authenication only (in reiner NT Umgebung möglich) 3 - Send NTLMv2 authentication only 4 - DC refuses LM authentication 5 - DC refuses LM and NTLM authenication (accepts only NTLMv2) ... kann die "Art" der verwendeten Passwörter eingestellt werden Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 19 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 13.) Ort der Eventlogdateien ändern • Die NT Eventlog´s liegen i.d.R. im Verzeichnis: %systemroot%/system32/config • Um diese in ein anderes Verzeichnis zu schreiben, muß... HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Application\Security Teilschlüssel "File" %SystemRoot%\System32\config\SecEvent.Evt ... auf das gewünschte Verzeichnis zeigen 14.) Default Admin Freigaben löschen • Die Standard-Freigaben (Laufwerk$ etc.) können durch folgenden Key gelöscht werden HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\ AutoShareWks bzw. AutoShareServer (REG_DWORD) auf den Wert 0 setzen Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 20 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 15.) Deaktivieren des OS/2- sowie POSIX Subsystems bei NT • • Aus Kompatibilitätsgründen ist das OS/2 Subsystem bei NT noch aktiviert Damit NT auch dem C2 Standard entspricht, muß der Key... HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Os2 (REG_EXPAND_SZ) … entfernt werden • Um auch das POSIX-Subsystem zu deaktivieren ist der Key... HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Posix (REG_EXPAND_SZ) … zu entfernen Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 21 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 16.) SYSKEY zur Verschlüsselung der SAM • SYSKEY dient zur nochmaligen 128-Bit-Verschlüsselung der NT-SAM-Datenbank (ab SP3) und deren Kopie • Verschlüsselung kann nicht mehr rückgängig gemacht machen • Dadurch können Hackertools wie "L0phtcrack" die SAM nicht mehr entschlüsseln • Im Netz "aufgefangene" verschlüsselte NTLM Passwörter hingegen können weiter mit L0phtcrack" entschlüsselt werden 17.) Alte Windowssysteme ablösen • Windows 3.x, Win 9X sollten durch modernere Systeme (NT, 2000) abgelöst werden Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 22 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 18.) NetBIOS auf FW filtern NetBIOS Ports vom LAN ins Internet sperren Insbesondere Port (139) , für Freigaben ist zu Filtern I.d.R. erlauben die FW ohnehin kein NetBIOS-Zugriff ins LAN 19.) Zugriffrechte auf %systemroot%\repair einstellen Im Verzeichnis %systemroot%/repair befindet die Kopie der Registry incl. SAM Das Verzeichnis sollte lediglich für Administratoren u. System zugänglich sein, damit Angreifer nicht an die verschlüsselten Paßwörter (SAM) gelangen 20.) Passwortcache deaktivieren The system cannot log you on now because the domain is not available. Windows NT speichert die letzten 10 login(Versuche) Aus Sicherheitsgründen sollte dieser Mechanismus deaktiviert werden HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount (REG_DWORD), Wert: 0 no cached pw, Wert: 1-50 Anzahl der "cached passwords" Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 23 10/2000 Andreas Ißleiber Einige Regeln, Windows-Systeme sicherer zu betreiben 21.) Fernzugriff auf Registry begrenzen Benutzerrechte auf den Key ... HKLM\System\CurrentControlSet\Control\SecurePipeServers\Winreg ... bestimmen die User/Gruppe die remote-Zugriff auf die Registry haben sollen. siehe: http://support.microsoft.com/support/kb/articles/Q155/3/63.ASP http://support.microsoft.com/support/kb/articles/q153/1/83.asp Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 24 10/2000 Andreas Ißleiber Firewall (Beispiel: SonicWall PRO, "www.sonicwall.com") Einige Merkmale • Stateful packet inspection • Network Anti-Virus • IPSec Virtual Private Networking (VPN) Client • Authentication Service • High Availability • Internet Content Filtering • AutoUpdates • ICSA Certified • DMZ (De-Militarized Zone) • Easy Setup and Administration • Robust, Scalable Architecture • Simple WebManagement SonicWall Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben Windows Analysetools IPCONFIG Zeigt die lokale IP-Konfiguration an (WINIPCFG bei Win 9x) C:>\netstat -a Windows NT IP-Konfiguration PPP Adapter NdisWan14: IP-Adresse. . . . . . . . . : 0.0.0.0 Subnet Mask . . . . . . . . : 0.0.0.0 Standard-Gateway. . . . . . : Ethernet-Adapter CBE16: IP-Adresse. . . . . . . . . : 134.76.11.163 Subnet Mask . . . . . . . . : 255.255.0.0 Standard-Gateway. . . . . . : 134.76.11.254 25 10/2000 Andreas Ißleiber Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 26 10/2000 Andreas Ißleiber Windows Analysetools NETSTAT Zeigt die Verbindungen (aktive/passive) an C:>\netstat -a Aktive Verbindungen Proto TCP TCP TCP TCP .... TCP TCP TCP TCP TCP TCP TCP TCP TCP UDP ... Aktive Verbindungen Ports, über die der Rechner erreichbar ist Lokale Adresse laptop-ai:echo laptop-ai:echo laptop-ai:discard laptop-ai:discard Remote-Adresse 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 0.0.0.0:0 Zustand LISTENING LISTENING LISTENING LISTENING laptop-ai:137 laptop-ai:138 laptop-ai:nbsession laptop-ai:1517 laptop-ai:1517 laptop-ai:1727 laptop-ai:2194 laptop-ai:2211 laptop-ai:2231 laptop-ai:echo 0.0.0.0:0 LISTENING 0.0.0.0:0 LISTENING 0.0.0.0:0 LISTENING 0.0.0.0:0 LISTENING gwdg-pc-ps1.gwdg.de:nbsession ESTABLISHED 212.150.163.34:80 CLOSE_WAIT GWDG-PC-S3.gwdg.de:nbsession TIME_WAIT technologies.com:80 TIME_WAIT Zielport 194.77.35.100:591 LAST_ACK Rechne *:* r Ziel Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 27 10/2000 Andreas Ißleiber Monitoring Tools und Programme zum Aufspüren von Sicherheitslücken • Netmon von Windows NT als Bestandteil von Windows NT Server bzw. SMS • NMAPNT for NT http://www.eeye.com/html/Databases/Software/nmapnt.html • Big Brother http://www.bb4.com/ • NGREP (Windows 9x/NT) Durchsucht TCP, UDP und ICMP Pakete nach dem angegebenen Inhalten und schreibt dieses in ein Logfile http://www.packetfactory.net/Projects/Ngrep/ • WinDump: TCPDUMP http://netgroup-serv.polito.it/windump/ • Portmapper http://www.analogx.com/contents/download/network/pmapper.htm • ShadowScan: Security Scanner http://www.rsh.kiev.ua/edown.htm • Einige Cracktools http://www.l0pht.com Gesellschaft für wissenschaftliche Datenverarbeitung Göttingen Microsoft-Betriebsysteme hinter Firewalls „sicher“ betreiben 28 10/2000 Andreas Ißleiber Monitoring Tools und Programme zum Aufspüren von Sicherheitslücken • Cerberus' Internet Scanner, guter, freier Portscanner unter NT/2000 http://www.cerberus-infosec.co.uk/ntinfoscan.shtml Beispiel • Sammlung von diversen Scannern, Securitytools etc. http://www.AntiOnline.com/cgi-bin/anticode/anticode.pl Weiterführende Links zum Thema Sicherheit: Microsoft Checklisten zur System-, Netzwerksicherheit: http://www.microsoft.com/technet/security/tools.asp http://www.microsoft.com/security/ NTBugtraq mailing list http://ntbugtraq.ntadvice.com/ NT Security Forum http://www.ntsecurity.net/ Liste der Firewallanbieter http://www.fwl.dfn.de/fwl/fw/fw-prod.html