R
Rushjo
Guest
Windows-Server mit IIS härten
-----------------------------
Erstmal sollte man sich mal vor Augen halten, dass
ein Server, der keine Services anbietet, auch keinerlei
Angriffsfläche aufweist!
Die meisten User nutzen unter Windows immer noch
den IIS (=Internet Information Server). Und dieser IIS
ist der Hauptangriffspunkt für die meisten Hacker!
Dieses Produkt hat, wie die meisten Microsoft-
Produkte, eine unglaubliche Menge an Bugs.
Allgemein sollte man immer die neusten Sicherheits-
Patches von Microsoft einspielen und dadurch stets
up-to-date bleiben!
[http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-018.asp]
Dazu gibt es auch von Microsoft ein Tool, das schon
auf installierte Hotfixes testet.
[http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/hfnetchk.asp]
Das härten des Windows-Servers fängt schon mit der
Installation an, hier sollte man gleich von Anfang an
gezielt nur benötigte Komponente installieren, d.h.
gleich mal die Installation der FTP-Server unterbinden,
da er sonst gleich mitinstalliert wird.
Nur mal ein paar der bekanntesten Bugs: Unicode-
Bug, transversal directory scripting, ASP-Bug und
ISAPI-Bug etc.
Immernoch nutzen die meisten Angreifer den Unicode-
Bug, was einerseits durch die weite Verbreitung von
Informationen über die Angriffs-Techniken und
anderseits viele bunte "klicki-tools" begünstigt wird!
Desweiteren gibt es immer noch mehr als genung
Server, die verwundbar gegen über diesem Bug sind!
Insgesamt gibt es mittlerweile mehr als 303 Unicode-
Bugs.
Der Unicode-Bug basiert auf einer ganz einfachen
Idee. Mit den Zeichen /../ kann man einfach ein
Verzeichnis höher gehen. Wenn dies auf einem Server
funktionieren würde, dann könnte man ganz einfach
ins Hauptverzeichnis gehen und dort dann "böse"
Sachen anstellen. Weil ja die Programmierer bei
Microsoft nicht ganz blöd sind, haben sie diese
Möglichkeit verboten. Und nun haben sich mal
schlaue Leute gedacht, man könne die Zeichen
einfach in Unicode-Zeichen umwandeln und dann
eingeben! Tja, und die bei Microsoft sind die Einzigen,
die so blöd waren, dies nicht zu bedenken!
Okay, und dies wird nun bei den Unicode-Bug
ausgenutzt. Also greift der Angreifer per Unicode-Bug
dann auch die cmd.exe (=das Dos von Windows) zu
und verwendet es für seine eigenen Zwecke!
Aber genug zum Bug, den Angreifer aus nutzen! Viel
wichtiger ist die Tatsache, das dieser Angriff immer
über ein paar Eckpfeiler geht. Diese Eckpfeiler sind im
allgemeinen folgende Dateien, die ein Angreifer
immer nutzt!
All diese Dateien sind Dateien, die von dem Angreifer
genutzt werden. Man sollte diese Dateien am besten
auf eine CD brennen und dann löschen. Und dann die
Dateien nur noch raufkopieren von der CD, wenn man
sie benötigt.
Desweiteren nutzt ein Angreifer immer die Standard-
Verzeichnisse. Dies kann man umgehen, indem man
virtuelle Verzeichnisse mit beschränkten Rechten
anlegt!
Schreib- und Löschrechte für diese Verzeichnisse nur
für System und Amdinistrator erlauben. Dann, vor
allem, auch den IIS nicht unter Administrator-Session
laufen lassen, sondern einen eigenen Account den IIS-
Betrieb einrichten, weil der Angreifer automatisch
die Rechte erlangt, die das Programmes erlangt,
welches er abschiesst/missbraucht!
Desweiteren sollte man sich noch eine Datei
schreiben, die man die Logfiles des IIS
automatisch bei jedem Reboot des Windows-OS in
eine anderes Verzeichnis kopiert/spiegelt und
dann auch noch zusätzlich mit einem Schreibschutz
versieht. Damit man zumindestens nach einem
erfolgreichen Angriff die Spuren des Angreifers
auswerten kann! Weil nach einem erfolgreichen
Angriff wird der Angreifer immer versuchen seine
Spuren, die hinterlassen hat zu vernichten.
Und dann einfach die log_save.bat in
Programme\Autostart\ legen!
Auch sollte man, gerade als Admin eines WebServer,
die Logs, die da so produziert werden, auch mal
anschauen! Allgemein erstmal der Aufbau der Log-
Dateien des IIS.
Orte der Logfiles:
c:\winnt\system32\logfile\msftpsvc1\*.log ( = Logfile des FTP-Servers)
c:\winnt\system32\logfile\w3svc1\*.log ( = Logfile des HTTP-Servers)
So, jetzt zu einer Beispiel-Log-File (mit special Thx an
den chinesischen Server, von dem sie stammen!!!):
Hier sieht man sehr schön die IP des Angreifers
XXX.XXX.XXX.XXX, die IP des Servers YYY.YYY.YYY.YYY
und den verwendeten Unicode-Bug, hier: ..%5c..%5c !
Dann als Nächstes kommt dann der Befehl, der
ausgeführt wurde. Und die Zahl da hinter gibt die
Antwort des Servers auf den Request aus. Hier mal
eine Zusammenstellung der wichtigsten möglichen
Antworten des Servers auf die Requests.
[http://www.webmeister.ch/server/error_code.htm]
Ein weiteres Tool, welches man zum Schutz des IIS
installieren sollte, ist UrlScan von Microsoft. Man kann
es hier downloaden.
[http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/urlscan.asp]
Dabei ist aber zu beachten, dass man zuerst UrlScan
1.0 oder UrlScan 2.0 installiert haben muss, bevor
man die neuste Version UrlScan 2.5 installieren bzw.
besser gesagt, darauf upgraden kann!
Noch günstiger ist es, wenn man gleich das Komplett-
Packet "IIS Lockdown Wizard" installiert.
Alternativ kann man natürlich auch "sichere" Web-
Server wie Apache, Jana Server, thttpd, mathopd, boa,
stronghold, IPlanet (netcape enterprise), roxen, zeus,
ibm httpd. Diese weisen zwar weniger Bugs auf als
der IIS, aber man sollte sich zu mindestens auch mal
mit deren Sicherheit befassen und eventuell not-
wendige Patches einspielen!
So, das war nur mal eine kurze Einführung zur
Sicherung des IIS.
Quellen & Links:
----------------
[1]http://www.securityfocus.com
[2]http://www.neworder.box.sk
[3]http://support.microsoft.com/default.aspx?xmlid=fh;DE;iisin2&ln=de
[4]http://www.rz.tu-cottbus.de/urz/security/Win2000IIS.html
[5]http://www.apache.org
[6]http://www.janaserver.de
-----------------------------
Erstmal sollte man sich mal vor Augen halten, dass
ein Server, der keine Services anbietet, auch keinerlei
Angriffsfläche aufweist!
Die meisten User nutzen unter Windows immer noch
den IIS (=Internet Information Server). Und dieser IIS
ist der Hauptangriffspunkt für die meisten Hacker!
Dieses Produkt hat, wie die meisten Microsoft-
Produkte, eine unglaubliche Menge an Bugs.
Allgemein sollte man immer die neusten Sicherheits-
Patches von Microsoft einspielen und dadurch stets
up-to-date bleiben!
[http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/ms02-018.asp]
Dazu gibt es auch von Microsoft ein Tool, das schon
auf installierte Hotfixes testet.
[http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/hfnetchk.asp]
Das härten des Windows-Servers fängt schon mit der
Installation an, hier sollte man gleich von Anfang an
gezielt nur benötigte Komponente installieren, d.h.
gleich mal die Installation der FTP-Server unterbinden,
da er sonst gleich mitinstalliert wird.
Nur mal ein paar der bekanntesten Bugs: Unicode-
Bug, transversal directory scripting, ASP-Bug und
ISAPI-Bug etc.
Immernoch nutzen die meisten Angreifer den Unicode-
Bug, was einerseits durch die weite Verbreitung von
Informationen über die Angriffs-Techniken und
anderseits viele bunte "klicki-tools" begünstigt wird!
Desweiteren gibt es immer noch mehr als genung
Server, die verwundbar gegen über diesem Bug sind!
Insgesamt gibt es mittlerweile mehr als 303 Unicode-
Bugs.
Der Unicode-Bug basiert auf einer ganz einfachen
Idee. Mit den Zeichen /../ kann man einfach ein
Verzeichnis höher gehen. Wenn dies auf einem Server
funktionieren würde, dann könnte man ganz einfach
ins Hauptverzeichnis gehen und dort dann "böse"
Sachen anstellen. Weil ja die Programmierer bei
Microsoft nicht ganz blöd sind, haben sie diese
Möglichkeit verboten. Und nun haben sich mal
schlaue Leute gedacht, man könne die Zeichen
einfach in Unicode-Zeichen umwandeln und dann
eingeben! Tja, und die bei Microsoft sind die Einzigen,
die so blöd waren, dies nicht zu bedenken!
Okay, und dies wird nun bei den Unicode-Bug
ausgenutzt. Also greift der Angreifer per Unicode-Bug
dann auch die cmd.exe (=das Dos von Windows) zu
und verwendet es für seine eigenen Zwecke!
Aber genug zum Bug, den Angreifer aus nutzen! Viel
wichtiger ist die Tatsache, das dieser Angriff immer
über ein paar Eckpfeiler geht. Diese Eckpfeiler sind im
allgemeinen folgende Dateien, die ein Angreifer
immer nutzt!
Code:
debug.exe MS-DOS Debugger
edit.exe MS-DOS Editor
edlin.exe MS-DOS Editor
ftp.exe FTP Client
finger.exe Finger Client
nbtstat.exe Anzeige von NetBT-Statistiken
qbasic.exe MS-DOS Quick Basic
rpc.exe, rexec.exe, rsh.exe R-Utilities
setfixup.exe undokumentiert
telnet.exe Telnet Client
tftp.exe Trivial FTP Client
arp.exe Bearbeiten des ARP-Caches
at.exe Scheduler
cacls.exe Setzen von Dateiberechtigungen
cmd.exe Kommandozeilen-Shell
ipconfig.exe Anzeigen der IP-konfiguration
net.exe, net1.exe Konfiguration von Benutzern und Shares
netstat.exe Anzeigen von Netzinformationen
nslookup.exe Tool zur DNS-Namensauflösung
ntbackup.exe Backup-Programm
ping.exe ICMP Echo Utility
rdisk.exe Zum Herstellen von Rettungsdisketten
regedit.exe, regedt32.exe Registry-Editoren
route.exe Konfigurieren der Routingtables
runonce.exe Einmaliges Starten von Programmen
syskey.exe Verschlüsseln der SAM-Datenbank
tracert.exe Traceroute Utility
winmsd.exe Anzeigen von Systeminformationen
xcopy.exe Kopiert Dateien
cscript.exe, wscript.exe Windows Scripting Host
All diese Dateien sind Dateien, die von dem Angreifer
genutzt werden. Man sollte diese Dateien am besten
auf eine CD brennen und dann löschen. Und dann die
Dateien nur noch raufkopieren von der CD, wenn man
sie benötigt.
Desweiteren nutzt ein Angreifer immer die Standard-
Verzeichnisse. Dies kann man umgehen, indem man
virtuelle Verzeichnisse mit beschränkten Rechten
anlegt!
Code:
ftpdata --> e:\ftproot\ftpdata
incoming --> e:\ftproot\incoming
bilder --> e:\ftproot\bilder
skripte --> e:\ftproot\skripte
start --> e:\ftproot\start
Schreib- und Löschrechte für diese Verzeichnisse nur
für System und Amdinistrator erlauben. Dann, vor
allem, auch den IIS nicht unter Administrator-Session
laufen lassen, sondern einen eigenen Account den IIS-
Betrieb einrichten, weil der Angreifer automatisch
die Rechte erlangt, die das Programmes erlangt,
welches er abschiesst/missbraucht!
Desweiteren sollte man sich noch eine Datei
schreiben, die man die Logfiles des IIS
automatisch bei jedem Reboot des Windows-OS in
eine anderes Verzeichnis kopiert/spiegelt und
dann auch noch zusätzlich mit einem Schreibschutz
versieht. Damit man zumindestens nach einem
erfolgreichen Angriff die Spuren des Angreifers
auswerten kann! Weil nach einem erfolgreichen
Angriff wird der Angreifer immer versuchen seine
Spuren, die hinterlassen hat zu vernichten.
Code:
----logs_save.bat----
echo off
copy /Y c:\winnt\logfile\W3SVC1\*.* d:\inet-server\logs\
attrib d:\inet-server\logs\*.* +H +A +R +S /S /D
---------------------
Und dann einfach die log_save.bat in
Programme\Autostart\ legen!
Auch sollte man, gerade als Admin eines WebServer,
die Logs, die da so produziert werden, auch mal
anschauen! Allgemein erstmal der Aufbau der Log-
Dateien des IIS.
Orte der Logfiles:
c:\winnt\system32\logfile\msftpsvc1\*.log ( = Logfile des FTP-Servers)
c:\winnt\system32\logfile\w3svc1\*.log ( = Logfile des HTTP-Servers)
Code:
[DATE] [TIME] [c-IP] [c-User] [s-IP] [s-Port] [cs-Method] [cs-Uri-Stem] [cs-Uri-Query] [sc-Status] [cs-UserAgent]
2002-07-06 18:18:03 127.0.0.1 - 127.0.0.1 80 GET /iisHelp/iis/misc/default.asp - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-06 18:18:03 127.0.0.1 - 127.0.0.1 80 GET /iisHelp/iis/misc/contents.asp - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-06 18:18:03 127.0.0.1 - 127.0.0.1 80 GET /iisHelp/iis/misc/navbar.asp - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-06 18:18:03 127.0.0.1 - 127.0.0.1 80 GET /iisHelp/iis/htm/core/iiwltop.htm - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-06 18:18:03 127.0.0.1 - 127.0.0.1 80 GET /iisHelp/iis/misc/Cont.gif - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-06 18:18:03 127.0.0.1 - 127.0.0.1 80 GET /iisHelp/iis/misc/NoIndex.gif - 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
So, jetzt zu einer Beispiel-Log-File (mit special Thx an
den chinesischen Server, von dem sie stammen!!!):
Code:
#Fields: date time c-ip cs-username s-ip s-port cs-method cs-uri-stem cs-uri-query sc-status cs(User-Agent)
2002-07-18 17:36:20 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /winnt/system32/cmd.exe /c+dir 404 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:36:49 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:37:26 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:39:02 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:39:10 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:39:20 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:39:33 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:39:42 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:39:50 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
2002-07-18 17:39:58 XXX.XXX.XXX.XXX - YYY.YYY.YYY.YYY 80 GET /scripts/..%5c..%5cwinnt/system32/cmd.exe /c+dir 200 Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0)
Hier sieht man sehr schön die IP des Angreifers
XXX.XXX.XXX.XXX, die IP des Servers YYY.YYY.YYY.YYY
und den verwendeten Unicode-Bug, hier: ..%5c..%5c !
Dann als Nächstes kommt dann der Befehl, der
ausgeführt wurde. Und die Zahl da hinter gibt die
Antwort des Servers auf den Request aus. Hier mal
eine Zusammenstellung der wichtigsten möglichen
Antworten des Servers auf die Requests.
[http://www.webmeister.ch/server/error_code.htm]
Ein weiteres Tool, welches man zum Schutz des IIS
installieren sollte, ist UrlScan von Microsoft. Man kann
es hier downloaden.
[http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools/urlscan.asp]
Dabei ist aber zu beachten, dass man zuerst UrlScan
1.0 oder UrlScan 2.0 installiert haben muss, bevor
man die neuste Version UrlScan 2.5 installieren bzw.
besser gesagt, darauf upgraden kann!
Noch günstiger ist es, wenn man gleich das Komplett-
Packet "IIS Lockdown Wizard" installiert.
Alternativ kann man natürlich auch "sichere" Web-
Server wie Apache, Jana Server, thttpd, mathopd, boa,
stronghold, IPlanet (netcape enterprise), roxen, zeus,
ibm httpd. Diese weisen zwar weniger Bugs auf als
der IIS, aber man sollte sich zu mindestens auch mal
mit deren Sicherheit befassen und eventuell not-
wendige Patches einspielen!
So, das war nur mal eine kurze Einführung zur
Sicherung des IIS.
Quellen & Links:
----------------
[1]http://www.securityfocus.com
[2]http://www.neworder.box.sk
[3]http://support.microsoft.com/default.aspx?xmlid=fh;DE;iisin2&ln=de
[4]http://www.rz.tu-cottbus.de/urz/security/Win2000IIS.html
[5]http://www.apache.org
[6]http://www.janaserver.de