В начале недели началась атака на почтовую систему организации, работающую на ZCS. Основной вектор - подбор пароля нескольких учётных записей посредством IMAP. У зимбры есть встроенный механизм - после нескольких неудачных попыток входа учётная запись на определённое время блокируется чтобы замедлить нападающего. Однако, такая блокировка бьёт по сотрудникам.
Начали смотреть насколько велико множество адресов, с которых ведётся атака. Оно оказалось большим, так что индивидуальные блокировки - не вариант. В результате одно-единственное правило форварда новых соединений для WAN-DMZ превратилось в несколько:
- Белый список. Все необходимые порты (http, imap, pop3, smtp) из локальной сети, систем внешнего мониторинга, мобильных сетей операторов Москвы - accept
- Серый список (для наблюдения за происходящим). Все порты для адресов из соответствующего списка - accept
- Подозреваемые. Порты http, imap - tar pit
- Почтальон Печкин. Порты pop3, smtp - accept
- Ну, и дефолтовое правило - drop всего что сюда дошло. В принципе, все необходимые условия должны отрабатывать раньше, так что для этого правила счётчик должен оставаться в 0. Если не 0, значит, где-то ошибка
В результате, почта доставляется, сотрудники на рабочих местах и на мобильниках в Москве могут пользоваться почтой, до подбора паролей дело не доходит. Маршрутизатор практически не напрягается. Однако, тем сотрудникам, у кого дома нет статического адреса или с какого-нибудь wifi - почта недоступна. Недоступна почта сотрудникам с мобильного не в Москве, особенно за границей.
Попробовали подумать вот в какую сторону: всё разрешено, но на почтовом сервере демоном мониторить лог-файл аудита. Если появляется ошибка аутентификации, при помощи API RouterOS соответствующий адрес заносить в чёрный список на какое-то время. Этим чёрным списком должны пользоваться правила как для новых соединений, так и для established/related. Однако, проблема в том, что с отдельного адреса обращение происходит очень редко, в параллель работает множество адресов, поэтому подбор всё равно будет происходить практически без потерь для атакующего. А сотрудники снова окажутся без почты.
В какую сторону стоит подумать? Как-то это решается?
Простой
Сложный
