Комментарии 54
В принципе, статья неплохая.
На практике — «и чего только люди не придумают дабы не ставить *nix»
На практике — «и чего только люди не придумают дабы не ставить *nix»
Если придумывают, значит это кому-то нжно. :)
Времена меняются… У Windows была инерция (в хорошем смысле), которую сейчас бездарно теряют ни на что.
Кстати, ваша статья в очередной раз показала что специалисты адекватнее фанатиков (К.О., да). Если бы подобная статья была про *nix, непременно нашёлся бы кто-нибудь, сказавший что в виндовс это всё полностью через гуй делается. :P
Кстати, ваша статья в очередной раз показала что специалисты адекватнее фанатиков (К.О., да). Если бы подобная статья была про *nix, непременно нашёлся бы кто-нибудь, сказавший что в виндовс это всё полностью через гуй делается. :P
Точно. Хороший пост, потому что демонстрирует, каких проблем у нас нет. Пока пользователи windows V/7 осваивают изоляцию служб и powershell, на десктопах с Linux эти функции давно есть и они просто месяцами работают прямо в инете.
Объявите конкурс на взлом… с вознаграждением. Иначе никто не поверит, и правильно сделает.
Думаете именно сейчас стОит?
Написать простую службу для Windows становится все сложнее :(
Хорошая статья, спасибо.
Проблема одна — эти возможности являются рекомендательными. Т.е. по сути разработчики не будут париться и будут по прежнему всегда указывать LocalSystem. Как, к своему стыду, делаю и я.
Я поначалу тоже так делал, но в связи с тем, что все работы на серверах выполняют коллеги из IT-отдела пришлось делать по-правильному, потому что они не разворачивали сервисы от LocalSystem.
Так что видимо нужен либо внешний фактор либо самостоятельно стремиться сделать как рекомендовано, чтобы избежать возможных проблем.
Так что видимо нужен либо внешний фактор либо самостоятельно стремиться сделать как рекомендовано, чтобы избежать возможных проблем.
Я про то и толкую. Нужен механизм, при котором разворачивание системы от LocalSystem было бы очень затруднено.
Зачем?
Если вы знаете, что это вредно и грозит последствиями вы всё равно будете так делать?
В нашем случае просто решили правильно организовать работу: разделили обязанности и в связи с этим в качестве мешающего фактора выступило IT.
А вообще можно было бы включить данное правило в стандарты кодирования на уровне конторы и за нарушение давать по рукам, не маленькие же.
Если вы знаете, что это вредно и грозит последствиями вы всё равно будете так делать?
В нашем случае просто решили правильно организовать работу: разделили обязанности и в связи с этим в качестве мешающего фактора выступило IT.
А вообще можно было бы включить данное правило в стандарты кодирования на уровне конторы и за нарушение давать по рукам, не маленькие же.
Я не о себе а о всех кодерах. Только добросовестных кодеров недостаточно ибо вирусня попадет через недобросовестных
С тем, что недобросовестных разработчиков масса, я безусловно согласен и тут, конечно, будет проблема.
Но средства изоляции нам как бы дали, так что мы можем это делать, ну хотя бы у себя.
Да, это будет сложно и муторно делать обычным пользователям, но тут такая вещь, что зачастую вирусы будут проникать и проникают к ним и так: по куче причин и заражаться компьютер будет далеко не через службы.
Насчёт мешающего механизма будем надеяться, что со временем по умолчания каждая новая устанавливаемая служба будет изолирована и не потребуется ручного вмешательства.
Но средства изоляции нам как бы дали, так что мы можем это делать, ну хотя бы у себя.
Да, это будет сложно и муторно делать обычным пользователям, но тут такая вещь, что зачастую вирусы будут проникать и проникают к ним и так: по куче причин и заражаться компьютер будет далеко не через службы.
Насчёт мешающего механизма будем надеяться, что со временем по умолчания каждая новая устанавливаемая служба будет изолирована и не потребуется ручного вмешательства.
Насколько я понял, microsoft перенимает обычную для unix практику заведения отдельных пользователей и групп для демонов. Это плюс. Смущает, что механизмов несколько и появляются они от версии к версии, т.е. некая монолитность модели безопасности теряется.
Проблема в том, что это должно было быть сделано фиг знает сколько времени тому назад.
То есть по вашему теперь и делать уже не нужно?
Нужно, конечно. Однако если сделать элементарные вещи по уму сразу, то можно бы было избежать многих проблем. А делать плохо, а потом исправлять, это самый ужасный путь, который можно только придумать.
Т.е. имея потенциально отличные средства обеспечения безопасности, делали откровенно плохо.
Т.е. имея потенциально отличные средства обеспечения безопасности, делали откровенно плохо.
Все продукты развиваются эволюционно и приоритеты зависят от того что хотят пользователи.
Или вы хотите сказать что у других производителей и сообществ все с первого раза совершенно выходит?
Или вы хотите сказать что у других производителей и сообществ все с первого раза совершенно выходит?
Вы чего на людей бросаетесь?
Нет, но это я так понимаю, был сознательный выбор. Снижение уровня безопасности. Запуск сервисов с минимальными правами, это не открытие Америки. Очень давно известная вещь. А запуск сервисов с максимальными правами, он часть концепции «по умолчанию разрешено все». В такой концепции проще делать, меньше вопросов от пользователей, но и дырок больше на порядок, а последствия их использования тоже на порядок разрушительней.
Это был сознательный выбор для обеспечения беспроблемной работы наибольшего количества унаследованного ПО.
Любое повышение безопасности ОС ломает стороннее ПО, потому что реальная система это всегда компромис между безопасностью и удобством. Кто в результате крайний? Конечно же MS.
Как вы убедились в комментариях коллеги paz к этой статье сторонние разработчики не хотят писать безопасный код. Они хотят писать код без труда. Это естественно для людей поэтому любые изменения в системе безопасности ОС Windows делаются постепенно.
Любое повышение безопасности ОС ломает стороннее ПО, потому что реальная система это всегда компромис между безопасностью и удобством. Кто в результате крайний? Конечно же MS.
Как вы убедились в комментариях коллеги paz к этой статье сторонние разработчики не хотят писать безопасный код. Они хотят писать код без труда. Это естественно для людей поэтому любые изменения в системе безопасности ОС Windows делаются постепенно.
Я именно про это и пишу, только другими словами.
А вывод должен быть следующим, для более.менее ответственных приложений, нужно выбирать системы, где по дефолту максимум запрещено/ограничено.
Иначе можно в результате удобства для лентяев и в результате дырок, по двое-трое суток стоять на ушах, как мне приходилось.
А вывод должен быть следующим, для более.менее ответственных приложений, нужно выбирать системы, где по дефолту максимум запрещено/ограничено.
Иначе можно в результате удобства для лентяев и в результате дырок, по двое-трое суток стоять на ушах, как мне приходилось.
Для создания безопасных систем есть групповые политики и настройки локальной системы позволяющие так закрутить гайки на Windows что даже Пентагон и множество других организаций обрабатывающих информацию деликатного характера использует Windows без каких либо проблем.
Все это я уже проходил. Не нужно мне это. Потом оказывается, что жизненно важный специализированный софт отказывается работать с закрученными гайками.
А если вы в другой ОС например закрутите гайки например такие как Selinux у вас проблем не будет?
Или вы все еще верите в ОС абсолютно безопасные по умолчанию? :)
Или вы все еще верите в ОС абсолютно безопасные по умолчанию? :)
Не нужно передергивать. Должны по умолчанию соблюдаться ЭЛЕМЕНТАРНЫЕ нормы безопасности.
Абсолютной безопасности никто не дает, но система может иметь приемлемый уровень безопасности и неприемлемый.
Абсолютной безопасности никто не дает, но система может иметь приемлемый уровень безопасности и неприемлемый.
>>А вывод должен быть следующим, для того чтобы воры не залезли в форточку, нужно копать бункер на глубине 80 метров.
Вот вы примерно это сказали.
Надо выбирать системы не где «по дефолту», а где можно настроить с теми настройками которые вам требуется.
Вот вы примерно это сказали.
Надо выбирать системы не где «по дефолту», а где можно настроить с теми настройками которые вам требуется.
«самый ужасный путь, который можно только придумать» — истеричное высказывание. Всегда есть путь хуже (/лучше).
«делали откровенно плохо» — конфликтоген. Вы бы сделали лучше? Wellcome!
Сорри за эмоции, просто задолбали оценки «умников». Заходишь на любой OpenSource проект и легко можешь отличить комменты некоторых наших соотечественников.
«делали откровенно плохо» — конфликтоген. Вы бы сделали лучше? Wellcome!
Сорри за эмоции, просто задолбали оценки «умников». Заходишь на любой OpenSource проект и легко можешь отличить комменты некоторых наших соотечественников.
Извините, но это был наполовину сознательный выбор.
Подход, чтобы по дефолту было бы все разрешено. Было нацелено на то, чтобы малоквалифицированные пользователи и разработчики встречали как можно меньше непонятного.
Плюсы подхода, это захват рынка, большое количество разработчиков и пользователей, которым нужно нажимать только кнопку «Next».
Минусы подхода, большое количество дырок и разрушительные последствия этих дырок. Разгул вирусов. Непонимание массой пользователей самой необходимости соблюдать элементарные правила.
При разработке NT были заложены все средства для создания очень хорошо защищенной ОС. А потом этими средствами воспользовались не очень хорошо.
Подход, чтобы по дефолту было бы все разрешено. Было нацелено на то, чтобы малоквалифицированные пользователи и разработчики встречали как можно меньше непонятного.
Плюсы подхода, это захват рынка, большое количество разработчиков и пользователей, которым нужно нажимать только кнопку «Next».
Минусы подхода, большое количество дырок и разрушительные последствия этих дырок. Разгул вирусов. Непонимание массой пользователей самой необходимости соблюдать элементарные правила.
При разработке NT были заложены все средства для создания очень хорошо защищенной ОС. А потом этими средствами воспользовались не очень хорошо.
Делать то может и нужно, но я сомневаюсь, что большинство пользователей, администраторов и программистов обрадуются и начнут делать «как нужно». Всех уже приучили к плохому. А к нему, как всем известно, легче привыкают.
Не совсем так. Запустить сервис от имени другого пользователя можно было и раньше. Другое дело, что пользователь этот становился локальным, со всеми вытекающими отсюда последствиями. И если в /etc/password проблема отключения консольного входа разруливается элементарно через задание пустого шелла, то в Windows всё чуть-чуть сложнее из-за множества способов этого самого входа. Навскидку — терминальный, локальный (консольный), RDP и их комбинации (Fast User Switching, например).
И всё это использует единую систему аутентификации. В отличии от Linux-овой Samba, например, которую можно прикрутить к pam, можно к ntlmauth, а можно и вообще ни к чему не прикручивать. Соответственно, аутентификационные службы должны четко знать, кого пускать, а кого — нет. Ведь в случае с Windows авторизация службы может проходить не только на локальном компьютере, но и на удаленном. Но при этом её нужно порезать в локальных правах как можно сильнее. И вот из-за этого весь этот сыр-бор, вкратце.
И всё это использует единую систему аутентификации. В отличии от Linux-овой Samba, например, которую можно прикрутить к pam, можно к ntlmauth, а можно и вообще ни к чему не прикручивать. Соответственно, аутентификационные службы должны четко знать, кого пускать, а кого — нет. Ведь в случае с Windows авторизация службы может проходить не только на локальном компьютере, но и на удаленном. Но при этом её нужно порезать в локальных правах как можно сильнее. И вот из-за этого весь этот сыр-бор, вкратце.
А можно такую же статью, только, что называется, under the hood?
Про виртуальные учётные записи не знал — спасибо статье. Но сам механизм как-то напоминает костыль.
Зачем вообще пароли для учётных записей, которыми не пользуются живые люди?
Зачем вообще пароли для учётных записей, которыми не пользуются живые люди?
Кэп: Чтобы удалённый злоумышленник не смог получить доступ к локальному компьютеру, зная только имя учётной записи.
Интересная статья, но увы — все способы обходятся. Хотя вынужден признать — эскалацию прав в W7 сделать стало несколько сложнее.
Но про LocalSystem — как сейчас помню :)
Но про LocalSystem — как сейчас помню :)
@echo off
sc create CmdAsSystem type= own type= interact binPath= "cmd /c start /low cmd /k (cd c:\ ^& color ec ^& title ***** SYSTEM *****)" > nul
net start CmdAsSystem
sc delete CmdAsSystem > nulИзготовление абсолютно защищенной системы экономически не окупится. Ей просто пользоваться будет невозможно. Поэтому делают системы которые способны обеспечить защищенность такого уровня чтобы взламывать их стало экономически не выгодно.
Экономическая выгода определяется не защищённостью системы, а тем, что она защищает.
А разве это не очевидно?
У любых данных обрабатываемых системой есть стоимость рисков разглашения и повреждения. Так же есть и срок жизни. Именно эти факторы определяют экономическую обоснованность использования той или иной системы для обработки и хранения данных.
Если стоимость взлома превышает стоимость данных то ломать врядли будут.
У любых данных обрабатываемых системой есть стоимость рисков разглашения и повреждения. Так же есть и срок жизни. Именно эти факторы определяют экономическую обоснованность использования той или иной системы для обработки и хранения данных.
Если стоимость взлома превышает стоимость данных то ломать врядли будут.
Это уже не работает. Интерактивные службы были запрещены. Но раньше действительно было возможно.
> Только бы пользовались
Ждем просвещающую статью про то, как пользоваться
Ждем просвещающую статью про то, как пользоваться
90% людей работает с правами администратора, можно примитивно дать им программку которая пропишется из под них под учетной записью System и творить с компом что угодно. Работает на любой ОС начиная с XP и заканчивая Windows Server 2008R2.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изоляция служб в Windows