bezpieczeństwo

Amavis

listopad 2007

bezpieczeństwo

Amavis

www.lpmagazine.org

lin

ftw

.co

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

listopad 2007

bezpieczeństwo

Amavis

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

'^]'.

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

-o

smtpd_soft_error_limit

=1001

-o

smtpd_hard_error_limit

=1000

-o

receive_override_options

=no_unknown_recipient_checks,

no_header_body_checks

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

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

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