Модели и методы антивирусной защиты на основе контроля штатного функционирования системного ПО

Ревизоры могут обнаружить любые вирусы, даже ранее неизвестные. Но для этого необходимо "поставить  на учет” заведомо чистые от вирусов  возможные объекты нападения. Кроме  этого, ревизор не обнаружит вирус, который попал с новым зараженным уже файлом, так как он "не знает” параметров этого файла до заражения вирусом. Вот когда новый вирус уже заразит другие файлы или загрузочный сектор, он будет обнаружен ревизором. Не сможет ревизор обнаружить вирус, заражающий файлы только при копировании, опять же не имея возможности сравнить параметры файлов. Ревизоры неэффективно использовать для обнаружения вирусов в файлах документов, так как эти файлы очень часто изменяются. Кроме того, следует учитывать, что ревизоры только обнаруживают изменения, но не все изменения связаны с внедрением вируса. Загрузочная запись может измениться при обновлении версии операционной системы, могут измениться командные файлы, некоторые программы могут записывать в свои исполняемые файлы данные, что тоже приводит к изменению файлов, в конце концов, пользователь может просто перекомпилировать свою программу.

В этих случаях у ревизоров  один общий недостаток с программами-мониторами: пользователь должен хорошо разбираться  во всех таких случаях и сам  принимать решения - является ли изменение  результатом действия вируса или  нет. То есть программы-ревизоры не предназначены  для рядового пользователя.

Правда, в последнее время  ревизоры дополняются базами сигнатур вирусов, и при подозрении на вирус  ревизор тут же осуществляет сканирование в поисках вирусов. Такие ревизоры уже более пригодны для использования  рядовыми пользователями.

Простейшая программа-ревизор Microsoft Anti-Virus (MSAV) входит в состав операционной системы MS-DOS. Более известна программа-ревизор Advanced Dikinfoscope (Adinf), созданная Дмитрием Юрьевичем Мостовым. Эта программа, кроме выявления новых вирусов, способна обнаруживать еще и Stelth-вирусы.

5. Защита на основе штатного функционирования.

Прежде всего, приведем известную  укрупненную классификацию вирусных атак:  

1. "Вредные программы" (трояны).

Отдельные программы, которые  выполняют те или иные деструктивные/несанкционированные  действия.

  2. «Вирусы».

Программы, обычно не имеющие  собственного исполняемого модуля и "живущие" (как правило, заражение осуществляется по средством их присоединения к  исполняемому файлу) внутри другого  файлового объекта или части  физического носителя. 

3. «Черви». 

Разновидность 1,2,4, использующая сетевые возможности для заражения.   4. «Макро-вирусы» (скриптовые вирусы)

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

Что же следует из этой классификации? Да то, что угрозу вирусной атаки  несет в себе процесс, по каким-то причинам реализующий то действие, от которого необходимо защититься. 

А теперь введем классификацию  процессов, или причин, обусловливающих  наше недоверие к определенным группам  процессов:

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

- Критичные процессы. К ним мы отнесем две группы процессов.

К процессам первой группы отнесем те, которые запускаются в системе с привилегированными правами, например, под учетной записью System, для которой механизмы защиты ОС не реализуют разграничительную политику доступа к ресурсам в полном объеме, к процессам второй группы те, которые наиболее вероятно могут быть подвержены атакам, например, это сетевые службы. Атаки на процессы первой группы наиболее критичны, что связано с возможностью расширения привилегий, в пределе – получения полного управления системой, атаки на процессы второй группы наиболее вероятны;

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

- Процессы, априори обладающие недекларированными (документально не описанными) возможностями. К этой группе мы отнесем процессы, являющиеся средой исполнения (прежде всего, это виртуальные машины, являющиеся средой исполнения для скриптов и апплетов, и офисные приложения, являющиеся средой исполнения для макросов).

 Итак, мы выделили группы  процессов, действия которых могут  нести в себе угрозу. Возникает  вопрос, что же следует защищать? Здесь имеет смысл говорить  о том, что в равной мере  защищать требуется и информационные (в первую очередь, файловые  объекты), и системные ресурсы,  в частности системный диск, исполняемые  файлы приложений, системные ресурсы  реестра ОС  (если речь об  ОС Windows) от модификации.    Вернемся к процессам. Следуя нашей квалификации, можно выделить две большие группы процессов – это сторонние, которым на защищаемом компьютере не место, и те процессы, которые необходимы для работы пользователю и которые могут нести в себе угрозу. Например, это офисные приложения, позволяющие запускать макросы.    Макро-вирусы являются побочным эффектом идеи тотальной автоматизации приложений, к которым, в первую очередь, следует отнести офисные приложения Microsoft, за счет использования макросов. Если какая-либо задача часто выполняется, ее выполнение можно автоматизировать с помощью макроса. Макрос — это набор команд и инструкций, выполняемых как одна команда.    Макросы, как правило, используются для решения следующих задач:   - Для ускорения часто выполняемых операций редактирования или форматирования;   - Для объединения нескольких команд, например, для вставки таблицы с указанными размерами и границами и определенным числом строк и столбцов;

  - Для упрощения доступа  к параметрам в диалоговых  окнах; 

- Для автоматизации обработки  сложных последовательных действий  в задачах.  

Другими словами, пользователь может произвольно расширить  возможности используемого программного обеспечения. Проблема же состоит в  том, что на возможности расширения функций офисных приложений практически  нет никаких ограничений. Ядро автоматизации  составляет Visual Basic for Application (VAP). Он включает в себя функции работы с реестром и файловой системой, что позволяет  осуществлять деструктивные действия не только по отношению к обрабатываемым данным, но и в отношении системных ресурсов. Высокая распространенность макро-вирусов имеет очень простое объяснение.

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

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

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

  Стоит также сказать,  что в последнее время макро-вирусы  все чаще используются совместно  с другими вирусными атаками.  Так, например, Kukudro.A – это макро-вирус,  внедряющий на зараженные компьютеры  троян Downloader.JIH. Очевидно, что принципы  антивирусной защиты для данных групп процессов должны кардинально различаться.

5.1. Защита от сторонних процессов

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

 В подтверждение сказанному  приведу достаточно наглядную аналогию. Есть самостоятельная   задача  защиты   – контроль  программ   на  наличие в них недекларированных (не описанных в документации) возможностей (НДВ). Проводится подобный контроль НДВ, посредством анализа исходного текста программы. Известно, что трудоемкость  проведения  подобного анализа сопоставима с трудоемкостью разработки  программы,  и может составлять  месяцы,  а иногда  и годы.  Самое интересное, что и в результате проведения подобного контроля, никто не поручится за то, что программа не содержит НДВ. Антивирусные же средства предлагают нам провести подобный контроль программ в реальном времени, на основании  некоего сигнатурного анализа. Если бы все было бы так просто!

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

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

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

Под корректностью реализации разграничительной политики доступа  в данном случае понимается предотвращение любой возможности модификации  разрешенных к запуску исполняемых  файлов, а также предотвращение любой  возможности запуска под их именем (под «видом» санкционированных) других (несанкционированных для  выполнения)   исполняемых файлов.

Очевидно, что при реализации на защищаемом компьютере подобного  решения, любая сторонняя программа, в том числе, и любая вредоносная  программа, не сможет быть запущена. Общность данного решения состоит в том, что не требуется какого- либо анализа (сравнения с эталоном) кода, который в общем случае не может быть осуществлен корректно, не требуется каких-либо выявления сигнатур, составления баз и т.д., т.к. все, что не разрешено, то запрещено, а разрешается только то, в чем мы уверены. Заметим, что при таком решении уже становится неважно, что несанкционированная программа каким-либо способом занесена на компьютер – ее все равно  невозможно запустить! Другими слова, не требуется противодействовать занесению вредоносного кода на защищаемый компьютер, что существенно упрощает задачу защиты.

 Однако не следует  забывать о разнородности вредоносного  кода, что, в том числе, определяет  и различные способы его запуска.  Дело в том, что деструктивные  программы могут запускаться,  как под учетной записью пользователя, так и под системными учетными  записями, например, System, что, в первую  очередь, характерно для эксплойтов. С широкими правами создается  учетная запись при установке  СУБД и т.д. При  этом  необходимо учитывать, что ошибки программирования могут обнаруживаться, как в системном, так и в прикладном ПО. 

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

Видим, что речь зашла  об инновационных подходах. Такой  подход, например, реализован в Комплексной  системе защиты информации (КСЗИ) «Панцирь-К» для ОС Windows  2000/XP/2003 (разработчик  ЗАО «НПП  «Информационные технологии в бизнесе»), и состоит он в  следующем.

Для решения рассматриваемой  задачи (и иных задач защиты, которые  будут рассмотрены далее) при  управлении доступом к ресурсам в  КСЗИ (в большинстве механизмов контроля доступа к ресурсам) различаются  два самостоятельных субъекта доступа  – «пользователь» и «процесс». При  этом реализованы следующие схемы  задания  разграничительной  политики  доступа к ресурсам:

- Разграничение прав доступа к объектам процессов вне разграничений пользователей (эксклюзивный режим обработки запросов процессов - доступ к объекту разрешается, если он разрешен процессу);

- Разграничение прав доступа к объектам пользователей, вне разграничений процессов (эксклюзивный режим обработки запросов пользователей - доступ к объекту разрешается, если он разрешен пользователю);

- Комбинированное разграничение прав доступа - разграничение прав доступа к объектам  процессов  в рамках  разграничений  пользователей  (доступ  к объекту разрешается, если он разрешен и пользователю, и процессу).

 Таким образом, в  качестве субъекта доступа может  рассматриваться либо только  пользователь, либо только процесс,  либо «пара» – процесс и  пользователь.

5.2. Защита от атак со стороны санкционированных процессов