plik

bezpieczeństwo

Weryfikacja nadawcy

czerwiec 2007

bezpieczeństwo

Weryfikacja nadawcy

www.lpmagazine.org

lin

ftw

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: jjb@lsdialog.pl
250 Ok
rcpt to: jjb@mol.uj.edu.pl
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

czerwiec 2007

bezpieczeństwo

Weryfikacja nadawcy

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: jjb@mol.uj.edu.pl. 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/

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=<wtwlabolt@comcast.ne
t>, orig_to=<wtwlabolt@comcast.net.>,
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 <vpmurqeozfd@club-internet.fr>:
Recipient address rejected: User
unknown in local recipient table
(in reply to RCPT TO command);
from=<vpmurqeozfd@club-internet.fr> to
=<kkkowalik@mol.uj.edu.pl> 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
t@graphinity.com>: Sender address
rejected: undeliverable address:
host mx1.cribellum.net[198.173.
211.125] said: 550 unknown user
<gilbert@graphinity.com> (in reply to
RCPT TO command); from=<gilbert@graph
inity.com> to=<taanna@mol.uj.edu.pl>
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
<msroka@uiuc.edu>: Sender address
rejected: unverified address:
Address verification in progress;
from=<msroka@uiuc.edu>
to=<konferencja@inib.uj.edu.pl>
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:
<200703260507.l2Q57eii013232@nauka.pl>
From: "Nauka.pl"
<mailing@nauka.pl>

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: jjb@mol.uj.edu.pl
250 ok
rcpt to: mailing@nauka.pl
511 sorry, no mailbox here by that
name / skrzynka pocztowa odbiorcy
nie istnieje (#5.1.1 – vuser)

Zapytajmy teraz bazę verify:

postmap -q mailing@nauka.pl 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.