Chroń Zimbra OSE przed brutalną siłą i atakami DoS

Zimbra Collaboration Suite Open-Source Edition zawiera kilka potężnych narzędzi zapewniających bezpieczeństwo informacji. Pomiędzy nimi Po ekranie - rozwiązanie chroniące serwer pocztowy przed atakami botnetów, ClamAV - program antywirusowy potrafiący skanować przychodzące pliki i listy pod kątem infekcji złośliwymi programami, a także SpamAssassin - jeden z najlepszych obecnie filtrów spamu. Jednakże narzędzia te nie są w stanie chronić Zimbra OSE przed atakami typu brute-force. Niezbyt eleganckie, ale wciąż dość skuteczne, brutalne wymuszanie haseł przy użyciu specjalnego słownika jest obarczone nie tylko prawdopodobieństwem udanego włamania ze wszystkimi wynikającymi z tego konsekwencjami, ale także utworzeniem znacznego obciążenia serwera, który przetwarza wszystkie nieudane próby włamania się do serwera za pomocą Zimbra OSE.

Chroń Zimbra OSE przed brutalną siłą i atakami DoS

Zasadniczo możesz uchronić się przed brutalną siłą, korzystając ze standardowych narzędzi Zimbra OSE. W ustawieniach polityki bezpieczeństwa haseł możesz ustawić liczbę nieudanych prób wprowadzenia hasła, po których potencjalnie zaatakowane konto zostanie zablokowane. Głównym problemem takiego podejścia jest to, że powstają sytuacje, w których konta jednego lub większej liczby pracowników mogą zostać zablokowane w wyniku ataku brute-force, na który nie mają oni nic wspólnego, a wynikające z tego przestoje w pracy pracowników mogą przynieść duże straty Firma. Dlatego najlepiej nie korzystać z tej opcji ochrony przed brutalną siłą.

Chroń Zimbra OSE przed brutalną siłą i atakami DoS

Do ochrony przed brutalną siłą znacznie lepiej nadaje się specjalne narzędzie o nazwie DoSFilter, które jest wbudowane w Zimbra OSE i może automatycznie zakończyć połączenie z Zimbra OSE poprzez HTTP. Innymi słowy, zasada działania DoSfilter jest podobna do zasady działania PostScreen, tyle że jest używana dla innego protokołu. Pierwotnie zaprojektowany, aby ograniczyć liczbę działań, które może wykonać pojedynczy użytkownik, DoSFilter może również zapewnić ochronę przed brutalną siłą. Jej zasadniczą różnicą w stosunku do narzędzia wbudowanego w Zimbrę jest to, że po określonej liczbie nieudanych prób nie blokuje samego użytkownika, a adres IP, z którego następuje wielokrotna próba zalogowania się na dane konto. Dzięki temu administrator systemu może nie tylko zabezpieczyć się przed brutalną siłą, ale także uniknąć blokowania pracowników firmy, po prostu dodając sieć wewnętrzną swojej firmy do listy zaufanych adresów IP i podsieci.

Dużą zaletą DoSFilter jest to, że oprócz licznych prób zalogowania się na dane konto, za pomocą tego narzędzia można automatycznie blokować tych atakujących, którzy wzięli w posiadanie dane uwierzytelniające pracownika, a następnie pomyślnie zalogowali się na jego konto i rozpoczęli wysyłanie setek żądań do serwera.

Możesz skonfigurować DoSfilter za pomocą następujących poleceń konsoli:

  • zimbraHttpDosFilterMaxRequests na sek — Za pomocą tego polecenia możesz ustawić maksymalną liczbę połączeń dozwolonych dla jednego użytkownika. Domyślnie ta wartość wynosi 30 połączeń.
  • zimbraHttpDosFilterDelayMillis - Za pomocą tego polecenia możesz ustawić opóźnienie w milisekundach dla połączeń, które przekroczą limit określony w poprzednim poleceniu. Oprócz wartości całkowitych administrator może podać 0, aby w ogóle nie było opóźnienia, oraz -1, aby wszystkie połączenia przekraczające określony limit były po prostu przerywane. Wartość domyślna to -1.
  • zimbraHttpThrottleSafeIPs — Za pomocą tego polecenia administrator może określić zaufane adresy IP i podsieci, które nie będą podlegały ograniczeniom wymienionym powyżej. Należy pamiętać, że składnia tego polecenia może się różnić w zależności od pożądanego rezultatu. A więc na przykład wpisując polecenie zmprov mcf zimbraHttpThrottleSafeIPs 127.0.0.1, całkowicie nadpiszesz całą listę i pozostawisz w niej tylko jeden adres IP. Jeśli wpiszesz polecenie zmprov mcf +zimbraHttpThrottleSafeIPs 127.0.0.1, wprowadzony adres IP zostanie dodany do białej listy. Podobnie, używając znaku odejmowania, możesz usunąć dowolny adres IP z listy dozwolonych.

Należy pamiętać, że DoSFilter może powodować wiele problemów podczas korzystania z rozszerzeń Zextras Suite Pro. Aby ich uniknąć, zalecamy zwiększyć liczbę jednoczesnych połączeń z 30 do 100 za pomocą polecenia zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec 100. Ponadto zalecamy dodanie sieci wewnętrznej przedsiębiorstwa do listy dozwolonych. Można to zrobić za pomocą polecenia zmprov mcf +zimbraHttpThrottleSafeIPs 192.168.0.0/24. Po wprowadzeniu jakichkolwiek zmian w DoSFilter pamiętaj o ponownym uruchomieniu serwera pocztowego za pomocą polecenia zmmailboxdctl uruchom ponownie.

Główną wadą DoSFilter jest to, że działa na poziomie aplikacji i dlatego może jedynie ograniczyć zdolność atakujących do wykonywania różnych działań na serwerze, nie ograniczając możliwości połączenia się z północą. Z tego powodu żądania wysyłane do serwera w celu uwierzytelnienia lub wysłania listów, choć oczywiście zakończą się niepowodzeniem, nadal będą stanowić stary, dobry atak DoS, którego nie da się zatrzymać na tak wysokim poziomie.

Aby całkowicie zabezpieczyć swój serwer firmowy za pomocą Zimbra OSE, możesz skorzystać z rozwiązania takiego jak Fail2ban, czyli frameworka, który może na bieżąco monitorować logi systemu informatycznego pod kątem powtarzających się działań oraz blokować intruza poprzez zmianę ustawień zapory ogniowej. Blokowanie na tak niskim poziomie pozwala na zablokowanie atakujących już na etapie połączenia IP z serwerem. Tym samym Fail2Ban może doskonale uzupełniać ochronę zbudowaną przy użyciu DoSfilter. Dowiedzmy się, jak możesz połączyć Fail2Ban z Zimbra OSE i tym samym zwiększyć bezpieczeństwo infrastruktury IT Twojego przedsiębiorstwa.

Jak każda inna aplikacja klasy korporacyjnej, Zimbra Collaboration Suite Open-Source Edition prowadzi szczegółowe dzienniki swojej pracy. Większość z nich jest przechowywana w folderze /opt/zimbra/log/ w formie plików. Oto tylko kilka z nich:

  • mailbox.log — Dzienniki usługi poczty Jetty
  • audyt.log - logi uwierzytelniania
  • clamd.log — dzienniki działania programu antywirusowego
  • Freshclam.log - logi aktualizacji programu antywirusowego
  • konwertowane.log — logi konwertera załączników
  • zimbrastats.csv - logi wydajności serwera

W pliku można również znaleźć dzienniki Zimbry /var/log/zimbra.log, gdzie przechowywane są logi Postfixa i samej Zimbry.

Będziemy monitorować, aby chronić nasz system przed brutalną siłą skrzynka pocztowa.log, Dziennik kontroli и Zimbra.log.

Aby wszystko działało konieczne jest zainstalowanie Fail2Ban i iptables na Twoim serwerze z Zimbra OSE. Jeśli używasz Ubuntu, możesz to zrobić za pomocą poleceń dpkg -s błąd2ban, jeśli używasz CentOS, możesz to sprawdzić za pomocą poleceń mniam, zainstalowano listę Fail2ban. Jeśli nie masz zainstalowanego Fail2Ban, jego instalacja nie będzie stanowić problemu, ponieważ ten pakiet jest dostępny w prawie wszystkich standardowych repozytoriach.

Po zainstalowaniu całego niezbędnego oprogramowania możesz rozpocząć konfigurowanie Fail2Ban. W tym celu należy utworzyć plik konfiguracyjny /etc/fail2ban/filter.d/zimbra.conf, w którym napiszemy wyrażenia regularne dla logów Zimbra OSE, które będą pasować do błędnych prób logowania i uruchamiać mechanizmy Fail2Ban. Oto przykład zawartości pliku zimbra.conf z zestawem wyrażeń regularnych odpowiadających różnym błędom, które generuje Zimbra OSE, gdy próba uwierzytelnienia nie powiedzie się:

# Fail2Ban configuration file
 
[Definition]
failregex = [ip=<HOST>;] account - authentication failed for .* (no such account)$
                        [ip=<HOST>;] security - cmd=Auth; .* error=authentication failed for .*, invalid password;$
                        ;oip=<HOST>;.* security - cmd=Auth; .* protocol=soap; error=authentication failed for .* invalid password;$
                        ;oip=<HOST>;.* security - cmd=Auth; .* protocol=imap; error=authentication failed for .* invalid password;$
                        [oip=<HOST>;.* SoapEngine - handler exception: authentication failed for .*, account not found$
                        WARN .*;ip=<HOST>;ua=ZimbraWebClient .* security - cmd=AdminAuth; .* error=authentication failed for .*;$

ignoreregex =

Po skompilowaniu wyrażeń regularnych dla Zimbra OSE czas rozpocząć edycję konfiguracji samego Fail2ban. Ustawienia tego narzędzia znajdują się w pliku /etc/fail2ban/jail.conf. Na wszelki wypadek zróbmy jego kopię zapasową za pomocą polecenia cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.bak. Następnie zredukujemy ten plik do mniej więcej następującej postaci:

# Fail2Ban configuration file
 
[DEFAULT]
ignoreip = 192.168.0.1/24
bantime = 600
findtime = 600
maxretry = 5
backend = auto
 
[ssh-iptables]
enabled = false
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, [email protected], [email protected]]
logpath = /var/log/messages
maxretry = 5
 
[sasl-iptables]
enabled = false
filter = sasl
backend = polling
action = iptables[name=sasl, port=smtp, protocol=tcp]
sendmail-whois[name=sasl, [email protected]]
logpath = /var/log/zimbra.log
 
[ssh-tcpwrapper]
enabled = false
filter = sshd
action = hostsdeny
sendmail-whois[name=SSH, dest=support@ company.ru]
ignoreregex = for myuser from
logpath = /var/log/messages
 
[zimbra-account]
enabled = true
filter = zimbra
action = iptables-allports[name=zimbra-account]
sendmail[name=zimbra-account, [email protected] ]
logpath = /opt/zimbra/log/mailbox.log
bantime = 600
maxretry = 5
 
[zimbra-audit]
enabled = true
filter = zimbra
action = iptables-allports[name=zimbra-audit]
sendmail[name=Zimbra-audit, [email protected]]
logpath = /opt/zimbra/log/audit.log
bantime = 600
maxretry = 5
 
[zimbra-recipient]
enabled = true
filter = zimbra
action = iptables-allports[name=zimbra-recipient]
sendmail[name=Zimbra-recipient, [email protected]]
logpath = /var/log/zimbra.log
bantime = 172800
maxretry = 5
 
[postfix]
enabled = true
filter = postfix
action = iptables-multiport[name=postfix, port=smtp, protocol=tcp]
sendmail-buffered[name=Postfix, [email protected]]
logpath = /var/log/zimbra.log
bantime = -1
maxretry = 5

Chociaż ten przykład jest dość ogólny, warto wyjaśnić niektóre parametry, które możesz chcieć zmienić podczas samodzielnej konfiguracji Fail2Ban:

  • Ignoruj — za pomocą tego parametru możesz określić konkretny adres IP lub podsieć, z której Fail2Ban nie powinien sprawdzać adresów. Z reguły sieć wewnętrzna przedsiębiorstwa i inne zaufane adresy są dodawane do listy ignorowanych.
  • Bantime — Czas, na jaki sprawca zostanie ukarany zakazem. Mierzone w sekundach. Wartość -1 oznacza stały ban.
  • Maxretry — Maksymalna liczba prób uzyskania dostępu do serwera przez jeden adres IP.
  • Wyślij maila — Ustawienie umożliwiające automatyczne wysyłanie powiadomień e-mail po uruchomieniu Fail2Ban.
  • Znaleźć czas — Ustawienie umożliwiające ustawienie przedziału czasu, po którym adres IP może próbować ponownie uzyskać dostęp do serwera po wyczerpaniu maksymalnej liczby nieudanych prób (parametr maxretry)

Po zapisaniu pliku z ustawieniami Fail2Ban pozostaje jedynie zrestartować to narzędzie za pomocą polecenia ponowne uruchomienie usługi Fail2ban. Po ponownym uruchomieniu główne logi Zimbry zaczną być stale monitorowane pod kątem zgodności z wyrażeniami regularnymi. Dzięki temu administrator będzie mógł praktycznie wyeliminować możliwość przedostania się atakującego nie tylko do skrzynek pocztowych Zimbra Collaboration Suite Open-Source Edition, ale także chronić wszystkie usługi działające w ramach Zimbra OSE, a także mieć świadomość wszelkich prób uzyskania nieautoryzowanego dostępu .

W przypadku wszystkich pytań związanych z Zextras Suite, możesz skontaktować się z przedstawicielem Zextras Ekaterina Triandafilidi przez e-mail [email chroniony]

Źródło: www.habr.com

Dodaj komentarz