10 ошибок в конфигурации IT-систем организаций

Ошибки в настройке IT-инфраструктуры регулярно встречаются в крупных организациях с большими и компетентными отделами IT и ИБ. Доказательство тому — еженедельно появляющиеся новости о взломах больших и солидных компаний, а также результаты аудитов безопасности, которые, правда, редко публикуются. Но проблема достаточно масштабна — это признают, в частности, американские регуляторы, такие как CISA и АНБ. В своем новом документе с рекомендациями, подготовленном «красной» и «синей» командами после множества аудитов и реагирования на инциденты, они отмечают, что «ошибки в конфигурации иллюстрируют системные слабости в крупных организациях, включая компании со зрелой ИБ». При этом в документе утверждается, что «команды сетевой безопасности при достаточном финансировании, подготовке и штатной численности могут нейтрализовать или смягчить эти слабости». Давайте посмотрим, какие ошибки коллеги считают наиболее опасными.

1. Конфигурация приложений по умолчанию

Любое устройство или приложение, будь то принтер, почтовый или файл-сервер, система конференц-связи, часто имеют механизм входа с использованием дефолтных реквизитов доступа, которые забывают отключать. Настройки этих устройств по умолчанию обычно мягкие, не очень безопасные, но их никто не меняет. Типичный пример — принтер, имеющий привилегированный сетевой доступ для удобства печати, а также веб-панель управления со стандартными реквизитами входа. Часто встречаются Windows-серверы, на которых не отключили старые версии SMB или других ретропротоколов. Весьма опасны стандартные настройки и шаблоны Active Directory Certificate Services, позволяющие выдать непривилегированному юзеру серверный сертификат, поднять права до администраторских или авторизоваться, получив Kerberos TGT.

Рекомендованные меры защиты:

• Обязательная процедура служб IT перед началом эксплуатации IT-системы: отключить стандартные аккаунты (admin, guest и тому подобные) или как минимум сменить на них пароли.
• Сделать обязательным использование стойких паролей — минимум 15 случайных символов.
• Установить на устройстве или сервисе безопасные настройки, руководствуясь инструкциями производителя по улучшению стойкости (hardening), а также релевантными общими руководствами, например DISA STIG.
• Внедрить безопасную конфигурацию ADCS: по возможности отключить присоединение через веб, отключить NTLM на серверах ADCS, отключить альтернативные имена (SAN) для UPN.
• Перепроверить стандартные разрешения в шаблонах ADCS, удалить из шаблонов флаг CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, забрать у низкопривилегированных пользователей свойства FullControl, WriteDacl и Write.
• Активировать подтверждение руководителем любых запрошенных сертификатов.

2. Неверное управление привилегиями пользователей и админов

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

Рекомендованные меры защиты:

• Внедрить принцип наименьших привилегий.
• Внедрить систему управления identity, включающую протоколирование выдачи и применения прав, — это позволит легче находить неправомерное использование прав доступа.
• С помощью этой системы минимизировать число административных учетных записей и уменьшить число учетных записей в целом (путем их корректного объединения).
• Регулярно проводить аудит аккаунтов, отключать неактивные, понижать права там, где они избыточны.
• Ограничить привилегированным учетным записям возможность выполнять повседневные действия вроде просмотра веба и e-mail.
• Выдавать повышенные привилегии только на время выполнения требуемых действий, даже администраторам.
• По возможности запускать сервисы и демоны с ограниченными привилегиями и доступами.

3. Недостаточный мониторинг внутренней сети

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

Рекомендованные меры защиты:

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

4. Отсутствие сетевой сегментации

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

Рекомендованные меры защиты:

• Внедрить сегментацию сети, если ее еще нет. Для этого можно применять как физические средства сегментации, так и логические (VLAN). Важно, чтобы инфраструктурные сетевые устройства были снабжены актуальными и верно настроенными списками контроля доступа (ACL), исключающими присоединение неавторизованных устройств к административным, промышленным и конфиденциальным сетям. Также рекомендовано использование «демилитаризованных зон» (DMZ) для снижения доступности внутренних IT-систем из Интернета.
• Внедрить сетевые средства защиты (NGFW), способные глубоко анализировать пакеты c учетом породившего их приложения и предыдущего состояния соединения. Межсетевой экран должен отклонять трафик, который отличается от стандартного трафика приложения, разрешенного в сети. Фильтрация трафика по приложениям не основывается на одних лишь сетевых портах и значительно сокращает возможности атакующих по злонамеренной эксплуатации сетевых протоколов.

5. Низкая культура патч-менеджмента

Систематической проблемой является медленное и неполное применение патчей и обновлений к аппаратным и программным комплексам. Ситуация значительно усугубляется тем, что многие организации по разным причинам продолжают эксплуатировать безнадежно устаревшие системы (Windows XP, SAP R/3 и тому подобные), для которых давно не выпускаются никакие обновления.

Рекомендованные меры защиты:

• Сделать управление обновлениями систематическим процессом, приоритизировать устранение известных эксплуатируемых уязвимостей и критических уязвимостей.
• Максимально автоматизировать применение обновлений при помощи систем автообновления от производителей ПО, а в идеале — централизованной системы патч-менеджмента.
• Обновлять не только ПО, но и прошивки оборудования, BIOS/UEFI компьютеров.
• Проанализировать применяемые в бизнесе устаревшие системы и по возможности запланировать их выведение из оборота. Если это невозможно — внедрить компенсирующие меры, такие как сетевая изоляция устаревших систем.

6. Возможность обойти контроль доступа

Настройки среды и приложений часто позволяют использовать такие атаки, как pass-the-hash и kerberoasting, для доступа к нужным ресурсам без знания пароля.

Рекомендованные меры защиты:

• Минимизировать одинаковые учетные данные в разных системах, чтобы атакующие не могли эффективно распространяться по сети. Отслеживать нестандартные и неуспешные попытки входа в системы.
• Воплотить системный патч-менеджмент (см. п. 5).
• Внедрить меры противодействия атакам PtH: использовать обновления KB2871997, применить ограничения UAC к локальным аккаунтам после входа в сеть, запретить доменным пользователям входить в группу локальных администраторов на компьютере.
• Ограничить прямые коммуникации между обычными компьютерами, они должны взаимодействовать через сервер.
• Использовать привилегированные аккаунты только на системах, требующих этих привилегий. Оцените возможность использования специальных выделенных компьютеров для привилегированного доступа администраторов.

7. Слабые или неверно настроенные методы многофакторной аутентификации

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

Другая распространенная проблема — методы MFA, недостаточно устойчивые к фишингу, например SMS-коды. Получать коды злоумышленники могут разными способами — от социальной инженерии и MFA-бомбардировки до атаки на телеком-сети SS7 или нелегитимного дублирования SIM-карт.

Рекомендованные меры защиты:

• Отключить устаревшие средства аутентификации, такие как NTLM.
• Использовать групповые политики или настройки Windows Hello for business, чтобы регулярно рандомизировать хеши для аккаунтов, вход в которые идет по смарт-картам.
• Подумать о переходе на открытые стандарты аутентификации, основанные на облачных инфраструктурах.
• Перейти на системы MFA, устойчивые к фишингу.

8. Недостаточное ограничение доступа к сетевым папкам и сервисам

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

Рекомендованные меры защиты:

• Все хранилища и сервисы должны разрешать доступ только аутентифицированным и авторизованным пользователям.
• Важные ресурсы должны быть настроены в соответствии с принципом наименьших привилегий.
• К файлам и папкам должны быть применены жесткие настройки, ограничивающие любые неавторизованные манипуляции, особенно это касается папок, содержащих конфиденциальную информацию наподобие ключей.
• Убедитесь, что атакующие не могут свободно модифицировать списки контроля доступа (ACL), фактически аннулируя все вышеперечисленные меры.
• В групповых политиках Windows запретите анонимный анализ аккаунтов и сетевых ресурсов (anonymous enumeration of SAM accounts and share).

9. Низкое качество паролей и парольных политик

Значительное количество организаций разрешает пользователям короткие и простые пароли. В результате до 80% паролей сотрудников могут быть подобраны инструментом вроде Hashcat достаточно быстро.

Рекомендованные меры защиты:

• Установите для всех паролей рекомендованные критерии сложности.
• Оцените, можно ли разрешить пользователям применять менеджеры паролей и какие.
• Запретите использование одинаковых паролей локального администратора на разных компьютерах.
• Установите высокие критерии сложности для административных паролей и парольных фраз на сертификатах/закрытых ключах.
• Внедрите процесс и автоматизированную систему поиска в IT-системах паролей, которые хранятся в открытом виде или легко извлекаемом виде (сохраненные пароли в браузере).

10. Отсутствие ограничений на выполнение кода

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

Рекомендованные меры защиты:

• Включите настройку, запрещающую запуск приложений из недоверенных источников.
• Еще лучше — включите allowlisting (он же default deny), то есть запуск приложений только из фиксированного списка одобренных. Убедитесь, что инструмент, реализующий эту политику, проверяет цифровые подписи и другие ключевые атрибуты файла, а не просто ориентируется на имена.
• Заблокируйте запуск известных уязвимых приложений, особенно драйверов.
• Ограничьте возможности запуска скриптовых языков (powershell и ему подобных), проверяйте журналы запуска разрешенных сценариев, запретите выполнение скриптовых языков, которые не используются в IT-системах компании.
• Регулярно проверяйте системы защиты хостов и периметра на эффективность фильтрации спама и блокировки запуска вредоносного ПО.