Bezpieczny Apache2 plus mod_security2

Bez kategorii Zostaw komentarz

W tym artykule zajmę się konfiguracją serwera apache2 w środowisku Debian. Krok po kroju zainstalujemy apache2 wraz z php5, mysql5 oraz kilkoma dodatkami podnoszącymi bezpieczeństwo naszej instalacji. Zainstalowanie tego oprogramowania ciężko nazwać czymś trudnym, jednakże skonfigurować wszystko w sposób skutecznie utrudniający hackerom życie jest już pewnym wyzwaniem.

Artykuł został tak napisany by czytając go i wykonując zapisane w nim polecenia w pełni skonfigurować serwer apache2 wraz z obsługą PHP oraz MYSQL. Oczywiście główny nacisk konfiguracji skierowany będzie na bezpieczeństwo serwera. Pisząc artykuł, wszystkie polecenia wykonywałem na świeżo zainstalowanym Debian 5.0 z niestandardowo skonfigurowanym plikiem /etc/apt/sources.list , oto jego zawartość:

deb http://ftp.fr.debian.org/debian/ stable main

deb-src http://ftp.fr.debian.org/debian/ stable main

deb http://security.debian.org/ stable/updates main

deb http://ftp2.de.debian.org/debian-volatile stable/volatile main

deb http://etc.inittab.org/~agi/debian/libapache-mod-security2/etch ./

deb http://ftp2.de.debian.org/debian-volatile stable/volatile main

Po zmianie zawartości source.list należy wykonać polecenia:

apt-get update

apt-get upgrade

apt-get dist-upgrade

Instalacja oprogramowania podstawowego.

W konsoli wydajemy polecenie:

apt-get install apache2 php5 mysql-server-5.0 php5-mysql mysql-client

Oprogramowanie zostanie automatycznie ściągnięte z repozytorium i zainstalowane. Ten etap jest absolutnie automatyczny i „dzieje się sam” (wyjątkiem jest prośba o podanie hasła dla serwera mysql), po instalacji tych pakietów nasz serwer www w zasadzie już działa. Można to sprawdzić wpisując do przeglądarki internetowej adres naszego serwera, na potrzeby tego artykułu uruchomiłem serwer pod adresem IP 10.10.10.32. Tak więc po wpisaniu adresu IP do przeglądarki zobaczymy wspaniały komunikat:
It works!

W tym momencie serwer www apache2 wraz obsługą PHP oraz MYSQ mamy „gotowy”, obsługę php sprawdzimy tworząc plik informacyjny:

w konsoli wpisujemy:

echo ” ” > /var/www/info.php

Wpisując w przeglądarce internetowej adres http://10.10.10.32/info.php zobaczy szczegółowe informacje na temat zainstalowanego PHP oraz modułów dodatkowych. Jak da się zauważyć w domyślnej konfiguracji instalacja jest zaopatrzona w Suhosin Patch, patch ma

za zadanie chronić zarówno skrypty, jak i serwery korzystające z PHP przed znanymi i przyszłymi błędami bezpieczeństwa.

Pozostało przetestować poprawność współpracy apache2-PHP5-Mysql5, w tym celu stworzymy plik php o nazwie sql.php i umieścimy go w katalogu /var/www. Oto zawartość pliku:

mysql_connect(„localhost”, „root”, „testowe”) or die(mysql_error());

echo „Polaczony MySQL
„;

?>

Wpisując w przeglądarce internetowej adres http://10.10.10.32/sql.php zobaczy komunikat:

Polaczony MySQL, oczywiście oznacza to poprawność instalacji.

Niestety na tym etapie wielu administratorów kończy konfigurację, serwer działa prawidłowo, strony wymagające obsługi PHP oraz MYSQL prawidłowo się instalują oraz działają. Efektem takiego postępowania są bardzo częste włamania na systemy CMS, nieprawidłowo napisane skrypty PHP itp. Naszym zadaniem będzie takie skonfigurowanie oprogramowania, że większość prób włamania zostanie zablokowane.

Konfiguracja serwera apache2

W celu eliminacji zagrożenia cross-site tracing uruchomimy moduł rewrite, moduł ten ma ogromne możliwości konfiguracyjne pomocne webmasterom, np. pozwala tworzyć „przyjazne adresy” czy tworzyć przekierowania. My wykorzystamy jego moc do walki z cross-site tracing, który w uproszczeniu pozwala na kradzież ciasteczek przy pomocy metody TRACE.

W celu uruchomienia modułu wpisujemy w konsoli:

ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load

następnie dodajemy odpowiednie wpisy do pliku apache2.conf:

RewriteEngine on

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)

RewriteRule .* – [F]

Warto także wyłączyć metodę TRACE w /etc/apache2/conf.d/security ustawiając dyrektywę TraceEnable On na TraceEnable Off

W większości przypadków zasadniczo można ograniczyć serwer do przyjmowania tylko standardowych metod komunikacji:

RewriteEngine on

RewriteCond %{REQUEST_METHOD} !^(GET|POST|PUT|HEAD)$

RewriteRule .* – [F]

Przeglądając sekcję apache2handler na wcześniej utworzonej stronie http://10.10.10.32/info.phpmożemy zobaczyć że nasz serwer jest strasznie gadatliwy i podaje bardzo dużo informacji. Wiadomo że im mniej wie atakujący tym lepiej, dlatego też teraz zajmiemy się tym problemem. W chwili obecnej serwer przedstawia się jako:

Apache/2.2.9 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.6-1+lenny3 with Suhosin-Patch mod_perl/2.0.4 Perl/v5.10.0

W celu uciszenia serwera edytujemy plik /etc/apache2/conf.d/security, i odpowiednio zmieniamy dyrektywy:

ServerTokens Prod

ServerSignature Off

Po tym zabiegu odpytany serwer podaje tylko jedną informację:

apache

w dalszej części artykułu zmienimy także i tę informację.

Domyślnie obsługa PHP jest dostępna dla wszystkich, nie jest to dobry pomysł, biorąc pod uwagę że część użytkowników nawet nie wie co to jest PHP, zakładają proste statyczne strony, które w zupełności zaspokajają ich potrzeby. Obsługa PHP na ich kontach jest tylko zagrożeniem dla całego serwera. W każdym razie warto świadomie załączać PHP tylko dla odpowiednich katalogów, oczywiście pamiętając równocześnie o odpowiednim skonfigurowaniu środowiska.

W tym celu w pliku apache2.conf dopisujemy odpowiednie dyrektywy:

Skoro domyślnie PHP jest załączone, musimy ustawić aby domyślnie PHP było wyłączone:

php_admin_flag engine Off

Następnie załączamy obsługę PHP dla konkretnego katalogu, w naszym przypadku /var/www , ponadto zmuszamy aplikacje PHP aby korzystały z katalogu tmp w katalogu użytkownika, domyślnie jest to katalog /tmp, czyli w głównym drzewie.

php_admin_flag engine On

php_admin_value open_basedir „/var/www:/usr/lib/php:/var/www/tmp:/usr/share/pear”

php_admin_value upload_tmp_dir „/var/www/tmp”

php_admin_value session.save_path „/var/www/tmp”

Dobrym zwyczajem jest zainstalowanie serwera w wyodrębnionym środowisku za pomocą mechanizmu chroot(), jednakże jest to temat na osobny artykuł. Wszystkie techniki opisane w tym artykule z powodzeniem można stosować w środowisku chroot(). Dlatego zachęcam do zapoznania się ze sposobem umieszczania serwera apache2 w środowisku wydzielonym.

Poprawa konfiguracji PHP5

Domyślny plik konfiguracyjny PHP5 jest bardzo liberalny w kwestii bezpieczeństwa, dlatego też absolutną koniecznością jest spędzenie kilku chwil nad jego zawartością. Z pewnością znacznie to podniesie poziom bezpieczeństwa serwera. Konfiguracja znajdziemy znajduje się w /etc/php5/apache2/php.ini

Bardzo istotną z punktu widzenia bezpieczeństwa jest dyrektywa register_globals, musi ona zostać wyłączona. W przypadku gdy funkcja jest aktywna wszystkie zmienne dostępne jako $zmienna, bez wykorzystywania tablic. Przy takiej konfiguracji nie ma możliwości sprawdzenia pochodzenia zmiennej, zmienna może pochodzić z zapytania GET lub POST wygenerowanego przez włamywacza, co dalej może się stać to już chyba wiadomo. Dlatego sprawdzamy czy register_globals na pewno ma wartość OFF.

register_globals = Off

PHP posada wiele bardzo ciekawych funkcjonalności, np. możemy wykonywać polecenia systemowe w ramach skryptu PHP, sprawdzać konfigurację serwera itp. Do typowych zastosowań większość tych funkcji nie jest potrzebna, nawet rozbudowane CMS jak PHPBB czy WordPress działają prawidłowo przy wyłączeniu wielu z tych funkcji. Poniżej przedstawiam konfigurację ze swoich serwerów.

disable_functions = dl,proc_open,get_cfg_var,get_cfg_all,

ini_get_all,set_time_limit,system,readfile,passthru,phpinfo,

exec,sendmail,popen,phpinfo,shell_exec,posix_getpwuid,disk_free_space,php_uname

Listę blokowanych wywołań stworzyłem na podstawie exploitów, które były testowane na moich maszynach przez zwykle azjatyckich i brazylijskich włamywaczy. Szczerze zalecam wyłączenie tych funkcji na swoich serwerach.

Podobnie jak apache tak i PHP jest gadatliwy na swój temat, zdradzając włamywaczowi zbyt wiele informacji, dlatego też ustawiamy:

expose_php = off

Warto także wyłączyć wyświetlanie błędów PHP na stronie skryptu, informacje z błędu zwykle przedstawiają bardzo dużo ciekawych informacji, dlatego dodajemy:

display_errors = Off

Przeglądając logi serwera apache bardzo szybko zauważymy że pojawiają się próby doklejania do adresu URL linków do skryptów na innych serwerach. Włamywacz na zdalnym serwerze umieszcza plik napisany w PHP będącym exploitem, czyli plikiem który jest wstanie skompromitować nasz serwer. Następnie wykorzystując błędnie napisane skrypty na naszym serwerze stara się wykonać swój kod, czyli nasz serwer apache2 wykonuje kod napisany przez włamywacza. Oczywiście wyłączamy tą wątpliwą funkcjonalność:

allow_url_fopen = Off

allow_url_include = Off

Ten prosty zabieg uchroni nas przed ogromną armią dzieci starających się za wszelką cenę zostać hakierami. Niedawna fala włamań, których źródłem byli tureccy włamywacze wykorzystywała min. tego typu podatność.

Bardzo popularne stało się instalowanie przez użytkowników rozbudowanych systemów CMS, korzystają one z mechanizmu sesji, dlatego też niewolno zapominać o prawidłowej konfiguracji tej sekcji.

session.use_only_cookies = 1

session.cookie_domain = twoja.domena

session.referer_check = twoja.domena

session.entropy_length = 16

session.entropy_file = /dev/urandom

session.hash_bits_per_character = 6

Tych kilka dyrektyw znacznie utrudni włamywaczowi zgadywanie identyfikatora sesji.

Instalacja i uruchamianie modsecurity.

Mod_Security jest modułem dla serwera apache2, który w znaczny sposób podnosi stopień bezpieczeństwa serwera. Po zainstalowaniu i skonfigurowaniu moduł przechwytuje wszelkie zapytania kierowane (GET , POST ,cookies) do naszego serwera i poddaje je dokładnym analizą, w zależności od wyniku analizy zapytania podejmuje odpowiednie akcje.

Dzięki tej funkcjonalności i dobrze dobranej konfiguracji, pozwala udaremnić znakomitą większość ataków na aplikacje web. Każdego dnia publikowane są exploity umożliwiające zaatakowanie systemów CMS, dokładnie skonfigurowane mod_security zwykle udaremnia te działania już na przedbiegach.

Na początek należy zainstalować niezbędne oprogramowanie oraz biblioteki.

apt-get install libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev g++ make

Tworzymy katalog, w którym będziemy kompilować moduł:

mkdir /usr/src/mod_security

cd /usr/src/mod_security

Pobieramy najnowszą wersję modułu ze strony producenta, na dziś tj. 30.07.09 jest to wersja 2.5.9.

wget http://www.modsecurity.org/download/modsecurity-apache_2.5.9.tar.gz

Rozpakowanie pobranego archiwum:

tar zxvf modsecurity-apache_2.5.9.tar.gz

cd modsecurity-apache_2.5.9/apache2/

Następnie kompilujemy:

./configure

make

make install

Tworzymy plik /etc/apache2/mods-available/mod-security2.load o zawartości:

LoadFile /usr/lib/libxml2.so

LoadFile /usr/lib/liblua5.1.so.0

LoadModule security2_module /usr/lib/apache2/modules/mod_security2.so

Pozostało aktywować nowo zainstalowany moduł:

a2enmod mod-security2

a2enmod unique_id

Tworzymy plik konfiguracyjny:

touch /etc/apache2/conf.d/mod-security2.conf

o zawartości:

Include /etc/apache2/mod_security/*.conf

Tworzymy katalog, w którym będą przechowywane reguły filtrów:

mkdir /etc/apache2/mod_security

Umieszczamy w nim filtry, które pobraliśmy wraz modułem:

cp /usr/src/mod_security/modsecurity-apache_2.5.9/rules/*.conf /etc/apache2/mod_security/

Domyślnie moduł stara się umieszczać logi w katalogu /etc/apache2/logs , jeśli nie zmienimy tej domyślnej konfiguracji w pliku /etc/apache2/mod_security/modsecurity_crs_10_config.conf musimy utworzyć katalog:

mkdir /etc/apache2/logs

Szybki restart usługi:

/etc/init.d/apache2 restart

W tym momencie moduł mod_security został zainstalowany i uruchomiony do pracy z naszym serwerem apache2.

Wcześniej pisałem że zmienimy informacje o nazwie serwera www, który pracuje na naszej maszynie. W jaki sposób przedstawia się nasz serwer możemy sprawdzić za pomocą serwisu:

http://www.pean.com/whats_that_site_running.php

Nasz serwer przedstawia się jako:

Apache

Sprawdźmy jak przedstawiają się znane serwery znanych firm:

Onet.pl – AOLserver/3.4.2

Wp.pl – aris

Microsoft.pl – Microsoft-IIS/7.0

Na potrzeby tego artykułu będziemy przedstawiać się jako aris, w tym celu w pliku w pliku /etc/apache2/mod_security/modsecurity_crs_10_config.conf ustawiamy dyrektywę:

SecServerSignature „aris”

Oczywiście nazwa serwera to dowolny ciąg znaków i nic nie stoi na przeszkodzie aby serwer nazwać antynet.pl lub jeszcze inaczej, jak to zrobił administrator serwera debacom.pl.

Gorąco zachęcam do zapoznania się zawartością plików w katalogu /etc/apache2/mod_security/ nawet początkujący administrator bez większych problemów będzie potrafił tworzyć własne zaawansowane reguły filtrowania.

W Internecie można znaleźć zbiory reguł przygotowane przez zaawansowanych administratorów, zwykle reguły te zabezpieczają przed nowo wykrytymi lukami bezpieczeństwa w aplikacjach PHP. Imponujący zbiór reguł znajduje się pod adresem http://www.gotroot.com/tiki-index.php?page=mod_security+rules .

Zmorą systemów CMS są boty spamujące fora, komentarze itp. formularze, przy pomocy modsecurity możemy unieszkodliwić te działania jeszcze zanim zapytanie dotrze do atakowanego skryptu.

Podsumowanie

Instalacja serwera www apache2 wraz z PHP i MYSQL, nie jest zaskakująco trudnym zadaniem, wystarczą absolutne podstawy znajomości linuxa. W podstawowej konfiguracji serwer jest prosty w obsłudze, nie stwarza problemów z uruchomieniem zaawansowanych skryptów CMS. Jednakże taka konfiguracja jest niezwykle niebezpieczna, to właśnie podstawowe konfiguracje są powodem tak wielu włamań na strony internetowe. Włamanie na stronę to nie tylko deface strony www, od pewnego czasu coraz częściej włamania są niezauważalne dla administratorów i użytkowników. Włamywacze wykorzystują skompromitowane strony www do rozprzestrzeniania złośliwego oprogramowania, rozsyłania spamu a nawet do łączenia serwerów w botnety i wykonywania ataków Ddos. Zastosowanie się administratora do porad zawartych w tym artykule w znakomity sposób zabezpiecza serwer przed większością tego typu zagrożeń. Nic jednak nie zwalnia administratora od czytania dzienników zdarzeń i reagowania na zagrożenia poprzez ciągłą aktualizację oprogramowania, konfiguracji oraz instalowania aktualnych filtrów modsecurity. Filtry są jak bazy antywirusowe, należy je możliwie często aktualizować.

Share and Enjoy:
  • Print
  • Facebook
  • Twitter
  • Google Bookmarks

Potrzebujesz pomocy w Bezpieczny Apache2 plus mod_security2 ? skontaktuj się z administratorem sieci oraz serwerów.
WordPress - Hosting: Twój hosting - Skórka: N.Design Studio - Spolszczenie: Adam Klimowski.
RSS wpisów RSS komentarzy Zaloguj się