bezpieczeństwo
Amavis
72
listopad 2007
bezpieczeństwo
Amavis
73
www.lpmagazine.org
lin
ux
@
so
ftw
ar
ae
.co
m
.p
l
M
ożna nawet zaryzykować stwierdzenie, że
administrator skazany jest na wybór, a jak
powszechnie wiadomo, człowiek skazany
na wybór strasznie się męczy. Celem te-
go artykułu jest pokazanie pewnej możliwości oceny całości
systemu antyspamowego pod kątem skuteczności konkret-
nych technologii oraz ryzyka odrzucania wiadomości. Pro-
ponowany mechanizm opiera się na statystyce, a więc wyma-
ga zebrania dużej liczby doświadczeń. Odniesienia do konfi-
guracji poruszają tylko aspekty, które są najczęstszą przyczy-
ną problemów, ale nie jest to, z uwagi na ograniczoność miej-
sca, kompendium konfiguracji.
Walka ze spamem – elementy myślenia
systemowego
Po pierwsze proponuję wziąć do pracy Amavisa, ponieważ
Amavis-new ma pewną zaletę, która na ogół nie jest do-
ceniana. Gdy budujemy swój system zabezpieczania pocz-
ty zapewne chcemy sprawdzić możliwości różnych progra-
mów antywirusowych, reguł antyspamowych etc. Być mo-
że sensowne okaże się odrzucanie przesyłek zawierających
potencjalnie niebezpieczne załączniki, a to możemy nie-
kiedy uzyskiwać bezpośrednio w Postfiksie, ale częściej
przez łączenie tych dodatkowych programów bezpośrednio
z Postfiksem. Jednak powstaje system trudny do zarządza-
nia. Lepszym podejściem jest użycie Amavisa, który łatwo
integruje się z programami antywirusowymi, SpamAssassi-
nem etc. Jeżeli połączymy Amavisa z Postfiksem będziemy
mogli swobodnie dodawać dodatkowe testy bezpośrednio
do Amavisa, a Postfix otrzyma zbiorczą ocenę wiadomości.
Wyjątkiem będzie tylko Postgrey, który współpracuje bez-
pośrednio z
smtpd.
Konfiguracja Amavisa
Od pewnego czasu konfigurowanie Amavisa nie jest kłopo-
tliwe, ponieważ dostępne są gotowe pakiety, na ogół wstęp-
nie skonfigurowane. Jednak Amavis-new to duży program,
który może być wykorzystywany jako biblioteka, gdzie od-
wołują się inne programy, a może też działać jako samo-
dzielny demon uruchamiany przy starcie systemu. Nas in-
teresuje ta druga możliwość, więc wykorzystujemy pro-
gram amavisd, który po wystartowaniu nasłuchuje na wy-
branym porcie. Zwykle jest to wysoki port 10024 lub 10025
otwierany tylko dla interfejsu lo. Warto zwrócić uwagę, że
Amavis – system
zabezpieczenia poczty
W rozważaniach na temat antyspamowych możliwości Postfiksa nie poruszaliśmy kwestii dodatkowych
narzędzi przeznaczonych do zwalczania spamu. Tymczasem Postfix, niezależnie od własnych
rozwiązań, potrafi korzystać z zewnętrznych programów. Ze względu na modułową budowę integracja
z dodatkowym oprogramowaniem jest dosyć intuicyjna, nie przysparza jednak problemów.
Janusz Bielec
bezpieczeństwo
Amavis
72
listopad 2007
bezpieczeństwo
Amavis
73
www.lpmagazine.org
przy dużym ruchu sensowne jest przeniesie-
nie amavisa na inną maszynę, a wtedy trze-
ba wskazać w konfiguracji właściwy adres
IP oraz port.
Jak już wspomniałem Amavis po urucho-
mieniu otwiera wysoki port, często mnemo-
nicznie związany z SMTP, np 10025. Możemy
to sprawdzić (Listing 1).
Test Amavisa – powinien
to przekazać na port 10026
gdzie nasłuchuje postfix
Takie samo połączenie na port 10026 powin-
no zaowocować zgłoszeniem się Postfiksa.
Jeżeli nie uzyskamy takich lub podobnych za-
chowań trzeba sprawdzić konfigurację Ama-
visa oraz czy w pliku /etc/amavis/amavisd.
conf mamy wpis:
$inet_socket_port = 10025
Jeżeli podany jest inny numer portu, połącz-
my się telnetem na ten port. Właściwie istotne
jest tylko poinformowanie Postfiksa, na któ-
ry port ma przekazywać informacje. W pliku
/etc/postfix/main.cf musi być fraza:
content_filter = lmtp-filter:127.0.0.1:
10025
zamiast
lmtp-filter
może być protokół lub
agent transportu, np. lmtp, smtp, ale ważne jest
to, że postfix „wie”, iż ma przekazać maile na
pętlę zwrotną, czyli na port 10025 i posłużyć
się protokołem lmtp lub smtp. Po przeanali-
zowaniu informacji Amavis powinien ją lub
informację o niej przekazać na właściwy,
otwarty specjalnie do tych celów przez Post-
fiksa. W konfiguracji Amavisa znajdziemy
w /etc/amavis/amavisd.conf – wiersze:
$notify_method =
'smtp:[127.0.0.1]:10026';
$forward_method =
'smtp:[127.0.0.1]:10026';
mówiące właśnie o tym, natomiast w pliku
/etc/postfix/master.cf – znajdziemy następują-
ce wpisy (Listing 2).
Właściwie istotny jest pierwszy wiersz, któ-
ry nakazuje otworzenie dla smtpd dodatkowe-
go portu 10026, ale biorąc pod uwagę konfigu-
rację smtpd, z rozlicznymi zaostrzeniami może-
my je tutaj nadpisać lub wyzerować, aby zwię-
kszyć wydajność systemu.
Współpraca Amavisa
z programami antywirusowymi
na przykładzie Clamav
Nie będziemy się omawiać wirusów, ale sys-
tem pocztowy bez działającego systemu anty-
wirusowego nie ma sensu, stąd te uwagi. Zna-
ne mi dystrybucje zawierają gotowy pakiet,
który wystarczy zainstalować i sprawdzić
prawidłowość domyślnej konfiguracji. Co na-
leży sprawdzić?
• Istnienie i aktualność bazy sygnatur. W pa-
kiecie dołączony jest programik freshclam,
który warto wywołać przed uruchomie-
niem clamd i uważnie przeczytać komu-
nikaty
• Sposób komunikowania się z Amavisem
– trzeba przeszukać w pliku amavisd.conf
frazy:
['ClamAV-clamd',\&ask_daemon,
["CONTSCAN {}\n"
,
"/var/lib/clamav/
clamd.socket"]
,
qr/\bOK$/, qr/\
bFOUND$/
,
qr/^.*?: (?!Infected Ar-
chive)(.*) FOUND$/ ]
• To nie jest jedyny sposób komunikowania
się Amavisa z clamd, można to zrobić via
Listing 1.
Amavisd otwiera wysoki port
telnet localhost 10025
Trying 127.0.0.1...
Connected to janusz.postfix.localnet (127.0.0.1).
Escape character
is
'^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready
ehlo localhost
250-[127.0.0.1]
250-VRFY
250-PIPELINING
250-SIZE
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 XFORWARD NAME ADDR PROTO HELO
mail from: <janusz@localhost>
250 2.1.0 Sender <janusz@localhost> OK
rcpt to: <root@localhost>
250 2.1.5 Recipient <root@localhost> OK
data
354 End data with <CR><LF>.<CR><LF>
Listing 2.
Wpisy
127.0.0.1:10026 inet n - n - - smtpd
-o
content_filter
=
-o
smtpd_restriction_classes
=
-o
smtpd_client_restrictions
=permit_mynetworks,reject
-o
smtpd_helo_restrictions
=
-o
smtpd_sender_restrictions
=
-o
smtpd_end_of_data_restrictions
=
-o
smtpd_etrn_restrictions
=
-o
smtpd_data_restrictions
=
-o
smtpd_delay_reject
=no
-o
smtpd_recipient_restrictions
=permit_mynetworks,reject
-o
mynetworks
=127.0.0.0/8
-o
smtpd_authorized_xforward_hosts
=127.0.0.0/8
-o
strict_rfc821_envelopes
=yes
-o
smtpd_error_sleep_time
=0
-o
smtpd_soft_error_limit
=1001
-o
smtpd_hard_error_limit
=1000
-o
receive_override_options
=no_unknown_recipient_checks,
no_header_body_checks
74
listopad 2007
bezpieczeństwo
Amavis
otwarty port tcp, podanie symbolicznie
nazwy katalogu do przeskanowania. Ważne
jest jednak to, żeby Amavis i clamd miały
ten sposób uzgodniony we własnych konfi-
guracjach. Oto wpis w clamd.conf:
LocalSocket /var/lib/clamav/
clamd.socket
• Poleceniem
su amavis (vscan)
zmienia-
my identyfikator użytkownika na taki z pra-
wami, z którymi będzie działał Amavis
i wykonujemy polecenie –
amavisd debug
oraz analizujemy treść. Dobrze byłoby za-
pisać wiersz w tej postaci:
Found primary (secondary)
av scanner ClamAV-clamscan
at /usr/bin/clamscan
• Teraz należy testowo przesłać kilka wiado-
mości, a jeżeli zostaną doręczone to mamy
działający system pocztowy z programem
antywirusowym i antyspamowym.
Analiza skuteczności
poszczególnych metod
antyspamowych
Oczywiście możemy monitorować dzienniki
systemu pocztowego – polecenie:
tail -f /var/log/mai/info
(nazwa i położenie dziennika może być nieco
inne) pozwala na bieżąco śledzić pracę syste-
mu. Ma to sens na początku, kiedy martwimy
się o to, czy działa. Potem warto przeanali-
zować dane statystycznie. Metoda, którą pro-
ponuję jest bardzo prosta, wręcz banalna, ale
daje zdroworozsądkowe podstawy do ewen-
tualnych zmian konfiguracji. Osobiście nie
przepadam za „szamaństwem” komputerowym
i argumentacją, że to „świetna metoda, bo
wszyscy ją stosują”.
Budowa dziennika
Zauważmy, że plik dziennika, opisującego pra-
cę systemu pocztowego zawiera tekstowe
wpisy, a operacje grupowane są wierszami.
Wynika z tego, że możemy zliczyć pewne nie-
powtarzalne operacje, zapisane w dzienniku,
używając zwykłych poleceń systemu Linux:
cat
,
grep
i
wc
.
Ot np. polecenie:
grep from= /var/log/mail/info | wc -l
pokaże liczbę nawiązywanych sesji SMTP.
Jeżeli wykorzystujemy RBL to, wpisując od-
powiednią frazę identyfikującą możemy zna-
leźć liczbę sesji SMTP zablokowanych przez
poszczególne bazy. Jednak co my wiemy o tych
odrzucanych sesjach, na ogół jest to spam, ale
jak ująć statystycznie?
SpamAssassin i punktowanie
Wykorzystamy do tego dziennik Amavisa.
W celu ułatwienia analizy niekiedy można ze-
zwolić Amavisowi na samodzielny dziennik,
niż zlecać to demonowi logów (
syslog
,
sy-
slog-ng
).
W dzienniku Amavisa znajdziemy też in-
formację o sposobie punktowania wiadomości
przez SpamAssassin i podsumowanie uzyska-
nych przez wiadomość punktów spamowych. W
tym przypadku wystarczą polecenia
grep
,
wc
,
aby oszacować jak wygląda punktowanie maili
i jaki jest względny udział wiadomości, miesz-
czących się w poszczególnych przedziałach
punktowania. Jak te informacje można wy-
korzystać? Po pierwsze pozwala zobaczyć
jaki procent wiadomości jest znakowany,
a jaki odrzucany. Po drugie taki rozkład bę-
dzie zależał od stosowanych w postfiksie
ograniczeń. Jeżeli wprowadzamy jakieś ogra-
niczenie i nie widzimy zmiany rozkładu to
zapewne działanie tego zaostrzenia jest mało
istotne.
Przykładowo załączam wykres, pokazu-
jący zmianę rozkładu punktów spamowych
przy włączonej i wyłączonej bazie Postgrey
(postgrey działa w ten sposób, że początko-
wo odpowiada na próbę przesłania wiado-
mości komunikatem z grupy 4xx, oznaczają-
cym chwilowy problem doręczenia, co zmu-
sza do próby powtórnego przesłania wiado-
mości).
Co widać na załączonym wykresie: otóż
po pierwsze działanie postgreya jest widoczne
w zakresie 0–2 punktów. Jest to bardzo waż-
ne, ponieważ takie wiadomości są doręcza-
ne do skrzynek, a sumaryczna różnica wyno-
si nieco ponad 5%. Część odrzucanych przez
postgreya wiadomości mają wysoką punkta-
cję, więc i tak nie byłyby doręczone, ale ob-
ciążenie systemu przez SpamAssassin przy
analizie maili będzie większe, aniżeli obcią-
żenie przez postgrey, a to dodatkowy zysk,
tym bardziej, że niecałe 3% sesji nie zosta-
ło powtórnie nawiązanych – w sytuacjach
wysypu wirusów ten udział procentowy jest
znacznie wyższy co zdecydowanie zmniej-
sza obciążenie systemu analizą wykonywa-
ną przez programy antywirusowe.
Podsumowanie
Możemy to podejście wykorzystać przy oce-
nie różnego rodzaju ograniczeń w Posfiksie,
Amavisie i SpamAssassinie. Ja na prywatnie
zrobiłem wiele takich statystyk, a ich wy-
niki rzadko pokrywają się na różnych sys-
temach pocztowych i serwerach w różnych
domenach, co oznacza, że warto je robić na
własny użytek. Szczególnie pomocne bywa
przy podejmowaniu decyzji; od jakiego po-
ziomu wiadomości znakować, a od jakiego
odrzucać.
Rysunek 1.
Wykres dla postgreya
Janusz Bielec jest pracownikiem Sekcji
Usług Serwerowo-Sieciowych Uniwersyte-
tu Jagiellońskiego oraz trenerem w Com-
pendium.
Kontakt z autorem: jjb@mol.uj.edu.pl
O autorze