Забыли пароль от “родительского контроля”. Как его обнулить?!
Всё спасибо. Разобрался сам.
В реестре хэш пароли снёс и перезапустил 
Пароль обнулился.
Я шокирован. Проверил. Залез в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\cmdGuard и выставил параметр Start в 4 (выключил) - Comodo разрешил и ни пискнул. А как же защита Comodo своих ключей реестра? В подобной ситуации с забытым паролем еще в третьей версии мне не удалось ничего сделать с реестром - отказ в доступе. И деинсталировать он себя не давал - требовал пароль. И в режиме защиты от сбоев, кажется, не сдался. А я то думал все по прежнему, а оно оказывается вот как. Мда…
Угу, есть такое дело 
Недоработка 5-ки налицо, притом серьезная. Нужно писать разрабам. Еще не обращались в англицкую ветку? Если нет, - я напишу или попробую через модераторов сообщить
Это не проблема тройки, четверки или пятерки, это проблема safe-режима. regedit - безопасное приложение, а им разрешается править защищаемые ветки (и файлы, кстати) без дополнительных вопросов. В принципе, это можно настроить, если как следует посидеть над “заводскими” пресетами, но направление в целом несколько удручает… Типичная проблема вывода продукта на больший круг пользователей. Например, контроль за динамическим линкованием в пятерке уже исчез как класс
regedit - безопасное приложение, а им разрешается править защищаемые ветки (и файлы, кстати) без дополнительных вопросов.Согласен, но вышеуказанный ключ реестра находится в списке [b]Защищенные ключи реестра[/b] CIS и поэтому HIPS фаервола [u]не должен молча пропускать изменения значений в защищенных ключах[/u], обозначить эти изменения ну хотя бы алертом. А если [b]доверенным приложениям[/b] разрешены такие манипуляции с [b]защищенными файлами\папками\реестром[/b], так это априори неправильно. Это что же получается, любой файл с правами доверенного, может вмиг вывести из строя HIPS фаера?! Можно было бы например прописать(по умолчанию при установке CIS) в предопределенную политику доверенных приложений запрет на изменение критично важных зон HIPSа или алерт на красном фоне типа: "Изменение данного файла может привести к нарушению работы Проактивной защиты!!!" Вы же если пытаетесь открыть любой файл для просмотра, который занесён в [b]Заблокированные файлы[/b], при помощи explorer.exe(даже если к нему применить предопределенную политику - Доверенное приложение), ничего не получится, верно? Так почему получается "крамсать" доверенными приложениями жизненно важные [b]защищённые[/b] файлы [b]Защиты[/b] фаервола. Ни это ли называется - уязвимость HIPS?
Нет. Посмотрите сами заводские политики для “Системных” и “Доверенных”, Там стоит “разрешить” для защищенных файлов, веток и ещё для много чего. Если хотим получить вопрос, значит приходится ставить “Спрашивать”.
Совершенно верно. Заводские настройки CIS вообще очень трудно назвать оптимальными. И лично я ожидаю, что по мере того, как CIS будет становиться всё более user-friendly (Ну, по заявкам трудящихся, сами понимаете, типа много алертов и всё такое), эти настройки будут всё менее оптимальными. К счастью (пока) всё это можно настроить вручную, хотя, как я писал выше, некоторые функции начали пропадать. Правда, можно порадоваться за то, что вырубить CIS мало, он ведь тогда начинает запрещать всё, что не разрешено без всяких вопросов.
Если прописать по умолчанию, то сами знаете, что выйдет. Все форумы, включая этот, будут переполнены “отзывами”, мол, Аааа-ааа, CIS плохой, сплошные алерты…
Отписал Модераторам, ждём ответа…
Скажут что это нормально, и они, наверное, правы. Я был шокирован, потому что я переписывал все политики по умолчанию, у меня выключена галка “Создавать правила для доверенных”, я даже удалил все (почти) из списка “Доверенные поставщики”. В частности одна из задач была - сделать CIS НЕ убиваемым. Я видел что HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services* в защищенных ключах и отдельно ни каких действий не предпринимал. Увидев стартовое сообщение userovich, я только посочувствовал мысленно человеку, так как я уже имел подобный печальный опыт, и тогда мне ничего с CIS 3 сделать не удалось - он стойко отбивал все попытки посягнуть на его благополучие (обожаю CIS 3, на работе до сих пор пользуюсь CIS 3, причем вообще без какого либо антивируса). Я после этого всем где пришлось устанавливать CIS говорил что “забытый пароль - ключ к скорейшей перестановке системы”. Очевидно поэтому, я считал, что и у CIS 5 такие вещи “по умолчанию” - и вот на тебе.
Сейчас повторно прошерстил все связанное с безопасностью CIS 5. В частности, среди всего прочего, кажется, после того как:
- Удалил все в группе “Ключи реестра CIS”
- Добавил туда
HKEY_LOCAL_MACHINE\SYSTEM*ControlSet*\services\cmdAgent*
HKEY_LOCAL_MACHINE\SYSTEM*ControlSet*\services\cmdGuard*
HKEY_LOCAL_MACHINE\SYSTEM*ControlSet*\services\cmdHlp*
HKEY_LOCAL_MACHINE\SYSTEM*ControlSet*\services\cmderd*
HKEY_LOCAL_MACHINE\SYSTEM\software\Comodo\Firewall Pro*
HKEY_LOCAL_MACHINE\SYSTEM\software\Comodo\Cam\CIS*
\Software\ComodoGroup\CFP
\Software\ComodoGroup\CIS - В правилах проактивной защиты для “Все приложения”-“Применять пользовательскую политику”-“Настроить”-“Права доступа” - “Защищенные ключи реестра”-“Исключения”-“Изменить”-“Заблокированные ключи реестра” добавил созданную в п 2. группу “Ключи реестра CIS”
regedit отказался править реестр в HKEY_LOCAL_MACHINE\SYSTEM*ControlSet*\services\cmdAgent* и честно признался, что нет доступа. Я успокоился, но буду ковырять еще.
regedit отказался править реестр в HKEY_LOCAL_MACHINE\SYSTEM\*ControlSet*\services\cmdAgent* и честно признался, что нет доступа. Я успокоился, но буду ковырять еще.Правит, да еще как :o Даже алерт не выскакивает, если Безопасный режим проактивки. А после перезагрузки компа CIS думает минут 7-10, блокируя службы и выдает затем: "COMODO Application Agent не работает". Собственной утилитой диагностики проблему исправить не может(см.скрин). Страшно подумать, что может быть, если regedit.exe "подхватит" какую то инъекцию >:(
Windows 7 x86,
CIS Premium *.1142
[attachment deleted by admin]
Вообще говоря, перед тем, как написать пост№4 я перепроверил этот вопрос на 3.10 и 4.1. Их поведение абсолютно идентично пятерке…
Хотел сразу написать, что таким образом можно обрубить доступ CIS “к самому себе”, но решил проверить, в том числе на файлах. SerB меня опередил. Вообще в данном случае лучшим выходом было бы разбиение защищаемых ресурсов хотя бы на две-три группы (доверенным - доступ без запроса к группе А, системным - без запроса к А,Б, особо привилегированным - к А,Б,В, всё остальное только через запрос), будет намного удобнее и надежнее прописывать политики, но не уверен, что COMODO сейчас на это пойдёт…
P.S.
ИМХО, то, что Вы пытались сделать, лучше сделать так:
http://img820.imageshack.us/img820/3207/12345hs.th.png
Т.е., предполагается, что в защищаемых ветках, как и всегда по умолчанию, присутствует группа ключей COMODO, но она не вносится в явные разрешения, а на операции с защищаемым объектом ставится запрос. По такой схеме системные (в данном случае) процессы смогут работать без запроса со “своими” ключами, но будут вынуждены спрашивать разрешения при открытии (на запись, само собой) ключей Комодо. Ясно, что всё это расширяется на любой круг объектов и пресетов, но нудно и не ахти как удобно…
Я не пытался, я сделал
http://i038.radikal.ru/1011/7b/e51ffdb85c99t.jpg
http://i014.radikal.ru/1011/61/ac9d65d00c17t.jpg
То, как предлагается на вашем скрине у меня давно по умолчанию - и оно и не работает.
Comodo может и не пойдет - я сам давно перелопатил встроенные, где разделил, где добавил, а где и новые группы создал.
Ага,
чем запретили доступ к веткам вообще, даже на чтение и, судя по всему, всем, по крайней мере у SerB’а так вышло…
Посмотрите внимательно на скрины SerB’а. Он выставил в значение 4 параметр Start, отменив тем самым автогагрузку драйвера, и… перегрузился. И что должен был сказать Комодо лишившись драйвера?
P.S. Ан нет. он службу зарубил, но результат все равно на лицо
Угу, именно службу, но не суть важно, главное, что
Т.е. у него явно произошел либо конфликт правил, либо надо было перезайти, перегрузиться, что-нибудь в этом роде. Я почему и сказал, что хотел перепроверить сам, часто из-за этих пересекающихся правил не найдешь, где намудрил. А моя схема работает, у меня масса похожих правил прописана, просто при стандартных, может быть частично, комодовских настройках там тоже куча пересечений, в том числе по маскам. Сделаю завтра это всё с чистого листа, чтобы рабочий конфиг не уродовать, продемонстрирую.
Создал тему на англоязычном форуме - https://forums.comodo.com/beta-corner-cis/free-access-to-registry-keys-cis-t65504.0.html;new#new
Будем следить за ответами…
Как по мне, - это дырка(недоработка). [b]Не может быть [u]свободный[/u] доступ для удаления/редактирования ключей CIS\CFP в реестре Windows[/b]. [u]По умолчанию, при установке CIS\CFP[/u], они должны быть заблокированы для доступа, в т.ч. и на программном уровне. Так как описывал [b]zil968[/b] -
еще в третьей версии мне не удалось ничего сделать с реестром - отказ в доступе.
И в чём же тогда сейчас в CIS 5 заключается защита Защищенных ключей реестра, если для их изменения даже алерт не выскакивает, не говоря уже о блокировке доступа к этим ключам?
Ведь, что написано в Справке CIS 5:
[b]Protected Registry Keys[/b] Comodo Internet Security automatically protects system critical registry keys against modification. Irreversible damage can be caused to your system if important registry keys are corrupted or modified in any way . It is essential that your registry keys are protected against attack.перевод: [b]Защищенные ключи реестра[/b] Comodo Internet Security автоматически защищает важные ключи реестра системы от модификации. Необратимые повреждения могут быть вызваны в вашей системе, если важные ключи реестра будут повреждены или изменены каким-либо образом. Важно, чтобы ваши ключи реестра были защищены от нападения.
SerB, ИМХО, Вы не туда копаете. Тут дело вот в чём. Во-первых, ещё раз напишу, я не нашел никаких отличий в плане работы с защищаемыми ветками реестра между третьей, четвертой и пятой версиями, они ведут себя абсолютно аналогично. Не знаю, что имел в виду zil968, когда говорил
и тогда мне ничего с CIS 3 сделать не удалось, но подозреваю, что он пытался править эти ключи тем же регедитом, но не назначив ему профиль "Доверенное" или "Системное". Подозреваю, что и вчера он сделал так же, естественно, что CIS будет отбиваться от "неизвестных" приложений. Беда в том, что такой регедит можно использовать "у друзей", но самому им пользоваться потом невозможно. А если ему назначить профиль "Доверенное" или "Системное", то ему разрешается доступ к защищаемым веткам без вопросов. И фокус, который вчера хотел провернуть [b]zil968[/b] не работает, потому как (насколько я понял из опыта общения с CIS'ом) вот здесь: [URL=http://img44.imageshack.us/img44/4885/63974077.png] http://img44.imageshack.us/img44/4885/63974077.th.png [/URL] разрешения имеют приоритет над запретами. А в разрешениях для доверенных приложений вполне четко указано, что в HKLM\SYSTEM\ControlSet???\Services\* им писать [u]можно без запроса[/u]. и дописывать в запреты ветку HKLM\SYSTEM\ControlSet*\services\cmdAgent* бесполезно, поскольку она попадает в разрешение по маске. Лично я знаю только один способ прописать похожие правила, тот, о котором писал вчера. Но существенным его недостатком (в данном конкретном случае) является то, что ветку HKLM\SYSTEM\ControlSet???\Services\* нужно переносить целиком из "Важных ключей" в "Ключи COMODO", как вот здесь:
http://img442.imageshack.us/img442/8006/98567718.th.png
иначе ничего не выйдет всвязи с перекрывающимися масками. Но тогда мы, разумеется, столкнемся с вот такими фокусами:
http://img152.imageshack.us/img152/8855/58869273.th.png
http://img19.imageshack.us/img19/1231/21696949h.th.png
что, ясное дело, есть не то, чтобы не совсем гуд, а совсем не гуд. И проблема здесь заключается в том, что, выражаясь заумно, над множеством правил COMODO не определено вычитание. Или, проще говоря, мы не можем прописать в “Важных ключах” конструкцию вот такого типа:
HKLM\SYSTEM\ControlSet???\Services\*
-(HKLM\SYSTEM\ControlSet*\services\cmdAgent*)
Почему так было сделано изначально, сказать трудно, скорее всего просто не подумали сразу. Да и изменить это сейчас не то чтобы очень сложно, но я просто уверен, что сейчас этого делать никто не будет, Вы сами видите, что в английской ветке идет угадайка про DACS-туDACS-растуDACS, а Мелих сражается с ветряными мельницами Симантеком. Посмотрим, что нового откроется с приходом 5.1, тем более, что в нынешнем виде в CIS есть намного более серьёзные вопросы с дырявостью…
Подтверждаю. Сегодня опробовал на версии 3,9 записать в HKLM\SYSTEM\CurrentControlSet\Services\cmdAgent* - пишет молча.
А вот так скорее всего и было, когда я не смог побороть CIS 3. Дело было действительно “у друзей”. Пользователь того компьютера 100 % не знает что такое regedit, и, соответственно, никогда его не запускал, и, следовательно правил для него не было. CIS стоял запароленный и тихо рубил все, для чего не было правил.
Фокус работает. Я использую режим “Чистый ПК”, в котором все приложения считаются доверенными, если для них в CIS 5 явно не заданы правила. Я прекрасно модифицирую regedit любые ветки в HKLM\SYSTEM\CurrentControlSet\Services, пока не нарвусь на ветки, которые были мною внесены в группу ключей Комодо. Такой же самый способ с самого начала (когда ставилась задача сделать COMODO не убиваемым) я использую и для файлов COMODO . Никаких проблем - и базы обновляются, и файлы карантинятся, но вот Far (явных правил нет вообще, т.к. “Чистый ПК” => Доверенный ) прекрасно копирующий даже *.exe (при запуске от имени администратора и с подтверждением для UAC) в %Windir%, %Windir%\System32, %ProgramFiles% в каталог COMODO не может скопировать даже текстовый файл (настоящий, не по расширению). Сейчас понимаю, что надо было изначально так сделать и для реестра, но сбил меня с толку мой предыидущий опыт.
А я знаю еще один способ и без всяких фокусов. Сегодня таким же способом я закрыл ветки CIS 3,9 в HKLM\SYSTEM\ControlSet???\Services* на работе. Там я тоже использую режим “Чистый ПК”, но CIS 3,9 в этом случае хотя и считает все приложения доверенными, но все равно создает для них правила. Было правило и для regedit, которым я ранее пользовался. Правило я снес, сделал то что ранее описывал, запустил regedit и попробовал модифицировать HKLM\SYSTEM\CurrentControlSet\Services\cmdAgent - получил отказ. Точнее (Windows XP SP3) выглядит это так: визуально в реестре появляктся новое значение, но появляется сообщение “не могу записать”. После F5 (обновить) видно что не смог записать - отображается старое значение. Другое в HKLM\SYSTEM\CurrentControlSet\Services пишется/читается без вопросов. После этого в правилах приложений опять создалось правило для regedit.
Ну, значит, угадал. Одна беда, если “что-то” захочет сносить CIS, то это будет, скорее всего, не регедит, а какой-нибудь svchost, у которого туда доступ скорее всего есть…
А-аа, так вот в чем дело, Вы, наверное, ещё и все записи из защищенных фалов/веток и т.п. повыбили? Тогда, да, запреты, по идее, окажутся сильнее. Я только могу, к своему стыду, признаться, что “чистый пк” вообще никогда не использовал, даже не тестировал толком. Но, имхо, он больше подходит к системе, где всё поставил, настроил и “накорми собак и ничего не трогай”, а вот как оно будет на “живой” и постоянно шевелящейся системе надо будет испытать…
Ну в общем ответ по теме в аглицкой ветке и от американских модераторов форума приблизительно такой:
“…когда regedit запускает пользователь, то уведомления не будет, так как это инициировано пользователем. Если другим процессом, - будет уведомление.
CIS не нянька для пользователей и не защищает их от ошибочных действий…”
В принципе правильно, если бы не одно "НО": ключи(значения) системного реестра Windows, [u]имея к ним доступ(for change)[/u], можно изменить\удалить не только запуском regedit.exe, но и многими другими командами,программами,скомпилированными экзе-бат-рег-файлами и т.п., не говоря уже об удаленном доступе к ПК в локальной сети. Как поведет себя с ними HIPS фаервола неизвестно. Покажут только эксперименты и наработки пользователей...