В принципе, защититься от брутфорса можно стандартными средствами Zimbra OSE. Настройки парольной политики безопасности позволяют установить число неудачных попыток ввода пароля, после которых потенциально атакуемый аккаунт блокируется. Главной проблемой такого подхода заключается в том, что возникают ситуации, при которых учетные записи одного или нескольких работников могут оказаться заблокированными из-за брутфорс-атаки, к которой они не имеют никакого отношения, а возникший простой в работе сотрудников может принести компании большие убытки. Именно поэтому такой вариант защиты от брутфорса лучше всего не применять.
Для защиты от брутфорса гораздо лучше подойдет специальный инструмент под названием DoSFilter, который встроен в Zimbra OSE и может автоматически прерывать соединение c Zimbra OSE по HTTP. Иными словами, принцип работы DoSFilter аналогичен принципу работы PostScreen, только используется для другого протокола. Изначально призванный ограничивать количество действий, которое может совершать один пользователей, DoSFilter также может обеспечить защиту от брутфорса. Ключевое его отличие от встроенного в Zimbra инструмента заключается в том, что после определенного количества неудачных попыток он блокирует не самого пользователя, а IP-адрес, с которого предпринимаются множественные попытки войти в ту или иную учетную запись. Благодаря этому, системный администратор может не только защититься от брутфорса, но и избежать блокировки сотрудников предприятия, просто добавив в список доверенных IP-адресов и подсетей внутреннюю сеть своего предприятия.
Большим плюсом DoSFilter является то, что помимо многочисленных попыток войти в ту или иную учетную запись, с помощью данного инструмента можно автоматически заблокировать тех злоумышленников, которые завладели аутентификационными данными сотрудника, а затем успешно вошли в его учетную запись и начали посылать на сервер сотни запросов.
Настроить DoSFilter можно при помощи следующих консольных команд:
- zimbraHttpDosFilterMaxRequestsPerSec — При помощи этой команды можно задать максимальное количество подключений, допускаемое для одного пользователя. По умолчанию это значение составляет 30 подключений.
- zimbraHttpDosFilterDelayMillis — При помощи этой команды можно задать задержку в миллисекундах для соединений, которые будут превышать заданный предыдущей командой лимит. Помимо целочисленных значений, администратор может указать 0, чтобы задержки не было вовсе, а также -1, чтобы все подключения, которые превышают заданный лимит, просто прерывались. По умолчанию это значение составляет -1.
- zimbraHttpThrottleSafeIPs — При помощи этой команды администратор может указать доверенные IP-адреса и подсети, на которые не будут действовать перечисленные выше ограничения. Отметим, что синтаксис этой команды может меняться в зависимости от желаемого результата. Так, например, введя команду zmprov mcf zimbraHttpThrottleSafeIPs 127.0.0.1, вы полностью перезапишете весь список и оставите в нем всего один IP-адрес. Если же вы введете команду zmprov mcf +zimbraHttpThrottleSafeIPs 127.0.0.1, то в белый список добавится введенный вами IP-адрес. Аналогичным образом, используя знак вычитания, можно удалить какой-либо IP из списка разрешенных.
Отметим, что DoSFilter может создавать ряд проблем при использовании расширений Zextras Suite Pro. Для того, чтобы их избежать, рекомендуем повысить число одновременных подключений с 30 до 100 при помощи команды zmprov mcf zimbraHttpDosFilterMaxRequestsPerSec 100. Кроме того, рекомендуем добавить внутреннюю сеть предприятия в список разрешенных. Сделать это можно при помощи команды zmprov mcf +zimbraHttpThrottleSafeIPs 192.168.0.0/24. После внесения любых изменений в DoSFilter обязательно перезапустите почтовый сервер с помощью команды zmmailboxdctl restart.
Главным же минусом DoSFilter является то, что он работает на уровне приложения и поэтому может лишь ограничить возможность злоумышленников осуществлять различные действия на сервере, не ограничивая при этом возможность соединяться с севером. Из-за этого посылаемые на сервер запросы на аутентификацию или отправку писем хоть и будут заведомо провальными, по-прежнему будут представлять из себя старую добрую DoS-атаку, остановить которую на столь высоком уровне невозможно.
Для того, чтобы полностью обезопасить свой корпоративный сервер с Zimbra OSE, можно воспользоваться таким решением, как Fail2ban, которое представляет из себя фреймворк, способный постоянно мониторить логи информационных систем на предмет повторяющихся действий и блокировать нарушителя за счет изменения настроек брандмауэра. Блокировка на столь низком уровне позволяет отключать злоумышленников прямо на этапе IP-соединения с сервером. Таким образом, Fail2Ban может прекрасно дополнить защиту, выстроенную с помощью DoSFilter. Давайте же узнаем, как можно подружить Fail2Ban с Zimbra OSE и за счет этого повысить защищенность ИТ-инфраструктуры вашего предприятия.
Как и любое другое приложение корпоративного класса, Zimbra Collaboration Suite Open-Source Edition ведет подробные логи своей работы. Большинство из них хранятся в папке /opt/zimbra/log/ в виде файлов. Вот лишь несколько из них:
- mailbox.log — логи почтовой службы Jetty
- audit.log — логи аутентификации
- clamd.log — логи работы антивируса
- freshclam.log — логи обновлений антивируса
- convertd.log — логи конвертера вложений
- zimbrastats.csv — логи производительности сервера
Также логи Zimbra можно найти в файле /var/log/zimbra.log, где ведутся логи работы Postfix и самой Zimbra.
Для того, чтобы защитить нашу систему от брутфорса, мы будем мониторить mailbox.log, audit.log и zimbra.log.
Для того чтобы всё работало, необходимо чтобы на вашем сервере с Zimbra OSE были установлены Fail2Ban и iptables. В том случае, если вы используете Ubuntu, сделать это вы можете с помощью команд dpkg -s fail2ban, если же вы используете CentOS, то проверить это можно с помощью команд yum list installed fail2ban. В том случае, если Fail2Ban у вас нет установлен, то его установка не станет проблемой, так как этот пакет есть в практически всех стандартных репозиториях.
После того как всё необходимое программное обеспечение установлено, можно приступить к настройке Fail2Ban. Для этого необходимо создать конфигурационный файл /etc/fail2ban/filter.d/zimbra.conf, в котором пропишем регулярные выражения для логов Zimbra OSE, которые будут соответствовать неверным попыткам входа и приводить в действие механизмы Fail2Ban. Вот пример содержимого zimbra.conf с набором регулярных выражений, соответствующих различным ошибкам, выдаваемым в Zimbra OSE при неудачной попытке аутентификации:
# 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 =После того как регулярные выражения для Zimbra OSE составлены, самое время приступить к редактированию конфигурации самого Fail2ban. Настройки этой утилиты располагаются в файле /etc/fail2ban/jail.conf. На всякий случай сделаем его резервную копию при помощи команды cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.bak. После этого приведем этот файл к примерно следующему виду:
# 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 = 5Этот пример хоть и является довольно универсальным, все же стоит разъяснить некоторые параметры, которые вы, возможно, захотите изменить при самостоятельной настройке Fail2Ban:
- Ignoreip — при помощи этого параметра можно указать конкретный ip или подсеть, адреса из которой Fail2Ban не должен проверять. Как правило, в список игнорируемых добавляется внутренняя сеть предприятия и другие доверенные адреса.
- Bantime — Время, на которое нарушитель будет баниться. Измеряется в секундах. Значение -1 означает бессрочный бан.
- Maxretry — Максимальное число раз, которое один ip-адрес может пробовать получить доступ к серверу.
- Sendmail — Настройка, позволяющая автоматически отправлять email-оповещения о срабатывании Fail2Ban.
- Findtime — Настройка, позволяющая задать временной интервал, после которого ip-адрес может вновь попытаться получить доступ к серверу после исчерпания максимального количества неудачных попыток (параметр maxretry)
После сохранения файла с настройками Fail2Ban, остается лишь перезапустить эту утилиту при помощи команды service fail2ban restart. После перезапуска основные логи Zimbra начнут постоянно мониториться на соответствие регулярным выражениям. Благодаря этому администратор сможет фактически исключить любую возможность проникновения злоумышленника в не только в почтовые ящики Zimbra Collaboration Suite Open-Source Edition, но и защитить все работающие в рамках Zimbra OSE службы, а также быть в курсе любых попыток получения несанкционированного доступа.
По всем вопросам, связанными c Zextras Suite вы можете обратиться к Представителю компании «Zextras» Екатерине Триандафилиди по электронной почте katerina@zextras.com
ссылка на оригинал статьи https://habr.com/ru/company/zimbra/blog/476640/
Добавить комментарий