none
Ограничение пользователей в запуске программ RRS feed

  • Общие обсуждения

  • Возникла и созрела проблема.
    Пользователи запускают программы, запуск которых нежелателен.
    Классический пример - игрушки.
    На клиентских машинах Vista Business SP1.
    Как запретить пользователям запуск нежелательных программ?
    9 февраля 2009 г. 16:40

Все ответы

  • Данная задача решается только одним методом, который требует некоторых подготовительных работ.
    Итак, самое главное, чего вам нужно добиться - запретить пользователям пользоваться административной учётной записью. Вы должны пользователям выделить ограниченную учётную запись. Её вполне хватает для комфортной работы с приложениями. Но главная задача, которая решается на данном этапе - непозволение пользователям изменять параметры и настройки системы. До тех пор, пока это не будет выполнено ваша задача не будет иметь решения.

    Если с первым шагом справились, то дальше необходимо приступать к настройке Software Restriction Policies. Что это такое и с чем это едят:
    http://www.samag.ru/cgi-bin/go.pl?q=articles;n=09.2008;a=02 (на русском)
    Секреты Software Restriction Policies (на русском)

    по первой ссылке не поленитесь внизу страницы просмотреть ссылки на более подробный материал на TechNet'e

    В принципе, ничего космически сложного нету там, но дам несколько рекомендаций:
    1) к правилам по умолчанию добавьте необходимые исключения, чтобы пользователи могли запускать ярлыки из меню Start и quicklaunch.
    2) добавьте исключения для рабочих программ, которые проинсталлированы в отличные от C:\Windows и C:\Progrm Files папки.

    При действии по умолчанию disallowed пользователи не смогут запустить ничего, кроме того, что вы явно разрешили, это т.н. "белый список".
    [тут могла быть ваша реклама] http://www.sysadmins.lv
    9 февраля 2009 г. 20:44
  • Vadims Podans написал:

    Данная задача решается только одним методом, который требует некоторых подготовительных работ.
    Итак, самое главное, чего вам нужно добиться - запретить пользователям пользоваться административной учётной записью. Вы должны пользователям выделить ограниченную учётную запись. Её вполне хватает для комфортной работы с приложениями. Но главная задача, которая решается на данном этапе - непозволение пользователям изменять параметры и настройки системы. До тех пор, пока это не будет выполнено ваша задача не будет иметь решения.

    Если с первым шагом справились, то дальше необходимо приступать к настройке Software Restriction Policies. Что это такое и с чем это едят:
    http://www.samag.ru/cgi-bin/go.pl?q=articles;n=09.2008;a=02 (на русском)
    Секреты Software Restriction Policies (на русском)

    по первой ссылке не поленитесь внизу страницы просмотреть ссылки на более подробный материал на TechNet'e

    В принципе, ничего космически сложного нету там, но дам несколько рекомендаций:
    1) к правилам по умолчанию добавьте необходимые исключения, чтобы пользователи могли запускать ярлыки из меню Start и quicklaunch.
    2) добавьте исключения для рабочих программ, которые проинсталлированы в отличные от C:\Windows и C:\Progrm Files папки.

    При действии по умолчанию disallowed пользователи не смогут запустить ничего, кроме того, что вы явно разрешили, это т.н. "белый список".


    [тут могла быть ваша реклама] http://www.sysadmins.lv



    Всё это уже давно пройденный этап. Эти рекомендации могут остановить только начинающих пользователей. Любая программа во время работы или между сеансами работы что-то пишет на диск. В моём случае только одна программа из полутора десятков установленных, писала свои временные файлы в папку где сама и находится. Соответственно был разрешен запуск программы из этой папки и была разрешена запись файлов в неё.
    Куда писать пользователи нашли меньше чем за час. Игрушки победили.
    Но если игрушку записанную на диск можно найти и пользователя "пожурить", то как быть со следующей ситуацией. Пользователь запускает браузер, такое действие ему разрешено. Заходит на сайт и играет. Есть и другие варианты этой "технологии".

    Наивно верить в могущество Software Restriction Policies.
    Также наивно верить в силу администраторского пароля.

    Можете ли предложить что-либо ещё?
    10 февраля 2009 г. 9:26
  • > Соответственно был разрешен запуск программы из этой папки и была разрешена запись файлов в неё

    пользователи всё равно не могут запускать свои .exe файлы даже при возможности записи в папку.

    > Пользователь запускает браузер, такое действие ему разрешено. Заходит на сайт и играет.

    это уже взаимодействие с сетью. На локальной станции максимум что можно сделать - отключить Java и флеш. Но проксирование в данном случае более выгодно.

    > Наивно верить в могущество Software Restriction Policies.

    я несколько иного мнения. Пока что обойти данный запрет не так и просто даже профессионалам.

    > Также наивно верить в силу администраторского пароля.

    а что он? Безусловно, есть  только одна лазейка, как обойти его - в оффлайне использовать ERD. Тут поможет разве что пломбирование кейса, запароливание BIOS'а ну и административные меры. В онлайн взломать пароль администратора ну неполучится, извините.

    > Можете ли предложить что-либо ещё?

    нет. Я остаюсь на своих же рекомендациях, которые действительно работают. Почему они не работают у вас - это вопрос. Я готов обсудить эти вопросы.

    [тут могла быть ваша реклама] http://www.sysadmins.lv
    10 февраля 2009 г. 11:00
  • Судя по всему вариант, когда пользователи - это очень грамотные, высококвалифицированные и бессовестные профессионалы даже не рассматривается.

     

    Речь идёт о студентах старших курсов специальности "Программное обеспечение вычислительных систем".

    На 3 курсе они изучают клиентские ОС. В том числе изучается парольная защита ОС. А после лабораторной работы "Получение доступа к ОС с неизвестным паролем", получить администраторский пароль может любой. Там же на 3 курсе они начинают знакомиться с политиками безопасности. На 4 курсе изучаются серверные ОС. И студенты учатся управлять доменами и применять эти самые политики.
    В начале этого семестра, преподаватель предложил студентам запустить "игрушку" на машинах с включённой политикой ограниченного использования программ. Студентам был обещан лишний балл к зачёту, если смогут это сделать. Через полчаса в папке Program files нашли папку с программой тестирования знаний студентов, а ней папку с разрешением на запись и запустили игру. Ещё через полчаса запустили игрушки в браузере. А через неделю нашли первую настоящую "дыру". Файлы с расширением "chm" запрещены для прямого запуска. Но если его запустить из rar-архива, то файл запускается. Под XP это работает без ограничений, запущенный файл не искажается. Под Вистой файл из архива запускается, но открывается в "Блокноте", в искажённом виде. До конца семестра 3 месяца, что ещё найдут и придумают???

    Вот так. Пароли снимаются, политики обходятся. Специфика работы такая.
    Призывы к совести не действуют. Штатные средства в описанной ситуации не помогают или помогают временно, дополнительные программы контроля за доступом так же.

    Не пробовали только наказывать, пойманных на несанкционированном доступе. Но их пока ещё и не поймали ни одного.

    Может быть ещё кто-нибудь что-нибудь предложит?

    13 февраля 2009 г. 14:54
  • > получить администраторский пароль может любой.

    получить сам пароль - это очень вряд ли, если машина в онлайне. Если в оффлайне, то можно поставить свой пароль. ERD и вперёд. Если у пользователей действительно ограниченные права (только Users и никаких Power Users и прочих), то просьба продемонстрировать. Без выключения компьютера или без повышения их прав свыше Users это будет невозможно. Разве что подбирать пароль. Но это слишком долго и неинтересно. В конце концов passprop решит вопрос с подбором.

    > Через полчаса в папке Program files нашли папку с программой тестирования знаний студентов, а ней папку с разрешением на запись и запустили игру.

    это не проблема SRP, а проблема неверного конфигурирования политики. Ведь недостаточно только включить политику и всё. Её же ещё и настроить надо. По таким случаям есть чёткие рекомендации:
    в случае если программа требует разрешение записи пользователем в каталог с исполняемым файлом, то в политике SRP следует явно запретить правилом эту папку, а исполняемый файл разрешать только по хешу. В таком случае пользователи могут копировать свои .exe файлы, но запустить их не смогут, даже подменив исполняемый файл программы.  Хеш не совпадёт.

    Опять же, ничто не мешает установить приложение на другой том и там разрешить исполняемый модуль по хешу. Тем самым вы избавляетесь в необходимости перекрёстного правила (когда запрещается вся папка одним правилом и что-то разрешается в ней другим правилом).

    об этом говорится в первой ссылке:
    Hash Rule – правило хэша. Для каждого приложения требуется создание отдельного правила. Данный тип правил очень полезен для приложений и файлов, которые находятся в открытых для записи пользователями папках. Например, можно разрешить запуск приложения из папки My Documents (куда пользователь имеет права записи) по хэшу. В таком случае гарантируется защита от подмены файла (с таким же именем) или при инфицировании файла вирусом, так как в обоих случаях хэш самого файла изменится и не подпадёт под правило хэша политики SRP и запуск его будет невозможен.

    но даже, если бы и не было такой программы, то я знаю минимум 2 лазейки в самой системе. Но об этом чуть позже. Что касается CHM, то там всё проще. В меню Start -> Run... наберите:

    hh path\filename.chm

    и он откроется. Именно такой метод использует WinRAR для открытия CHM. Но с исполняемыми (а так же пакетными) файлами это не пройдёт. В принципе из CHM можно запустить исполняемый файл, но этот исполняемый файл должен будет пройти отдельную проверку политикой на легитимность запуска.

    Что касается браузера - готовы ли вы продемонстрировать процесс?

    Вам достаточно было открыть вторую ссылку в моём посте, чтобы узнать альтернативные методы обхода политики. Но это же нужно делать.

    Я попрежнему настаиваю на своей позиции. Вопрос только в том, на сколько у вас есть желание изучить материал и применить его на практике.

    кстати говоря, тут немаловажную роль играет обновление. Если у вас на сервере не установлены последние заплатки, а у студентов есть на руках эксплоит, который использует уязвимости MS08-067 или MS09-001 (достать его не проблема), то при помощи него можно исполнить свой код от имени системы.
    [тут могла быть ваша реклама] http://www.sysadmins.lv
    13 февраля 2009 г. 21:54
  • Согласен, что политику нужно не только применить, но и настроить.
    Но как я уже писал специфика не даёт. Пример с программой-тестером просто для начала.
    3 и 4 курс работают с Делфи и Visual Studio. Соответственно студенты сохраняют свои проекты, компилируют их, запускают созданные приложения. Набор программ на компьютере может поменяться несколько раз за час. И запуск их нужно разрешать. Политика запрета программ работает для статичного набора программ на компьютере. Но способа контроля за постоянно меняющимся набором программ, я не нашел.
    По этой же причине я не могу ограничить функциональность браузеров. На занятиях по WEB-программированию студенты учатся работать с флэш, Java и много ещё чем.

    Теперь положение с применением Software Restriction Policies описано почти полностью. Может быть что-то и забыл, но на фоне положения с компиляторами, это что-то пока не важно.

    О паролях. Всё та же специфика.

    Как работать с парольной дискеткой и программами сброса и замены пароля (в том числе и Майкрософтовской) студенты знают, но не меняют администраторский пароль. Изменённый пароль обнаруживается очень быстро. Куда выгоднее узнать действующий пароль администратора.
    На занятиях по парольной защите студенты работают с программой SAMinside. Она позволяет получать парольные хэши в том числе и on-line (может быть у нас разное понимание термина on-line). После этого LM-пароли подбираются от 20 минут до нескольких часов. Так же у студентов есть возможность снять с компьютеров файлы реестра, содержащие пароли и работать с ними дома. Пробовал ставить NT-пароли. Месяца не прошло, как пароль вскрыли. Как сделали не знаю. Скорее всего вынудили кого-то из преподавателей набрать пароль с администраторскими правами и засняли на камеру мобильника.
    Собственно и причина нестойкости паролей известна. Студенты имеют физический доступ к учебным компьютерам. И ограничить их в этом доступе нет возможности. А вот к серверам физического доступа они не имеют. И хотя знают чем и как атаковать компьтер через сеть, до серверов ещё ни разу не добрались.

    Общее положение описано уже почти полностью.
    И снова самый первый вопрос, а можно ли вообще в описанной ситуации ограничить доступ к играм.

    14 февраля 2009 г. 21:36