none
Как через GPO назначить права на ветку реестра HKCU\software\microsoft\windows\currentversion\run? RRS feed

  • Вопрос

  • Доброго времени суток всем гуру!

    В компании последнее время наблюдается такая проблема: юзеры хватают злополучный банер "Trololo" :) (блочит рабочий стол картинками непристойного содержания).

    Собственно бороться с ним достаточно просто, если это разовая акция (убить процесс самой программы, рестарнуть процесс explorer-а, удалить ключ автозапуска из указанной в теме поста ветки и почистить темпы).

    Проблема в том, что в компании используется антивирус зарубежного производства, в связи с чем сигнатуры этой "отечественной разработки" попадают с опозданием - троян постоянно модифицируется, но у него всегда единая точка входа - он прописывает ссылку на исполняемый файл в ветку HKCU\software\microsoft\windows\currentversion\run для автозапуска.

    Собственно проанализоровав, пришёл к выводу, что пользователю незачем иметь права на запись в оноую. В связи с чем столкнулся со следующей проблеммой: как на этой ветке отобрать права на запись у пользователей? В gpmc назначение какой-либо политики на ветку HKCU невозможно, т.к. эта ветка создается для каждого пользователя при первом логине живет она на самом деле в HKU\{SID_пользователя} 

    Насколько я понял, шаблон для этой ветки со всем разрешениями берётся из локального Default User's Profile (по умолчанию C:\Documents and Settings\Default User\NTUSER.DAT) Так ли это? (сначала думал, что HKU\.default и есть дефолотовые настройки для профиля пользователей).

    Если так, то вопрос следующий: как сделать так, чтобы пользователю данная ветка создавалась с заранее установленными разрешениями и где их нужно устанавливать: в политике реестра или же в политике профилей пользователей?

    P.S. хочу отметить, что Групповая политика User Configuration\Administrative Templates\System\Logon\"Не обрабатывать список автозапуска для старых версий" в данном случае не подойдёт, т.к. она исключит возможность автозагрузки из данной ветки в принципе. Целью же является ограничить права на запись.

    Заранее спасибо!

     

    8 июля 2010 г. 19:38

Ответы

  • Идея неправильная и работать не будет. То, что вы должны (обязаны) сделать на всех машинах без исключения - реализовать политику Software Restriction Policies.

    Смотрите соответствующую главу в Руководстве по безопасной работе с Windows - http://forum.sysadmins.su/index.php?showtopic=16346


    MCPIT: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor
    8 июля 2010 г. 20:02
    Отвечающий
  • Несколько соображений сразу.

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

    2. Точек автозапуска гораздо больше, чем один ключ Run. Воевать со всеми сразу не получится.

    3. В любом случае, это была бы реактивная защита (сломалось? чиним. пожар? тушим.), которая сначала допускает прорыв безопасности, затем как-то его маскирует. Верный метод - проактивная защита, недопущение запуска зловредных исполняемых модулей. Не с последствиями бороться нужно, а с первопричиной .)


    MCPIT: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor
    Отвечающий

Все ответы

  • Идея неправильная и работать не будет. То, что вы должны (обязаны) сделать на всех машинах без исключения - реализовать политику Software Restriction Policies.

    Смотрите соответствующую главу в Руководстве по безопасной работе с Windows - http://forum.sysadmins.su/index.php?showtopic=16346


    MCPIT: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor
    8 июля 2010 г. 20:02
    Отвечающий
  • Чтож, спасибо за совет, не так давно поднимал тему по-поводу SRP. Видимо это решение будет проще и разумнее...

    Позволю себе два встречный вопрос: в чем именно неправильность идеи? Права на ветки реестра невозможно разграничить? 

    8 июля 2010 г. 20:24
  • Несколько соображений сразу.

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

    2. Точек автозапуска гораздо больше, чем один ключ Run. Воевать со всеми сразу не получится.

    3. В любом случае, это была бы реактивная защита (сломалось? чиним. пожар? тушим.), которая сначала допускает прорыв безопасности, затем как-то его маскирует. Верный метод - проактивная защита, недопущение запуска зловредных исполняемых модулей. Не с последствиями бороться нужно, а с первопричиной .)


    MCPIT: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor
    Отвечающий
  • 1. Ну в данном случае речь идет об ограничении одной единственной возможности пользователя: запись программы в автозапуск через линк в ветке реестра. Объективно, обращается туда пользователь только при установке легитимного ПО, а т.к. прав на установку у него все равно нет и задача установки ПО лежит на администраторах - то почему бы и нет?

    2. На остальные ветки и директории, отвечающие за автозагрузку прав у пользователей нет.

    3. Вот тут позволю себе согласиться не со всем  - не имея возможности попасть в автозагрузку, вирус не сможет отрабатывать свой сценарий. Проактивная защита с помощью SRP получится только в том случае, если будет реализован белый список ПО. Задача с его составлением в крупной инфраструктуре (около 7000 ПК) требует значительных временных затрат. Я совершенно согласен, что White List - самое правильное решение. Но в данном случае получается именно пожар, который нужно устранить максимально быстро. Реализовать это с помощью SRP Black List - временное решение...

     

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
    HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\load
    HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices
    Папка Startup в профиле

    .

    Это только то, что навскидку.  Хуже того - думается, если провести аудит, обнаружится МАССА учётных записей с повышенными привилегиями. То есть, тех, что имеют доступ и к HKEY_LOCAL_MACHINE.

    .

    .

    Далее - вирус сможет отрабатывать сценарий, не попадая в автозагрузку. Автозагрузка нужна будет ему для повторного неоднократного исполнения, но один раз он отработает как минимум. На самом деле, больше одного - об этом свидетельствуют ваши же слова о разовой акции. Поэтому я сразу обозначаю своё несогласие с точкой возникновения проблемы - "Проблема в том, что в компании используется антивирус зарубежного производства..."

    .

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

    .

    .

    Делайте белый список, другого пути не будет. На всех машинах.

     


    MCPIT: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor
    Отвечающий
  • И в догонку: для ознакомления с тем, что есть такое SRP и, как с ним жить и работать, обратитесь к замечательной серии статей от Вадима


    blog: http://shss.wordpress.com/
    9 июля 2010 г. 17:40