Serwer WWW Apache

HTTP (HyperText Transfer Protocol) to sieciowy protokół, który zapewnia dostęp do stron sieci web w Internecie. Termin hypertext odnosi się do strukturyzowanego tekstu, który używa hyperlinków aby zezwolić na niesekwencyjny dostęp do informacji hostowanych na serwerze www przez protokół HTTP. Serwer WWW określany jest także serwerem HTTP. Klientem sieci web jest zazwyczaj przeglądarka taka jak Firefox, Google Chrome czy Ms Edge, która rozumie protokół HTTP i jest w stanie “rozmawiać” z serwerem webowym. Najbardziej popularnym serwerem, który dostarcza usługi webowe przy wykorzystaniu protokołu HTTP i HTTPS jest Apache. 

Apache to aplikacja działająca w architekturze klient/serwer, wykorzystuje demona httpd, który nasłuchuje na porcie 80 TCP (http) lub 443 TCP (https).

Komendy do kontrolowania Apache:

  • # apachectl – uruchamia, zatrzymuje, restartuje i sprawdza status procesu httpd. Do tych czynności może być wykorzystywany także systemctl lub service. Ponadto apachectl może testować składnie plików konfiguracyjnych.
  • # htpasswd – tworzy i modyfikuje pliki do składowania nazw użytkowników i haseł do autentykacji basic. Opcja –c tworzy plik, -m używa szyfrowania MD5 dla haseł.
  • # httpd – demon Apacha, uruchomiony z opcją -t sprawdza składnię plików konfiguracyjnych.

Więcej informacji w dokumentacji systemowej man.

Pliki z logami Apacha znajdują się w katalogu /var/log/httpd.

Pakiety związane z Apachem w RHEL to m.in:

  • httpd – demon Apacha.
  • httpd-tool -narzędzia do obsługi Apacha.
  • httpd-manual – dokumentacja i przykładowe pliki konfiguracyjne. Dostępna jest pod adresem http://localhost/manual.
  • mod_ssl – wsparcie dla stron bezpiecznych stron https.
  • mod_wsgi – wsparcie dla obsługi skryptów WSGI.

 

Pliki konfiguracyjne.

Cała konfiguracja Apacha składowana jest w katalogu /etc/httpd, główny plik konfiguracyjny to: /etc/httpd/http.conf.  Główne dyrektywy  pliku konfiguracyjnego przedstawia tabela poniżej.

 Dyrektywa  Opis
 ServerRoot Katalog z konfiguracją serwera, domyślnie /etc/httpd.
 Listen Port na którym nasłuchuje serwer. Domyślnie 80. Można poza portem określić także adres IP, na którym ma nasłuchiwać serwer.
 Include Określa położenie modułów wczytywanych podczas startu demona. domyślnie conf.modules.d/*.conf w odniesieniu do katalogu z konfiguracją apacha.
 User  Właściciel procesu httpd.
Group Grupa systemowa, do której należy demon httpd. Domyślną grupą jest apache.

 

Dyrektywy, które dotyczą domyślnego web serwera przedstawia tabela poniżej. Dyrektywy te dotyczą również hostów wirtualnych o ile nie są nadpisane przez te same dyrektywy wewnątrz definicji konfiguracji hosta wirtualnego.

Dyrektywa Opis
ServerName Nazwa web serwera (lub adres IP) i numer portu. Domyślnie www.example.com:80.
ServerAdmin Adres e-mail webmastera. Domyślnie root@localhost.
DocumentRoot Położenie katalogu z plikami web. Domyślnie /var/www/html.
DirectoryIndex Określa jaka strona ma być serwowana klientowi, który odwiedza serwer. Domyślnie index.html.
AccessFileName Plik używany do kontroli dostępu do serwera. Domyślnie .htaccess.
Alias Położenie katalogu do składowania plików poza DocumentRoot.
ScriptAlias Położenie skryptu CGI (Common Gateway Interface).
WSGIScriptAlias Położenie skryptu WSGI.
IncludeOptional Położenie dodatkowych plików konfiguracyjnych.
CustomLog Określa custom log i jego format. Domyślnie custom log składowany jest w logs/httpd/access_log w odniesieniu do katalogu ServerRoot.
ErrorLog Położenie logu z komunikatami o błędach. Domyślnie w logs/error_log w ServerRoot.
LogFormat Format dla komunikatów logowania.
LogLevel Poziom “gadatliwości” logów. Domyślnie warn, inne opcje to: debug, info, notice, error, crit, alert i emerg.
 Options Ustawia funkcjonalność związaną w katalogami, w których znajdują się pliki stron web.

  • ExecCGI – pozwala na uruchamianie skryptów CGI.
  • FollowSymLinks – pozwala na używanie dowiązań do katalogów z poza DocumentRoot.
  • Indexes – jeżeli w katalogu DirectoryRoot danego serwera web nie ma pliku index.html (lub index.php itd.) to wyświetlana jest zawartość tego katalogu zamiast strony web.
  • Includes – włącza include po stronie serwera (?).
  • MultiViews – pozwala na zamienniki rozszerzeń plików.
  • All – włącza wszystkie opcja poza MultiViews.
  • None – wyłącza wszystkie dodatkowe funkcjonalności.
AllowOverride Określa typy dyrektyw jakie mogą być zdefiniowane w pliku AccessFileName. Dyrektywy te kontrolują dostęp użytkowników i grup do katalogów prywatnych i hosta. Niektóre opcje:

  • All – pozwala na użycie wszystkich wspieranych dyrektyw AccessFileName.
  • AuthConfig – pozwala na użycie dyrektyw autoryzacyjnych takich jak AuthName, AuthType, AuthUserFile, AuthGroupFile oraz Require w AccessFileName.
 Require Zezwala lub zakazuje dostępu dla określonych użytkowników, grup, hostów, sieci lub domen.
 AddHandler  Mapują rozszerzenia plików do określonego handlera.

Wiele dyrektyw jest definiowanych wewnątrz kontenerów:

  • <Directory ……… >      </Directory>
  • <Files …………. >        </Files>
  • <IfModule ……. >       </IfModule>
  • <VirtualHost …. >     </VirtualHost>

 

Kontrola dostępu.

Ograniczanie dostępu do katalogów dla określonych użytkowników lub grup jest zarządzane przez dyrektywy zdefiniowane w pliku .htaccess lub bezpośrednio w kontenerze <Directory ....> w pliku httpd.conf i jego załącznikach. Użytkownicy mogą mieć inne hasła niż systemowe. Kluczowe dyrektywy związane z kontrolą dostępu na poziomie użytkownika przedstawia tabela poniżej.

 Dyrektywa Opis
AuthType Ustawia podstawową autentykację.
AuthName Dodaje komentarz.
AuthBasicProvider Typ używanej autentykacji. Domyślnie file.
 AuthUserFile  Określa plik z autoryzowanymi hasłami użytkowników.
 AuthGroupFile  Określa plik z autoryzowanymi hasłami grup.

 

Za ograniczanie dostępu na poziomie hosta odpowiada dyrektywa Require, przykłady jej użycia przedstawia tabela poniżej:

Dyrektywa Require Skutek
Require user <username or UID> Dostęp jest przyznany tylko dla określonego użytkownika (dotyczy katalogów).
Require not user <username orUID> Odmowa dostępu dla określonego użytkownika
Require group <group name orGID> Dostęp jest przyznany tylko dla określonej grupy (dotyczy zawartości zarządzanych przez grupy).
Require not group <group name or GID> Odmowa dostępu dla określonej grupy.
Require valid-user Dostęp jest przyznany dla ważnych (aktualnych) użytkowników.
Require ip 192.168.0 15.2 Dostęp jest przyznany tylko dla podsieci 192.168.0 i 15.2.
Require not ip 192.168.0 15.2 Odmowa dostępu dla podsieci 192.168.0 i 15.2.
Require host server2 Dostęp jest przyznany dla hosta server2.
Require not host server2 Odmowa dostępu dla hosta server2.
Require host example.com Dostęp jest przyznany dla domen example.com.
Require not host .example.com Odmowa dostępu dla domen example.com.
Require all granted Dostęp jest przyznany  dla wszystkich hostów.
Require all denied Odmowa dostępu dla wszystkich hostów.

 

Przykład 1:  zezwolenie na dostęp bez hasła do /var/www/example dla użytkowników user1, user2 i grupy dba.

Przykład 2:  zezwolenie na dostęp bez hasła do /var/www/example dla użytkowników user1, user2 i grupy dba z domeny example.net, podsieci 192.168.0 i hosta server2.example.com. Odmowa dostępu z domeny example.org.

Przykład 3:  zezwolenie na dostęp z hasłem do /var/www/example dla użytkowników user1, user2 i grupy dba z domeny example.net, podsieci 192.168.0 i hosta server2.example.com. Odmowa dostępu z domeny example.org.

Zawartość pliku The .htaccess:

 

Wymagania SELinux.

Zmienne boolean związane z Apachem przedstawia tabela poniżej.

Boolean Opis
httpd_anon_write Zezwala/zabrania Apachowi na zapis do katalogów z etykietą public_content_rw_t  tak jak do katalogów publicznych.
httpd_sys_script_anon_write  Zezwala/zabrania skryptom Apacha na zapis do katalogów z etykietą public_content_rw_t  tak jak do katalogów publicznych.
httpd_enable_cgi Włącza/wyłącza możliwość uruchamiania skryptów CGI z etykietą httpd_sys_script_exec_t .
httpd_enable_ftp_server Zezwala/zabrania Apachowi działania jako serwer FTP i nasłuchiwania na porcie 21.
httpd_enable_homedirs Włącza/wyłącza Apachowi dostęp do katalogów domowych użytkowników.
httpd_use_cifs Zezwala/zabrania Apachowi na używanie podmontowanych zasobów Samba typu cifs_t.
httpd_use_nfs Zezwala/zabrania Apachowi na używanie podmontowanych zasobów  typy nfs_t .

Poza zmiennymi boolean SELinux wymaga aby był ustawiony odpowiedni kontekst na katalogach związanych z Apachem.

A zatem katalogi z konfiguracją muszą mieć ustawiony kontekst httpd_config_t,  katalogi ze stronami web kontekst httpd_sys_content_t, a katalogi z logami kontekst httpd_log_t.

 

Konfiguracja domyślnego web serwera.

1. Instalacja pakietu Apache.

2. Odblokowanie protokołu http na firewallu:

3. Autostart, uruchomienie i status Apacha:

4. Weryfikacka możliwości dostępu do domyślnej strony web:

5. Weryfikacja na komputerze klienta:

 

Wystawienie innej strony na domyślnym web serwerze.

1. Utworzenie strony w katalogu DocumentRoot  /var/www/html:

2. Modyfikacja pliku /etc/hosts:

3. Modyfikacja konfiguracji w pliku /etc/httpd/conf/httpd.conf:

4. Sprawdzenie poprawności składni pliku httpd.conf:

5. Weryfikacja dostępu do nowej strony:

 

Przyznanie dostępu do prywatnego katalogu web serwera.

1. Utworzenie prywatnego katalogu w DocumentRoot:

2. Zmiana praw dostępu do katalogu:

3. Utworzenie pliku index.html w prywatnym katalogu:

4. Dodanie kontekstu SELinux typ httpd_sys_content_t dla katalogu /var/privusr:

5. Modyfikacja konfiguracji w pliku httpd.conf:

7. Weryfikacja poprawności składni pliku httpd.conf:

8. Utworzenie pliku .htaccess w katalogu /var/privusr:

9. Utworzenie hasła dla użytkownika user1 i umieszczenie go komendą htpasswd w pliku AuthUserFile (/etc/httpd/conf/.userdb).
Hasło może być inne niż hasło systemowe użytkownika user1.

10. Zmiana praw dostępu do pliku AuthUserFile file:

11. Restart Apacha:

12. Test konfiguracji ze zdalnego systemu przy wykorzystaniu dowolnej przeglądarki:

Żeby sprawdzić czy nie występują jakieś błędy można wykorzystać tail:

 

Zapewnienie dostępu do katalogów pracy grupowej.

1. Utworzenie katalogu, który będzie zarządzany przez grupę w DocumentRoot:

2. Create an index.html file in the directory:

3. Dodanie kontekstu SELinux httpd_sys_content_t dla katalogu /var/privgrp:

4. Modyfikacja dyrektyw w pliku /etc/httpd/conf/httpd.conf:

5. Weryfikacja:

6. Utworzenie pliku .htaccess file w katalogu /var/privgrp:

7. Utworzenie AuthGroupFile (/etc/httpd/conf/.userdb) i dodanie informacji o grupie:

8. Zmiana uprawnień do pliku AuthGroupFile:

9. Utworzenie haseł dla członków grupy i umieszczenie ich w pliku AuthUserFile (/etc/httpd/conf/.grouppassworddb) komendą htpasswd:

10. Restart Apacha:

11. Test konfiguracji ze zdalnego systemu przy wykorzystaniu dowolnej przeglądarki:

 

Zapewnienie dostępu do serwera web tylko dla wybranego hosta na niedomyślnym porcie.

1. Modyffikacja pliku /etc/httpd/conf/httpd.conf:

2. Weryfikacja ppoprawności składni pliku httpd.conf:

3. Restart Apacha:

4. Otwarcie portu TCP 8989 na firewallu:

5. Dodanie portu 8989 TCP do polityki SELinux dla typu http_port_t:

6. Test konfiguracji z systemu w domenie example.com domain i z podsieci 192.168.1.0/24 przez przeglądarkę Firefox:

 

Wirtualne web serwery – hosty wirtualne.

Apache pozwala na uruchamianie wielu web serwerów na jednym systemie. Każdy wirtualny host może zarówno współdzielić jeden adres IP jak i mieć przypisany osobny adres IP.  Konfigurację hostów wirtualnych umieszczamy w katalogu /etc/httpd/conf.d w osobnych plikach. Przykład kontenera z konfiguracją hosta wirtualnego:

Weryfikacja poprawności konfiguracji hosta wirtualnego przeprowadzana jest komendą:

 

Konfiguracja prostego hosta wirtualnego.

1. Utworzenie pliku /etc/httpd/conf.d/vhost1.conf o treści:

2. Utworzenie katalogu, w którym będzie składowana strona:

3. Utworzenie pliku index.html w DocumentRoot:

4. Weryfikacja:

5. Modyfikacja pliku /etc/hosts:

6. Restart Apacha:

7. Test:

 

Konfiguracja bardziej skomplikowanego hosta wirtualnego.

1. Utworzenie pliku /etc/httpd/conf.d/vhost2.conf o treści:

2. Utworzenie katalogu, w którym będzie składowana strona:

3. Utworzenie pliku index.html w DocumentRoot:

4. Weryfikacja:

5. Modyfikacja pliku /etc/hosts:

6. Dodanie kontekstu SELinux typ httpd_sys_content_t dla katalogu /var/vhost2:

7. Dodanie portu TCP 8900 do polityki SELinux typ http_port_t:

8. Odblokowanie portu TCP 8900 na firewallu:

9. Restart Apacha:

10. Test dostępu lokalnie i zdalnie:

 

Web serwery SSL/TLS.

Secure Socket Layer (SSL) to protokół kryptograficzny, który pozwala systememom na bezpieczną komunikację przez sieć. Może być używane wraz z Transport Layer Security (TLS), protokołem który zapewnia integralność, prywatność i bezpieczną autentykację. Apache działający w oparciu o SSL i TLS może być określany jako HTTPS (HyperText Transfer Protocol Secure)  webowy serwer SSL. Serwer HTTPS używa cyfrowego certyfikatu by dowieść swej autentyczności klientom, którzy się do niego podłączają. Certyfikat podpisywany jest przez Certificate Authority (CA). Aby uzyskać podpis aplikant generuje parę zaszyfrowanych kluczy prywatny/publiczny oraz
CSR (Certificate Signing Request) na serwerze, dla którego ma być wystawiony certyfikat. CSR zawiera dane identyfikujące aplikanta takie jak nazwa, adres czy nazwę systemu hosta. CSR jest szyfrowany przed wysłaniem do CA. CA przegląda CSR i wydaje podpisany certyfikat. Innym typem certyfikatów są certyfikaty podpisane samodzielnie. Taki certyfikat jest wygenerowany lokalnie i jest używany do celów testowych.

W RHEL pakiety wspierające HTTPS to mod_ssl i openssl. Po instalacji mod_ssl w katalogu /etc/httpd/conf.d pojawi się przykładowy plik ssl.conf, który może byyć wykorzystany jako wzór przy uruchamianiu web serwerów ssl. Openssl oferuje wiele narzędzi do tworzenia i zarządzania zaszyfrowanymi kluczami, CSRami, cyfrowymi certyfikatami oraz połączeniami HTTPS. Komendy dostępne w pakiecie openssl można wylistować w sposób następujący:

Przykład wirtualnego hosta SSL:

 

Generowanie pary kluczy i samodzielnie podpisanego certyfikatu.

1. Instalacja pakietów mod_ssl i openssl:

2. Zmiana katalogu na /etc/pki/tls/certs i wygenerowanie klucza prywatnego o rozmiarze 2048 bits algorytmem RSA.
Zapisanie klucza w pliku server.example.com.key.

3. Utworzenie żądania podpisania certyfikatu (CSR) w pliku server.example.com.csr przy wykorzystaniu klucza prywatnego wygenerowanego w poprzednim punkcie:

4. Wygenerowanie samodzielnie podpisanego certyfikatu (server.example.com.crt) ważnego 120 dni przy wykorzystaniu klucza prywatnego (server.example.com.key) i żądania podpisania certyfikatu (server.example.com.csr) utworzonych wcześniej:

5. Zabezpieczenie kluczy nadaniem im odpowiednich praw dostępu and umieszczenie ich w katalogu /etc/pki/tls/private:

6. Sprawdzenie ważności i statusu certyfikatu komendą openssl:

 

Konfiguracja bezpiecznego hosta wirtualnego SSL.

1. Utworzenie DocumentRoot:

2. Wykorzystanie przykładowego pliku /etc/httpd/conf.d/ssl.conf do konfiguracji witual hosta. Zmieniamy w pliku ssl.conf tylko dyrektywy zawarte poniżej, pozostałe pozostawwiamy bez zmian.

3. Weryfikacja składni pliku konfiguracyjnego:

4. Utworzenie pliku index.html w DocumentRoot:

5. Zastosowanie kontektu SELinux dla katalogu /var/www/html:

6. Odblokowanie https na firewallu:

7. Restart Apacha:

8. Test dostępu z hosta lokalnego i zdalnego:

 

Hostowanie dynamicznych stron CGI.

Apache pozwala nam nie tylko na hostowanie stron statycznych ale także dynamicznych. Skrypt jest uruchamiany w tle a wynik jego wykonania wyświetlany jest na serwowanej stronie web. Taki mechanizm może być realizowany m.in. dzięki Common Gateway Interface (CGI). Skrypty CGI mogą być napisane w Perlu, Ruby, Pythonie, C, bashu lub w innym języku programowania.

 

Uruchomienie podstawowego skryptu CGI.

1. Utworzenie skryptu systime.sh w katalogu /var/www/cgi-bin:

2. Zezwolenie na wykonywanie skryptu:

3. Aktywacja zmiennej boolean SELinux httpd_enable_cgi:

4. Restart Apacha:

5. Test:

6. Sprawdzenie logu:

7. Sprawdzenie, jakie logi zostały zaktualizowane:

 

Uruchomienie podstawowego skryptu CGI w niedomyślnym katalogu.

1. Utworzenie katalogu /var/dynpage do składowania skryptów CGI:

2. Utworzenie skryptu sysmem.sh w katalogu /var/dynpage:

3. Dodanie praw wykonywania skryptu:

4. Aktywacja zmiennej boolean SELinux httpd_enable_cgi:

5. Dodanie kontekstu SELinux typ httpd_sys_script_exec_t dla katalogu /var/dynpage:

6. Modyfikacja dyrektywy ScriptAlias w pliku httpd.conf:

7. Restart Apacha:

8. Test:

9. Sprawdzenie logu:

 

Serwowanie dynamicznych stron PHP.

Skrypty PHP mogą być serwowane jako skrypty CGI ale lepiej jest zainstalować moduł mod_php, który włącza wewnętrzny bardziej wydajny interpreter PHP.  Instalacja mod_php tworzy nowy plik konfiguracyjny /etc/httpd/conf.d/php.conf, który zawiera kilka dyrektyw pozwalających na uruchamianie skryptów PHP.

 

Serwowanie dynamicznych stron Python.

Również skrypty Python mogą być serwowane jako skrypty CGI lub przez Web Server Gateway Interface (WSGI) zawarty w module mod_wsgi.

1. Instalacja modułu mod_wsgi.

2. Edycja /etc/hosts:

3. Utworzenie katalogu, w którym będzie hostowany skrypt WSGI:

4. Utworzenie przykładowego skryptu WSGI:

5. Konfiguracja hosta wirtualnego do serwowania skryptu WSGI:

6. Restart Apacha.

 

Leave a Reply

Your email address will not be published.