Zimbra Collaboration Suite Open-Source Edition dysponuje wieloma potężnymi narzędziami do zapewnienia bezpieczeństwa informacji. Należą do nich — rozwiązanie chroniące serwer pocztowy przed atakami ze strony botnetów, ClamAV — program antywirusowy, który może skanować przychodzące pliki i wiadomości pod kątem złośliwego oprogramowania, a także — jeden z najlepszych filtrów antyspamowych dostępnych dzisiaj. Jednak te narzędzia nie są w stanie zapewnić ochrony Zimbra OSE przed atakiem brute force. Choć nie jest to najbardziej eleganckie rozwiązanie, próbowanie odgadnięcia haseł przy użyciu specjalnych słowników nadal stanowi skuteczny sposób, który nie tylko zwiększa ryzyko udanego włamania z tego wszystkiego wynikających konsekwencji, ale także generuje znaczne obciążenie serwera, który obsługuje wszystkie nieudane próby złamania zabezpieczeń Zimbra OSE.
Zasadniczo, można zabezpieczyć się przed atakami brute force standardowymi środkami Zimbra OSE. Ustawienia polityki bezpieczeństwa haseł pozwalają określić liczbę nieudanych prób wprowadzenia hasła, po których potencjalnie zagrożone konto zostaje zablokowane. Głównym problemem takiego podejścia jest to, że mogą wystąpić sytuacje, w których konta jednego lub kilku pracowników mogą zostać zablokowane z powodu ataku brute force, z którym nie mają nic wspólnego, co może spowodować przestoje w pracy pracowników i przynieść firmie znaczne straty. Dlatego taki sposób ochrony przed brute forcem najlepiej unikać.
Aby chronić się przed atakami brute force, znacznie lepszym rozwiązaniem jest specjalne narzędzie o nazwie DoSFilter, które jest zintegrowane z Zimbra OSE i może automatycznie przerywać połączenia z Zimbra OSE przez HTTP. Innymi słowy, zasada działania DoSFilter jest podobna do zasady działania PostScreen, różni się jednak protokołem. Początkowo zaprojektowane do ograniczenia liczby działań, jakie może wykonać jednego użytkownika, DoSFilter może również zapewnić ochronę przed atakami brute force. Jego kluczową różnicą w porównaniu do wbudowanego narzędzia w Zimbra jest to, że po określonej liczbie nieudanych prób blokuje nie użytkownika, lecz adres IP, z którego dokonywane są liczne próby logowania do określonego konta. Dzięki temu administrator systemu może nie tylko ochronić się przed atakami brute force, ale także uniknąć blokowania pracowników firmy, dodając wewnętrzną sieć swojego przedsiębiorstwa do listy zaufanych adresów IP i podsieci.
Dużą zaletą DoSFilter jest to, że poza licznymi próbami logowania do określonego konta, za pomocą tego narzędzie można automatycznie zablokować tych intruzów, którzy zdobyli dane uwierzytelniające pracownika, a następnie pomyślnie logowali się na jego konto i zaczęli wysyłać setki zapytań do serwera.
Skonfigurować DoSFilter można przy pomocy następujących poleceń konsolowych:
- zimbraHttpDosFilterMaxRequestsPerSec — Za pomocą tego polecenia można ustawić maksymalną liczbę połączeń dozwolonych dla jednego użytkownika. Domyślnie ta wartość wynosi 30 połączeń.
- zimbraHttpDosFilterDelayMillis — Za pomocą tego polecenia można ustawić opóźnienie w milisekundach dla połączeń, które będą przekraczać wcześniej określony limit. Oprócz wartości całkowitych administrator może określić 0, aby nie było opóźnienia, oraz -1, aby wszystkie połączenia przekraczające ustalony limit były po prostu przerywane. Domyślnie ta wartość wynosi -1.
- zimbraHttpThrottleSafeIPs — Za pomocą tego polecenia administrator może określić zaufane adresy IP i podsieci, na które nie będą miały zastosowania wyżej wymienione ograniczenia. Należy zauważyć, że składnia tego polecenia może się różnić w zależności od oczekiwanego rezultatu. Na przykład, wprowadzając polecenie zmprov mcf zimbraHttpThrottleSafeIPs 127.0.0.1, całkowicie nadpiszesz całą listę i pozostawisz tylko jeden adres IP. Jeśli wprowadzisz polecenie zmprov mcf +zimbraHttpThrottleSafeIPs 127.0.0.1, wprowadzony adres IP zostanie dodany do białej listy. Podobnie, używając znaku minus, można usunąć dowolny adres IP z listy dozwolonych.
Należy zauważyć, że DoSFilter może powodować szereg problemów podczas korzystania z rozszerzeń Zextras Suite Pro. Aby ich uniknąć, zalecamy zwiększenie liczby równoczesnych połączeń z 30 do 100 za pomocą polecenia zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec 100. Ponadto zalecamy dodanie wewnętrznej sieci 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 należy koniecznie zrestartować serwer pocztowy za pomocą polecenia zmmailboxdctl restart.
Główną wadą DoSFilter jest to, że działa na poziomie aplikacji, a zatem może jedynie ograniczyć możliwości atakujących w zakresie wykonywania różnych działań na serwerze, nie ograniczając jednocześnie możliwości łączenia się z serwerem. W związku z tym zapytania wysyłane do serwera w celu uwierzytelnienia lub wysyłania wiadomości, chociaż będą z góry skazane na porażkę, nadal będą stanowić starą dobrą atak DoS, której zatrzymanie na tak wysokim poziomie jest niemożliwe.
Aby całkowicie zabezpieczyć swój serwer korporacyjny z Zimbra OSE, można skorzystać z takiego rozwiązania jak Fail2ban, które jest ramą zdolną do ciągłego monitorowania logów systemów informacyjnych na podstawie powtarzających się działań i blokowania naruszycieli poprzez zmianę ustawień zapory. Blokada na tak niskim poziomie pozwala na wyłączanie atakujących już na etapie połączenia IP z serwerem. W ten sposób Fail2Ban może doskonale uzupełnić zabezpieczenia zbudowane za pomocą DoSFilter. Dowiedzmy się, jak można połączyć Fail2Ban z Zimbra OSE i tym samym zwiększyć bezpieczeństwo infrastruktury IT w Twoim przedsiębiorstwie.
Jak każde inne aplikacja klasy korporacyjnej, Zimbra Collaboration Suite Open-Source Edition prowadzi szczegółowe logi swojej pracy. Większość z nich jest przechowywana w folderze /opt/zimbra/log/ w formie plików. Oto tylko kilka z nich:
- mailbox.log — logi usługi pocztowej Jetty
- audit.log — logi uwierzytelniania
- clamd.log — dzienniki pracy oprogramowania antywirusowego
- freshclam.log — dzienniki aktualizacji oprogramowania antywirusowego
- convertd.log — dzienniki konwertera załączników
- zimbrastats.csv — dzienniki wydajności serwera
Dzienniki Zimbra można również znaleźć w pliku /var/log/zimbra.log, w którym zapisane są dzienniki pracy Postfixa i samej Zimbry.
Aby chronić nasz system przed atakiem brute force, będziemy monitorować mailbox.log, audit.log i zimbra.log.
Aby wszystko działało, musisz mieć zainstalowane Fail2Ban i iptables na swoim serwerze z Zimbra OSE. Jeśli używasz Ubuntu, możesz to zrobić za pomocą poleceń dpkg -s fail2ban, jeśli używasz CentOS, możesz to sprawdzić za pomocą poleceń yum list installed fail2ban. Jeśli Fail2Ban nie jest zainstalowane, jego instalacja nie będzie problemem, ponieważ ten pakiet znajduje się praktycznie we wszystkich standardowych repozytoriach.
Po zainstalowaniu niezbędnego oprogramowania można przystąpić do konfiguracji Fail2Ban. W tym celu należy stworzyć plik konfiguracyjny /etc/fail2ban/filter.d/zimbra.conf, w którym zapisujemy wyrażenia regularne dla dzienników Zimbra OSE, które będą odpowiadać błędnym próbom logowania i uruchamiać mechanizmy Fail2Ban. Oto przykład zawartości zimbra.conf z zestawem wyrażeń regularnych odpowiadających różnym błędom zgłaszanym w Zimbra OSE podczas nieudanej próby uwierzytelnienia:
# 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 sporządzeniu wyrażeń regularnych dla Zimbra OSE, nadszedł czas, aby przejść do edycji 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 przekształcimy ten plik w mniej więcej następujący sposób:
# 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, dest=admin@company.ru, sender=fail2ban@company.ru]
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, dest=support@company.ru]
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, dest=support@company.ru ]
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, dest=support@company.ru]
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, dest=support@company.ru]
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, dest=support@company.ru]
logpath = /var/log/zimbra.log
bantime = -1
maxretry = 5Ten przykład, choć dość uniwersalny, wymaga wyjaśnienia niektórych parametrów, które być może zechcesz zmienić podczas ustawiania Fail2Ban samodzielnie:
- Ignoreip — za pomocą tego parametru można określić konkretny adres IP lub podsieć, adresy z której Fail2Ban nie powinno sprawdzać. Zazwyczaj do listy ignorowanych dodawana jest wewnętrzna sieć przedsiębiorstwa oraz inne zaufane adresy.
- Bantime — Czas, na który naruszający będzie zbanowany. Mierzony jest w sekundach. Wartość -1 oznacza ban bezterminowy.
- Maxretry — Maksymalna liczba prób, które jeden adres IP może wykonać, aby uzyskać dostęp do serwera.
- Sendmail — Ustawienie, które automatycznie wysyła powiadomienia e-mail o aktywacji Fail2Ban.
- Findtime — Ustawienie, które pozwala określić czas oczekiwania, po którym adres IP może ponownie próbować uzyskać dostęp do serwera po wyczerpaniu maksymalnej liczby nieudanych prób (parametr maxretry).
Po zapisaniu pliku konfiguracyjnego Fail2Ban, wystarczy zrestartować to narzędzie używając polecenia service fail2ban restart. Po ponownym uruchomieniu główne logi Zimbra będą stale monitorowane pod kątem dopasowania do wyrażeń regularnych. Dzięki temu administrator będzie mógł faktycznie wykluczyć wszelkie możliwości wniknięcia intruza nie tylko do skrzynek pocztowych Zimbra Collaboration Suite Open-Source Edition, ale także chronić wszystkie działające w ramach Zimbra OSE usługi oraz być na bieżąco z wszelkimi próbami nieautoryzowanego dostępu.
Wszelkie pytania dotyczące Zextras Suite można kierować do przedstawiciela firmy „Zextras” Ekateriny Triandafiliidi pod adresem e-mail katerina@zextras.com
Źródło: habr.com
