Буду благодарен за инструкцию о том, как запустить Zabbix Agent на Windows не под Local System и чтобы при этом работали хотя бы базовые проверки плюс performance counters.
— Используя MITM атаки на инфраструктуру (в статье упоминается ARP spoofing) можно перехватить данные, в т.ч. логины/пароли, куки/sessiondid и т.п. секретные вещи, особенно если они не зашифрованы.
— Если вы не обновляетесь — вы можете быть уязвимы.
— Если вы не меняете дефолтные логин и пароль, то его может знать кто-то кроме вас.
— Если вы разрешили в агентах системы мониторинга удалённое исполнение команд (EnableRemoteCommands=1 для Zabbix агента), а сам агент запущен от LOCAL SYSTEM или подобного привилегированного пользователя, то компрометация системы мониторинга компрометирует всю инфраструктуру с которой работает эта система. Аналогично с параметрами, спецсимволами можно экранироваться и выполнить инъекции команд (UnsafeUserParameters=1 для Zabbix агента, Unsafe как-бы намекает). По умолчанию это отключено.
Все эти вектора имеют весьма посредственное отношение к системам мониторинга и в полной мере применимы к абсолютно любой системе с централизованным управлением с учётом описанных выше допущений.
Это может быть и AD, и любая система управления конфигурацией типа SCCM и т.п., и даже сервер администрирования антивируса, например KAV, и ещё неисчислимое множество их комбинаций.
Добавлю свои 5 копеек про SRP/AppLocker.
Все знают что SRP/AppLocker можно обойти. Это легко гуглится по «SRP/AppLocker bypass».
В нагрузку к этому Microsoft не считает это настоящими уязвимостями по простой причине — эти продукты не задумывались как средства обеспечения безопасности изначально, и поэтому были разработаны соответствующим образом, и поэтому столько способов их обхода. ( www.securityfocus.com/archive/1/540310 )
AppLocker только дополняет WDDG. Защита всегда состоит из слоёв, и лучше — когда их больше.
Если WDAC чересчур сложно и ограничиваться только AppLocker'ом, то перед тем как спать спокойно, необходимо заблокировать все методы, которые выдаёт гугл по запросам SRP/AppLocker Bypass и Hardening.
атака подменой исполняемого файла выглядит вполне реализуемой
В такой ситуации, это то, что называется preimage attack, т.е. у вас есть известный хеш, вам надо создать файл с таким же хешем.
Это для SHA1 пока-что не реализуемо (не нашли такую уязвимость в алгоритме, которая позволит понизить требуемую вычислительную мощность для перебора и уйти от прямого brute-force).
Поэтому само по себе подменить один заданный файл на второй файл с таким же хешем пока не выйдет.
Основная проблема с SHA1 коллизией, в том, что этим алгоритмом хеширования пользуются CA для подписи сертификата (digital signature). Т.е. возможно при определённых условиях получить сертификат с подписью идентичной подписи уже ранее выпущенного сертификата (только подпись, не закрытый ключ) и, например, подписать им код, и ему будут доверять, т.к. поддельный сертификат будет проходить проверку на валидность (это верная цепочка доверия до корневого CA плюс проверка на отзыв), хоть при этом и не будет являться идентичным сертификатом. Одно из этих определённых условий — предсказуемость полного содержимого сертификата (того сообщения, которое будет подвергнуто хешированию самим CA). CA с этим борется путём увеличения энтропии этого сообщения, т.е. делая его непредсказуемым и исключая известные векторы атаки в содержимом запросов. Плюс ужесточая проверку в реальном мире(документы, юрлица, звонки) при получении Code Signing сертификатов.
Такую подмену смогли сделать пока только для MD5.
Поэтому как раз подмена файла на файл с таким же хешем выглядит маловероятно.
На данный момент гораздо более вероятной выглядит угроза компрометации сертификатов. Поэтому CA так торопятся уйти от SHA1 одними из первых.
Это справедливо и для файлов, которые заверены подписью в PE заголовке или отдельно, через catroot.
В любом случае, если злоумышленник хозяйничает в каталоге ОС, то уже поздно. Это просто плюс один способ дольше оставаться незамеченным.
Диалог начался с того предположения, что подписи нет вообще. По факту она есть, просто не в PE заголовке.
Подобрать к уже существующему хешу файл с таким же хешем и подобрать два произвольных документа с одинаковым хешем — разные вещи. (вот тут разъясняют blog.cloudflare.com/why-its-harder-to-forge-a-sha-1-certificate-than-it-is-to-find-a-sha-1-collision )
Пишут, что second-preimage attack даже на MD5 ещё не найдена.
Статья хоть и 2015 года, но всё ещё соответствует реалиям, SHA1 уже в то время считался не самым стойким алгоритмом хеширования.
Плюс найденные(опубликованные) векторы коллизии в SHA1 известны и нормальные CA не должны выдавать сертификаты в которых замечают подобное, таким образом компенсировать этот риск (ещё там энтропия и непредсказуемость).
(пример github.com/cr-marcstevens/sha1collisiondetection)
Поэтому провести атаку с подменой файла, подписанного SHA1, всё ещё выглядит нереальным. Скорее, более уязвимыми в этом плане являются сами сертификаты, при помощи которых осуществляется подпись, т.е. CA, которая их выдаёт.
10 Мбит/с вполне достаточно для комфортной работы.
Спорное заявление, если учесть, что тот же iDRAC позволяет монтировать ISO (например, для установки системы).
При скорости в 10Мбит — это откровенное издевательство.
Например, ISO Windows Server 2016 (X21-30350) 5750МБ придётся ждать 75 минут. При том что сама по себе установка(с той же USB флешки) занимает меньше 10 минут.
Наша ситуация при внедрении page compression была аналогичной, но риск полностью оправдался.
Мануалы и специалист MS всегда скажут что оно потребляет ресурсы, но никогда не скажут сколько т.к. не будут брать на себя ответственность за то что творится в вашей БД. Да и в тех же мануалах написано что для каждого случая надо тестировать и цифр нет.
Даже если само page compression потребляет ресурсы CPU с одной стороны, то с другой — оно позволяет транзакциям проходить быстрее за счёт меньшей нагрузки на диск и buffer pool и т.о. снижает потребление ресурсов CPU на блокировках.
В целом — рекомендую вам протестировать этот способ, он может дать заметно больший эффект чем sparse columns.
Чтобы снизить риски — начните с применения сжатия на не самых критичных таблицах.
Проводили ли вы тестирование вариантов со сжатием данных? Интересно увидеть ваши цифры нагрузки на CPU со включенным сжатием и без.
Сами активно используем page compression при аналогичном порядке размера БД и некоторых таблиц. Какого либо существенного прироста нагрузки на CPU не заметили (на уровне шума 2-3%). При этом оно заметно снижает нагрузку на диск, объём хранимых данных на диске и в памяти (buffer pool).
Очень полезная фича, с учётом того, что она стала доступна в SQL Standard 2016 (после SP1).
1. Про локальные диски: с точки зрения безопасности наилучшим решением будет верно настроить ACL на самих дисках. например забрать у пользователей права на создание файлов, CREATOR OWNER и т.п. и оставить только traverse+list folder в корне. Каталоги Windows и Program Files по умолчанию не наследуют разрешения от корня диска, поэтому там права на чтение/выполнение не пропадут. Hide these specified drives in My Computer и Prevent access to drives from My Computer больше косметические политики, чем относящиеся к безопасности.
2. «Убираем кнопки выключения \ перезагрузки \ сна» — зачем, если SeShutdownPrivilege по умолчанию доступно только Backup Operators и Administrators? Обычные пользователи по умолчанию не входят в эти группы и не видят опций Shutdown/reboot.
3. «Запрещаем Автозапуск «Управление сервером» при логине». Аналогично. У обычных пользователей Server Manager не включается.
4. «Запрещаем запуск редактора реестра». Regedit требует прав администратора при запуске. Плюс стандартные ACL в реестре по умолчанию обычному пользователю не дадут что либо редактировать, кроме HKCU.
5. Почему для запрета запуска некоторых приложений предлагается использовать отдельные политики и реестр, а не AppLocker/SRP, которые специально для этого созданы и в целом более гибкие (можно разрешать/запрещать по хэшу, цифровой подписи)? В AppLocker, например, по умолчанию действует «запрещено всё, что не разрешено» и запустить приложение из собственного профиля (с рабочего стола/temp и т.д.) пользователь не сможет.
— Используя MITM атаки на инфраструктуру (в статье упоминается ARP spoofing) можно перехватить данные, в т.ч. логины/пароли, куки/sessiondid и т.п. секретные вещи, особенно если они не зашифрованы.
— Если вы не обновляетесь — вы можете быть уязвимы.
— Если вы не меняете дефолтные логин и пароль, то его может знать кто-то кроме вас.
— Если вы разрешили в агентах системы мониторинга удалённое исполнение команд (EnableRemoteCommands=1 для Zabbix агента), а сам агент запущен от LOCAL SYSTEM или подобного привилегированного пользователя, то компрометация системы мониторинга компрометирует всю инфраструктуру с которой работает эта система. Аналогично с параметрами, спецсимволами можно экранироваться и выполнить инъекции команд (UnsafeUserParameters=1 для Zabbix агента, Unsafe как-бы намекает). По умолчанию это отключено.
Все эти вектора имеют весьма посредственное отношение к системам мониторинга и в полной мере применимы к абсолютно любой системе с централизованным управлением с учётом описанных выше допущений.
Это может быть и AD, и любая система управления конфигурацией типа SCCM и т.п., и даже сервер администрирования антивируса, например KAV, и ещё неисчислимое множество их комбинаций.
Следующий слой защиты — запретить исполнение скриптов тем или иным образом.
После этого — запретить неподписанные исполняемые файлы/dll.
Этот момент тоже не очень понял.
Может мы рассмотрим конкретный сценарий обхода?
Вот тут разъяснено неплохо, плюс скрипты: social.technet.microsoft.com/wiki/contents/articles/4197.how-to-list-all-of-the-windows-and-software-updates-applied-to-a-computer.aspx
Не надо так, это плохой совет. .NET Framework отсутствует в этом списке у большей части пользователей свежих версий Windows.
Вот правильный способ: docs.microsoft.com/ru-ru/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed
Все знают что SRP/AppLocker можно обойти. Это легко гуглится по «SRP/AppLocker bypass».
В нагрузку к этому Microsoft не считает это настоящими уязвимостями по простой причине — эти продукты не задумывались как средства обеспечения безопасности изначально, и поэтому были разработаны соответствующим образом, и поэтому столько способов их обхода. ( www.securityfocus.com/archive/1/540310 )
Возникает вопрос: а что тогда задумывалось?
Эта штука называется Windows Defender Device Guard/Windows Defender Application Control. ( docs.microsoft.com/en-us/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies )
Грубо говоря, политика WDDG позволит запретить запуск неподписанного кода на устройствах. Если необходимо запускать приложения, на которых нет цифровой подписи, то подписать их можно самостоятельно.
Так же WDDG добавляет дополнительные уровни изоляции для некоторых критически важных областей системы.
AppLocker только дополняет WDDG. Защита всегда состоит из слоёв, и лучше — когда их больше.
Если WDAC чересчур сложно и ограничиваться только AppLocker'ом, то перед тем как спать
спокойно, необходимо заблокировать все методы, которые выдаёт гугл по запросам SRP/AppLocker Bypass и Hardening.В такой ситуации, это то, что называется preimage attack, т.е. у вас есть известный хеш, вам надо создать файл с таким же хешем.
Это для SHA1 пока-что не реализуемо (не нашли такую уязвимость в алгоритме, которая позволит понизить требуемую вычислительную мощность для перебора и уйти от прямого brute-force).
Поэтому само по себе подменить один заданный файл на второй файл с таким же хешем пока не выйдет.
Основная проблема с SHA1 коллизией, в том, что этим алгоритмом хеширования пользуются CA для подписи сертификата (digital signature). Т.е. возможно при определённых условиях получить сертификат с подписью идентичной подписи уже ранее выпущенного сертификата (только подпись, не закрытый ключ) и, например, подписать им код, и ему будут доверять, т.к. поддельный сертификат будет проходить проверку на валидность (это верная цепочка доверия до корневого CA плюс проверка на отзыв), хоть при этом и не будет являться идентичным сертификатом. Одно из этих определённых условий — предсказуемость полного содержимого сертификата (того сообщения, которое будет подвергнуто хешированию самим CA). CA с этим борется путём увеличения энтропии этого сообщения, т.е. делая его непредсказуемым и исключая известные векторы атаки в содержимом запросов. Плюс ужесточая проверку в реальном мире(документы, юрлица, звонки) при получении Code Signing сертификатов.
Такую подмену смогли сделать пока только для MD5.
Поэтому как раз подмена файла на файл с таким же хешем выглядит маловероятно.
На данный момент гораздо более вероятной выглядит угроза компрометации сертификатов. Поэтому CA так торопятся уйти от SHA1 одними из первых.
Это справедливо и для файлов, которые заверены подписью в PE заголовке или отдельно, через catroot.
В любом случае, если злоумышленник хозяйничает в каталоге ОС, то уже поздно. Это просто плюс один способ дольше оставаться незамеченным.
Диалог начался с того предположения, что подписи нет вообще. По факту она есть, просто не в PE заголовке.
Пишут, что second-preimage attack даже на MD5 ещё не найдена.
Статья хоть и 2015 года, но всё ещё соответствует реалиям, SHA1 уже в то время считался не самым стойким алгоритмом хеширования.
Плюс найденные(опубликованные) векторы коллизии в SHA1 известны и нормальные CA не должны выдавать сертификаты в которых замечают подобное, таким образом компенсировать этот риск (ещё там энтропия и непредсказуемость).
(пример github.com/cr-marcstevens/sha1collisiondetection)
Поэтому провести атаку с подменой файла, подписанного SHA1, всё ещё выглядит нереальным. Скорее, более уязвимыми в этом плане являются сами сертификаты, при помощи которых осуществляется подпись, т.е. CA, которая их выдаёт.
Спорное заявление, если учесть, что тот же iDRAC позволяет монтировать ISO (например, для установки системы).
При скорости в 10Мбит — это откровенное издевательство.
Например, ISO Windows Server 2016 (X21-30350) 5750МБ придётся ждать 75 минут. При том что сама по себе установка(с той же USB флешки) занимает меньше 10 минут.
Мануалы и специалист MS всегда скажут что оно потребляет ресурсы, но никогда не скажут сколько т.к. не будут брать на себя ответственность за то что творится в вашей БД. Да и в тех же мануалах написано что для каждого случая надо тестировать и цифр нет.
Даже если само page compression потребляет ресурсы CPU с одной стороны, то с другой — оно позволяет транзакциям проходить быстрее за счёт меньшей нагрузки на диск и buffer pool и т.о. снижает потребление ресурсов CPU на блокировках.
В целом — рекомендую вам протестировать этот способ, он может дать заметно больший эффект чем sparse columns.
Чтобы снизить риски — начните с применения сжатия на не самых критичных таблицах.
Сами активно используем page compression при аналогичном порядке размера БД и некоторых таблиц. Какого либо существенного прироста нагрузки на CPU не заметили (на уровне шума 2-3%). При этом оно заметно снижает нагрузку на диск, объём хранимых данных на диске и в памяти (buffer pool).
Очень полезная фича, с учётом того, что она стала доступна в SQL Standard 2016 (после SP1).
2. «Убираем кнопки выключения \ перезагрузки \ сна» — зачем, если SeShutdownPrivilege по умолчанию доступно только Backup Operators и Administrators? Обычные пользователи по умолчанию не входят в эти группы и не видят опций Shutdown/reboot.
3. «Запрещаем Автозапуск «Управление сервером» при логине». Аналогично. У обычных пользователей Server Manager не включается.
4. «Запрещаем запуск редактора реестра». Regedit требует прав администратора при запуске. Плюс стандартные ACL в реестре по умолчанию обычному пользователю не дадут что либо редактировать, кроме HKCU.
5. Почему для запрета запуска некоторых приложений предлагается использовать отдельные политики и реестр, а не AppLocker/SRP, которые специально для этого созданы и в целом более гибкие (можно разрешать/запрещать по хэшу, цифровой подписи)? В AppLocker, например, по умолчанию действует «запрещено всё, что не разрешено» и запустить приложение из собственного профиля (с рабочего стола/temp и т.д.) пользователь не сможет.