Konfiguracja postfixa

Na początek warto powiedzieć jak wygląda sesja SMTP, poniżej jest przykład, znaki » oznaczają znaki wysyłane przez klienta, znaki « oznaczają znaki wysyłane przez serwer. Kolorem niebieskim są zaznaczone moje komentarze.

klient łączy się z serwerem, serwer sprawdza smtpd_client_restrictions, w tym momencie serwer zna tylko adres IP i revDNS
« 220 dual.lemat.priv.pl ESMTP Postfix (2.x.x)
» helo nazwa.hosta.tld
lub ehlo nazwa.hosta.tld; serwer sprawdza smtpd_helo_restrictions, w tym momencie serwer zna adres IP, revDNS i podaną nazwę hosta w helo
« 250 dual.lemat.priv.pl
» mail from: < adres nadawcy >
serwer sprawdza smtpd_sender_restrictions, w tym momencie serwer zna adres IP, revDNS, helo, adres kopertowy nadawcy oraz to, czy nadawca wysłał poprawny login i hasło
« 250 Ok
» rcpt to: < adres odbiorcy >
serwer sprawdza smtpd_recipient_restrictions, w tym momencie serwer zna adres IP, revDNS, helo, adres kopertowy nadawcy, to, czy nadawca wysłał poprawny login i hasło oraz adres odbiorcy
« 250 Ok
» data
« 354 End data with .
» Subject: test
» to jest test
» .
serwer sprawdza smtpd_data_restrictions, header_checks i body_checks
« 250 Ok: queued as 15D121040A
» quit
« 221 Bye
Connection closed by foreign host.

Każdy z tych testów może zwrócić właściwie jedną z trzech odpowiedzi:

• kod 2xx oznaczający "OK, idziemy dalej"
• kod 4xx oznaczający "Mam błąd, spróbuj ponownie później"
• kod 5xx oznaczający "Spadaj na drzewo i nie wracaj"

Powyższy przykład oczywiście zawsze dawał OK.

Tutaj jest schemat w Dia (http://www.gnome.org/projects/dia/), autorstwa Bartłomieja Syryjczyka, który pomoże zobrazować sesję SMTP. Można wyłączyć warstwę 'Practice', bo to dotyczy serwera B.S., ew. zmodyfikować ją wg swoich potrzeb.

Jest kilka bardzo ważnych powódów dla którego zacząłem ten artukuł zobrazowaniem sesji SMTP:

1) będziecie w stanie sami zrobić telnet na port 25 i ręcznie wysłać emaila,

2) serwer (postfix) po każdym takim pytaniu-odpowiedzi zna coraz więcej szczegółów dotyczacych emaila. W odpowiednich fazach są uruchamiane odpowiednie smtp_*_restrictions. Dlatego błędem jest np. umieszczenie reguł sprawdzających odbiorcę przed smtpd_recipient_restrictions - bo wtedy jeszcze odbiorca nie jest znany.

Kilka ważnych uwag - po przeczytaniu spalić:

1) przy ustawionym smtpd_delay_reject=yes postfix uruchamia sprawdzanie smpt_client/helo/sender/recipient_restrictions dopiero po tym jak dostanie adres odbiorcy. Ja mam w konfigu ustawione na "no" i w zasadzie tak polecam ustawić jak już dopracujecie własną konfigurację - bez tego trafia mi się spam na postmaster@, który nie wiadomo czemu postfix sam z siebie whitelistuje. A tak odrzuci przynajmniej te Chiny/Koreę w smtpd_client_restrictions.

2) pliki typu hash: po każdej zmianie należy traktować poleceniem postmap. Ponadto polecenie postmap -q "xxx" typ:plik sprawdzi czy dodana ostatnio do pliku regułka jest prawidłowa.

3) jak coś nie działa to pierwszym miejscem w jakie należy zajrzeć są logi. Odpowiednio ustawione debug_peer_list = 1.2.3.4 zdecydowanie pomoże. Tu jest w sumie największy problem, bo o ile ja mam ileś tam lat praktyki i wszelkie błedy w logach wyłapuję od razu, to zdaję sobie sprawę, że nie każdy tak potrafi. A umiejętność przeglądania logów jest podstawą w pracy admina.

4) polecenie postconf -n pozwala nam zweryfikować czy nie popełniliśmy błędu w pisaniu main.cf - nie przyjmie/wyświetli błędnych wpisów.

Dla kogo (nie) jest przeznaczony ten artykuł

Artykuł jest przeznaczony dla administratorów, którzy już mają serwer poczty ale chcieliby uszczelnić swoje filtry antyspamowe. Zdecydowanie nie jest on przeznaczony dla administratorów, którzy mają pierwszą styczność z postfixem, lub co gorsza - z linuxem! Artykuł nie wyjaśnia działania poszczególnych opcji postfixa - nie miałem zamiaru przepisywać manuala. W zasadzie czytając tą stronę warto mieć otwartą stronę http://www.postfix.org/postconf.5.html dającą szersze wytłumaczenie danych opcji. Artykuł wyjaśnia którą opcję i gdzie należy zastosować.

Podstawowa konfiguracja.

mydestination =  $mydomain
myorigin = $mydomain
mynetworks = 127.0.0.1/32
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous

smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    permit
header_checks =
body_checks =

# od postfixa 2.10 defaultowo smtpd_*_restrictions są puste, zamiast nich jest:

smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,

zapewnia nam podstawową kontrolę nad serwerem

• serwer może sam wysyłać mejle - permit_my_networks
• ci, którzy się zautoryzowali loginem i hasłem mogą wysyłać mejle do dowolnych adresatów
• pozostałe przypadki są odrzucane jeżeli nadawca nie jest lokalny

Taki konfig zapewnia nam elastyczność - serwer nie jest OpenRelajem i każdy user po podaniu loginu i hasła może wysłać przez niego meila.

Kolejność reguł ma znaczenie:

postfix ma cztery główne łańcuchy reguł: smtpd_client/helo/sender/recipient_restrictions (i jeszcze jest _data_), każdy łańcuch zawiera pojedyncze reguły, pojedyncza reguła, która daje w wyniku OK lub REJECT (5xx,4xx) powoduje zakończenie przetwarzania danego łańcucha i przejście do następnego łańcucha.

Przykład:

smtpd_recipient_restrictions =
# hosty zaliczane do $mynetworks wychodzą po tej regule z dalszego sprawdzania, gdyby w mynetworks umieścić cały świat to serwer byłby Open Relajem
    permit_mynetworks,
# klienci, którzy wysłali poprawny login i hasło wychodzą po tej regule z dalszego sprawdzania
    permit_sasl_authenticated,
# dlatego też do tego miejsca docierają tylko klienci, którzy chcą do nas coś przysłać - nasz serwer jest odbiorcą tej poczty, a poniższa reguła sprawdza czy przypadkiem ktoś nie testuje naszego serwera jako Open Relay, gdyby w mydestination umieścić cały świat albo na przykład całe .pl to serwer byłby Open Relayem
    reject_unauth_destination,
# do tego miejsca docierają klienci, dla których nasz serwer jest rzeczywiście odbiorcą poczty. Przyjmując, że wszystkie domeny utrzymywane na naszym serwerze istnieją to poniższa reguła jest całkowicie bez sensu - jest umieszczona w złym miejscu i powoduje tylko bezsensowne mielenie taktów procesora.
    reject_unknown_recipient_domain

# "permit" na końcu dla  postfixa nie ma żadnego znaczenia. Ma to wizualne znaczenie dla Was, że łańcuch się kończy i email zostanie przyjety (nie ma juz nic więcej, co może odrzucić email)
    permit

Ale bardzo szybko na nasz serwer zaczną przychodzić wirusy i spam

Jak sobie z nimi poradzić? Trzeba nieco zmodyfikować konfig, korzystając z tego, że postfix umożliwia tworzenie list np. lista adresów email spamerów.

Ale najpierw skorzystajmy z dobrodziejstw RBLi:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
#    reject_rbl_client dynamic.rbl.tld, # (proponuję zrobić własnego RBLa - patrz artykuł obok)
#    reject_rhsbl_client revdns.rbl.tld,
#    reject_rhsbl_helo revdns.rbl.tld,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    permit

pierwszy RBL listuje adresy dynamiczne, na przykład neostrada. Chodzi o to, że adresy dynamiczne z reguły należą do osób prywatnych, które stawiają na nich windowsa a nie serwer SMTP. Oczywiście nic nie stoi na przeszkodzie aby jednak postawić tam serwer! Problem jest taki, że nikt od nas wtedy nie będzie przyjmował poczty. Po prostu 99,(9)% połączeń z adresów dynamicznych to wirusy lub spam. A dla ułamka procenta nie warto rezygnować z korzyści odrzucania na podstawie tego kryterium.

RBLe *.rbl.tld są specjalnie zakomentowane, bo mnóstwo ludzi bezmyślnie kopiuje moją konfigurację. Ta konfiguracja nie będzie działać jeżeli nie zainstalujemy najpierw rbldnsd z odpowiednim plikiem.

Pozostałe/niewymienione (zobaczcie robtex.com) RBLe trzymają po prostu adresy IP spamerów, przy czym różnią się oczywiście niuansami np. czasem usunięcia IP z listingu. Więcej info znajdziecie na stronach głównych tych RBLi.

Ważna uwaga: powyżej znajduje się 5 RBLi, nic nie stoi na przeszkodzie aby umieścić ich tam 300. Problem byłby tylko taki, że każde zapytanie trwa nawet kilka sekund. Dlatego warto ograniczyć się tylko do tych, które są najszybsze i mają najwięcej IPków. Warto sobie stworzyć nawet własnego RBLa - z niektórych można pobrać kopię stref i nakarmić nimi własnego.

Ważna uwaga 2: trzeba co jakiś czas sprawdzać, czy dane RBLe jeszcze istnieją.

Jak wspomniałem sprawdzanie RBLi trwa

Czy są jeszcze jakieś kryteria, które pozwolą nam odsiać trochę wirusów i spamu, a które mogą być przeprowadzone minimalnym nakładem środków? Jasne że tak!

Protokół SMTP jest opisany w RFC 821, rozszerzenie jego, jest opisane w RFC 2821. To drugie RFC w punkcie 3.6 mówi, że klient po EHLO musi dać nazwę hosta, tzw. FQDN - czyli musi to być poprawnie pod względem znaków (nie może być na przykład znaków specjalnych) oraz, że taka nazwa musi funkcjonować w DNS. Przykładem takiej nazwy jest mail.lemat.priv.pl, [79.190.106.114] Przykłady nazw, które nie spełniają tego kryterium: cokolwiek.lemat.priv.pl, ^%^$^&%&.tld, 79.190.106.114

Biorąc pod uwagę fakt, że stare SMTP całkowicie wyszło z mody można bez przeszkód wymagać, aby klient łączący się z naszym serwerem:

1. gadał nowocześnie czyli EHLO
2. po EHLO przedstawił się prawidłową nazwą hosta
3. przedstawiał się SWOJĄ nazwą a nie nazwą naszego serwera

dlatego też można rozszerzyć nasze regułki:

smtpd_helo_restrictions =
        reject_unauth_pipelining,
        reject_invalid_helo_hostname, # dla postfixa < 2.3 reject_invalid_hostname,
        permit

smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   check_helo_access hash:/etc/postfix/helo_checks,
   check_helo_access pcre:/etc/postfix/helo_checks.pcre,
   reject_unknown_helo_hostname, # dla postfixa < 2.3 reject_unknown_hostname,
   reject_non_fqdn_helo_hostname, # dla postfixa < 2.3 reject_non_fqdn_hostname,
   reject_rbl_client dynamic.rbl.tld,
   reject_rhsbl_client revdns.rbl.tld,
   reject_rhsbl_helo revdns.rbl.tld,
   reject_rbl_client sbl-xbl.spamhaus.org,
   permit

smtpd_helo_required = yes
unknown_hostname_reject_code = 550

plik helo_checks zawiera:

lemat.priv.pl REJECT You are not lemat.priv.pl 
# Somebody HELO'ing with our IP address?
79.190.106.114 REJECT You are not 79.190.106.114
# Somebody HELO'ing as "localhost?"  Impossible, we're "localhost"
localhost REJECT You are not me

plik helo_checks.pcre zawiera:

/^\[[0-9]+(\.[0-9]+){3}\]$/     REJECT Numerical helo/ehlo is not allowed here
/[0-9]+(\-[0-9]+){3}/           REJECT Generic / dynamic helo/ehlo is not allowed here
/^google\.com$/                 REJECT fake EHLO name
/^gmail\.com$/                   REJECT fake EHLO name
/^mail2world\.com$/              REJECT fake EHLO name

/\S*(?:static|fixip)/                                                   DUNNO

/dialin|dialup|dial-up|dynamic|dhcp|gprs|ddns|pppoe|chello/             REJECT Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/^dial-\d+.[a-z]+\.dialog\.net\.pl$/                                    REJECT Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP

/\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+\S*\.\S+\.\S+/                     REJECT HELO_DYNAMIC_IPADDR Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S*(?:cm|catv|docsis|cable|dsl|dhcp|cpe|node)\S*\d+[^\d\s]+\d+/        REJECT HELO_DYNAMIC_DHCP Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S*\d+[^\d\s]+\d+\S*\.(?:docsis|cable|dsl|adsl|dhcp|cpe)\./            REJECT HELO_DYNAMIC_HCC Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+\d+\S+\.client2\.attbi\.com/                                        REJECT HELO_DYNAMIC_ATTBI Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/CPE\d+\S+\.rogers\.com/                                                REJECT HELO_DYNAMIC_ROGERS Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/[a-z]{2}-\S+-\d{1,3}\.[a-z]{3,8}\.adelphia\.net/                       REJECT HELO_DYNAMIC_ADELPHIA Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/[a-z][A-F0-9]+\.dip\./                                                 REJECT HELO_DYNAMIC_DIALIN Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/0x[a-f0-9]{8}\./                                                       REJECT HELO_DYNAMIC_HEXIP Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\d+\.\S+\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]/                                REJECT HELO_DYNAMIC_SPLIT_IP Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/YahooBB/                                                               REJECT HELO_DYNAMIC_YAHOOBB Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+\.dyn\.optonline\.net/                                              REJECT HELO_DYNAMIC_OOL Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/[a-z]+-\d{1,3}-\d{1,5}\.roadrunner/                                    REJECT HELO_DYNAMIC_RR2 Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/[a-z-]+\d+[a-z]{3}\.[a-z0-9]+\...\.comcast/                            REJECT HELO_DYNAMIC_COMCAST Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/h\d+n\d+fls\S+\.telia\.com/                                            REJECT HELO_DYNAMIC_TELIA Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/cm-[a-z]+\d+-\d+-\d+\.cm\.vtr/                                         REJECT HELO_DYNAMIC_VTR Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+\.cm\.chello\.no/                                                   REJECT HELO_DYNAMIC_CHELLO_NO Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/[a-z]\d+\.upc-[a-z]\.chello\.nl/                                       REJECT HELO_DYNAMIC_CHELLO_NL Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/[a-z]{2}\d+\.user\.veloxzone\./                                        REJECT HELO_DYNAMIC_VELOX Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+\d+-\d+-cust\d+\.[a-z]{4,6}\.broadband\.ntl\.com/                   REJECT HELO_DYNAMIC_NTL Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/[a-z]{2}\d+-\S\.\S+\d\.[a-z]{2}\.home\.nl/                             REJECT HELO_DYNAMIC_HOME_NL Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+-[a-z]\d+\.[a-z]{6}\.tds\.net/                                      REJECT HELO_DYNAMIC_TDS Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\d+\.cps\./                                                            REJECT HELO_DYNAMIC_VIRTUA Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+-[a-z]\d+-\d+\./                                                    REJECT HELO_DYNAMIC_SPACELAN Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+[\-\.]dyn(?:amic)?[\-\.]/                                           REJECT HELO_INDICATOR_DYN Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+[\-\.](?:docsis|dhcp|cpe|catv)[\-\.]/                               REJECT HELO_INDICATOR_TYPE2 Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP
/\S+[\-\.]dyn(?:amic)?\d/                                               REJECT HELO_DYNAMIC_TTNET Dynamic/residential IP; spam source (dial-up or DSL line). Please use your ISP's SMTP

Jak widać regułki sprawdzające HELO umieściłem przed regułkami odpytującymi RBLe - chodzi o szybkość oraz o to, aby niepotrzebnie nie męczyć i tak od czasu do czasu DDOSowanych organizacji antyspamerskich utrzymujących te serwery.

Ważna uwaga: niektórzy ladmini polskich serwerów (kilka banków, jakieś organizacje w domenie *.gov.pl) skonfigurowali źle swoje serwery zatem powyższa konfiguracja odrzuci legalną pocztę z tych domen! Jakby jednak dostali kilkaset odpowiedzi 550 dziennie to zmądrzeliby szybko. Zwłaszcza prezesi byliby zdziwieni czemu ich poczta nie dochodzi. - nieaktualne - od bardzo dawna nie widziałem takiego przypadku.

Ważna uwaga2: postfix nie sprawdza czy to, co podaje klient w HELO zgadza się z jego IP lub z revDNSem, postfix sprawdza tylko czy dana nazwa da się rozwiązać na numer IP - na dowolny numer IP. Stąd tez spamerzy przez jakiś czas dawali w helo "mail.com", co ja z kolei dorzuciłem do hasha helo_checks z odpowiednim REJECTem. Do takiego bardziej szczegółowego sprawdzania przydaje się SPF - realizuje to postfix-policyd-spf-perl (mxfilter tego nie robi)

HELO mamy z głowy, a co z poprawnością adresów nadawcy i odbiorcy?

Załatwia to poniższy konfig:

strict_rfc821_envelopes = yes
unknown_address_reject_code = 550

najpierw nadawca:

smtpd_sender_restrictions =
    reject_unknown_sender_domain,
    reject_non_fqdn_sender,
    check_sender_access pcre:/etc/postfix/sender_checks.pcre
    permit

Te opcje sprawdzają czy adres nadawcy nie zawiera dziwnych znaków, oraz czy istnieje jego domena - spamerzy oraz wirusy dość często tutaj się łapią.
Plik sender_checks.pcre jest do pobrania razem z całym moim konfigiem ze strony instalacja postfix-a

Następnie adres odbiorcy:

smtpd_recipient_restrictions =
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_sender_access hash:/etc/postfix/sender_checks_my, # (patrz dział o podszywaniu się)
    check_helo_access hash:/etc/postfix/helo_checks,
    check_helo_access pcre:/etc/postfix/helo_checks.pcre,
    reject_unknown_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_rbl_client dynamic.rbl.tld,
    reject_rhsbl_client revdns.rbl.tld,
    reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client sbl-xbl.spamhaus.org,
    permit

A gdyby tak lista spamerów?

smtpd_recipient_restrictions =
    check_recipient_access hash:/etc/postfix/sender_checks,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_sender_access hash:/etc/postfix/sender_checks_my,
    check_helo_access hash:/etc/postfix/helo_checks,
    check_helo_access pcre:/etc/postfix/helo_checks.pcre,
    reject_unknown_helo_hostname,
    reject_non_fqdn_helo_hostname,
    check_sender_access hash:/etc/postfix/sender_checks,
    reject_rbl_client dynamic.rbl.tld,
    reject_rhsbl_client revdns.rbl.tld,
    reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client sbl-xbl.spamhaus.org,
    permit

Dlaczego umieściłem tam 2 razy plik sender_checks ? Bo skoro ci nadawcy nie mogą nadawać do nas, to my też nie powinniśmy wysyłać do nich - takie info dla wszystkich naszych userów "ten adres jest zablokowany za spam" - aby wiedzieli z kim mają do czynienia.

Przykład tego pliku znajduje się w moim konfigu. Zawiera ogólnodostępną listę spamerów. Sami musicie sobie zbudować własną. Obecnie mam tą listę w postaci tabeli w bazie mysql - łatwiej się dodaje wpisy.

Co to jest RFC-ignorant i jaki to może mieć wpływ na nasz konfig.

Według RFC każda domena powinna mieć funkcjonujące 2 adresy email: postmaster@ i abuse@.
Funkcjonujące czyli można wysłać tam mejla i jakaś osoba go odbierze i przeczyta. Dlatego trzeba te adresy whitelistować:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
    check_helo_access hash:/etc/postfix/helo_checks,
    ...
    permit

w ten sposób poczta kierowana na adresy postmaster@ i abuse@ zawsze dojdzie, niezależnie od tego czy nadawca siedzi w RBLu, ma nieprawidłowe HELO, czy nadaje z Marsa.

Z Marsa to może i powinna dojść ale z takich Chin?

Moje statsy są wyraźne: około 30% spamu pochodzi z Chin. Tamtejsze Wszystkie abuse@ mają w 4 literach resztę świata. Zatem:

smtpd_client_restrictions =
    check_client_access cidr:/etc/postfix/client_checks,
#    reject_rbl_client chikor.rbl.tld,
    permit

Tutaj jest zamiast hash-a zastosowana baza cidr (wprowadzona dopiero w 2.1), są to IPki w formacie: 1.2.3.4/5, bardzo użyteczne jeżeli mamy blokować cały zakres IPków. Aby sprawdzić czy nasz postfix obsługuje mapę cidr mozna wykonać polecenie postconf -m.

Ze strony www.okean.com można było pobrać zakresy należące do Korei i Chin i wstawić do swojego pliku - obecnie strona nie działa.
Alternatywą jest RBL chikor.rbl.tld opisany w sąsiednim artykule "Własny serwer RBL"

Ważna uwaga: w stosunku do tych krajów jesteśmy rfc-ignorant, w zasadzie nie powinniśmy tak robić. Ja się jednak nie przejmuję.

Kilka słów o podszywaniu się

Aby zapobiec sytuacji w której z zewnątrz przychodzi przesyłka, która w polu from (na kopercie) ma adresy typu cośtam@moja.domena.tld należy umieścić listę własnych (!) domen na czarnej liście:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    ...
    check_sender_access hash:/etc/postfix/sender_checks_my,
    ...

a w pliku sender_checks_my umieszczamy pary:

moja.domena.tld        554 Wymagany jest login i haslo

Ważna uwaga: tą opcję należy umieścić tuż za reject_unauth_destination tak aby klient, który "zapomni" wysłać login i hasło dostał czytelny komunikat.

aby zaś zapobiec sytuacji kiedy jeden użytkownik może zalogować się na swoje konto, ale pocztę wysłać już z innego konta należy użyć:

smtpd_sender_restrictions =
    reject_unknown_sender_domain,
    reject_non_fqdn_sender,
    reject_unknown_address,
    reject_sender_login_mismatch,
    check_sender_access pcre:/etc/postfix/sender_checks.pcre
    reject_unauth_pipelining,
    permit

smtpd_sender_login_maps = hash:/etc/postfix/sender_login_maps

gdzie w pliku sender_login_maps należy umieścić pary

user@domena.tld       user@domena.tld

i to w dodatku należy umieścić tam wszystkich userów, bo jeżeli któryś nie wystąpi to będzie mógł wysyłać z każdego konta - ja obecnie trzymam wszystko w bazie danych, tak więc jest łatwiej tym zarządzać. 

Spamerzy mają soft, który nie przestrzega reguł

Normalny serwer SMTP wysyła linijkę z np. adresem mail i czeka na odpowiedź. Spamerskiego softu nie interesuje jaką odpowiedź dał nasz serwer - po prostu wysyłają to co mają do powiedzenia "jednym ciągiem". Na takich trzeba użyć opcji:

smtpd_*_restrictions =
    ...
    reject_unauth_pipelining,
    ...
    permit

Whitelistowanie

Jeżeli mamy nadawcę, który ma np. źle skonfigurowany serwer, albo często jego serwer ląduje w RBLach to warto zrobić whitelistę. Najlepiej niech whitelista zawiera adresy IP serwerów nadawcy, czyli niech będzie na przykład hashem /etc/postfix/whitelista:

1.2.3.4 OK

taką listę umieszczamy za reject_unath_destination a przed regułką, która powoduje odrzucanie (na przykład z powodu błędnego HELO) - dla przykładu:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_sender_access hash:/etc/postfix/sender_checks_my,
    check_client_access hash:/etc/postfix/whitelista,
    check_helo_access hash:/etc/postfix/helo_checks,
    check_helo_access pcre:/etc/postfix/helo_checks.pcre,
    reject_unknown_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_rbl_client dynamic.rbl.tld,
    reject_rhsbl_client revdns.rbl.tld,
    reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client sbl-xbl.spamhaus.org,
   permit

można też w ten sposób whitelistować adresy nadawców (check_sender_access hash:/etc/postfix/whitelista_senderow) lub zrobić whitelistę dla odbiorców (check_recipient_access hash:/etc/postfix/whitelista_odbiorcow), którzy nie życzą sobie filtrowania - powyżej jest opisane jak to zrobić dla adresów postmaster@, abuse@.

Należy jednak pamiętać, że spamerzy i wirusy łatwo fałszują adresy nadawców - lepszym zabezpieczeniem jest lista adresów IP.

Odrzucanie poczty od lamersko skonfigurowanych serwerów

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        ...
# odrzucamy dziwne MXy domeny nadawcy
        check_sender_mx_access cidr:/etc/postfix/mx_access.cidr,
        check_helo_mx_access cidr:/etc/postfix/mx_access.cidr,
        ...
        permit

plik mx_access.cidr zawiera:

0.0.0.0/8       REJECT mail server in broadcast network
10.0.0.0/8      REJECT mail server in RFC 1918 private network
127.0.0.0/8     REJECT mail server in loopback network
169.254.0.0/16  REJECT mail server in link local network
172.16.0.0/12   REJECT mail server in RFC 1918 private network
192.0.2.0/24    REJECT mail server in TEST-NET network
192.168.0.0/16  REJECT mail server in RFC 1918 private network
224.0.0.0/4     REJECT mail server in class D multicast network
240.0.0.0/5     REJECT mail server in class E reserved network
248.0.0.0/5     REJECT mail server in reserved network

Czemu tak? Jeżeli nasz użytkownik zechce odpisać nadawcy to nasz serwer będzie szukał serwera odbiorcy np. w swojej sieci lokalnej. Czyli przesyłka może pójść nie tam gdzie trzeba lub zostać po prostu opóźniona. Dodatkowo niektórzy postmasterzy ustawiają podczas DDOSu na ich domenę adres MXa 127.0.0.1.

Większość połączeń podszywających się pod "localhost" pochodzi z Indii - tam nawet revDNSy to localhost.

Anvil - konfiguracja dla bardzo małych serwerów

(postfix 2.2 i wyżej)

Spamerzy usiłują podczas jednego połączenia do serwera wysyłać spam metodą prób i błędów (zmieniając adres nadawcy) i rozesłać go do wszystkich userów w danej domenie (oczywiście nie chodzi o wielkości typu onet). U siebie obserwowałem w jednym połączeniu około 30 prób. Dlatego też bardzo prostym zabezpieczeniem jest użycie anvila i ograniczenie do:

1 jednoczesnych połączeń dla danego klienta:
smtpd_client_connection_count_limit = 1

2 połączeń na minutę (dokładnie na anvil_rate_time_unit)
smtpd_client_connection_rate_limit = 2
anvil_rate_time_unit = 60s

20 odbiorców na minutę:
smtpd_client_recipient_rate_limit = 20

20 wiadomości na minutę:
smtpd_client_message_rate_limit = 20

zerwanie połączenia po 2 błędach (np. user unknown)
smtpd_hard_error_limit = 2

po 2 błędach przytrzymanie klienta przez smtpd_error_sleep_time sekund:
smtpd_soft_error_limit = 2
smtpd_error_sleep_time = 30
nie polecam ustawiania smtpd_*_error_limit na 1, bo userzy często popełniają literówki i wtedy ich MUA muszą czekać 30s doprowadzając ich do białej gorączki (no i potem "serwer nie działa").

I w logach możemy zaobserwować:
warning: Connection concurrency limit exceeded: 31 from unknown[1.2.3.4] for service smtp

Taka konfiguracja jak powyżej sprawdza się dla małych serwerów, gdzie na przykład 10 userów z jednego IP w zdalnej sieci (zobacz smtpd_client_event_limit_exceptions) nie zechce naraz wysłać emaila. Dla większych serwerów trzeba to oczywiście stunigować sobie.

Jeżeli jakiś klient przekroczy limit dostanie komunikat "450 wróć później" i oczywiście spamerzy nie wracają później - podobnie jak w greylistingu.

header_checks

/^Content-(Type|Disposition):.*(file)?name=.*(\.|=2E)(ade|adp|bas|bat|chm|cmd|com|cpl|crt|hlp|hta|inf|ins|isp|js|jse|lnk|mde|msc|msi|msp|mst|pcd|pif|reg|scr|sct|shs|shb|vb|vbe|vbs|wsc|wsf|wsh|mim|b64|bhx|hqx|xxe|uu|uue)"/ REJECT Sorry, we do not accept .${4} file type.
/^Content-(Type|Disposition):.*(file)?name=.*\.([a-z]+\.exe)"/                  REJECT Sorry, we do not accept double extension .${3} file type.
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?196\.[0-9]+\.[0-9]+\.[0-9]+\]?/                             REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?82\.128\.([0-9]|[0-9][0-9]|1[0-1][0-9]|12[0-7])\.[0-9]+\]?/ REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?86\.62\.([0-9]|[0-6][0-9]|6[0-3])\.[0-9]+\]?/               REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?213\.136\.(9[6-9]|1[0-1][0-9]|12[0-7])\.[0-9]+\]?/          REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?81\.91\.2(2[4-9]|3[0-9])\.[0-9]+\]?/                        REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?41\.[0-9]+\.[0-9]+\.[0-9]+\]?/                              REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?213\.181\.(6[4-9]|[7-8][0-9]|9[0-5])\.[0-9]+\]?/            REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?87\.255\.(9[6-9]|10[0-7])\.[0-9]+\]?/                       REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?212\.52\.(12[8-9]|1[3-5][0-9])\.[0-9]+\]?/                  REJECT nigerian spam/scam/419 detected
/^(Received: from|X-Originating-IP:|OriginalSenderIP:|X-AOL-IP:) \[?83\.229\.([0-9]?[0-9]|1[0-1][0-9]|12[0-7])\.[0-9]+\]?/      REJECT nigerian spam/scam/419 detected

Przykład mojej konfiguracji

Przykładowe pliki konfiguracyjne można pobrać stąd.

Zawsze aktualny plik tld potrzebny do budowania własnego RBLa można pobrać stąd.
Jeżeli ktoś sobie życzy pobierać go automatycznie to są 2 sposoby:

• jakimś wgetem po http - proszę nie częściej niż raz na tydzień i prosiłbym się zgłosić do mnie to będę rozsyłał info o zmianach np. w położeniu pliku. 
• możecie mi udostępnić np. rsynca, scp dla mojego adresu IP to będę wrzucał na bieżąco po zmianach.
  

Kilka ważnych uwag

Przedstawiony konfig jest działającym konfigiem U MNIE. U kogoś innego może nie działać lub generować niepożądane skutki. Dlatego musicie wszystko sprawdzać 2 razy zanim wstawicie to do swoich konfigów. Przykładowo "insiders_only" (o czym jeszcze nie napisałem) wyrwane z kontekstu może narobić bardzo dużo szkód. Ponadto jeżeli używacie na raz wielu tutoriali to one mogą wchodzić sobie wzajemnie w paradę. Dlatego doradzam najpierw wygrać jeden tutorial, skończyć konfigurację według niego, przetestować a dopiero potem wklejać kolejne fragmenty z innych tutoriali.

Komentarze: