Walka ze spamem cz.3 – Postfix DMARC

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email validation system designed to detect and prevent email spoofing. It provides a mechanism which allows a receiving organization to check that incoming mail from a domain is authorized by that domain’s administrators and that the email (including attachments) has not been modified during transport – Wikipedia

 

Wpis ten jest kontynuacją postów dotyczących walki ze spamem, poprzednio skonfigurowaliśmy SPF oraz DKIM, korzystaliśmy z serwera postfix-a, którzy uwcześnie skonfigurowaliśmy.

 

Zainstalujmy paczkę, która będzie niezbędna:

#debian/ubuntu
apt-get install opendmarc

Skonfigurujmy nowo zainstalowany soft:

#vim /etc/opendmarc.conf

AuthservID mail.example.com
PidFile /var/run/opendmarc.pid #Debian default
RejectFailures false
Syslog true
TrustedAuthservIDs mail.example.com,mail2.example.com
UMask 0002
UserID opendmarc:opendmarc
IgnoreHosts /etc/opendmarc/ignore.hosts
HistoryFile /var/run/opendmarc/opendmarc.dat
#w celu debugowania można dodać poniższą linię ale wyłączymy ją potem
SoftwareHeader true

To nie wszystko

mkdir /etc/opendmarc/

Dodajmy hosty, których nie skanujemy – nas ?!

#vim /etc/opendmarc/ignore.hosts

localhost
adress_ip_naszego_serwera

Zakładając, że korzystaliście z poprzednich wpisów na porcie 12301 posiadamyt DKIM, więc śmiało możemy dla DMARC wykorzystać port 54321:

#vim /etc/default/opendmarc
...
SOCKET="inet:54321@localhost"
...

Możemy uruchomić opendmarc, przy okazji sprawdzają czy nie mamy typo 🙂 lub czy coś nie siedzi na wybranym przez nas porcie:

/etc/init.d/opendmarc start

 

Powiadommy postfixa, że chcemy korzystać z kolejnego rozwiązania dla wyłapywania spamu:

#vim /etc/postfix/main.cf

...
smtpd_milters=inet:localhost:12345,inet:localhost:54321
non_smtpd_milters=inet:localhost:12345,inet:localhost:54321
...

Pamiętajmy, że pierwsza pozycja obu wpisów dotyczy DKIM, a druga naszego DMARC-a 🙂

Zrestartujmy postfixa, niech biedak już nie czeka na nowy config 😉

/etc/init.d/postfix reload

 

Jako, że DMARC korzysta z DKIM i SPF, musimy mieć odpowiedni wpis DNS, w internecie jest pełno „wizardów”, które wygenerują wam wpis ja polecam takowy:

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=0; adkim=r; aspf=r; pct=100; rf=afrf; ri=86400"

 

Teoretycznie można by tutaj zakończyć, jednak pełna implementacja DMARC wymaga generowania i wysyłania raportów – o czym administratorzy zapominają.

#vim /usr/share/doc/opendmarc/schema.mysql
...
CREATE USER 'opendmarc'@'localhost' IDENTIFIED BY 'changeme';
GRANT ALL ON opendmarc.* to 'opendmarc'@'localhost';
...

Wpis ten widnieje w pliku ale jest zakomentowany, dzięki niemu utworzony zostanie użytkownik opendmarc, jego hasło oraz baza 🙂

Wczytajmy schemat:

mysql -u root -p < schema.mysql

Utwórzmy skrypt do  generowania raportów:

#vim /etc/opendmarc/report_script

#!/bin/bash

DB_SERVER='database.example.com'
DB_USER='opendmarc'
DB_PASS='password
DB_NAME='opendmarc'
WORK_DIR='/var/run/opendmarc'
REPORT_EMAIL='dmarc@example.com'
REPORT_ORG=example.com'

mv ${WORK_DIR}/opendmarc.dat ${WORK_DIR}/opendmarc_import.dat -f
cat /dev/null > ${WORK_DIR}/opendmarc.dat

/usr/sbin/opendmarc-import --dbhost=${DB_SERVER} --dbuser=${DB_USER} --dbpasswd=${DB_PASS} --dbname=${DB_NAME} --verbose < ${WORK_DIR}/opendmarc_import.dat
/usr/sbin/opendmarc-reports --dbhost=${DB_SERVER} --dbuser=${DB_USER} --dbpasswd=${DB_PASS} --dbname=${DB_NAME} --verbose --interval=86400 --report-email $REPORT_EMAIL --report-org $REPORT_ORG
/usr/sbin/opendmarc-expire --dbhost=${DB_SERVER} --dbuser=${DB_USER} --dbpasswd=${DB_PASS} --dbname=${DB_NAME} --verbose

Sam skrypt na niewiele się zda jeżeli nie bedzie wykonywał się w harmonogramie:

chmod +x /etc/opendmarc/report_script

#przetestujmy skrypt zanim dodamy go do crona
su -c "/etc/opendmarc/report_script" -s /bin/bash opendmarc

#vim /etc/crontab

1 0 * * * opendmarc /etc/opendmarc/report_script

 

Warto było by przeglądać maile z raportami jakie wysyłamy do innych administratorów korzystających z DMARC-a, zrobimy to poprzez mały wpis do postfixa:

#vim /etc/postfix/main.cf

...
sender_bcc_maps = hash:/etc/postfix/bcc_map
...

#vim /etc/postfix/bcc_map
dmarc@example.com mailboxforbcc@example.com


postmap /etc/postfix/bcc_map

Jeszcze tylko restart postfix-a, w celu wczytania nowego configa:

/etc/init.d/postfix restart

 

W celu przetestowania naszego nowego narzędzia możemy wysłać na inną skrzynkę maila testowego (mail musi być na zewnątrz naszego serwera, ale także musi obsługiwać DMARC np. gmail).

W nagłówku powinniśmy widzieć wpis od DMARCu. Jeżeli już skończymy testy pamiętajmy o usunięciu wpisu z config-a, który był dodany w celu testu:

#vim /etc/opendmarc.conf

#SoftwareHeader true

Szybki restart:

/etc/init.d/opendmarc restart

 

 

W ten sposób ludzie otrzymujący maile z domeny, która obsługujesz powinni mieć pewność, że maile są legalne 🙂

 

Pozostałe wpisy dotyczące tego cyklu:

Posftix i Dovecot – Idealny duet tworzący serwer poczty

Walka ze spamem cz.1 – Postfix SPF

Walka ze spamem cz.2 – Postfix DKIM

Walka ze spamem cz.4 – Postfix SpamAssassin

Walka ze spamem cz.5 – Dovecot Sieve

15 myśli na “Walka ze spamem cz.3 – Postfix DMARC”

  1. Witam,

    dzięki za wyczerpującą konfigurację. Jest jednak jeden problem:

    warning: connect to Milter service inet:localhost:54321: Connection refused

    Jest na to jakieś rozwiązanie ?

    1. z jakiej dystrybucji korzystasz ?
      co mówi o procesie
      `/etc/init.d/opendmarc status`
      dodatkowo upewnij się, że zmodyfikowałeś listę serwerów:
      `TrustedAuthservIDs mail.example.com,mail2.example.com` tu powinien być wpisany twoj serwer poczty

      1. doprecyzuj proszę pojęcie „twój serwer poczty”. Bo jeśli to serwer dla wielu domen, to mamy wpisać wszystkie domeny?

        1. `TrustedAuthservIDs mail.example.com,mail2.example.com`

          zamiast mail.example.com wpisujesz swojego hosta ze swojej domeny od poczty. Serwer może obsługiwać wiele domen, możesz po przecinku wypisywać wszystkie serwery poczty, które sa aktualnie na tym samym hoście/serwerze

  2. Dzięki wielkie. Przechodzi wszystkie testy. <3

    Wcześniej korzystałem z artykułów na Linode i DigitalOcean.

  3. Działa, ale co z tego skoro praktycznie nikt nie bierze pod uwagę tych usług. identyczny efekt uzyskuje się stosują podstawowy SPF. właśnie zrezygnowałem z DMARC, DKIM… pozostaję przy podstawowym SPF.
    PS: Testowałem około 4 lat (czy ma się wdrożony DMARC, DKIM czy nie… nic to nie zmienia). Na logikę daje to praktycznie tyle samo co SPF.

    1. Nie zgodzę się z Tobą. Tzn. tak możesz nie korzystać z DMARC/DKIM i wszystko będzie w najlepszym porządku, ale zdecydowanie warto ustawić te funkcje gdyż zaniżają one scoring w SpamAssassinie, zdecydowanie rzadziej mail z Twojej domeny wpada do spamu. Jest to także dobra i zdrowa praktyka.
      Także monopoliści wprowadzają (np. google) ostrzeżenia w skrzynkach emailowych, że mail z Twojej nie podpisanej domeny nie jest bezpieczny (tutaj musisz sam wyważyć czy będzie Tobie to przeszkadzać czy nie).

      Na szczęści raz skonfigurowany może leżeć sobie jakiś dłuższy czas (do dmarc-a są dedykowane narzędzie, które odczytują raporty i na ich podstawie proponują reguły, ale nikt Ci głowy nie oberwie za to że masz go cały czas w trybie raportowania, ważne, że jest)

      1. W mojej ocenie DMARC i DMKI nie szkodzi, ale także niczego nowego i dobrego nie dodało, popularność zyskało chyba tylko dzięki google (gdyby nie google nikt prawdopodobnie by nie wiedział co to takiego). Czy taki MTA z DKIM i DMARC jest lepszy niż taki, na którym jest jedynie SPF ? te 2 usługi to tak wyglądają jak na siłę skomplikowany SPF bo google tak sobie chce. 80% administratorów nie wie nawet jak to poprawnie konfigurować 🙂 serio. Proszę tego nie odbierać jako hejt, to tylko moje zdanie.

        1. Cyt: Na szczęści raz skonfigurowany może leżeć sobie jakiś dłuższy czas (do dmarc-a są dedykowane narzędzie, które odczytują raporty i na ich podstawie proponują reguły, ale nikt Ci głowy nie oberwie za to że masz go cały czas w trybie raportowania, ważne, że jest)

          regułach można ustawić politykę na none, reject, quarantine. Przeważnie wszyscy mają to gdzieś bo wiedzą, że to nic nie daje i politykę ustawią na none.

          Dowody:
          _dmarc.wp.pl descriptive text „v=DMARC1; p=none; rua=mailto:dmarc-reports@wp.pl”
          _dmarc.onet.pl descriptive text „v=DMARC1; p=none; rua=mailto:dmarc-reports@onet.pl; ruf=mailto:dmarc-reports@onet.pl”
          _dmarc.interia.pl descriptive text „v=DMARC1; p=none; rua=mailto:dmarc.reports@interia.pl; ruf=mailto:dmarc.reports@interia.pl”

          Nawet google ustawiło sobie politykę tak:
          _dmarc.gmail.com descriptive text „v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com”

          _dmarc.google.com descriptive text „v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com”

          1. I tak i nie. Scoring jest jaki jest, jedni używają DMARKu przy skoringu inni nie. Oczywiście są serwery, które przepuszczają wszystkie spoofowane maile, są takie które nie zezwalają na wysyłkę z innego IP niż wskazany.
            _dmarc.gmail.com. 14 IN TXT „v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com”
            _dmarc.google.com. 300 IN TXT „v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com”
            sp – to subdomeny, czyli mimo, że google nie odrzuca maili na głównej domenie, odrzuca je dla wszystkich subdomen – co też jest zabezpieczeniem.

            Niestety, monopoliści wymuszają stosowanie mechanizmów, ale sami od siebie tego nie dokońca wymagają, ale w przypadku googla może być to też związane z rozbudowanym systemem poczty – może jakieś konflikty ? może farmy tak szybko się zmieniają? Tego nie wiem, wiem natomiast, że niejednokrotnie maile z czystej instalacji postfixa, z tylko spf, lubiły bbaaardzo lądować w SPAMie, a DMARK/DKIM jak za pomocą czarodziejskiej różdźki, magicznie „wyciągał” następne maile ze spamu (także u googla).

            Obciążenie na serwer nieistniejące, zagrożenie z działaniem usługi lokalnie minimalne, benefity wyraźnie widoczne. Czy uchroni to Nas przed spoofingiem, spamem, phishingiem? Absolutnie NIE! Czy poprawi nam skoring w systemach antyspamowych niektórych odbiorców ? zdecydowanie tak.

  4. Cyt:
    Obciążenie na serwer nieistniejące, zagrożenie z działaniem usługi lokalnie minimalne, benefity wyraźnie widoczne. Czy uchroni to Nas przed spoofingiem, spamem, phishingiem? Absolutnie NIE! Czy poprawi nam skoring w systemach antyspamowych niektórych odbiorców ? zdecydowanie tak.
    ————————————————-
    Tak czy siak nic nie zastąpi Spamassassin + RBL + SPF + PROCMAIL + konfiguracja ze zrozumieniem a nie ta domyślna…
    Do postfixa napisałem sobie jeszcze daemona, który dba o stosowne limity i inne bzdety.

  5. Jakieś forum mógłbyś zrobić, można by podyskutować o takich sprawach.
    takie forum liberalne, aby nikt do nikogo nie miał spin (bo każdy powinien mieć własne zdanie)
    Pozdrawiam 😀

    1. Fora… oh jak ja za wami tęskie… teraz tylko Discord aka „lepszy irc”… na chwilę obecną wstrzymałem się z migracją z WP więc chociaż sekcja komentarzy jest 🙂
      SA + RBL + SPF zdecydowanie procmail – chętnie zobacze z czym to się je 🙂 i może zaczne stosować. Jeszcze gdzieś migneło mi coś lepszego niż SA, ale teraz za chiny nie pamiętam jak się nazywało.

      Kusisz mnie Krzysztof, aż chciało by się kupić VPS postawić coś znowu od zera.

      1. Polecam 🙂 Ja mam vpsa w ovh, wszytko sam robię, poczta i www działa po IPv4 jak i IPv6. Miesięcznie kosztuje mnie to kokło 20zł + domena raz w roku :D. Serwer na debianie, satysfakcja gwarantowana 😀 certyfikaty od LetsEncrypt dla poczty i www.

        1. PS: Ja to mam jeszcze tak fajnie porobione, że mi procmail segreguje maile, spam do takiego folderu, mailing do innego, aliexpress do innego… itp 😀

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

*