Mail bombing to jedna z najstarszych form cyberataków. W swojej istocie przypomina zwykły atak DoS, z tą różnicą, że zamiast fali żądań z różnych adresów IP, na serwer wysyłana jest lawina e-maili, które w ogromnych ilościach trafiają na jeden z adresów pocztowych, co znacząco zwiększa obciążenie. Taki atak może prowadzić do niemożności korzystania z skrzynki pocztowej, a czasami może nawet doprowadzić do awarii całego serwera. Wieloletnia historia tego rodzaju cyberataków przyniosła szereg pozytywnych i negatywnych skutków dla administratorów systemów. Wśród pozytywnych aspektów należy wymienić dobrą znajomość mail bombingu oraz istnienie prostych metod ochrony przed takim atakiem. Wśród negatywnych można wskazać na dużą liczbę ogólnodostępnych rozwiązań programowych do przeprowadzania tego typu ataków oraz możliwość dla cyberprzestępców na skuteczną ochronę przed wykryciem.
Nie mniej ważną cechą tego cyberataku jest to, że praktycznie niemożliwe jest przekształcenie go w zysk. Cóż z tego, że cyberprzestępca skieruje na jeden z adresów pocztowych lawinę e-maili, pozostawiając ofiarę bez możliwości korzystania z poczty elektronicznej, czy włamał się do czyjejś poczty firmowej i masowo wysyła tysiące wiadomości przez GAL, przez co serwer się zawiesił lub zaczął działać tak wolno, że korzystanie z niego stało się niemożliwe, a co dalej? Przekształcanie takiego cyberprzestępstwa w realne pieniądze jest prawie niemożliwe, dlatego mail bombing obecnie jest dość rzadkim zjawiskiem i administratorzy systemów projektując infrastrukturę mogą po prostu nie pamiętać o konieczności ochrony przed tego rodzaju cyberatakami.
Niemniej jednak, pomimo że mail bombing sam w sobie jest dość bezsensowną czynnością z komercyjnego punktu widzenia, często stanowi część innych, bardziej złożonych i wieloetapowych ataków cybernetycznych. Na przykład, w przypadku włamania na konto e-mail i jego wykorzystania do przejęcia konta w jakiejś publicznej usłudze, przestępcy często "bombardują" skrzynkę pocztową ofiary bezsensownymi wiadomościami, aby wiadomość z potwierdzeniem zgubiła się w ich strumieniu i pozostała niezauważona. Mail bombing może być również stosowany jako środek ekonomicznego nacisku na przedsiębiorstwo. Aktywne bombardowanie publicznej skrzynki e-mail przedsiębiorstwa, na którą wpływają zgłoszenia od klientów, może poważnie utrudnić pracę z nimi i, w konsekwencji, doprowadzić do przestojów w działaniu sprzętu, niewykonanych zamówień, a także utraty reputacji i utraconych zysków.
Dlatego doświadczony administrator systemów nie powinien zapominać o możliwości przeprowadzenia mail bombingu i zawsze podejmować konieczne środki ochrony przed tym zagrożeniem. Biorąc pod uwagę, że można to zrobić jeszcze na etapie budowy infrastruktury pocztowej, a także to, że zajmuje to administratorowi systemu bardzo niewiele czasu i wysiłku, nie ma obiektywnych powodów, aby nie zapewnić swojej infrastrukturze ochrony przed mail bombingiem. Przyjrzyjmy się, jak zabezpieczenia przed tym atakiem cybernetycznym są realizowane w Zimbra Collaboration Suite Open-Source Edition.
Podstawą Zimbry jest Postfix – jeden z najbardziej niezawodnych i funkcjonalnych agentów transferu poczty typu Mail Transfer Agent z otwartym źródłem obecnie. Jedną z głównych zalet jego otwartości jest to, że wspiera najróżniejsze zewnętrzne rozwiązania dla rozszerzenia funkcjonalności. W szczególności, Postfix w pełni wspiera cbpolicyd – zaawansowane narzędzie do zapewnienia cyberbezpieczeństwa serwera pocztowego. Oprócz ochrony przed spamem i tworzenia list białych, czarnych i szarych, cbpolicyd pozwala administratorowi Zimbry skonfigurować weryfikację podpisu SPF oraz ustalić ograniczenia dotyczące odbioru i wysyłania wiadomości email lub danych. Mogą one zarówno zapewnić solidną ochronę przed spamem i wiadomościami phishingowymi, jak i chronić serwer przed mail bombingiem.
Pierwszą rzeczą, której będzie potrzebował administrator systemu, jest aktywacja modułu cbpolicyd, który jest preinstalowany w Zimbra Collaboration Suite OSE na serwerze MTA w infrastrukturze. Można to zrobić za pomocą polecenia zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd. Następnie należy aktywować interfejs webowy, aby móc wygodnie zarządzać cbpolicyd. W tym celu trzeba zezwolić na połączenia na porcie webowym numer 7780, utworzyć dowiązanie symboliczne za pomocą polecenia ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, a następnie edytować plik z ustawieniami za pomocą polecenia nano /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, gdzie należy wpisać następujące linie:
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="root";
$DB_TABLE_PREFIX="";
Po tym wystarczy tylko zrestartować usługi Zimbra i Zimbra Apache za pomocą poleceń zmcontrol restart i zmapachectl restart. Po tym uzyskasz dostęp do interfejsu webowego pod adresem :7780/webui/index.php. Głównym aspektem jest to, że logowanie do tego interfejsu webowego nie jest obecnie w żaden sposób zabezpieczone, dlatego aby uniknąć dostępu osób trzecich, można po każdym logowaniu do interfejsu webowego po prostu zamknąć połączenia na porcie 7780.
Ograniczenia w wysyłaniu wiadomości e-mail wychodzących z sieci wewnętrznej można ustawić dzięki systemowi cbpolicyd. Takie ograniczenia pozwalają ustalić maksymalną liczbę wiadomości, która może być wysyłana z jednego konta e-mail w jednostce czasu. Na przykład, jeśli menedżerowie twojej firmy średnio wysyłają 60-80 wiadomości e-mail na godzinę, to, biorąc pod uwagę niewielki zapas, można ustawić im limit na 100 wiadomości e-mail na godzinę. Aby wyczerpać taki limit, menedżerowie będą musieli wysyłać jedną wiadomość co 36 sekund. Z jednej strony to wystarczające, aby prowadzić normalną działalność, a z drugiej strony, z takim limitem, napastnicy, którzy uzyskali dostęp do skrzynki jednego z twoich menedżerów, nie będą mogli przeprowadzić tzw. mail-bombingu ani masowej akcji spamowej w firmie.
Aby ustawić takie ograniczenie, należy w interfejsie webowym utworzyć nową politykę ograniczenia wysyłania wiadomości e-mail i wskazać, że ma ona działać zarówno dla wiadomości wysyłanych wewnątrz domeny, jak i dla wiadomości kierowanych do adresów zewnętrznych. Można to zrobić w następujący sposób:
Po tym można bardziej szczegółowo określić ograniczenia związane z wysyłaniem wiadomości e-mail, w szczególności ustalić przedział czasowy, po którym ograniczenia będą aktualizowane, a także wiadomość, którą otrzyma użytkownik, który przekroczy swój limit. Następnie można ustawić samo ograniczenie na wysyłanie wiadomości e-mail. Można je określić zarówno jako liczbę wychodzących wiadomości, jak i liczbę bajtów przesyłanych informacji. Przy tym z wiadomościami, które są wysyłane ponad wyznaczony limit, należy postępować na różne sposoby. Na przykład, można je po prostu natychmiast usunąć, a można je zachować, aby zostały wysłane od razu po aktualizacji limitu wysyłania wiadomości. Z drugiej opcji można skorzystać podczas ustalania optymalnej wartości limitu wysyłania wiadomości e-mail przez pracowników.
Oprócz ograniczeń dotyczących wysyłania wiadomości, cbpolicyd pozwala na ustawienie limitu na odbieranie wiadomości. Takie ograniczenie, na pierwszy rzut oka, wydaje się doskonałym rozwiązaniem w celu ochrony przed spamowaniem, jednak w rzeczywistości wprowadzenie takiego limitu, nawet dużego, wiąże się z tym, że w określonych warunkach ważna wiadomość może do Ciebie nie dotrzeć. Dlatego włączenie jakichkolwiek ograniczeń dla poczty przychodzącej jest zdecydowanie niezalecane. Jeśli jednak zdecydujesz się zaryzykować, do ustawienia limitu wiadomości przychodzących należy podchodzić ze szczególną uwagą. Na przykład, można ograniczyć liczbę przychodzących wiadomości od zaufanych kontrahentów, aby w przypadku, gdy ich serwer pocztowy został skompromitowany, nie przeprowadzano ataków spamowych na Twoją firmę.
Aby zabezpieczyć się przed napływem wiadomości przychodzących w przypadku spamowania, administrator systemu powinien podjąć bardziej inteligentne działania niż proste ograniczenie poczty przychodzącej. Takim rozwiązaniem może być użycie szarych list. Ich działanie polega na tym, że przy pierwszej próbie dostarczenia wiadomości od nieznanego nadawcy, połączenie z serwerem zostaje natychmiast przerwane, co sprawia, że dostarczenie wiadomości kończy się niepowodzeniem. Jednak, jeśli w określonym czasie nieznany serwer ponownie podejmuje próbę wysłania tej samej wiadomości, serwer nie przerywa połączenia i jej dostarczenie przebiega pomyślnie.
Sens wszystkich tych działań polega na tym, że programy do automatycznej masowej wysyłki e-maili zwykle nie sprawdzają powodzenia dostarczenia wysłanej wiadomości i nie podejmują prób jej ponownej wysyłki, podczas gdy człowiek z pewnością upewni się, czy jego wiadomość została wysłana pod dany adres, czy nie.
Można również włączyć szare listy w interfejsie webowym cbpolicyd. Aby wszystko działało, należy utworzyć politykę, która obejmowałaby wszystkie przychodzące wiadomości skierowane do użytkowników na naszym serwerze, a następnie na podstawie tej polityki utworzyć regułę Greylisting, w której można skonfigurować interwał, w którym cbpolicyd będzie oczekiwał na powtórną odpowiedź od nieznanego nadawcy. Zazwyczaj wynosi on 4-5 minut. Jednocześnie szare listy można skonfigurować tak, aby wszystkie udane i nieudane próby dostarczenia wiadomości od różnych nadawców były brane pod uwagę, a na podstawie ich liczby podejmowane była decyzja o automatycznym dodaniu nadawcy do białej lub czarnej listy.
Zwracamy uwagę, że do korzystania z szarych list należy podchodzić z maksymalną odpowiedzialnością. Najlepiej będzie, jeśli stosowanie tej technologii będzie szło w parze z ciągłym prowadzeniem białych i czarnych list, aby wykluczyć możliwość utraty naprawdę ważnych dla przedsiębiorstwa wiadomości.
Ponadto, ochronę przed mail-bombingiem może pomóc zapewnić dodanie kontroli SPF, DMARC i DKIM. Często wiadomości, które przychodzą podczas mail-bombingu, nie przechodzą takich kontroli. O tym, jak to zrobić, pisano już wcześniej. .
W ten sposób ochrona przed taką groźbą jak mail-bombing jest dość prosta i można ją zrealizować już na etapie budowy infrastruktury Zimbra dla Twojego przedsiębiorstwa. Ważne jest jednak, aby stale monitorować, aby ryzyko związane z używaniem takiej ochrony nigdy nie przewyższało uzyskiwanych przez Ciebie korzyści.
Źródło: habr.com
