7. Zabezpieczanie serwera i połączeń

Każda nowa usługa na serwerze na jaka się decydujemy, niesie za sobą nowe ryzyko, dlatego też bardzo dużą uwagę należy zwrócić na to w jakim stopniu jesteśmy ostrożni przy konfigurowaniu, a raczej nie dopuszczeniu aby ktoś spowodował szkody na naszym serwerze.

Na początek należy przyjąć pewna twarda regułę :

Blokujemy wszystko, następnie puszczamy tylko to co jest / będzie nam potrzebne. Jeżeli chodzi o serwer httpd Apache, ważnym jest śledzenie zmian i poprawek, dlatego tez zapraszam na stronę http://www.apache.org/.

7.1. Opis dyrektyw zabezpieczających serwer httpd

Przedstawione dyrektywy oczywiście wpisujemy w plik httpd.conf.

LimitRequestBody
Dyrektywa ta ogranicza rozmiar treści żądania HTTP, Jeżeli żądanie przekroczy limit zostanie odrzucone z komunikatem o błędzie. Dyrektywa ta zmniejsza ryzyko blokady usługi. W dyrektywie tej 0 oznacza brak limitu, - ustawienie domyślne. Zakres to 0-2147483647.

LimitRequestFields
Ograniczenie dopuszczenia liczby pól nagłówka w żądaniu. Jeżeli przekroczony zostanie limit, żądanie zostanie odrzucone z błędem(0 oznacza brak limitu) zakres to 0-32767.

LimitRequestFieldSize
Ograniczenie rozmiaru każdego nagłówka żądania - zmniejsza to ryzyko przepełnienia bufora (buffer-overflow).
Zakres to 0-8190 (0 oznacza brak limitu).

LimitRequestLine
Ograniczenie długości każdego wiersza. Zakres to 0-8190 (0 oznacza brak limitu).

RLimitCPU
Dyrektywa ta ogranicza liczbę sekund, przez którą proces może zajmować procesor, dyrektywa ta posiada dwa parametry pierwszy limit miękki a drugi maksymalny, dyrektywa ta może też występować w <VirtualHost>

RlimitNProc
Ograniczenie liczby procesów, które mogą zostać odgałęzione przez każdy proces, przyjmuje jeden lub dwa parametry liczbowe, tak jak dyrektywa wyżej.

KeepAlive
Dyrektywa ta włącza trwale połączenie, zwiększa to wydajność serwera, gdyż klient może zgłosić kilka żądań, nie nawiązując za każdym razem oddzielnego połączenia, dyrektywa ta może przyjąć parametr on lub off.

KeepAliveTimeout
Wyznacza maksymalny czas oczekiwania na następne żądanie przez to samo połączenie.

MaxKeepAliveRequests
Ograniczenie liczby żądań zgłaszane przez to samo połączenie, domyślne ustawienie to 100, zalecane jest obniżenie tej wartości.

7.2. Wprowadzenie do SSL

SSL odpowiada za szyfrowanie danych, miedzy warstwą transportu a warstwą aplikacji TCP, szyfruje wszystkie dane wychodzące z aplikacji i deszyfruje dane wchodzące do aplikacji. W przypadku serwera httpd SSL zabezpiecza dokumenty czyli poufne dane. Standardowo SSL oczekuje na zapytania na porcie 443, przeglądarka zgłasza takie zapytanie poprzez protokół https://. SSL daje poczucie bezpieczeństwa, które jest tak ważne w dzisiejszej dobie internetu.

7.3. Kompilacja apache do współpracy z SSL

Na początek musimy zaopatrzyć się w źródła modułu ssl, które znajdziemy na stronie projektu http://www.modssl.org/.

A dokładniej ściągamy wersje pod apache w wersji 1.3.29 http://www.modssl.org/source/mod_ssl-2.8.16-1.3.29.tar.gz.

Rozpakowywujemy źródła:

Przechodzimy do katalogu

Konfigurujemy z podaniem ścieżki do naszych źródeł serwera apache :

Przechodzimy do katalogu apache :

I zaczynamy kompilacje tak jak w zrobiliśmy to wcześniej :

Do tego dodajemy jeszcze jedna opcje a dokładnie :

# make

I tworzymy certyfikat

Po odpowiedzeniu na kilka zadanych pytań, zostanie utworzony certyfikat. W tym momencie musimy zdecydować czy usuwamy hasło z klucza serwera, w przeciwnym wypadku przy każdym restarcie serwera apache będziemy pytani o hasło, co w niektórych sytuacjach może przysporzyć problemu.

Jeżeli zdecydujemy się na takowy krok piszemy :

Podajemy hasło jakie wcześniej ustaliliśmy.

Jeżeli wszystko zrobiliśmy bezbłędnie oznacza to iż jesteśmy gotowi do uruchomienia serwera z modułem ssl.

Jeszcze jedna ważna sprawa, przy tej instalacji został wygenerowany nowy plik konfiguracyjny:

Proszę o zapoznanie się ze zmianami jakie nastąpiły - są to dyrektywy odpowiedzialne za poprawne funkcjonowanie SSL.

Od tego momentu zmienia się sposób uruchamiania serwera a dokładnie :

Czyli opcja startssl.

Oczywiście użyliśmy metody, własnego podpisania certyfikatu. Jeżeli nie zdecydujemy się aby podpisała nam certyfikat odpowiednia do tego celu instytucja, przy uruchomieniu protokołu https:// przeglądarka wyświetli nam komunikat iż certyfikat został podpisany przez firmę która nie została sklasyfikowana jako godna zaufania.

7.4. CGI konfiguracja i bezpieczeństwo

CGI, ma ogromne zastosowanie, i udostępnia pełna moc systemu operacyjnego, jest to oczywiście zaleta ale i wada.

Ważne jest określenie komu pozwalasz na umieszczanie skryptów CGI a komu nie. Aby poprawnie mogły funkcjonować skrypty CGI na koncie użytkownika musimy zdefiniować pewne dyrektywy. Na początek dodajemy :

Następnie aby zezwolić użytkownikowi np. "jasio" który mieści się w katalogu /home/users/jasio piszemy :

Oczywiście w przypadku takim musi być stworzony katalog cgi-bin, zakładając ze to właśnie w tym katalogu użytkownik będzie trzymał skrypty CGI.

Istnieje możliwość zrobienia aliasu do katalogu za pomocą dyrektywy "ScriptAlias".

Dobrym sposobem na zabezpieczenie się przed błędami programistycznymi naszych użytkowników jest korzystanie z nakładek CGI.

Czyli przed instalacją źródeł należy aktywować opcje "suexec", dokładne opcje opisane są po wydaniu komendy ./configure -help w katalogu apache.

Aby uaktywnić przed kompilacją apache czyli w ./configure dodajemy :

7.5. PHP, kilka rad na zabezpieczenie skryptów

Jeżeli prowadzimy usługi typu hosting, bardzo ważnym elementem jest zabronienie, uruchamiania poleceń systemowych za pomocą funkcji w php.

Czyli włączmy opcje Safe_Mode

Wyedytujmy plik /usr/local/lib/php.ini

Odszukujemy dyrektywę Safe_Mode i uaktywniamy ją zmieniając z off na on :

Oczywiście można tak, aby tylko użytkownicy mieli włączona taką opcje a np. my opcje tą wyłączoną, w takim przypadku edytujemy plik httpd.conf i piszemy : <Directory "/home/admin/public_html"> php_admin_value safe_mode 0 </Directory>

Pamiętajmy o przeładowaniu serwera aby opcje mogły wejść w życie:

Opisze teraz ciekawy sposób utajnienia hasła do bazy danych np. MySQL

Edytujemy plik httpd.conf i wstawiamy następująca dyrektywę:

Nic nie stoi na przeszkodzie abyśmy wpisali jakiś string zakodowany, w takim przypadku nasz skrypt po otrzymaniu zakodowanego hasła musiał by najpierw go rozkodować. Jednak na potrzeby artykułu opisze sposób bez kodowania - tylko ukrycia hasła.

Mamy hasło w httpd.conf, w takim przypadku musimy pamiętać o tym abyśmy tylko my mieli prawo do odczytania pliku httpd.conf czyli np.:

Następnie przechodzimy do naszego skryptu łączącego się a bazą czyli tak jak zdefiniowaliśmy w dyrektywie powyżej: edytujemy plik np. /home/users/jasio/public_html/connect_sql.php

Następna sprawa to standardowo pliki sesji trzymane są w /tmp/ Na ogół do tego katalogu mają dostęp również zwykli użytkownicy, co stwarza zagrożenie przejęcia sesji.

Istnieje możliwość umieszczenia plików sesji w innym katalogu niż standardowo "/tmp/". Służy do tego funkcja PHP o nazwie : session_save_path();

Czyli rozkładając na kod PHP:

Od razu nasuwa się myśl aby zakodować również podobnym sposobem jak metodą z hasłem ścieżkę gdzie trzymamy katalog sesji, więc w przypadku takowym zasada jest ta sama.