Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Мне вот интересно, неужели есть в природе реальные структуры, в которых пользователям разрешено регистрировать устройства самостоятельно?
Уже не первый раз ссылаются на ms-DS-MachineAccountQuota = 10 , по-моему первое, что при поднятии нового домена в лесу делает вменяемый администратор, это меняет значение на 0.
Или все чисто по "дальше"-"дальше"-"дальше" теперь действуют?
И таких мест, где по умолчанию дырка в безопасности в сети винды 100500, и в какой одной статье того же микрософта, где это было бы собрано вместе - нету. Инфа размазана по статейкам, блогам, комментам в твиттере, а за этим всем уследить сложно. Не знаю причину, по которой микрософт не делает безопасно по-умолчанию.
В свое время винда и смогла потеснить тот же гораздо более развитый новелл именно по причине того, что оно просто все работало со старта без головняка и все было интегрировано в одном флаконе с рабочими станциями.
Мне кажется, что сейчас объем сложности в управлении виндовой сетью с учетом всех ее косяков переваливает через некий разумный порог сложности, и уже будет легче вручную настроить базовые сервисы на открытых решениях или решениях других вендоров.
Мне кажется, что сейчас объем сложности в управлении виндовой сетью с учетом всех ее косяков переваливает через некий разумный порог сложности, и уже будет легче вручную настроить базовые сервисы на открытых решениях или решениях других вендоров.
Нет, пока это не так. "Допиливания" после установки "с нуля" действительно нужны, про некоторые даже явно пишется, например, при установке роли контроллера домена. Но количество нужных кастомизаций вполне укладывается в опыт очень среднего админа. Большая часть "дыр" , по видимому, оставлена из соображений совместимости.
Не знаю причину, по которой микрософт не делает безопасно по-умолчанию.
Возможные причины;
Первая. "Конечному пользователю неудобно". Например, конечному пользователю неудобно переключаться на учетку администратора, чтобы что-то сделать в системе, а потом возвращаться обратно для работы. А потому никак усложнять обычную работу под администратором никто не будет, и пользователь будет сидеть в административной учетке (а то и вообще из учетки "Администратор", или как она сейчас в виндовс точно называется) постоянно.
Вторая. Так исторически сложилось с тех времен, когда 3-я виндовс еще не имела логина и разграничения прав как класса. И никто это дремучее легаси разгребать не собирается.
Вы, судя по вами написанному, несколько не в теме.
Пример из первой причины существовал долго, но, начиная с Win Vista (лет пятнадцать назад) был устранен: учетная запись из группы администраторов по умолчанию имеет права пользователя, а получение прав администратора надо либо явно подтвердить, либо (начиная с Win7) они могут быть даны молча, но только довереным программам, происхождение которых тщательно контролируется.
Что до второй, то это какая-то седая древность, не имеющая к нынешней Windows никакого отношения: нынешняя Windows — она ведет родословную не от Wndows 3.x, а от Windows NT, в которой дискреционный контроль доступа был изначально заложен в технические требования к системе перед ее разаработкой
.
А вероятная причина почему MS не делает работу с LDAP усиленно-безопасной по умолчанию — в совместимости: самописные/устарешие/пришедшие из мира *nix и кое-как переделанные под работу с Windows программы зачастую ничего не знают ни про LDAP Signing, ни про Channel Binding. А заменить их нередко нечем/дорого/требует квалификации, отсутсвующей у обслуживающего персонала. По крайней мере, в advisory вопросам проверки совместимости существующих программ с усиленными настройками уделено немало внимания.
Пример из первой причины существовал долго, но, начиная с Win Vista (лет пятнадцать назад) был устранен: учетная запись из группы администраторов по умолчанию имеет права пользователя, а получение прав администратора надо либо явно подтвердить, либо (начиная с Win7) они могут быть даны молча, но только довереным программам, происхождение которых тщательно контролируется.
Что до второй, то это какая-то седая древность, не имеющая к нынешней Windows никакого отношения: нынешняя Windows — она ведет родословную не от Wndows 3.x, а от Windows NT, в которой дискреционный контроль доступа был изначально заложен в технические требования к системе перед ее разаработкой
.
А вероятная причина почему MS не делает работу с LDAP усиленно-безопасной по умолчанию — в совместимости: самописные/устарешие/пришедшие из мира *nix и кое-как переделанные под работу с Windows программы зачастую ничего не знают ни про LDAP Signing, ни про Channel Binding. А заменить их нередко нечем/дорого/требует квалификации, отсутсвующей у обслуживающего персонала. По крайней мере, в advisory вопросам проверки совместимости существующих программ с усиленными настройками уделено немало внимания.
Пример из первой причины существовал долго, но, начиная с Win Vista (лет пятнадцать назад) был устранен: учетная запись из группы администраторов по умолчанию имеет права пользователя
Пес его знает, но в семерке пользователь Администратор вроде имеет чуть больше прав, чем просто пользователь из группы "Администраторы". По крайней мере сталкивался с тем, что некоторые вещи можно было сделать только из под этой учетки (уже не помню, что именно). И UAC под ней вроде реже вылазит с предупреждениями.
, а получение прав администратора надо либо явно подтвердить,
Просто тыкнув кнопку подтверждения? Так себе защита.
А вероятная причина почему MS не делает работу с LDAP усиленно-безопасной по умолчанию — в совместимости: самописные/устарешие/пришедшие из мира *nix и кое-как переделанные под работу с Windows программы зачастую ничего не знают ни про LDAP Signing
Вот примерно это я и имел ввиду, когда ссылался на 3.0. Только думал не только про LDAP, но и про другие моменты. Поддержка совместимости со всякой древностью (в 95 запускались программы из 3.0, в хр из 95, дедка за репку, мышка за кошку) требует жертв в плане безопасности.
Пес его знает, но в семерке пользователь Администратор вроде имеет чуть больше прав, чем просто пользователь из группы «Администраторы». По крайней мере сталкивался с тем, что некоторые вещи можно было сделать только из под этой учетки (уже не помню, что именно).
ЕМНИП для него по умолчанию отключен UAC — тот самый механизм, который дает администраторам при входе в систему только права пользователя, но позволяет их повысить. По крайней мере, на Win2K8 R2 Server это так, про Win7 точно не помню, потому как очень давно не сталкивался: Administrator там обычно отключен. Ну, и в режиме восстановления шатными средствами требуется пароль именно Administartor.
Просто тыкнув кнопку подтверждения? Так себе защита.От автоматического получения прав администратора недоверенным кодом защищает. Так что какая-никакая, а защита. А от дурака-пользователя никакая защита не поможет.
Вот примерно это я и имел ввиду, когда ссылался на 3.0. Только думал не только про LDAP, но и про другие моменты. Поддержка совместимости со всякой древностью (в 95 запускались программы из 3.0, в хр из 95, дедка за репку, мышка за кошку) требует жертв в плане безопасности.
В Win95 все было совсем по-другому: там вообще не было разграничения доступа локально на компьютере — только по сети. И графическая подсистема с оконной реально работали, в основном, в 16-битном режиме, как в 3.x. Но программы из Win3.x можно было запускать и на NT/2K/XP это да.
В свое время винда и смогла потеснить тот же гораздо более развитый новелл именно по причине того, что оно просто все работало со старта без головняка и все было интегрировано в одном флаконе с рабочими станциями.
Ну да, все со старта было просто включено и работало. И не было никакого головняка — до тех пор, пока Code Red по сетям не прошелся: это был такой червь — чисто сетевой, он вообще на диск ничего не писал и перезапуск IIS не переживал, — который использовал уязвимость в одном весьма редко используемом компоненте IIS — но IIS со всеми компонентами был на Win2K включен из коробки. ВОт тогда MS получили головняк и головомойку, и в Win2K3 все компоненты надо было уже ставить отдельно.
Мне кажется, что сейчас объем сложности в управлении виндовой сетью с учетом всех ее косяков переваливает через некий разумный порог сложности, и уже будет легче вручную настроить базовые сервисы на открытых решениях или решениях других вендоров.
Ну, если не следовать рекомендациям изготовителя — таки да, переваливает. Впрочем, он лет двадцать назад переваливал, у типичных «win-админов» (шутка тех времен, сейчас, наверное, малопонятная: «win-админ подобен win-модему и win-принтеру — своих мозгов у него нет, за него думает Windows»): не просто так же MS создала свою программу сертификации специалистов о нескольких уровнях, чтобы готовить людей для обслуживания своих сетей.
А в данном случае, вообще-то, еще с 2020 все нужные настройки можно сделать через групповую политику, то есть делаются они один раз. А если через реестр — то и с 2017, но там надо было не забывать их для новых серверов и ПК (на практике — образов, т.к. с нуля Windows профессионалы давно уже не ставят). И advisory про это еще тогда была написана (и ЕМНИП MS вообще хотела тогда сделать это повышение уровня безопасности с какого-то обновления принудительным, но не рискнула, потому что совместимость).
А " базовые сервисы на открытых решениях или решениях других вендоров" в плане безопасности хороши, в основном, тем, что они отсекают неквалифицированных построителей систем: для их построения уже нужна определенная квалификация.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Microsoft объяснила, как защитить корпоративные среды Windows от атак KrbRelayUp