Комментарии 6
Если доступ извне нужен только ограниченному кругу лиц (сотрудникам?), не проще все убрать за VPN и оставить кроме него только 25 порт для SMTP<->SMTP трафика, нещадно отправляя в блэклист всех остальных?
Публикация интерфейсов для пользовательских подключений вовне – это всегда плохо, и нужно этого избегать по возможности. Лучше использовать туннелирование трафика, а еще лучше терминировать сессию мобильного или web-клиента на каком-нибудь HAproxy в DMZ сегменте. Идеально было бы использовать MDM решение с капсулой почтового клиента на мобильном устройстве, хотя это дороже)
А что касается SMTP – тут выбор зависит от того, кто ваши контрагенты. Если вы принимаете почту из всего интернета, то пути блэклистинга, даже автоматизированного, не так широки. Хорошая практика – установить антиспам и антивирус на вход и настроить через его интерфейс уровень фильтрации и доверия, паттерны проверки и т.д.
Spamd, sa, ptr-checking и т.п. это все само собой разумеется. Но Вы упомянули, что к почте нужен был доступ "из любой точки мира с любого устройства". Отсюда и вопрос про торчащие в мир 465/993 (пусть даже и в DMZ), потому что если речь идет не о почтовом хостинге для 0.0.0.0, а о внутрикорпоративной почте для заранее известного круга людей, можно же кроме VPN и 25 ничего не открывать, а SMTP проверять, и все соединения не сервер-сервер дропать.
Тоже имел печальный опыт с шифровальщиком, который всю базу эксченджа навернул )) Как раз потому что он OWA наружу висел,ага. И бэкапы там были сделаны в лоб (тоже зашифровались). Восстанавливал все экспортом в pst на клиентских аутлуках, та еще песня.
Попробую уточнить.
Сервер, принимающий почту из внешнего мира (порты 25\465\587), неизбежно будет «торчать». Даже при использовании KDP другого варианта нет, иначе это будет почтовый сервер закрытого периметра.
В случае с клиентским интерфейсом в ПЯ (порты 443\143\993\6005+ и т.д.) имеется доступ к данным ПЯ, адресной книге, календарям и прочим секретам. Эшелонированная защита, которая безусловно включает в себя VPN, пусть даже без 2FA, является хорошей мерой для снижения рисков.
По вашему вопросу: действительно, имеет смысл повесить на отдельные публичные адреса VPN и порт 25. Все запросы, которые не соответствуют фильтрам и требованиям коннектора, должны блокироваться.
Спасибо за развёрнутую статью. Заказчик видимо было очень большой, если смогли позволить себе такую инфраструктуру. Хотя поиск "пропавших писем" в ней ещё то удовольствие. :-)
"Валидация публичных DNS-записей на предмет гигиены. Необходимо избегать прямых указаний на почтовые сервера при использовании DDOS фильтров" Мне не приходилось настраивать DDOS фильтры, можете подробнее расписать о чём речь?
Немного комментариев по поводу рекомендаций по защите:
"Модификация стандартных портов, если это допустимо по функциональному уровню. Например, не 587, а 5588 и т.д." Допустим от скрипто-сканеров из Инета это поможет, хотя RDP и SSH на кастомных портах со временем находят, но если речь про настоящих профи, то это для них не препятствие.
Использование только STARTTLS для SMTPs во внешний мир. Ключевое слово 'ТОЛЬКО'. С одной стороны это правильно, с другой -- рано или поздно какая-нибудь гостиница со скриптом отправки почты с сайта не сможет доставить сообщение и начнётся открывание тикетов :-)
Шифрование для почтовых баз данных. Даже думать не хочу, что будет с поиском писем при их большом количестве. А резервное копирование и восстановление как, обычно это отдельные программы, которые должны уметь расшифровывать?
Запрет на типовые имена DNS при публикации. Необходимо скрывать информацию о вендоре, ПО, сервисе и IP. Это вообще не препятствие для реальных хакеров. У МС даже была бумага, что нет смысла скрывать имена внутренних серверов в Internet header, т.к. сервера всё равно существуют. Хотя я их режу всё равно при возможности :-).
Обезличивание SMTP баннера. Опытный админ по ответам сервера поймёт, что за сервер отвечает.
Обезличивание и ограничение деталей в NDR. NDR то генерит сервер отправителя, а запускать все письма для домена не проверяя получателя такое себе.
Я так, подискутировать по доброму :-)
Всегда рад подискутировать :)
В нашей компании принято начинать с предварительного концептуального проектирования. Заказчик хочет максимальной защиты, чтобы избежать повторения инцидента, и этот максимум в реалиях ландшафта заказчика возможен. Далее начинается оценка работ, объем изменений, стоимость лицензий, и, как правило, концепция худеет раза в 2 по инициативам.
Теперь по вопросам:
В качестве примера, как воспринимает ИБ риски. Если опубликовать веб-сервер без защиты на час, это низкий риск, поскольку время открытия является митигантом. Однако неделя открытой доступности – это уже недопустимо, и требуются дополнительные меры безопасности.
В случае с почтой такие меры защиты как баннер, порты, обезличивание НДР и заголовков сессии с технической точки зрения не очень эффективны, но с точки зрения ИБ они снижают вероятность атак. Если удастся отбить хотя бы несколько примитивных попыток взлома, это уже оправдано.
Со сканерами портов то же самое. Часто злоумышленники проверяют типовые порты сервисов, поэтому модификация может оказаться эффективным средством защиты. Например, порт 3389 быстро обнаружат, а 41781 может долго оставаться незамеченным. Однако, если мы говорим о целенаправленных атаках «квалифицированными специалистами», то эти меры не помогут.
Потенциал у внешних DDoS-фильтров, таких как Qrator и CloudFlare, обычно выше. Они имеют большие вычислительные ресурсы, обрабатывают большое количество соединений и имеют более широкие каналы связи, чем внутренние шлюзы типа ASA.
Про Start TLS: тут компромисс между безопасностью и совместимостью. Outlook.com использует Start TLS – это индустриальный стандарт. К сожалению, иногда приходится жертвовать уровнем защиты ради удобства пользователей.
Шифрование БД зависит от уровня рисков, но в большинстве случаев оно излишне. Можно шифровать данные на уровне дисковой подсистемы средствами СХД или ОС, что защищает от физического доступа к серверам в дата-центрах. Шифрование на уровне приложения обеспечивает дополнительную защиту, даже если база данных «уйдет» . Однако реализовать такое шифрование сложно, и не всегда возможно сделать это штатными методами. Потоковое шифрование конечно требует значительных ресурсов и применяется лишь для критически важных данных, обычно можно выделить БД с чувствительными почтовыми ящиками под это. Если вы рассматриваете такие риски, значит, стоимость защищаемых активов высока, и у вас есть ресурсы для обеспечения этой защиты.
Как мы почту закаляли: поэтапный харденинг инфраструктурных сервисов на практике