Microsoft-Betriebssysteme hinter Firewalls "sicher" betreiben 17. DV-Treffen der...

Microsoft-Betriebssysteme hinter Firewalls "sicher" betreiben

17. DV-Treffen der Max-Planck-Institute

• 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 10/2000

Andreas Ißleiber

Inhalt:

2



Andreas Ißleiber

LAN

Kriterien für den Einsatz einer FirewallInternet

Firewall

Router134.76.10.254

134.76.10.253

DMZ

Öffentliche ServerWeb,Mail,DNS, etc.

IP: 134.76.10.2GW: 134.76.10.254

IP: 134.76.10.1GW: 134.76.10.254

•Transparente FW:Vorteil: Die bisherige Netzstruktur kann beibehalten bleibenEine 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

•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-AdresseNachteil: Fällt die FW aus, ist ein Zugriff vom LAN auf das Internet nicht möglich.

•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.

•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

192.168.1.254

IP: 192.168.1.1GW: 192.168.1.254

NAT NAT& IP Umsetung

Lokaler Server: IP: 134.76.10.3GW: 134.76.10.254

Lokaler Server: IP: 192.168.1.2GW: 192.168.1.254

Server ist vom Internet erreichbarIP: 192.168.1.2Externe IP: 134.76.10.3GW: 192.168.1.254

•DMZDie FW sollte über eine DMZ verfügen, damit Zugriffe auf öffentliche Dienste nicht in das geschützte LAN erfolgen müssen

3


DMZ LAN

internes Netz

Firewall

Aufteilung der internen- und öffentlichen Dienste

Internet

öffentliche ServerWeb,Mail,DNS, etc.

!

Firewall

Grundregeln auf der FW:

Quelle Dienst allow / reject ZielDMZ alle InternetLAN alle InternetLAN alle DMZInternet alle LANInternet alle/einige DMZDMZ alle LAN

Grundregeln auf der FW:

Quelle Dienst allow / reject ZielDMZ alle InternetLAN alle InternetLAN alle DMZInternet alle LANInternet alle/einige DMZDMZ alle LAN


Andreas Ißleiber

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

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 NT-Servern 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

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 (Achtung mit NAT bei Providern).

8) Ist ein Einwahlservers unumgänglich, so sollte als Authentifizierungsverfahren ausschließlich CHAP(MS-CHAP) verwendet werden. Bei Einsatz eines RADIUS-Servers ist darauf zu achten, daß die Paßwörter gegen die SAM-DB des NT-Servers (verschlüsselt) übetragen werden

9) DMZ ist, selbst bei "offenen "Filtern, gegen IP-Spoofing, DoS Attacken geschützt

4


Betrieb eines Windows-Mailserver

DMZ LAN

vertrauende Domäne

Firewall

Internet

Mailserver auf PDC der Domäne A

Firewall

Zentraler PDC derDomäne B

vertraute Domäne

1

2

3

4

1

2

3

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

Dom.Server B bestätigt das Paßwort

Benutzerzugriff auf Mail (Domäne A)

Erforderliche Regeln auf der FW :

Quelle Dienst allow / reject Ziel Bemerkung(6) 137..139 (7) Netbios, SMBLAN 137..139 (6) Netbios, SMB


Quelle Dienst allow / reject Ziel Bemerkung(6) 137..139 (7) Netbios, SMBLAN 137..139 (6) Netbios, SMB

6

7


Andreas Ißleiber

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) Aufgrund des stetigen Datenaustauschs zwischen den DC ist eine Verbindung zwischen LAN<->DMZ zu vermeidenMailserver Exchange:Problematisch wird dies, bei Mailservern (z.B. Exchange), da hierbei häufig der Zugriff auf die zentrale Userdatenbank zur Anmeldung erforderlich ist. Konflikt: Mailserver bieten Dienste nach Außen an, müssen zugleich auch innerhalb des LAN erreichbar sein. Lösung: Aufbau einer zweiten Domäne für "public Server" in der DMZ mit Vertrauensstellung zur "Haupt"-Domäne. NTLM Paßwörter werden von der Domäne (B) im LAN verifiziert. Ggf. sind Rechner im LAN in LMHOST des Mailservers einzutragen (kein WINS Zugriff ins LAN)DC der Domäne B muß trotz seines Standortes im sicheren LAN gesondert abgesichert sein, da über die Netbios Ports aus der DMZ(one) zugegriffen werden kann

3) Alternative Betriebsart des Mailservers in DMZ:Server in der DMZ bildet als PDC eine eigene Domäne. Benutzerkonten werden redundant eingetragen 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öglichNachteil: Verwaltungsaufwand (doppelte Benutzerführung)Der Mailabruf aus dem LAN belastet die FW (LAN DMZ)

Wichtig bei der Mailboxsynchronisation zwischen Outlook und Exchange

Für die Mailsynchronisation zwischen Outlook und Exchange sind über die IMAP,POP3, SMTP Ports hinaus, auch die Ports...

1071 (TCP), 1062 (TCP), 1054 (TCP), 1042 (TCP), 135 (TCP), 445 (TCP), bei LDAP 389(TCP)

...zu aktivieren. Eine Synchronisation aus dem Internet auf den Exchangeserver ist nicht sinnvoll, da die FW zu weit geöffnet werden muß und dadurch einfacheres Ziel für Attacken darstellt

Auch hier wäre VPN eine Lösung!

Wichtig bei der Mailboxsynchronisation zwischen Outlook und Exchange

Für die Mailsynchronisation zwischen Outlook und Exchange sind über die IMAP,POP3, SMTP Ports hinaus, auch die Ports...

1071 (TCP), 1062 (TCP), 1054 (TCP), 1042 (TCP), 135 (TCP), 445 (TCP), bei LDAP 389(TCP)

...zu aktivieren. Eine Synchronisation aus dem Internet auf den Exchangeserver ist nicht sinnvoll, da die FW zu weit geöffnet werden muß und dadurch einfacheres Ziel für Attacken darstellt

Auch hier wäre VPN eine Lösung!

5


1) Ein Nameserver sollte in der DMZ placiert werdenVorteil: Für den erforderlichen Zonentransfer ist nicht der Port (53, TCP & UDP) in das LAN zu öffnenNachteil: Die DNS-Requests im LAN laufen durch die Firewall

2) Ein im LAN betriebener DNS muß durch entsprechende Filter der FW für etwaige Zonentransfers berücksichtigt werdenHierbei 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 aus dem Internet über SMB erreicht werden können

Betrieb eines DNS(ervers)

DMZLAN

Internet

DNS Server als"stand alone" Server

Firewall1

Zonentransfer vom übergerordneten DNS

1

Erforderliche Regeln auf der FW wenn DNS in der DMZ steht:

Quelle Dienst allow / reject Ziel Bemerkung(6) DNS(53) (8) Zonentransfer (TCP & UDP)LAN DNS(53) (2) DNS Request (UDP)...

Erforderliche Regeln auf der FW wenn DNS in der DMZ steht:

Quelle Dienst allow / reject Ziel Bemerkung(6) DNS(53) (8) Zonentransfer (TCP & UDP)LAN DNS(53) (2) DNS Request (UDP)...

"übergeordneter" DNS

6

8

Die zweite Regel kann entfallen, wenn der DNS im LAN betrieben wird

3

DNS Anfrage, wenn nicht lokal aufgelöst wird3

2

DNS Anfrage vom Client2

4

4

DNS Antwort zum Client

zweiter DNS im LAN(cache only)

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 weiterleitetDieser Server ist aus dem Internet nicht direkt erreichbarDer Zonentransfer findet lediglich zwischen DMZ (DNS) und übergeordnetem DNS stattDieser LAN(DNS) kann auf einem DC betrieben werden


Andreas Ißleiber

6


1) Ein Webserver sollte in der DMZ placiert seinVorteil: Er ermöglicht bei erfolgreichen Attacken, kein Zugriff auf das geschützte LANNachteil: Der Zugriff auf Webseiten aus dem LAN laufen über die FW und belasten diese zusätzlich

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

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

7) Das Management sollte über VPN erfolgen

Betrieb eines Windows-Webservers (IIS)

DMZ LAN

Firewall

Internet

WEB-Server als"stand alone" Server

Firewall1

2

3

Webrequest aus dem Internet

Webrequest aus dem LAN

1

2


Quelle Dienst allow / reject Ziel BemerkungInternet HTTP(80) (3) WebLAN HTTP(80) (3) WebInternet HTTPS(443) (3) Web (SSL, TCP)LAN HTTPS(443) (3) Web (SSL, TCP)


Quelle Dienst allow / reject Ziel BemerkungInternet HTTP(80) (3) WebLAN HTTP(80) (3) WebInternet HTTPS(443) (3) Web (SSL, TCP)LAN HTTPS(443) (3) Web (SSL, TCP)


Andreas Ißleiber

7


Betrieb eines Windows-Terminalservers (TS)

DMZ

LAN

Internet

Windows Terminal Server

Firewall

1

2

3

Erforderliche Regeln auf der FW:

Quelle Dienst allow / reject Ziel Bemerkung(6) ICA(1604) (2) o. (3) icabrowser (UDP)(6) ICA(1494) (2) o. (3) ICA (TCP)LAN ICA(1604,1494) (2) wenn TS in DMZ steht


Quelle Dienst allow / reject Ziel Bemerkung(6) ICA(1604) (2) o. (3) icabrowser (UDP)(6) ICA(1494) (2) o. (3) ICA (TCP)LAN ICA(1604,1494) (2) wenn TS in DMZ steht

ICA Client

Werden VPN-Clients eingesetzt, sind keine Filterregeln erforderlich!


Andreas Ißleiber

• Terminalserver im LANVorteil: Der Zugrif der Client im LAN kann "schnell" erfolgen ohne die FW zu belastenNachteil: Entsprechende Filterreglen für den Zugriff von Außen müssen auf der FW eingerichtet sein

• 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 werdenNachteil: Wird häufig aus dem LAN auf den TS zugegriffen, belastet das erheblich die FWTS ist weniger vor Angriffen geschützt als im LAN VPN-Tunnel

ICA Client mitVPN Client

• Optimaler Einsatz eines TS:Das beste Ergebnis wird erreicht, wenn externe ICA-Client über VPN auf den TS zugreifenHierbei kann der TS im LAN angeschlossen sein, ohne durch zusätzliche Filter die FW zu öffnen

8


Scenario

DMZ

LAN

Internet

Mailserver und PDC derDomäne A

Firewall

Übergeordneter DNS

1

23

4


Quelle Dienst allow / reject Ziel BemerkungInternet SMTP(25) (1) Mailgateway(6) DNS(53) (2) Zonentransfer (TCP & UDP)Internet http(80) (2) WebzugriffLAN alle InternetDMZ alle InternetLAN alle DMZInternet alle LANInternet alle DMZDMZ alle LAN


Quelle Dienst allow / reject Ziel BemerkungInternet SMTP(25) (1) Mailgateway(6) DNS(53) (2) Zonentransfer (TCP & UDP)Internet http(80) (2) WebzugriffLAN alle InternetDMZ alle InternetLAN alle DMZInternet alle LANInternet alle DMZDMZ alle LAN

DNS und Webserver

5

RAS-Server alsMitglied der Domäne A

RAS-Server greift auf diePaßwörter des PDC (1) zurück

Zentraler PDC derDomäne B

6

1

2

3

4

5

Mailserver (PDC) in DMZ

DNS & Webserver in DMZ

PDC im LAN (geschützt)

Clients im LAN (geschützt)

RAS-Server in DMZ

Zentraler Terminalserver(Zugriff nur mit VPN)

Domäne B


Andreas Ißleiber

9


VPN (IPSec)

DMZ LAN

RAS, Einwahl-Server, CHAP Internes Netz

VPN-fähige Firewall

VPN Clients über ein Einwahlserver

VPN Clients aus dem Internet oderFremd-Provider

Internet-router

VPN-Tunnel

VPN-Tunnel


Andreas Ißleiber

1) VPN (IPSec) ist ein geeignetes Verfahren, Verbindungen in das gesicherte LAN über unsichere Netze (Internet) zu führen

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)

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

6) Immer dann, wenn administrative Zugriffe, aber auch Clients, auf lokale Ressourcen im geschützten LAN zugreifen, ist die Benutzung vonVPN eine ideale Lösung

7) Die schlechtere Alternative ist das Öffnen der Firewall durch erweiterte Filterregeln oder die Einschränkung der Dienste der Server

10


Benutzung von "privaten" Netzadressen

Internet

Rechner mit Internetzugang

Rechner ohne Internetzugang

(public) Server mit Internetzugang

Router

1

2

3

4

IP(1): 192.168.1.1IP(2): 134.76.10.11Gw: 134.76.10.254

IP(1): 192.168.1.2

WebserverIP(1): 192.168.1.3IP(2): 134.76.10.13Gw: 134.76.10.254

1

2

3

4

Privates Netz: 192.168.1.0Öffentliches Netz: 134.76.10.0

Gateway (gw): 134.76.10.254


Andreas Ißleiber

• Windows NT erlaubt die gleichzeitige Verwendung mehrer IP-Adressen

• Dies kann die Sicherheit erhöhen, wenn keine FW installiert ist

• "private networks" ersetzten jedoch nicht eine FW

• Bei NT wird lediglich die erste vergebene IP-Adresse für NetBIOS verwendet

• 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

11


Lokale Filter unter Windows NT mit "Boardmitteln"

Liste der Ports:ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers

Soll der Rechner über SMB erreicht werden, so sind auch die Ports 137,138 (UDP) sowie 139 (TCP) auf dem Filter "freizuschalten"

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-PortsFilter für UDP-Ports

IP-ProtokolleIP-Protokolle

Filter für TCP-Ports

Filter für TCP-Ports


Andreas Ißleiber

• 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.)

12


Personal Firewalls auf Windows-Systemen


Andreas Ißleiber

13

Quellen: c't 20/00, Seite 126, c't 17/00, Seite 77http://www.tecchannel.de/software/405/0.html

• Vorteil:Günstiger Preis, wenn wenige Rechner geschützt werden müssenKein "single point of failure" im Vergleich zur zentralen FW

• Nachteil:Jeder einzelne Rechner wird durch die "Software" Firewall belastetKeine(bzw. selten) einheitliche PoliciesTeilweise unzureichender Schutz vor AngriffenKombination aus zentraler- und personal FW nicht sinnvollFW ist nicht ohne "tiefere" Kenntnisse des Benutzers konfigurierbarHoher VerwaltungsaufwandBetriebsystemabhängig

Fazit

• Personal Firewalls ersetzen keine zentrale FW

• Sie bieten, i.d.R.nur bei fachgerechter ! Konfiguration einen Schutz vor Angriffen



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 RechnerViele 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 deaktivierenauf dem NT-Rechner ist das Routing zu deaktivierenWä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

14



Andreas Ißleiber


6.) Die Bindung zwischen dem Serverdienst und dem WAN-Interface trennen,

• wenn kein SMB-Zugriff auf den Rechner über das WAN erfolgen sollBei 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

15



Andreas Ißleiber


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\RunHKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceHKLM\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

16




Andreas Ißleiber

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)

17




Andreas Ißleiber

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 0 - Send LM response and NTLM responseLevel 1 - Use NTLMv2 session security if negotiatedLevel 2 - Send NTLM authenication only (in reiner NT Umgebung möglich)Level 3 - Send NTLMv2 authentication onlyLevel 4 - DC refuses LM authenticationLevel 5 - DC refuses LM and NTLM authenication (accepts only NTLMv2)

... kann die "Art" der verwendeten Passwörter eingestellt werden

18




Andreas Ißleiber

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\SecurityTeilschlü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

19




Andreas Ißleiber

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

20




Andreas Ißleiber

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

21




Andreas Ißleiber

18.) NetBIOS auf FW filtern

NetBIOS Ports vom LAN ins Internet sperrenInsbesondere Port (139) , für Freigaben ist zu FilternI.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. SAMDas 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 werdenHKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount(REG_DWORD), Wert: 0 no cached pw, Wert: 1-50 Anzahl der "cached passwords"

22




Andreas Ißleiber

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

23


Firewall (Beispiel: SonicWall PRO, "www.sonicwall.com")


Andreas Ißleiber

• 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

Einige Merkmale

24


IPCONFIG

Zeigt die lokale IP-Konfiguration an (WINIPCFG bei Win 9x)

Windows Analysetools

C:>\netstat -aWindows NT IP-Konfiguration

PPP Adapter NdisWan14:

IP-Adresse. . . . . . . . . : 0.0.0.0Subnet Mask . . . . . . . . : 0.0.0.0Standard-Gateway. . . . . . :

Ethernet-Adapter CBE16:

IP-Adresse. . . . . . . . . : 134.76.11.163Subnet Mask . . . . . . . . : 255.255.0.0Standard-Gateway. . . . . . : 134.76.11.254

C:>\netstat -aWindows NT IP-Konfiguration

PPP Adapter NdisWan14:

IP-Adresse. . . . . . . . . : 0.0.0.0Subnet Mask . . . . . . . . : 0.0.0.0Standard-Gateway. . . . . . :

Ethernet-Adapter CBE16:

IP-Adresse. . . . . . . . . : 134.76.11.163Subnet Mask . . . . . . . . : 255.255.0.0Standard-Gateway. . . . . . : 134.76.11.254


Andreas Ißleiber

25


C:>\netstat -aAktive Verbindungen

Proto Lokale Adresse Remote-Adresse Zustand TCP laptop-ai:echo 0.0.0.0:0 LISTENING TCP laptop-ai:echo 0.0.0.0:0 LISTENING TCP laptop-ai:discard 0.0.0.0:0 LISTENING TCP laptop-ai:discard 0.0.0.0:0 LISTENING .... TCP laptop-ai:137 0.0.0.0:0 LISTENING TCP laptop-ai:138 0.0.0.0:0 LISTENING TCP laptop-ai:nbsession 0.0.0.0:0 LISTENING TCP laptop-ai:1517 0.0.0.0:0 LISTENING TCP laptop-ai:1517 gwdg-pc-ps1.gwdg.de:nbsession ESTABLISHED TCP laptop-ai:1727 212.150.163.34:80 CLOSE_WAIT TCP laptop-ai:2194 GWDG-PC-S3.gwdg.de:nbsession TIME_WAIT TCP laptop-ai:2211 technologies.com:80 TIME_WAIT TCP laptop-ai:2231 194.77.35.100:591 LAST_ACK UDP laptop-ai:echo *:* ...

C:>\netstat -aAktive Verbindungen

Proto Lokale Adresse Remote-Adresse Zustand TCP laptop-ai:echo 0.0.0.0:0 LISTENING TCP laptop-ai:echo 0.0.0.0:0 LISTENING TCP laptop-ai:discard 0.0.0.0:0 LISTENING TCP laptop-ai:discard 0.0.0.0:0 LISTENING .... TCP laptop-ai:137 0.0.0.0:0 LISTENING TCP laptop-ai:138 0.0.0.0:0 LISTENING TCP laptop-ai:nbsession 0.0.0.0:0 LISTENING TCP laptop-ai:1517 0.0.0.0:0 LISTENING TCP laptop-ai:1517 gwdg-pc-ps1.gwdg.de:nbsession ESTABLISHED TCP laptop-ai:1727 212.150.163.34:80 CLOSE_WAIT TCP laptop-ai:2194 GWDG-PC-S3.gwdg.de:nbsession TIME_WAIT TCP laptop-ai:2211 technologies.com:80 TIME_WAIT TCP laptop-ai:2231 194.77.35.100:591 LAST_ACK UDP laptop-ai:echo *:* ...

NETSTAT

Zeigt die Verbindungen (aktive/passive) an


Andreas Ißleiber

Windows Analysetools

Ports, über die der

Rechner erreichbar

ist

Aktive Verbindungen

ZielportRechner Ziel

26


• Netmon von Windows NT als Bestandteil von Windows NT Server bzw. SMS

• NMAPNT for NThttp://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 Logfilehttp://www.packetfactory.net/Projects/Ngrep/

• WinDump: TCPDUMPhttp://netgroup-serv.polito.it/windump/

• Portmapperhttp://www.analogx.com/contents/download/network/pmapper.htm

• ShadowScan: Security Scannerhttp://www.rsh.kiev.ua/edown.htm

• Einige Cracktoolshttp://www.l0pht.com

• Netmon von Windows NT als Bestandteil von Windows NT Server bzw. SMS

• NMAPNT for NThttp://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 Logfilehttp://www.packetfactory.net/Projects/Ngrep/

• WinDump: TCPDUMPhttp://netgroup-serv.polito.it/windump/

• Portmapperhttp://www.analogx.com/contents/download/network/pmapper.htm

• ShadowScan: Security Scannerhttp://www.rsh.kiev.ua/edown.htm

• Einige Cracktoolshttp://www.l0pht.com

Monitoring Tools und Programme zum Aufspüren von Sicherheitslücken


Andreas Ißleiber

27


• 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

• 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

Monitoring Tools und Programme zum Aufspüren von Sicherheitslücken


Andreas Ißleiber

28

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

Weiterführende Links zum Thema Sicherheit:

Microsoft-Betriebssysteme hinter Firewalls "sicher" betreiben 17. DV-Treffen der...

Documents

Transcript of Microsoft-Betriebssysteme hinter Firewalls "sicher" betreiben 17. DV-Treffen der...