2007.06_Weryfikacja nadawcy–dylematy administratora_[Bezpieczenstwo].pdf

bezpieczeństwo

Weryikacja nadawcy

– dylematy administratora

Janusz Bielec

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.

iksie jest weryikacja 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, potrai w jakiś sposób zweryikować nadaw-

cę listu. Oczywiście ta weryikacja nie jest może profesjonalna,

ale jednakowoż istnieje, a to w wielu przypadkach wystarczy.

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

Weryikacja nadawcy w Postiksie

Na czym polega weryikacja nadawcy w Postiksie ? Przyj-

rzyjmy się typowej wymianie informacji w sesji SMTP .

Możemy to zobaczyć, łącząc się programem telnet z por-

tem 25 serwera:

O autorze

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

telnet pryncyp.mol.uj.edu.pl 25

220 pryncyp.mol.uj.edu.pl ESMTP over Postix

czerwiec 2007

J edną z metod możliwych do zastosowania np. w Post-

bezpieczeństwo

Weryikacja nadawcy

data

354 End data with <CR><LF>.<CR><LF>

Teraz podawany jest tekst wiadomości.

Ok: queued as D3E05104FCD

potwierdzenie, że to akurat on wysłał tę

przesyłkę, ale możemy przynajmniej spraw-

dzić, czy taki użytkownik istnieje.

W Postiksie 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 Postix podejmuje decyzje okreś-

lone w koniguracji, 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

zweryikowane 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. Postix może współ-

pracować z wieloma bazami danych, żeby

się dowiedzieć, jakie mamy możliwości. Wy-

starczy wydać polecenie:

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.

Konigurują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 koniguracji

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

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

iksa. Wszelkie zmiany będą wprowadzane

w pliku main.cf – zwykle znajduje się on w /etc/

R E K L A M A

www.lpmagazine.org

bezpieczeństwo

Weryikacja nadawcy

postix . Powinien się tu znaleźć wpis określa-

jący rodzaj i położenie pliku z bazą zweryi-

kowanych nadawców, np. dla bazy hash bę-

dzie to wpis tego rodzaju:

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

internet.fr>

Polecenie:

dig -t mx nauka.pl

albo:

address_verify_map =

hash:/var/log/mail/verify

pryncyp postix/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>

informuje mnie, dokąd wyśle zapytanie mój

serwer przy próbie weryikacji nadawcy:

Ten wpis nie ustanawia jeszcze żadnej restry-

kcji, ustala jedynie, gdzie należy wpisywać

informację o zweryikowanych nadawcach

i gdzie jej potem szukać.

Narzućmy teraz na nadawcę obowiązek

weryikacji:

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)

smtpd_sender_restrictions =

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

Jeżeli adres nadawcy jest niedoręczalny ( un-

deliverable ), Postix 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:

unveriied_sender_reject_code = 450

smtpd_sender_restrictions =

warn_if_reject reject_

unveriied_sender

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 Postiksa (np. /var/log/

maillog ), obserwując jego zachowanie w kon-

kretnych przypadkach. Będziemy mieli wpi-

sy podobne temu:

Zapytajmy teraz bazę verify:

A oto wpis w dzienniku:

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)

pryncyp postix/smtpd[7540]: NOQUEUE:

reject_warning: RCPT from expredir4

.cites.uiuc.edu[128.174.5.187]: 450

<msroka@uiuc.edu>: Sender address

rejected: unveriied address:

Address veriication in progress;

from=<msroka@uiuc.edu>

to=<konferencja@inib.uj.edu.pl>

proto=ESMTP helo=<expredir4.cites.

uiuc.edu>

pryncyp postix/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))

To jest niestety częsty przypadek – jak sobie

poradzić? Możemy zezwolić na przesyłanie in-

formacji z tej domeny bez weryikacji 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 weryikowalnym 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.

lub:

Po upewnieniu się, że wszystko działa popraw-

nie, możemy wpis warn_if_reject wyrzucić.

pryncyp postix/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

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:

Podsumowanie

Moim zdaniem jest to koniguracja 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.

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 .

czerwiec 2007

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: