bezpieczeństwo

Weryfikacja nadawcy

38

czerwiec 2007

bezpieczeństwo

Weryfikacja nadawcy

39

www.lpmagazine.org

lin

ux

@

so

ftw

ar

e.

co

m

.p

l

J

edną z metod możliwych do zastosowania np. w Post-
fiksie jest weryfikacja nadawcy. Pomysł jest zdrowo-
rozsądkowy i ma swoje proste odniesienie do rzeczy-
wistości zupełnie niezwiązanej ze światem kompute-

rów. Są ludzie, którzy nie znoszą anonimowych listów. Ta-
kowe listy bez czytania wyrzucają do kosza i nie cierpią przy
tym żadnych moralnych katuszy. Tak samo bez obciążeń wy-
rzucają listy podpisane „życzliwy” etc. Człowiek taki nie da
się też łatwo oszukać, gdy ktoś chce się podszyć pod jego zna-
jomych – rozpoznaje bowiem styl, charakter pisma, ogólnie
rzecz ujmując, potrafi w jakiś sposób zweryfikować nadaw-
cę listu. Oczywiście ta weryfikacja nie jest może profesjonalna,
ale jednakowoż istnieje, a to w wielu przypadkach wystarczy.

Weryfikacja nadawcy w Postfiksie

Na czym polega weryfikacja nadawcy w Postfiksie? Przyj-
rzyjmy się typowej wymianie informacji w sesji SMTP.
Możemy to zobaczyć, łącząc się programem telnet z por-
tem 25 serwera:

telnet pryncyp.mol.uj.edu.pl 25
220 pryncyp.mol.uj.edu.pl ESMTP over Postfix

system on freeBSD
ehlo poczta.lsdialog.pl
250-pryncyp.mol.uj.edu.pl
250-PIPELINING
250-SIZE 8000000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250 8BITMIME
mail from: [e-mail]
250 Ok
rcpt to: [e-mail]
250 Ok

Weryfikacja nadawcy

– dylematy administratora

Wszędobylski spam wymusza na administratorach poszukiwanie różnych metod zabezpieczania
serwerów pocztowych przed zalewem niechcianych wiadomości. Nie ma jedynie słusznych metod
– niektóre metody sprawdzają się znakomicie w pewnych warunkach, w innych zaś ich skuteczność
jest zdecydowanie mniejsza.

Janusz Bielec

Janusz Bielec jest trenerem w Compendium Centrum
Edukacyjnym oraz pracownikiem Uczelnianego Ośrodka
Komputerowo-Sieciowego Uniwersytetu Jagiellońskiego.
Posiada stronę domową o adresie: http://awe.mol.uj.
edu.pl/~jjb

O autorze

bezpieczeństwo

Weryfikacja nadawcy

38

czerwiec 2007

bezpieczeństwo

Weryfikacja nadawcy

39

www.lpmagazine.org

data
354 End data with <CR><LF>.<CR><LF>
Teraz podawany jest tekst wiadomości.
Ok: queued as D3E05104FCD

Nieparzyste numery dotyczą klienta, parzy-
ste to odpowiedzi serwera. W praktyce klien-
tem będzie najczęściej inny MTA i takich sy-
tuacji dotyczą dalsze rozważania.

Konfigurując MTA, przyjmuje się zwy-

kle, że każdy może do nas napisać. Podob-
nie jak każdy może do nas wysłać list pocz-
tą. Z tego powodu w typowej konfiguracji
agent transportu nie poświęca dużo uwagi
danym przekazanym w wierszu 5. po pole-
ceniu mail from:, skoro w następnym swoim
kroku (wiersz 7.) klient deklaruje, że chce
przekazać przesyłkę do lokalnego użytkow-
nika rcpt to: [e-mail]. Teraz po pole-
ceniu data treść informacji powinna dotrzeć
do odbiorcy. W wielu przypadkach będzie
to spam, który może zostać wychwycony
przez analizę treści, ale taka dokładna ana-
liza pożera zasoby serwera.

W tej sytuacji możemy pokusić się o spraw-

dzenie, czy nadawca listu mógł wysłać prze-
syłkę z konkretnego serwera. Nie będzie to

potwierdzenie, że to akurat on wysłał tę
przesyłkę, ale możemy przynajmniej spraw-
dzić, czy taki użytkownik istnieje.

W Postfiksie do takich zadań służy pro-

gram verify. Uruchomiony jako demon w mo-
mencie, kiedy serwer odbierze określony po-
leceniem mail from: adres nadawcy, łączy się
z serwerem nadawcy jako klient chcący prze-
słać na adres nadawcy przesyłkę. Oczywiście
nie wysyła żadnej przesyłki, nawet pustej,
chce tylko potwierdzić, że nadawca istnieje
i można do niego wysłać w tym momencie
przesyłkę. W zależności od zachowania serwe-
ra nadawcy Postfix podejmuje decyzje okreś-
lone w konfiguracji, którą omówimy dokład-
nie nieco dalej.

Zasadniczo demon verify mógłby za każ-

dym razem sprawdzać istnienie nadawcy
i jego gotowość do przyjęcia przesyłki, ale
to zabiera trochę czasu, innymi słowy – nie
byłoby to zbyt wydajne rozwiązanie. W ta-
kim razie może lepiej byłoby zbierać takie
zweryfikowane informacje i przechowywać
je przez pewien czas. Do tego jest potrzeb-
na jakaś baza danych, która te informacje bę-
dzie przechowywać. Zasadniczo jest to bar-
dzo prosta tabela, ale dostęp do informacji

powinien być szybki. Postfix może współ-
pracować z wieloma bazami danych, żeby
się dowiedzieć, jakie mamy możliwości. Wy-
starczy wydać polecenie:

postconf -m
btree
cidr
environ
hash
mysql
nis
proxy
regexp
sdbm
static
tcp
unix

Widzimy tu, że w tym przypadku można się
oprzeć np. na bazie typu hash, btree czy mysql.
Załóżmy, że wykorzystamy bazę typu hash,
chociaż przy mocno obciążonych systemach
wydajniejsza będzie baza btree albo mysql.

Teraz przejdźmy do konfiguracji Post-

fiksa. Wszelkie zmiany będą wprowadzane
w pliku main.cf – zwykle znajduje się on w /etc/

R

E

K

L

A

M

A

40

Weryfikacja nadawcy

czerwiec 2007

bezpieczeństwo

postfix. Powinien się tu znaleźć wpis określa-
jący rodzaj i położenie pliku z bazą zweryfi-
kowanych nadawców, np. dla bazy hash bę-
dzie to wpis tego rodzaju:

address_verify_map =
hash:/var/log/mail/verify

Ten wpis nie ustanawia jeszcze żadnej restry-
kcji, ustala jedynie, gdzie należy wpisywać
informację o zweryfikowanych nadawcach
i gdzie jej potem szukać.

Narzućmy teraz na nadawcę obowiązek

weryfikacji:

smtpd_sender_restrictions =
reject_unverified_sender

Teraz nadawca, który nie będzie gotów przy-
jąć od nas przesyłki, zostanie odrzucony. Po-
winniśmy zadeklarować, jak go traktować,
tzn. jakim kodem odpowiedzieć. 450 w po-
niższym przypadku oznacza błąd o charak-
terze nietrwałym:

unverified_sender_reject_code = 450

Jeżeli będziemy pewni poprawności dzia-
łania naszego systemu, możemy ten numer
zmienić na 550. Ale do tego momentu warto
przeglądać dzienniki Postfiksa (np. /var/log/
maillog), obserwując jego zachowanie w kon-
kretnych przypadkach. Będziemy mieli wpi-
sy podobne temu:

pryncyp postfix/smtp[7116]:
D1FFE104EB8: to=<[e-mail]
t>, orig_to=<[e-mail].>,
relay=gateway-s.comcast.net[63.240.76
.26], delay=12, status=undeliverable
(host gateway-s.comcast.net[63.240.7
6.26] said: 551 not our customer (in
reply to RCPT TO command))

lub:

pryncyp postfix/smtpd[7132]: NOQUEUE:
reject: RCPT from i07v-212-194-
92-142.d4.club-internet.fr[212.19
4.92.142]: 450 <vpmurqeozfd@club-
internet.fr>: Sender address rejected:
undeliverable address: host mx.club-
internet.fr[194.158.120.25] said: 550
5.1.1 <[e-mail]>:
Recipient address rejected: User
unknown in local recipient table
(in reply to RCPT TO command);
from=<[e-mail]> to
=<[e-mail]> proto=ESMTP

helo=<i07v-212-194-92-142.d4.club-
internet.fr>

albo:

pryncyp postfix/smtpd[7141]:
NOQUEUE: reject: RCPT from
unknown[189.141.1.18]: 450 <gilber
[e-mail]>: Sender address
rejected: undeliverable address:
host mx1.cribellum.net[198.173.
211.125] said: 550 unknown user
<[e-mail]> (in reply to
RCPT TO command); from=<gilbert@graph
inity.com> to=<[e-mail]>
proto=ESMTP helo=<friend>

Jeżeli adres nadawcy jest niedoręczalny (un-
deliverable), Postfix odrzuca informację. Ale
początkowo warto śledzić, kiedy system
podjąłby taką decyzję, nie odrzucając jednak
informacji. W tym celu należy posłużyć się
poleceniem warn_if_reject. System zapisze w
dzienniku, że informacja zostałaby odrzuco-
na, ale przyjmie ją do dalszej analizy:

smtpd_sender_restrictions =
warn_if_reject reject_
unverified_sender

A oto wpis w dzienniku:

pryncyp postfix/smtpd[7540]: NOQUEUE:
reject_warning: RCPT from expredir4
.cites.uiuc.edu[128.174.5.187]: 450
<[e-mail]>: Sender address
rejected: unverified address:
Address verification in progress;
from=<[e-mail]>
to=<[e-mail]>
proto=ESMTP helo=<expredir4.cites.
uiuc.edu>

Po upewnieniu się, że wszystko działa popraw-
nie, możemy wpis warn_if_reject wyrzucić.

Typowe problemy

Zapisuję się do grupy językowej, aby otrzy-
mywać codzienną dawkę ćwiczeń, a tu infor-
macje nie docierają. Sprawdzam w nagłówku
wiadomości i widzę wpis:

Message-Id:
<[e-mail]>
From: "Nauka.pl"
<[e-mail]>

To znaczy, że wysyła to użytkownik mailing z
domeny nauka.pl.

Polecenie:

dig -t mx nauka.pl

informuje mnie, dokąd wyśle zapytanie mój
serwer przy próbie weryfikacji nadawcy:

ANSWER SECTION: nauka.pl. 86400
IN MX 10 mx.nauka.pl.

Teraz łączę się telnetem z portem 25. serwera
mx.nauka.pl:

telnet mx.nauka.pl 25
Trying 195.149.231.91...
Connected to mx.nauka.pl
(195.149.231.91).
Escape character is '^]'.
220 smtp.h.win.pl ESMTP
helo pryncyp.mol.uj.edu.pl
250 smtp.h.win.pl
mail from: [e-mail]
250 ok
rcpt to: [e-mail]
511 sorry, no mailbox here by that
name / skrzynka pocztowa odbiorcy
nie istnieje (#5.1.1 – vuser)

Zapytajmy teraz bazę verify:

postmap -q [e-mail] hash:
/var/log/mail/verify
2:0:1168402483:host mx.nauka.pl
[195.149.231.91] said: 511 sorry,
no mailbox here by that name /
skrzynka pocztowa odbiorcy nie
istnieje (#5.1.1 - vuser) (in reply
to RCPT TO command)

To jest niestety częsty przypadek – jak sobie
poradzić? Możemy zezwolić na przesyłanie in-
formacji z tej domeny bez weryfikacji nadaw-
cy, ale problem jest dosyć popularny. Wiele
list dyskusyjnych, systemów wysyłających in-
formacje np. o rezerwacjach biletów wpisuje
w nazwie nadawcy coś, co ma znaczenie dla ba-
zy rezerwacji, ale nie jest weryfikowalnym kon-
tem. W dodatku na ogół nie są przesyłane żad-
ne dodatkowe informacje, że jest to konto typu
„bulk”, służące li tylko do rozsyłania maili.

Podsumowanie

Moim zdaniem jest to konfiguracja utrudniają-
ca kontrolowanie spamu. Swego czasu przyję-
te było, że pewne nazwy w adresach należy
łączyć z listami mailowymi, ale teraz wydaje
mi się to mało sensowną zasadą. Po prostu
należałoby stworzyć choćby alias dla adre-
su nadawcy.