ANTYNET.PL – Administracja Sieci

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

[email protected] [email protected]

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.

Zapraszam do kontaktu.

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 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

CustomLog               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ć.

SPF czyli [wikipedia] Sender Policy Framework (SPF) to niekomercyjny projekt mający na celu wprowadzenie zabezpieczenia serwerów SMTP przed przyjmowaniem poczty z niedozwolonych źródeł. Ma to pozytywnie wpłynąć na ograniczenie ilości spamu oraz zmniejszenie ilości rozsyłających się wirusów.

Teraz uruchomimy to ustrojstwo u siebie, pozytywne doświadczenie arta na podstawie strony [http://www.urug.net/blog/archives/6-postfix,_SPF_jako_antybiotyk_na_greyliste.html ]

Do dzieła:

instalujemy podstawowy soft.
apt-get install whitelister

edytujemy plik /etc/whitelister.conf

sock: 127.0.0.1:10000
user: www-data
group: www-data
verb: 1
spf: 3
spfrej: yes

Jak widać odpalamy go na prawach www-data, to uprawnienia apache w debianie.
Jak ktoś nam włamie się na apache to przejmie też whitelister , myślę że to wtedy będzie bardzo mały istotny problem.

Teraz edycja main.cf :

należy dopisać: check_policy_service inet:127.0.0.1:10000
u mnie tak to wygląda:
[…]
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_invalid_hostname,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rhsbl_sender dsn.rfc-ignorant.org,
reject_unauth_destination,
check_policy_service inet:127.0.0.1:10000
[…]

pozostało zatwierdzenie konfiguracj:
/etc/init.d/postfix restart