K-NET s.c.

Gmail SPF – jak ułatwić sobie życie

Jak powiadają rasowi sysadmini nie poznał życia kto nie administrował serwerem poczty – niezależnie czy sam czy za pomocą dużego dostawcy – wszędzie czekają pułapki jak chociażby rekord Gmail SPF. Całkiem niedawno oznaczało to budowanie serwera od podstaw. Można w tym celu bawić się Linuksem i rozwiązaniami typu iRedMail, które zdecydowanie polecam jako wieloletni użytkownik. Nie ma przeszkód aby bardzo ułatwić sobie zadanie i w oparciu o kontenery Dockera zainstalować mailcow. Można wreszcie skorzystać z Microsoft Exchange. Dla każdego coś się znajdzie.

Po instalacji serwera pocztowego dla wybranej domeny trzeba skonfigurować serwer DNS. Oprócz obligatoryjnych rekordów MX wskazujących podstawowy serwer pocztowy a także zapasowe jeśli jest taka potrzeba i możliwość warto pamiętać o kilku dodatkowych. We współczesnym świecie liczą się wszelkiego rodzaju zabezpieczenia.

Rekordem który chciałbym krótko opisać jest TXT pozwalający na zdefiniowanie protokołu SPF – Sender Policy Framework. Obecnie wiele serwerów sprawdza jego wartość i nie pozwala przyjąć wiadomości w przypadku błędów bądź braku tego wpisu. Generalnie nie jest to specjalnie trudna rzecz a w sieci można znaleźć dużo poradników na ten temat, czy nawet generatorów znacznie upraszczających sprawę.

Co jednak zrobić gdy zdecydowaliśmy się na skorzystanie z dużego dostawcy usług a nie budowanie własnego serwera? Czy mocny gracz na rynku zawsze będzie pamiętał o wszystkich szczegółach? W kontekście ustawień DNS niekoniecznie. Zwłaszcza jeżeli serwer nazw nie został zrealizowany za pomocą jego zasobów. Weźmy jako przykład usługi pocztowe Google.

Samo wykupienie skrzynek pocztowych Gmail dla naszej domeny firmowej lub jakiejkolwiek innej nie załatwi nam wspomnianych wpisów DNS, w szczególności Gmail SPF. Może się wydawać, że jest to dosyć niespotykany scenariusz użycia. W rzeczywistości jednak nierzadko firma posiada najpierw własny serwer pocztowy i własny serwer DNS a potem przenosi tylko usługę email na zewnątrz. Jeśli mamy do czynienia z taką sytuacją należy pamiętać aby zdefiniować koniecznie rekord TXT postaci

v=spf1 include:_spf.google.com ~all

Aż tyle i tylko tyle…. aby nie otrzymywać niespodziewanych telefonów od użytkowników z uwagami typu ”moja poczta nie dochodzi” a przecież o to w praktyce chodzi 🙂

MG

Eksport i import LDAP

Przez ostanich parę lat serwery poczty e-mail przeszły niemałą rewolucję. Jak dobrze pamiętam, kiedyś postawienie własnego MXa wiązało się z konkretną pracą. Mówiąc precyzyjniej zabezpieczeniem takiego serwera tak, aby nie był open-relayem, włączeniem wszystkich autoryzacji i np. przygotowaniem skrzynek z obsługą IMAP, LDAP itp. Obecnie można w miarę łatwo osiągnąć ten cel stosując dopracowane i wygodne w użyciu platformy, jak chociażby iRedMail. Jest to prawdą w odniesieniu do standardowych konfiguracji. Nie po to jednak mamy Linuxa aby zostawić rzeczy samym sobie i nie próbować zmieniać czy poprawiać konfiguracji, czytaj – dostosowywać do swoich potrzeb.

Przy rozbudowanych systemach, z obsługą dużej liczby skrzynek pocztowych, wygodną metodą jest przechowywanie konfiguracji w bazie danych. Osobiście preferuję w tym celu usługi katalogowe LDAP. Moim zdaniem są szybkie i niezawodne, a odpowiednio skonfigurowane bezpieczne. Wspomniany iRedMail pozwala na organizowanie warstwy logiki serwera pocztowego za pomocą LDAPa.

Świat nie stoi w miejscu i nawet jeżeli jako administratorzy mamy względny spokój, bo nikt od nas nie wymaga przenoszenia usługi pocztowej do nowego dostawcy lub na nowe serwery, to zawsze może się zdarzyć, że sami zostaniemy do tego zmuszeni, bo np. chcemy wymienić sprzęt (lub fizycznie nawet cały serwer). Oczywiście w najprostszym scenariuszu będzie się to wiązało z wykonaniem kopii zapasowej bazy LDAP a potem odtworzeniem jej na nowym węźle. No właśnie – w najprostszym, co się jednak stanie jeżeli musimy zmienić co nieco w naszej usłudze katalogowej.

Przykładem takiej ingerencji może być wymuszenie zmiany atrybutu Distinguished Name – DN. Dzieje się tak, gdy przenosimy jedną z obsługiwanych domen emailowych do całkowicie nowej struktury LDAP. W tym miejscu okazuje się jak wygodny i zarazem niewygodny potrafi być LDAP. Otóż dla jego doświadczonego użytkownika sprawa jest prosta i realizowana w 3 krokach:

• wyeksportuj starą bazę LDAP do pliku LDIF (format tekstowy, bez kompresji)
• wyedytuj dowolnym edytorem plik LDIF i wprowadź potrzebne zmiany
• zaimportuj plik LDIF do nowej bazy LDAP

I wszystko byłoby dobrze gdyby nie fakt, że w trakcie eksportu każdy wiersz pliku LDIF jest obcinany do 76 znaków a część nadmiarowa przenoszona ze spacją do nowej linii. Bardzo to utrudnia zastosowanie popularnej metody edycji Search and Replace, ponieważ wzorzec wyszukiwania nie jest jednoznaczny. Należy po prostu inteligentnie usunąć wszystkie miejsca łamiania wiersza.

Jeżeli dysponujemy Linuxem z jego wszelkiemi udogodnieniami i narzędziami to przepis jak to zrobić będzie prosty:

awk 'NR>1 && !sub(/^ /,""){print s; s=""} \ 
{s = s $0} END{print s}' stary.ldif > nowy.ldif

Potem pozostaje już tylko import atrybutów z wartościami do nowej bazy LDAP.

MG

DNSBL i Postfix

RBL, DNSBL o co w tym chodzi? Chociaż czasami poczta elektroniczna nie jest łatwa w konfiguracji to do tej pory, przynajmniej moim zdaniem, nie wymyślono lepszego zamiennika. Szczególnie jeśli mowa np. o korespondencji firmowej, oficjalnej itp. Będąc administratorem firmowego serwera pocztowego na pewno nie unikniemy walki ze spamem i temu chciałbym poświęcić ten wpis.

Wydawać by się mogło, że temat jest ponad miarę wyeksploatowany i w zasadzie nie ma nad czym się rozwodzić. Dlatego nie chcę się skupiać na instalacji i zabezpieczeniu serwera w całości. W końcu można do tego użyć chociażby pakietu iRedMail, który naprawdę polecam. Tym razem chcę pokazać jak ubić spam na wejściu, czyli na poziomie Postfixa, a jeszcze precyzyjniej na poziomie demona systemowego nierozerwalnie z nim związanego – mowa o Postscreen. Zwróćmy od razu uwagę, że taka konfiguracja nie wymaga instalacji np. Amavis i Spamassasin, co bywa pewnym wyzwaniem, zwłaszcza dla początkujących użtkowników.

Podstawą dla przytaczanego tutaj rozwiązania jest DNSBL, czyli czarna lista tworzona z pomocą DNS. Nie musimy tworzyć jej sami, możemy wykorzystać ogólnodostępne serwisy, które robią to dla nas. Z Postfixem bardzo dobrze komponują się dwa z nich – Spamhaus oraz BarracudaCentral. W tym miejscu należy wspomnieć, że Spamhaus ma ograniczenie do 100.000 połączeń na dzień. Zakładam jednak, że mówimy o normalnym serwerze pocztowym dla średniej firmy, więc raczej nie powinniśmy przekroczyć 100.000 maili przychodzących z zewnątrz dziennie.

Ostatecznie uzbrojenie w powyższą wiedzę możemy przystąpić do konfiguracji Postfixa, która jak zwykla jest dosyć prosta. 🙂

Skonfigurowanie obsługi DNSBL wymaga wyedytowania pliku /etc/postfix/main.cf i dodaniu parametrów do opcji postscreen_dnsbl_sites:

postscreen_dnsbl_sites =
  zen.spamhaus.org*2
  b.barracudacentral.org*2

Liczba na końcu parametru jest wagą, która powoduje podbicie punktacji.

Sugerowaną konfiguracją jest również korzystanie z lokalnego serwera cache DNS. Może to być dowolny pakiet. Przy dużym natężeniu ruchu przychodzącego zdecydowanie przyspiesza działanie usługi pocztowej:

postscreen_dnsbl_sites =
  zen.spamhaus.org=127.0.0.[2..11]*2
  b.barracudacentral.org=127.0.0.2*2

Ostanim parametrem, którego wartość warto rozważyć jest postscreen_dnsbl_action. Zazwyczaj jest ona ustawiona na enforce, co oznacza przekazanie do dalszego przetwarzania. Czasami jednak warto jest ubić wszystkie niechciane połączenia:

postscreen_dnsbl_action = drop

Po zapisaniu nowej konfiguracji Postfixa, musimy ponwnie uruchomić serwis.

MG

Postfix main.cf czyli kolejność ma jednak znaczenie

Przez wiele lat konfigurowałem rozmaite serwery poczty opierając się o sprawdzony serwer Postfix w tandemie z Debianem. Były to konfiguracje bardzo proste, średnio złożone i takie, które wymagają posiedzenia nad problemem dłużej. Wykorzystywałem Postfix natywnie i w połączeniu z gotowymi skryptami (np. polecanym iRedMail). Przyznam, że nigdy nie zawiódł i wydawał się być dość prosty w obsłudze przy jednocześnie rozbudowanych opcjach ustawień. Do czasu aż trafiłem na problem, który zatrzymał mnie w miejscu na parę godzin. O co chodzi? Otóż w każdej sieci znajdzie się urządzenie, komputer, router może termometr IP, które będzie chciało wysyłać emaile z komunikatami. I zazwyczaj mają one wbudowaną obsługę autoryzacji dla połączeń SMTP. Jedna raz na jakiś czas trafi się egzamplarz, który za żadne skarby świata nie potrafi się kulturalnie przedstawić naszemu Postfixowi. Wówczas nie pozostaje nic innego jak zrobić małe obejście i dopuścić urządzenie do wysyłania emaili bez żadnych ograniczeń. Wiem, że nie powinniśmy tak nigdy robić ale czasem trzeba. W Postfixie służy do tego opcja (na przykładzie adresu 10.10.10.10):

mynetworks = 127.0.0.1 10.10.10.10

która spowoduje, że wymienione po kolei hosty stają się uprzywilejowane. Czy zawsze to zadziała? W tym właśnie tkwi sedno sprawy, że nie! Otóż jeżeli w naszej konfiguracji stosujemy różne ograniczenia (a jak wspomniałem Postfix jest bogaty w możliwości) czyli np. zastosujemy dyrektywę smtpd_recipient_restrictions to kolejność jej atrybutów zaczyna mieć znaczenie. Czyli np. kod:

smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient

jest prawidłowy bo atrybut permit_mynetworks jest pierwszy na liście. Jednak ten sam kod zapisany:

smtpd_recipient_restrictions =
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient
  permit_mynetworks

jest już nieprawidłowy bo kolejność ma jednak duże znaczenie. Reguła ta obowiązuje dla wszystkich dyrektyw, dla których możemy użyć atrybutu permit_mynetworks.

MG

ClamAV-clamd av-scanner FAILED

Całkiem niedawno instalowałem po raz kolejny serwer poczty dla klienta. Niestety wsparcie dla mojego ulubionego Debiana Squeeze skończyło się w kwietniu tego roku dlatego postanowiłem od razu pominąć dystrybucje Wheezy i skorzystać z Jessie. W jednym ze wcześniejszych wpisów podałem adres bardzo dobrego poradnika, który omawiał jak niewielkim kosztem przygotować bardzo wydajną i sprawną bramkę mailową typu Antivirus/Antispam. Świat idzie szybko do przodu i okazało się, że poradnik już nie jest dostępny. Co więcej autor poleca skorzystanie ze skryptów iRedMail. Skrypty skryptami, niby rozwiązanie wygodne i szybkie ale co ma zrobić administrator przyzwyczajony do konfigurowania wszystkiego ręcznie? Przez wiele lat nagromadziłem własne gotowe pliki konfiguracyjne i nie bardzo uśmiechało mi się przeglądanie gotowców z iRedMail. Dlatego postanowiłem sprawdzić co pozmieniało się w stosunku do informacji (konfiguracji) które już posiadam i jednak zbudować serwer poczty od początku na własną ręke. Musze przyznać, że zmian było stosunkowo niewiele. Oczywiście niektóre repozytoria wygasły a w ich miejsce pojawiły się inne. Miłą niespodzianką okazała się na przykład dostępność w podstawowym repo pakietu clamav-unofficial-sigs, o czy zupełnie nie wiedziałem i zawsze instalowałem “z palca”. W trakcie instalacji trafiłem jednak na spory problem. Coś co do tej pory działało niezawodnie, nagle w Jessie przestało funkcjonować prawidłowo. Chodzi o pakiet Clamav, który zaczał zgłaszać błędy:

... run_av (ClamAV-clamd) FAILED ...
... ClamAV-clamd av-scanner FAILED ...
... WARN: all primary virus scanners failed, considering backups...

Sprawa wyglądała dość poważnie bo dotyczyła jednego z kluczowych elementów każdego systemu pocztowego. Jak zwykle w takich sytuacjach rozwiązanie okazało się dość banalne. W pliku konfiguracyjnym /etc/clamav/clamd.conf, w dystrybucji Jessie zmieniła się jedna linijka. Wygląda ona obecnie tak:

AllowSupplementaryGroups false

a powinna wyglądać jak w poprzednich dystrybucjach, czyli:

AllowSupplementaryGroups true

I to wszystko.

MG