This media is not supported in your browser
VIEW IN TELEGRAM
Как выглядела уязвимость в Windows 98 (и почему она ей не считалась)
В прошлой статье я писал про PressAnyKey на максималках — и вспомнил, как в Windows 98 можно было войти в систему без пароля, просто вызвав Справку из окна печати (внимание — на видео).
Сейчас такое кажется дикостью, но когда-то сетевая аутентификация в Windows 98 была отдельным компонентом для установки. По умолчанию система предлагала ввести логин и пароль, которые затем использовались для доступа к сетевым ресурсам. А нажатие Esc загружало вход под локальным пользователем без всяких проверок. Чтобы сделать аутентификацию обязательной, требовалась особая настройка реестра — тогда система выдавала ошибку при попытке входа без пароля.
Но, как понятно из видео, можно было обойти и её.
Мораль
Не стоит думать, что современные уязвимости стали какими-то другими. В большинстве случаев это просто «фичи», о которых разработчики (пока) не подумали. Зачастую взлом происходит примерно как на видео — без магии и высоких технологий.
Разница в том, что сейчас анонимность и инструменты интернета позволяют эти трюки монетизировать. И наша задача как системных администраторов — знать эти трюки, чтобы лишать злодеев такого лёгкого заработка.
Всех приобнял.
В прошлой статье я писал про PressAnyKey на максималках — и вспомнил, как в Windows 98 можно было войти в систему без пароля, просто вызвав Справку из окна печати (внимание — на видео).
Сейчас такое кажется дикостью, но когда-то сетевая аутентификация в Windows 98 была отдельным компонентом для установки. По умолчанию система предлагала ввести логин и пароль, которые затем использовались для доступа к сетевым ресурсам. А нажатие Esc загружало вход под локальным пользователем без всяких проверок. Чтобы сделать аутентификацию обязательной, требовалась особая настройка реестра — тогда система выдавала ошибку при попытке входа без пароля.
Но, как понятно из видео, можно было обойти и её.
Мораль
Не стоит думать, что современные уязвимости стали какими-то другими. В большинстве случаев это просто «фичи», о которых разработчики (пока) не подумали. Зачастую взлом происходит примерно как на видео — без магии и высоких технологий.
Разница в том, что сейчас анонимность и инструменты интернета позволяют эти трюки монетизировать. И наша задача как системных администраторов — знать эти трюки, чтобы лишать злодеев такого лёгкого заработка.
Всех приобнял.
👍6🔥4❤2🤯1🫡1
1С как точка входа в домен
Чтобы вам не казалось, будто уязвимости бывают только в Microsoft — вот классика из мира 1С.
***
Практически в каждом аудите мы встречаем одно из двух:
1. Нет пароля на кластер администрирования 1С — создаём на сервере 1С свою базу, указывая в качестве SQL-сервера машину под своим управлением.
2. Нет пароля к тестовой базе («тут же нет данных — зачем пароль?») — загружаем внешнюю обработку в существующую конфигурацию.
В обоих случаях получаем консольный доступ к серверу 1С от имени учётной записи, под которой запущена служба (внимание на скриншот). И — барабанная дробь — в 90% случаев эта учётка имеет права локального администратора («ну чтобы лучше работало» 🙃).
Такая уязвимость встречается чаще, чем логин и пароль администратора домена, записанные на МФУ.
Что делать
1. Установить пароль на кластер администрирования.
2. Запускать службу 1С без прав локального администратора — она прекрасно работает и с правами локального пользователя.
3. Переслать этот пост разработчикам 1С, чтобы напомнить: пароль нужен везде, даже в «песочнице».
Ну и как обычно: ходите-оглядывайтесь
Чтобы вам не казалось, будто уязвимости бывают только в Microsoft — вот классика из мира 1С.
***
Практически в каждом аудите мы встречаем одно из двух:
1. Нет пароля на кластер администрирования 1С — создаём на сервере 1С свою базу, указывая в качестве SQL-сервера машину под своим управлением.
2. Нет пароля к тестовой базе («тут же нет данных — зачем пароль?») — загружаем внешнюю обработку в существующую конфигурацию.
В обоих случаях получаем консольный доступ к серверу 1С от имени учётной записи, под которой запущена служба (внимание на скриншот). И — барабанная дробь — в 90% случаев эта учётка имеет права локального администратора («ну чтобы лучше работало» 🙃).
Такая уязвимость встречается чаще, чем логин и пароль администратора домена, записанные на МФУ.
Что делать
1. Установить пароль на кластер администрирования.
2. Запускать службу 1С без прав локального администратора — она прекрасно работает и с правами локального пользователя.
3. Переслать этот пост разработчикам 1С, чтобы напомнить: пароль нужен везде, даже в «песочнице».
Ну и как обычно: ходите-оглядывайтесь
👍6🔥6❤3👏1
Почему одних обновлений недостаточно
Надеюсь, вы не пропустили октябрьскую историю с CVE-2025-59287 — уязвимостью, дающей доступ к серверам установки обновлений WSUS. Тот случай, когда система, предназначенная защищать, примкнула к злодеям.
• 14 октября Microsoft сообщила об уязвимости, которую уже вовсю эксплуатируют, и рекомендовала отключить WSUS.
• 23 октября — выпустила патч (даже для списанного Windows Server 2012).
Мы остановили WSUS у клиентов и стали разбираться, что это за новый зверь такой.
Вскрытие показало: стоит кому-то на сервере запустить консоль управления WSUS — мы получаем обратный shell от имени этого пользователя. Легко, быстро и без ограничений. Признак такой атаки — появление в консоли WSUS неизвестного компьютера с непонятной версией Windows.
На скриншотах из нашей лаборатории администратор домена открыл оснастку (ошибка и моргнувшее чёрное окно его не смутили), а мы получили обратный shell и создали себе учётную запись с такими же правами. Главное — дождаться момента открытия.
Ещё раз: Microsoft узнала об уязвимости, которую уже эксплуатируют, и закрыла её только через девять дней. У таких историй есть специальный термин — «уязвимость нулевого дня». Повезёт, если первым её обнаружит разработчик. Не повезёт — если злодеи.
Поэтому всегда нужны хотя бы базовые меры предосторожности
1. Не входить на рядовые серверы с учётной записью администратора домена. Полные права — только на контроллере домена. На остальные серверы — отдельные учётные записи (гуглите тировую систему).
2. Завершать сеанс сразу после работы. Это спасает хотя бы от скрипт-кидди, который проспит момент, когда вы зашли на сервер и вышли с него, оборвав обратный shell.
3. Установить и поддерживать антивирус на сервере. Даже штатный Defender режет большинство инструментов для обратного подключения — как минимум, атака будет требовать больше компетенций, чем даёт обычныйгуглинг дипсикинг.
4. Ну и, конечно, своевременно ставить обновления и следить за новыми уязвимостями.
Мы не можем защитить системы от всего. Какие-то дыры есть в них прямо сейчас — просто об этом ещё никто не знает. Наша задача — сделать так, чтобы инфраструктура выдержала атаку до момента, когда разработчики устранят эти «новые» уязвимости.
ЭТО БАЗА
Надеюсь, вы не пропустили октябрьскую историю с CVE-2025-59287 — уязвимостью, дающей доступ к серверам установки обновлений WSUS. Тот случай, когда система, предназначенная защищать, примкнула к злодеям.
• 14 октября Microsoft сообщила об уязвимости, которую уже вовсю эксплуатируют, и рекомендовала отключить WSUS.
• 23 октября — выпустила патч (даже для списанного Windows Server 2012).
Мы остановили WSUS у клиентов и стали разбираться, что это за новый зверь такой.
Вскрытие показало: стоит кому-то на сервере запустить консоль управления WSUS — мы получаем обратный shell от имени этого пользователя. Легко, быстро и без ограничений. Признак такой атаки — появление в консоли WSUS неизвестного компьютера с непонятной версией Windows.
На скриншотах из нашей лаборатории администратор домена открыл оснастку (ошибка и моргнувшее чёрное окно его не смутили), а мы получили обратный shell и создали себе учётную запись с такими же правами. Главное — дождаться момента открытия.
Ещё раз: Microsoft узнала об уязвимости, которую уже эксплуатируют, и закрыла её только через девять дней. У таких историй есть специальный термин — «уязвимость нулевого дня». Повезёт, если первым её обнаружит разработчик. Не повезёт — если злодеи.
Поэтому всегда нужны хотя бы базовые меры предосторожности
1. Не входить на рядовые серверы с учётной записью администратора домена. Полные права — только на контроллере домена. На остальные серверы — отдельные учётные записи (гуглите тировую систему).
2. Завершать сеанс сразу после работы. Это спасает хотя бы от скрипт-кидди, который проспит момент, когда вы зашли на сервер и вышли с него, оборвав обратный shell.
3. Установить и поддерживать антивирус на сервере. Даже штатный Defender режет большинство инструментов для обратного подключения — как минимум, атака будет требовать больше компетенций, чем даёт обычный
4. Ну и, конечно, своевременно ставить обновления и следить за новыми уязвимостями.
Мы не можем защитить системы от всего. Какие-то дыры есть в них прямо сейчас — просто об этом ещё никто не знает. Наша задача — сделать так, чтобы инфраструктура выдержала атаку до момента, когда разработчики устранят эти «новые» уязвимости.
ЭТО БАЗА
🔥8👍6🤯2😱1
И снова про WSUS
Раз уж подняли тему, давайте разберём ещё одну особенность «по умолчанию».
Во время развертывания WSUS мастер установки обычно информирует, что неплохо бы настроить SSL. Многие этот момент пропускают, и сервер продолжает работать по HTTP. Даже если включить SSL, клиенты будут ходить по HTTPS только за метаданными (списком обновлений), а сами файлы обновлений всё равно будут скачиваться по HTTP. И это не баг — а такая фича.
Хорошая новость: в самом скачивании по HTTP особой беды нет — Windows Update проверяет цифровую подпись каждого загруженного файла. Неподписанные просто не запустятся.
Плохая новость: PsExec (утилита для удалённого запуска процессов) подписана Microsoft. Значит, проверку пройдёт.
Как выглядит атака: на скриншотах — пример из нашей лаборатории. С помощью ARP spoofing мы подменили адрес WSUS-сервера у машины-жертвы — контроллера домена. Ждём его обращения к «подменному» WSUS и отдаём обновление в виде PsExec с параметрами установки — скриптом создания учётной записи и добавления её в администраторы.
Ни Defender ни Kaspersky даже не дёрнулись — всё чинно-благородно-штатно. Чистая, тихая и легитимная компрометация домена.
Что с этим делать
1. Перевести WSUS на SSL — Windows Update подключается только к серверу с валидным сертификатом. MITM в этом случае не сработает.
2. Изолировать WSUS и контроллеры домена — если всё находится в одном широковещательном домене, то у меня для вас плохие новости.
3. Включить сетевую защиту — Dynamic ARP Inspection, DHCP Snooping. Про IPv6 я уже писал. Это база.
4. Настроить мониторинг создания новых учётных записей — как минимум, увидите, что вас атакуют.
Общий вывод, надеюсь, понятен: такие «зонтичные» системы как WSUS, антивирус, мониторинг, резервное копирование, помимо возможностей несут в себе и риски. Защищать их нужно не меньше, чем контроллеры домена, ибо через них можно получить доступ ко всему остальному.
И это тоже БАЗА
Раз уж подняли тему, давайте разберём ещё одну особенность «по умолчанию».
Во время развертывания WSUS мастер установки обычно информирует, что неплохо бы настроить SSL. Многие этот момент пропускают, и сервер продолжает работать по HTTP. Даже если включить SSL, клиенты будут ходить по HTTPS только за метаданными (списком обновлений), а сами файлы обновлений всё равно будут скачиваться по HTTP. И это не баг — а такая фича.
Хорошая новость: в самом скачивании по HTTP особой беды нет — Windows Update проверяет цифровую подпись каждого загруженного файла. Неподписанные просто не запустятся.
Плохая новость: PsExec (утилита для удалённого запуска процессов) подписана Microsoft. Значит, проверку пройдёт.
Как выглядит атака: на скриншотах — пример из нашей лаборатории. С помощью ARP spoofing мы подменили адрес WSUS-сервера у машины-жертвы — контроллера домена. Ждём его обращения к «подменному» WSUS и отдаём обновление в виде PsExec с параметрами установки — скриптом создания учётной записи и добавления её в администраторы.
Ни Defender ни Kaspersky даже не дёрнулись — всё чинно-благородно-штатно. Чистая, тихая и легитимная компрометация домена.
Что с этим делать
1. Перевести WSUS на SSL — Windows Update подключается только к серверу с валидным сертификатом. MITM в этом случае не сработает.
2. Изолировать WSUS и контроллеры домена — если всё находится в одном широковещательном домене, то у меня для вас плохие новости.
3. Включить сетевую защиту — Dynamic ARP Inspection, DHCP Snooping. Про IPv6 я уже писал. Это база.
4. Настроить мониторинг создания новых учётных записей — как минимум, увидите, что вас атакуют.
Общий вывод, надеюсь, понятен: такие «зонтичные» системы как WSUS, антивирус, мониторинг, резервное копирование, помимо возможностей несут в себе и риски. Защищать их нужно не меньше, чем контроллеры домена, ибо через них можно получить доступ ко всему остальному.
И это тоже БАЗА
🔥12👍5❤2😱1
Если у вас паранойя — это не значит, что за вами не следят
Помните Эрнеста Хемингуэя? Писателя, которому годами твердили, что слежка ФБР это плод его воображения. А потом архивы рассекретили, и оказалось, что за ним и правда следили. Причём всерьёз.
А вот вам моя история
Всем нашим клиентам SMB наружу мы блокируем. Причина простая: по SMB в интернет ходят только для того, чтобы сливать злодеям NTLM-хэши. Но и этого нам мало, поэтому ещё мы логируем попытки таких подключений. Паранойя?
А оказывается вот что: на любой наш внешний сервис стабильно прилетают подключения с портами 135, 139 или 445 — классический набор для SMB. То есть злоумышленник подключается к веб-серверу по HTTPS (443-й порт), притворяясь при этом SMB-сервером.
Если соединение не проходит — он понимает, что SMB заблокирован, и идёт дальше.
Если проходит — значит, SMB открыт, и можно разворачивать фишинговые кампании со ссылками на внешние ресурсы. NTLM-хэши сами приплывут в руки, а инфраструктура вскроется как консервная банка (особенно если у клиента всё ещё живёт древний NTLMv1).
На скриншоте видно: проверяют не только SMB, но и LDAP, и SNMP. Зачем — неизвестно. Но, похоже, ботнет из ростовского «Электро-Кома» знает о жизни немного больше, чем его коллега из ярославского «Транстелекома».
Так что теперь официально: за всеми следят. Круглосуточно, методично, без выходных и перерывов на обед.
Живите теперь с этим.
Что можно сделать — напишу в комментариях
Помните Эрнеста Хемингуэя? Писателя, которому годами твердили, что слежка ФБР это плод его воображения. А потом архивы рассекретили, и оказалось, что за ним и правда следили. Причём всерьёз.
А вот вам моя история
Всем нашим клиентам SMB наружу мы блокируем. Причина простая: по SMB в интернет ходят только для того, чтобы сливать злодеям NTLM-хэши. Но и этого нам мало, поэтому ещё мы логируем попытки таких подключений. Паранойя?
А оказывается вот что: на любой наш внешний сервис стабильно прилетают подключения с портами 135, 139 или 445 — классический набор для SMB. То есть злоумышленник подключается к веб-серверу по HTTPS (443-й порт), притворяясь при этом SMB-сервером.
Если соединение не проходит — он понимает, что SMB заблокирован, и идёт дальше.
Если проходит — значит, SMB открыт, и можно разворачивать фишинговые кампании со ссылками на внешние ресурсы. NTLM-хэши сами приплывут в руки, а инфраструктура вскроется как консервная банка (особенно если у клиента всё ещё живёт древний NTLMv1).
На скриншоте видно: проверяют не только SMB, но и LDAP, и SNMP. Зачем — неизвестно. Но, похоже, ботнет из ростовского «Электро-Кома» знает о жизни немного больше, чем его коллега из ярославского «Транстелекома».
Так что теперь официально: за всеми следят. Круглосуточно, методично, без выходных и перерывов на обед.
Живите теперь с этим.
Что можно сделать — напишу в комментариях
👍17😱5❤4
Выдал БАЗУ: как защитить корпоративную ИТ-инфраструктуру... хотя бы от меня.
👉 Читать на Хабре
Пользуйтесь, благодарите.
P.S. Дальше в канале буду разбирать каждый пункт подробно — с примерами из жизни и поправками на личные предубеждения.
👉 Читать на Хабре
Пользуйтесь, благодарите.
P.S. Дальше в канале буду разбирать каждый пункт подробно — с примерами из жизни и поправками на личные предубеждения.
Хабр
Нет времени объяснять — это БАЗА: чек-лист защиты корпоративной инфраструктуры
Сложно ли взломать вашу инфраструктуру? Во время аудита у меня на это уходит от 15 минут до 8 часов . И это не потому, что у клиентов нет SOC, NGFW, WAF, MFA и других атрибутов безопасности — тот же...
🔥21👍8❤3👏3
Каждый раз, когда речь заходит об отключении SMBv1 и изоляции МФУ в отдельном VLAN, появляется кавалерия на старых Kyocera и Ricoh — и вступает со мной в бой. Публикация на Хабре не стала исключением.
Риторика примерно такая:
«SMB1 отключить нельзя — у нас Ricoh с 2006 года. Он ещё Лужкова помнит!»
«Да этот принтер сотню Бразеров пережил — пусть и дальше живёт»
«NGFW поставьте и хоть по FTP передавайте!»
«Как изолировать МФУ? Пользователи привыкли сканировать себе на комп!»
Ну и хит сезона: «Если сервер печати видит МФУ, значит МФУ не изолированы!»
И каждый раз мне хочется задать вопрос: «Вот вы сейчас серьёзно?»
Это здорово, когда техника настолько надёжна, что повидала уже три поколения администраторов. Не очень здорово — когда вместе с опытом она несёт в себе и три поколения уязвимостей.
Может принтер и пережил кучу Бразеров — но переживёт ли он студента с пятью командами в терминале?
NGFW? Отлично. Но это как повесить камеру над дырой в заборе: дыра от этого не зарастёт. Кто пролезет — вы увидите. Но уже постфактум.
Привычки пользователей? Аргумент. Но стоят ли они того, чтобы остаться без результатов труда?
Ну и да: изоляция — это не когда к системе «ничего не подключено», а когда подключено только то, что нужно, и только так, как нужно.
Про МФУ (и SMBv1) я уже написал столько, что можно делать отдельный курс:
• Почему нельзя использовать SMBv1
• Почему нужно менять дефолтные пароли на МФУ и включать SMB-signing
• Зачем избавляться от SMBv1-устройств и изолировать МФУ в отдельном VLAN
• Зачем отключать неиспользуемые протоколы на МФУ
• Почему нельзя использовать привилегированные учётные записи на МФУ
Почему я так много об этом говорю? Да потому что в 4 из 5 аудитов безопасности МФУ оказываются удобной точкой входа в домен. Это стабильная ошибка, которой лет 15 и которая до сих пор встречается регулярно.
Поэтому повторю ещё раз, медленно и чётко:
1. Никакого SMBv1. Ни при каких сценариях.
2. МФУ — только в отдельном VLAN, недоступном из пользовательской сети.
3. Никаких дефолтных паролей.
4. Никаких привилегированных учётных записей.
5. Прошивки МФУ обновляем. Ненужные протоколы — выключаем.
Это не «параноидальные требования». Это база.
Риторика примерно такая:
«SMB1 отключить нельзя — у нас Ricoh с 2006 года. Он ещё Лужкова помнит!»
«Да этот принтер сотню Бразеров пережил — пусть и дальше живёт»
«NGFW поставьте и хоть по FTP передавайте!»
«Как изолировать МФУ? Пользователи привыкли сканировать себе на комп!»
Ну и хит сезона: «Если сервер печати видит МФУ, значит МФУ не изолированы!»
И каждый раз мне хочется задать вопрос: «Вот вы сейчас серьёзно?»
Это здорово, когда техника настолько надёжна, что повидала уже три поколения администраторов. Не очень здорово — когда вместе с опытом она несёт в себе и три поколения уязвимостей.
Может принтер и пережил кучу Бразеров — но переживёт ли он студента с пятью командами в терминале?
NGFW? Отлично. Но это как повесить камеру над дырой в заборе: дыра от этого не зарастёт. Кто пролезет — вы увидите. Но уже постфактум.
Привычки пользователей? Аргумент. Но стоят ли они того, чтобы остаться без результатов труда?
Ну и да: изоляция — это не когда к системе «ничего не подключено», а когда подключено только то, что нужно, и только так, как нужно.
Про МФУ (и SMBv1) я уже написал столько, что можно делать отдельный курс:
• Почему нельзя использовать SMBv1
• Почему нужно менять дефолтные пароли на МФУ и включать SMB-signing
• Зачем избавляться от SMBv1-устройств и изолировать МФУ в отдельном VLAN
• Зачем отключать неиспользуемые протоколы на МФУ
• Почему нельзя использовать привилегированные учётные записи на МФУ
Почему я так много об этом говорю? Да потому что в 4 из 5 аудитов безопасности МФУ оказываются удобной точкой входа в домен. Это стабильная ошибка, которой лет 15 и которая до сих пор встречается регулярно.
Поэтому повторю ещё раз, медленно и чётко:
1. Никакого SMBv1. Ни при каких сценариях.
2. МФУ — только в отдельном VLAN, недоступном из пользовательской сети.
3. Никаких дефолтных паролей.
4. Никаких привилегированных учётных записей.
5. Прошивки МФУ обновляем. Ненужные протоколы — выключаем.
Это не «параноидальные требования». Это база.
🔥18👍11❤5✍2🫡1
Почему нам придётся отключить NTLM
Когда-то я обещал рассказать, зачем отказываться от NTLM и переезжать на Kerberos. Пришло время это сделать( тот пост набрал нужное количество лайков).
Как известно, аутентификация в домене Windows опирается на два протокола: Kerberos и NTLM. Существуя параллельно, они имеют разную модель безопасности.
Kerberos работает с билетами. Клиент получает у контроллера домена билет, зашифрованный паролем сервера или сервиса, и передаёт его при подключении:
• билет может быть принят только тем сервисом, для которого он выпущен;
• перехваченный билет нельзя использовать на другом сервере;
• расшифровать билет практически нереально (пароль учётной записи сервера — 120 символов).
NTLM устроен сильно проще:
• нет жёсткой привязки аутентификации к конкретному серверу;
• клиент фактически передаёт серверу хэш пароля пользователя;
• перехваченную аутентификацию можно перенаправить на другой сервер или сервис;
Именно эти свойства и делают NTLM удобной и устойчивой целью для офлайн-подбора пароля и атаки класса relay.
Почему NTLM всё еще используется и чем это опасно
Windows в домене всегда старается в первую очередь использовать аутентификацию Kerberos. Но при любой проблеме (обращение к серверу по IP-адресу, подключение к неизвестному хосту, некорректно настроенный SPN) система автоматически откатывается на NTLM. Формально это сделано для удобства пользователя, а по факту — упрощает работу злоумышленника.
На механизме fallback к NTLM завязано множество атак:
• Coerce-атаки
• Перехваты NetBIOS, LLMNR, mDNS, WPAD
• Атаки с подменой IPv6
Кстати, про офлайн-брут: NTLM появился в 1993 году. Тогда считалось, что вычислить пароль по хэшу — нереально. Сейчас пароль из семи случайных символов подбирается на домашней видеокарте за 17 минут. Учитывая, что аренда GPU теперь доступна буквально по подписке, окончательное признание NTLM небезопасным — лишь вопрос времени.
Так нужен ли NTLM в современной инфраструктуре
На практике — почти никогда. Если не считать экзотику подключений по IP-адресам, единственный по-настоящему массовый случай — почтовые клиенты и Exchange (особенно при работе из интернета). В остальных сценариях NTLM не добавляет функциональности, существенно снижает уровень безопасности и живёт в инфраструктуре по инерции.
Рационально — запретить исходящий NTLM с серверов и рабочих станций в домене и оставить исключения только там, где без него действительно нельзя (тот же Exchange). А для привилегированных учётных записей в домене не лишним будет напомнить о группе Protected Users, которая в том числе отключает NTLM на уровне учётной записи.
Блокируя исходящий NTLM можно предотвратить утечки данных при обращении к сторонним ресурсам, резко сократить класс атак внутри домена и сделать поведение аутентификации предсказуемым.
Как жить с NTLM там, где его нельзя отключить
1. Если NTLM всё же разрешён, к таким сервисам нельзя подключаться с привилегированными учётными записями. Отсюда логичное следствие — у администраторов домена не должно быть почтовых ящиков на Exchange.
2. Для компьютеров, не входящих в домен, Kerberos неприменим — аутентификация всегда будет по NTLM. Значит, подключение к таким системам с правами локального администратора должно быть запрещено.
3. Корректный сценарий для недоменных систем — вход под обычным пользователем с последующим повышением привилегий внутри уже установленного защищённого сеанса. Ну и пароли к недоменным системам должны быть длиннее, чем к доменным.
Disclaimer
Отключение даже исходящего NTLM — процесс, требующий подготовки и тестирования. В эти моменты почти всегда всплывают вещи, которые годами работали «по IP и по привычке» — и к этому нужно быть готовыми. Однако результат в виде более устойчивой и защищённой инфраструктуры того стоит.
Дерзайте!
И не забывайте, что лайки — это путь к просвещению
Когда-то я обещал рассказать, зачем отказываться от NTLM и переезжать на Kerberos. Пришло время это сделать
Как известно, аутентификация в домене Windows опирается на два протокола: Kerberos и NTLM. Существуя параллельно, они имеют разную модель безопасности.
Kerberos работает с билетами. Клиент получает у контроллера домена билет, зашифрованный паролем сервера или сервиса, и передаёт его при подключении:
• билет может быть принят только тем сервисом, для которого он выпущен;
• перехваченный билет нельзя использовать на другом сервере;
• расшифровать билет практически нереально (пароль учётной записи сервера — 120 символов).
NTLM устроен сильно проще:
• нет жёсткой привязки аутентификации к конкретному серверу;
• клиент фактически передаёт серверу хэш пароля пользователя;
• перехваченную аутентификацию можно перенаправить на другой сервер или сервис;
Именно эти свойства и делают NTLM удобной и устойчивой целью для офлайн-подбора пароля и атаки класса relay.
Почему NTLM всё еще используется и чем это опасно
Windows в домене всегда старается в первую очередь использовать аутентификацию Kerberos. Но при любой проблеме (обращение к серверу по IP-адресу, подключение к неизвестному хосту, некорректно настроенный SPN) система автоматически откатывается на NTLM. Формально это сделано для удобства пользователя, а по факту — упрощает работу злоумышленника.
На механизме fallback к NTLM завязано множество атак:
• Coerce-атаки
• Перехваты NetBIOS, LLMNR, mDNS, WPAD
• Атаки с подменой IPv6
Кстати, про офлайн-брут: NTLM появился в 1993 году. Тогда считалось, что вычислить пароль по хэшу — нереально. Сейчас пароль из семи случайных символов подбирается на домашней видеокарте за 17 минут. Учитывая, что аренда GPU теперь доступна буквально по подписке, окончательное признание NTLM небезопасным — лишь вопрос времени.
Так нужен ли NTLM в современной инфраструктуре
На практике — почти никогда. Если не считать экзотику подключений по IP-адресам, единственный по-настоящему массовый случай — почтовые клиенты и Exchange (особенно при работе из интернета). В остальных сценариях NTLM не добавляет функциональности, существенно снижает уровень безопасности и живёт в инфраструктуре по инерции.
Рационально — запретить исходящий NTLM с серверов и рабочих станций в домене и оставить исключения только там, где без него действительно нельзя (тот же Exchange). А для привилегированных учётных записей в домене не лишним будет напомнить о группе Protected Users, которая в том числе отключает NTLM на уровне учётной записи.
Блокируя исходящий NTLM можно предотвратить утечки данных при обращении к сторонним ресурсам, резко сократить класс атак внутри домена и сделать поведение аутентификации предсказуемым.
Как жить с NTLM там, где его нельзя отключить
1. Если NTLM всё же разрешён, к таким сервисам нельзя подключаться с привилегированными учётными записями. Отсюда логичное следствие — у администраторов домена не должно быть почтовых ящиков на Exchange.
2. Для компьютеров, не входящих в домен, Kerberos неприменим — аутентификация всегда будет по NTLM. Значит, подключение к таким системам с правами локального администратора должно быть запрещено.
3. Корректный сценарий для недоменных систем — вход под обычным пользователем с последующим повышением привилегий внутри уже установленного защищённого сеанса. Ну и пароли к недоменным системам должны быть длиннее, чем к доменным.
Disclaimer
Отключение даже исходящего NTLM — процесс, требующий подготовки и тестирования. В эти моменты почти всегда всплывают вещи, которые годами работали «по IP и по привычке» — и к этому нужно быть готовыми. Однако результат в виде более устойчивой и защищённой инфраструктуры того стоит.
Дерзайте!
И не забывайте, что лайки — это путь к просвещению
👍21🔥20❤4😱1
🎄 Все люди как люди — украшают ёлки. А мы — серверные стойки
Перед вами серия фотографий серверной стойки клиента в трёх состояниях.
Состояние «До»: доступ заблокирован проводами, но общее представление получить можно — хаос и тлен.
Состояние «В процессе»: подход «разминирован» — выброшено всё, что давно нужно было списать.
Состояние «После»: в стойке навели порядок как могли.
А теперь — к конкретике: что мы сделали
1. Промаркировали оборудование: на каждом — наклейка с сетевым именем.
2. Проложили патч-корды так, чтобы они не перекрывали доступ к индикации, и применили цветовую маркировку:
• синий — пользовательские устройства (принтеры, компьютеры)
• жёлтый — L2-устройства (точки доступа, коммутаторы)
• красный — подключение маршрутизаторов к коммутаторам
• зелёный — СХД и серверы
• оранжевый — интерфейсы управления СХД, серверами и ИБП
3. Подвели единственный канал интернета к основному маршрутизатору так, чтобы его можно было легко переключить на резервный.
4. Смонтировали PDU с удобным доступом для включения и отключения.
5. Подключили оборудование проводами питания с цветомаркировкой:
• красный и синий — резервные БП
• чёрный — одиночный БП
• оранжевый — холодный резерв (отключено)
6. Промаркировали кабели питания и PDU: в месте подключения — имя устройства, на PDU — номер ИБП.
7. Открыли свободный доступ к серверной стойке со всех сторон. Любое оборудование теперь можно извлечь без разбора половины шкафа.
На работу ушло более 16 часов, которые были распределены на несколько месяцев итераций.
Зачем мы так упарываемся
Чтобы в случае аварийной ситуации не накосячить самим и не превратить рядовой сбой в катастрофу. Потому что в стрессовой ситуации ты не поднимаешься на уровень своих ожиданий, а падаешь на уровень своей подготовки.
Маркировка и логика в серверном шкафу для нас — не «эстетика», а часть тренировочного процесса.
Это база, на которой строится стабильная работа систем.
Перед вами серия фотографий серверной стойки клиента в трёх состояниях.
Состояние «До»: доступ заблокирован проводами, но общее представление получить можно — хаос и тлен.
Состояние «В процессе»: подход «разминирован» — выброшено всё, что давно нужно было списать.
Состояние «После»: в стойке навели порядок как могли.
А теперь — к конкретике: что мы сделали
1. Промаркировали оборудование: на каждом — наклейка с сетевым именем.
2. Проложили патч-корды так, чтобы они не перекрывали доступ к индикации, и применили цветовую маркировку:
• синий — пользовательские устройства (принтеры, компьютеры)
• жёлтый — L2-устройства (точки доступа, коммутаторы)
• красный — подключение маршрутизаторов к коммутаторам
• зелёный — СХД и серверы
• оранжевый — интерфейсы управления СХД, серверами и ИБП
3. Подвели единственный канал интернета к основному маршрутизатору так, чтобы его можно было легко переключить на резервный.
4. Смонтировали PDU с удобным доступом для включения и отключения.
5. Подключили оборудование проводами питания с цветомаркировкой:
• красный и синий — резервные БП
• чёрный — одиночный БП
• оранжевый — холодный резерв (отключено)
6. Промаркировали кабели питания и PDU: в месте подключения — имя устройства, на PDU — номер ИБП.
7. Открыли свободный доступ к серверной стойке со всех сторон. Любое оборудование теперь можно извлечь без разбора половины шкафа.
На работу ушло более 16 часов, которые были распределены на несколько месяцев итераций.
Зачем мы так упарываемся
Чтобы в случае аварийной ситуации не накосячить самим и не превратить рядовой сбой в катастрофу. Потому что в стрессовой ситуации ты не поднимаешься на уровень своих ожиданий, а падаешь на уровень своей подготовки.
Маркировка и логика в серверном шкафу для нас — не «эстетика», а часть тренировочного процесса.
Это база, на которой строится стабильная работа систем.
🔥21👍12❤6✍1
🎁 С наступающим! Я с подарком
Поскольку канал вместе с его автором уходит на каникулы, новостей до середины января не ждите (я не настоящий блогер, я только учусь!)
Чтобы в это время вам было чем заняться, делюсь утилитой для диагностики безопасности Active Directory — PingCastle.
Запускается под рядовым пользователем домена. Три раза нажимаете Enter — и утилита проверяет домен по 180 пунктам. На выходе формирует HTML-отчёт по безопасности. В начале — общая оценка. Ниже — детальное описание того, что именно, где и как она накопала.
В прикреплённых файлах — скриншоты из PingCastle до и после харденинга не самого запущенного домена. На такой результат (не только в части PingCastle, конечно) ушёл почти год работы.
Желаю вам в новом году пройти этот путь в разы быстрее. Со своей стороны постараюсь помочь — как знаниями, так и стимулами.
Всех приобнял 👋
Поскольку канал вместе с его автором уходит на каникулы, новостей до середины января не ждите (я не настоящий блогер, я только учусь!)
Чтобы в это время вам было чем заняться, делюсь утилитой для диагностики безопасности Active Directory — PingCastle.
Запускается под рядовым пользователем домена. Три раза нажимаете Enter — и утилита проверяет домен по 180 пунктам. На выходе формирует HTML-отчёт по безопасности. В начале — общая оценка. Ниже — детальное описание того, что именно, где и как она накопала.
В прикреплённых файлах — скриншоты из PingCastle до и после харденинга не самого запущенного домена. На такой результат (не только в части PingCastle, конечно) ушёл почти год работы.
Желаю вам в новом году пройти этот путь в разы быстрее. Со своей стороны постараюсь помочь — как знаниями, так и стимулами.
Всех приобнял 👋
🎉22👍7🔥7🎅4