E-mail na stałe zagościł jako standard komunikacji biznesowej. Dzięki wysokiej efektywności ekonomicznej e-maili oraz pewnym cechom związanym z cytowaniem tekstu i załączaniem plików, e-maile idealnie nadają się do wymiany dokumentów oraz grzecznej komunikacji biznesowej. Te same cechy sprawiły, że e-mail stał się ulubionym narzędziem spammerów. W rezultacie, dziś e-mail to ogromny, burzliwy ocean spamu, w którym tylko od czasu do czasu pojawiają się wiadomości biznesowe. Dlatego jednym z najważniejszych zadań administratora każdego serwera pocztowego jest ochrona przed spamem. Przyjrzyjmy się, co można zrobić z tym problemem w Zimbra Collaboration Suite Open-Source Edition.
Pomimo, że Zimbra OSE jest darmowym rozwiązaniem, potrafi dostarczyć administratorowi systemu mnóstwo bardzo skutecznych narzędzi do radzenia sobie z problemem niechcianych wiadomości. Już pisaliśmy o takich narzędziach jak Amavis, SpamAssassin, ClamAV i cbpolicyd, które pozwalają na niezawodne filtrowanie przychodzącej poczty, eliminując spam, a także zainfekowane i phishingowe wiadomości. Niemniej jednak, ich główną wadą jest to, że wszystkie działają na już odebranych wiadomościach e-mail, zużywając zasoby systemowe na filtrację bezużytecznych wiadomości, które zawsze można wykorzystać w lepszy sposób. Ale co, jeśli Twoje przedsiębiorstwo znalazło się pod ostrzałem dużego botnetu, który regularnie bombarduje Twój serwer pocztowy tak ogromnymi ilościami spamowych wiadomości, że tylko ich filtrowanie zajmuje znaczną część mocy serwera MTA?
Teoretycznie można się przed tym ochronić, korzystając z usługi chmurowej do filtrowania przychodzącej poczty, jednak w praktyce taki sposób zabezpieczenia nie pasuje do każdego przedsiębiorstwa, ponieważ w takim przypadku konieczne byłoby zaufanie osobom trzecim do przetwarzania nie tylko spamu, ale i korespondencji służbowej, co nie zawsze jest bezpieczne, a często wręcz sprzeczne z polityką bezpieczeństwa firmy. Dodatkowo pojawiają się ryzyko związane z niezawodnością działania chmurowego filtra spamu. Rozwiązaniem tej sytuacji może być zorganizowanie ochrony serwera we własnym zakresie. Specjalnie w tym celu w Zimbrze wbudowana została narzędzie Postscreen, które ma na celu ochronę serwera pocztowego przed wiadomościami wysyłanymi przez botnety, nie obciążając przy tym serwera pocztowego.
Istota działania Postscreen polega na tym, że to narzędzie przegląda wszystkie żądania połączenia z serwerem pocztowym serwera i nie pozwala na połączenie się z serwerem tym klientom, którzy wydają się jej podejrzani. Ponieważ zgodnie z statystyką około 90% spamu na świecie jest rozsyłane przez botnety, Postscreen często jest używane jako pierwsza linia obrony serwera pocztowego przed niechcianymi wiadomościami reklamowymi. Dzięki temu serwer pocztowy może stabilnie działać bez przeciążeń nawet w warunkach silnych ataków spamowych ze strony dużych botnetów.
Zasada działania Postscreen jest dość prosta, narzędzie jest w stanie przeprowadzić szereg podstawowych kontroli wchodzących wiadomości przed ich przekazaniem do serwera pocztowego lub innych usług, które przeprowadzają głębszą i bardziej szczegółową analizę przychodzących wiadomości. Każda z kontroli może zostać pozytywnie lub negatywnie zakończona. Na podstawie wyników każdej z kontroli Postscreen może zastosować jedną z trzech akcji według wyboru administratora Zimbry: Odrzuć, Ignoruj lub Wymuś. Akcja Odrzuć wymusza zerwanie połączenia z klientem w przypadku, gdy kontrola nie została ukończona, akcja Ignoruj pozwala ignorować wyniki kontroli przy podejmowaniu ostatecznej decyzji, ale przy tym zbierać informacje i statystyki na temat przeprowadzanych kontroli, a akcja Wymuś pozwala uwzględniać wyniki przeprowadzonych kontroli przy podejmowaniu ostatecznej decyzji, ale przy tym kontynuuje wykonywanie wszystkich testów zaplanowanych przez administratora systemu.
Prosty zasada działania wcale nie oznacza łatwości w użyciu i konfiguracji. Chodzi o to, że niewłaściwie skonfigurowany Postscreen może być przyczyną, dla której szereg ważnych wiadomości dla firmy nie dotrze do odbiorcy. Dlatego do konfiguracji tak potężnego narzędzia jak Postscreen należy podchodzić z dużą ostrożnością i stale testować jego działanie w różnych sytuacjach.
Postscreen w Zimbrze jest włączony domyślnie, jednak wielu może nie satysfakcjonować początkowa konfiguracja. Teraz omówimy najlepszą pod względem bezpieczeństwa oraz minimalizacji ryzyka opcję konfiguracji Postscreen. Istotą jego działania jest to, że po niepowodzeniu którejkolwiek z kontroli, Postscreen nie zerwie bez rozmowy połączenia z klientem, ale przeprowadzi wszystkie kontrole do końca, a w przypadku ich niepowodzenia wyświetli komunikat o błędzie. Umożliwi to powiadomienie żywego nadawcy o niedostarczeniu wiadomości, jeśli Postscreen uzna ją za spam. Osiąga się to przez ustawienie wartości enforce w parametrach przeprowadzania kontroli. To właśnie ta wartość pozwala na zakończenie rozpoczętych kontrol do końca, bez zrywania połączenia z klientem przy pierwszym niepowodzeniu, ale po ich zakończeniu mimo to zablokować wiadomość ze spamem, nie dostarczając jej na serwer.
Aby włączyć potrzebne kontrole, należy wpisać następujące polecenia:
zmprov mcf zimbraMtaPostscreenDnsblSites ‘b.barracudacentral.org=127.0.0.2*7’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[10;11]*8’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.[4..7]*6’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.3*4’ zimbraMtaPostscreenDnsblSites ‘zen.spamhaus.org=127.0.0.2*3’
To polecenie umożliwia dodanie kontroli DNS połączeń przychodzących do dwóch najpopularniejszych publicznych baz spamowych oraz ocenę wiadomości w zależności od tego, w której z baz znajdzie się adres nadawcy. Im więcej karanych „gwiazdek” zbierze klient, tym bardziej prawdopodobne, że jest spamerem.
zmprov mcf zimbraMtaPostscreenDnsblAction enforce
To polecenie określa działanie, które jest podejmowane w wyniku przeprowadzenia kontroli DNS. W tym przypadku wynik kontroli zostaje zapamiętany, a sama wiadomość przechodzi dalsze testy.
zmprov mcf zimbraMtaPostscreenGreetAction enforce
Ponieważ w protokole SMTP, po nawiązaniu połączenia, serwer jako pierwszy rozpoczyna komunikację z klientem, Postscreen może wysłać powitanie do klienta. Dzięki temu, że wiele klientów spamowych, nie czekając na zakończenie powitania, zaczyna wysyłać polecenia, można je łatwo rozpoznać. To polecenie pozwala uwzględnić wyniki tej kontroli, ale jednocześnie kontynuować dalsze testy.
zmprov mcf zimbraMtaPostscreenNonSmtpCommandAction drop
W ramach tej kontroli Postscreen pozwala na odfiltrowanie tych połączeń, które nie pochodzą od klientów poczty. Ponieważ nie wysyłają żadnych wiadomości, można je bez obaw odłączyć od serwera.
zmprov mcf zimbraMtaPostscreenPipeliningAction enforce
Ta kontrola opiera się na tym, że w protokole SMTP klient może domyślnie wysłać tylko jedno polecenie na raz i następnie oczekiwać na odpowiedź serwera na to polecenie. Jednak wiele botów spamowych zachowuje się inaczej, wysyłając wiele poleceń, nie czekając na odpowiedź od serwera. To pozwala praktycznie bezbłędnie zidentyfikować bota spamowego.
W zasadzie te kontrole będą więcej niż wystarczające, aby odfiltrować główną masę botów spamowych z serwera i osiągnąć znaczne zmniejszenie obciążenia serwera pocztowego. Żywi ludzie otrzymają informację, że ich wiadomość nie została dostarczona, co znacznie zmniejsza ryzyko utraty ważnych wiadomości z powodu ustawień Postscreen. W przypadku, gdy to miało miejsce, można dodać zaufanego nadawcę do białej listy Postscreen. Aby tworzyć białe i czarne listy Postscreen, najpierw należy stworzyć plik /opt/zimbra/conf/postfix/postscreen_wblist.
Do którego dodamy listę dozwolonych i zabronionych adresów IP oraz podsieci w formacie CIDR. Na przykład zablokujemy podsieć 121.144.169.*, ale zezwolimy na połączenie jedynemu adresu IP z tej podsieci:
# Rules are evaluated in the order as specified.
# Blacklist 121.144.169.* except 121.144.169.196.
121.144.169.196/32 zezwól
121.144.169.0/24 odrzuć
Zwracamy uwagę na ważność kolejności wpisów. Chodzi o to, że Postscreen będzie skanował plik z białymi i czarnymi listami do pierwszego dopasowania, a jeśli zablokowana podsieć będzie stała przed dozwolonym adresem IP, to kontrola po prostu nie dojdzie do wpisu, że dany adres IP został dodany do białej listy i połączenie z serwerem nie nastąpi.
Po edytowaniu i zapisaniu pliku z białymi i czarnymi listami, można włączyć odpowiednie sprawdzenie za pomocą następujących poleceń:
zmprov mcf zimbraMtaPostscreenAccessList «permit_mynetworks, cidr: /opt/zimbra/conf/postfix/postscreen_wblist»
zmprov mcf zimbraMtaPostscreenBlacklistAction enforce
Teraz Postscreen, obok wcześniej ustawionych przez nas kontroli, będzie również odnosił się do pliku z białymi i czarnymi listami, co pozwoli administratorowi stosunkowo łatwo rozwiązywać problemy z brakiem możliwości połączenia z serwerem zaufanych nadawców.
Źródło: habr.com
