DNSSEC (Domain Name System Security Extensions) добавляет к DNS-запросам цифровые подписи для проверки целостности и подлинности данных, но не шифрует сами поля DNS. Это означает, что содержимое запросов и ответов остаётся видимым, и модели, описанные в статье, будут работать с теми же данными, что и при обычном DNS.
Так как злоумышленники контролируют домен или поддомен, DNSSEC не сможет предотвратить туннелирование через этот домен, так как подписанные данные всё равно будут считаться подлинными. DNSSEC лишь подтверждает, что они не были изменены при передаче.
Идея, конечно, хорошая – одним действием решить все проблемы с DNS. Но тут есть два момента. Во-первых, не всегда есть возможность влиять на защищаемую инфраструктуру. И статья в целом про обнаружение DNS-туннелей средством, не влияющим на сеть. Во-вторых, не совсем понятно, как установка DNS-прокси позволит заблокировать канал утечки. DNS работает с поддоменами, используя иерархическую структуру доменных имен. Даже если DNS-сервер знает IP-адрес для одного поддомена (например, first-request.pirates.com), это не означает, что он автоматически знает IP-адрес для другого поддомена (например, second-request.pirates.com). Каждый поддомен может иметь свой собственный IP-адрес и соответствующие DNS-записи. Соответственно, если DNS-прокси не знает IP-адрес для нового домена (а он его не знает, потому что поддомен-то сгенерированный), то он сам пойдёт на внешний DNS за такой информацией – по сути, прокинет через себя туннель, доставив информацию получателю. Поэтому выглядит так, будто DNS-прокси не решит эту проблему. Может быть, идея была в чём-то другом?
Согласен с вами, однако, CRF все еще намного легче предложенных вами вариантов, к тому же CRF способен решать множество задач, среди которых есть и те, для которых не существует готовых баз знаний, способных решить задачу. Объяснимость предсказаний CRF, безусловно, не такая, как у систем логического вывода, опирающихся непосредственно на готовые базы знаний, но и объяснять предсказания модели требуется далеко не в каждой задаче. В данной статье был рассмотрен именно подход с использованием CRF, однако, в целом возможно применение комбинированных подходов, использующих знания из доступных баз и экспертных систем.
Естественные языки довольно флективны, новые слова появляются каждый день, из-за чего будет постоянно увеличиваться количество переборов, не говоря о случаях, когда новые слова могут иметь недостаточную базу для определения POS-тэга. К тому же, при увеличении длины предложения количество переборов так же будет заметно возрастать, без мощного железа за приемлемое время уже не обойтись. CRF имеет в среднем около 10-12 тысяч параметров и предсказывает в режиме реального времени на среднем процессоре. Если есть свободные ресурсы для перебора и вышеперечисленные недостатки не страшны вашей системе, то гарантированное предсказание тэга будет, конечно, лучше статистической модели. Однако, в задачах сложнее POS-тэггинга, например Named Entity Recognition, такие алгоритмы уже не покажут такого же качества работы.
Сеть разворачивалась для студентов с целью обучения. Из-за того, что занятия проходили на регулярной основе, отзывать сертификат не надо. Поэтому было значительно удобнее и быстрее создать один сертификат на всех и выдать его один раз. После этого все по нему работали. Система для раздачи данных, которая выдавала бы каждому пользователю индивидуальный логин и пароль для входа, в нашем случае была бы избыточной. В самом начале у нас была попытка раздать каждому участнику заранее сгенерированный конфиг. Но моментально возникли сложности с тем, что многие студенты подключались по одному конфигу. В итоге работа на занятии приостанавливалась. Что касается того, если участники положат сервис, то поднять его можно одной командой. Но обычно я создавал резервные копии сервисов на случай, если кому-то удастся положить сервис, что является обыденным событием для учебного процесса
Описанная в статье сеть разворачивалась для проведения занятий у студентов. В основном на эти встречи приходили пользователи, совершенно не знакомые с Linux. Наша задача была научить их решать CTF. Почему не Wireguard? Он по стандарту не предустановлен, например, в kali linux, а его нужно ставить дополнительно (в отличии от OpenVPN, который есть по стандарту). Да, Wireguard настроить несложно, но на это требуется время, которое было рассчитано не на настройку VPN, а на обучение. К тому же, участники, например, не знали или не могли найти место сохранения скачивания конфига в системе. Приходилось помогать каждому индивидуально, на что также затрачивалось время. Если бы Wireguard дал какие-то значительные плюсы по сравнению с OpenVPN, то был бы смысл его ставить, но по функционалу они схожи, а в настройке проще OpenVPN. Поэтому был использован именно он, чтобы сэкономить время на занятии.
LSTM работает не со строкой и ее элементами, она работает с последовательностью векторов признаков для каждого из кусочков изображения вдоль слова, полученных из сверточной части сети. Соответственно, одному символу в выходной последовательности может соответствовать один или несколько таких векторов. Каждый вектор классифицируется как символ (позже на этапе декодирования избавляемся от дублей), при классификации i-го вектора блок внутри LSTM получает информацию с предыдущих блоков, то, как эту информацию использовать, решает сама сеть с помощью т.н. "forget gate", соответственно, то насколько далеко LSTM "смотрит назад" определяет она сама, в том и прелесть нейронных сетей. Итого: сеть может думать, как буквами и их сочетаниями, так и словами. Возможно, получится залезть в веса, отвечающие за "степень забывания" предыдущих элементов последовательности и выяснить, насколько далеко "в прошлое" сеть учитывает предыдущие элементы входной последовательности. Вот хорошая статья, о том, как работает LSTM, механизм забывания там достойно описан: https://habr.com/ru/companies/wunderfund/articles/331310/
Добрый день, Дмитрий. Мы обновили блокнот и добавили два дополнительных теста. К сожалению, возникли трудности с бинаризацией текста с вашего примера. Возникли они по двум причинам:
Центр изображения в фокусе камеры, а края – нет.
Присутствует клетка. Мы подготовили схожий пример на листе белой бумаги и отсканировали его. Как мы видим, модель находит схожие паттерны у букв «Л» и «М» и из-за этого ошибается на них.
Добрый день! Вообще в разработке такой задачи не стояло, так как не очень ясна цель. Клиентское приложение, которое будет только лишь эмулировать браузер, отбрасываем, а задач оператора и администратора системы, которые можно было бы решить исключительно через API, в системе нет. Плюс браузеры это и независимость от OS на клиентском ПК, достаточно лишь более менее современного браузера (Google Chrome 95 и выше, Mozilla Firefox 95 и выше, да хоть бы и Microsoft Edge 93 и выше) и, для редких администраторских задач - SSH-клиента. Сегодня под это требование подходит подавляющее большинство тех ПК, которые используются сотрудниками отделов ИБ.
А какие недостатки управления через веб-интерфейс Вы видите?
Да, 6LoWPAN – не совсем протокол. Это стандарт, который лежит в основе других протоколов.
Для данных сетей понятие Gateway не применяется, в источниках указывают border router или edge router. Шлюз в данном случае - это устройство которое преобразует, но не передает данные дальше: чтобы их получить, нужно знать адрес шлюза и запросить их у него. Роутер знает обе сети и может сразу направить данные к получателю, за ними не надо обращаться.
Бельгийским исследовательским институтом CETIC был разработан проект 6LBR. Благодаря ему связь между сетями может быть настроена как в аппаратном (отдельным устройством), так и программном (на ОС Linux) виде без необходимости использования отдельного устройства, занимающегося только преобразованием и передачей. Условно, у нас может быть сервер, на котором установлен 6LBR, и к нему подключены 6LoWPAN и Ethernet сеть. ПО на сервере сможет обращаться к устройствам в обеих сетях, сами устройства из разных сетей будут обмениваться данными.
Некоторые из доступных видов передачи данных для 6LBR: умный мост, роутер и прозрачный мост. При работе в режиме прозрачного моста связь между сетями 6LoWPAN и Ethernet проходит на уровне пакетного фильтра. Про сам граничный роутер написано тут. Доступные режимы работы проекта 6LBR с описанием и схемами можно посмотреть тут.
К сожалению в статье ничего не увидел про реальную защиту IoT устройств на уровне железа. Утверждения что в устройствах не хватает ресурсов на шифрацию безосновательны. В недавно рассмотренном мной микроконтроллере для IoT скорость шифрования была около 50 Мегабайт в сек! Это превышает все мыслимые требования IoT. Даже если взять менее мощные микроконтроллеры от ST на 100..200 МГц, то там будет 10-20 Мегабайт в сек скорость шифрования AES-256 GCM.
В приложенной статье рассматривается настоящий монстр с огромным количеством ресурсов. Для оконечных IoT продуктов (не контроллеров) используются куда более простые чипы, у которых ресурсов меньше на порядки.
Это еще не начиная обсуждать такие технологии как TrustZone в совсем простых Cortex-M23..33 Все MQTT, AMQP, XMPP ... работают через TLS, поддерживают цепочки сертификатов, доверенные сервера и прочее.
В статье не написано, что протоколы IoT не умеют в шифрование. Про AMQP, MQTT в статье отмечено, что шифрование возможно. Другой вопрос – защищённость в этих протоколах является опцией, которую используют далеко не все.
Надеялся в статье будет от том как взламывают что-то вроде Mbed TLS
Статья – обзор IoT в целом, регулирования, стандартов, протоколов, решений по ИБ IoT. Тема поиска уязвимостей в Mbed TLS, если бы мне было, что про это сказать, уместнее была бы в рамках более специализированной статьи.
Если проверить слова автора о незащищенности протоколов, то они не подтверждаются сразу же первыми ссылками в поиске. Вот, например, как сделана защита в ZigBee.
Как и в вопросе про шифрование IoT, не нашёл в статье слов про то, что ZigBee не защищён. Да, в документе по ссылке есть описание каких-то механизмов создания защищённой сети на основе ключей, сертификатов, но их использование – опция, а не требование, и дополнительная проблема в том, что дыры в них находят с завидной регулярностью. Причем есть там не только уязвимости реализации (кода), но и архитектурные уязвимости, которые так просто не закрыть.
Соглашусь, тут Вы меня поймали. В своё оправдание скажу, что научно-методические материалы, предназначенные для внутриведомственного обращения по линии Министерства обороны, едва ли можно считать публично доступными.
Тем не менее, большое спасибо за архив, материалы безусловно будут изучены, и, возможно, сподвигнут меня написать третью часть этого цикла, посвященную профильным разработкам, которые существовали в СССР.
Спасибо! Добавление действительно важное. Конечно разработкой ОС с разделением времени занимались не только в MIT и Multics не была единственной такой ОС в 60-ые.
Как удалось найти в одной статье: ENIAC стал первым, потому что его первого презентовали широкой общественности, пока остальные играли в секретность. Вот такая несправедливость J
А слабости Willis Ware (который будет упомянут в следующей части) сформулировал очень просто:
Summary Comment. The detailed design of the Supervisor and the protective safeguards that it contains and that are afforded it are vital to adequate security control. Since commercially designed Supervisors and operating systems have not included security control, it is to be expected that the average commercial software will not provide the standards, conventions, and capabilities required.
Т.е. он в своем отчете попросту делает вывод, что в коммерческих программах-супервизорах никаких адекватных механизмов безопасности нет вообще. и это подтверждается тем, что все реализованные на тот момент механизмы безопасности изначально проектировались, чтобы защищать программы и данные пользователей от неумышленной порчи, а про ту же конфиденциальность никто особо и не задумывался – сам термин multilevel security пришел из среды военных и предприятий оборонного комплекса.
Любая политика ужесточающая сетевой обмен в домене AD должна применяться аккуратно: это относится и к отключению легаси механизмов аутентификации, и к требованию по использованию LDAPs и пр.
И тут есть два варианта:
Подождать, пока MS сделает соответствующую политику дефолтной – они это делают с учетом груза легаси, медленно и аккуратно. Например, сейчас те же соединения LDAP по умолчанию уже требуют безопасное соединение, а LM hash (наконец-то) больше не формируется вообще. Но надо понимать, что все время, пока MS не сделает эту опцию опцией по умолчанию – ваши системы будут уязвимы.
Можно внедрить эту настройку, но аккуратно, как это делается для любых других харденингов взаимодействия клиент-сервер. Для этого нужно:
Проверить, что домен удовлетворяет требованиям (все контроллеры домена с ОС не ниже Win server 2012, соответствующие функциональные уровни домена и леса).
Включаем на серверах опцию использования FAST в рекомендуемом режиме (“Always provide claims”) – естественно, с помощью GPO, а не вручную. Далее, ту же опцию развертываем на клиенты (и тоже с помощью GPO). А потом долго и нудно мониторим события на предмет наличия клиентов, которые не смогли сформировать запрос с поддержкой FAST. И для каждого вида ПО изучаем, что можно сделать – обновить, заменить, сменить настройки и пр.
Повторюсь, что это верно для любой другой опции, которая ужесточает взаимодействие клиента и сервера – будь то переход на SMB новой версии, отключение уязвимых протоколов аутентификации или требование обязательного шифрования канала.
Все что можно сделать без машинного обучения – надо делать без машинного обучения )
Описанный Вами подход понятен и наверняка эффективен. Было бы интересно узнать метрики качества за какой-то продолжительный период.
Но важно отметить, что сейчас методы атак становятся все более изощренными, поэтому арсенал для защиты тоже необходимо развивать и применять методы, которые самообучаются в окружающей среде.
Алгоритмы машинного обучения были использованы при обнаружении атаки. Атака при создании датасета была проведена без использования ML.
Добрый день!
DNSSEC (Domain Name System Security Extensions) добавляет к DNS-запросам цифровые подписи для проверки целостности и подлинности данных, но не шифрует сами поля DNS. Это означает, что содержимое запросов и ответов остаётся видимым, и модели, описанные в статье, будут работать с теми же данными, что и при обычном DNS.
Так как злоумышленники контролируют домен или поддомен, DNSSEC не сможет предотвратить туннелирование через этот домен, так как подписанные данные всё равно будут считаться подлинными. DNSSEC лишь подтверждает, что они не были изменены при передаче.
Идея, конечно, хорошая – одним действием решить все проблемы с DNS. Но тут есть два момента.
Во-первых, не всегда есть возможность влиять на защищаемую инфраструктуру. И статья в целом про обнаружение DNS-туннелей средством, не влияющим на сеть.
Во-вторых, не совсем понятно, как установка DNS-прокси позволит заблокировать канал утечки.
DNS работает с поддоменами, используя иерархическую структуру доменных имен. Даже если DNS-сервер знает IP-адрес для одного поддомена (например, first-request.pirates.com), это не означает, что он автоматически знает IP-адрес для другого поддомена (например, second-request.pirates.com). Каждый поддомен может иметь свой собственный IP-адрес и соответствующие DNS-записи.
Соответственно, если DNS-прокси не знает IP-адрес для нового домена (а он его не знает, потому что поддомен-то сгенерированный), то он сам пойдёт на внешний DNS за такой информацией – по сути, прокинет через себя туннель, доставив информацию получателю. Поэтому выглядит так, будто DNS-прокси не решит эту проблему.
Может быть, идея была в чём-то другом?
Согласен с вами, однако, CRF все еще намного легче предложенных вами вариантов, к тому же CRF способен решать множество задач, среди которых есть и те, для которых не существует готовых баз знаний, способных решить задачу. Объяснимость предсказаний CRF, безусловно, не такая, как у систем логического вывода, опирающихся непосредственно на готовые базы знаний, но и объяснять предсказания модели требуется далеко не в каждой задаче. В данной статье был рассмотрен именно подход с использованием CRF, однако, в целом возможно применение комбинированных подходов, использующих знания из доступных баз и экспертных систем.
Естественные языки довольно флективны, новые слова появляются каждый день, из-за чего будет постоянно увеличиваться количество переборов, не говоря о случаях, когда новые слова могут иметь недостаточную базу для определения POS-тэга. К тому же, при увеличении длины предложения количество переборов так же будет заметно возрастать, без мощного железа за приемлемое время уже не обойтись. CRF имеет в среднем около 10-12 тысяч параметров и предсказывает в режиме реального времени на среднем процессоре. Если есть свободные ресурсы для перебора и вышеперечисленные недостатки не страшны вашей системе, то гарантированное предсказание тэга будет, конечно, лучше статистической модели. Однако, в задачах сложнее POS-тэггинга, например Named Entity Recognition, такие алгоритмы уже не покажут такого же качества работы.
Сеть разворачивалась для студентов с целью обучения. Из-за того, что занятия проходили на регулярной основе, отзывать сертификат не надо. Поэтому было значительно удобнее и быстрее создать один сертификат на всех и выдать его один раз. После этого все по нему работали. Система для раздачи данных, которая выдавала бы каждому пользователю индивидуальный логин и пароль для входа, в нашем случае была бы избыточной.
В самом начале у нас была попытка раздать каждому участнику заранее сгенерированный конфиг. Но моментально возникли сложности с тем, что многие студенты подключались по одному конфигу. В итоге работа на занятии приостанавливалась.
Что касается того, если участники положат сервис, то поднять его можно одной командой. Но обычно я создавал резервные копии сервисов на случай, если кому-то удастся положить сервис, что является обыденным событием для учебного процесса
Описанная в статье сеть разворачивалась для проведения занятий у студентов. В основном на эти встречи приходили пользователи, совершенно не знакомые с Linux. Наша задача была научить их решать CTF.
Почему не Wireguard? Он по стандарту не предустановлен, например, в kali linux, а его нужно ставить дополнительно (в отличии от OpenVPN, который есть по стандарту). Да, Wireguard настроить несложно, но на это требуется время, которое было рассчитано не на настройку VPN, а на обучение. К тому же, участники, например, не знали или не могли найти место сохранения скачивания конфига в системе. Приходилось помогать каждому индивидуально, на что также затрачивалось время.
Если бы Wireguard дал какие-то значительные плюсы по сравнению с OpenVPN, то был бы смысл его ставить, но по функционалу они схожи, а в настройке проще OpenVPN. Поэтому был использован именно он, чтобы сэкономить время на занятии.
LSTM работает не со строкой и ее элементами, она работает с последовательностью векторов признаков для каждого из кусочков изображения вдоль слова, полученных из сверточной части сети. Соответственно, одному символу в выходной последовательности может соответствовать один или несколько таких векторов. Каждый вектор классифицируется как символ (позже на этапе декодирования избавляемся от дублей), при классификации i-го вектора блок внутри LSTM получает информацию с предыдущих блоков, то, как эту информацию использовать, решает сама сеть с помощью т.н. "forget gate", соответственно, то насколько далеко LSTM "смотрит назад" определяет она сама, в том и прелесть нейронных сетей.
Итого: сеть может думать, как буквами и их сочетаниями, так и словами. Возможно, получится залезть в веса, отвечающие за "степень забывания" предыдущих элементов последовательности и выяснить, насколько далеко "в прошлое" сеть учитывает предыдущие элементы входной последовательности.
Вот хорошая статья, о том, как работает LSTM, механизм забывания там достойно описан: https://habr.com/ru/companies/wunderfund/articles/331310/
Добрый день, Дмитрий.
Мы обновили блокнот и добавили два дополнительных теста. К сожалению, возникли трудности с бинаризацией текста с вашего примера. Возникли они по двум причинам:
Центр изображения в фокусе камеры, а края – нет.
Присутствует клетка. Мы подготовили схожий пример на листе белой бумаги и отсканировали его. Как мы видим, модель находит схожие паттерны у букв «Л» и «М» и из-за этого ошибается на них.
Добрый день! Вообще в разработке такой задачи не стояло, так как не очень ясна цель. Клиентское приложение, которое будет только лишь эмулировать браузер, отбрасываем, а задач оператора и администратора системы, которые можно было бы решить исключительно через API, в системе нет. Плюс браузеры это и независимость от OS на клиентском ПК, достаточно лишь более менее современного браузера (Google Chrome 95 и выше, Mozilla Firefox 95 и выше, да хоть бы и Microsoft Edge 93 и выше) и, для редких администраторских задач - SSH-клиента. Сегодня под это требование подходит подавляющее большинство тех ПК, которые используются сотрудниками отделов ИБ.
А какие недостатки управления через веб-интерфейс Вы видите?
Да, 6LoWPAN – не совсем протокол. Это стандарт, который лежит в основе других протоколов.
Для данных сетей понятие Gateway не применяется, в источниках указывают border router или edge router.
Шлюз в данном случае - это устройство которое преобразует, но не передает данные дальше: чтобы их получить, нужно знать адрес шлюза и запросить их у него. Роутер знает обе сети и может сразу направить данные к получателю, за ними не надо обращаться.
Бельгийским исследовательским институтом CETIC был разработан проект 6LBR. Благодаря ему связь между сетями может быть настроена как в аппаратном (отдельным устройством), так и программном (на ОС Linux) виде без необходимости использования отдельного устройства, занимающегося только преобразованием и передачей. Условно, у нас может быть сервер, на котором установлен 6LBR, и к нему подключены 6LoWPAN и Ethernet сеть. ПО на сервере сможет обращаться к устройствам в обеих сетях, сами устройства из разных сетей будут обмениваться данными.
Некоторые из доступных видов передачи данных для 6LBR: умный мост, роутер и прозрачный мост. При работе в режиме прозрачного моста связь между сетями 6LoWPAN и Ethernet проходит на уровне пакетного фильтра.
Про сам граничный роутер написано тут.
Доступные режимы работы проекта 6LBR с описанием и схемами можно посмотреть тут.
В приложенной статье рассматривается настоящий монстр с огромным количеством ресурсов. Для оконечных IoT продуктов (не контроллеров) используются куда более простые чипы, у которых ресурсов меньше на порядки.
В статье не написано, что протоколы IoT не умеют в шифрование. Про AMQP, MQTT в статье отмечено, что шифрование возможно. Другой вопрос – защищённость в этих протоколах является опцией, которую используют далеко не все.
Статья – обзор IoT в целом, регулирования, стандартов, протоколов, решений по ИБ IoT. Тема поиска уязвимостей в Mbed TLS, если бы мне было, что про это сказать, уместнее была бы в рамках более специализированной статьи.
Как и в вопросе про шифрование IoT, не нашёл в статье слов про то, что ZigBee не защищён. Да, в документе по ссылке есть описание каких-то механизмов создания защищённой сети на основе ключей, сертификатов, но их использование – опция, а не требование, и дополнительная проблема в том, что дыры в них находят с завидной регулярностью. Причем есть там не только уязвимости реализации (кода), но и архитектурные уязвимости, которые так просто не закрыть.
Соглашусь, тут Вы меня поймали. В своё оправдание скажу, что научно-методические материалы, предназначенные для внутриведомственного обращения по линии Министерства обороны, едва ли можно считать публично доступными.
Тем не менее, большое спасибо за архив, материалы безусловно будут изучены, и, возможно, сподвигнут меня написать третью часть этого цикла, посвященную профильным разработкам, которые существовали в СССР.
Спасибо! Добавление действительно важное. Конечно разработкой ОС с разделением времени занимались не только в MIT и Multics не была единственной такой ОС в 60-ые.
Да, действительно не все так просто оказывается…
Как удалось найти в одной статье: ENIAC стал первым, потому что его первого презентовали широкой общественности, пока остальные играли в секретность. Вот такая несправедливость J
Но замечание ценное – про ABC почитаю (не буду лукавить – до вашего комментария про нее не слышал), а вот про борьбу за первенство с Колоссом есть интересная статья: https://shura.shu.ac.uk/9501/3/Atkinson_-_Eniac_versus_Colossus_paper_%26_url.pdf
ОС на тот момент было уже много (см., например, https://en.wikipedia.org/wiki/Timeline_of_operating_systems)
А слабости Willis Ware (который будет упомянут в следующей части) сформулировал очень просто:
Summary Comment. The detailed design of the Supervisor and the protective safeguards that it contains and that are afforded it are vital to adequate security control. Since commercially designed Supervisors and operating systems have not included security control, it is to be expected that the average commercial software will not provide the standards, conventions, and capabilities required.
Т.е. он в своем отчете попросту делает вывод, что в коммерческих программах-супервизорах никаких адекватных механизмов безопасности нет вообще. и это подтверждается тем, что все реализованные на тот момент механизмы безопасности изначально проектировались, чтобы защищать программы и данные пользователей от неумышленной порчи, а про ту же конфиденциальность никто особо и не задумывался – сам термин multilevel security пришел из среды военных и предприятий оборонного комплекса.
Любая политика ужесточающая сетевой обмен в домене AD должна применяться аккуратно: это относится и к отключению легаси механизмов аутентификации, и к требованию по использованию LDAPs и пр.
И тут есть два варианта:
Подождать, пока MS сделает соответствующую политику дефолтной – они это делают с учетом груза легаси, медленно и аккуратно. Например, сейчас те же соединения LDAP по умолчанию уже требуют безопасное соединение, а LM hash (наконец-то) больше не формируется вообще. Но надо понимать, что все время, пока MS не сделает эту опцию опцией по умолчанию – ваши системы будут уязвимы.
Можно внедрить эту настройку, но аккуратно, как это делается для любых других харденингов взаимодействия клиент-сервер. Для этого нужно:
Проверить, что домен удовлетворяет требованиям (все контроллеры домена с ОС не ниже Win server 2012, соответствующие функциональные уровни домена и леса).
Включаем на серверах опцию использования FAST в рекомендуемом режиме (“Always provide claims”) – естественно, с помощью GPO, а не вручную. Далее, ту же опцию развертываем на клиенты (и тоже с помощью GPO). А потом долго и нудно мониторим события на предмет наличия клиентов, которые не смогли сформировать запрос с поддержкой FAST. И для каждого вида ПО изучаем, что можно сделать – обновить, заменить, сменить настройки и пр.
Повторюсь, что это верно для любой другой опции, которая ужесточает взаимодействие клиента и сервера – будь то переход на SMB новой версии, отключение уязвимых протоколов аутентификации или требование обязательного шифрования канала.
Большое спасибо, что заметили опечатку! Исправлено
теперь правильно)
Все что можно сделать без машинного обучения – надо делать без машинного обучения )
Описанный Вами подход понятен и наверняка эффективен. Было бы интересно узнать метрики качества за какой-то продолжительный период.
Но важно отметить, что сейчас методы атак становятся все более изощренными, поэтому арсенал для защиты тоже необходимо развивать и применять методы, которые самообучаются в окружающей среде.