W tym artykule zajm\u0119 si\u0119 konfiguracj\u0105 serwera apache2 w \u015brodowisku Debian. Krok po kroju zainstalujemy apache2 wraz z php5, mysql5 oraz kilkoma dodatkami podnosz\u0105cymi bezpiecze\u0144stwo naszej instalacji. Zainstalowanie tego oprogramowania ci\u0119\u017cko nazwa\u0107 czym\u015b trudnym, jednak\u017ce skonfigurowa\u0107 wszystko w spos\u00f3b skutecznie utrudniaj\u0105cy hackerom \u017cycie jest ju\u017c pewnym wyzwaniem.<\/p>\n
Artyku\u0142 zosta\u0142 tak napisany by czytaj\u0105c go i wykonuj\u0105c zapisane w nim polecenia w pe\u0142ni skonfigurowa\u0107 serwer apache2 wraz z obs\u0142ug\u0105 PHP oraz MYSQL. Oczywi\u015bcie g\u0142\u00f3wny nacisk konfiguracji skierowany b\u0119dzie na bezpiecze\u0144stwo serwera. Pisz\u0105c artyku\u0142, wszystkie polecenia wykonywa\u0142em na \u015bwie\u017co zainstalowanym Debian 5.0 z niestandardowo skonfigurowanym plikiem \/etc\/apt\/sources.list , oto jego zawarto\u015b\u0107:<\/p>\n
deb\u00a0http:\/\/ftp.fr.debian.org\/debian\/<\/a> stable main<\/p>\n deb-src\u00a0http:\/\/ftp.fr.debian.org\/debian\/<\/a> stable main<\/p>\n deb\u00a0http:\/\/security.debian.org\/<\/a> stable\/updates main<\/p>\n deb\u00a0http:\/\/ftp2.de.debian.org\/debian-volatile<\/a> stable\/volatile main<\/p>\n deb\u00a0http:\/\/etc.inittab.org\/~agi\/debian\/libapache-mod-security2\/etch<\/a> .\/<\/p>\n deb\u00a0http:\/\/ftp2.de.debian.org\/debian-volatile<\/a> stable\/volatile main<\/p>\n Po zmianie zawarto\u015bci source.list nale\u017cy wykona\u0107 polecenia:<\/p>\n apt-get update<\/p>\n apt-get upgrade<\/p>\n apt-get dist-upgrade<\/p>\n Instalacja oprogramowania podstawowego.<\/strong><\/p>\n W konsoli wydajemy polecenie:<\/p>\n apt-get install apache2 php5 mysql-server-5.0 php5-mysql mysql-client<\/p>\n Oprogramowanie zostanie automatycznie \u015bci\u0105gni\u0119te z repozytorium i zainstalowane. Ten etap jest absolutnie automatyczny i \u201edzieje si\u0119 sam\u201d (wyj\u0105tkiem jest pro\u015bba o podanie has\u0142a dla serwera mysql), po instalacji tych pakiet\u00f3w nasz serwer www w zasadzie ju\u017c dzia\u0142a. Mo\u017cna to sprawdzi\u0107 wpisuj\u0105c do przegl\u0105darki internetowej adres naszego serwera, na potrzeby tego artyku\u0142u uruchomi\u0142em serwer pod adresem IP 10.10.10.32. Tak wi\u0119c po wpisaniu adresu IP do przegl\u0105darki zobaczymy wspania\u0142y komunikat: W tym momencie serwer www apache2 wraz obs\u0142ug\u0105 PHP oraz MYSQ mamy \u201egotowy\u201d, obs\u0142ug\u0119 php sprawdzimy tworz\u0105c plik informacyjny:<\/p>\n w konsoli wpisujemy:<\/p>\n echo ” ” > \/var\/www\/info.php<\/p>\n Wpisuj\u0105c w przegl\u0105darce internetowej adres\u00a0http:\/\/10.10.10.32\/info.php<\/a> zobaczy szczeg\u00f3\u0142owe informacje na temat zainstalowanego PHP oraz modu\u0142\u00f3w dodatkowych. Jak da si\u0119 zauwa\u017cy\u0107 w domy\u015blnej konfiguracji instalacja jest zaopatrzona w Suhosin Patch, patch ma<\/p>\n za zadanie chroni\u0107 zar\u00f3wno skrypty, jak i serwery korzystaj\u0105ce z PHP przed znanymi i przysz\u0142ymi b\u0142\u0119dami bezpiecze\u0144stwa.<\/p>\n Pozosta\u0142o przetestowa\u0107 poprawno\u015b\u0107 wsp\u00f3\u0142pracy apache2-PHP5-Mysql5, w tym celu stworzymy plik php o nazwie sql.php i umie\u015bcimy go w katalogu \/var\/www. Oto zawarto\u015b\u0107 pliku:<\/p>\n mysql_connect(„localhost”, „root”, „testowe”) or die(mysql_error());<\/p>\n echo „Polaczony MySQL ?><\/p>\n Wpisuj\u0105c w przegl\u0105darce internetowej adres\u00a0http:\/\/10.10.10.32\/sql.php<\/a> zobaczy komunikat:<\/p>\n Polaczony MySQL, oczywi\u015bcie oznacza to poprawno\u015b\u0107 instalacji.<\/p>\n Niestety na tym etapie wielu administrator\u00f3w ko\u0144czy konfiguracj\u0119, serwer dzia\u0142a prawid\u0142owo, strony wymagaj\u0105ce obs\u0142ugi PHP oraz MYSQL prawid\u0142owo si\u0119 instaluj\u0105 oraz dzia\u0142aj\u0105. Efektem takiego post\u0119powania s\u0105 bardzo cz\u0119ste w\u0142amania na systemy CMS, nieprawid\u0142owo napisane skrypty PHP itp. Naszym zadaniem b\u0119dzie takie skonfigurowanie oprogramowania, \u017ce wi\u0119kszo\u015b\u0107 pr\u00f3b w\u0142amania zostanie zablokowane.<\/p>\n Konfiguracja serwera apache2<\/strong><\/p>\n W celu eliminacji zagro\u017cenia cross-site tracing uruchomimy modu\u0142 rewrite, modu\u0142 ten ma ogromne mo\u017cliwo\u015bci konfiguracyjne pomocne webmasterom, np. pozwala tworzy\u0107 \u201eprzyjazne adresy\u201d czy tworzy\u0107 przekierowania. My wykorzystamy jego moc do walki z cross-site tracing, kt\u00f3ry w uproszczeniu pozwala na kradzie\u017c ciasteczek przy pomocy metody TRACE.<\/p>\n W celu uruchomienia modu\u0142u wpisujemy w konsoli:<\/p>\n ln -s \/etc\/apache2\/mods-available\/rewrite.load \/etc\/apache2\/mods-enabled\/rewrite.load<\/p>\n nast\u0119pnie dodajemy odpowiednie wpisy do pliku apache2.conf:<\/p>\n RewriteEngine on<\/p>\n RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)<\/p>\n RewriteRule .* – [F]<\/p>\n Warto tak\u017ce wy\u0142\u0105czy\u0107 metod\u0119 TRACE w \/etc\/apache2\/conf.d\/security ustawiaj\u0105c dyrektyw\u0119 TraceEnable On na TraceEnable Off<\/p>\n W wi\u0119kszo\u015bci przypadk\u00f3w zasadniczo mo\u017cna ograniczy\u0107 serwer do przyjmowania tylko standardowych metod komunikacji:<\/p>\n RewriteEngine on<\/p>\n RewriteCond %{REQUEST_METHOD} !^(GET|POST|PUT|HEAD)$<\/p>\n RewriteRule .* – [F]<\/p>\n Przegl\u0105daj\u0105c sekcj\u0119 apache2handler na wcze\u015bniej utworzonej stronie\u00a0http:\/\/10.10.10.32\/info.php<\/a>mo\u017cemy zobaczy\u0107 \u017ce nasz serwer jest strasznie gadatliwy i podaje bardzo du\u017co informacji. Wiadomo \u017ce im mniej wie atakuj\u0105cy tym lepiej, dlatego te\u017c teraz zajmiemy si\u0119 tym problemem. W chwili obecnej serwer przedstawia si\u0119 jako:<\/p>\n 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<\/p>\n W celu uciszenia serwera edytujemy plik \/etc\/apache2\/conf.d\/security, i odpowiednio zmieniamy dyrektywy:<\/p>\n ServerTokens Prod<\/p>\n ServerSignature Off<\/p>\n Po tym zabiegu odpytany serwer podaje tylko jedn\u0105 informacj\u0119:<\/p>\n apache<\/p>\n w dalszej cz\u0119\u015bci artyku\u0142u zmienimy tak\u017ce i t\u0119 informacj\u0119.<\/p>\n Domy\u015blnie obs\u0142uga PHP jest dost\u0119pna dla wszystkich, nie jest to dobry pomys\u0142, bior\u0105c pod uwag\u0119 \u017ce cz\u0119\u015b\u0107 u\u017cytkownik\u00f3w nawet nie wie co to jest PHP, zak\u0142adaj\u0105 proste statyczne strony, kt\u00f3re w zupe\u0142no\u015bci zaspokajaj\u0105 ich potrzeby. Obs\u0142uga PHP na ich kontach jest tylko zagro\u017ceniem dla ca\u0142ego serwera. W ka\u017cdym razie warto \u015bwiadomie za\u0142\u0105cza\u0107 PHP tylko dla odpowiednich katalog\u00f3w, oczywi\u015bcie pami\u0119taj\u0105c r\u00f3wnocze\u015bnie o odpowiednim skonfigurowaniu \u015brodowiska.<\/p>\n W tym celu w pliku apache2.conf dopisujemy odpowiednie dyrektywy:<\/p>\n Skoro domy\u015blnie PHP jest za\u0142\u0105czone, musimy ustawi\u0107 aby domy\u015blnie PHP by\u0142o wy\u0142\u0105czone:<\/p>\n php_admin_flag engine Off<\/p>\n Nast\u0119pnie za\u0142\u0105czamy obs\u0142ug\u0119 PHP dla konkretnego katalogu, w naszym przypadku \/var\/www , ponadto zmuszamy aplikacje PHP aby korzysta\u0142y z katalogu tmp w katalogu u\u017cytkownika, domy\u015blnie jest to katalog \/tmp, czyli w g\u0142\u00f3wnym drzewie.<\/p>\n php_admin_flag engine On<\/p>\n php_admin_value open_basedir „\/var\/www:\/usr\/lib\/php:\/var\/www\/tmp:\/usr\/share\/pear”<\/p>\n php_admin_value upload_tmp_dir „\/var\/www\/tmp”<\/p>\n php_admin_value session.save_path „\/var\/www\/tmp”<\/p>\n Dobrym zwyczajem jest zainstalowanie serwera w wyodr\u0119bnionym \u015brodowisku za pomoc\u0105 mechanizmu chroot(), jednak\u017ce jest to temat na osobny artyku\u0142. Wszystkie techniki opisane w tym artykule z powodzeniem mo\u017cna stosowa\u0107 w \u015brodowisku chroot(). Dlatego zach\u0119cam do zapoznania si\u0119 ze sposobem umieszczania serwera apache2 w \u015brodowisku wydzielonym.<\/p>\n Poprawa konfiguracji PHP5<\/strong><\/p>\n Domy\u015blny plik konfiguracyjny PHP5 jest bardzo liberalny w kwestii bezpiecze\u0144stwa, dlatego te\u017c absolutn\u0105 konieczno\u015bci\u0105 jest sp\u0119dzenie kilku chwil nad jego zawarto\u015bci\u0105. Z pewno\u015bci\u0105 znacznie to podniesie poziom bezpiecze\u0144stwa serwera. Konfiguracja znajdziemy znajduje si\u0119 w \/etc\/php5\/apache2\/php.ini<\/p>\n Bardzo istotn\u0105 z punktu widzenia bezpiecze\u0144stwa jest dyrektywa register_globals, musi ona zosta\u0107 wy\u0142\u0105czona. W przypadku gdy funkcja jest aktywna wszystkie zmienne dost\u0119pne jako $zmienna, bez wykorzystywania tablic. Przy takiej konfiguracji nie ma mo\u017cliwo\u015bci sprawdzenia pochodzenia zmiennej, zmienna mo\u017ce pochodzi\u0107 z zapytania GET lub POST wygenerowanego przez w\u0142amywacza, co dalej mo\u017ce si\u0119 sta\u0107 to ju\u017c chyba wiadomo. Dlatego sprawdzamy czy register_globals na pewno ma warto\u015b\u0107 OFF.<\/p>\n register_globals = Off<\/p>\n PHP posada wiele bardzo ciekawych funkcjonalno\u015bci, np. mo\u017cemy wykonywa\u0107 polecenia systemowe w ramach skryptu PHP, sprawdza\u0107 konfiguracj\u0119 serwera itp. Do typowych zastosowa\u0144 wi\u0119kszo\u015b\u0107 tych funkcji nie jest potrzebna, nawet rozbudowane CMS jak PHPBB czy WordPress dzia\u0142aj\u0105 prawid\u0142owo przy wy\u0142\u0105czeniu wielu z tych funkcji. Poni\u017cej przedstawiam konfiguracj\u0119 ze swoich serwer\u00f3w.<\/p>\n disable_functions = dl,proc_open,get_cfg_var,get_cfg_all,<\/p>\n ini_get_all,set_time_limit,system,readfile,passthru,phpinfo,<\/p>\n exec,sendmail,popen,phpinfo,shell_exec,posix_getpwuid,disk_free_space,php_uname<\/p>\n List\u0119 blokowanych wywo\u0142a\u0144 stworzy\u0142em na podstawie exploit\u00f3w, kt\u00f3re by\u0142y testowane na moich maszynach przez zwykle azjatyckich i brazylijskich w\u0142amywaczy. Szczerze zalecam wy\u0142\u0105czenie tych funkcji na swoich serwerach.<\/p>\n Podobnie jak apache tak i PHP jest gadatliwy na sw\u00f3j temat, zdradzaj\u0105c w\u0142amywaczowi zbyt wiele informacji, dlatego te\u017c ustawiamy:<\/p>\n expose_php = off<\/p>\n Warto tak\u017ce wy\u0142\u0105czy\u0107 wy\u015bwietlanie b\u0142\u0119d\u00f3w PHP na stronie skryptu, informacje z b\u0142\u0119du zwykle przedstawiaj\u0105 bardzo du\u017co ciekawych informacji, dlatego dodajemy:<\/p>\n display_errors = Off<\/p>\n Przegl\u0105daj\u0105c logi serwera apache bardzo szybko zauwa\u017cymy \u017ce pojawiaj\u0105 si\u0119 pr\u00f3by doklejania do adresu URL link\u00f3w do skrypt\u00f3w na innych serwerach. W\u0142amywacz na zdalnym serwerze umieszcza plik napisany w PHP b\u0119d\u0105cym exploitem, czyli plikiem kt\u00f3ry jest wstanie skompromitowa\u0107 nasz serwer. Nast\u0119pnie wykorzystuj\u0105c b\u0142\u0119dnie napisane skrypty na naszym serwerze stara si\u0119 wykona\u0107 sw\u00f3j kod, czyli nasz serwer apache2 wykonuje kod napisany przez w\u0142amywacza. Oczywi\u015bcie wy\u0142\u0105czamy t\u0105 w\u0105tpliw\u0105 funkcjonalno\u015b\u0107:<\/p>\n allow_url_fopen = Off<\/p>\n allow_url_include = Off<\/p>\n Ten prosty zabieg uchroni nas przed ogromn\u0105 armi\u0105 dzieci staraj\u0105cych si\u0119 za wszelk\u0105 cen\u0119 zosta\u0107 hakierami. Niedawna fala w\u0142ama\u0144, kt\u00f3rych \u017ar\u00f3d\u0142em byli tureccy w\u0142amywacze wykorzystywa\u0142a min. tego typu podatno\u015b\u0107.<\/p>\n Bardzo popularne sta\u0142o si\u0119 instalowanie przez u\u017cytkownik\u00f3w rozbudowanych system\u00f3w CMS, korzystaj\u0105 one z mechanizmu sesji, dlatego te\u017c niewolno zapomina\u0107 o prawid\u0142owej konfiguracji tej sekcji.<\/p>\n session.use_only_cookies = 1<\/p>\n session.cookie_domain = twoja.domena<\/p>\n session.referer_check = twoja.domena<\/p>\n session.entropy_length = 16<\/p>\n session.entropy_file = \/dev\/urandom<\/p>\n session.hash_bits_per_character = 6<\/p>\n Tych kilka dyrektyw znacznie utrudni w\u0142amywaczowi zgadywanie identyfikatora sesji.<\/p>\n Instalacja i uruchamianie modsecurity.<\/strong><\/p>\n Mod_Security jest modu\u0142em dla serwera apache2, kt\u00f3ry w znaczny spos\u00f3b podnosi stopie\u0144 bezpiecze\u0144stwa serwera. Po zainstalowaniu i skonfigurowaniu modu\u0142 przechwytuje wszelkie zapytania kierowane (GET , POST ,cookies) do naszego serwera i poddaje je dok\u0142adnym analiz\u0105, w zale\u017cno\u015bci od wyniku analizy zapytania podejmuje odpowiednie akcje.<\/p>\n Dzi\u0119ki tej funkcjonalno\u015bci i dobrze dobranej konfiguracji, pozwala udaremni\u0107 znakomit\u0105 wi\u0119kszo\u015b\u0107 atak\u00f3w na aplikacje web. Ka\u017cdego dnia publikowane s\u0105 exploity umo\u017cliwiaj\u0105ce zaatakowanie system\u00f3w CMS, dok\u0142adnie skonfigurowane mod_security zwykle udaremnia te dzia\u0142ania ju\u017c na przedbiegach.<\/p>\n Na pocz\u0105tek nale\u017cy zainstalowa\u0107 niezb\u0119dne oprogramowanie oraz biblioteki.<\/p>\n apt-get install libxml2-dev liblua5.1-0 lua5.1 apache2-threaded-dev g++ make<\/p>\n Tworzymy katalog, w kt\u00f3rym b\u0119dziemy kompilowa\u0107 modu\u0142:<\/p>\n mkdir \/usr\/src\/mod_security<\/p>\n cd \/usr\/src\/mod_security<\/p>\n Pobieramy najnowsz\u0105 wersj\u0119 modu\u0142u ze strony producenta, na dzi\u015b tj. 30.07.09 jest to wersja 2.5.9.<\/p>\n
\nIt works!<\/p>\n
\n„;<\/p>\n