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

После этого осознания появляются логические вопросы: с чего начать, какие аспекты учесть, на что сосредоточить внимание? Именно на них я, Кирилл Васильев, руководитель команды Центра практической информационной безопасности Innostage, постараюсь ответить.

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

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

• точно будут использоваться инфраструктурные сервисы по типу почтового MS Exchange, службы каталогов MS Active Directory и разрешения имён.

• «хитрые» пользователи работают на хостах с ОС Windows и считают, что они лучше знают, что им делать и где хранить пароли.

• бухгалтеры подключаются к 1С через пару расшаренных на всех сотрудников учёток, как из офиса, так и из дома, при использовании неизомерного количества RAT утилит, чтобы получить заветный доступ до своего работающего 24/7 офисного компьютера.

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

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

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

Инвентаризация

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

Например, мы для себя выделили первый спринт — собрать информацию по всем хостам, которые есть у нас в сети. Для этого определяем пару подходящих нам техрешений из всего накопленного опыта: «Инвентаризация доменных машин путём выгрузки информации с контроллера домена с использованием оснастки RSAT системной утилиты PowerShell» и «Инвентаризация узлов в сети с использованием NMAP».

Первое техрешение содержит готовый PowerShell-скрипт и краткую инструкцию, что позволит нам собрать объекты из каталогов Active Directory нашей инфраструктуры, с которыми мы сможем дальше работать: проверить актуальность доменных хостов, уточнить их назначение и их «хозяев» для классификации и группировки хостов, начать обозначать для себя объект защиты. Сам скрипт с запросами к AD можно найти в интернете, типовые LDAP-запросы находятся в открытом доступе. Например, следующая часть скрипта поможет вытащить конкретный доменный объект с его DNS-именем и IP-адресом:

Get-ADComputer -Identity "my.pc-01.local" -Properties Name, DNSHostName, Enabled, Operatingsystem, IPv4Address

Результат работы скрипта прост: мы получаем записанную информацию об объекте AD, при этом можно использовать фильтрацию по любым атрибутам объекта. Подобное можно реализовать и через оснастку AD, но скриптом получится более автоматизировано.

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

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

Проведя разовую инвентаризацию, мы обозначили для себя объект защиты, с которым уже можно продолжить работу.

Контроль изменений и соответствие политикам

Контроль отличается от инвентаризации как раз периодичностью проверок. Вернёмся к описанию нашей вымышленной компании: у нас отсутствует утверждённый регламент регистрации пользователей и назначения им привилегий. Поэтому в нашей инфраструктуре неконтролируемо появляются новые учётные записи с явно лишними правами и непонятные хосты в сети. В нашем подходе есть некоторые простые, но полезные процессы контроля, к примеру, «Контроль устаревших доменных учётных записей» и «Контроль соответствия политикам». Возьмём то же техрешение с PowerShell-скриптом и RSAT, но скорректируем фильтр. Для начала выгрузим учётные записи AD, которые не проходили аутентификацию на DC за последние два месяца, для этого нам понадобится атрибут LastLogonDate:

Get-ADUser -Properties LastLogonTimeStamp -Filter {LastLogonTimeStamp -lt ((Get-Date).AddDays(-60))}

Для выгруженных учётных записей стоит обратить отдельное внимание на их права в домене и статус атрибутов «Enable» и «Lockout». Наличие в инфраструктуре подобных учёток становится ещё одним вектором атаки на нас, поэтому избыточные для бизнес-процесса объекты в AD стоит заблокировать или удалить.

Чтобы проводить подобный анализ с заданной периодичностью, можно настроить Планировщик заданий Windows и автоматизировать процесс блокировки неиспользуемых доменных учётных записей.

Для контроля соответствия политикам сможем использовать снова наше техрешение с оснасткой RSAT для PowerShell, но уже для проверки атрибутов учётных записей, которые нам помогут развить наш уровень киберустойчивости: длина пароля, требования к сложности, история, минимальный и максимальный сроки действия и условия блокировки. Все эти параметры увеличивают возможность нашей инфраструктуры противостоять атакам подбора. Для контроля выберем учётные записи группы AD «администраторы домена» и проверим, насколько настройки таких пользователей будут устойчивы к простым атакам брутфорса. С помощью нашего скрипта, вытянем состав доменной группы командой:

Get-ADGroupMember "Domain Admins"

Для учётных записей этой доменной группы пользователей проведём контроль «Как давно пользователи меняли свой пароль?» с помощью той же оснастки RSAT:

Get-ADUser -identity "bad_admin" -Filter "Enabled -eq 'True' -AND" -Properties
PasswordLastSet,PasswordNeverExpires,PasswordExpired |
Select DistinguishedName,Name,pass*,@{Name="PasswordAge";
Expression={(Get-Date)-$.PasswordLastSet}} |sort
PasswordAge -Descending |

Примем за политику в нашей компании, что хорошей практикой будет смена пароля от учётных записей каждые 90 дней. Тогда скрипт поможет найти забытые учётные записи, для которых стоит проверить настройки требований к паролю в групповых политиках AD и выставить атрибуты «Maximum password age = 90» и «Minimum password length = 12», например, через наш недавно открытий PowerShell:

Set-ADDefaultDomainPasswordPolicy -Identity “bad_admin” - Maximum password age 90 - Minimum password length 12

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

Get-ADUserResultantPasswordPolicy -Identity “bad_admin”

В дополнение можем взять на вооружение и доработать свой скрипт для контроля блоком проверки созданных за 24 часа доменных пользователей:

$lastday = ((Get-Date).AddDays(-1))
Get-ADUser -filter {(whencreated -ge $lastday)}

Подобный контроль позволит поймать несогласованное создание доменных пользователей и снизить вероятность размножения неиспользуемых учётных записей.

Обеспечение защиты

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

Возьмёмся снова за нашу виртуальную компанию и выберем пару технических решений по харденингу Windows: «Отключить протокол LLMNR» и «Отключение SMBv1». Для многих подобные меры могут показаться очевидными, но это просто несколько примеров, какой опыт мы собираем. Техрешение, кроме самой инструкции, содержит в себе обоснование применения подобных мер и возможные риски.

В первом случае техрешение описывает, что протокол LLMNR подвержен атакам типа «человек посередине» и спуфингу в частности. Сам протокол предназначен для опознания хостом в сети соседей за счёт широковещательных запросов в локальном сегменте сети на уровне L2 и разрешения имён соседних компьютеров (FQDN) без использования DNS-сервера, либо при потере связи с сервером имён.

В случае проникновения во внутреннюю сеть нашей компании киберпреступник сможет провести MITM-атаку через широковещательный запрос и перенаправить запросы «жертвы» на подконтрольный сервер. Атака используется для перехвата учётных данных и, с большой вероятностью, в результате будет получен хэш NetNTLMv2 нашей «жертвы». Далее злоумышленник перебирает брутфорсом хэш с использованием hashcat, чтобы добыть валидные данные для будущего lateral movement.

Способ защиты можно выбрать простой — ограничить на хостах использование протокола LLMNR через групповые политики.

"Конфигурация компьютера\Административные шаблоны\Сеть\DNS-клиент\Отключить многоадресное разрешение имен"

Однако у такого технического решения есть и риск: хосты, временно утратившие связь с DNS-сервером, «ослепнут» в разрешении имён и могут потерять своих соседей. Для стабильно работающей инфраструктуры и корректно функционирующих DNS-серверов подобный риск можно принять, значительно снизив объём векторов атак киберпреступников, которые получили первоначальный доступ к инфраструктуре. Подобный путь можно пройти с исключением устаревшего протокола NETBIOS, который таким же образом используется для MITM-атак.

Продолжим и перейдём ко второму выбранному техническому решению «Отключение SMBv1». Протокол сам обеспечивает сетевой доступ к общим файлам. SMB версии 1.0 из коробки отключён в последних версиях Windows 11 и 10, а также в Windows Server 2019/2022, но остальные рабочие станции и сервера с ОС Windows, вероятнее всего, имеют старую версию протокола. Уязвимости в SMBv1 активно используются в эксплойтах EternalBlue и EternalRomance. Кроме того, дырками в старом протоколе пользуются и распространяются по сети вредоносы: TrickBot, Emotet, WannaCry, Retefe, NotPetya, Olympic Destroyer.

Проверить, отключён ли на серверах SMBv1 на конечном хосте, можно с помощью команды PowerShell, который мы активно использовали ранее:

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

True означает, что протокол SMBv1 включён. Для отключения SMBv1 можно выполнить команду на хосте:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\
Parameters" SMB1 -Type DWORD -Value 0 -Force

Нашей виртуальной компании будет удобнее использовать групповые политики, чтобы охватить всю инфраструктуру. В стандартных GPO нет отдельной политики настройки SMB, однако протокол можно отключать через редактирование реестра самой политикой. Для этого переходим в консоль управления gpmc.msc, создаём новый объект «smb1_disable» и назначаем его на OU`шку с серверами и рабочими станциями, на которых нужно отключить SMB1.

Computer Configuration → Preferences → Windows Settings → Registry.
Создаём новый параметр реестра (Registry Item) с настройками:
Action: Create
Hive: HKEY_LOCAL_MACHINE
Key Path: SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Value name: SMB1
Value type: REG_DWORD
Value data: 0

Какие могут быть риски? SMB v1 может быть необходим для корректной работы устаревших устройств с Windows XP/2003, старых версий NAS, сетевых принтеров с поддержкой SMBv1 и устройств со старыми версиями samba. Поэтому отключение устаревшей версии протокола может нарушить работу несовместимых устройств с более свежими версиями SMB.

Мониторинг

Наш подход содержит хорошие практики и примеры построения мониторинга ИБ и ИТ. Так, рассматривая нашу виртуальную компанию, мы можем подобрать для себя инструкции по настройке ИТ-мониторинга серверов и рабочих станций на основе Zabbix или настройке ИБ-мониторинга в части журналирования наиболее полезных событий ИБ с источников событий на ОС Windows.­ Всё это — результат опыта команды Innostage. Например, настройки аудита ОС Windows в инструкции содержат детальное описание всех необходимых журналов ОС с примерами, для каких инцидентов информационной безопасности они могут быть использованы (одним из вариантов могут быть атаки с использованием Mimikatz или Impacket), как при централизованном ИБ-мониторинге на основе SIEM-решений, так и при проведении расследований компьютерных атак.

Реагирование

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

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