Serwer WWW

AKADEMIA GÓRNICZO-HUTNICZA
Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki
KATEDRA INFORMATYKI
Serwer WWW
Komercyjny serwer www oparty na appache
Kierunek, rok studiów:

Informatyka, Studia Dzienne, Rok IV
Przedmiot:
Administracja systemami komputerowymi
Prowadzący zajęcia: Rok akad: 2002/2003
Mgr inż. Bogusław Juza Semestr: letni
Zespół autorski:
Łukasz Kawulok E-mail: luc@ernie.icslab.agh.edu.pl
Michał Jaeschke E-mail: jaeschke@ernie.icslab.agh.edu.pl
Grzegorz Duda E-mail: dudek@ernie.icslab.agh.edu.pl
Kraków, maj 2002

Łukasz Kawulok, Michał Jaeschke, Grzegorz Duda Administracja systemami komputerowymi
Spis treści
1. Wstęp i opis zadań ____________________________________________________________________ 4
2. Virtual Host – wirtuane serwery ________________________________________________________ 5

2.1. Name-based Virtual Hosts – wirtualne serwery bazujące na nazwach___________________ 5
2.1.1. Czego wymagają wirtualne serwery bazujące na nazwach ______________________________ 5
2.1.2. Używanie wirtualnych serwerów bazujących na nazwach ______________________________ 6
2.1.3. Kwestia kompatybilności z starszymi przeglądarkami __________________________________ 7
2.2. IP-based Virtual Hosts – bazujące na IP wirtualne hosty _____________________________ 8
2.2.1. Czego wymagają bazujące na IP wirtualne hosty _____________________________________ 8
2.2.2. Jak skonfigurować Appache do współpracy z bazującymi na IP wirtualnymi hostami ________ 8
2.2.3. Konfiguracja dla wielu demonów__________________________________________________ 8
2.2.4. Konfiguracja oparta na jednym demonie____________________________________________ 9
3. Przykłady różnych konfiguracji ________________________________________________________ 10
3.1. Name-based Virtual Hosts _____________________________________________________ 10
3.1.1. Przykład 1 ___________________________________________________________________ 10
3.1.2. Przykład 2 ___________________________________________________________________ 10
3.1.3. Przykład 3 ___________________________________________________________________ 11
3.1.4. Przykład 4 ___________________________________________________________________ 11
3.1.5. Przykład 5 ___________________________________________________________________ 12
3.2. IP-based Virtual Hosts ________________________________________________________ 13
3.2.1. Przykład 1 ___________________________________________________________________ 13
3.2.2. Przykład 2 ___________________________________________________________________ 13
3.2.3. Przykład 3 ___________________________________________________________________ 14
3.3. Mixed name-/IP-based vhosts ___________________________________________________ 14
3.4. Port-based vhosts _____________________________________________________________ 15
3.5. Użycie _default_ w vhostach ___________________________________________________ 16
3.5.1. Przykład 1 ___________________________________________________________________ 16
3.5.2. Przykład 2 ___________________________________________________________________ 16
3.5.3. Przykład 3 ___________________________________________________________________ 16
3.6. Użycie dyrektywy ServerPath__________________________________________________ 17
4. Obsługa skryptów CGI _______________________________________________________________ 19

4.1. Uwagi wstępne _______________________________________________________________ 19
4.2. Model bezpieczeństwa w suEXEC’u _____________________________________________ 19
4.3. Konfiguracja i instalacja suEXEC’a _____________________________________________ 20
4.4. Użycie suEXEC’a z wirtualnymi serwerami _______________________________________ 21
5. Format Logów ______________________________________________________________________ 22
5.1. Ostrzeżenie związane z bezpieczeństwem _________________________________________ 22
5.2. Error Log ___________________________________________________________________ 22
5.3. Access Log __________________________________________________________________ 23
5.3.1. Common Log Format __________________________________________________________ 23
5.3.2. Opis części stringu formatującego ________________________________________________ 23
5.3.2.1. 127.0.0.1 (%h) 23
5.3.2.2. (%l) 23
5.3.2.3. frank (%u) 24
5.3.2.4. [10/Oct/2000:13:55:36 -0700] (%t) 24
5.3.2.5. "GET /apache_pb.gif HTTP/1.0" ("%r") 24
5.3.2.6. 200 (%>s) 24
5.3.2.7. 2326 (%b) 24
5.3.3. Combined Log Format _________________________________________________________ 24
6. Appache - poprawa osiągów ___________________________________________________________ 26
6.1. Zmiany w pliku konfiguracyjnym _______________________________________________ 26
Plik: Serwer WWW.doc Wersja: 0.1-68 z dnia 07.06.2002 Stron: 36 Długość: 916 kB
Copyright © 2002 Akademia Górniczo-Hutnicza Prowadzenie zajęć: mgr inż. Bogusław Juza
2
6.1.1. MaxKeepAliveRequests_________________________________________________________ 26
6.1.2. MinSpareServers______________________________________________________________ 26
6.1.3. MaxSpareServers _____________________________________________________________ 26
6.1.4. StartServers __________________________________________________________________ 26
6.1.5. MaxClients __________________________________________________________________ 26
6.1.6. MaxRequestsPerChild _________________________________________________________ 27
6.2. mod_mmap_static moduł Apache’a______________________________________________ 27
6.2.1. Zmapowanie dokumentów do pamięci: ____________________________________________ 27
6.2.2. Modyfikacja httpd.conf_________________________________________________________ 27
7. Klika zabezpieczeń Appache’a _________________________________________________________ 28
7.1. Read-only na “httpd” _________________________________________________________ 28
7.2. Katalogi_____________________________________________________________________ 28
7.3. Automatic indexing ___________________________________________________________ 28
7.4. Zabezpieczenie “httpd.conf”____________________________________________________ 28
8. Składnia podstawowych dyrektyw ______________________________________________________ 29
9. Nasza konfiguracja __________________________________________________________________ 30

9.1. Istalacja i konfiguracja Appache________________________________________________ 30
9.2. Doinstalowanie suExeca _______________________________________________________ 31
9.3. Dodanie grupy, użytkowników i katalogów________________________________________ 32
9.4. Testy poprawnej konfiguracji___________________________________________________ 32
10. Skrypty przeglądające logi ____________________________________________________________ 33

10.1. Dziesięć najczęściej odwiedzanych serwisów_______________________________________ 34
10.2. Dziesięć najczęstszych adresów, z których ktoś ogląda strony www serwera danego
serwera._____________________________________________________________________ 35
3
1. Wstęp i opis zadań
Naszym zadaniem było skonfigurowanie serwer www do celów komercyjnych. Konfiguracja ta ma

umożliwiać:
• instalowania wirtualnych serwerów www
• instalowania skryptów CGI, przy czym skrypty te uruchamiane są z prawami użytkownika innego
dla każdego serwisu wirtualnego.
W rozdziale drugim opisujemy podstawy konfiguracji wirtualnych serwisów, zarówno tych bazujących na
nazwach jak i na adresach IP. Kolejny rozdział to przykładowe konfiguracje, które ułatwiają zrozumienie
podstawowych zasad konfiguracji.
Dalej, w rozdziale czwartym opisujemy zasady działania i konfigurację suExec’a – programu
odpowiedzialnego za uruchamianie skryptów CGI z innymi prawami użytkownika niż prawa użytkownika
uruchamiającego serwis. Po krótkim opisie logów i składni podstawowych poleceń przechodzimy do naszej
konfiguracji.
W opisie konfiguracji akcentujemy głównie zmiany w stosunku do domyślnej konfiguracji.
Na koniec zajmujemy się skryptami analizującymi logi napisanie napisanymi przez nas. Skrypty te generują
informacje o:
• 10. najczęściej odwiedzanych serwisach
• 10. najczęstszych adresach, z których ktoś ogląda strony www serwera.
W zadaniu używaliśmy serwera WWW – apache_1.3.23, który jest dostępny pod adresem:
http://www.apache.org/dist/httpd/.
4
2. Virtual Host – wirtuane serwery
Określenie Virtual Host do sytuacji gdy na jednej maszynie utrzymujemy więcej niż jeden serwer
odróżniany przy pomocy jego nazwy – hostname. Przykładem może być sytuacja gdy w dowolnej firmie
serwer WWW jest dzielony pomiędzy różne domeny i są one dostępne poprzez nazwy:
www.company1.com, www.company2.com. Nie wymaga to od użytkownika znajomości żadnych
dodatkowych ścieżek w głównej domenie firmy, tylko znajomości tych nazw domen..
Appache był jednym z pierwszych serwerów WWW który wspierał IP-based (bazujące na adresie IP)
wirtualne hosty. Od wersji 1.1 Apache udostępnia zarówno IP-based, jak i name-based (bazujące na
nazwach) wirtualne hosty.
Poniżej omówimy oba rozwiązania (oczywiście rozwiązania mieszane także są możliwe). Dla szybkiego
zrozumienia idei wirtualnych hostów najlepiej nadają się przykłady zamieszczone w następnym rozdziale.
2.1. Name-based Virtual Hosts – wirtualne serwery bazujące na nazwach

2.1.1. Czego wymagają wirtualne serwery bazujące na nazwach
IP-based virtual host używa adresu IP połączenia do określenia odpowiedniego wirtualnego hosta. Dlatego
konieczne jest posiadanie oddzielnych adresów IP dla każdego z tych hostów. W przypadku name-based
wirtual host, serwer polega na nazwach hostów z nagłówków HTTP. Używanie tej techniki umożliwia
różnym hostom dzielić ten sam IP.
Wirtualne serwery WWW bazujące na nazwie są w gruncie rzeczy prostsze do konfiguracji, ponieważ
wystarczy odpowiednio skonfigurować DNS’a, (lub inaczej rezolwoać nazwy hostów) aby ten mapował
każdy z hostów do odpowiedniego jednego adresu IP i następnie skonfigurować serwer Appache do
rozpoznawania tych różnych hostów. Dodatkowo nie cierpimy tu na brak adresów IP. Dlatego zalecane jest
używanie wirtualnych serwerów bazujących na nazwach, poza pewnymi specyficznymi przypadkami, z
których kilka wymieniamy poniżej:
• Niektóre starsze przeglądarki – klienci – nie są kompatybilne z wirtualnymi serwerami bazującymi
na nazwach, ponieważ dla ich poprawnego działania klient musi wysyłać nagłówek HTTP Host
Header. Jest on wymagany przez HTTP/1.1, a nowoczesne przeglądarki mają go zaimplementowany
jako rozszerzenie HTTP/1.0.
• Ze względu na naturę protokołu SSL wirtualne serwery bazujące na nazwach nie mogą być używane
z tym protokołem.
5
• Niektóre systemy, lub wyposażenie implementujące zarządzanie pasmem przepustowości nie potrafi
rozróżniać hostów jeśli nie mają one odrębnych adresów IP.
2.1.2. Używanie wirtualnych serwerów bazujących na nazwach

Dyrektywy konfiguracyjne:
• DocumentRoot
• NameVirtualHost
• ServerAlias
• ServerName
• ServerPath
• VirtualHost
Jeżeli chcemy używać wirtualne serwery bazujące na nazwach to musimy określić adres IP (jeśli to możliwe
to również port) na serwerze który będzie akceptował żądania dla tych hostów. Konfigurujemy to przy
użyciu dyrektywy NameVirtualHost. W standardowym przypadku, kiedy jakikolwiek i każdy z adresów IP
na serwerze ma być użyty w tym celu można użyć * – jako argumentu w dyrektywie NameVirtualHost.
(dotyczy to tylko wersjo 1.3.13 i późniejszych). Użycie adresu IP w dyrektywie NameVirtualHost nie
powoduje automatycznie, że serwer będzie na tym porcie nasłuchiwał. Adres taki musi być oczywiście
połączony z interfejsem sieciowym serwera.
Kolejnym krokiem w konfiguracji jest określenie bloków <VirtualHost> dla każdego z hostów które chcemy
obsłużyć. Argument tej dyrektywy powinien być taki sam jak NameVirtualHost (tzn. ten sam adres IP, lub
*). Wewnątrz każdego z takich bloków <VirtualHost> musi wystąpić minimalnie dyrektywa ServerName ,
która określa wybrany serwer i dyrektywa DocumentRoot, która określa gdzie w systemie plików znajduje
się zawartość dla tego serwera.
Poniższy prosty przykład ilustruje taką sytuację. Załóżmy , że mamy dwie domeny: www.domain.tld i
www.otherdomain.tld i mają one przypisany ten sam adres IP. W pliku http.conf dopisujemy poniższe linie.
NameVirtualHost *
<VirtualHost *>
ServerName www.domain.tld
DocumentRoot /www/domain
</VirtualHost>
<VirtualHost *>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
6
Zamiast gwiazdek można wpisać konkretny adres serwera. (jest on wymagany w wersjach wcześniejszych
od 1.3.13)
Wiele serwerów chce być dostępnych poprzez więcej niż jedną nazwę. Jest to możliwe przy użyciu
dyrektywy ServerAlias umieszczonej w sekcji <VirtualHost>. Przykładowo dodanie do pierwszego bloku z
sekcją dla wirtualnych hostów następującej linii:
ServerAlias domain.tld *.domain.tld
Spowoduje, że wszystkie zapytania w domenie domain.tld będą obsługiwane przez wirtualny serwer
www.domain.tld. Można tutaj używać znaków zastępujących * i ?.
W sekcjach mogą być także używane inne dyrektywy które określają wtedy tylko konfigurację wybranego
wirtualnego hosta i nie mają wpływu na konfigurację pozostałych hostów.
W momencie przybycia żądania, serwer sprawdza czy używa ono adresu IP używanego przez wirtualne
hosty. Jeśli adres ten pasuje do dyrektywy NameVirtualHost, to przeszukiwane są kolejne sekcje
<VirtualHost> z pasującym adresem IP i próbuje znaleźć jedną gdzie ServerAlias lub ServerName pasuje do
żądanej nazwy hosta. Jeżeli jakiś wirtualny host zostanie w ten sposób znaleziony to jego konfiguracja jest
używana, jeśli nie to używana jest konfiguracja dla pierwszego wymienionego wirtualnego serwera. Dlatego
jest on często nazywany default virtual host (domyślnym wirtualnym hostem).
2.1.3. Kwestia kompatybilności z starszymi przeglądarkami
Jak już było wspominane wcześniej niektóre starsze przeglądarki nie wysyłają danych potrzebnych dla
prawidłowej pracy wirtualnych serwerów opartych na nazwach. Ci klienci będą zawsze wysyłani do
domyślnego wirtualnego hosta dla określonego adresu IP (the primary name-based virtual host).
Jednak przy użyciu dyrektywy ServerPath można zrobić pewne obejście dla takich wypadków. Obrazuje go
poniższy przykład.
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerPath /domain
DocumentRoot /web/domain
</VirtualHost>
Daje to taką możliwość, że teraz zapytanie URI: http://www.domain.tld/domain/ będzie obsługiwane przez
serwer www.domain.tld dla wszystkich klientów pomimo faktu, że dla tych którzy wysyłają odpowiedni
7
nagłówek może być dostępny przez: http://www.domain.tld/. Aby to działało należy w głównym wirtualnym
hoście dodać link do http://www.domain.tld/domain/.
2.2. IP-based Virtual Hosts – bazujące na IP wirtualne hosty

2.2.1. Czego wymagają bazujące na IP wirtualne hosty
Określenie IP-based (bazujące na IP) określa, że serwer musi mieć różne adresy IP dla każdego z bazujących
na IP wirtualnych hostów. Można to osiągnąć wyposażając maszynę w kilka fizycznych interfejsów
sieciowych lub przy użyciu „ip aliases” (aliasów IP).
2.2.2. Jak skonfigurować Appache do współpracy z bazującymi na IP wirtualnymi

hostami
Są dwie możliwości takiej konfiguracji. Można albo uruchomić oddzielnego demona – httpd dla każdego z
hostów, lub użyć jednego demona z wyspecyfikowanymi wirtualnymi hostami. Każde z tych rozwiązań ma
określone sytuacje kiedy należy je stosować.
Wielu demonów używamy gdy:
• Z względów bezpieczeństwa tj. w wypadku gdy przedsiębiorstwo1 nie chce aby ktokolwiek z
przedsiębiorstwa2 miał możliwość czytania ich danych poza sposobem przez sieć. W tym wypadku
potrzebne będą dwa demony, każdy z innymi użytkownikami, grupami portami i ustawieniami
katalogu głównego.
• Jeśli z jakichś powodów istnieje potrzeba nasłuchiwania na jakiś specyficzny adres, wtedy należy
stworzyć dla niego osobnego demona.
Jednego demona zaleca się używać w sytuacjach gdy:
• Dzielenie konfiguracji pomiędzy wirtualnymi serwerami jest dostępne.
• Maszyna obsługuje wielką liczbę zapytań, więc utrzymywanie wielu odrębnych demonów jest dość
kosztowne pod względem dostępnych zasobów.
2.2.3. Konfiguracja dla wielu demonów

Należy stworzyć odrębną instalację dla każdego z wirtualnych hostów. Dla każdej z tych instalacji
dyrektywa Listen w pliku konfiguracyjnym określa którego z hostów dotyczy (którego z adresów IP).
Listen www.smallco.com:80
W tym wypadku zalecane jest używanie adresu IP zamiast nazwy hosta.
8
2.2.4. Konfiguracja oparta na jednym demonie

W takim wypadku jeden serwer httpd odpowiada za zapytania do serwera głównego i wszystkich
wirtualnych hostów. Wewnątrz dyrektywy VirtualHost umieszczono różne wartości parametrów
konfiguracyjnych takich jak: ServerAdmin, ServerName, DocumentRoot, ErrorLog i TransferLog czy
CustomLog, dla poszczególnych hostów.
<VirtualHost www.smallco.com>
ServerAdmin webmaster@mail.smallco.com
DocumentRoot /groups/smallco/www
ServerName www.smallco.com
ErrorLog /groups/smallco/logs/error_log
TransferLog /groups/smallco/logs/access_log
</VirtualHost>
<VirtualHost www.baygroup.org>
ServerAdmin webmaster@mail.baygroup.org
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>
Zalecane jest używanie adresów IP zamiast nazw hostów wewnątrz dyrektyw.
9
3. Przykłady różnych konfiguracji
3.1. Name-based Virtual Hosts

3.1.1. Przykład 1
W tym przykładzie używamy składni dla serwerów Apache 1.3.13 i wyższych. Główna nazwa serwera to
server.domain.tld. Dodatkowo istnieją dwa aliasy dla tej nazwy www.domain.tld i www.sub.domain.tld
Proponowana konfiguracja:
...
Port 80
ServerName server.domain.tld
NameVirtualHost *
<VirtualHost *>
...
</VirtualHost>
<VirtualHost *>
DocumentRoot /www/subdomain
ServerName www.sub.domain.tld
...
</VirtualHost>
Wszystkie możliwe nazwy hostów są obsługiwane więc serwer bazowy nie będzie obsługiwał żadnych
odwołań. Z uwagi na fakt, że www.domain.tld jest pierwszy w liście serwerów ma on najwyższy priorytet i
może on być uznawany, za domyślny.
3.1.2. Przykład 2
Maszyna serwera ma aders IP (111.22.33.44) który rezolwuje na nazwę server.domain.tld. Dodatkowo
mamy dwa aliasy www.domain.tld i www.sub.domain.tld dla adersu 111.22.33.44.
...
Port 80
10
...
</VirtualHost>
...
</VirtualHost>
Poza localhost’em nie ma niewyspecyfikowanych adresów/portów dlatego bazowy serwer rezolwuje tylko
zapytania na localhost. Z uwagi na fakt, że www.domain.tld jest pierwszy w liście serwerów ma on
najwyższy priorytet i może on być uznawany, za domyślny.
3.1.3. Przykład 3
Maszyna na której jest serwer ma dwa adresy IP (111.22.33.44 i 111.22.33.55) które rezolwują do nazw
server1.domain.tld i server2.domain.tld. Alias www.domain.tld powinien być użyty dla serwera głównego
i powinien przechwytywać niewyspecyfikowane adresy. Chcemy używać wirtualnego hosta dla aliasu i
innego wirtualnego hosta o nazwie www.sub.domain.tld, dla żądań o host postaci *.sub.domain.tld.
Wirtualne hosty powinny używać adresu 111.22.33.55.
...
Port 80
...
</VirtualHost>
ServerAlias *.sub.domain.tld
...
</VirtualHost>
Każde żądanie do adresu innego niż 111.22.33.55 będzie obsługiwane przez serwer główny. Żądanie do
111.22.33.55 z nieznanym lub bez nagłówka Host: będzie obsługiwane przez www.otherdomain.tld.
3.1.4. Przykład 4
Maszyna z serwerem ma dwa adresy IP (192.168.1.1 i 111.22.33.55). Maszyna znajduje się pomiędzy
wewnętrzną (intranet) i zewnętrzną (internet) siecią. Na zewnątrz sieci nazwa server1.domain.tld resolwuje
11
Do zewnętrznego adresu IP (111.22.33.55), ale wewnątrz sieci, ta sama nazwa rezolwuje do wewnętrznego
adresu IP (192.168.1.1).
Ten serwer może być tak skonfigurowany, aby odpowiadał na zewnętrzne i wewnętrzne zapytania tą samą
zawartością przy użyciu tylko jednego wirtualnego serwera.
...
<VirtualHost 192.168.1.1 111.22.33.55>
DocumentRoot /www/server1
ServerName server1.domain.tld
ServerAlias server1
...
</VirtualHost>
3.1.5. Przykład 5
Przykład ten pokazuje użycie serwera o jednym IP do obsługi wielu domen przy pomocy portów. Ważne
jest, że w tagach "NameVirtualHost" specyfikowany jest także port. Próba użycia <VirtualHost name:port>
bez wcześniejszego NameVirtualHost name:port nie zadziała
...
NameVirtualHost 111.22.33.44:80
NameVirtualHost 111.22.33.44:8080
<VirtualHost 111.22.33.44:80>
DocumentRoot /www/domain-80
</VirtualHost>
<VirtualHost 111.22.33.44:8080>
DocumentRoot /www/domain-8080
</VirtualHost>
<VirtualHost 111.22.33.44:80>
DocumentRoot /www/otherdomain-80
</VirtualHost>
<VirtualHost 111.22.33.44:8080>
DocumentRoot /www/otherdomain-8080
</VirtualHost>
12
3.2. IP-based Virtual Hosts

3.2.1. Przykład 1
Maszyna serwera ma dwa adresy (111.22.33.44 and 111.22.33.55) które rezolwują do nazw
server.domain.tld i www.otherdomain.tld. Nazwa www.domain.tld jest aliasem dla server.domain.tld i
powinna reprezentować serwer bazowy.
...
Port 80
...
</VirtualHost>
www.otherdomain.tld może być osiągnięte tylko przez adres 111.22.33.55, podczas gdy www.domain.tld
może być osiągnięte tylko przez 111.22.33.44
3.2.2. Przykład 2
Sytuacja jak wyżej ale nie chcemy mieć serwera bazowego.
...
Port 80
...
</VirtualHost>
...
</VirtualHost>
Serwer bazowy jest niedostępny ponieważ wszystkie adresy IP maszyny są użyte przez bazujące na IP
wirtualne hosty (tylko żądanie do localhost może dosięgnąć ten serwer).
13
3.2.3. Przykład 3
Maszyna serwera ma dwa adresy IP(111.22.33.44 i 111.22.33.55) które rezolwwują do nazw
server.domain.tld i www-cache.domain.tld. Nazwa hosta www.domain.tld jest aliasem dla server.domain.tld i
reprezentuje serwer bazowy. www-cache.domain.tld stanie się proxy-cache nasłuchującym na porcie 8080,
kiedy sam web serwer używał będzie portu 80.
...
Port 80
Listen 111.22.33.44:80
Listen 111.22.33.55:8080
<VirtualHost 111.22.33.44:80>
...
</VirtualHost>
<VirtualHost 111.22.33.55:8080>
ServerName www-cache.domain.tld
...
<Directory proxy:>
Order Deny,Allow
Deny from all
Allow from 111.22.33
</Directory>
</VirtualHost>
Główny serwer jest nieosiągalny, bo wszystkie adresy IP (poza localhost) są używane przez wirtualne hosty
bazujące na IP. Web serwer jest osiągalny tylko poprzez pierwszy adres na porcie 80 a proksy tylko poprzez
drugi adres na porcie 8080.
3.3. Mixed name-/IP-based vhosts

Maszyna serwer ma trzy adresy IP 111.22.33.44, 111.22.33.55 i111.22.33.66 które odpowiadają kolejno
nazwom server.domain.tld, www.otherdomain1.tld i www.otherdomain2.tld. Adres 111.22.33.44 użyjemy
dla kilku name-based vhosts a pozostałe adresy dla IP-based vhosts.
...
Port 80
14
...
</VirtualHost>
DocumentRoot /www/subdomain1
ServerName www.sub1.domain.tld
...
</VirtualHost>
DocumentRoot /www/subdomain2
...
</VirtualHost>
DocumentRoot /www/otherdomain1
ServerName www.otherdomain1.tld
...
</VirtualHost>
DocumentRoot /www/otherdomain2
ServerName www.otherdomain2.tld
...
</VirtualHost>
3.4. Port-based vhosts

Maszyna serwer ma jeden adres IP 111.22.33.44 odpowiadający nazwie www.domain.tld. Jeśli nie mamy
możliwości posiadania innego adresu lub aliasu dla tego serwera możemy użyć port-based vhosts jeśli
potrzebujemy wirtualnych hostów do przedstawiania różnych stron.
...
Listen 80
Listen 8080
<VirtualHost 111.22.33.44:8080>
DocumentRoot /www/domain2
...
</VirtualHost>
Zapytanie do www.domain.tld na port 80 obsługuje serwer główny, a zapytanie na port 8080 serwer
wirtualny.
15
3.5. Użycie _default_ w vhostach

3.5.1. Przykład 1
Wyłapywanie każdego IP i na każdym porcie, tj. kombinacji adres/port która nie jest używana dla żadnego z
wirtualnych hostów.
...
<VirtualHost _default_:*>
DocumentRoot /www/default
...
</VirtualHost>
Takie użycie default vhost zabezpiecza przed zapytaniami do serwera głównego..
default vhost nigdy nie obsługuje zapytań do kombinacji adres/port używanej dla name-based vhosts. Jeśli
żądanie odwołuje się do nieznanego lub nie ma nagłówka z hostem to zawsze jest obsługiwane przez główny
name-based vhost (tj. vhost którego adres/port pojawia się jako pierwszy w pliku z konfiguracyjnym).
Można też użyć AliasMatch lub RewriteRule aby przypisać pojedynczą stronę informacyjną lub
skrypt.
3.5.2. Przykład 2
Konfiguracja jak serwera wyżej , przy czym serwer nasłuchuje na różnych portach, przy czym my chcemy
użyć drugiego _default_ vhost dla portu 80.
...
<VirtualHost _default_:80>
DocumentRoot /www/default80
...
</VirtualHost>
<VirtualHost _default_:*>
...
</VirtualHost>
Domyślny vhost dla portu 80 (który musi pojawić się przed default vhost z gwiazdką) łapie wszystkie
żądania do niewyspecyfikowanych IP. Główny serwer nie jest nigdy używany.
3.5.3. Przykład 3
Chcemy mieć default vhost dla portu 80, ale żadnych innych domyślnych vhosts.
16
...
<VirtualHost _default_:80>
...
</VirtualHost>
Żądanie do niewyspecyfikowanego adresu na port 80 jest obsługiwane przez default vhost ,a wszystkie inne
żądania do niewyspecyfikowanego adresu i portu są obsługiwane przez serwer główny.
3.6. Użycie dyrektywy ServerPath

Mamy serwer z dwoma name-based vhost’ami. W celu dopasowania odpowiednich wirtualnych hostów
klient musi wysłać odpowiedni nagłówek (correct Host: header) Stare przeglądarki - klienci z
HTTP/1.0 nie wysyłają takich nagłówków i serwer Apache nie ma wskazówki który vhost klient chce
osiągnąć (i odpowiada żądaniem do pierwszego vhost’a). W celu wprowadzenia kompatybilności wstecz
Pierwszy vhost zwraca pojedynczą stronę z linkami (prefixami URL do name-based virtual hosts).
...
# primary vhost
RewriteEngine On
RewriteRule ^/.* /www/subdomain/index.html
...
</VirtualHost>
DocumentRoot /www/subdomain/sub1
ServerPath /sub1/
RewriteEngine On
RewriteRule ^(/sub1/.*) /www/subdomain$1
...
</VirtualHost>
DocumentRoot /www/subdomain/sub2
ServerPath /sub2/
RewriteEngine On
RewriteRule ^(/sub2/.*) /www/subdomain$1
...
</VirtualHost>
Ze względu na dyrektywę ServerPath żądanie URL postaci: http://www.sub1.domain.tld/sub1/ jest
zawsze obsługiwane przez sub1-vhost Żądanie URL: http://www.sub1.domain.tld/ jest obsługiwane przez
17
sub1-vhost jeśli klient wysyła odpowiedni nagłówek correct Host :header. Gdy nagłówek nie jest
wysyłany klient dostaje stronę informacyjną z pierwszego hosta.
Żądanie do http://www.sub2.domain.tld/sub1/ jest również zawsze obsługiwane przez sub1-vhost jeśli klient
nie wysyła nagłówka.
Dyrektywa RewriteRule używana jest w celu upewnienia się, że klient wysyłający poprawny nagłówek
może używać obu wariantów URL tj. z lub bez prefix’a URL.
18
4. Obsługa skryptów CGI
4.1. Uwagi wstępne

Jednym z założeń odnośnie konfiguracji była możliwość używania skryptów CGI, przy czym skrypty te mają
być uruchamiane z prawami użytkownika innego dla każdego serwisu wirtualnego, a nie z prawami
użytkownika który uruchomił serwer. Możliwość takiego uruchamiania skryptów wprowadzono w Appache
1.2 przy pomocy programu suEXEC. SuEXEC pozwala na uruchamianie programów CGI i SSI z innymi
Id’ami użytkownika niż ID użytkownika uruchamiającego serwer. Pozwala to w znaczny sposób zredukować
ryzyko bezpieczeństwa związane z pozwalaniem użytkownikom na pisanie i uruchamianie ich prywatnych
skryptów CGI . Jednak niepoprawne skonfigurowanie suEXEC’a może powodować powstanie nowych dziur
w systemie bezpieczeństwa.
System operacyjny musi umożliwiać wykonanie operacji setuid i setgid. Instalacja suEXEC’a nie jest
dołączona do standardowej instalacji Appache z uwagi na jego duże wymagania konfiguracyjne i trzeba go
doinstalować (można to zrobić również na etapie konfiguracji przed instalacją i zainstalować suExeca razem
a Appachem). Konfiguracja powinna być przeprowadzana ostrożnie.
4.2. Model bezpieczeństwa w suEXEC’u

SuExec bazuje na programie wykorzystującym setuid. Program ten jest wywoływany przez serwer Appache,
kiedy otrzymuje on żądanie o wykonanie skryptu CGI lub SSI, a administrator określił, że skrypt ten ma być
uruchamiany z innym identyfikatorem użytkownika niż identyfikator uruchamiającego serwer. Appache
dostarcza do suEXEC’a nazwę programu, ID’y grupy i użytkownika pod którymi program ten powinien być
wykonany. W tym momencie suEXEC wykonuje następujący proces. Jeśli któryś z etapów zawiedzie
logowany jest błąd.
1. Czy suEXEC był wywołany z odpowiednią liczbą parametrów
2. Czy użytkownik wywołujący suEXEC’a jest prawidłowym użytkownikiem systemu.
3. Czy ten prawidłowy użytkownik systemu może uruchamiać suEXEC’a.
4. Czy program nie ma czasem niebezpiecznych odwołań hierarchicznych. ( / .. )
5. Czy prawidłowa jest nazwa użytkownika docelowego.
6. Czy prawidłowa jest grupa użytkownika docelowego.
7. Czy docelowy użytkownik nie jest superużytkownikiem
8. Czy Id docelowego użytkownika jest określonego powyżej minimalnego ID.
9. Czy grupa docelowa nie jest grupą superużytkownika
10. Czy ID grupy docelowej jest powyżej określonego minimum
11. Czy suEXEC może się stać docelowym użytkownikiem i grupą.
19
12. Czy istnieje katalog w którym program się znajduje.

13. Czy katalog ten jest w obrębie przestrzeni webowe serwera.
14. Czy katalog nie ma praw do zapisu przez nikogo innego.
15. Czy program docelowy istnieje
16. Czy program nie ma praw do zapisu przez nikogo innego.
17. Czy docelowy program nie jest programem wywołującym setguid lub setuid.
18. Czy docelowy użytkownik/grupa to ten sam co użytkownik/grupa programu.
19. Czy można usunąć zmienne procesu i zapewnić bezpieczeństwo operacji.
20. Czy suEXEC może stać się docelowym programem i wykonać go.
W tym momencie suEXEC kończy a program docelowy uruchamia się.
4.3. Konfiguracja i instalacja suEXEC’a

W przypadku gdy Appache jest już zainstalowany i należy tylko doinstalować suEXEC’a dokonujemy
modyfikacji w pliku suexec.h znajdującym się w podkatalogu katalogu instalacyjnego – src/support/suexec.h
(szczegółowe informacje można znaleźć na stronie w rozdziale 7). Jeśli instalujemy suExec’a razem z
Appachem to poniżej znajdują się opcje do konfigurowania parametrów tej instalacji.
--enable-suexec
Włączenie seEXeC’a do instalacji
--suexec-caller=UID
Użytkownik który normalnie uruchamia serwer Appache, jedyny możliwy.
--suexec-docroot=DIR
Określa DocumentRoot (główny katalog) dla Apache. Początek hierarchii używanej przez seEXEC.
Domyślnie wartość --datadir z sufiksem "/htdocs", np. jeśli konfigurujemy z --
datadir=/home/apache" to katalog "/home/apache/htdocs" jest używany jako główny dla
suEXECa.
--suexec-logfile=FILE
Nazwa pliku do logowania błędów, domyślnie "suexec_log" w katalogu (--logfiledir).
--suexec-userdir=DIR
Określa podkatalog w katalogach użytkowników gdzie suEXEC ma mieć dostęp. Wszystkie
uruchamialne programy w tym katalogu będą uruchamiane jako programu użytkownika więc powinny
być bezpieczne. Wartość domyślna to "public_html".
W przypadku serwerów wirtualnych z różnymi UserDir dla każdego z nich, konieczne jest określenie
dla nich jednego katalogu wspólnego wyżej w hierarchii.
--suexec-uidmin=UID
Najniższy UID dopuszczony do użycia przez suEXEC. Dla większości systemów 100 lub 500 jest
domyślne.
--suexec-gidmin=GID
Najniższy GID dopuszczony do użycia przez suEXEC. Dla większości systemów 100 jest domyślne.
20
--suexec-safepath=PATH
Określa bezpieczną ścieżkę w środowisku do plików uruchomieniowych CGI. Domyślnie
"/usr/local/bin:/usr/bin:/bin".
Przed instalacją można sprawdzić ustawienia dla suEXEC’a przy pomocy opcji –layout.
Dalsza instalacja przebiega standardowo, a domyślnym katalogiem dla suEXEC’a jest
"/usr/local/apache/sbin/suexec". Po uruchomieniu Appache szuka suexec’a w tym właśnie katalogu. Jeśli
znajdzie lub nie to loguje informację o nim do error_log’aa.
4.4. Użycie suEXEC’a z wirtualnymi serwerami

W przypadku wirtualnych serwerów użycie suEXEc’a następuje przy pomocą dyrektyw User i Group w
sekcji definicji VirtualHost. Ustawiając wartości tych dyrektyw na inne niż dla głównego serwera uzyskamy
to o co nam chodzi, czyli wszystkie zapytania do zasobów CGI będą uruchamiane jako User i Group
zdefiniowane przez nas w sekcji VirtualHost. Jeśli jedna lub żadna z nich nie będzie wyspecyfikowana w
omawianej sekcji użyte zostaną ustawienia serwera głównego. Przykładem jest nasza konfiguracja (patrz
rozdział 7.)
21
5. Format Logów
Serwer Appache ma bardzo rozbudowany format logów. W naszym przypadku poza standardowym
error_log‘iem który informował nas o błędach konfiguracji czy też uruchomieniu np. suExeca używaliśmy
też logów do zrzucania informacji które następnie analizowaliśmy w celu uzyskania danych o ilości
odwiedzin poszczególnych serwisów.
Bardzo wygodnym mechanizmem jest definiowanie stringu opisującego formatowanie logów. Umożliwia to
wyłuskanie i zapisanie tylko tych informacji które nas interesują. I takie rozwiązanie zastosowaliśmy dla
naszego zadania przypisując nazwę dla stworzonego przez nas formatu i aplikując ją do wszystkich logów
poszczególnych wirtualnych serwerów. Umieszczenie dyrektywy określającej plik docelowy i format
generowania logów wewnątrz deklaracji wirtualnego hosta możemy albo zapisywać informacje do osobnych
logów dla każdego serwisu (tak jak w naszym wypadku), albo do jednego wspólnego logu odpowiednio
oznaczając każdy serwis który z wpisów jest wygenerowany przez niego. (Patrz przykład w pkt 8). Możliwe
jest także rozwiązanie pośrednie w którym cześć logów jest zapisywana do osobnych logów a część do
wspólnego.
5.1. Ostrzeżenie związane z bezpieczeństwem

Każdy kto ma dostęp do katalogu gdzie Appache przechowuje logi może również dostać się do pliku
zawierającego UID pod jakim serwer jest wystartowany. Dlatego ważne jest aby nie umozliwiać
użytkownikom dostępu do tego pliku.
5.2. Error Log

Jest to log używany za najważniejszy. W konfiguracji używamy dyrektyw ErrorLog i LogLevel. Do tego
logu Appache wypisuje informacje diagnostyczne i zapisuje wszelkie błędy które wystąpiły podczas pracy i
przetwarzania zapytań. Czyli jst to pierwsze miejsce gdzie należy spojrzeć gdy coś nie działa. A oto przykład
typowego wpisu do Error loga:
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server
configuration: /export/home/live/ap/htdocs/test
Pierwszym elementem jest data i czas wiadomości. Następnie rodzaj komunikatu. Następnie adres IP klienta
generującego błąd i ścieżkę do żądanego dokumentu.
Error log zawiera również różne informacje generowane poprzez skrypt CGI.
22
5.3. Access Log

Log dostępu zawiera wszystkie odwołania przetwarzane przez serwer, Położenie i zawartość logów jest
kontrolowana poprzez dyrektywę CustomLog. Dyrektywa LogFormat może być użyta do uproszczenia i
selekcji informacji które są przechowywane w logu. Różne wersje Appache używały różnych dyrektye
(TransferLog) i modułów mod_log_referer, mod_log_agent. Obecnie cała tą funkcjonalność zawiera w sobie
i sumuje dyrektywa CustomLog. Format tego stringu jest bardzo dogodny do konfiguracji i jest podobny do
znanego z C formatu funkcji printf.
5.3.1. Common Log Format

Typowa konfiguracja dla logu dostępu może wyglądać następująco:
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
Mamy tutaj zdefiniowana nazwe common dla określonego stringu formatującego. Poszczególne fragmenty
logów mają w sobie znak %_ który określa jaka informacja ma zostać w tym miejscu umieszczona. W
stringu tym zupełnie tak jak w printfie mogą być umieszczone napisy które zostaną skopiowane do loga.
Znaczek ” musi być zaback-slash’owany, a format może zawierać także takie znaki specjalne jak „\n” czy
„\t”.
Dyrektywa CustomLog tworzy nowy plik z logami przy użyciu formatu określonego przez nazwe (np. jak
wyżej – common). Log jest tworzony w katalogu względnym do ServerRoot, chyba, że zaczyna się od
slasha.
Powyżej przedstawiona konfiguracja zapisuje logi w formacie znanym jako (CLF) – Common Log Format –
i wygląda następująco.
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0"
200 2326
5.3.2. Opis części stringu formatującego
5.3.2.1. 127.0.0.1 (%h)
Jest to adres IP klienta (remote host) który robi zapytania do serwera. Jeśli HostNameLookups jest włączone,
To serwer próbuje określić hostname i zalogować właśnie ją zamiast adresu IP. Jednak nie jest to polecane z
uwagi na zwalnianie pracy serwera. Lepiej użyć post-processora logów jak np. logresolve w celu otrzymania
nazw hostów. Jeśli pomiędzy użytkownikiem i serwerem jest proksy do serwer pamięta tylko adres tego
Proksy.
5.3.2.2. (%l)
Napis "hyphen" oznacza ze jakieś informacje nie były dostępne. Apache httpd mnie będzie nawet próbował
dostępować do logu , chyba, że jest włączony IdentityCheck.
23
5.3.2.3. frank (%u)
To jest userid osoby, że dające osoby i dotyczy autentyjkacji HTTP.
5.3.2.4. [10/Oct/2000:13:55:36 -0700] (%t)
Określa czas końca obsługi zapytania.

m[day/month/year:hour:minute:second zone]
day = 2*digit
month = 3*letter
year = 4*digit
hour = 2*digit
minute = 2*digit
second = 2*digit
zone = (`+' | `-') 4*digit
Zmiany formatu czasu dokonujemy poprzez %{format}t.
5.3.2.5. "GET /apache_pb.gif HTTP/1.0" (\"%r\")
Linia żądania od klienta w podwójnych apostrofach. Zawiera ono wiele cennych informacji. Po pierwsze
Klient używa metody GET.Po drugie żąda pliku /apache_pb.gif, po trzecie używa protokołu
HTTP/1.0.
Można także logować tylko części tej linii żądania klienta. Dla przykładu string "%m %U%q %H" zaloguje
metodę, ścieżkę, string zapytania, protokół zwracając to samo co "%r".
5.3.2.6. 200 (%>s)
Kod statusu wysyłany zwrotnie do klienta. Określa czy operacja była pomyślna – zazwyczaj zaczynająca się
od 2), przy przekierowaniu (3), błędy z powodu klienta (4), błędy serwera (5). Pełną listę można znaleźć w
HTTP specification (RFC2616 section 10).
5.3.2.7. 2326 (%b)
Ostatni element jest rozmiarem obiektu zwracanym do klienta , bez nagłówków. Jeśli nic nie było zwracane
to będzie to „-” Żeby logować „0” dla pustego rozmiaru używamy %B zamiast małej litery.
5.3.3. Combined Log Format

Innym szeroko używanym stringiem formatującym logi jest Combined Log FormatMoże mieć nastepującą
postać.
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/acces_log combined
24
Ten format dokładnie odpowiada Common Log Format, ale ma dwa dodatkowe pola. Każde z nich używa
dyrektywy %{ header}i, gdzie header może być dowolnym zapytaniem HTTP. Log dostępu z tym
formatem wygląda następująco.
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200
2326 "http://www.example.com/start.html" "Mozilla/4.08 [en] (Win98;;Nav)"
Dodatkowe pola to:
"http://www.example.com/start.html" (\"%{Referer}i\")
"Referer" (sic) to HTTP request header. Daje stronę i klienta który się z niej łączy. (Powinna to być strona
która zawiera /apache_pb.gif).
"Mozilla/4.08 [en] (Win98; I ;Nav)" (\"%{User-agent}i\")

User-Agent HTTP request header. Przeglądarka klienta raportuje o sobie samej.
25
6. Appache - poprawa osiągów
Poniżej opisane są optymalizacje osiągów serwera WWW proponowane w książce: „Securing and
Optimizing Linux: RedHat Edition, A hands on guide for Linux professionals” autorstwa Gerhard
Mourani’ego. Ogólnie zmiany dotyczą kilku aspektów wydajnościowych, których takie ustawienia są
rekomendowane przez różne benchmarki.
6.1. Zmiany w pliku konfiguracyjnym

6.1.1. MaxKeepAliveRequests
MaxKeepAliveRequests 0
Opcja ta “MaxKeepAliveRequests” ilość żądań dopuszczalną na połączenie, kiedy opcja “KeepAlive” jest
ustawiona na “On”. Ustawienie tej wartości na “0” powoduje dopuszczanie do serwera nieograniczonej
liczby zapytań. Dla podwyższenia “performance” jest zalecane umożliwienie nieograniczonych zapytań.
6.1.2. MinSpareServers
MinSpareServers 16
Opcja “MinSpareServers” określa minimalną ilość bezczynnych procesów dzieci serwera, który nie
obsługuje żądań. Jest to ważny parametr tuning’owy. Dla bardzo obciążających operacji, rekomendowana
jest wartość “16”.
6.1.3. MaxSpareServers
MaxSpareServers 64
Opcja “MaxSpareServers” określa maksymalną ilość bezczynnych procesów dzieci serwera, który nie
obsługuje żądań. Jest to również ważny parametr tuning’owy. Dla bardzo obciążających operacji,
rekomendowana jest właśnie wartość “64”.
6.1.4. StartServers
StartServers 16
Opcja “StartServers” określa ilość procesów dzieci serwera, która zostanie uruchomiona na starcie serwera.
Tak jak poprezadnio jest to parametr tuning’owy Apache’a. Najbardziej zalecana jest wartość “16”
6.1.5. MaxClients
MaxClients 512
26
Opcja “MaxClients” określa ilość równoczesnych zapytań jakie Appache może obsługiwać. Najbardziej
optymalna jest wartość “512”.
6.1.6. MaxRequestsPerChild
MaxRequestsPerChild 100000
Opcja “MaxRequestsPerChild” określa ilość żądań na które pojedynczy proces potomny może odpowiadać.
I z tych samych przyczyn co wcześniejsze opcje ma być ustawiony na taką wartość.
6.2. mod_mmap_static moduł Apache’a

W Apache istnieje specjalny moduł nazywany “mod_mmap_static” który może być użyty dla zwiększenia
osiągów serwera. Moduł ten pracuje dostarczając statycznej listy najczęstszych zadań, nie zmienianych,
plików w RootDirectory. Więc jeśli pliki wyświetlane przez Apache nie zmieniają się za często,można użyć
tego modułu do statycznego zmapowania dokumentów do pamięci i zwiększenia tym samym szybkości
serwera.
Moduł mod_mmap_static musi być włączony podczas konfiguracji i kompilacji Apache’a.
6.2.1. Zmapowanie dokumentów do pamięci:

[root@deep /]# find /home/httpd/ona -type f -print | sed -e 's/.*/mmapfile &/' >
/etc/httpd/conf/mmap.conf
</home/httpd/ona> to RootDirectory, czy też dokładniej katalog z którego są serwowane dokumenty, a

</etc/httpd/conf/mmap.conf> jest miejscem, w którym utworzyć plik, “mmap.conf”, zawierający mapę
dokumentów z RootDirectory.
6.2.2. Modyfikacja httpd.conf

Po stworzeniu “mmap.conf” należy go zainkludować do pliku “httpd.conf” Apache’a. Czynimy to dodając
linie:
<IfModule mod_include.c>
Include conf/mmap.conf
</IfModule>
Po zmianach w piku konfiguracyjnym restartujemy Appache.
27
7. Klika zabezpieczeń Appache’a
Zmiana uprawnień do poszczególnych plików Web Server’a Appache może znacznie wpłynąć na jego
bezpieczeństwo. Podczas instalacji wiele z tych plików ma ustawione domyślnie zbyt wiele uprawnień.
Poniżej przedstawiamy kilka dodatkowych czynności które mogą temu zaradzić.
7.1. Read-only na “httpd”

Program “httpd” może być ustawiony na read-only przez super-user “root”, a uruchamiany przez owner’a,
group, czy others dla większego bezpieczeństwa.
7.2. Katalogi
Katalogi “/etc/httpd/conf” i “/var/log/httpd” nie muszą być oni do odczytu, zapisu czy wykonywania przez
innych.
[root@deep /]# chmod 511 /usr/sbin/httpd
[root@deep /]# chmod 750 /etc/httpd/conf/
[root@deep /]# chmod 750 /var/log/httpd/
7.3. Automatic indexing

Jeżeli “automatic indexing” katalogów jest włączone w pliku konfiguracyjnym Appache (IndexOptions), to
w przypadku zapytania do katalogu gdzie nie ma pliku index udostępniony zostaje dostęp do zawartości tego
katalogu. Jeśli w takim miejscu jest jakiś link może to powodować niebezpieczeństwo. Dla wyłączenia tego
należy usunąć prawa z katalogu DocumentRoot (ale nie z plików wewnątrz niego).
[root@deep /]# cd /home/httpd/
[root@deep httpd]# chmod 311 ona
[root@deep httpd]# ls -la
Teraz otrzymywać będziemy następujący komunikat:

Forbidden
You don't have permission to access “/ona/” on this server.
NOTKA: “ona” to DocumentRoot.
7.4. Zabezpieczenie “httpd.conf”

Bit immutable może być użyty aby zapobiec skasowaniu, przykryciu czy też stworzeniu linku
symbolicznego do pliku. Po skonfigurowaniu “httpd.conf” dobrym pomysłem jest zabezpieczenie go , np.
komendą:
[root@deep /]# chattr +i /etc/httpd/conf/httpd.conf
28
8. Składnia podstawowych dyrektyw
<VirtualHost> directive
Syntax: <VirtualHost addr[:port] [addr[:port]] ...> ... </VirtualHost>
Compatibility: Non-IP address-based Virtual Hosting only available in Apache 1.1 and later.
Compatibility: Multiple address support only available in Apache 1.2 and later.
NameVirtualHost directive
Syntax: NameVirtualHost addr[:port]
ServerName directive
Syntax: ServerName fully-qualified-domain-name
ServerAlias directive
Syntax: ServerAlias hostname [hostname] ...
Compatibility: ServerAlias is only available in Apache 1.1 and later.
ServerPath directive
Syntax: ServerPath directory-path
Compatibility: ServerPath is only available in Apache 1.1 and later.
DocumentRoot directive
Syntax: DocumentRoot directory-path
Default: DocumentRoot /usr/local/apache/htdocs
User directive
Syntax: User unix-userid
Default: User #-1
Group directive
Syntax: Group unix-group
Default: Group #-1
CustomLog directive
Syntax: CustomLog file|pipe format|nickname [env=[!]environment-variable]
Compatibility: Nickname only available in Apache 1.3 or later. Conditional logging available in 1.3.5 or
later.
ScriptAlias directive
Syntax: ScriptAlias URL-path file-path|directory-path
29
9. Nasza konfiguracja
Konfiguracja poniższa jest przykładową konfiguracją, którą stworzyliśmy dla wirtualnych hostów
bazujących na nazwach, konfiguracja ta dotyczy tworzy kilka wirtualnych hostów: www.domain1.com,
www.domain2.com, www.domain3.com, ... oraz obsługuje skrypty CGI z prawami innymi dla każdego z
hostów, które odpowiadają użytkownikom : d1,d2,d3, a nie z prawami użytkownika uruchamiającego
serwer. Host pierwszy jest domyślnym hostem dla danego adresu IP i dlatego nie ma możliwości odwołania
się do bazowego serwera, chyba że poprzez localhost.
9.1. Istalacja i konfiguracja Appache

Najpierw zainstalowaliśmy samego Appache bez suExec’a. Instalacja przebiegła standardowo, tj w katalogu
głównym z źródłami wpisaliśmy kolejno komendy.
cnfigure
mke
mke install
Spowodowało to zainstalowanie Appache w katalogu /usr/local/appache. W podkatalogu /conf
znajduje się plik konfiguracyjny do którego dopisaliśmy w sekcji dotyczącej wirtualnych hostów (na koniec
pliku) następujący kod.
LogFormat "%h" logfrmt # okreslenie formatu logów
NameVirtualHost 192.168.2.4 # adres IP wirtualnego hosta
<VirtualHost 192.168.2.4> #definicja pierwszego wirtualnego
#hosta , domyślnego dla tego IP
User d1 #Użytkownik i grupa potrzebne dla
Group wwwdomains #suExec’a i skryptów CGI
ServerName www.domain1.com #nazwa serwisu
DocumentRoot /home/d1/www #katalog główny serwisu
ScriptAlias /cgi-bin/ "/home/d1/www/cgi-bin/" #katalog na instalowane skrypty
CustomLog /www/logs/host_domain1 logfrmt #katalog i plik logów
</VirtualHost> #koniec definicji pierwszego hosta
<VirtualHost 192.168.2.4> #analogiczne definicje pozostałych
User d2 #hostów ......
Group wwwdomains
ServerName www.domain2.com
DocumentRoot /home/d2/www
ScriptAlias /cgi-bin/ "/home/d2/www/cgi-bin/"
CustomLog /www/logs/host_domain2 logfrmt
</VirtualHost>
30
User d3
Group wwwdomains
CustomLog /www/logs/host_domain3 logfrmt
</VirtualHost>
......
9.2. Doinstalowanie suExeca

Kolejnym krokiem było doinstalowanie suExeca (można to też było zrobić od razu). Wybraliśmy tą drogę
instalacji ponieważ najpierw testowaliśmy różne konfiguracje samych wirtualnych hostów także z CGI ale
bez uruchamiania z innymi prawami niż użytkownik głównego serwisu, u nas „nobody”.
Aby doinstalować suExec’a w katalogu z źródłami: /src/support modyfikujemy plik suexec.h .
Zmodyfikowane fragmenty zaznaczono pogrubieniem.
#ifndef _SUEXEC_H
#define _SUEXEC_H
#ifndef HTTPD_USER
#define HTTPD_USER "nobody"
#endif
#ifndef UID_MIN
#define UID_MIN 100
#endif
#ifndef GID_MIN
#define GID_MIN 100
#endif
#ifndef USERDIR_SUFFIX
#define USERDIR_SUFFIX "www/cgi-bin"
#endif
#ifndef LOG_EXEC
#define LOG_EXEC "/usr/local/apache/logs/cgi.log" /* Need me? */
#endif
#ifndef DOC_ROOT
#define DOC_ROOT "/home"
#endif
#ifndef SAFE_PATH
#define SAFE_PATH "/usr/local/bin:/usr/bin:/bin"
#endif
31
Opis zmian:
HTTPD_USER – (odpowiada --suexec-caller=UID z konfiguracji razem z appachem) to
użytkownik uruchamiający samego Appache. U nas to właśnie nobody
USERDIR_SUFFIX – (--suexec-userdir=DIR) to podkatalog w katalogu użytkownika w którym
są uruchamiane skrypty CGI, u nas www/cgi-bin
DOC_ROOT – (--suexec-docroot=DIR) określa początek hierarhi katalogów w których seExec
może uruchamiać CGI
Następnie wywołujemy komendę:

make suexec
A plik wykonywalny suexec kopiujemy do katalogu bin apache, ponieważ tak w domyślnej konfiguracji
powinien on się znajdować.
cp suexec /usr/local/apache/bin/suexec
I zmieniamy prawa i właściciela pliku
chown root /usr/local/apache/sbin/suexec
chmod 4711 /usr/local/apache/sbin/suexec
Poprawne uruchomienie Appache z obsługą CGI przez suExeca jest zapisywane w logu:
[Thu May 30 22:12:38 2002] [notice] suEXEC mechanism enabled (wrapper:
/usr/local/apache/bin/suexec)
9.3. Dodanie grupy, użytkowników i katalogów

Aby wszystko zaczęło działać konieczne jest jeszcze dodanie użytkowników dla każdego z serwisów.
Najpierw dodaliśmy grupę wwwdomains a następnie odpowiednio użytkowników d1, d2, d3, ..
W podkatalogu każdego z użytkowników stworzyliśmy katalog www na dokumenty i jego podkatalog cgi-
bin na skrypty. Ważne jest odpowiednie ustalenie własności do katalogów i plików aby należały one do
odpowiedniego użytkownika dla danej domeny.
9.4. Testy poprawnej konfiguracji

Dla sprawdzenia działania mechanizmu wirtualnych hostów w każdym z katalogów stworzyliśmy proste
pliki index.html. A w katalogu cgi-bin skrypt cgi informujący o użytkowniku który go wykonał – first.cgi.
#!/bin/bash
echo "Content-type: text/html";
echo "";
echo "";
echo "Hello, World. Domain3";
echo "User ID = $UID";
echo "`whoami`"
32
10. Skrypty przeglądające logi
Aby mieć możliwość analizowania informacji o ilości odwiedzin poszczególnych serwisów (naszych
wirtualnych hostów), po przetestowaniu różnych konfiguracji wirtualnych serwerów, skonfigurowaliśmy
nasz serwer w opisany powyżej sposób. Instalacja suExeca i obsługa sktyptów CGI nie jest związana z
informacjami w logach które przetwarzamy.
Rozwiązaniem które zastosowaliśmy jest generowanie logów przez każdy z wirtualnych serwerów do
osobnych plików w wcześniej stworzonym katalogu /www/logs/. Pliki te jak widać w konfiguracji to
odpowiednio host_domain1, host_domain2, host_domain3, .... Logować będziemy tylko
adresy IP hostów z których odwołania dotyczą poszczególnych wirtualnych serwerów.
LogFormat "%h" logfrmt # określenie formatu logu
# czyli tylko adres IP
User d1
Group wwwdomains
CustomLog /www/logs/host_domain1 logfrmt # określenie pliku
# docelowego dla logów i jego formatu
</VirtualHost>
User d2
Group wwwdomains
CustomLog /www/logs/host_domain2 logfrmt #to samo dla kolejnego
# hosta
</VirtualHost>
...
33
Wszystkie skrypty korzystają z basha i z perla.

Przykładowy plik z logami ma postać:
192.168.2.4
192.168.2.4
192.168.2.5
192.168.2.5
192.168.2.4
192.168.2.4
192.168.2.4
192.168.2.4
192.168.2.5
192.168.2.6
192.168.2.7
192.168.1.2
10.1. Dziesięć najczęściej odwiedzanych serwisów

Zliczanie ilości odwołać do różnych serwisów wirtualnych w celu stwierdzenia który z nich jest
najpopularniejszy najprościej rozwiązać konfigurując serwery wirtualne w pokazany sposób. Dzięki temu
każdy z serwerów ma swój plik z logami zawierającymi adresy IP z których ktoś oglądał dany serwis. Już po
rozmiarze loga można określić który z serwisów był częściej odwiedzany. Poniższy skrypt zlicza ilość linii
występującą w plikach poszczególnych serwisów, korzystając z faktu, że wszystkie te pliki są w tym samym
katalogu i zaczynają się od nazwy host_domaini
#!/bin/bash
a=`ls | grep hosts` #wyszukanie plików z logami hostów i podpisanie
#ich do ziemnej np: host_domain1 host_domain2
echo "10 najczęściej odwiedzanych serwisów"
#linia informacyjna co robi skrypt
perl -e 'for($i=0; $i <= $#ARGV; ++$i) #wywołanie perla dla linii
{ # i pętla po wszystkich argumentach
open(F,"@ARGV[$i]"); #otwieranie kolejnych plików
while($line = <F>){ #pętla po ich liniach
$addresses{@ARGV[$i]} += 1; #wpis do tablicy asocjacyjnej po
} # nazwę hosta za zinkrementowaną ilością linii
close F; #zamkniecie pliku
}
@tab = %addresses; #przepisanie do zwykłej tablicy w postaci
# ilość, linia, ilość, linia
$size = $#tab; #pobranie jej rozmiaru
for ($i=1; $i <= $size; $i+=2){ #petla co 2 po tej tablicy
print $tab[$i]," odwolan na: ", $tab[$i-1],"\n";
# z wypisaniem: liczba odwolan na <nazwa pliku z
# logami> i całość
}' $a |sort -gr|head #posortowana liczbowo malejąco i obciecie 10
#pierwszych
exit 0 #wyjscie z programu
34
W wyniku działania skryptu otrzymujemy (dla 4 serwisów w systemie):

10 najczęściej odwiedzanych serwisów
124 odwołan na: host_domain1
10.2. Dziesięć najczęstszych adresów, z których ktoś ogląda strony www

serwera danego serwera.
Skrypt zliczający ilość odwołać z jakiegoś adresu z którego jest oglądany dany nasz serwis bazuje na tych
samych plikach z logami co poprzedni skrypt. Jako parametr podaje się mu właśnie nazwę pliku z logami
hosta którego chcemy przeanalizować. Oto kod poniższego skryptu:
#!/bin/bash
if [ -z "$1" ] #testuje czy podano argument
then #jesli nie podano
echo "nie podales nazwypliku, uzycie: 10ex <logfile>" #to komunikat i
exit 1 #wyjscie z progr
elif [ ! -e "$1" ] #testuje czy podany plik istnieje
then #jesli nie podano
echo "nie ma takiego pliku, uzycie: 10ex <logfile>" #to komunikat i
else #jesli podano istniejacy plik
echo "10 adresow najczesciej odwiedzajacych serwis " #wypisanie
#informacji czego dotyczy skrypt
perl -e 'open(F,"@ARGV[0]"); #wywolanie perla z linia jako skrypt,
while($line = <F>){ #^otwarcie pliku i pentla po jego liniach
chop $line; #obcina karetke
$addresses{$line} += 1; #wpis do tablicy asocjacyjnej pod
#index lini
} #^lub inkrementacja istniejacego wpis
@tab = %addresses; #przepisanie do zwyklej tablicy
#ilosc,linia,ilosc,linia
$size = $#tab; #pobranie jej rozmiaru
for ($i=1; $i <= $size; $i+=2){ #petla co 2 po tej tablicy
print $tab[$i], " x adres:",$tab[$i-1],"\n"; #wypisanie ilosci x
#linia czyli IP z pliku
}
close F;' $1 |sort -gr|head #zamkniecie pliku, sortowanie liczbowe
#odwrocone i obciecie 10 pierwszych
fi #koniec ifa
W wyniku otrzymujemy następującą informację:
35
10 adresow najczesciej odwiedzajacych serwis

1234 x 192.168.2.4
133 x 192.168.2.5
123 x 192.168.2.6
104 x 192.168.2.7
89 x 192.168.1.2
12 x 156.149.50.80
11 x 156.149.50.3
10 x 156.149.5.3
6 x 156.149.4.4
1 x 156.149.4.45
36

Serwer WWW

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Serwer WWW

Uploaded by

Copyright:

Available Formats

AKADEMIA GÓRNICZO-HUTNICZA

Wydział Elektrotechniki, Automatyki, Informatyki i Elektroniki

Kierunek, rok studiów:

Michał Jaeschke E-mail: jaeschke@ernie.icslab.agh.edu.pl

Grzegorz Duda E-mail: dudek@ernie.icslab.agh.edu.pl

Kraków, maj 2002

2. Virtual Host – wirtuane serwery ________________________________________________________ 5

4. Obsługa skryptów CGI _______________________________________________________________ 19

9. Nasza konfiguracja __________________________________________________________________ 30

10. Skrypty przeglądające logi ____________________________________________________________ 33

1. Wstęp i opis zadań

Naszym zadaniem było skonfigurowanie serwer www do celów komercyjnych. Konfiguracja ta ma

2. Virtual Host – wirtuane serwery

2.1. Name-based Virtual Hosts – wirtualne serwery bazujące na nazwach

2.1.2. Używanie wirtualnych serwerów bazujących na nazwach

2.1.3. Kwestia kompatybilności z starszymi przeglądarkami

2.2. IP-based Virtual Hosts – bazujące na IP wirtualne hosty

2.2.2. Jak skonfigurować Appache do współpracy z bazującymi na IP wirtualnymi

2.2.3. Konfiguracja dla wielu demonów

2.2.4. Konfiguracja oparta na jednym demonie

3. Przykłady różnych konfiguracji

3.1. Name-based Virtual Hosts

3.2. IP-based Virtual Hosts

3.3. Mixed name-/IP-based vhosts

3.4. Port-based vhosts

3.5. Użycie _default_ w vhostach

3.6. Użycie dyrektywy ServerPath

4. Obsługa skryptów CGI

4.1. Uwagi wstępne

4.2. Model bezpieczeństwa w suEXEC’u

12. Czy istnieje katalog w którym program się znajduje.

4.3. Konfiguracja i instalacja suEXEC’a

4.4. Użycie suEXEC’a z wirtualnymi serwerami

5.1. Ostrzeżenie związane z bezpieczeństwem

5.2. Error Log

5.3. Access Log

5.3.1. Common Log Format

5.3.2. Opis części stringu formatującego

5.3.2.1. 127.0.0.1 (%h)

5.3.2.3. frank (%u)

To jest userid osoby, że dające osoby i dotyczy autentyjkacji HTTP.

5.3.2.4. [10/Oct/2000:13:55:36 -0700] (%t)

Określa czas końca obsługi zapytania.

Zmiany formatu czasu dokonujemy poprzez %{format}t.

5.3.2.5. "GET /apache_pb.gif HTTP/1.0" (\"%r\")

5.3.2.6. 200 (%>s)

5.3.2.7. 2326 (%b)

5.3.3. Combined Log Format

"Mozilla/4.08 [en] (Win98; I ;Nav)" (\"%{User-agent}i\")

6. Appache - poprawa osiągów

6.1. Zmiany w pliku konfiguracyjnym

6.2. mod_mmap_static moduł Apache’a

6.2.1. Zmapowanie dokumentów do pamięci:

</home/httpd/ona> to RootDirectory, czy też dokładniej katalog z którego są serwowane dokumenty, a

6.2.2. Modyfikacja httpd.conf

Po zmianach w piku konfiguracyjnym restartujemy Appache.

7. Klika zabezpieczeń Appache’a

7.1. Read-only na “httpd”

7.3. Automatic indexing

Teraz otrzymywać będziemy następujący komunikat:

7.4. Zabezpieczenie “httpd.conf”

8. Składnia podstawowych dyrektyw

9.1. Istalacja i konfiguracja Appache