Общие функции и параметры проактивной защиты
Рассмотрим опции, которые влияют на работу проактивной защиты в целом, включая и HIPS, и Auto-Containment.
Различные параметры проактивной защиты
Опция «Адаптировать режим работы при низких ресурсах системы» на вкладке «Настройка HIPS» нужна только при недостатке оперативной памяти. Когда она включена, CIS использует приемы экономии памяти, чтобы избежать сбоя при выполнении своих задач. Однако тем самым снижается производительность.
Опция «Блокировать неизвестные запросы, если приложение не запущено» предназначена только для зараженных систем и не рекомендуется к постоянному использованию, так как она мешает корректному автозапуску безопасных приложений. Если эта опция включена, то до тех пор, пока не загрузится графический интерфейс CIS, всем программам, независимо от их рейтинга, будет заблокирована любая активность, кроме явно разрешенной в правилах HIPS. Иначе говоря, до загрузки GUI поведение HIPS будет подобно «Параноидальному режиму» с опцией «Не показывать оповещения: Блокировать запросы». Блокировки не будет, если HIPS отключен или включен с опцией «Не показывать оповещения: Разрешать запросы».
К объектам, входящим в список HIPS → Защищенные объекты → Заблокированные файлы, запрещается любой доступ, включая и запись, и чтение. В данный список вносятся пути и шаблоны путей к файлам. Блокировка работает только при включенном HIPS.
Остальные параметры, задаваемые в разделе HIPS → Защищенные объекты имеют значение не только для HIPS, но и для Auto-Containment. Так, приложению, которое выполняется в реальной среде с ограничениями Auto-Containment, будет запрещен доступ именно к ресурсам, указанным на соответствующих вкладках этого раздела. Для приложений, выполняющихся в виртуальной среде, этот раздел тоже имеет значение: от них будет скрываться содержимое каталогов, перечисленных на вкладке «Папки с защищенными данными».
Особенности защиты файлов
Как уже говорилось, защите посредством HIPS или Auto-Containment (в отсутствие виртуализации) подлежат только те файлы и их группы, которые занесены в список HIPS → Защищенные объекты → Защищенные файлы. Для указания файлов можно использовать шаблоны (знаки * и ?) и переменные среды (%temp%, %windir% и т.д.).
Отмечу, что CIS воспринимает в качестве «файлов» не только физические файлы, но и различные системные объекты, например, сокеты Windows или устройства, физические или виртуальные. Поскольку в виртуальной среде COMODO отсутствует защита файлов, подобные объекты не защищаются от виртуально запущенных программ.
Добавляя в список защищенных файлов какой-либо каталог, следует учитывать, что он записывается в виде шаблона, наподобие D:\Docs\*. Добавление такого шаблона в список защищенных файлов означает защиту файлов и папок, расположенных в выбранном каталоге D:\Docs и его подкаталогах. Однако сам выбранный каталог Docs при этом не становится защищенным от переименования, и вредоносная программа, переименовав его, сможет повредить и его содержимое. Чтобы защитить не только содержимое каталога от изменений, но и его имя, можно отредактировать шаблон, оставив на конце только звездочку без слеша: D:\Docs*.
Как вариант, можно добавить в список защищенных файлов универсальный шаблон, чтобы изменение любых файлов неопознанными программами было запрещено (или пресекалось оповещениями). Возможны разные варианты «универсальных шаблонов». Если использовать самый общий шаблон *, то защищенными станут не только файлы, но и различные системные объекты — как следствие, оповещений HIPS станет слишком много. Шаблон ?:\* означает содержимое всех локальных дисков, однако он не охватывает файлы на шифрованных томах VeraCrypt. Шаблон *.* соответствует всем файлам, имя или путь которых содержит точку — на мой взгляд, это оптимальный вариант, чтобы охватить почти все файлы и почти ничего лишнего.
В списке HIPS → Защищенные объекты → Защищенные файлы многие шаблоны имеют на конце символ |, назначение которого раскрывалось в предыдущих статьях: его наличие влияет на автоматическое создание правил HIPS и на права программ, ограниченных посредством Auto-Containment без виртуализации. Отмечу, что на мой взгляд, нет смысла пользоваться ни режимами HIPS, при которых правила создаются автоматически, ни правилами Auto-Containment, предписывающими запускать программы ограниченно без виртуализации. Когда эти функции не используются, никакого влияния знака | на работу CIS не замечено.
По моим наблюдениям, не всегда корректно работает защита файлов на сетевых ресурсах, в частности, на сетевых дисках, а также на дисках, подключенных по протоколу WebDAV. В связи с этим рекомендую, формируя список защищенных объектов или правила HIPS, не конкретизировать, на каком сетевом ресурсе расположены файлы. Например, чтобы защитить содержимое папки Z:\Documents, расположенной на сетевом диске, желательно использовать шаблон вида *\Documents*, т.е. не привязанный к диску. Если все же необходимо конкретизировать местоположение, то рекомендую указывать в шаблоне не букву диска, а имя сетевого ресурса, наподобие \\*имя_сетевого_ресурса*\Documents*, \\*yandex*\* и т.п.
Защита данных от чтения
Можно защищать данные не только от изменений, но и, в какой-то мере, от чтения определенными приложениями. Для этого предназначена вкладка HIPS → Защищенные объекты → Защищенные данные. Каталоги, добавленные в список на этой вкладке, защищаются следующим образом:
- программы, запущенные виртуально, воспринимают эти каталоги пустыми;
- программам, запущенным в реальной среде с ограничениями Auto-Containment, запрещается обзор содержимого этих каталогов, а также чтение находящихся в них файлов;
- программам, которым посредством HIPS заблокирован ресурс «Диск», запрещается обзор содержимого этих каталогов (но остается возможным открытие содержащихся в них файлов).
Подчеркну, что именно при использовании виртуализации защищенные папки будут восприниматься изолированными приложениями как пустые, а их файлы — как несуществующие. Если программа ограничена только посредством HIPS, то она сможет открывать файлы, «зная» их пути.
Через интерфейс CIS можно добавить в список «Папок с защищенными данными» лишь те каталоги, которые видны в проводнике. Если необходимо защитить данные в каком-либо скрытом каталоге, следует временно разрешить показ скрытых файлов и папок в проводнике (например, через «Панель управления»).
В список «Папок с защищенными данными» следует добавлять каталоги, расположенные только на локальных дисках. Формально можно добавить в этот список съемные носители или виртуальные шифрованные диски, но для них защита, как правило, не работает.
Начиная с CIS 11, защищать от чтения можно делать не только каталоги, но и произвольные файлы, шаблоны их путей и группы — соответствующие файлы становятся невидимыми в виртуальной среде (но не в реальной). Также в какой-то мере стало работать сокрытие данных, размещенных на виртуальных шифрованных дисках. Однако, например, данные на томе VeraCrypt, смонтированном в режиме съемного устройства, по-прежнему не скрываются.
Специализированные приложения, имея права администратора, способны обойти данную защиту, даже если им заблокирован доступ к диску, даже если они выполняются в виртуальной среде, и даже если они изолированы в Auto-Containment как «Частично ограниченное» или «Подозрительное». Рекомендую держать включенным UAC.
Защита памяти процессов
CIS способен запрещать одним процессам изменять память других. Так, программам, которые запущены виртуально и/или с ограничениями Auto-Containment, запрещено менять память процессов, выполняющихся в реальной среде. Дополнительные ограничения на межпроцессное изменение памяти задаются в правилах HIPS.
Правила HIPS какой-либо программы или группы программ содержат две вкладки: «Права доступа» и «Настройка защиты». На вкладке «Права доступа» пункт «Межпроцессный доступ к памяти» указывает, чью память может изменять данная программа (см. порядок работы HIPS). На вкладке «Настройка защиты» пункт с аналогичным названием означает защиту памяти самой этой программы от изменения: если включить эту защиту, то всем приложениям, кроме указанных в списке исключений, будет запрещено менять память данной программы, независимо от их собственных правил HIPS (см. защиту процессов).
HIPS, Auto-Containment и виртуальная среда защищают память процессов от изменений, но не от чтения. Даже если заблокировать вредоносной программе «Межпроцессный доступ к памяти» и даже если запустить ее виртуально с ограничениями, она сможет прочитать конфиденциальные данные из памяти процессов, выполняющихся в реальной среде.
В то же время защита от межпроцессного изменения памяти препятствует созданию дампа памяти. По-видимому, запрещается именно приостановка процесса, необходимая для создания дампа, но не само чтение памяти.
Защиту памяти процессов от чтения предоставляет среда «Безопасного шоппинга»: память запущенных в этой среде программ запрещено читать программам, которые выполняются в обычной среде.
Защита конфигурации браузеров
В CIS есть дополнительная функция, защищающая конфигурацию браузеров, независимо от того, включен ли HIPS или Auto-Containment. Эта защита включается опцией «Показывать оповещения при попытках других программ изменять текущую настройку браузеров» на вкладке «Усиленная защита → Разное». Когда она активна, сторонним программам будет запрещено менять конфигурацию браузера без разрешения пользователя.
Ответ пользователя относительно той или иной программы запоминается лишь на время ее работы, а каких-либо правил, списков исключений и т.п. здесь нет. Также нет явного указания, какие именно браузеры подлежат защите и в чем эта защита заключается.
Судя по экспериментам, защита предотвращает изменение файлов, которые имеют расположение, характерное для конфигурационных файлов браузеров, например, соответствуют шаблону *\Mozilla\Firefox\Profiles\*.default\prefs.js. При этом, во-первых, не играет роли расположение этой структуры каталогов: будь это действительно профиль браузера в %AppData% или копия профиля, удаленная в корзину, — CIS одинаково станет его защищать. Во-вторых, не играет даже роли, установлен ли браузер: просто защищаются все файлы с характерными путями.
Отмечу, что путь указанного вида имеет только профиль обычного браузера Firefox, установленного в системе. Портативный вариант браузера не попадает под эту защиту.
Судя по экспериментам, CIS отличает браузеры от сторонних программ на основании подписи. Даже если сторонняя программа является доверенной, даже если она имеет привилегии установщика — попытка изменить конфигурацию браузера вызовет оповещение.
Анализ командной строки
Некоторые виды приложений выполняются не самостоятельно, а посредством программ-интерпретаторов. Например, выполнением bat-скриптов занимается системный интерпретатор cmd.exe, выполнением vbs-скриптов — системный интерпретатор wscript.exe, выполнением jar-приложений — программа javaw.exe, входящая в состав виртуальной машины Java, и т.д. При запуске скрипта (или подобного приложения) фактически запускается ассоциированная с ним программа-интерпретатор, получая путь этого скрипта в аргументах командной строки.
Когда запускается какой-либо интерпретатор, CIS принимает его за файл, заданный в аргументах командной строки. Так, в системном диспетчере задач процесс, исполняющий скрипт test.bat, отобразится как интерпретатор cmd.exe, а CIS в списке активных процессов определит его как скрипт test.bat. Соответственно, процесс интерпретатора получает именно те права и ограничения, которые имеет файл, указанный в аргументах командной строки.
Данное поведение CIS задается опцией Анализировать скрипты в разделе Усиленная защита (название до CIS 12 — «Выполнять эвристический анализ в командной строке»), по умолчанию она включена. Если ее отключить, то скрипты и подобные им приложения станут идентифицироваться как интерпретаторы, т.е. станет невозможным контролировать запуск неопознанных скриптов или назначать разным скриптам разные права.
В параметрах указанной опции задается таблица приложений, чья командная строка подлежит анализу. При необходимости можно для отдельных приложений отключить опцию в столбце «Анализ в командной строке» — тогда CIS не будет распознавать, исполнением каких файлов они занимаются. Также можно добавлять новые приложения в таблицу или редактировать имеющиеся записи.
Приложения, которые CIS воспринимает подобно интерпретаторам, задаются в таблице путями или шаблонами путей. Например, чтобы контролировать скрипты, выполняемые интерпретатором AutoHotkey.exe, понадобится добавить в таблицу его путь, наподобие C:\Program Files\AutoHotkey\AutoHotkey.exe. Можно применять шаблоны, например, задать интерпретатор строкой *\AutoHotkey.exe — тогда анализ командной строки будет работать для любой программы с именем AutoHotkey.exe, независимо от ее местоположения. Внимание! Здесь не работают переменные среды, т.е. нельзя использовать строку вида %PROGRAMFILES%\AutoHotkey\AutoHotkey.exe.
Интерфейс настройки анализа командной строки позволяет лишь указать расположение нового приложения-интерпретатора, но не способ разбора его командной строки. Судя по экспериментам, аргументы командной строки проверяются последовательно, пока среди них не встретится путь (абсолютный или относительный) какого-либо существующего файла — за этот файл и будет принято запускаемое приложение.
Описанный выше порядок идентификации интерпретаторов и разбора их командной строки относится именно к записям, добавленным пользователем. Предустановленные записи работают более тонко.
Хотя предустановленные записи выглядят, будто приложения-интерпретаторы идентифицируются лишь по именам, в действительности проверяется также рейтинг этих приложений. Судя по экспериментам, приложение с именем интерпретатора принимается за файл, указанный в командной строке, только если оно является доверенным.
Требование к рейтингу интерпретаторов защищает от атаки, которой был подвержен CIS старых версий: вредоносная программа, названная именем интерпретатора, при запуске получала права приложения, указанного в ее командной строке. К сожалению, такая атака остается возможной, если использовать имя не стандартного интерпретатора, а добавленного пользователем. В качестве защиты предлагаю указывать в пользовательских записях полные пути к интерпретаторам (c:\Program Files\AutoHotkey\AutoHotkey.exe), а не шаблоны (*\AutoHotkey.exe).
Недоработка: не проверяется рейтинг в предустановленных записях *\AutoIt3.exe и *\AutoIt3_x64.exe.
Другая особенность — доверенное приложение принимается за файл, указанный в его командной строке, даже если предустановленным шаблонам соответствует не имя этого приложения, а поле OriginalFilename в его File Version Info. Тем самым контролируется выполнение неопознанных скриптов переименованной копией интерпретатора. (Спасибо разработчикам, реализовавшим это пожелание.)
Опять же, анализ командной строки опирается на File Version Info только для предустановленных записей, но не для пользовательских. Поэтому, даже если добавить AutoHotkey-интерпретатор в таблицу приложениий, чья командная строка подлежит анализу, останется возможность запустить вредоносный скрипт переименованным интерпретатором.
Разбор командной строки несколько различается для разных приложений. По крайней мере, интерпретатор cmd.exe принимается за файл, указанный в его командной строке, только если командная строка начинается с аргумента /c или /k, за которым следует путь к файлу.
Еще одна особенность предустановленных записей: от свойств файла, указанного в командной строке, может зависеть, будет ли принято за него запускаемое приложение. Как правило, приложения-интерпретаторы принимаются только за файлы, которые не являются исполняемыми (Portable Executable). Эта особенность дополнительно препятствует некоторым способам обхода защиты.
Однако любое доверенное приложение с именем rundll32.exe принимается за любой файл, указанный в командной строке. Также и приложения, добавленные пользователем, принимаются за файлы любого типа.
Обнаружение внедренного кода
При запуске некоторых приложений-интерпретаторов можно передать в командной строке весь код, предназначенный для выполнения. Таким образом, в роли скрипта выступает сама командная строка, а не отдельный файл.
CIS способен контролировать запуск и активность таких бесфайловых скриптов. Он отслеживает передачу кода в командной строке при запуске интерпретатора и сохраняет этот код в файле. Затем CIS обращается с процессом интерпретатора как с этим файлом, применяя к нему ограничения, которые имеет этот файл. Файлы, в которых сохраняется внедренный код, создаются в каталоге %ProgramData%\Comodo\Cis\tempscrpt, при этом в имени файла указывается его хеш Sha1, например, C_cmd.exe_E9823A1FBD7DA4DB232D818039174D9C4DE8DA04.bat.
Контроль бесфайловых скриптов настраивается аналогично контролю обычных скриптов в таблице на вкладке «Усиленная защита → Анализ скриптов». За него отвечает столбец «Обнаружение внедренного кода».
По умолчанию контролируется код, передаваемый в командной строке интерпретаторам PowerShell и Python, а также программе rundll32.exe. Можно расширить контроль, включив обнаружение внедренного кода, например, для интерпретаторов *\cmd.exe и *\mshta.exe. Однако предпрежу, что если включить обнаружение внедренного кода для интерпретатора cmd.exe, то может потребоваться довольно кропотливая настройка исключений из этой защиты.
Опция защиты от внедрения shell-кода
На вкладке «Усиленная защита → Разное» расположена опция «Не обнаруживать внедрение shell-кода». Как следует из названия, она регулирует предотвращение атак, основанных на переполнении буфера.
Однако в действительности сообщения пользователей и эксперименты говорят о несостоятельности этой защиты в CIS. Возможно, ее наличие фиктивно.
Тем не менее список, заданный в опции «Не обнаруживать внедрение shell-кода», все же влияет на работу CIS. В работе приложения, исключенного из «защиты от shell-кода», наблюдаются следующие особенности:
- в его процесс не внедряется библиотека guard(32|64).dll (в обычные процессы внедряется);
- программы, запускаемые этим приложением, попадают под действие правил Auto-Containment, даже если на это приложение или его родительский процесс действует правило, предписывающее игнорировать его вместе с дочерними процессами;
- однако правила Auto-Containment не полностью применяются к программам, которые запускает это приложение: действует блокировка, виртуализация и ограничение по времени, но не действуют прочие ограничения;
- для программ, запускаемых этим приложением, не работает анализ командной строки и обнаружение внедренного кода, т.е. не контролируется запуск этим приложением скриптов;
- HIPS не контролирует определенную активность этого приложения:
- доступ к системным объектам, представленным как файлы, например, к сокетам Windows,
- доступ к системному интерфейсу DNS,
- доступ к клавиатуре,
- доступ к монитору,
- отправку оконных сообщений,
- установку глобального хука.
В то же время HIPS контролирует приложения, исключенные из «защиты от shell-кода», на предмет запуска программ, изменения файлов и реестра, межпроцессного доступа к памяти, доступа к диску, к некоторым COM-интерфейсам.
По-видимому, именно внедрение библиотеки guard(32|64).dll отвечает за функции CIS, которые не работают для приложений, исключенных из «защиты от shell-кода».
Иногда внедрение в процесс библиотеки guard32.dll или guard64.dll приводит к конфликтам. Поэтому, если какая-либо программа работает некорректно, имеет смысл добавить ее в исключения опции «Не обнаруживать внедрение shell-кода».
Отмечу, что в процессы браузеров дополнительно внедряется библиотека cmdshim(32|64).dll, помимо guard(32|64).dll. Ее внедрение также отключается исключением из «защиты от shell-кода». Кроме этих библиотек, используются, в частности, библиотеки Internet Security Essentials (iseguard(32|64).dll, внедряется в браузеры, кроме Edge) и Безопасного шоппинга (cssguard(32|64).dll, внедряется всюду) — однако их внедрение не отключается исключением из этой «защиты».
Контроль автозапуска
Начиная с версии CIS 12, имеются дополнительные средства для контроля за автоматическим запуском приложений. Анализируются различные виды автозапуска, включая реестр, задачи планировщика, службы и др.
За контроль над состоянием автозапуска в реальном времени отвечает опция Применять выбранное действие к неопознанным элементам автозапуска в разделе Усиленная защита → Разное. По умолчанию в ней выбран режим Игнорировать, т.е. не предпринимать никаких действий.
Если выставить режим Изолировать в карантине и отключить, то, как только в системе появится новый автозапуск какой-либо неопознанной программы, CIS удалит эту программу и отключит элемент автозапуска.
Чтобы избежать автоматического отключения автозапуска и удаления программы, понадобится либо сделать ее доверенной, либо добавить в исключения: Усиленная защита → Исключения сканирования → Исключенные пути.
Действия, выполняемые CIS'ом, обратимы: программу можно будет восстановить из карантина, а элемент автозапуска вернуть в прежнее состояние. Эти элементом может оказаться отключенная задача в планировщике, или перемещенный в папке COMODO DISABLED ярлык, или перемещенная в раздел Run.COMODO_DISABLED запись в реестре и т.д.
Важно учесть, что при очистке автозапуске нет ни оповещений для выбора действия пользователем, ни даже уведомлений. Информация о произошедшем лишь молча заносится в журналы События автозапуска и События антивируса, причем даже в них нет дается достаточно подробностей, какой именно элемент и каким образом был отключен.
Таким образом, режим Изолировать в карантине и отключить выглядит рискованным. Однако в режиме Прервать вообще никакого эффекта от защиты автозапуска замечено не было. Поэтому сомнительной представляется вся функция постоянного контроля за автозапуском.
Кроме постоянного контроля, есть возможность проверки автозапуска по требованию или по расписанию. Для этого необходимо создать в разделе Антивирус → Виды сканирования новое сканирование и задать в нем опцию Применять это действие к подозрительным процессам автозапуска (можно отключить остальные опции этого сканирования, а в качестве его «объекта» добавить пустую папку).
Если теперь запустить это сканирование, выполнится очистка автозапуска, причем выведется отчет об удаленных элементах.
Дополнительно можно настраивать, как должна анализироваться командная строка для атозапускаемых программ. Эти параметры задаются на вкладке Усиленная защита → Анализ скриптов → Сканирование элементов автозапуска. Здесь можно указать, для каких интерпретаторов следует контролировать автозапускаемые скрипты, с том числе бесфайловые.
VirusScope
Оповещения VirusScope
Кроме основных средств проактивной защиты — HIPS и Auto-Containment — имеется компонент VirusScope, предназначенный для динамического обнаружения подозрительной активности процессов. Он должен выявлять опасное поведение неопознанных программ и выдавать оповещение с предложением откатить изменения, произведенные определенной программой и ее дочерними процессами, а саму программу удалить.
Если включена опция «Не показывать оповещения» на вкладке «Усиленная защита → VirusScope», то удаление программ и откат изменений произойдет автоматически (аналогично, если не отвечать на оповещение в течение 2 минут).
Откат изменений вручную
Завершение программ с откатом произведенных ими изменений можно производить не только при обнаружении подозрительной активности, но и вручную. Для этого следует запустить менеджер задач KillSwitch, вызвать контекстное меню на нужном процессе и выбрать пункт «Завершить дерево процесса и вернуть произведенные изменения». Файл программы при этом не удаляется. Данный пункт контекстного меню KillSwitch имеется только при включенном VirusScope.
Другой путь ручного завершения программ с откатом произведенных ими изменений — оповещения HIPS и фаервола. Когда включен VirusScope, в этих оповещениях появляется дополнительный пункт: «Заблокировать, завершить выполнение и отменить изменения». При выборе этого пункта завершится указанная в оповещении программа и все ее дочерние процессы, а также будут отменены произведенные ими изменения; файл программы удален не будет.
Отчет об активности
При включенном VirusScope в контекстном меню списка активных процессов, вызываемом из главного окна CIS, появляется новый пункт: «Показать активность». Нажатием на него откроется окно с отчетом об активности выбранной программы и ее дочерних процессов.
Также при включенном VirusScope в оповещениях разных компонентов CIS появляется кнопка «Показать активность». По нажатию на нее тоже открывается отчет об активности программы, указанной в оповещении.
Следует сказать, что представление отчета об активности в окне CIS далеко от удобного. Однако можно через контекстное меню экспортировать этот отчет в XML-файл и изучать отдельно.
Также отчет об активности можно просмотреть через менеджер задач KillSwitch: в окне свойств процесса, вызываемом через контекстное меню, есть вкладка «Активность процесса». Однако в KillSwitch этот отчет представлен еще хуже, чем в CIS, причем отсутствует функция экспорта в файл.
Ограничение контроля VirusScope только изолированными программами
По умолчанию в конфигурации «Proactive Security» на вкладке «Усиленная защита → VirusScope» включена опция «Использовать VirusScope» и отключена опция «Отслеживать только приложения, запущенные в Контейнере». В такой конфигурации происходит слежение за всеми процессами в реальной и в виртуальной среде. Выше описана работа VirusScope именно для такого режима.
Если отметить опцию «Отслеживать только приложения, запущенные в Контейнере», то будет отслеживаться активность только тех программ, которые запущены в виртуальной среде или ограничены посредством Auto-Containment. Для программ же, выполняющихся в реальной среде без ограничений Auto-Containment, не будет вестись запись активности и, соответственно, не будет даваться отчет о ней.
Однако после включения данной опции оповещения HIPS и фаервола по-прежнему будут содержать пункт «Заблокировать, завершить выполнение и отменить изменения», а также в контекстном меню KillSwitch будет пункт «Завершить дерево процесса и вернуть произведенные изменения». В действительности, выбор этих пунктов приведет не к откату изменений, а лишь к завершению выбранной программы и ее дочерних процессов.
Управление распознавателями
На вкладке «VirusScope» указан файл, на основании данных которого определенная активность приложений считается подозрительной. В этом файле заданы образцы поведения, которые должны вызывать оповещения VirusScope. Если перевести статус такого файла в отключенное положение, то соответствующее поведение приложений не приведет к оповещениям и блокировкам VirusScope; слежение за активностью программ при этом сохранится.
Ограниченность применения и проблемы VirusScope
В VirusScope невозможен откат таких действий, как удаление файлов с диска. Также не подлежат откату изменения, выполненные за предыдущие циклы работы подозрительного процесса. Откат же действий процесса, ошибочно признанного опасным, может привести к потере данных (этот риск возникает в режиме «Не показывать оповещения»).
В версии CIS 7 наблюдалась серьезная проблема — при включенном VirusScope происходили непредсказуемые сбои в работе безопасных приложений. Эти сбои происходили в отсутствие каких-либо уведомлений и записей в журналах CIS, что затрудняло поиск их причины. По-видимому, сбои провоцировались самим наблюдением за процессами, а не обнаружением подозрительного поведения.
В дальнейших версиях CIS перестали проявляться прежние известные конфликты. Возможно, проблема устранена. Однако, ввиду ее серьезности и трудности обнаружения, я по-прежнему рекомендую отказаться от VirusScope. С учетом всех ограничений, польза от VirusScope в защите выглядит сомнительной.
Для безопасного использования VirusScope можно включить его с опцией «Отслеживать только приложения, запущенные в Контейнере». Но в этом случае назначением VirusScope станет не защита, а исследование работы приложений, запущенных в виртуальной среде.