Budowa intranetu – Linux, Apache, VirtualHost Rajmund Radziewicz

Budowa intranetu – Linux, Apache, VirtualHost Rajmund Radziewicz

Budowa intranetu – Linux, Apache, VirtualHost
Rajmund Radziewicz
Celem tego artykułu będzie opis konfiguracji serwera WWW w sieci lokalnej, z
uwierzytelnianiem, udostępnianiem określonych zasobów i usług za pomocą szyfrowanego
połączenia. Główną ideą Intranetu - bo taką nazwę nosi wspomniane wydzielanie internetowych
usług tylko w obrębie prywatnej sieci - jest dostarczanie podobnej funkcjonalności jaką daje praca
w Internecie. W Intranecie możemy więc przeglądać strony WWW znajdujące się na lokalnym
serwerze, pobierać pliki z konta FTP, korzystać z baz danych, czy np. pracować z aplikacjami
działającymi po stronie serwera. Wszystko to funkcjonuje wyłącznie wewnątrz naszej sieci i
chociaż jest taka możliwość – najczęściej nie jest dostępne na zewnątrz.
Swojego rodzaju “opakowaniem” dla wspomnianych usług wewnątrz sieci jest właśnie serwer
WWW. W naszym przypadku będzie to wyjątkowo elastyczny i popularny w Internecie Apache i na
jego konfiguracji chciałbym się skoncentrować przede wszystkim. Zagadnienia których ta
konfiguracja będzie dotyczyła i którymi się zajmiemy to:
•
Tworzenie szyfrowanego połączenia pomiędzy komputerami a serwerem
•
Dodatkowe zabezpieczenia Apache
•
Udostępnianie określonych witryn WWW i części zasobów w Intranecie na hasło
•
Tworzenie wewnątrz sieci serwerów wirtualnych
•
Przekierowywanie lokalnie działającego serwera WWW na komputer z publicznym IP
Pomimo tego że cały czas mówimy o Intranecie, omawiane poniżej rozwiązania można oczywiście
z powodzeniem stosować przy konfiguracji publicznego serwera WWW. Całość opisywana jest na
przykładzie dystrybucji Debian i praktycznie od ręki działa w dystrybucjach debianopochodnych,
takich jak Knoppix, czy też Linux-EduCD. W artykule wykorzystywana jest specjalna odmiana
serwera Apache – Apache-SSL. Jest to serwer WWW, domyślnie obsługujący szyfrowane
połączenia i posługujący się bezpieczną odmianą protokołu HTTP o nazwie HTTPS.
Apache-SSL
Apache-SSL jest specjalną odmianą serwera Apache z wbudowaną obsługą SSL. Zamiast
rekompilować standardową wersję serwera WWW i dodawać do niej moduł mod_ssl, możemy ze
strony http://www.apache-ssl.org pobrać pakiet Apache-SSL, który zapewnia obsługę szyfrowanych
połączeń realizowanych za pomocą OpenSSL. Razem z aplikacją otrzymujemy również
odpowiednio przygotowany httpd.conf (główny plik konfiguracyjny serwera Apache), który w
przypadku stosowania tradycyjnego serwera należy po dodaniu mod_ssl odpowiednio
modyfikować. Apache-SSL w postaci źródeł i gotowych binarek RPM można pobrać ze strony
projektu. W repozytoriach Debiana dostępne są również gotowe pakiety DEB.
Konfigurację serwera, który docelowo będzie udostępniał zarówno serwisy WWW, jak i pliki w
naszym Intranecie, zaczynamy więc od instalacji wymaganych paczek DEB. Do tego celu
wystarczy polecenie:
apt-get update
apt-get install apache-ssl
System w tym momencie pobierze z sieci potrzebne pakiety wraz z zależnościami (m.in
odpowiednie biblioteki, takie jak libssl, czy pakiet openssl jeśli nie został wcześniej zainstalowany).
Następnie rozpocznie się proces instalowania pobranych składników i tworzenie certyfikatu SSL
dla serwera. To po zatwierdzeniu tego właśnie certyfikatu będziemy oglądać strony WWW w
naszym Intranecie, czy też logować się do serwisu udostępniającego pliki. Przy jego tworzeniu
będziemy musieli odpowiedzieć na kilka pytań. Będzie to swojego rodzaju wypełnianie
elektronicznego formularza, na podstawie którego certyfikat zostanie wygenerowany i umieszczony
pod nazwą “apache.pem” w katalogu /etc/apache-ssl/. Dane które musimy podać to: “Country
Name” - czyli skrót nazwy kraju. My wpisujemy oczywiście PL, “State or Province Name” – w
naszym przypadku może to być np. województwo, “Locality Name” - tu podajemy miejscowość,
“Organization Name” - nazwa organizacji. Możemy podać np. nazwę szkoły itp
Jeśli nie korzystamy z dystrybucji debianopochodnej lub po prostu nie skonfigurowaliśmy pakietu
skryptem poinstalacyjnym - możemy także w każdej chwili wygenerować taki
Po utworzeniu własnego, podpisanego przez nas samych certyfikatu, powinniśmy dokonać jeszcze
kilku najpotrzebniejszych zmian w pliku /etc/apache-ssl/httpd.conf, który jest głównym plikiem
konfiguracyjnym Apache-SSL.
Domyślnie serwer ustawia kodowanie znaków na stronach WWW na iso-8859-1. Nasze rodzime
kodowanie to iso-8859-2 i z pewnością takie będziemy deklarować w plikach html naszego serwisu
intranetowego. Należy więc wyłączyć opcję domyślnego kodowania przez serwer. W tym celu
odszukujemy w pliku httpd.conf dyrektywę
AddDefaultCharset on
i zamieniamy parametr “on” na “off”. Po tej operacji serwer będzie wyświetlał treści naszych stron
wg deklaracji “charset” jaką umieścimy pomiędzy znacznikami <META> w plikach html.
Zasadniczo jeszcze przed uruchomieniem Apache powinniśmy ustawić także zawartość dyrektywy
ServerName, czyli nazwę naszego serwera. Jest to wymagane wyłącznie kiedy konfigurujemy
publiczny serwer WWW. W przypadku omawianego Intranetu nie musimy tego robić i możemy
zachować domyślny wpis “localhost”, który się tam znajduje. Serwer działa przecież wyłącznie w
sieci lokalnej i na lokalnym adresie IP, a na potrzeby komputerów pracujących wewnątrz sieci i tak
zdefiniujemy za chwilę tzw. wirtualne serwery (z wirtualnymi nazwami). Pozwolą one na łączenie
się z określonymi zasobami lokalnego Apache, bez potrzeby posługiwania się numerem, czy
konfigurowaniem własnego serwera DNS. Oczywiście jeśli mamy zamiar konfigurować wirtualne
serwery i samego Apache, który będzie widoczny w Internecie, należy ustawić odpowiednią
wartość dla “ServerName” (wpisać tam zarejestrowaną nazwę domeny).
Wirtualne serwery w Intranecie
Skonfigurowanie w sieci kilku tzw. “wirtualnych serwerów”, w ramach jednej fizycznej maszyny –
ułatwi nam znacznie organizację zasobów naszego Intranetu i komunikację z tymi zasobami. Dzięki
nim będziemy mogli obsłużyć wiele serwisów WWW i dla każdego z nich ustawić inną nazwę,
pomimo tego że żadna z tych nazw nie jest zarejestrowana w DNS a sam serwer pracuje na
lokalnym adresie IP. Przykładowo adres http://www.szkolny-intranet.pl będzie oznaczał główną
stronę, której pliki umieścimy w /var/www naszego serwera (jest to główny katalog Apache w
Debianie i bazujących na nim dystrybucjach), a np. https://zasoby.szkolny-intranet.pl będzie
katalogiem public_html specjalnego użytkownika systemowego, w którym będą przechowywane
udostępniane wewnątrz Intranetu pliki. Dostęp do https://zasoby.szkolny-intranet.pl będzie możliwy
po uwierzytelnieniu się za pomocą loginu i hasła. Co więcej – ze stroną główną będziemy łączyli
się tradycyjnie, na porcie 80 i bez żadnego szyfrowanego połączenia - natomiast dostęp do witryny
z plikami będzie już realizowany poprzez https i szyfrowanie SSL.
Apache potrafi obsługiwać dwa rodzaje serwerów wirtualnych. Jeden – oparty na adresach IP
polega na tym, że w ramach jednej zarejestrowanej nazwy obsługiwane są zasoby umieszczone na
kilku oddzielnych komputerach. Np. łącząc się z adresem http://www.simp-st.pl łączymy się z
maszyną o określonym, publicznym adresie IP. Wpisując natomiast w przeglądarce adres
http://www.simp-st.pl/simp łączymy się w rzeczywistości z serwisem WWW, znajdującym się na
zupełnie innym komputerze, pracującym wewnątrz sieci lokalnej. Drugi rodzaj – oparty na nazwach
(i tym będziemy się posługiwać) polega na tym, że w ramach jednego adresu IP możemy stosować
wiele nazw. Bez względu więc na to, czy wpisujemy http://www.szkolny-intranet.pl, czy
https://zasoby.szkolny-intranet.pl łączymy się z tym samym serwerem, a wyświetlane nam serwisy
znajdują się po prostu w różnych katalogach. Domyślna konfiguracja Apache nie zawiera żadnych
hostów wirtualnych.
Wszystkie adresy IP w ramach których działają wirtualne serwery muszą być zdefiniowane w
httpd.conf za pomocą dyrektywy “NameVirtualHost”. Sekcje poszczególnych wirtualnych
serwisów z kolei umieszczany w tym samym pliku pomiędzy tzw. kontenerami (znacznikami)
<VirtualHost>, gdzie dopisujemy wszelkie dodatkowe opcje mające wpływ na ich działanie.
Reasumując, do naszego /etc/apache-ssl/httpd.conf, w miejscu gdzie znajdują się zakomentowane,
przykładowe dyrektywy NameVirtualHost, dopisujemy następujący fragment:
NameVirtualHost *
<VirtualHost *>
DocumentRoot /var/www
ServerName localhost
SSLEnable
SSLCertificateFile /etc/apache-ssl/apache.pem
</VirtualHost>
<VirtualHost *:80>
SSLDisable
Port 80
DocumentRoot /var/www
ServerName www.szkolny-intranet.pl
</VirtualHost>
<VirtualHost *>
DocumentRoot /home/user/public_html
ServerName zasoby.szkolny-intranet.pl
SSLEnable
SSLCertificateFile /etc/apache-ssl/apache.pem
</VirtualHost>
W tej chwili, w ramach lokalnie działającego serwera WWW, zainstalowanego na komputerze o
adresie IP np. 192.168.0.10 (może być dowolnie inny z puli prywatnych adresów, które stosujemy
w sieci) mamy zdefiniowanych kilka serwerów wirtualnych. Gwiazdka po dyrektywie
“NameVirtualHost” oznacza że zdefiniowane wirtualki będą działały na wszystkich adresach
maszyny na której są ustawione (w tym także na localhoście). Dyrektywy “DocumentRoot”
oznaczają katalog główny ze stronami WWW i innymi zasobami, które otrzyma użytkownik po
połączeniu się z takim wirtualnym adresem. “ServerName” to właśnie wspomniany adres, który
będziemy wpisywać w przeglądarkach. “SSLEnable” oznacza że komunikacja z danym serwerem
wirtualnym będzie szyfrowana za pomocą kluczy SSL. Ostatnia dyrektywa w sekcjach z
włączonym SSL’em to “SSLCertificateFile”, w której podajemy ścieżkę do certyfikatu serwera.
Przy standardowej instalacji pakietu apache-ssl, certyfikat który utworzyliśmy zapisywany jest
właśnie w podanym pliku.
Według powyższej konfiguracji mamy więc zdefiniowany wirtualny serwer
http://www.szkolny-intranet.pl, który nie wykorzystuje protokołu SSL. Mówią o tym dyrektywy
“SSLDisable” i “Port 80”, określające sposób jego pracy. Działa on jak standardowy serwis WWW
przy typowej konfiguracji Apache. Należy przy tej okazji pamiętać, że serwer wykorzystujący SSL
(taki jak nasz Apache-SSL) nasłuchuje domyślnie na porcie 443. Jeśli chcemy więc wykorzystywać
port 80 i zwykłe połączenia realizowane po HTTP, musimy do pliku /etc/apache-ssl/httpd.conf
dodać dyrektywę:
Listen 80
W pliku tym znajduje się już podobny wpis, tyle że dotyczący oczywiście portu 443 (Listen 443).
Najlepiej więc odszukać ten wpis i pod nim dopisać dodatkową dyrektywę, nakazującą Apache-SSL
nasłuchiwać także na porcie 80.
Ponadto mamy także http://zasoby.szkolny-intranet.pl, do którego dostęp realizowany jest za
pośrednictwem SSL. Dyrektywa “DocumentRoot” wskazuje na katalog public_html znajdujący się
w katalogu domowym użytkownika systemowego. Może to być w zasadzie dowolny użytkownik
(np. specjalnie utworzony do tego celu), gdyż domyślna konfiguracja Apache, dzięki specjalnemu
modułowi “mod_userdir” pozwala na umieszczanie stron i zasobów poszczególnym użytkownikom
właśnie w public_html. Jeśli więc osoba posiadająca konto na przykładowym serwerze
www.domena.pl chce mieć własną stronę WWW, tworzy w swoim katalogu domowym podkatalog
public_html i umieszcza w nim pliki własnego serwisu internetowego. Taki serwis widoczny jest z
zewnątrz pod adresem: http://www.domena.pl/~nazwa_użytkownika.
Gdybyśmy nie stosowali wirtualnych hostów, moglibyśmy więc odwołać się do naszego zasobu
wpisując w dowolnej przegladarce: http://192.168.0.10/~user.
No dobrze … w zasadzie musimy wykonać jeszcze tylko jedną czynność, żeby wirtualne adresy
zadziałały w sieci. Jako że nie chcemy stawiać serwera DNS i niepotrzebnie komplikować sobie
życia – wystarczy jak do pliku /etc/hosts każdego komputera w naszym szkolnym Intranecie
dopiszemy dwie linijki (np. zaraz pod wpisem “localhost”):
192.168.0.10 www.szkolny-intranet.pl
192.168.0.10 zasoby.szkolny-intranet.pl
Podany adres IP musi być oczywiście adresem komputera, na którym zainstalowaliśmy Apache.
Dodatkowo jeśli chcemy łączyć się z wirtualnymi adresami pracując przy samym serwerze – w jego
/etc/hosts również musi się znaleźć identyczny wpis.
Po tych wszystkich operacjach możemy spróbować uruchomić naszą wstępnie skonfigurowaną
usługę WWW. Jeśli nie popełniliśmy żadnego błędu składniowego lub np. nie zdublowaliśmy
nieumyślnie jakiegoś wpisu (np. Listen 443), po wydaniu komendy:
apache-sslctl start
lub:
cd /etc/init.d/ ; ./apache-ssl start
powinniśmy otrzymać komunikat “Starting web server: apache-ssl”.
Przy pierwszym połączeniu z wirtualnym serwerem za pośrednictwem SSL (np. z adresem
https://zasoby.szkolny-intranet.pl przeglądarka wyświetli nam ostrzeżenie, że certyfikat serwera nie
jest wystawiony przez żadną znaną instytucję certyfikującą CA. Jako że na potrzeby naszej sieci
sami sobie wystawiliśmy ten certyfikat – mamy oczywiście pewność że jest wiarygodny. Możemy
więc zaakceptować w przeglądarce połączenie wybierając opcję “Na zawsze” (konqueror) lub
“Zaakceptuj ten certyfikat na stałe” (Mozilla). Co prawda istnieje możliwość generowania
specjalnych certyfikatów i importowania ich do przeglądarek na poszczególnych komputerach,
żeby nie wyświetlały takiego ostrzeżenia – ale w przypadku lokalnej sieci było by to zbędną
komplikacją. Po wybraniu wspomnianej opcji akceptowania połączenia na stałe – komunikat drugi
raz już się nie pojawi.
Należy pamiętać również żeby po każdej zmianie w httpd.conf restartować serwer WWW (np.
komendą “apache-sslctl restart”).
Apache jako FTP. Dostęp autoryzowany i “udawane” konto anonymous
Po zainstalowaniu Apache-SSL i wygenerowaniu certyfikatu apache.pem - wszelka wymiana
danych pomiędzy komputerami a wirtualnymi serwerami, zawierającymi w swoich kontenerach
<VirtualHost> wpisy “SSLEnable” i “SSLCertificateFile” - będzie autoryzowana i szyfrowana.
Teraz pora na nieco bardziej selektywne zabezpieczanie poszczególnych zasobów serwera WWW.
Jedną ze wspomnianych wcześniej czynności będzie tworzenie witryny dostępnej w Intranecie po
uwierzytelnieniu za pomocą loginu i hasła. Będzie to w zasadzie coś w stylu FTP, gdzie po części
dostęp będzie anonimowy (np. dla określonej grupy użytkowników), a po części autoryzowany. Po
wejściu na konto “anonymous” użytkownik będzie miał dostęp przykładowo tylko do plików *.pdf
i *.txt – natomiast po zalogowaniu na określone konto, będzie mógł pobierać także pliki *.mp3. Na
koncie anonimowym będzie co prawda widział mptrójki, ale nie będzie mógł ich ani ściągnąć, ani
odworzyć.
Autentykacja w Apache możliwa jest dzięki specjalnym modułom “mod_access” i “mod_auth”.
Podobnie jak w przypadku “mod_userdir” nie musimy niczego rekompilować, czy
przekonfigurowywać - gdyż moduły te standardowo dołączane są do każdej wersji serwera.
Co prawda do obsługi kont typu anonymous można doinstalować specjalny moduł
“mod_authn_anon”, jednak praktycznie taką samą funkcjonalność uzyskamy za pomocą
standardowych rozszerzeń Apache.
Do zdefiniowania autoryzacji, będziemy potrzebować specjalnego pliku .htaccess. Plik utworzymy
w chronionym katalogu i umieścimy w nim dyrektywy, określające sposób dostępu do
umieszczonych w nim plików. Serwer WWW wczyta te dyrektywy tak, jakby były częścią pliku
httpd.conf.
Wg zastosowanej wcześniej konfiguracji, plik .htaccess tworzymy w katalogu public_html
użytkownika (żeby zachować konsekwencję z poprzednimi przykładami, może to być użytkownik o
nazwie “user”). W pliku tym umieszczamy następujące dyrektywy:
AuthType Basic
AuthName “Szkolny Intranet - AUTORYZACJA”
AuthUserFile /home/user/.htpasswd
Require valid-user
<Files *.mp3>
Require user rajmund
</Files>
Dyrektywa “AuthUserFile” oznacza plik z zaszyfrowanymi hasłami dostępu. Plik ten utworzymy za
chwilę. “AuthName” to nazwa chronionego serwisu, która wyświetli się użytkownikowi w
momencie logowania. “AuthType” natomiast definiuje sposób uwierzytelniania. “Basic” jest
najprostszym ze sposobów i oznacza, że hasło zakodowane będzie za pomocą odwracalnego
algorytmu base-64 i w momencie logowania przekazywane w sposób jawny w nagłówku żądania.
Teoretycznie ktoś mógłby podsłuchać takie hasło za pomocą sniffera i rozszyfrować. W momencie
kiedy korzystamy jednak z bezpiecznego połączenia SSL – wspomniane nagłówki i cała transmisja
w całości jest szyfrowana kluczem prywatnym serwera WWW. Istnieje co prawda silniejsze
uwierzytelnianie “Digest”, ale jego stosowanie ma raczej sens kiedy nie używamy protokołu SSL.
Ponadto nie jest ono obsługiwane przez wszystkie przeglądarki.
Dodatkowe wpisy zawarte w kontenerze <Files>, definiują jakiego rodzaju pliki będą dostępne
wyłącznie dla zdefiniowanej grupy użytkowników. W powyższym przykładzie do plików *.mp3
dostęp będzie miał tylko użytkownik rajmund. Nie musi on rzecz jasna być użytkownikiem
systemowym.
Po utworzeniu w katalogu /home/user/public_html pliku .htaccess, możemy przejść do generowania
haseł. Przechodzimy piętro wyżej (do katalogu /home/user/) i tworzymy w tym miejscu plik
.htpasswd zawierający wymagane do autoryzacji dane. Zaczniemy więc od ustawienia hasła dla
konta “rajmund”. Wykonujemy polecenie:
htpasswd -c .htpasswd rajmund
W tym momencie program poprosi nas o podanie hasła dla tworzonego konta. Opcja “-c” oznacza
że plik .htaccess zostanie utworzony (bez tej opcji musielibyśmy utworzyć go ręcznie, np. za
pomocą komendy “touch”) i wpisze do niego parę:
użytkownik: zaszyfrowane hasło
Przy dodawaniu kolejnych kont nie dodajemy już oczywiście “-c”, gdyż za każdym razem system
będzie tworzył nowy plik .htpasswd, napisując tym samym poprzedni.
Użytkownik rajmund jest już gotowy do logowania się na swoje konto. Jak pamiętamy z zawartości
pliku .htaccess, jako jedyny ma dostęp do plików *.mp3. Pora teraz na konto anonymous. Założenie
jest takie, żeby każdy kto wpisze jako login “anonymous” lub “guest” dostał się do
https://zasoby.szkolny-intranet.pl bez podawania hasła. Pole hasła będzie w zasadzie pomijane,
więc nie ma znaczenia czy wpisze tam cokolwiek, czy zostawi to pole puste. Weryfikowany będzie
tylko login.
Po wejściu na anonimowe konto, Apache wyświetli użytkownikowi wszystkie pliki, ale nie będzie
on miał praw dostępu do plików z rozszerzeniem *.mp3.
Żeby uzyskać taki efekt, wystarczy wyedytować plik .htpasswd i dopisać do niego dwie linijki:
anonymous:
guest:
Wpis ten oznacza dodanie dwóch kolejnych kont: “anonymous” i “guest”, ale tym razem bez
generowania hasła. Jeśli więc dodałem wcześniej (poza użytkownikiem “rajmund”) np. hasło dla
użytkownika “janek” - cały mój .htpasswd powinien wyglądać mniej więcej tak:
janek:RlCk2rUo3NoYM
rajmund:xTakNT4IVozog
anonymous:
guest:
W tej chwili, jeśli użytkownik “anonymous” lub “guest” będzie chciał pobrać plik *mp3, otrzyma
komunikat o błędzie autoryzacji.
Żeby dyrektywy w .htaccess były wzięte pod uwagę przez Apache, należy oczywiście zrestartować
serwer:
cd /etc/init.d ; ./apache-ssl restart
W sytuacji opisywanej powyżej stosowaliśmy plik .htaccess. Oczywiście nic nie stoi na
przeszkodzie, żeby zawartość tego pliku znalazła się bezpośrednio w /etc/apache-ssl/httpd.conf. W
pliku tym szczegółowe prawa dostępu do określonych katalogów serwera WWW definiuje się w
kontenerach <Directory>. Przykładowo jest tam domyślna sekcja, opisująca dostęp do /var/www.
Wygląda ona mniej więcej tak:
<Directory /var/www/>
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Dyrektywa “Options Indexes Includes FollowSymLinks MultiViews” oznacza, że jeśli ktoś wpiszę
adres URL tego katalogu w przeglądarce, to Apache utworzy dla niego listę (indeks) zawartości.
Gdybyśmy przykładowo zamienili ją na:
Options -Indexes
to po wpisaniu adresu URL katalogu, serwer zwróci nam komunikat o braku uprawnień i nie
wylistuje żadnych plików. Moglibyśmy więc utworzyć nasz dodatkowy zasób, np. nie w
/home/user/public_html, a powiedzmy w /var/www/test. Do httpd.conf dopisujemy zawartość
naszego .htaccess, ale tym razem umieszczamy ją w kontenerze <Directory>:
<Directory /var/www/test>
Options -Indexes
AuthType Basic
AuthName “Szkolny Intranet - AUTORYZACJA”
AuthUserFile /home/user/.htpasswd
Require valid-user
</Directory>
Plik z hasłami może oczywiście pozostać tam gdzie był. Po dodaniu (jak widać powyżej) do całej
sekcji wpisu “Options -Indexes”, nawet jeśli uwierzytelnimy się na podstawie utworzonego konta,
serwer WWW nie wyświetli nam zawartości /var/www/test.
Wracając do domyślnego <Directory /var/www>, dyrektywa “ AllowOverride None” nakazuje
serwerowi żeby dla danego katalogu nie szukał nigdzie pliku .htaccess. Gdyby zamiast “None” było
tutaj “All”, plik .htaccess byłby przez serwer odczytany, a wpisy w nim miały by wyższy priorytet
niż te w pliku httpd.conf.
Skoro jesteśmy już przy określaniu kto ma mieć dostęp do jakich plików na serwerze, warto
również zapoznać się z <FilesMatch>. Wyobraźmy sobie sytuacje, w której chcemy ustawić dostęp
do plików *.zip, *.sxw i *.pdf tylko z określonego komputera w sieci. Ewentualnie mamy np.
skrypt, który można wywołać wpisując jego URL w przeglądarce. Z wiadomych przyczyn nie
chcemy żeby ktokolwiek (chyba że pracuje zalogowany na serwerze) mógł ten skrypt wykonać. We
wszystkich tych przypadkach dyrektywa “FilesMatch” jest niezastąpiona. Żeby wprowadzić
wspomniane restrykcje, wystarczy umieścić np. w głównym kontenerze <Directory /var/www>
wpis:
<FilesMatch “\.(zip)|\.(sxw)|\.(pdf)”>
Order Deny,Allow
Deny from all
Allow from 192.168.0.25
</FilesMatch>
Po zrestartowaniu serwera WWW, każdy kto będzie chciał pobrać lub otworzyć plik o podanych
rozszerzeniach w obrębie /var/www, a nie łączy się z adresu 192.168.0.25 - otrzyma kod błędu 403
(brak uprawnień).
Zarówno przy definiowaniu <FilesMatch>, jak i dodatkowych opcji w <Directory>, posługiwaliśy
się dyrektywami “Deny” i “Allow”. Określają one dostęp do zasobów Apache weryfikując go na
podstawie adresów IP, adresów sieci, bądź nazw domen. “Order” oznacza natomiast kolejność
wykonywania tych dyrektyw. Reasumując, przykładowy wpis:
<Directory /var/www/test>
Order Allow,Deny
Allow from przykładowa.domena.pl
</Directory>
będzie oznaczał, że do adresu http://nasz_serwer/test/ będą mieli dostęp wyłącznie użytkownicy
domeny http://przykładowa.domena.pl. Gdybyśmy chcieli teraz zmodyfikować dyrektywę tak, żeby
do katalogu /var/www/test/ dostęp był wyłącznie z adresu localhost, wystarczy jako wartość “Allow
from” wpisać “127.0.0.0/255.0.0.0”. Kolejność wykonywania “Allow” i “Deny” będzie zależała
właściwie od tego, ile maszyn chcemy blokować, a ile dopuszczać.
Przekierowanie serwera WWW z maszyny lokalnej na publiczną
Pakiet OpenSSH zasadniczo służy do realizacji szyfrowanego połączenia ze zdalną
maszyną, na której uruchomiony jest serwer SSH. Oczywiście myli się ten, kto przypuszcza, że
służy wyłącznie do tego. Za jego pomocą można np. przekierowywać porty TCP. Jeśli z jakiegoś
powodu chcielibyśmy udostępnić omawianego w artykule Apache komuś spoza sieci, najwygodniej
będzie przekierować jego port 443 lub 80 na jakiś zupełnie inny (wolny i otwarty) port komputera z
publicznym adresem IP. Innymi słowy nasz serwer WWW działa na komputerze z adresem
192.168.0.10. Komputer ten widoczny jest w sieci lokalnej, natomiast nie jest widoczny na
zewnątrz. Ktoś z zewnątrz chciałby obejrzeć naszą nowiutką aplikację napisaną w PHP i
uruchomioną w Intranecie. Wystarczy jak przekierujemy port 80 wewnętrznego serwera np. na port
8001 naszego rutera, który posiada publiczny adres i za pomocą którego realizujemy maskaradę. Do
tego celu posłużymy się tzw. tunelem SSH.
W tym celu na komputerze z lokalnym adresem IP musimy uruchomić serwer SSH:
cd /etc/init.d ; ./ssh start
Następnie na ruterze z publicznym IP, jako użytkownik root wpisujemy:
ssh -f -g -N -L8001:localhost:80 192.168.0.10
Polecenie to spowoduje, że wszystkie połączenia z portu 8001 rutera będą przekazywane
(tunelowane) na port 80 wewnętrznego serwera WWW. Jeśli ktoś wpisze więc w swojej
przeglądarce:
http://adres_naszego_rutera:8001
zobaczy wewnętrzny serwer pracujący faktycznie na hoście 192.168.0.10.
Parametr “-L” otwiera tunel na komputerze lokalnym, i wymaga zdefiniowania portu i hosta
komputera zdalnego. Opcja “-g” pozwala z kolei łączyć się zdalnym maszynom na lokalne,
przekazywane wewnątrz sieci porty. Dodane “-f” tworzy nam egzemplarz programu działający w
tle, a przy pomocy “-N” natomiast, konfigurujemy połączenie w taki sposób, żeby na końcu tunelu
nastąpiło przekazywanie (a nie standardowe wywoływanie jakiegoś polecenia).
Generowanie certyfikatów SSL
Po zainstalowaniu Apache-SSL otrzymujemy certyfikat na okres jednego miesiąca. My jednak
chcemy aby nasz serwer pracujący na https działał znacznie dłużej. Jako że w Linux-EduCD
możemy skorzystać z OpenSSL - w katalogu /usr/lib/ssl mamy narzędzia przy pomocy, których
przygotujemy sobie klucze naszego certyfikatu niezbędne do prawidłowej pracy Apache’a .Klucze z
certyfikatami będą aktywowane na okres jednego roku. Gdyby ten okres czasu był dla nas za krótki
lub za długi możemy w pliku CA.sh odszukać wartość zmiennej $DAYS, która defaultowo
ustawiona jest na 365 dni zmieniając ja na wartość nam odpowiadającą. Procedura wystawiania
certyfikatów będzie następująca:
Najpierw wygeneruje klucze cacert.pem i cakey.pem “naszej” organiazacji wystawiającej
certyfikaty Następnie wygenerujemy klucze dla witryny WWW. Będą to newreq.pem i
newkey.pem. Na zakoćzenie z klucza newkey.pem usuniemy hasło a podpiszemy się w
newcert.pem. Zaszyfrowane treśći z obu kluczy wkleimy w miejsce istniejących do pliku
apache.pem.
Zaczynamy:
1. Z poziomu roota przechodzimy do katalogu /usr/lib/ssl/misc i wpisujemy:
./CA.sh -newca
Odpowiadamy na następujące komunikaty:
CA certificate filename (or enter to create) - naciskamy klawisz enter bo chcemy utworzyć klucze
Enter PEM pass phrase: twojehaslo - podajemy hasło od 4 do 8192 znaków
Verifing pass phrase: twojehaslo
Country Name: PL
State or Province Name: województwo - podajemy na przykład nazwę województwa
Locality Name: miejscowość - nazwe miejscowości
Organization name: nazwa firmy - podajemy na przykład nazwę organizacji zarządzającej szkołą
Organization Unit Name: - nazwaoddziału - podajemy nazwę naszej placówki szkolnej
Common Name: -Twoje imie - np imię/nazwisko osoby wystawiającej sobie certyfikat
Email Name: Twó[email protected] - podaj swój adres e-mail
Na dwa następne polecenia odpowiadamy klawiszem enter. Dotyczy to:
Please enter the following ‘extra’ attributes
A challenge password: klawisz Enter
An optional company Name: Enter
Teraz odpowiemy na pytanie dotyczące klucza cakey.pem.
Enter pass phrase for cakey.pem: hasło jak wyżej
Na ekranie pojawi sie treść wygenerowanych kluczy.
2. generujemy klucze newreq.pem i newkey.pem dla naszej domeny
./CA.sh -newreq
Enter pass phrase: podajemy hasło od 4 do 8192 znaków
Verifing pass phrase: twojehaslo
Country Name: PL
State or Province Name: województwo - podajemy na przykład nazwę województwa
Locality Name: miejscowość - nazwe miejscowości
Organization name: nazwafirmy - podajemy na przykład nazwę organizacji zarządzającej szkołą
Organization Unit Name: nazwaoddziału - podajemy nazwę naszej placówki szkolnej
Common Name: localhost - nie podawaj swojego imienia !!!. Wpisz po prostu localhost
Email Name: Twó[email protected] - podaj adres e-maila
Jak w poprzednim punkcie, na dwa polecenia następne odpowiadamy klawiszem enter. Dotyczy to:
Please enter the following ‘extra’ attributes
A challenge password: klawisz Enter
An optional company Name: Enter
Teraz mamy parę kluczy newreq.pem i newkey.pem
3. Usuwamy hasło z newkey.pem
openssl rsa -in newkey.pem -out newkey.pem
Na pytanie “Enter pass phrase”: podajemy to hasło które podaliśmy wcześniej
Za chwile otrzymamy komunikat o wygenerowaniu klucza bez hasła
4. Podpisujemy newcert.pem
./CA.sh -sign
Odpowiadamy na polecenia
Enter pass phrase: hasło podane wcześniej dla cakey.pem
Sign the certificate [y/n] - odpowiadamy “y”
1 out of 1 certificata request certificied commit [y/n] - odpowiadamy “y”
5. Przenosimy zawrtość zaszyfrowanych kluczy newkey.pem i necert.pem do apache.pem
6. Na koniec reastartujemy apache-ssl
/etc/init.d ./apache-ssl restart (start)
Podczas otwierania strony (HTTPS) można przeczytać przez kogo i na jaki okres zostały
wystawione certyfikaty