Zainspirowany wpisem:
Proponuję w apache zablokować tę funkcjonalność, a przynajmniej ograniczyć do zaufanych hostów.
<FilesMatch „xmlrpc.php”>
Order Deny,Allow
Deny from all
</FilesMatch>
Dziś podczas przenoszenia jednej z domen zaskoczył mnie komunikat:
zone transfer deferred due to quota
Musze przyznać że nie spodziewałam się limitów sterf przy ilości ok. 20 domen.
W każdym razie:
transfers-out x;
transfers-per-ns x;
Skutecznie rozwiązuje problem, zanim znalazłem powód problemu myślałem że mam jakieś spore szambo w swoich DNS.
O przydatności funkcji always_bcc w postfix można pisać wiele. Pomaga tworzyć kopie przesyłek w systemie, pomaga w diagnozie problemów z pocztą itp. itd.
Czasem jednak ta funkcja to za mało, a dokładnie rzecz ujmując zbyt wiele. Jak sobie poradzić z kopią wiadomości od jednego użytkownika/domeny ?
Przedstawiony poniżej przykład będzie przesyłał wiadomości od/do [email protected] na konto [email protected]
recipient_bcc_maps = hash:/etc/postfix/sender_bcc
sender_bcc_maps = hash:/etc/postfix/sender_bcc
mail:/etc/postfix# cat sender_bcc
Oczywiście rozwiązanie to nasuwa na myśli problemy etyczne, jednakże są sytuacje w których tego typu działania są konieczne. Np. użytkownik nagminnie informujący o problemach z pocztą.
Pozdrowienia dla admina BetaSoft, tutaj też będzie „polewka”? 😉
Z przyjemnością polecamy naukę w zaprzyjaźnionej placówce na kierunku Technik Informatyk,
przy zapisie otrzymujesz pierwszy semestr CISCO Exploration GRATIS!
Polecamy także LOKALNĄ AKADEMIĘ CISCO.
Linux w zastosowaniach profesjonalnych to bardzo tania i wygodna alternatywa.
ISP, czyli dostawcy Internetu często borykają się z granicami przepustowości routerów. Internet jest pełen opisów, tutoriali traktujących o budowie routera opartego o Linux.
Często są to bardzo dobre informacje, rzetelne i pozwalające zbudować dobrej jakości router. Jednakże zwykle administrator trafia na problem z wydajnością, przepustowością.
Kupuje od dostawcy 400Mbps puszcza ruch a tam 250 – 300Mbps i koniec, dach na wykresach.
Powody są złożone, sprzęt (frimware np. eth) skonfigurowany optymalnie a nie wydajnie, braki w optymalizacji Firewalla.
Niekończące się linie iptables i tc, zanim pakiet trafi na swoja regułkę przeleci 2tyś innych, w tym czasie system się obciąża a pakiet czeka na wysłanie w świat. Jest wiele różnych bolączek konfiguracyjnych routera.
Doświadczenie i wiedza pozwalają rozwiązać te problemy, na maszynie
cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Pentium(R) CPU G6950 @ 2.80GHz
model name : Intel(R) Pentium(R) CPU G6950 @ 2.80GHz
cat /proc/meminfo
MemTotal: 2053400 kB
MemFree: 175188 kB
lspci | grep Eth
10:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
10:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
20:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe (rev 10)
22:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe (rev 10)
Spokojnie z load 0.0 czasem 0.05 obsługiwanych jest 4tyś. abonentów, adresy prywatne a więc maskowane.
Komunikat ip_conntrack: table full
nie zaistnieje. Wszystko jest kwestią odpowiedniego przeprogramowania sprzętu oraz systemu.
Profesjonalne, niezwykle wydajne i skalowalne routery, które nie kosztują dziesiątek czy setek tysięcy złotych to nie mit.
Nie daj się wciągać w drogie „sprzętowe” rozwiązania. Zaufaj odpowiedniej wiedzy i doświadczeniu.
Odpowiednio przygotowana maszyna może być równocześnie wydajnym i skalowalnym routerem dla tysięcy abonentów, obsługiwać BGP i OSPF do kilku operatorów oraz pracować jako koncentrator PPPoE. W takiej konfiguracji podmiana adresu mac nie pozwoli kraść Internet.
Wykres przepustowości z jednego z routerów Linuks:
Teraz z grubej rury blokada 😉
iptables -N apache_dos
iptables -A INPUT -p tcp –dport 80 –syn -j apache_dos
iptables -A apache_dos -m hashlimit –hashlimit 10/sec –hashlimit-burst 30 \
–hashlimit-mode srcip –hashlimit-name apache_DDOS \
–hashlimit-htable-expire 30000 \
–hashlimit-htable-max 65535 -j ACCEPT
iptables -A apache_dos -j DROP
Metoda chyba najpewniejsza i najprostsza, można zobaczyć efekty wykonując polecenie:
iptables -vL apache_dos
inspiracja – sow 😉
Skoro dziś tak o DoS i DDoS to nie może zabraknąć mod_mod_evasive dla apache2.
apt-get install libapache2-mod-evasive
mcedit /etc/apache2/mods-available/mod-evasive.load
i wpisujemy:
#################################
LoadModule evasive20_module /usr/lib/apache2/modules/mod_evasive20.so
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 10
DOSSiteCount 200
DOSPageInterval 2
DOSSiteInterval 2
DOSBlockingPeriod 10
DOSLogDir „/var/log/evasive”
DOSEmailNotify [email protected]
</IfModule>
######################################
Pamiętamy utworzeniu i nadaniu odpowiednich uprawnień dla:
/var/log/evasive
Dla pewności włączamy moduł:
a2enmod mod-evasive
restart apache2:
/etc/init.d/apache2 restart
inspiracja – sow 😉
Jest fajny moduł do apacha2, który w pewnym stopniu blokuje ataki DoS oraz DDoS.
Oczywiście wszystko zależy od możliwości atakującego i naszych zasobów sieciowych oraz sprzętowych.
Ale do rzeczy.
Mowa o mod_qos
aktualna wersja na 10.06.2011:
cd /usr/src
wget http://netcologne.dl.sourceforge.net/project/mod-qos/mod_qos-9.57.tar.gz
tar zxvf mod_qos-9.57.tar.gz
cd mod_qos-9.57/apache2
apxs2 -i -c mod_qos.c
cd / etc/apache2/mods-available
mcedit qos.load
w zawartości:
##########################
LoadModule qos_module /usr/lib/apache2/modules/mod_qos.so## QoS module Settings<IfModule mod_qos.c># zezwalamy na polaczenia z 1000 różnych IP.QS_ClientEntries 1000# Kazde IP moze wykonac 40 polaczenQS_SrvMaxConnPerIP 40# Maksymalna ilosc rownoczesnych polaczen TCPMaxClients 256# Wylacz keep-alive gdy aktywnych jest polaczenQS_SrvMaxConnClose 180# zapytanie / czas odpowiedzi ( ubij polaczenia niczego niezadajace, DoS)QS_SrvMinDataRate 150 1200CustomLog logs/qsaudit_log „%{qos-path}n%{qos-query}n”</IfModule>LoadModule qos_module /usr/lib/apache2/modules/mod_qos.so
## QoS module Settings
<IfModule mod_qos.c>
# zezwalamy na polaczenia z 1000 różnych IP.
QS_ClientEntries 1000
# Kazde IP moze wykonac 40 polaczen
QS_SrvMaxConnPerIP 40
# Maksymalna ilosc rownoczesnych polaczen TCP
MaxClients 256
# Wylacz keep-alive gdy aktywnych jest polaczen
QS_SrvMaxConnClose 180
# zapytanie / czas odpowiedzi ( ubij polaczenia niczego niezadajace, DoS)
QS_SrvMinDataRate 150 1200
</IfModule>
#####################################
Teraz aktywujemy moduł:
a2enmod qos
no i restartujemy apache2:
/etc/init.d/apache2 restart
Oczywiście gdy DDoS będzie pochodził z większej ilości IP jak określonych w QS_ClientEntries to się powiedzie.
Dlatego ważne jest ustalić dokładnie parametry pracy modułu mając na uwadze wydolność naszej sieci oraz moc obliczeniową serwera.
inspiracja – sow 😉
Automatyczne skanery bezpieczeństwa skanują na ślepo,
odpalają bazę sygnatur i wykonują skanowanie.
Tego typu operacja z oczywistych względów wywoła całą masę 404 w logach apache2.
Więc dlaczego nie wykorzystać tego typu zależności?
SecRule RESPONSE_STATUS „@streq 404” \
„phase:5,t:none,nolog,pass,setvar:ip.not_found_counter=+1,expirevar:ip.not_found_counter=60”
SecRule IP:NOT_FOUND_COUNTER „@gt 5” „phase:1,t:none,log,block,msg:’Zbyt wiele 404′,id:’100003′,setvar:’tx.msg=%{rule.msg}’,setvar:tx.anomaly_score=+%{tx.error_anomaly_score}”
powodzenia 😉
inspiracja – sow 😛
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ć.
Ostatnie komentarze