Как мы почту закаляли: поэтапный харденинг инфраструктурных сервисов на практике

Хабр, привет! Меня зовут Юрий Родионов, и я эксперт практики объединенных коммуникаций в К2Тех. Сегодня я хочу поговорить о теме, волнующей многих ИТ-администраторов и инженеров – о харденинге информационных систем и сервисов. В статье я поделюсь своим опытом проектирования и разработки архитектуры решения и дизайна ландшафта на примере сервиса электронной почты в периметре заказчика с применением подходов харденинга и концепции построения надежной и устойчивой ИТ-инфраструктуры. Сразу предупрежу: для профессионалов крупных государственных или коммерческих холдингов, где усиление инфраструктуры и ее отказоустойчивости – повседневная практика, мои советы вряд ли станут откровением. Однако материал может быть полезен тем, кто только начинает выстраивает защищенную инфраструктуру, развивает это направление в своей компании, старается придерживаться принципов гигиены информационной безопасности, стремиться повысить надежность сервисов и приложений, минимизировать риски простоев и обеспечить бесперебойную работу ИТ-ландшафта.

Что такое «hardening» в моем понимании

Для начала давайте определимся, что такое харденинг, чтобы семантика изначально англоязычного слова (hardening) понималась нами одинаково. Я формулирую это так. Харденинг — это процесс повышения защищенности системы путем удаления или ограничения ее потенциальных уязвимостей. Этот подход включает целый комплекс мер и настроек, направленных на снижение возможностей для атак и защиту данных.

Многие рассматривают харденинг исключительно как низкоуровневое изменение конфигурации программного обеспечения, следуя предписаниям разработчиков или бюллетеням отраслевых экспертных сообществ и институций, таких как CIS, NIST, ФСТЭК. Такой подход мне кажется неполным и в некоторых случаях неприменимым, поскольку далеко не все производители программного обеспечения предоставляют шаблоны и рекомендации для проведения харденинга. Зону импортозамещения тема вообще обошла стороной практически полностью: российские разработчики в первую очередь сосредоточены на развитии функционала продукта и их соответствии  требованиям заказчиков, а не на проработке глубинных деталей и анализе безопасности своих продуктов. Тут надо оговориться, что все же есть исключения: некоторые компании активно взаимодействуют с ИБ заказчиков и интеграторов, анализируют и разрабатывают специальные харденинг-гайды. Но таких примеров – единицы. 

На мой взгляд, харденинг следует рассматривать гораздо шире. Если обратиться к этимологии и семантике, слово «hardening» вовсе не ограничивается конфигурационными изменениями. «Упрочнение» подразумевает комплекс мер, подходов и настроек, направленных на повышение безопасности как системы в целом, так и окружающего инфраструктурного ИТ-ландшафта компании.

Злоумышленник на пороге! Объясняем харденинг простыми словами 

Чтобы понять, что такое харденинг и как он может быть представлен в обычном физическом мире, проведем простую аналогию. Представьте себе вашу организацию как дом, вашу систему как квартиру, а ваши серверы как комнаты.

Злоумышленник выбрал вас в качестве своей жертвы. Допустим, он хочет не только вас обокрасть, забрав все ценное, но и повредить имущество, потому что вы ему лично очень не симпатичны. Чтобы обезопасить себя, мы примем меры эшелонированной защиты. В случае реальной квартиры это будут домофон, двери, камеры наблюдения и даже умные устройства. В интернете аналогичную роль играют файрволы разных производителей с разными алгоритмами проверки, включая современные NGFW.

Сначала незваному гостю необходимо узнать ваше местоположение – будь то реальный адрес или IP адрес в сети. Существуют методы сокрытия подобной информации, такие как использование прокси-серверов или сервисов вроде Kaspersky DDoS Protection. Подобно абонентским ящикам в реальной жизни, такие сервисы скрывают ваш истинный адрес за подменным. Разумеется, вы тут же скажете, что есть масса способов выявить реальные адреса, и будете правы. Но для реализации механики и подходов эшелонированной защиты сокрытие адреса тоже мера, которая усложнит путь для атакующих ботов, потребует большей квалификации и ручного времени злоумышленника.

Предположим, что преступник не так прост и все-таки сумел преодолеть первые «барьеры»: подобрал код к домофону, прошел двери подъезда, повредил камеру наблюдения и оказался в квартире. А у нас есть злая собака внутренняя система защиты, которая только этого и ждала. В ИТ-мире вашим сторожевым псом будут различные ИБ-системы: системы контроля целостности, SIEM анализ с реагированием в Security Operation Center (SOC), банальные антивирусы и контроль их наличия на клиентах, средства обнаружения нетиповых активностей и прочее. 

В хорошем сценарии ИБ-специалист получит информацию о подозрительной активности и сможет купировать атаку: 

• выключить скомпрометированный сервер, 

• проследить вектор атаки, 

• закрыть пути доступа. 

Даже если эти средства защиты окажутся преодолёнными или не среагируют на злоумышленника, то время, которое он тратит на реализацию своих намерений, сыграет в нашу пользу: чем дольше правонарушитель находится в защищённом периметре, тем больше шансов его остановить, а у него – меньше времени на реализацию дальнейших планов атаки. В рамках аллегории надо еще добавить, что чем больше квартир в доме и комнат в квартире, тем сложнее злоумышленнику искать для себя цель и тем большее количество средств защиты ему надо пройти. В ИТ это именуется микро-сегментацией сети. Чем мельче каждая подсеть, в которой расположен сервер, и чем меньше у него соседей, тем более устойчива к атакам будет система, но тем сложнее и дороже ее проектировать и реализовывать. 

Вернемся к злоумышленнику. Представим, что он внутри одной из «комнат» – на вашем сервере. Теперь ему надо найти ценности или путь к другим серверам, где они могут находиться. На практике это означает, что находясь на скомпрометированном сервере, неприятель исследует доступные коннекты к другим серверам и разворачивает весь джентльменский набор преступных инструментов: тулы сканирования сети и подборщики паролей. С точки зрения харденинга, все это происходит в зоне архитектуры сетевой инфраструктуры компании, сегментации сети и дизайна архитектурного решения приложения, установленного на атакованном сервере.

Развиваем историю. Преступник  снова преуспел и смог проникнуть за одну из запертых дверей. Он попал в комнату, где есть шкафы и прочие места хранения потенциальных ценностей. Но внимательный осмотр показал, что ничего действительно ценного там нет – ни золота, ни наличных. Тут я провожу параллель с сервером Back, который хранит данные пользователей, но в случае с почтой это могут быть вложения, файлы очередей, исполняемое приложение, но не базы данных. Базы данных у нас находятся в соседнем периметре, за еще одной дверью. Такая архитектура – классический пример трехзвенного дизайна приложения.

Далее история может повториться в новой комнате. Но все старания вора тщетны, потому что ценности находятся вне зоны его досягаемости – во внешнем сейфе или банковской ячейке, если угодно. В ИТ-структурах это выделенный сервер под базы данных, защищенный и контролируемый средствами контроля конфигураций и аномалий типа Wazuh, с модифицированными портами и другими механизмами защиты. В альтернативном варианте данные могут быть вынесены в другой контур, например, S3 облачного оператора. Подобная неожиданность для атакующего тоже может стать частью механики защиты.

Стоит упомянуть, что приведенные рекомендации касаются в основном вопросов сетевого и инфраструктурного харденинга. Компрометация протокола и эксплуатация ошибок и уязвимостей приложения остаются отдельными точками проникновения вредоносных файлов, независимо от мер защиты на уровне сети

И наконец помните, что целью злоумышленника может являться и нанесение ущерба – шифрование или удаление данных, к которым он смог получить доступ.

Помните, как в фильме «Один дома» грабители оставляли следы своего пребывания, открывая краны с водой? Так и киберпреступники стремятся оставить свою «визитную карточку». Поэтому важно не только предотвратить вторжение, но и минимизировать потенциальный урон, который может быть нанесен внутри периметра. Это выходит за рамки классического харденинга, поскольку никакие модификации портов ПО и отключение технических учетных записей не спасут от целенаправленного уничтожения данных. Только комплекс мер информационной безопасности, многоконтурность и микро-сегментация сети ограничивают зону поражения от действия правонарушителя. 

Формализация представления о харденинге и этапы его внедрения

Когда речь идет о внедрении харденинга в проекты по интеграции, я разделяю процесс на пять составных частей, что позволяет структурировать и организовать путь повышения безопасности и обеспечить комплексный подход к построению устойчивой к атакам системы. Каждая из этих частей охватывает различные аспекты защиты системы, начиная с базового проектирования и заканчивая активным мониторингом и реагированием. Далеко не все заказчики готовы принять и сформулировать потребность вплоть до реализации SOC на своей стороне, многие просто хотят решение, похожее на коробку. В таком случае единственный вариант проекта – дать тот объем услуг, который готова принять компания-заказчик. Вот этапы, из которых состоит процесс внедрения харденинга:

1. Архитектура и дизайн безопасности в ИТ-ландшафте.
   На этапе проектирования системы особое внимание уделяется архитектурным решениям и подходам к безопасности: выбор устойчивых технологий, методы шифрования, распределение ролей и доступов, сегментация сети и другие аспекты. Именно на этом этапе закладываются основы общей безопасности ИТ-ландшафта.

2. Конфигурационные паттерны для приложения и зависимых систем.
   Эта часть харденинга фокусируется на конфигурации программного обеспечения и системных сервисов. Она включает минимально возможный набор услуг и базовый шаблон для улучшения безопасности информационной системы. Применяются проверенные конфигурационные паттерны (CIS Benchmarks, ФСТЭК и др.), а также рекомендации и скрипты, разработанные как внутренними командами, так и разработчиком продукта.

3. Накладные средства мониторинга и иные приложения безопасности.
   На этом этапе подключаются инструменты и методы для отслеживания и обнаружения вторжений и реагирования на них. Сюда входят дополнительные средства защиты, такие как антивирусы, системы предотвращения (IPS) и обнаружения (IDS) вторжений, системы сбора и анализа логов (SIEM), управление привилегированным доступом и контроль действий администраторов (PIM-PAM). Дополнительно отмечу, что сегодня даже без собственного подразделения ИБ можно контролировать подозрительные инциденты благодаря услуге SOC в формате SAAS.

4. Документирование и управление политиками.
   Эта часть для многих заказчиков не является обязательной и описывает процедуры, связанные с этапом эксплуатации внедряемого решения. Несмотря на то, что документирование — это неотъемлемая часть передачи информационной системы в эксплуатацию, блок, посвященный информационной безопасности, может как включать, так и не включать детальное описание харденинг-политик и архитектурных подходов.

5. Контроль конфигурации в рамках эксплуатации.

Тут решений на нашем рынке CIM систем пока не очень много, но тема важная, если мы достигли этой точки вовлеченности в процесс укрепления периметра безопасности. Вчера я бы предложил использовать спецсредства от ИБ или западных вендоров, однако на сегодня живых проектов по теме CIM практически нет. Ориентируясь на мнение коллег, скажу, что выбор продуктов есть, однако решение необходимо подбирать индивидуально под каждый проект, исходя из условий собственной инфраструктуры заказчика и зон ответственности. Например, ПО «Линза» больше ориентировано на контроль Compliance, а вот ПО «Атом.Порт» – на инфраструктурный контроль конфигураций АРМ.

3 сценария внедрения решений с применением харденинга

Как я упомянул выше, далеко не каждый заказчик имеет собственный развитый Департамент информационной безопасности и может участвовать в харденинг-процессах совместно с нами. Поэтому мы с командой К2Тех подготовили три типовых сценария внедрения с применением харденинг-подходов с учетом степени готовности и пожеланий нашего заказчика. 

Но прежде чем я начну их описывать, сделаю небольшое отступление, где обращу внимание на то, что вопросы безопасности системы находятся не только в поле целевой системы и ИС ее окружения. Все начинается с простейшей гигиены информационной безопасности, которая заключается в применении рекомендованных  default domain policy по комплексу парольных требований, наличию регламентов и проверок учетных записей в группах повышенных привилегий, использования сервисных учетных записей из каталога, а не «как обычно», локальных на сервере, под которым запускаются у нас службы или какое-либо приложение, и бэкапы делаются из-под энтерпрайз админа. Избыточность прав для любых УЗ – это тоже наследуемый бич многих, а ведь список условий, выполнение которых закроет сразу 50% рисков, может уместиться в скромное перечисление, например:

• Длинные и сложные пароли.

• Ограниченный 6 месяцами и менее срок жизни пароля. 

• Регулярные проверки учетных записей в группах администраторов. 

• Наличие работающего WSUS или его аналога, чтобы патч менеджмент в компании все же был бы предусмотрен. 

• Использование централизованной инсталляции антивирусной системы, которая умеет ловить АРМ без клиента. 

• Обучение пользователей не открывать все подряд, особенно ссылки из писем.

А теперь возвращаемся к сценариям хардинга для нашей электронной почты:

1. Сценарий №1 — «Ванильный путь»

По сути это обычный интеграционный проект, в котором харденинг сводится к базовым нормам гигиены информационной безопасности, которые мы распространяем на продукт при первичной его конфигурации. Эти нормы являются частью харденинг-процедур и включают в себя тюнинг настроек, параметров и протоколов.

Позволю себе очередное литературное отступление в описании. Вспомните, как наши родители или бабушки с дедушками после покупки машины обязательно делали антикоррозийную обработку. Сейчас это делается прямо на заводе, но тогда мало было купить автомобиль, его нужно было «протянуть» и покрыть днище «антикором» (кто постарше, помнит :)). Так вот, наш «ванильный» вариант инсталляции – это именно та обработка. Не секрет, что большинство продуктов класса импортозамещения на российском рынке довольно молодые, и им, как и советскому автопрому, требуется доводка после покупки.

Мы как раз занимаемся этим: заменяем «поумолчательные» настройки, отключаем неиспользуемые модули, включаем системные средства контроля целостности файлов и защиту системных файлов. У нас накопилась целая библиотека наработанных решений, позволяющих вывести продукт из коробки на уровень с уверенным митигированием множества типовых рисков и предупреждением популярных атак на почтовые системы.

2. Сценарий №2. 

Тут исходные данные такие: заказчик не имеет собственного подразделения ИБ или специалистов, которые могли бы участвовать в проекте, но, согласно требованиям, внедряемое решение должно соответствовать лучшим практикам и строиться в защищенном исполнении. По правде говоря, это самый распространенный сценарий, с которым обращаются заказчики. Содержать свое подразделение ИБ дорого, а осознание необходимости мер защиты пришло (зачастую через бэкдор, к сожалению). В таких ситуациях мы проектируем всю рабочую среду информационной системы. Как правило, от заказчика требуется только согласовать с нами функциональные требования, а нам – как следует понять бизнес процессы и окружение, в котором исполняется система (этот сценарий описан ниже, хотя такой подход применим к внедрению не только почтовых систем, но и любых других).

3. Сценарий №3.

Наиболее сложный и масштабный проект возникает, когда у заказчика есть собственное зрелое ИБ подразделение. Такие компании, как правило, насчитывают более 10 000 АРМ (автоматизированных рабочих мест) и чаще всего относятся к банковскому сектору, добывающей промышленности, крупнейшим ритейлерам или  государственным структурам. В таком случае нашими контрагентами в проекте выступают представители ИБ заказчика: архитекторы, офицеры и эксперты. Подготовка дизайна решения осуществляется с учетом требований обеих сторон, а его защита рассматривается как важная составляющая проекта. Тут особая нагрузка приходится на наших архитекторов всех направлений, поскольку шаблоны неприменимы, а каждое решение нужно обосновывать, согласовывать и принимать как целевое.   

Почему именно почтовые системы?

Мы все прекрасно понимаем, что почтовые системы являются одними из наиболее уязвимых элементов инфраструктуры и подвержены большому риску по радиусу поражения в случае компрометации или эксплуатации уязвимостей.

Так случилось исторически, но на сегодняшний день существует только один унифицированный стандарт и протокол обмена сообщениями, который поддерживается множеством систем и программными продуктами по всему миру — это SMTP. И вот почему:

• электронная почта является самым распространенным кроссплатформенным унифицированным инструментом делового общения

• играет важную роль в достижении бизнес-результатов компании, а местами является и конвейером в бизнес процессах компании

• содержит критичные данные, в том числе персданные, банковскую и государственную тайну

• является шлюзом входа в защищаемый периметр компании

Таким образом, мы можем смело выделять систему электронной почты в качестве  первого кандидата на проведение комплексных харденинг-процедур. 

Наш опыт внедрения почтовой системы с применением харденинга

Недавно к нам обратился заказчик – производственная компания из северной столицы. Они столкнулись с масштабной атакой, результатом которой стало заражение шифровальщиком. Инцидент привел к утрате более  80% критичных для бизнеса ИТ-объектов: как производственных информационных систем, так и объектов инфраструктурного слоя. К несчастью, почти вся компания работала на Windows based решениях, включая виртуализацию и средства резервного копирования. Кстати, мы уже писали статьи о том, как построить безопасную архитектуру бэкапов и какие устройства для этого выбрать. Советую с ними ознакомиться, чтобы избежать аналогичных плачевных последствий. У нашего заказчика точкой входа злоумышленника стала уязвимость web-сервера одного из бизнес-приложений. Однако на его месте мог быть и интерфейс OWA, и любой другой опубликованный интерфейс. 

«Жареный петух» оказал мощное воздействие, и заказчик, осознав важность вложений в информационную безопасность ИТ, попросил К2Тех разработать комплексную реорганизацию инфраструктурного ИТ-ландшафта компании. Поскольку тема нашей статьи о харденинге почтовой системы, сконцентрирую свое изложение именно в этой плоскости.
После утраты почти всех наработанных данных заказчик согласился на совмещение процессов восстановления сервисов с процессом импортозамещения почтовой системы и ряда инфраструктурных сервисов. Для внедрения мы выбрали Mailion как систему, наиболее соответствующую функциональным требованиям и хорошо вписывающуюся в ландшафт компании по ее масштабу. 

Первым шагом было проектирование верхнеуровневого ИТ-ландшафта компании, которое мы прорабатывали совместно с сетевым архитектором. Мы разделили сеть на несколько модулей: для размещения серверов, для терминирования провайдерских каналов связи, для партнерских подключений и для пользователей. Каждый модуль получил собственный обособленный шлюз и маршрутизацию через пограничные файрволы. Внутри каждого модуля мы создали VLAN за файрволом, обеспечив возможность создания нужного нам количества DMZ сегментов и реализации концепции микро-сегментации сети. 

Теперь, когда у нас есть готовый сетевой ландшафт, можно ‘посеять’ информационную систему согласно нашим подходам по харденингу и всестороннему обеспечению безопасности решения.

Для начала определимся, как к нам будет приходить трафик. Мы решили применять внешние средства защиты от DDOS, хотя наши шлюзы ставятся с запасом мощностей и хорошими средствами защиты. Тем не менее, если бюджет позволяет, то DDOS фильтрация никогда не помешает, особенно на фоне растущей популярности этого типа атаки. Например, сервис Kaspersky DDoS Protection (KDP) или аналогичные сервисы по вашему вкусу. 

В качестве антиспама и потокового антивируса решено было использовать Kaspersky Secure Mail Gateway (KSMG), хотя существует ряд других достойных решений, обладающих высокими показателями эффективности. Если бы дело было несколько лет назад, то я бы выбрал Cisco Iron Port. Но сегодня это решение скорее добавляет рисков, нежели снижает их.

Актуальные версии KSMG не требуют установки предварительного балансировщика трафика, так как распределение нагрузки по нодам будет осуществляться на уровне «стоимостей» MX-записей, а конфигурациями правой и левой стороны система умеет обмениваться самостоятельно. Это не полноценный кластер, но он нам тут и не нужен: логика работы почтовых серверов и SMTP-коннекторов делает эту точку отказоустойчивой при правильной конфигурации. 

Следующий шаг, согласованный с отделом ИБ заказчика, – внедрение DLP-системы. Она контролирует трафик исходящей почты, выявляя запрещённый контент в теле сообщений. Фильтры и критерии нам настраивать не придется, но для теста будет использована реакция на тестовые триггеры в теле писем. Впоследствии заказчик сам сформирует перечень текстов для реагирования и настроит правила уведомления SOC, который, как я писал выше, может быть передан на аутсорсинг – это современный и эффективный подход. В качестве DLP-решения заказчик предпочел работать с «Infowatch». Несмотря на все преимущества этой системы,  она не поддерживает кластерное исполнение, поэтому мы предусмотрели реализацию установки в Disaster Recovery исполнении накладными средствами. Здесь мы применили проверенный подход с использованием двух каскадов балансировки: на входе в информационную систему и на выходе. Схема позволит переключать трафик по направлению к нодам или вовсе обеспечивать bypass режим, при котором DLP система исключается из маршрутизации. Это может понадобиться, например, для отладки или при сбоях в работе системы. 

Поскольку почтовая система – это во многом комбайн, а современная среда подразумевает высокую гибкость в доступе к данным и рабочему окружению, то в наш проект включается также проработка доступов. Внутри периметра все предельно понятно: «толстый клиент» на базе традиционного Outlook. А вот внешний доступ защитить сложнее. Очень действенным накладным решением для защиты доступа к web-клиенту со стороны АРМ является использование обязательного туннелирования трафика с двухфакторной аутентификаций. Но наш случай, согласно функциональным требованиям заказчика, этого не предполагает –  необходим доступ из любой точки мира с любого устройства. 

Мы разделяем трафик от web-клиента и мобильное подключение (где порт 443, делим их на уровне разных публичных IP). Первично весь трафик, как и любой другой, проходит проверку потоковым антивирусом на базе KSMG той же инсталляции, что и для SMTP.  

Затем выполняется SSL offloading, прохождение через  Positive Technologies Application Firewall (PTAF), который у нас тоже в исполнении двух раздельных серверов. Web-часть трафика подвергается проверке, снова шифруется и передается дальше во фронт почтового сервера. 

Следующим этапом мы создали верхнеуровневую концептуальную архитектуру решения, которая демонстрируется заказчику как часть технического задания. Эта документация служит основой для дальнейшей работы профильных экспертов, которые будут декомпозировать решение вглубь: разрабатывать техническое решение для каждого из функциональных компонентов комплекса.

Ниже представленная схема относится к классу HLD (High level diagram), ее создание не требует много времени. Позже при детальном проектировании она может быть преобразована в LLD (Low level diagram) диаграмму, содержащую все необходимые подробности: IP-адреса, имена, VLAN, VIP. Эти данные могут понадобиться для работы специалистов компании-заказчика, например, в качестве руководства для администратора и пояснительной записки. 

Наиболее значимым аспектом в проработке проекта внедрения является поддержание правильной трехзвенной архитектуры и разделение компонентов системы по изолированным сетевым зонам. С точки зрения дизайна это несложно реализовать, особенно при наличии «правильного» сетевого оборудования. Однако определение всех необходимых портов и зависимостей, открытие нужных доступов без избыточности и избегание использования потенциально уязвимых протоколов – это задача, которая требует больше всего времени на проработку и согласование.

Как вы можете видеть на схеме, мы выделяем четыре сетевые зоны безопасности с разными уровнями доверия. Надо понимать, что это лишь концепция, и при реализации внешние факторы могут привести к упрощению архитектуры по тем или иным причинам.

Решения MDM в сочетании с «капсулой» для запуска почты на мобильных устройствах, например, от WorksPad, именуемое уже Enterprise Mobility Management (EMM), также представлено на схеме, но углубляться в его особенности мы не будем, так как это самостоятельная система, которая будет использоваться в компании не только для работы почты. В нашем случае мы используем «капсулизацию» почтового клиента для переноса периметра безопасности компании и митигации большей части рисков, возникающих при публикации почтового сервиса в открытом виде в интернет. 

На схеме присутствует направление исходящего трафика во внешний мир для реализации PUSH-сервисов, где на маршруте предусмотрен proxy сервер. Однако наши тесты показали, что через прокси сложно маршрутизировать исходящий трафик в реальном времени в направлении серверов Apple, поэтому наиболее вероятно, что при  реализации мы пойдем по пути традиционного NAT. 

Как вы можете видеть, в периметрах появляются другие средства ИБ, которые по сути своей являются «коммунальными» и внедряются не в рамках одной системы, а как автономные решения. Среди них – средства привилегированного доступа (PIM/PAM), средства управления учетными записями в организации (IDM), cистема сбора логов и реагирования (SIEM) и система мониторинга (ZABBIX). 

«Тюнинг» почтового сервера

Выше я уже упоминал, что очень многие российские разработчики не имеют разработанных шаблонов харденинга их ПО. Наш случай не исключение. Поэтому мы идем по двум маршрутам: используем готовые шаблоны для операционной системы Astra Linux, которые в большей своей части «приезжают» вместе с золотым образом в платформе виртуализации, и комплекс настроек со стороны Mailion, который мы определяем сами и соотносим с функциональными требованиями заказчика, чтобы они не противоречили друг другу.

Вот некоторые из настроек, которые мы определили:

• Отключение неиспользуемой функциональности. Все функции, которые не использованы в рабочем процессе, должны быть деактивированы. Не должно быть задействованных драйверов протоколов, коннекторов «в никуда» и других конфигурационных единиц, которые не приняты в качестве технологии в компании и не задействуются в процессе работы ИС.

• Отказ от нешифрованных протоколов аутентификации. По возможности использовать Кerberos для пользовательской аутентификации вместо LDAPS.

• Включение защищенных протоколов и отключение протоколов без шифрования HTTPS, SMTPS, IMAPS, POP3S

• Выбор сертифицированных криптографических стандартов. Вот примеры:

LSv1.2 и TLSv1.3    X448: curve448-sha512
TLSv1.2 и TLSv1.3    modp16: diffie-hellman-group16-sha512 (4096 bit modulus)
TLSv1.2 и TLSv1.3    X25519: curve25519-sha256
TLSv1.2 и TLSv1.3    modp15: diffie-hellman-group15-sha512 (3072 bit modulus)
TLSv1.2 и TLSv1.3    modp14: diffie-hellman-group14-sha256 (2048 bit modulus)

• Ограничение набора криптографических алгоритмов. Для сессионного шифрования следует выбирать только устойчивые крипто алгоритмы (cipher suite):

TLSv1.3    TLS_AES_256_GCM_SHA384
TLSv1.3    TLS_AES_128_GCM_SHA256
TLSv1.2    TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLSv1.2    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLSv1.2    TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLSv1.2    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

• Модификация стандартных портов, если это допустимо по функциональному уровню. Например, не 587, а 5588 и т.д.

• Отключение использования TCP:25 для всех коннекторов, кроме входящей внешней почты. Необходимо создавать отдельные коннекторы для выделенных отправителей с модификацией порта и ограничением по IP.

• Использование только STARTTLS для SMTPs во внешний мир. Использовать SMTP AUTH и авторизованные пересылки (authenticated mail relay) при необходимости.

• Правильная настройка использования технологий PTR, SPF, DKIM, DMARC уровня публичного DNS.

• Шифрование для почтовых баз данных. В качестве альтернативы шифрования почтовых БД можно включить шифрование дисков с БД, если работа ведется на чужом хостинге.

• Блокировка вложения по расширению встроенными средствами. Разрешить только типовые документы.

• Запрет на типовые имена DNS при публикации. Необходимо скрывать информацию о вендоре, ПО, сервисе и IP.

• Обезличивание SMTP баннера.

• Обезличивание и ограничение деталей в NDR.

• Валидация публичных DNS-записей на предмет гигиены. Необходимо избегать прямых указаний на почтовые сервера при использовании DDOS фильтров.

• Изменение «поумолчательных» локальных учетных записей и ключей на уровне межкомпонентного взаимодействия в системе. 

Изменений может быть и больше – все зависит от системы, фантазии и вашей прокаченности в теме. 

Валидация результата

Важно подтверждать эффективность внедренных мер. Для этого подойдут автоматизированные сканеры, такие как ImmuniWeb, Nessus и MXToolbox. Дополнительно заказчики проводят тесты на проникновение с привлечением сторонних компаний, специализирующихся на тестировании устойчивости систем к взлому («белые» или «добрые» хакеры).

Если в ходе тестирования выявляются уязвимости, связанные с недооценкой рисков, то разрабатываются планы по их устранения, ведутся переговоры с разработчиком и осуществляется сопровождение процесса ликвидации уязвимостей. Результаты тестов фиксируются в финальной документации.

Итоги

Надеюсь, на примере моего опыта вы убедились, что харденинг почтовых сервисов – не просто рекомендация, а необходимость в условиях современных киберугроз. В 2024 году количество кибератак на российские компании выросло в 4 раза, причем 20% из них происходят через электронную почту. Только комплексный многоуровневый подход, включающий регулярное обновление ПО, установку патчей безопасности и двухфакторной аутентификации, проведение регулярных аудитов и тестирований на выявление слабых мест в системе безопасности поможет предотвратить атаку хакеров и сохранить конфиденциальные данные. Халатность в вопросах защиты может привести к необратимым последствиям для всей инфраструктуры компании, как случилось у нашего заказчика. Даже самые незначительные уязвимости могут стать точкой входа для злоумышленника – дьявол кроется в деталях.

Я постарался провести вас через процессы ИБ в контексте почтовых систем наиболее понятным и прямым маршрутом. Даже если вы не погрузились в детали, у вас сложилось общее представление о стратегии и комплексности подхода, который репрезентует наша компания и который я донес до вас на простых примерах в начале этой статьи.

Если вас интересуют какие-либо детали, пишите в комментариях!