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ój@adres.email - 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ój@adres.email - 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