Niniejsze opracowanie omawia zagadnienia związane z implementacją i zabezpieczaniem serwera internetowego na platformie Windows Server 2003.

Od kilku już wersji systemy serwerowe z rodziny Windows stanowią zaawansowaną platformę do publikowania w Internecie. Windows Server 2003 kontynuuje ten trend, co więcej - stanowi jednolitą platformę pozwalającą na uruchomienie bezpiecznej witryny internetowej niemal "prosto z pudełka".

Zabezpieczanie serwera internetowego nie jest czynnością jednorazową. Jest to proces, który trwa nieustannie. Administrator dysponuje ograniczoną ilością czasu i dostępnych zasobów, w przeciwieństwie do jego potencjalnych przeciwników. Potwierdza się tu stara zasada, o tym, że system jest tak bezpieczny jak jego najsłabsze ogniwo. Broniąc serwera trzeba pamiętać o setkach różnych spraw, atakując go wystarczy znaleźć ten jeden słaby punkt. Walka administratora z hackerem jest nierówna, co nie znaczy jednak, że jest z góry skazana na niepowodzenie. Zalecenia i narzędzia przedstawione w tym artykule mają za cel przynajmniej wyrównanie szans.

W pierwszej części artykułu przedstawię nowe elementy systemu Windows Server 2003 związane z jego pracą w Internecie. Następnie zaprezentuję ogólne zalecenia związane z instalowaniem i konfigurowaniem systemu Windows Server 2003. Główna część tekstu będzie poświęcona zabezpieczaniu serwera IIS i aplikacji internetowych. Na końcu artykułu można będzie znaleźć listę odnośników do materiałów i narzędzi dostępnych w Internecie i pomocnych w codziennej pracy administratora.

Nowości w Windows Server 2003

W systemie Windows Server 2003 wprowadzono wiele nowych rozwiązań znacznie zwiększających jego wartość jako serwera internetowego.

Dostępność i niezawodność

Architektura odporna na błędy - IIS 6.0 izoluje od siebie witryny Web i aplikacje grupując je w tzw. pule aplikacji. Pule pozwalają na wygodne administrowanie grupami witryn oraz zwiększają niezawodność, ponieważ błędy występujące w aplikacji w jednej z pól nie mogą spowodować błędów w innych pulach ani w samym serwerze.

Monitorowanie stanu - IIS 6.0 okresowo kontroluje stan puli aplikacji i potrafi automatycznie zrestartować te z nich, które uległy awarii. Dodatkowo, jeżeli takie awarie występują zbyt często w danej jednostce czasu, serwer może je automatycznie wyłączyć.

Automatyczne odzyskiwanie procesów - IIS 6.0 automatycznie restartuje awaryjne witryny i aplikacje na podstawie elastycznie definiowalnych kryteriów, takich jak wykorzystanie CPU lub zużycie pamięci. Proces ten przebiega niezauważalnie dla użytkowników: ich żądania są kolejkowane, a połączenia TCP/IP z klientami są utrzymywane podczas restartu aplikacji: pozwala to na efektywne ukrycie niestabilności aplikacji przez klientem.

Zarządzanie

Pliki konfiguracyjne oparte na XML - przechowywanie metabazy w tekstowych plikach XML zwiększa łatwość backupu i odtwarzania stanu serwera po awarii. Niemniej istotne jest ułatwienie wyszukiwania błędów w konfiguracji i naprawy uszkodzonych plików konfiguracyjnych. Bezpośrednia edycja plików metabazy pozwala na łatwe i szybkie zarządzanie serwerem internetowym.

Edycja "na gorąco" - IIS 6.0 umożliwia administratorom zmienianie konfiguracji serwera podczas jego pracy. Przykładowo, można tworzyć nowe witryny, katalogi wirtualne lub zmieniać konfigurację pól aplikacji i procesów roboczych - wszystko bez zakłócania przetwarzania żądań klientów.

Zarządzanie z wiersza poleceń lub skryptu - administratorzy serwera IIS 6.0 mogą wykonywać wiele typowych czynności korzystając z wiersza poleceń. Za pomocą jednego polecenia można zarządzać wieloma lokalnymi lub zdalnymi komputerami. IIS 6.0 udostępnia także kompletne środowisko skryptowe, co pozwala na automatyzację najczęściej wykonywanych zadań bez użycia graficznego interfejsu użytkownika.

Obsługa WMI - IIS 6.0 w pełni obsługuje interfejs WMI (Windows Management Instrumentation), dając administratorom dostęp do ważnych danych związanych, takich jak mierniki wydajności lub pliki konfiguracyjne. Interfejsy WMI, podobne w swojej naturze do interfejsów ADSI (wciąż dostępnych) mogą być używane w skryptach administracyjnych i pozwalaja m. in. na modyfikację metabazy w formacie XML.

Konsolidacja serwerów

Skalowalność - w serwerze IIS 6.0 znacznie usprawniono sposób wykorzystania zasobów systemu. Przykładowo, serwer nie alokuje zasobów podczas inicjalizacji. Na pojedynczym komputerze w którym działa IIS 6.0 może być uruchomionych znacznie więcej witryn obsługiwanych przez znacznie większą liczbę jednocześnie działających procesów roboczych. Uruchamianie i zatrzymywanie serwera następuje szybciej niż w poprzednich wersjach IIS. Wszystkie te usprawnienia zwiększają skalowalność serwera używającego IIS 6.0.

Nowy sterownik HTTP.sys działający w trybie jądra - W systemie Windows 2003 Server wprowadzono nowy, działający w trybie jądra, sterownik obsługujący stos protokołu HTTP. Jego zadaniem jest przetwarzanie i cachowanie żądań HTTP. Serwer IIS 6.0 korzysta z usług tego sterownika tak, aby zmaksymalizować liczbę obsługiwanych żądań w jednostce czasu.

Web gardens - IIS 6.0 umożliwia takie skonfigurowanie procesów roboczych, aby kilka z nich obsługiwało określoną pulę aplikacji. Konfiguracja taka jest określana jako "Web Garden".

Wyznaczanie procesorów - umożliwia procesom roboczym IIS 6.0 działanie na określonych mikroprocesorach (CPU). Możliwe jest też rozszerzenie konfiguracji typu "Web garden" tak, aby określone grupy procesorów obsługiwały określone pule aplikacji.

Szybsze tworzenie aplikacji

Integracja ASP.NET i IIS - W systemie Windows 2003 polepszona została integracja z ASP.NET i .NET Framework: architektura obsługi żądań została zintegrowana z IIS 6.0.

Usługi XML Web Services - IIS stanowi wydajną platformę dla usług XML Web Services. Usługa taka umożliwia zdalne korzystanie z funkcji udostępnianych przez aplikacje działające w serwerze. Dzięki temu możliwe jest wyeksponowanie interfejsów programistycznych do danych lub logiki biznesowej tak, aby mogły zostać wykorzystane zdalnie przez aplikacje klienckie i serwerowe.

Zwiększone bezpieczeństwo

Serwer domyślnie zablokowany - IIS 6.0 jest znacznie bezpieczniejszy od poprzednich wersji. Aby zmniejszyć powierzchnię potencjalnego ataku, serwer ten jest domyślnie wyłączony i instalowany jedynie na wyraźne życzenie administratora. Po zainstalowaniu większość jego funkcji jest zablokowanych: możliwe jest serwowanie jedynie statycznej zawartości. Za pomocą narzędzi administracyjnych można włączać i wyłączać poszczególne funkcje serwera tak, aby odpowiadały konkretnym potrzebom danej organizacji.

Lista rozszerzeń usług - domyślna instalacja IIS nie pozwala na kompilowanie, uruchamianie ani serwowanie dynamicznej zawartości. Aby umożliwić serwowanie plików o określonych rozszerzeniach, należy każde z nich indywidualnie dodać do listy rozszerzeń - co skutecznie uniemożliwia wywołanie plików skojarzonych z dynamicznym rozszerzeniem, którego zabezpieczenia nie zostały skonfigurowane.

Domyślne konto o niskich uprawnieniach - domyślnie, wszystkie procesy robocze serwera IIS 6.0 działają w kontekście konta Network Service (Usługa sieciowa). Jest to nowe, wbudowane konto o ograniczonych uprawnieniach w kontekście systemu operacyjnego. Wszystkie funkcje wbudowane w ASP zawsze działają w używając nisko uprzywilejowanych kont (użytkownik anonimowy).

Windows Server 2003 w roli serwera aplikacji

W systemie Windows Server 2003 po raz pierwszy wprowadzono tzw. role serwera. Rola jest predefiniowanym zbiorem usług i ich ustawień pozwalających na świadczenie określonych usług. Aby wykorzystywać serwer w którejś z ról, należy zainstalować ją za pomocą kreatora konfigurowania serwera (Configure Your Server Wizard) i skonfigurować przy użyciu narzędzia zarządzania serwerem (Manage Your Server). Z punktu widzenia niniejszego oprogramowania będzie nas interesowała rola serwera aplikacyjnego (Application Server role).

Serwer aplikacyjny to zbiór kluczowych technologii składających się na infrastrukturę i usługi niezbędne do działania aplikacji udostępnianych przez dany serwer. Typowo, serwer aplikacji udostępnia następujące usługi:

• Pule zasobów (przykładowo pule połączeń lub pule obiektów),
• Zarządzanie transakcjami rozproszonymi,
• Asynchroniczna komunikacja między programami, typowo przy wykorzystaniu kolejkowania komunikatów,
• Model aktywacji obiektów na żądanie (Just-in-time),
• Automatycznie tworzone interfejsy XML Web Services pozwalające na korzystanie z obiektów biznesowych,
• Usługi monitorowania stanu aplikacji i odzyskiwania ich stabilności po awarii,
• Funkcje zabezpieczeń.

Rodzina serwerów Windows Server 2003 zawiera serwer aplikacji udostępniający całą wyżej wymienioną funkcjonalność wraz z innymi usługami umożliwiającymi tworzenie, wdrażanie i bieżące zarządzanie usługami XML Web Services, aplikacjami Web oraz aplikacjami rozproszonymi.

Po włączeniu roli serwera aplikacyjnego zostanie zainstalowana usługa IIS (Internet Information Server) oraz dodatkowe komponenty i usługi, takie jak COM+ i ASP.NET. IIS wspólnie z Windows Server 2003 tworzą zintegrowaną, niezawodną, bezpieczną i łatwą w zarządzaniu podstawę dla serwera sieci Web działającego w intranecie, Internecie oraz poprzez ekstranet. IIS może stanowić bazę do tworzenia platformy komunikacyjnej lub dynamicznych aplikacji internetowych.

Konfigurowanie roli serwera aplikacji

Przed uruchomieniem roli serwera aplikacyjnego należy sprawdzić, czy:

• Wszystkie istniejące w komputerze woluminy dyskowe korzystają z systemu NTFS. Woluminy FAT32 nie są bezpieczne, nie obsługują kompresji plików i folderów, limitów dyskowych, szyfrowania plików ani indywidualnie określanych uprawnień. Aby sprawdzić rodzaj systemu plików należy kliknąć prawym przyciskiem myszy ikonę woluminu dyskowego i wybrać polecenie Właściwości (Properties).
• Komputer ma łączność z siecią i przypisany statyczny adres IP.

W poniższej tabeli opisano podstawowe fakty związane z rolą serwera aplikacyjnego:

Aby skonfigurować rolę serwera aplikacyjnego, należy uruchomić kreator Configure Your Server Wizard (dostępny w menu Administrative Tools), kliknąć Custom Configuration na stronie Configuration Options, a następnie wybrać Application Server na stronie Server Role i kliknąć Next.

Na następnej zakładce mamy możliwość zainstalowania komponentów opcjonalnych:

• FrontPage Server Extensions - jest to zestaw dodatków umożliwiających użytkownikom administrowanie i dokonywanie publikacji na witrynie internetowej zdalnie, z komputera klienckiego. Tą opcję należy włączyć, jeżeli użytkownicy mają mieć możliwość tworzenia witryn internetowych lub aplikacji webowych zdalnie za pośrednictwem Internetu. Z punktu widzenia bezpieczeństwa serwera nie zaleca się instalowania rozszerzeń FrontPage na serwerze dostępnym publicznie w Internecie.
• Enable ASP.NET - ASP.NET jest platformą służącą do budowy zaawansowanych aplikacji webowych. Oferuje ona nowy model programistyczny i infrastrukturę pozwalającą na tworzenie bezpiecznych, skalowalnych i stabilnych aplikacji. Tą opcję należy zaznaczyć, jeżeli konfigurowany serwer ma udostępniać aplikacje korzystające z ASP.NET. Jeżeli na etapie konfigurowania serwera jeszcze tego nie wiadomo, to można pozostawić ją nie włączoną - ASP.NET można skonfigurować w dowolnym momencie za pomocą aplikacji IIS Manager.

Po zakończeniu należy kliknąć Next.

Konfigurowanie serwera IIS

Konfigurowanie serwera IIS należy rozpocząć od utworzenia witryn i aplikacji oraz niezbędnych katalogów wirtualnych. Dla utworzonych aplikacji można kontrolować sposób przechowywania danych sesji i obsługi błędów, włączyć lub wyłączyć debugowanie, skonfigurować nagłówki HTTP i wiele innych parametrów. Na każdym etapie tego procesu należy pamiętać o zagadnieniach bezpieczeństwa, omówionych w dalszej części tego tekstu - w podrozdziale Zabezpieczanie witryn i aplikacji internetowych.

Tworzenie witryn webowych

Po zainstalowaniu serwera IIS 6.0 na twardym dysku tworzony jest domyślny katalog domowy oraz skojarzona z nim witryna webowa. Możliwe jest utworzenie dodatkowych witryn za pomocą menedżera IIS. Nie powoduje to wygenerowania żadnej zawartości witryny: tworzona jest jedynie struktura katalogów i pliki konfiguracyjne. Aby opublikować zawartość witryny należy umieścić w jej katalogu domowym (lub nowym katalogu wirtualnym) odpowiednie pliki.

Aby utworzyć nową witrynę webową, należy:

1. W menedżerze IIS rozwinąć węzeł komputera lokalnego i kliknąć prawym przyciskiem myszy folder Web Sites.
2. Wybrać polecenie New, a następnie Web Site. Zostanie uruchomiony kreator Web Site Creation Wizard.
3. Kliknąć Next.
4. W polu Description wpisać tytuł (opis) witryny, a następnie kliknąć Next.
5. Wpisać adres IP, port TCP i nagłówek hosta (np. www.mojawitryna.pl) z którymi ma być skojarzona nowa witryna.
   Domyślną wartością adresu IP jest (All Unassigned), co oznacza że witryna będzie wyświetlana niezależnie od adresu IP zarządanego przez klienta - pod warunkiem jednak, że pokrywać się będzie wartość portu i nagłówka hosta.

   

   
   
   
6. Kliknąć Next.
7. W polu Path wpisać ścieżkę katalogu lub kliknąć Browse i wskazać katalog który zawiera, lub będzie zawierał, zawartość witryny.
8. Kliknąć Next.
9. Wybrać opcje odpowiadające uprawnieniom, jakie mają otrzymać klienci witryny, a następnie kliknęć Next.
   Informacje o uprawnieniach związanych z witryną można znaleźć w dalszej części artykułu - "Określanie uprawnień witryny IIS".
10. Kliknąć Finish.
11. Aby zmienić powyższe ustawienia później, należy kliknąć prawym przyciskiem myszy witrynę i wybrać polecenie Properties.

Tworzenie katalogów wirtualnych

Typowo, zawartość witryny internetowej jest przechowywana w jej katalogu domowym. Może się jednak pojawić konieczność umieszczenia jej w innym katalogu lub wręcz na innym komputerze. W tym celu należy utworzyć tzw. katalog wirtualny - czyli pewnego rodzaju wskaźnik na fizyczny katalog znajdujący się poza katalogiem domowym witryny lub aplikacji. Można to zrobić na dwa sposoby: za pomocą menedżera IIS lub przy użyciu Eksploratora Windows.

Aby utworzyć katalog wirtualny przy użyciu menedżera IIS, należy:

1. W menedżerze IIS kliknąć prawym przyciskiem myszy witrynę lub folder, do którego ma zostać dodany katalog wirtualny, wybrać polecenie New oraz Virtual Directory. Zostanie uruchomiony kreator Virtual Directory Creation Wizard.

   

2. Kliknąć Next.
3. W polu Alias wpisać nazwę katalogu wirtualnego. Jest to nazwa, którą będzie widział użytkownik aplikacji - dlatego powinna być krótka i łatwa do wpisania.
4. Kliknąć Next.
5. W polu Path wpisać ścieżkę do katalogu fizycznego lub kliknąć Browse i wskazać go za pomocą myszki.
6. Kliknąć Next.
7. Zaznaczyć opcje odpowiadające uprawnieniom dostępu, które mają zostać przypisane użytkownikom katalogu wirtualnego, a następnie kliknąć Next.
   Z punktu widzenia bezpieczeństwa warto gdy tylko jest to możliwe zaznaczać jedynie uprawnienie odczytu (Read).
8. Kliknąć Finish. Katalog wirtualny zostanie utworzony poniżej folderu wybranego w pierwszym kroku.

Aby utworzyć katalog wirtualny za pomocą Eksploratora Windows, należy:

1. Uruchomić Eksploratora Windows.
2. Kliknąć prawym przyciskiem myszy folder, który ma zostać katalogiem wirtualnym i wybrać polecenie Properties.

   

   
   
   
3. Na zakładce Web Sharing kliknąć Share This Folder. Zostanie wyświetlone okno dialogowe Edit Alias.

   

   
   
   
4. W polu Alias wpisać nazwę katalogu wirtualnego.
5. W sekcji Access permissions określić uprawnienia przypisane do katalogu wirtualnego.
6. W sekcji Application permissions określić typ dostępu przypisany do katalogu wirtualnego.
7. Kliknąć dwa razy OK.

Konfigurowanie obsługi stanu sesji ASP.NET

Z punktu widzenia serwera internetowego, każde żądanie HTTP wysyłane przez przeglądarkę klienta jest niezależne od pozostałych. Aby aplikacja internetowa mogła funkcjonować z uwzględnieniem wszystkich wcześniejszych akcji użytkownika, konieczne jest zarządzanie jej stanem. Można tego dokonać przekazując każdorazowo informacje o stanie aplikacji za pomocą ukrytych pól formularza lub przenieść część tego obciążenia na serwer: dane sesji są wtedy przechowywane w pamięci serwera webowego i kojarzone automatycznie z kolejnymi żądaniami klienta na podstawie identyfikatora zapisanego na jego komputerze w pliku cookie lub przekazywanego w URL-u żądań.

Stan sesji w ASP.NET umożliwia współdzielenie danych związanych z sesją użytkownika pomiędzy wszystkimi serwerami webowymi w farmie serwerów lub pomiędzy różnymi procesami roboczymi w jednym serwerze webowym. Klienci mogą korzystać z różnych serwerów w farmie przy poszczególnych żądaniach HTTP i wciąż mieć dostęp do kompletnych danych sesji. W zależności od potrzeb można wybrać jedną z kilku metod przechowywania stanu aplikacji.

Wybór metody przechowywania stanu aplikacji

ASP.NET obsługuje następujące metody przechowywania stanu aplikacji:

• Wewnątrz procesu (In-process). Proces utrzymujący stan aplikacji działa w tym samym procesie roboczym, co aplikacja ASP.NET. Ta metoda przechowywania stanu działa podobnie, jak to ma miejsce przy aplikacjacj ASP. Jeżeli proces roboczy aplikacji zostanie odświeżony, to wszystkie informacje o stanie sesji zostaną utracone.
• Na zewnątrz procesu (Out-of-process). Stan sesji jest utrzymywany przez proces oddzielny od tego, w którym działa aplikacja ASP.NET, co więcej, może to zachodzić także w innym serwerze. Po odświeżeniu procesu roboczego aplikacji, informacje o jej stanie są przywracane.

Stan sesji ASP.NET konfiguruje się za pomocą atrybutu mode w sekcji <sessionState> pliku Machine.config - dla wszystkich aplikacji działających na serwerze - lub w plikach Web.config poszczególnych aplikacji. Ustawienia dotyczące sesji we właściwościach aplikacji (dostępnych z poziomu menedżera IIS) mają zastosowanie jedynie do aplikacji ASP. Aplikacje ASP.NET i ASP nie mogą współdzielć stanu sesji.

W efekcie do wyboru pozostają następujące metody przechowywania stanu sesji:

• Wewnątrz procesu, lokalnie dla serwera webowego. Stan sesji ASP.NET jest obsługiwany i przechowywany w lokalnym serwerze webowym. Jest to tryb domyślny, przypominający sposób obsługi stanu sesji w klasycznych aplikacjach ASP.
  Metoda ta umożliwia współdzielenie stanu sesji pomiędzy procesami roboczymi w tzw. Web garden, ale nie pozwala na wspólne z niego korzystanie przez kilka serwerów w farmie.
• Na zewnątrz procesu, przy użyciu usługi ASP.NET State Service. Usługa ASP.NET State Service (aspnet_state.exe) działa jako usługa systemu Windows Server 2003. Można ją uruchamiać lokalnie na serwerze webowym, tak aby obsługiwała konfigurację typu Web garden, lub na oddzielnym serwerze, aby mogła obsługiwać farmę serwerów.
• Na zewnątrz procesu, przy użyciu serwera SQL. Stan sesji może być przechowywany także w bazie danych na komputerze z zainstalowanym serwerem Microsoft SQL Server. Podobnie jak w przypadku usługi ASP.NET State Service, metoda ta może obsługiwać zarówno konfigurację typu Web garden jak i farmy serwerów.

Porównanie metod przechowywania stanu aplikacji:

Ustawienia dotyczące stanu sesji

Aby wybrać metodę przechowywania stanu sesji, należy skonfigurować atrybut mode w sekcji sessionState w pliku Machine.config lub Web.config>. Dodatkowo, można w nim określić następujące atrybuty:

• cookieless - Ten atrybut określa, czy identyfikator sesji będzie przesyłany pomiędzy serwerem a klientem za pomocą pliku cookie. Domyślną wartością jest false.
• timeout - Ten atrybut określa, po jakim czasie bezczynności klienta sesja zostanie uznana za zakończoną. Domyślną wartością jest 20 minut.

Konfigurowanie przechowywania stanu sesji wewnątrz procesu

Aby skorzystać z tej metody, należy usunąć sekcję sessionState z pliku Web.config lub Machine.config, lub ustawić wartość atrybutu mode na InProc:

<configuration>
  <system.web>
     <sessionState 
         mode="InProc"
         cookieless="false" 
         timeout="20" 
     </sessionState>
  </system.web>
</configuration>

Konfigurowanie przechowywania stanu sesji na zewnątrz procesu przy użyciu usługi ASP.NET State Service

Aby skorzystać z tej metody, należy najpierw uruchomić usługę ASP.NET State Service za pomocą narzędzia Services, określając jej typ uruchomienia na automatyczny (Automatic). W zależności należy tego dokonać na serwerze lokalnym lub oddzielnym, co pozwoli na obsługiwanie farmy serwerów.

Aby skorzystać z usługi ASP.NET State Service, należy ustawić wartość atrybutu mode na StateServer, oraz określić wartości atrybutów stateConnectionString i stateNetworkTimeout. Pierwszy z nich pozwala na podanie adresu IP i portu TCP serwera stanu (domyślny port to 42424), a drugi - to czas (w sekundach) w którym utrzymywane jest połączenie TCP/IP z serwerem stanu w przypadku braku aktywności.

Przykładowa konfiguracja:

<configuration>
  <system.web>
     <sessionState 
         mode="StateServer"
         cookieless="false" 
         timeout="20" 
         stateConnectionString="tcpip=127.0.0.1:42424" 
         stateNetworkTimeout=”10”
     </sessionState>
  </system.web>
</configuration>

Konfigurowanie przechowywania stanu sesji na zewnątrz procesu przy użyciu serwera SQL

Aby skorzystać z tej metody, trzeba najpierw utworzyć bazę danych przechowującą stany sesji na serwerze SQL. W tym celu należy uruchomić za pomocą aplikacji SQL Query Analyzer skrypt InstallSqlState.sql, który utworzy bazę danych ASPState i wszystkie niezbędne procedury składowane oraz doda tabele ASPStateTempApplications oraz AspStateTempSessions do bazy danych tempdb. Skrypt InstallSqlState.sql znajduje się domyślnie w katalogu systemroot\Microsoft.NET\Framework\wersja.

Następnie należy ustawić w pliku Web.config lub Machine.config wartość atrybutu mode na SQLServer oraz dodać atrybut sqlConnectionString:

<configuration>
  <system.web>
     <sessionState 
         mode="SQLServer"
         cookieless="true" 
         timeout="20" 
         sqlConnectionString="data source=localhost;
                              Integrated Security=SSPI;
                              Initial Catalog=ASPState" 
     </sessionState>
  </system.web>
</configuration>

Określanie domyślnego dokumentu

Domyślny dokument to plik, który zostanie przesłany do przeglądarki klienta jeżeli w URL-u zostanie podana jedynie nazwa katalogu. Możliwe jest skonfigurowanie kilku nazw dokumentu domyślnego - w tym przypadku do klienta zostanie wysłany ten, który jako pierwszy zostanie znaleziony w żądanym folderze:

Domyślny dokument dla witryny, aplikacji lub folderu można skonfigurować w menedżerze IIS po kliknięciu wybranego obiektu prawym przyciskiem myszy i wybraniu polecenia Properties a następnie zakładki Documents. Na tej samej zakładce można też wskazać plik, który będzie doklejany jako stopka do każdej udostępnianej strony.

Określanie czasu ważności zawartości i innych nagłówków HTTP

Wraz z zawartością żądanego pliku, serwer IIS wysyła do przeglądarki klienta różne nagłówki HTTP, informujące ją o tym, w jaki sposób ma przetwarzać udostępnioną zawartość. Jeden z najczęściej używanych nagłówków określa czas życia tej zawartości, tzn. okres, przez jaki może ona być pobierana z cachce przeglądarki. Po upływie tego okresu, zawartość spod danego adresu URL jest ponownie pobierana z serwera internetowego. Aby określić czas życia zawartości witryny, aplikacji lub folderu, należy kliknąć dany obiekt prawym przyciskiem myszy i wybrać polecenie Properties, a następnie wskazać zakładkę HTTP Headers.

Na tej samej zakładce można także skonfigurować dodatkowe nagłówki HTTP, np. informacyjne, związane z rozszerzeniami obsługiwanymi przez serwer, a także ustawienia dotyczące klasyfikacji treści.

Tworzenie własnych stron informujących o błędach

IIS pozwala na utworzenie własnych stron informujących użytkownika aplikacji o błędach. Po ich utworzeniu, należy zmodyfikować odpowiednie wpisy na zakładce Custom Errors we właściwościach witryny, aplikacji lub katalogu:

Konfigurowanie wydajności aplikacji

W zależności od potrzeb możliwe jest także skonfigurowanie pewnych ustawień dotyczących wydajności aplikacji webowej. Są one dostępne na zakładce Performance we właściwościach aplikacji:

Powyższe ustawienia pozwalają na ograniczenie przepustowości przeznaczonej do obsługi witryny internetewej oraz liczby jednoczesnych połączeń do serwera internetowego.

Eksportowanie i importowanie ustawień witryny do i z pliku

IIS 6.0 umożliwia zapisanie ustawień witryny, aplikacji, katalogu wirtualnego, witryny FTP lub puli aplikacji w postaci pliku XML. Po kliknięciu wybranego obiektu prawym przyciskiem myszy, należy wybrać polecenie All Tasks, a następnie Save Configuration to a File. Zostanie wyświetlone następujące okno dialogowe:

Następnie należy podać nazwę pliku i lokalizację, w którym ma on zostać zapisany (odpowiednio w polach FileName i Path) oraz opcjonalnie hasło zabezpieczające dostęp do tego pliku. Plik z konfiguracją można następnie zaimportować do innej lokalizacji na tym samym lub innym serwerze webowym. Pozwala to na szybkie migrowanie witryn i pul aplikacji pomiędzy serwerami.

Aby odtworzyć obiekt na podstawie pliku z konfiguracją, należy kliknąć prawym przyciskiem myszy kontener, w którym ma on zostać utworzony (np. folder Web Sites - gdy ma zostać odtworzona witryna, lub aplikację - gdy ma zostać odtworzony katalog wirtualny), wybrać polecenie New, a następnie rodzaj obiektu: np. Web Site (from file...) lub Virtual Directory (from file...).

Zabezpieczanie witryn i aplikacji internetowych

Funkcjonowanie wielu organizacji w dużym stopniu zależy od krytycznych aplikacji działających na serwerach webowych pod kontrolą IIS 6.0. Z tego powodu witryny i aplikacje internetowe wymagają maksymalnego poziomu zabezpieczeń jaki jest możliwy. Po zainstalowaniu usługi IIS 6.0, znajduje się ona w stanie zablokowanym i jest bardzo bezpieczna. W zależności od potrzeb konkretnych aplikacji i witryn internetowych może zajść potrzeba skonfigurowania zabezpieczeń IIS tak, aby były mniej restrykcyjne. Z drugiej strony, może być konieczne takie skonfigurowanie witryn i aplikacji aby były dodatkowo zabezpieczone przez uwierzytelnienie i autoryzację użytkowników, określające jakie dane i czynności są dla nich dozwolone.

Aby zapewnić bezpieczeństwo witryny lub aplikacji internetowej, konieczne jest zabezpieczenie całego serwera webowego - w tym wszystkich działających w nim witryn i aplikacji. Może także pojawić się konieczność zabezpieczenia ich przed innymi witrynami i aplikacjami działającymi w obrębie tego samego serwera. Po implementacji zabezpieczeń konieczne jest wdrożenie praktyk pozwalających na ciągłe utrzymanie stanu bezpieczeństwa serwera.

Proces zabezpieczania witryn i aplikacji internetowych można podzielić na sześć etapów: minimalizacja powierzchni ataku, uniemożliwienie nieautoryzowanego dostępu, izolowanie witryn i aplikacji, konfiguracja uwierzytelniania użytkowników, szyfrowanie tajnych danych i w końcu - ciągły proces utrzymania stanu bezpieczeństwa. W dalszej części tego dokumentu zostaną omówione kolejno te etapy.

Minimalizacja powierzchni ataku

Po zainstalowaniu systemu Windows Server 2003 i IIS 6.0 z domyślnymi ustawieniami, serwer Web jest skonfigurowany tak aby udostępniał jedynie statyczną zawartość. Jeżeli odpowiada to potrzebom, to domyślna konfiguracja minimalizuje powierzchnię ataku eksponowaną przez serwer. W przypadku, gdy witryny i aplikacje mają zawierać dynamiczną zawartość, lub gdy występuje konieczność użycia dodatkowych komponentów serwera IIS, to konieczne jest włączenie dodatkowych funkcji. Należy wówczas pamiętać o konieczności minimalizowania powierzchni ataku serwera webowego, czyli zakresu w jakim jest on wystawiony na działania potencjalnych atakujących.

Nadmierne zmniejszenie powierzchni ataku skutkuje zablokowaniem funkcjonalności wymaganej przez witryny i aplikacje hostowane przez serwer. Z tego powodu należy tak konfigurować serwer webowy, aby były w nim włączone tylko usługi niezbędne dla działania witryn i aplikacji - i żadne inne.

Włączenie tylko niezbędnych składników i usług Windows Server 2003

Na powierzchnię ataku serwera webowego wpływają m. in. komponenty i usługi włączone w systemie operacyjnym. Jeżeli serwer jest dedykowanym serwerem internetowym, to warto zmodyfikować domyślne ustawienia usług i komponentów:

Włączenie tylko niezbędnych składników i usług IIS

Serwer IIS 6.0 oprócz usługi WWW zawiera także inne komponenty i usługi - przykładowo usługę FTP i SMTP. Poszczególne składniki IIS można włączać za pomocą narzędzia Add or Remove Windows Components w Panelu sterowania.

Należy włączać jedynie te składniki IIS 6.0, które są wymagane przez witryny i aplikacje webowe. Aktywowanie zbędnych komponentów zwiększa powierzchnię ataku serwera.

Jeżeli jakaś witryna lub aplikacja nie działa prawidłowo w serwerze IIS 6.0 i podejrzewa się, że przyczyną jest brak jakiejś usługi lub komponentu tego serwera, to należy:

1. Włączyć komponent, którego brak prawdopodobnie powoduje problemy,
2. Sprawdzić, czy aplikacja lub witryna zaczęła działać prawidłowo,
3. Jeżeli tak, to szczegółowo skonfigurować zainstalowany komponent tak, aby jego ustawienia były możliwie najbardziej restrykcyjne a jednocześnie nie zakłócały pracy aplikacji,
4. Jeżeli włączenie danego komponentu nie poprawiło sytuacji, to należy go ponownie zablokować i kontynuować poszukiwanie przyczyny problemów.

W poniższej tabeli wymieniono dostępne komponenty serwera aplikacyjnego. Polegając na podanych informacjach należy dla każdego z nich określić, czy jest on konieczny dla działania publikowanych aplikacji i witryn a następnie w zależności od tego włączyć go lub wyłączyć.

Komponenty serwera aplikacji (Application Server)

Komponenty serwera webowego IIS (Internet Information Services)

Komponenty usługi Message Queuing

Komponenty usługi Background Intelligent Transfer Service (BITS) server extension

Komponenty usługi World Wide Web Service

Włączenie tylko niezbędnych rozszerzeń serwera Web

Jeżeli aplikacja lub witryna webowa udostępnia rozszerzoną funkcjonalność (ponad serwowanie statycznych stron internetowych) - np. generowanie dynamicznej zawartości lub inne usługi - to dzieje się to przy użyciu tzw. rozszerzeń serwera Web.

Mając na uwadze bezpieczeństwo można włączać lub wyłączać poszczególne rozszerzenia serwera IIS 6.0. Świeżo zainstalowany serwer udostępnia jedynie zawartość statyczną. Funkcje związane z zawartością dynamiczną, takie jak ASP.NET, Server-Side Includes, publikowanie WebDAV lub rozszerzenia serwera FrontPage 2002, można włączać lub wyłączać korzystając z węzła Web Service Extensions w menedżerze IIS.

Włączenie wszystkich rozszerzeń serwera Web (indywidualnie lub przez zezwolenie na uruchamianie wszystkich nieznanych rozszerzeń ISAPI) pozwala na zachowanie maksymalnej zgodności z istniejącymi aplikacjami. Wadą takiego rozwiązania jest ryzyko związane ze zwiększeniem powierzchni ataku - dopuszcza ono włączenie funkcjonalności która nie jest niezbędna dla działania serwera.

W poniższej tabeli opisano podstawowe rozszerzenia serwera. Kierując się tym opisem należy włączyć te i tylko te z nich, które są potrzebne do działania udostępnionych aplikacji lub witryn internetowych.

Podstawowe rozszerzenia serwera Web

Jeżeli witryna lub aplikacja korzysta z rozszerzenia serwera, które nie znajduje się na podstawowej liście, to można je do niej dodać i skonfigurować je jako dozwolone (Allowed).

Włączenie tylko niezbędnych typów MIME

Serwer IIS 6.0 udostępnia jedynie te pliki statyczne, które zostały skonfigurowane na liście typów MIME (Multipurpose Internet Mail Extensions). Domyślna instalacja IIS 6.0 jest prekonfigurowana tak, aby rozpoznawała standardowy zestaw globalnych typów MIME. Możliwe jest ich definiowanie na poziomie witryny internetowej lub poszczególnych katalogów; niezależnie od siebie lub globalnie. IIS pozwala także na ich zmienianie, usuwanie i konfigurowanie dodatkowych typów MIME. Jeżeli IIS ma hostować plik o rozszerzeniu nie skojarzonym z typem MIME skonfigurowanym na liście typów dostępnych, to konieczne jest jego dodanie.

Konfiguracja zabezpieczeń systemu Windows Server 2003

Po zainstalowaniu, zabezpieczenia serwera Windows Server 2003 są skonfigurowane dość restrykcyjnie, mogą jednak nie być wystarczające dla witryn i aplikacji oferowanych przez serwer Web. Jeżeli spełniony jest któryś z poniższych warunków, to warto rozważyć zaostrzenie zabezpieczeń:

• Witryny i aplikacje webowe są używane przez użytkowników Internetu,
• Witryny i aplikacje webowe zawierają poufne informacje.

Aby zwiększyć poziom zabezpieczeń systemu Windows Server 2003, należy:

1. Zmienić nazwę konta Administrator
   Wbudowane konto Administrator istnieje domyślnie na każdym świeżo zainstalowanym serwerze webowym. Aby dokonać udanego ataku na serwer, wystarczy jedynie, że napastnik odgadnie skojarzone z nim hasło. Aby zabezpieczyć serwer przed tym zagrożeniem, należy zmienić nazwę konta administratora.
2. Upewnić się, czy nie zostało włączone konto gościa (Guest)
   Podczas domyślnej instalacji systemu Windows Server 2003, konto gościa pozostaje nieaktywne. Należy upewnić się, czy nie zostało ono po instalacji aktywowane.
3. Sformatować wszystkie woluminy dyskowe używając NTFS
   Z punktu widzenia bezpieczeństwa, głównym powodem dla którego wszystkie woluminy powinny być sformatowane przy użyciu NTFS jest fakt, że jest to jedyny system plików obsługiwany przez Windows Server 2003 jaki pozwala na zabezpieczanie plików i folderów. Partycje FAT i FAT32 nie mogą być zabezpieczane. Ponieważ witryny i aplikacje są przechowywane na serwerze w postaci plików i folderów, to zastosowanie NTFS pozwala zabezpieczyć je przed niepowołanym dostępem. Jeżeli w komputerze istnieją już woluminy sformatowane w systemie FAT lub FAT32, to należy je przekonwertować do NTFS. W tym celu należy posłużyć się narzędziem convert.exe.
4. Usunąć uprawnienia NTFS, które są przyznane grupie Everyone na katalogach głównych wszystkich woluminów dyskowych
   Domyślnie, grupa Everyone posiada uprawnienia odczytu i wykonywania na katalogach głównych wszystkich woluminach dyskowych. Może to skutkować potencjalnym zagrożeniem bezpieczeństwa, ponieważ nowo tworzone foldery dziedziczą te uprawnienia.
5. Usunąć wszelkie kompilatory i środowiska programistyczne
   Bardzo często kompilatory lub środowiska programistyczne zainstalowane na produkcyjnych serwerach Web mogą pozwolić napastnikom na przesłanie na serwer i skompilowanie plików programów.
6. Wyłączyć protokół NetBIOS over TCP/IP
   Aby zapobiec uruchomieniu na serwerze przez napastnika polecenia NetBIOS Adapter Status i uzyskania w ten sposób nazwy aktualnie zalogowanego użytkownika, należy wyłączyć protokół NetBIOS over TCP/IP we wszystkich publicznych połączeniach serwera.

Uniemożliwienie nieautoryzowanego dostępu

Każda witryna i aplikacja usługi IIS 6.0 jest przechowywana w formie grupy folderów i plików. Nieupoważniony dostęp do nich lub ich modyfikacja może stanowić poważne naruszenie bezpieczeństwa. Z tego powodu konieczne jest zagwarantowanie, że jedynie autoryzowani użytkownicy będą mieli bezpośredni dostęp do plików i katalogów witryn i aplikacji udostępnianych w danym serwerze webowym.

Przechowywanie zawartości na dedykowanym woluminie dyskowym

Pliki i foldery składające się na zawartość witryn i aplikacji webowych powinny być przechowywane na dedykowanym woluminie dyskowym, który nie zawiera systemu operacyjnego. Pozwala to na zapobiec atakom polegającym na trawersowaniu katalogów. Ataki te polegają na próbach przesłania do serwera webowego żądań pliku znajdującego się w innej gałęzi drzewa katalogów niż aplikacja webowa.

Przykładowo, plik Cmd.exe znajduje się w folderze %systemroot%\System32. Gdyby nie były zastosowane odpowiednie środki bezpieczeństwa, to napastnik mógłby być w stanie zażądać pliku %systemroot%\System32\Cmd.exe i skorzystać w ten sposób z funkcjonalności wiersza poleceń. Gdy zawartość witryny jest przechowywana na oddzielnym woluminie dyskowym, to tego typu ataki nie mogą zadziałać.

Oprócz zwiększenia bezpieczeństwa, umieszczenie zawartości witryn na oddzielnym woluminie ułatwia zadania administracyjne, takie jak tworzenie i odtwarzanie kopii bezpieczeństwa. Jeżeli dedykowany wolumin znajduje się na oddzielnym dysku fizycznym, to dodatkowo zostanie zmniejszone obciążenie napędu systemowego co poprawi wydajność całego serwera. Wciąż należy pamiętać o sformatowaniu tego dedykowanego woluminu przy użyciu NTFS. Katalog główny dedykowanego woluminu powinien mieć ustawione następujące uprawnienia:

• Grupa Administrators posiada uprawnienia pełnej kontroli.
• Wszystkie pozostałe uprawnienia są usunięte.

Po określeniu tych uprawnień, należy utworzyć folder (lub wyznaczyć jeden z istniejących folderów) który będzie przechowywał podfoldery dla poszczególnych aplikacji i witryn webowych.

Na tym etapie zabezpieczania serwera, jedynie członkowie grupy Administratorzy mają dostęp do zawartości serwera webowego. Proces określania uprawnień dla użytkowników, którzy będą korzystać z witryn i aplikacji zostanie opisany w dalszej części dokumentu - "Określanie uprawnień NTFS".

Określanie uprawnień witryny IIS

W serwerze IIS 6.0 możliwe jest określenie uprawnień witryny webowej, co pozwala na kontrolowanie dostępu do niej lub do katalogu wirtualnego. Z uprawnień tych korzysta IIS sprawdzając, jakiego rodzaju akcje są dozwolone - przykładowo, dostęp do kodu źródłowego skryptu lub przeglądanie folderów.

Uprawnień witryny webowej należy używać wraz z uprawnieniami NTFS, a nie zamiast nich. Możliwe jest określanie uprawnień witryny dla określonych witryn, katalogów i plików. W przeciwieństwie do uprawnień NTFS, są one skuteczne dla wszystkich użytkowników próbujących uzyskać dostęp do danej witryny internetowej.

Jeżeli uprawnienia witryny pozostają w konflikcie z uprawnieniami NTFS, to mają zastosowanie te bardziej restrykcyjne.

Aby określić uprawnienia witryny webowej, należy uruchomić menedżera IIS, kliknąć prawym przyciskiem myszy daną witrynę lub katalog wirtualny i wybrać polecenie Properties. Następnie należy skonfigurować opcje dostępne na zakładce Home Directory:

W poniższej tabeli opisano dostępne w IIS 6.0 uprawnienia witryny webowej:

Nakładanie ograniczeń na adresy IP i nazwy domen

Jedną z metod zabezpieczania witryn internetowych jest ograniczenie dostępu dla określonych adresów IP lub nazw domen. Możliwe jest bezpośrednie przyznanie lub zabronienie dostępu dla dowolnej kombinacji zakresów adresów IP i nazw domen.

Korzystając z tej metody można zabronić lub zezwolić na dostęp do witryny określonym komputerom lub organizacji. Sprawdza się to szczególnie w przypadku np. witryn ekstranetowych lub aplikacji dostępnych np. dla odległych oddziałów firmy. Restrykcje na adresy IP i nazwy domen można nakładać w kontekście całej witryny internetowej lub aplikacji - nie można ich konfigurować dla poszczególnych elementów (plików lub katalogów).

Aby określić uprawnienia witryny webowej, należy uruchomić menedżera IIS, kliknąć prawym przyciskiem myszy daną witrynę lub katalog wirtualny i wybrać polecenie Properties. Następnie należy kliknąć przycisk Edit w polu IP address and domain name restrictions i skonfigurować filtry adresów:

Filtry adresów IP i nazw domen są konfigurowane za pomocą ustawienia domyślnego oraz listy wyjątków. Jeżeli domyślnym ustawieniem będzie Granted access (dostęp dozwolony), to lista wyjątków będzie dotyczyła komputerów, którym odmawiamy dostępu do witryny - i na odwrót.

Z punktu widzenia wydajności, zaleca się korzystać z filtrów opartych na adresach IP. Gdy nie jest to możliwe, to trzeba określić filtr na podstawie nazwy domeny, powoduje to jednak, że serwer webowy będzie przy każdym żądaniu dokonywał odwrotnego wyszukiwania DNS aby ustalić domenę klienta na podstawie jego adresu IP. Spowoduje to znaczną degradację wydajności aplikacji.

Określanie uprawnień NTFS

System plików NTFS pozwala na określenie uprawnień, które będą widoczne dla serwera IIS i innych komponentów systemu Windows Server 2003. Na ich podstawie system operacyjny ustala, jaki rodzaj operacji użytkownik lub proces może wykonywać na określonym pliku lub folderze.

Uprawnień NTFS należy używać w połączeniu z uprawnieniami witryny webowej. Uprawnienia NTFS wpływają jedynie na prawa kont, którym przyznano lub odmówiono dostępu do zawartości witryny webowej lub aplikacji. Uprawnienia witryny mają zastosowanie do wszystkich użytkowników, którzy z niej korzystają.

Jeżeli uprawnienia witryny webowej pozostają w konflikcie z uprawnieniami NTFS, to mają zastosowanie te bardziej restrykcyjne.

Uprawnienia NTFS należy ustawić tak, aby:

• Administratorzy mogli zarządzać zawartością witryn i aplikacji.
• Użytkownicy mogli, co najmniej, odczytywać zawartość witryn i aplikacji.
• Tożsamość przypisana puli aplikami mogła, co najmniej, odczytywać zawartość witryn i aplikacji.

Witryny i aplikacje webowe mogą działać korzystając z tożsamości:

• Użytkownika, który z nich korzysta

  Aby ograniczyć dostęp do zasobów, takich jak określone strony webowe lub zawartość bazy danych przechowywana w serwerze SQL, należy uruchamiać witryny i aplikacje w kontekście tożsamości korzystającego z nich użytkownika. Wymaga to włączenia uwierzytelniania (np. zintegrowanego uwierzytelniania Windows lub uwierzytelniania pdstawowego) i wyłączenia dostępu anonimowego. Po wykonaniu tych czynności, witryny i aplikacje będą mogły przekazywać tożsamość użytkownika do innych serwerów - np. serwera SQL - lub do systemu plików. Korzystając z tej metody można uzależnić działanie witryny od tego, kto jej używa.

• Puli aplikacji, która jest używana przez witrynę lub aplikację

  Aby odizolować od siebie witryny i aplikacje działające w jednym serwerze webowym, należy uruchamiać je w kontekście tożsamości puli aplikacji. Korzystając z tej metody można zapobiec przed wpływaniem na siebie nawzajem przez poszczególne witryny i aplikacje, niezależnie od tego kto z nich korzysta. Więcej informacji na temat izolowania aplikacji można znaleźć w dalszej części niniejszego dokumentu.

Niezależnie od tożsamości której używa witryna lub aplikacja, konieczne jest przypisanie odpowiednich uprawnień NTFS do jej plików - tak, aby mogła działać w kontekście tej tożsamości bez zakłóceń. Typowo, uprawnienia NTFS przypisuje się grupie, do której należy większa liczba użytkowników. Korzystając z tej grupy można wygodnie określać uprawnienia do poszczególnych zasobów.

Główną wadą ograniczania dostępu na podstawie kont rzeczywistych użytkowników jest konieczność posiadania przez każdego z nich konta na serwerze webowym lub w domenie. Można to łatwo zrealizować w przypadku witryny intranetowej, jednak w serwerze webowym dostępnym w Internecie podejście to jest zdecydowanie niepraktyczne.

Aby uniemożliwić anonimowy dostęp do zasobów witryny internetowej, należy korzystając z uprawnień NTFS odmówić dostępu dla kont anonimowych: wbudowanego konta gościa (Guest), grupy Guests oraz kont anonimowych skonfigurowanych dla witryny IIS (typowo IUSR_NAZWA_KOMPUTERA).

Oprócz odmowy dostępu dla kont anonimowych, należy także wyłączyć uprawnienia do zapisu dla wszystkich użytkowników oprócz grupy administratorów witryny.

Rozwiązując problemy z uprawnieniami - przykładowo, gdy IIS odmówi dostępu do zawartości, która powinna być w danym kontekście widoczna - warto włączyć audyt dostępu do obiektów. Nieudane próby dostępu są wtedy rejestrowane w dzienniku zdarzeń zabezpieczeń (Security event log), wraz z nazwą konta które próbowało dostęp uzyskać. Po rozpoznaniu konta, z którym są związane problemy, należy przyznać mu odpowiednie uprawnienia NTFS, w oparciu o konkretne potrzeby.

Izolowanie witryn i aplikacji

Bardzo często zdarza się, że jeden serwer udostępnia więcej niż jedną witrynę lub aplikację. W takiej sytuacji poszczególne witryny i aplikacje wymagają określonego poziomu izolacji od siebie nawzajem.

Przykładowo, dostawca usług internetowych może hostować witryny setek różnych organizacji. Każda z nich będzie wymagała wysokiej izolacji od witryn innych klientów dostawcy usług.

Z tego powodu konieczne jest uniemożliwienie witrynom i aplikacjom działającym w jednym serwerze webowym wzajemnych, szkodliwych interakcji. Jeżeli IIS 6.0 działa w trybie izolacji procesów roboczych, to witryny i aplikacje webowe można odizolować od siebie umieszczając je w oddzielnych pulach aplikacji. Pula jest grupą witryn lub aplikacji obsługiwanych przez ten sam proces roboczy. Dzięki zastosowaniu pul można uniemożliwić witrynom działającym w jednej z nich korzystanie z zawartości zawartej w innej puli.

Dla każdej puli aplikacji można określić tożsamość, czyli przypisane do niej konto użytkownika. Następnie można tej tożsamości przypisać wszystkie niezbędne uprawnienia (NTFS, dostęp do bazy danych SQL itd.). Ponieważ poszczególne pule używają różnych tożsamości, to można selektywnie przyznawać lub odbierać im uprawnienia do określonych zasobów. Wszystkie witryny działające w jednej puli aplikacji mają te same uprawnienia, związane z przypisaną jej tożsamością.

Uwaga Witryny i aplikacje webowe działające w jednej puli aplikacji mogą wpływać wzajemnie na swoją dostępność (stabilność). Aby zwiększyć dostępność witryn i aplikacji, należy odizolować te z nich, które są niestabilne umieszczając je w oddzielnych pulach.

Ocena wpływu personifikacji na kompatybilność aplikacji

Zabezpieczenie witryn i aplikacji przez odizolowanie ich za pomocą pul aplikacji, do których przypisane są oddzielne tożsamości, może spowodować problemy z kompatybilnością. Kłopoty te wynikają ze złożoności procesu nazywanego personifikacją.

Personifikacja umożliwia procesowi roboczemu na działanie przy użyciu poświadczeń odmiennych od jego podstawowej tożsamości. Ważne jest zrozumienie w jaki sposób tożsamość procesu roboczego, określana przez tożsamość puli aplikacji, jest powiązana z kontem personifikowanego użytkownika.

Podczas tworzenia procesu roboczego przez usługę WWW, otrzymuje on znacznik powiązany z tożsamością puli aplikacji. Powoduje to przypisanie tej tożsamości do nowego procesu roboczego. Domyślnie, wszystkie czynności podejmowane przez proces roboczy są wykonywane w kontekście konta - tożsamości tego procesu. Podczas przetwarzania żądania klienta, jednakże, wątek który obsługuje to zadanie używa znacznika związanego z klientem czyli tzw. znacznika uwierzytelnionego użytkownika.

Przed obsłużeniem URL-a przez IIS, znacznik uwierzytelnionego użytkownika jest porównywany z listą kontroli dostępu (ACL) zasobu, którego dotyczy żądanie. Dodatkowo, jeżeli żądanie jest związane z rozszerzeniem ISAPI (np. ASP), proces roboczy stosuje znacznik uwierzytelnionego użytkownika do wątku, który ma wywołać rozszerzenie ISAPI. Gdy rozszerzenie to zaczyna przetwarzać zgłoszone żądanie, to stosuje ten właśnie znacznik. Z tego powodu akcje podejmowane przez rozszerzenie ISAPI są związane z uwierzytelnionym użytkownikiem, a nie tożsamością procesu. W efekcie personifikacja wpływa na kompatybilność aplikacji ASP i ASP.NET.

Personifikacja w aplikacjach ASP

W przypadku aplikacji ASP, rodzaj użytego uwierzytelniania automatycznie określa sposób personifikacji. Z tego powodu nie jest konieczna żadna konfiguracja.

Personifikacja w aplikacjach ASP działa w następujący sposób:

• Jeżeli żądanie jest wysłane przez użytkownika anonimowego, to znacznik użytkownika jest określany na podstawie konta skonfigurowanego jako tożsamość użytkownika anonimowego (domyślnie IUSR_NAZWA_KOMPUTERA).
• Jeżeli żądanie jest wysłane przez użytkownika uwierzytelnionego, to znacznik użytkownika jest określany na podstawie jego konta w systemie operacyjnym.

Personifikacja w aplikacjach ASP.NET

W przeciwieństwie do aplikacji ASP, ASP.NET wymaga skonfigurowania metody personifikacji. Po jej włączeniu, ASP.NET otrzymuje znacznik zabezpieczeń używany do personifikacji od serwera IIS. Ustawienia tego procesu można kontrolować za pomocą wpisów w pliku Web.config przynależącego do poszczególnych aplikacji. Dostępne są następujące opcje:

• Personifikacja jest wyłączona
  Jest to ustawienie domyślne. W tej sytuacji, proces ASP.NET działa używając znacznika procesu roboczego przypisanego aplikacji, niezależnie od rodzaju uwierzytelniania z którego korzysta IIS i ASP.NET. Standardowo, znacznikiem używanym przez proces roboczy aplikacji jest NetworkService.
  Aby wyłączyć personifikację, należy umieścić w pliku Web.config aplikacji następującą linię:

  <identity impersonate="false" />

• Personifikacja jest włączona
  W tej sytuacji, ASP.NET korzysta ze znacznika przekazanego przez IIS, ustalanego w ten sam sposób jak w przypadku aplikacji ASP. Dla zachowania wstecznej zgodności z aplikacjami ASP należy stosować to właśnie ustawienie.
  Aby włączyć personifikację, należy umieścić w pliku Web.config aplikacji następującą linię:

  <identity impersonate="true" />

• Personifikacja jest włączona i podano określoną tożsamość
  W tej sytuacji, ASP.NET korzysta ze znacznika generowanego na podstawie podanej tożsamości. Znacznik uwierzytelnionego klienta nie jest używany poza kontrolą uprawnień dostępu.
  Aby włączyć personifikację i podać określoną tożsamość, należy umieścić w pliku Web.config aplikacji następującą linię:

  <identity impersonate="true" name="domena\użytkownik" password="hasło" />

Konfigurowanie izolacji witryn i aplikacji

Aby określić czy witryny i aplikacje wymagają izolacji z uwagi na bezpieczeństwo, należy:

1. Utworzyć listę witryn i aplikacji które mają być hostowane na serwerze webowym.
2. Pogrupować te witryny i aplikacje wg organizacji (lub jednostek biznesowych, jeżeli wszystkie witryny i aplikacje należą do jednej organizacji).
3. Podzielić każdą z utworzonych w ten sposób grup na mniejsze podgrupy witryn i aplikacji wymagających tych samych uprawnień i dostępu do zasobów.
4. Dla każdej z grup utworzonych w poprzednim kroku, utworzyć nową pulę aplikacji.
   Aby utworzyć pulę aplikacji, należy:
   1. W menedżerze IIS rozwinąć węzeł komputera lokalnego, kliknąć prawym przyciskiem myszy Application Pools, wybrać polecenie New, a następnie Application Pool.
   2. W razie potrzeby nadać nowy identyfikator puli.
   3. Określić, czy nowa pula ma korzystać z ustawień domyślnych, czy też skopiować je z istniejącej już puli.
   4. W tym drugim przypadku, wybrać z listy pulę, która ma zostać użyta jako szablon.
   5. Kliknąć OK.

   

   
   
   
5. Przypisać witryny i aplikacje z każdej z grup do odpowiednich pul aplikacji.
   Aby przypisać aplikację do puli, należy:
   1. W menedżerze IIS kliknąć prawym przyciskiem myszy aplikację, która ma zostać przypisana do puli i wybrać polecenie Properties.
   2. Wybrać zakładkę Virtual Directory, Directory lub Home Directory w zależności od wybranej puli aplikacji.
   3. Jeżeli do puli przypisywany jest katalog lub katalog wirtualny, to należy sprawdzić czy wypełnione jest pole Application Name. Jeżeli nie, to należy kliknąć przycisk Create i wpisać nazwę nowej aplikacji.
   4. Z listy Application pool wybrać pulę, do której ma zostać przypisana aplikacja.
   5. Kliknąć OK.

   

   
   
   
6. Dla każdej z pól aplikacji, utworzyć konto usługi, które będzie używane jako jej tożsamość.
   W serwerze IIS domyślną tożsamością dla nowo tworzonych pul aplikacji jest NetworkService. Aby móc indywidualnie przypisywać uprawnienia do zasobów, należy utworzyć dla puli indywidualne konto usługi. Konta usług są specjalnymi kontami użytkowników, tworzonymi specjalnie w celu zapewnienia kontekstu zabezpieczeń dla usług działających w systemie Windows Server 2003.
   Dodatkowo, należy dodać nowe konto usługi do grupy IIS_WPG, co umożliwi mu odpowiedni dostęp do metabazy i zawartości IIS. Grupa ta ma domyślnie przypisane odpowiednie uprawnienia pozwalające na prawidłowe działanie większości witryn i aplikacji webowych.
   Konta usług tworzy się w standardowy sposób na komputerze lokalnym lub w Active Directory. Od zwykłych kont użytkowników różnią się jedynie kontekstem, w jakim będą używane. Dobrą praktyką jest wyróżnienie ich wspólnych prefiksem dodanym do nazwy.
7. Przypisać wszystkie niezbędne prawa utworzonej tożsamości.
   Prawa pozwalają użytkownikom na wykonywanie określonych czynności, takich jak interaktywne logowanie się do systemu lub tworzenie kopii bezpieczeństwa plików i katalogów. Prawa różnią się tym od uprawnień, że dotyczą bezpośrednio kont, podczas gdy te drugie stosuje się do obiektów.
   Prawa przypisane grupie IIS_WPG są wystarczające dla większości aplikacji webowych. Jeżeli tak jednak nie jest, to należy przyznać niezbędne dodatkowe prawa kontom użytkowników używanych przez bardziej wymagające aplikacje i witryny.
   Aby przypisać prawa do konta serwisowego, należy zdefiniować je w lokalnych zasadach grup za pomocą narzędzia Group Policy Object Editor jeżeli konto jest utworzone na komputerze lokalnie, lub w obiekcie Group Policy jeżeli konto znajduje się w Active Directory.
8. Przypisać utworzoną tożsamość do odpowiedniej puli aplikacji:
   1. W menedżerze IIS kliknąć prawym przyciskiem myszy konfigurowaną pulę aplikacji, a następnie wybrać polecenie Properties.
   2. Wybrać zakładkę Identity, a następnie zaznaczyć opcję Configurable.
   3. Wpisać nazwę i hasło dla odpowiedniego konta serwisowego.
   4. Kliknąć OK.

   

   
   
   
9. Przypisać odpowiednie uprawnienia do zasobów, takie jak uprawnienia NTFS lub SQL, do tożsamości pul aplikacji.

Konfigurowanie uwierzytelniania użytkowników

Uwierzytelniając użytkowników wcześnie w procesie nawiązywania połączenia zmniejsza ilość informacji, jakie mogą być uzyskane o konfiguracji IIS 6.0 przy użyciu dostępu nieuwierzytelnionego. W silnie zabezpieczonych aplikacjach i witrynach często występuje konieczność uwierzytelnienia przed uzyskaniem jakiejkolwiek informacji. W innych sytuacjach może być wystarczające żądanie uwierzytelnienia jedynie, gdy użytkownik ma zamiar skorzystać z tych części witryny, które zawierają poufne informacje.

W oparciu o rodzaj usług udostępnianych przez serwer webowy, może być konieczne skonfigurowanie uwierzytelniania dla witryn sieci Web lub witryn FTP. Obydwa rodzaje witryn obsługują różne metody uwierzytelniania użytkowników.

Konfigurowanie uwierzytelniania witryn sieci Web

Metoda uwierzytelniania witryn webowych zależy od tego, czy są one wdrażane w intranecie czy Internecie oraz od związku ich użytkowników z daną organizacją.

• Aplikacje intranetowe
  W przypadku witryn i aplikacji intranetowych można zazwyczaj wykorzystać w nich tą metodę uwierzytelniania, która jest już używana w danej organizacji. W większości przypadków można wykorzystać zintegrowane uwierzytelnianie systemu Windows (Integrated Windows Authentication) - ta metoda pozwala na czerpanie korzyści z jednokrotnego uwierzytelniania i silnej ochrony poświadczeń użytkowników. Jeżeli nie można skorzystać z uwierzytelniania zintegrowanego, to należy wybrać najsilniejszą spośród innych dostępnych metod opisanych w tabeli w dalszej części tego artykułu.
• Aplikacje internetowe
  Aplikacje internetowe muszą zazwyczaj obsługiwać szeroki zakres różnych klienckich systemów operacyjnych i przeglądarek. W ich przypadku najczęściej używanymi metodami uwierzytelniania jest uwierzytelnianie anonimowe (Anonymous) lub podstawowe (Basic).

Wybór metody uwierzytelniania

Wybór metody uwierzytelniania należy oprzeć na poziomie ochrony, jaki oferuje ona dla poświadczeń użytkowników oraz na tym, w jaki sposób użytkownicy są powiązani z daną organizacją. Zawsze należy korzystać z najsilniejszej dostępnej w danej sytuacji metody uwierzytelniania.

Metody uwierzytelniania w witrynach internetowych można podzielić na dwie kategorie:

• Metody, które nie wymagają lub nie szyfrują poświadczeń użytkowników
  W przypadku aplikacji i witryn internetowych najczęściej korzysta się z metod uwierzytelniania nie wymagających lub nie szyfrujących poświadczeń użytkownika.
  Metody te można wybrać, jeżeli:
  • Dostęp do witryn i aplikacji może pozostać anonimowy,
  • Dostęp do witryn i aplikacji musi być niezależny od konfiguracji klienta i związku użytkownika z daną organizacją.
  Dostęp anonimowy nie wymaga żadnego uwierzytelnienia. Większość witryn internetowych korzysta z tej metody, ponieważ ich zawartość może być dostępna dla wszystkich użytkowników bez żadnych ograniczeń. Uwierzytelnianie niezależne od konfiguracji klienta ani od użytkownika to przede wszystkim uwierzytelnianie podstawowe (Basic). Należy je stosować jeżeli konieczne jest uwierzytelnienie użytkownika, ale:
  • Nie można od niego żądać dokonania specjalnej konfiguracji,
  • Użytkownik nie jest w żaden sposób związany z daną organizacją,
  • Infrastruktura sieci nie pozwala na zastosowanie szyfrujących metod uwierzytelniania (np. zintegrowane uwierzytelnianie Windows wymaga podtrzymania połączenia pomiędzy żądaniami, co jest uniemożliwiane przez większość serwerów proxy).
  Ponieważ uwierzytelnianie podstawowe nie szyfruje poświadczeń użytkowników, to warto je zabezpieczyć przy użyciu bezpiecznego kanału SSL. Jeżeli skorzystanie z takiego kanału jest niemożliwe, to należy w miarę możliwości korzystać z szyfrujących metod uwierzytelniania.
• Metody, które szyfrują poświadczenia użytkowników
  Szyfrujące metody uwierzytelniania zazwyczaj wymagają pewnego stopnia kontroli nad komputerem klienta - w praktyce oznacza to, że mogą być stosowane gdy użytkownik jest pracownikiem danej organizacji lub jej partnera biznesowego. W poniższej tabeli przedstawiono porównanie dostępnych w serwerze IIS metod uwierzytelniania szyfrującego:

  Metoda	Zalety	Wady
  Digest	Obsługuje uwierzytelnianie przez firewalle i serwery proxy Szyfruje poświadczenia użytkowników Wymaga usługi Active Directory działającej w serwerze Windows 2000 Server lub nowszym Zapewnia średni poziom bezpieczeństwa	Wymaga przeglądarki Internet Explorer 5.0 lub nowszej Przechowuje hasła tekstem jawnym w Active Directory Nie może być używana do uwierzytelniania kont lokalnych Wymaga skonfigurowania tożsamości puli aplikacji jako LocalSystem
  Advanced Digest	Obsługuje uwierzytelnianie przez firewalle i serwery proxy Szyfruje poświadczenia użytkowników Przechowuje zaszyfrowane hasła w Active Directory Zapewnia średni poziom bezpieczeństwa	Wymaga przeglądarki Internet Explorer 5.0 lub nowszej Wymaga usługi Active Directory działającej w serwerze Windows Server 2003 Nie może być używana do uwierzytelniania kont lokalnych
  Integrated Windows	Szyfruje poświadczenia użytkowników Zapewnia wysoki poziom bezpieczeństwa Wymaga przeglądarki Internet Explorer 2.0 lub nowszej	Wymaga oprogramowania klienckiego firmy Microsoft
  Client Certificates	Przy uwierzytelnianiu po stronie serwera (certyfikaty składowane na serwerze) organizacja otrzymuje certyfikaty od zaufanego urzędu certyfikacji Przy uwierzytelnianiu po stronie klienta, certyfikaty są mapowane do kont użytkowników przechowywanych w AD działającej na serwerze Windows 2000 Server lub nowszym Zapewnia wysoki poziom bezpieczeństwa	Przy uwierzytelnianiu po stronie klienta (certyfikaty przechowywane na kliencie) organizacja musi wdrożyć infrastrukturę kluczy publicznych (PKI) Przy uwierzytelnianiu po stronie klienta konieczne jest opracowanie metody bezpiecznej dystrybucji certyfikatów do klientów
  Microsoft .NET Passport	Obsługuje uwierzytelnianie przez firewalle i serwery proxy Szyfruje poświadczenia użytkowników Wymaga przeglądarki Internet Explorer 4.0 lub nowszej, lub Nestscape Navigator 4.0, lub nowszej	Wymaga Active Directory jeżeli używane jest mapowanie kont Wymaga licencjonowania usługi uwierzytelniania .NET Passport

Konfigurowanie metody uwierzytelniania dla aplikacji webowej

Metodę uwierzytelniania można skonfigurować na poziomie witryny webowej, katalogu lub pliku, za pomocą menedżera IIS. W tym celu należy:

1. W menedżerze IIS rozwinąć folder Web Sites, a następnie kliknąć prawym przyciskiem myszy witrynę, katalog lub plik i wybrać polecenie Properties.
2. Wybrać zakładkę Directory Security lub File Security w zależności od konfigurowanego zasobu.
3. Kliknąć przycisk Edit w polu Authentication and user control.
4. Wybrać metodę uwierzytelniania.
5. W razie potrzeby należy wpisać nazwę zabezpieczanego obszaru w polu Realm oraz nazwę domeny w polu Default Domain.
6. Kliknąć OK dwa razy.

Konfigurowanie uwierzytelniania witryn FTP

Aby skonfigurować uwierzytelnianie witryny FTP, należy:

1. Wybrać metodę uwierzytelniania odpowiadającą wymaganiom związanym z bezpieczeństwem.

   Metoda	Opis
   Uwierzytelnianie anonimowe (Anonymous)	Jeżeli zachodzi potrzeba przesyłania informacji poufnych, to należy unikać stosowania tego typu uwierzytelniania - nie jest przy nim przeprowadzane żadne uwierzytelnianie użytkownika.
   Uwierzytelnianie podstawowe (Basic)	Podstawowe uwierzytelnianie FTP jest związane z przesyłaniem poświadczeń użytkownika tekstem jawnym, co stanowi znaczne naruszenie bezpieczeństwa.

   
   
2. Skonfigurować serwer FTP tak, aby korzystał z wybranej metody uwierzytelniania. W przypadku, gdy konieczne jest przesyłanie poufnych danych, należy skorzystać z poniższych wskazówek:
   • Wewnątrz intranetu - w tym przypadku najlepiej użyć protokołu IPSec, pozwalającego na szyfrowanie nazwy i hasła konta oraz przesyłanych danych.
   • Poza intranetem - w tym przypadku do bezpiecznego uwierzytelnienia i przesyłania danych konieczne jest zastosowanie tunelu VPN.

Szyfrowanie tajnych danych

Z punktu widzenia potrzeb biznesowych, może być konieczne przesyłanie poufnych danych pomiędzy serwerem webowym a komputerami klienckimi. Bezpieczeństwo przesyłanej informacji można zapewnić korzystając z różnych technik szyfrowania.

Wybór metody szyfrowania danych zależy od różnych czynników. W przypadku serwera opartego na systemie Windows Server 2003 dostępne są następujące rozwiązania:

• SSL dla użytkowników korzystających z witryn i aplikacji hostowanych w serwerze webowym,
• IPSec lub VPN dla administratorów zdalnie zarządzających witrynami i aplikacjami hostowanymi w serwerze webowym.

Szyfrowanie poufnych danych przy użyciu SSL

Za pomocą protokołu SSL (Secure Sockets Layer) możliwe jest szyfrowanie transmisji sieciowych, co pozwala zapewnić integralność tych transmisji i weryfikację tożsamości użytkowników. Za pomocą SSL można zabezpieczać dowolny fragment witryny sieciowej lub aplikacji.

Proces opisany poniżej dotyczy konfigurowania SSL tak, aby korzystał z certyfikatów serwera. Certyfikaty te są instalowane w serwerze webowym i zazwyczaj nie wymagają żadnej dodatkowej konfiguracji po stronie klienta. Ich zadaniem jest umożliwienie klientom weryfikacji tożsamości serwera. Niektóre aplikacje mogą wymagać zastosowania tzw. certyfikatów klienta, instalowanych jak sama nazwa wskazuje po stronie klienta i pozwalających na uwierzytelnianie go przez serwer. Więcej informacji o konfigurowaniu certyfikatów klienta można znaleźć w pomocy serwera IIS 6.0.

SSL można skonfigurować tak, aby zabezpieczał poufne dane dla poszczególnych adresów URL (czyli dla indywidualnych fragmentów witryny lub aplikacji). Niektóre fragmenty witryny mogą wymagać szyfrowania danych przy użyciu SSL (po podaniu HTTPS w adresie URL), podczas gdy inne pozwalają na niezaszyfrowaną transmisję danych (po podaniu HTTP w adresie URL). Takie rozwiązanie jest bardziej elastyczne niż np. IPSec czy VPN, ponieważ te dwie technologie wymagają szyfrowania wszystkich danych przesyłanych pomiędzy klientem a serwerem webowym.

Aby wykorzystać SSL, konieczne jest zainstalowanie w serwerze ważnego certyfikatu dla każdej z witryn która ma z tego protokołu korzystać. Certyfikaty są zazwyczaj przyznawane organizacjom przez tzw. zaufane urzędy certyfikacji. W certyfikacie są zawarte m.in. informacje o organizacji, która go otrzymała - np. zarejestrowana nazwa domeny. Z tego powodu potrzebny jest oddzielny certyfikat dla każdej witryny, która posiada zarejestrowaną nazwę domeny.

Przeglądarki internetowe wykonują szereg weryfikacji certyfikatu SSL. Jeżeli w certyfikacie znajdzie się jakaś nieprawidłowa wartość, to przeglądarka wyświetla komunikat ostrzegawczy. Do weryfikowanych danych zaliczają się:

• Podpis cyfrowy certyfikatu,
• Data wygaśnięcia certyfikatu,
• Zgodność nazwy domeny dla której certyfikat został wydany z żądanym adresem URL.

Aby włączyć SSL, należy wykonać następujące czynności dla każdej z witryn i aplikacji:

1. Zażądać certyfikatu serwera dla witryny od odpowiedniego urzędu certyfikacji.
   Aby wygenerować plik żądania certyfikatu (domyślnie Certreq.txt) można skorzystać z narzędzia Web Server Certificate Wizard. Plik ten można potem przesłać do urzędu certyfikacji. W zależności od poziomu zaufania wymaganego od certyfikatu, proces jego wydania może trwać od kilku dni do nawet kilku miesięcy.
   Aby zażądać certyfikatu, należy:
   1. W menedżerze IIS kliknąć prawym przyciskiem myszy wybraną witrynę, a następnie wybrać polecenie Properties.
   2. Na zakładce Directory Security kliknąć przycisk Server Certificate.
   3. W kreatorze Web Server Certificate Wizard wybrać opcję Create a new certificate.
   4. Postępować dalej według wskazówek kreatora.
2. Zainstalować certyfikat w serwerze webowym za pomocą narzędzia Certificates w konsoli MMC:
   1. Dodać do konsoli MMC narzędzie Certificates:
      1. Uruchomić konsolę MMC.
      2. W menu File kliknąć Add/Remove Snap-in.
      3. Kliknąć przycisk Add na zakładce Standalone.
      4. Wybrać narzędzie Certificates z listy Available Standalone Snap-ins i kliknąć Add.
      5. Wybrać opcję Computer account i kliknąć Next.
      6. Wybrać opcję Local computer (the computer this console is running on) i kliknąć Finish.
      7. Kliknąć Close a następnie OK.
   2. W drzewie konsoli kliknąć magazyn logiczny, do którego ma zostać zaimportowany certyfikat (domyślną lokalizacją jest folder /Personal/Certificates)
   3. Z menu Action wybrać polecenie All tasks, a następnie Import. Zostanie uruchomiony kreator importu certyfikatu (Certificate Import Wizard).
      Uwaga! Należy importować jedynie certyfikaty otrzymane z zaufanego źródła. Zaimportowanie zmienionego lub niewiadomego pochodzenia certyfikatu może skompromitować bezpieczeństwo komponentów systemowych, które będą z niego korzystać.
   4. Postępować zgodnie ze wskazówkami kreatora.
3. Przypisać certyfikat do witryny internetowej:
   1. W menedżerze IIS kliknąć prawym przyciskiem myszy wybraną witrynę, a następnie wybrać polecenie Properties.
   2. Na zakładce Directory Security kliknąć przycisk Server Certificate.
   3. W kreatorze Web Server Certificate Wizard wybrać opcję Assign an existing certificate.
   4. Postępować zgodnie ze wskazówkami kreatora.
   5. Informacje o przypisanym certyfikacie można przeglądać po klinięciu przycisku View Certificate na zakładce Directory Security.

Zdalna administracja przy użyciu IPSec lub VPN

Aby zabezpieczyć transfer danych związany z administracją serwera webowego poprzez sieć - np. ładowanie zawartości przez FTP lub zarządzanie usługą IIS - można skorzystać z protokołu IPSec (Internet Protocol security) lub wirtualnych sieci prywatnych (VPN). Oprócz szyfrowania ruchu, rozwiązania te udostępniają silne metody uwierzytelniania, takie jak karty inteligentne, pozwalające na wiarygodne potwierdzanie tożsamości klienta.

Potwierdzanie tożsamości jest procesem weryfikacji autentyczności poświadczeń. Przykładowo, certyfikaty komputerów, wystawiane przez organizację, pozwalają na zagwarantowanie, że zadania administracyjne będą wykonywane jedynie z wyznaczonych komputerów.

Jeżeli serwer webowy udostępnia usługi hostingowe dla innych organizacji, to konieczne jest zapewnienie im bezpiecznej metody aktualizacji zawartości witryn. Ponieważ organizacje te przesyłają zawartość przez Internet, to konieczne jest szyfrowanie tego ruchu i dokonywanie dodatkowych kontroli tożsamości.

Projektowanie i wdrażanie architektury IPSec i VPN nie mieści się w zakresie tego artykułu. Polecam przeczytać artykuł mojego redakcyjnego kolegi Szymona Śmiecha poświęcony konfigurowaniu IPSec. Ponadto, w witrynie TechNet można znaleźć wiele szczegółowych informacji opisujących ten proces.

Utrzymanie bezpieczeństwa serwera

Zabezpieczenie serwera jest jedynie początkiem pracy. Równie konieczne jest utrzymanie go w tym stanie tak, aby mógł odpierać coraz to nowe zagrożenia płynące z Internetu. Z tej przyczyny należy starać się doprowadzić do tego, aby serwer internetowy był łatwy i wygodny do zarządzania oraz aby zostały wdrożone procedury pozwalające na utrzymanie bezpieczeństwa.

Instalowanie aktualnych poprawek bezpieczeństwa

Regularną praktyką administratora powinno być instalowanie aktualnych poprawek zabezpieczeń, pozwalających na utrzymanie stanu bezpieczeństwa witryny internetowej. W miarę jak odkrywane są nowe luki w zabezpieczeniach, firma Microsoft publikuje aktualizacje pozwalające na uniknięcie ryzyka, jakie mogłyby one spowodować. Aktualne poprawki i service-packi można pozyskać na różne sposoby:

• Przez subskrybcję biuletynu "Microsoft Security Notification Service". Aby bezpłatnie stać się subskrybentem tego emailowego biuletynu, należy zarejestrować się na stronie http://register.microsoft.com/subscription/subscribeme.asp?ID=135.
• Regularnie korzystając z systemowej usługi Windows Update.
• Przez wdrożenie usługi Microsoft Software Update Services (SUS). SUS jest usługą pośredniczącą pomiędzy serwerem Windows Update na witrynie Microsoft.com a komputerami w sieci organizacji korzystającymi z systemu operacyjnego Microsoft Windows. Korzystając z SUS, można pobrać wszystkie najnowsze aktualizacje do serwera umieszczonego w intranecie, przetestować je, a następnie wdrożyć we wszystkich komputerach w organizacji. Więcej informacji o usłudze SUS można znaleźć w artykule Wojtka Kowasza pod tytułem Konfiguracja Software Update Services.

Dobrym nawykiem jest testowanie wszelkich aktualizacji w wydzielonym środowisku testowym przed wdrożeniem ich w komputerach działających w środowisku produkcyjnym.

Wykorzystanie dzienników bezpieczeństwa (Security Log)

Aby mieć pewność, że serwer webowy pozostaje bezpieczny, konieczne jest bieżące gromadzenie odpowiednich danych. W systemie Windows Server 2003 można do tego celu wykorzystać dzienniki zdarzeń: dziennik systemowy (System Log) oraz dziennik zabezpieczeń (Security Log). Wiele systemów służących do zarządzania infrastrukturą, m.in. Microsoft Operation Manager, okresowo skanuje te dzienniki i pozwala na raportowanie informacji o problemach związanych z zabezpieczeniami lub ich naruszeniem.

Aby efektywnie korzystać z rejestrowanych informacji, należy włączyć mechanizmy audytu dla dziennika systemowego i określić liczbę zdarzeń jakie mają być zapisywane w dzienniku bezpieczeństwa. Audyt zdarzeń można skonfigurować w oparciu o ich kategorie. Warto, jako minimum, włączyć audyt dla następujących kategorii zdarzeń:

• Zmiany w kontach użytkowników i uprawnieniach dostępu do zasobów,
• Wszystkie nieudane próby logowania,
• Wszystkie nieudane próby dostępu do zasobów,
• Wszystkie modyfikacje plików systemowych.

Aby zdefiniować lub zmodyfikować ustawienia reguły audytu dla lokalnego serwera webowego, należy:

1. Otworzyć folder Administrative Tools, a następnie narzędzie Local Security Policy.
2. W drzewie konsoli kliknąć Local Policies, a następnie Audit Policy.
3. W panelu szczegółów dwukrotnie kliknąć kategorię, dla której ma zostać zmienione ustawienie audytu.
4. Na zakładce Properties wybrać rodzaj zdarzenia, jakie ma być rejestrowane: Success (sukces) i/lub Failure (porażka).
5. Kliknąć OK.

Aby zdefiniować lub zmodyfikować ustawienia reguły audytu dla serwera webowego, który należy do domeny, należy:

1. Otworzyć folder Administrative Tools, a następnie narzędzie Active Directory Users and Computers.
2. Kliknąć prawym przyciskiem myszy odpowiednią domenę, lokalizację lub jednostkę organizacyjną, a następnie wybrać polecenie Properties.
3. W edytorze zasad grup (Group Policy Object Editor), w drzewie konsoli, rozwinąć węzeł Computer Configuration, następnie Windows Settings, Local policy - i na koniec kliknąć Audit Policy.
4. Dalej postępować podobnie jak w przypadku serwera samodzielnego.

Wykorzystanie audytu dostępu do plików dla monitorowania aktywności związanej z zawartością witryny

Oprócz dzienników zabezpieczeń, można włączyć audyt dostępu do plików składających się na zawartość witryny internetowej. Jest to krok niezależny od poprzedniego i musi być wykonany, jeżeli konieczne jest monitorowanie wszystkich zmian plików i katalogów zawierających zawartość witryny lub aplikacji. Rejestrowane zdarzenia można przeglądać w logu zabezpieczeń (Security Log).

Możliwe jest włączenie audytu dla poszczególnych użytkowników oraz dla każdego pliku i katalogu oddzielnie. Warto, jako minimum, włączyć audyt dla wszystkich użytkowników i następujących kategorii zdarzeń (zarówno sukcesów jak i prób nieudanych):

• Zmodyfikowanie lub usunięcie istniejącej zawartości,
• Utworzenie nowej zawartości.

Aby włączyć audyt dostępu do obiektów, należy:

1. Otworzyć folder Administrative Tools, a następnie narzędzie Local Security Policy.
2. Rozwinąć węzeł Local Policies, a następnie kliknąć Audit Policy.
3. Kliknąć prawym przyciskiem myszy Audit object access i wybrać polcenie Properties.
4. Włączyć audyt klikając Success i/lub Failure, odpowiednio dla rejestrowania operacji zakończonych sukcesem lub niepowodzeniem.
5. Jeżeli zostaną wyłączone obydwie opcje, to audyt dostępu do obiektów nie będzie wykonywany.
6. Kliknąć OK.

Aby włączyć lub zmodyfikować ustawienia audytu dla lokalnego pliku lub folderu, należy:

1. Kliknąć prawym przyciskiem myszy plik lub folder, dla którego mają być zmienione ustawienia audytu, wybrać polecenie Properites, a następnie wybrać zakładkę Security.
2. Kliknąć Advanced, a następnie wybrać zakładkę Auditing.

   

   
   
   
3. Wykonać jedną z czynności:
   1. Aby włączyć audyt dla nowego użytkownika lub grupy, kliknąć Add, a następnie podać nazwę tego użytkownika lub grupy i kliknąć OK.
   2. Aby wyłączyć audyt dla użytkownika lub grupy, kliknąć odpowiednią pozycję na liście, a następnie przycisk Remove.
   3. Aby obejrzeć lub zmienić ustawienia audytu dla użytkownika lub grupy, kliknąć odpowiednią pozycję na liście, a następnie przycisk Edit.
4. Z listy Apply onto wybrać lokalizację, dla której ma być wykonywany audyt dostępu do obiektów.
5. Na liście Access określić jakie akcje mają podlegać audytowi, wybierając opcję Successful i/lub Failed.
6. Jeżeli ustawienia audytu nie mają być dziedziczone przez pliki i podfoldery znajdujące się w konfigurowanym folderze, to należy włączyć opcję Apply these auditing entries to objects and/or containers within this container only.

   

Wdrożenie procedur pozwalających na utrzymanie stanu bezpieczeństwa serwera

Częścią procesu utrzymania bezpieczeństwa serwera webowego są okresowe przeglądy zasad, procesów i procedur stosowanych w organizacji. Po początkowym wdrożeniu bezpiecznego serwera, warto przejrzeć aktualnie stosowane praktyki, sprawdzając, czy gwarantują one:

Uniknięcie nowych ryzyk związanych z bezpieczeństwem
Podczas gdy wciąż pojawiają się nowe ryzyka dla bezpieczeństwa - nowe wirusy lub luki w systemie operacyjnym - procedury bezpieczeństwa powinny pomagać w ich uniknięciu. Jeżeli aktualnie stosowane praktyki tego nie gwarantują, to należy je zmodyfikować.

Identyfikację zmian w konfiguracji serwera webowego, które mogą doprowadzić do kompromitacji zabezpieczeń
Podczas normalnej administracji serwera webowego pojawiają się zmiany w jego konfiguracji. Proces ten może spowodować zmianę ustawień mających wpływ na bezpieczeństwo. Konieczne są okresowe przeglądy konfiguracji serwera webowego, pozwalające na skonfrontowanie jej z wymaganiami organizacji w zakresie bezpieczeństwa.

Wyżej wymienione praktyki można pogrupować funkcjonalnie, np. na dotyczące systemu operacyjnego, zasad zabezpieczeń, bezpieczeństwa firewalla i bezpieczeństwa routera. Ponadto, zróżnicowana może być częstotliwość wykonywania poszczególnych procesów i procedur. Niektóre z nich muszą zachodzić stale, w przypadku innych wystarczy, że będą przeprowadzane raz w miesiącu. Poniższe tabele przedstawiają przykładowe listy zasad, procesów i procedur, pogrupowanych w wyżej wymienione kategorie. Są to reguły reprezentatywne dla procesu utrzymania bezpieczeństwa serwera webowego, jednak nie należy się do nich ograniczać. Każda organizacja ma własne potrzeby i z tego powodu opracowanie tego typu list musi być poprzedzone gruntowną analizą konkretnej sytuacji.

Zabezpieczenia systemu operacyjnego Windows Server 2003

Zasady zabezpieczeń systemu operacyjnego Windows Server 2003

Bezpieczeństwo firewalla i routera

Inne

Podsumowanie

Powyższe wskazówki kończą niniejszy artykuł. Przedstawione w nim rady i sugestie pozwalają na skonfigurowanie i utrzymanie bezpiecznego serwera. Nie należy jednak ograniczać się do zawartości tego tekstu: zapewnienie bezpieczeństwa jest procesem ciągłym. Hacker dysponuje niemal nieograniczonymi zasobami w porównaniu z administratorem, co więcej - dla napastnika wystarczy jedna nie zamknięta luka, podczas gdy administrator musi dbać jednocześnie o wszystkie aspekty systemu. Czy jest to walka z góry skazana na niepowodzenie? Tysiące bezproblemowo działających serwerów świadczą o tym, że nie. Należy jednak trzymać rękę na pulsie i wybiegać naprzód wszystkim nowo pojawiającym się zagrożeniom.

Autor: Michał Chaniewski

• Nowości w Windows Server 2003
• Windows Server 2003 w roli serwera aplikacji
• Konfigurowanie serwera IIS
• Tworzenie witryn webowych
• Tworzenie katalogów wirtualnych
• Konfigurowanie obsługi stanu sesji ASP.NET
• Określanie domyślnego dokumentu
• Określanie czasu ważności zawartości i innych nagłówków HTTP
• Tworzenie własnych stron informujących o błędach
• Konfigurowanie wydajności aplikacji
• Eksportowanie i importowanie ustawień witryny do i z pliku
• Zabezpieczanie witryn i aplikacji internetowych
• Minimalizacja powierzchni ataku
• Uniemożliwienie nieautoryzowanego dostępu
• Izolowanie witryn i aplikacji
• Konfigurowanie uwierzytelniania użytkowników
• Szyfrowanie tajnych danych
• Utrzymanie bezpieczeństwa serwera
• Podsumowanie