Третий уровень КСАЗ — это уровень защиты серверов и рабочих станций. Иногда для ясности говорят "файловых серверов и рабочих станций", чтобы не включать в категорию защищаемых объектов, например, почтовые сервера. Такая подмена не вполне оправдана.
Важно понимать, что два предыдущих уровня КСАЗ — уровень защиты шлюзов и уровень защиты почтовых систем - выполняют задачу перехвата вирусов на стадии распространения (проникновения) и никак не участвуют в защите от вредоносных программ на этапе их - программ - активации. Напротив, задача третьего уровня защиты, в первую очередь, - воспрепятствовать активации вируса и выполнения им заложенных функций.
В связи с этим отличаются и принципы, по которым определяется состав защищаемых на третьем уровне узлов. Если на уровнях защиты шлюзов и почтовых систем защищаемые узлы определялись по признаку назначения и выполняемых функций (обработка соответствующего потока информации), то на третьем уровне одним из основных признаков для включения узла в класс защищаемых является существование вредоносных программ, которые могут быть запущены (активированы) на узле.
Соответственно, третий уровень КСАЗ охватывает далеко не только сервера, выполняющие функции файловых хранилищ. К подлежащим защите на этом уровне вполне могут относиться номинальные почтовые сервера или сервера баз данных, если они используют операционную систему семейства Microsoft Windows.
Учитывая, что большинство современных вирусов попадают на компьютеры по сети, для обозначения третьего уровня КСАЗ используют также формулировку: уровень защиты сетевых серверов и рабочих станций. Несмотря на то, что такое определение уже гораздо точнее, оно тоже не является безупречным. Гипотетически можно предположить компьютер, использующий операционную систему серверного класса, предназначенный для обработки классифицированной информации и по этой причине отключенный от сети. Такой компьютер тоже необходимо защищать в рамках третьего уровня КСАЗ, поскольку поступающие через сменные носители непроверенные данные представляют собой угрозу с точки зрения вирусного заражения, а с учетом особой важности обрабатываемой информации, суммарный риск будет слишком большим, чтобы его игнорировать.
Впрочем, описанная гипотетическая ситуация достаточно редко встречается в реальных автоматизированных системах, и для практических целей можно было удовлетвориться формулировкой: третий уровень КСАЗ - это уровень защиты сетевых серверов и рабочих станций. Сетевых в данном случае означает - подключенных к сети.
Уже глядя на название, можно сделать вывод о некоторой неоднородности третьего уровня КСАЗ с точки зрения используемых средств защиты. Если общность угроз позволяет объединить сетевые сервера и рабочие станции в один уровень, то существенно разные профили использования выражаются в различных требованиях к эксплуатационным характеристикам АПО. Как следствие, достаточно часто для защиты сетевых серверов и рабочих станций используются разные продукты.
Принимая во внимание вышесказанное, естественным выглядит выделение на третьем уровне КСАЗ двух подсистем:
Однако этими подсистемами уровень не исчерпывается. Сказывается тот факт, что сетевые сервера и рабочие станции - наиболее многочисленный класс узлов в сети: в крупных организациях их количество может составлять несколько сотен, тысяч или даже десятков тысяч узлов. Встречаются и еще более крупные сети. В связи с этим возникает проблема контроля и управления защитой всех этих узлов.
Как показывает практика, ничего лучше для решения указанной проблемы, чем создание отдельной подсистемы управления, пока придумать не удалось. Таким образом третий уровень КСАЗ - уровень защиты сетевых серверов и рабочих станций - в общем случае состоит из трех подсистем:
При этом чаще всего говорят не о подсистеме управления, а о системе управления. Связано это с тем, что на других уровнях КСАЗ подсистем аналогичного назначения нет: либо функции управления входят в состав антивирусных средств (это требование-минимум), либо система управления третьего уровня КСАЗ распространяется также на средства защиты шлюзов и почтовых систем.
Далее в главе будут отдельно рассмотрены средства защиты рабочих станций, средства защиты серверов и средства управления. Для каждой из подсистем сперва проводится обзор основных угроз, условий эксплуатации и применяемых в связи с этим технологий, после чего формулируются требования к программному обеспечению данного класса.
Как можно понять из приведенных ранее примеров, подсистема защиты рабочих станций также далеко не всегда оказывается однородной в смысле используемых средств защиты. Причина тому - неоднородность самих рабочих станций с точки зрения используемых операционных систем.
Сегодня рабочими станциями могут быть компьютеры, работающие под управлением таких операционных систем:
В силу существенных архитектурных различий рабочие станции Windows обычно делят на два дополнительных подкласса:
Прямым следствием такого положения дел является наличие различных - зачастую даже по антивирусному функционалу - средств защиты для каждого из классов рабочих станций.
Как уже говорилось выше, основной причиной введения системы управления на третьем уровне является необходимость управлять большим количеством антивирусных средств. Верно и обратное, когда количество защищаемых узлов невелико, система управления, как правило, не используется.
Поэтому существуют различные версии антивирусных средств защиты рабочих станций - предназначенные для взаимодействия с системой управления и не предназначенные. Первые называют по-разному, но чаще всего - сетевыми или корпоративными версиями, иногда - управляемыми. Для вторых устоялся единый термин - персональные версии.
Продукты для защиты рабочих станций Linux/Unix или MacOS нередко вовсе не имеют сетевых (корпоративных) вариаций. Причина та же - количество таких рабочих станций, как правило, невелико.
В последние годы ситуация начала меняться и сейчас нередко можно встретить институты или правительственные организации, полностью оснащенные рабочими станциями на базе Linux. Тем не менее, во-первых, количество вирусов для этой платформы ничтожно в сравнении с количеством вирусов для Windows, а во-вторых, новые вирусы для Linux появляются также крайне редко. Результатом такого положения вещей является низкая вероятность заражения и отсутствие насущной необходимости в постоянном контроле состояния системы защиты.
Как известно, большинство современных вредоносных программ являются ОС-ориентированными, т. е. могут запускаться только на некоторых типах родственных ОС (как правило, ОС Windows). Более того, способы распространения (проникновения) также во многих случаях являются ОС-ориентированными. По этой причине рассмотренные ранее в совокупности вирусные угрозы в различной степени относятся к разным классам рабочих станций.
Большинство угроз, и это неудивительно, ориентированы на ОС семейства Windows. Под управлением ОС этого семейства функционирует львиная доля всех компьютеров в мире, что создает большой простор для деятельности авторов вирусов, на что бы эта деятельность ни была направлена - удовлетворение личных амбиций, приобретение известности, получение прибыли или всего вместе.
Для заражения компьютера под управлением Microsoft Windows применяются практически все способы проникновения и активизации. Используются всевозможные каналы проникновения, уязвимости в системных и прикладных программах, методы социальной инженерии. Соответственно, ПО для защиты рабочих станций Windows должно обладать средствами для противодействия по возможности всем видам угроз.
В конечном итоге, за редкими исключениями, чтобы запуститься, вирусу необходимо сохранить свой код на диске
компьютера-жертвы в виде файла — зараженного файла, в случае чистого вируса, либо полностью вредоносной программы,
в случаях червей и большинства
Соответственно, основные средства из состава антивирусного комплекса для рабочих станций Windows направлены на предотвращение записи вредоносного кода на диски компьютера, на предотвращение запуска вредоносных программ, а также на проверку хранящихся на дисках (постоянных, сменных, сетевых) файлов - нет ли в них вредоносного кода. Последняя функция нужна для того, чтобы при запуске (или сразу после установки) антивируса удостовериться в отсутствии вирусов на компьютере - функции предотвращения в последствии позволяют сохранить этот status quo.
Как уже отмечалось в классификации антивирусов, средства проверки файловой системы бывают двух видов:
Реализация подобных средств может быть различной. Это могут быть независимые модули, либо различные функции одного и того же модуля. Модуль проверки при доступе, который по понятным причинам должен постоянно находиться в памяти компьютера в зависимости от применяемых технологий может быть выполнен в виде приложения, службы или драйвера файловой системы. Эффективность при этом растет в порядке перечисления.
Кроме того, что на момент установки или запуска антивируса вредоносные программы могут находиться на дисках, они могут находиться также и в памяти компьютера. Соответственно, имеется необходимость в проверке памяти. Особенности архитектуры операционной системы Windows таковы, что отслеживать изменения в памяти на лету попросту невозможно. В связи с этим функции проверки памяти выполняются сканером по требованию.
С точки зрения применяемых технологий обнаружения вирусов, основной упор при проверке объектов памяти и файловой системы
делается на
Тем не менее, в некоторых специфических случаях применение поведенческого анализа не только оправдано, но и является более эффективным методом предотвращения запуска новых вирусов, чем эвристический анализ.
Стоит сказать, что современные вирусы крайне редко пытаются записать данные в загрузочные сектора или в BIOS.
Эпоха
Если в случае исполняемых файлов, подозрительные операции выделить достаточно сложно в силу очень большого разнообразия этих файлов и решаемых ими задач, то сфера применения макросов в документах Microsoft Office и других офисных пакетов, достаточно ограничена - чаще всего они используются для сокращения времени на выполнение рутинных операций или же для придания дополнительной функциональности документам. В большинстве случаев действие макроса распространяется только на документ, в состав которого он входит, а взаимодействие с другими документами чаще всего ограничивается операциями чтения. Следовательно, активные действия связанные с файловыми операциями или с записью в другие документы, могут вызывать обоснованные подозрения.
Нерассмотренным остался метод анализа изменений (контрольных сумм). Здесь необходимо отметить, что для обнаружения вирусов этот метод в современных условиях уже не годится. Даже в системном каталоге Windows количество файлов может достигать нескольких тысяч. При этом обновления ОС и ряда приложений регулярно приводят к изменениям в составе и версиях хранящихся там файлов. Анализ изменений на дисках в целом - задача еще более трудоемкая и плохо автоматизируемая.
Конечно, опытный специалист на основании данных об изменениях в файловой системе мог бы с большой вероятностью определить признаки заражения неизвестным вирусом. Но количество времени, необходимое на такой анализ, делают его с одной стороны невозможным в сколько-нибудь больших сетях, а с другой стороны нерентабельным в сетях небольшого размера или в единичных случаях - из-за стоимости услуг по привлечению высококвалифицированного специалиста.
Тем не менее, даже если анализ контрольных сумм не позволяет определить факт наличия вируса в системе, он позволяет определить факт отсутствия вирусов в файлах, контрольная сумма которых осталась неизменной. Об использовании метода сравнения контрольных сумм в таком качестве будет рассказано при рассмотрении эксплуатационных характеристик антивирусных продуктов.
Одним из наиболее часто используемых каналов проникновения вредоносных программ по прежнему остается электронная почта. И хотя для предотвращения пересылки зараженных писем имеются специализированные средства антивирусной защиты уровня почтовых систем, существует множество ситуаций, когда такие средства по тем или иным причинам не используются.
В связи с этим, антивирус для рабочих станций Windows должен обладать собственными средствами защиты от вирусов, приходящих по почте.
Нужно отметить, что с большинством таких вирусов вполне справляются стандартные средства проверки файловой системы, поскольку находящийся во вложении вирус, даже будучи запущенным пользователем, все равно сначала сохраняется на диск во временный каталог, и только потом загружается в память. В момент сохранения он будет обнаружен и обезврежен средством проверки при доступе.
Для чего же в таком случае нужны и нужны ли вообще дополнительные средства проверки почты? В первую очередь для повышения производительности и надежности. Не секрет, что наибольшее "замедление" работы компьютера связано именно с работой постоянной защиты файловой системы. По этой причине многие пользователи отключают эту защиту вовсе или неоправданно снижают уровень защиты в настройках. Модуль защиты почты серьезного влияния на производительность не оказывает и может работать едва ли не с максимальными настройками, перекрывая один из наиболее опасных, с точки зрения распространения вирусов, потоков.
В силу того, что задача постоянной защиты файлов не проверяет архивы, только задача постоянной защиты почты может помешать отправке письма с инфицированным вложением, что также немаловажно.
По сути, локальный модуль проверки почтовых сообщений играет роль отсутствующего антивируса на почтовом сервере - он снижает нагрузку на другие модули проверки и уменьшает общую вероятность заражения. Например, некоторые черви используют уязвимости в почтовых клиентах для автоматического запуска зараженного вложения. Если проверка файловой системы по каким-то причинам отключена, получение такого червя означало бы немедленное заражение, не будь в составе антивирусного комплекса модуля проверки почты.
Кроме этого, не следует забывать, что любой вирус, даже находящийся в архиве или почтовой базе, представляет
собой потенциальную угрозу. Если вирус уже так или иначе проник на компьютер и ожидает, что пользователь сам его
запустит, это рано или поздно может случиться. Полная проверка компьютера проводится, как правило, не так часто:
раз в неделю, а то и реже, чтобы можно было быть уверенным в своевременном обнаружении и удалении вируса внутри
архива и/или почтовой базы. А значит, есть шанс, что вирус будет запущен пользователем хотя бы по причине
небрежности или случайной ошибки. Использование модуля проверки почты позволяет не допустить появления в
почтовой базе зараженных объектов и предотвратить возникновение потенциально
Есть и еще одна опасность. Как известно, в ответ на то, что антивирусы стали проверять заархивированные вложения, многие вредоносные программы стали распространяться в защищенных паролем архивах, указывая пароль в теле сообщения. В отсутствие модуля проверки почты, такие письма будут беспрепятственно попадать в почтовый ящик с все тем же риском быть запущенными. Но в этом случае даже проверка по требованию может не обнаружить такие вирусы, если не включена или не реализована проверка в архивах, защищенных паролем.
С точки зрения технологий, используемых в модулях проверки почты, можно выделить два направления в которых ведутся разработки:
Преимущества первого способа состоят в том, что проверяются все почтовые сообщения, обрабатываемые почтовым клиентом, независимо от используемых протоколов. С другой стороны, обеспечить необходимую интеграцию со всеми возможными почтовыми клиентами - задача практически неразрешимая. Поэтому используется второй способ, когда модуль проверки перехватывает соединения по некоторым почтовым протоколам, вычленяет из потока данных объекты, которые могут быть заражены, и проверяет их.
Каждый из способов имеет свои преимущества и недостатки. Интеграция обычно поддерживается с очень ограниченным числом почтовых клиентов, например, только с клиентом Microsoft Outlook. С другой стороны, способ перехвата соединений также ограничен в числе поддерживаемых протоколов - как правило, это только протоколы SMTP и POP.
Наравне с почтой, и в последнее время особенно часто, для проникновения на компьютер вредоносные программы используют поток данных непосредственно из Интернет. Соответствующие угрозы можно разделить на несколько классов:
С угрозами первых двух типов успешно справляется средство проверки файловой системы при доступе - загруженный файл будет проверен в момент записи на диск. Кроме этого могут использоваться и другие технологии.
Так, большинство менеджеров загрузки обладают возможностью запускать антивирусную проверку всех загружаемых файлов. Для эффективного использования этой возможности антивирус должен поддерживать передачу объектов для проверки и параметров проверки через командную строку.
Для защиты от использования на веб-страницах вредоносных скриптов, инициирующих несанкционированную загрузку и выполнение программ может использоваться специальный компонент проверки скриптов. Как известно, для выполнения скриптов, написанных на языках VBScript и JavaScript в ОС семейства Windows используется специальный компонент - Windows Script Host, допускающий интеграцию внешних фильтров. В некоторых антивирусах реализован отдельный модуль, проверяющий все скрипты, выполняемые посредством Windows Script Host, обеспечивая защиту не только от веб-страниц, но также от содержащих скрипты писем в html-формате и просто от сохраненных на диске скриптов.
Удаленная атака на сетевые службы является более серьезной проблемой, которую стандартными антивирусными средствами решить не удается - постоянный контроль адресного пространства в ОС Windows невозможен. Для защиты от подобных атак в антивирусные средства интегрируется часть функций персональных брандмауэров либо полноценный персональный брандмауэр. Таким образом, антивирус превращается в более сложный и многофункциональный программный продукт, способный отслеживать сетевые соединения и блокировать атаки на переполнение буфера, которые чаще всего и используются для удаленного внедрения и выполнения кода.
В целом же защиту от атак на сетевые службы следует обеспечивать не антивирусными средствами, а установкой обновлений, устраняющих уязвимости. В крупных компаниях такой подход должен быть закреплен организационными мерами в рамках комплексного подхода к построению системы антивирусной защиты.
В отличие от рабочих станций Windows, вредоносных программ, угрожающих заражением непосредственно рабочим станциям под управлением Unix или MacOS крайне мало. В большинстве своем это либо так называемые proof-of-concept (доказательство возможности) вирусы, либо вирусы, использующие весьма специфические уязвимости. Первые не встречаются в "диком виде" и на практике опасности не представляют. Что касается вторых, то они способны поражать только системы с очень специфическим набором свойств (например, с установленным прикладным ПО определенной версии) и, как правило, не угрожают актуальным версиям ОС и соответствующих программ.
В связи с этим антивирусы для таких рабочих станций предназначены не столько для предотвращения заражения, сколько для недопущения распространения вредоносных программ. Зараженный файл, скопированный с Windows-машины на Unix-машину, не может нанести вреда Unix-машине, но остается зараженным и, будучи скопированным назад на Windows-машину (ту же или любую другую), представляет собой опасность.
Следовательно, антивирус для рабочих станций под управлением ОС, отличных от Microsoft Windows, не нуждается в большинстве модулей и технологий, применяемых для защиты рабочих станций Windows. Как правило, оказывается достаточно средства проверки по запросу, для регулярной проверки файловой системы или же для нерегулярной проверки отдельных файлов или папок.
Если же на Unix-машине имеется ресурс, активно используемый для хранения и передачи файлов пользователями рабочих станций Windows, это означает, что такая Unix-система относится к классу серверных и требует соответствующих назначению средств защиты.
Кроме того, что антивирус должен эффективно защищать компьютер от вирусных угроз, он также должен обеспечивать:
Задача обновления — обеспечить связь между разработчиками и антивирусным продуктом. Специфика антивирусной защиты
такова, что по мере обнаружения и изучения новых видов и типов угроз, антивирус постоянно нуждается в обновлениях,
позволяющих ему эффективно противостоять этим угрозам. В основном это касается обновления
Сегодня ежедневно появляется несколько десятков, а то и сотен новых вредоносных программ. Практически все они
требуют внесения изменений в антивирусные базы, даже те, которые обнаруживаются при помощи эвристического анализа,
поскольку обнаружение
Никогда заранее неизвестно, в какой момент может появиться вредоносная программа, которая потребует внесения изменений в алгоритмическую часть антивируса, т. е. в антивирусное ядро. С другой стороны, когда она появляется, необходимо оперативно предоставить механизмы защиты всем пользователям, чтобы локализовать эпидемию - ждать выпуска новой версии нет времени. В связи с этим, механизм обновления должен подразумевать обновление как сигнатур - антивирусной базы, - так и антивирусного ядра.
Не стоит забывать и о том, что в модулях антивируса могут быть обнаружены ошибки, требующие устранения. В этом случае могут выпускаться специальные заплаты, устраняющие ошибки. Процесс загрузки заплат бывает автоматизированным или нет. Во втором случае пользователь должен самостоятельно загружать исправления с сайта производителя и устанавливать их. На практике это означает, что многие (если не большинство) пользователи заплату не установят, создавая тем самым предпосылки к возникновению эпидемий, т. к. заплата может устранять в том числе и уязвимости в самом антивирусе, открывающие лазейки для нейтрализации антивирусной защиты вредоносной программой. Следовательно, автоматическая загрузка и установка заплат является предпочтительной.
Обновления антивирусных баз и само антивирусное ядро могут быть как зависящими от операционной системы, так и не зависящими. В первом случае антивирусы одного производителя, установленные на разные платформы (Windows, Unix), будут загружать различные обновления. Во втором случае, обновления будут одинаковыми, что позволит сэкономить на объеме загружаемой из Интернет информации - достаточно будет один раз загрузить обновления с сайта производителя и поместить их в общедоступный ресурс внутри сети.
Возможность размещения обновлений на общедоступном ресурсе внутри сети приводит к вопросу о допустимых способах организации этого ресурса. Стандартом де-факто в антивирусной индустрии является поддержка антивирусными средствами обновления из HTTP-, FTP- или локального (сетевого) ресурса.
Реализация управления связана с двумя аспектами - структурой инструментов управления и организацией доступа к этим инструментам. К инструментам управления относятся настройки и задачи.
Настройки — это значения параметров, определяющих характер выполнения тех или иных действий
Задачи — это именованные действия, связанные с используемыми в антивирусе средствами и характеризующиеся индивидуальными настройками выполнения
Пример. В Антивирусе Касперского для Windows Workstations существуют следующие типы задач:
Количество создаваемых задач проверки по требованию не ограниченно. В то же время в Антивирусе Касперского для Linux Workstations задачи как инструмент отсутствуют. Есть только настройки выполнения обновления, проверки по требованию
С точки зрения доступа к инструментам управления выделяются следующие средства:
Можно отметить, что для антивирусов под Windows штатным способом управления является локальный - через графический интерфейс. Развитых средств удаленного доступа в ОС Windows нет, а точнее эти средства применяются преимущественно в серверных системах, а в пользовательских версиях Windows эти средства если и есть, то очень ограничены (речь идет об инструменте Remote Desktop).
В антивирусах для Unix-систем, напротив, используется преимущественно удаленный доступ: либо через веб-интерфейс, либо через telnet- или ssh-клиент.
Пример. В Антивирусе Касперского для Windows Workstations имеется графический интерфейс и интерфейс командной строки. Настройки продукта в целом и отдельных задач хранятся в xml-файлах, которые подписаны и не предназначены для непосредственного редактирования. В реестр Windows вынесены лишь некоторые настройки антивирусного ядра, не касающиеся антивирусных функций
В Антивирусе Касперского для Linux Workstations используются конфигурационные файлы, интерфейс командной строки и веб-интерфейс.
Диагностика состояния и результатов функционирования антивируса проявляется в двух плоскостях:
Уведомления бывают двух видов: локальные и сетевые. Локальные могут выражаться в виде информационных окон, всплывающих сообщений в системной панели, в виде изменения статуса антивируса (в той же системной панели или в окне интерфейса). В какой-то мере локальным уведомлением может считаться запись в журнал.
Сетевые уведомления предназначены для уведомления не пользователя, а администратора антивирусной безопасности, отвечающего за защиту сети в целом. Следовательно, сетевые уведомления могут быть реализованы только в сетевой (корпоративной) версии антивируса, в персональной версии сетевые уведомления не имеют смысла.
Наиболее распространенными способами доставки сетевых уведомлений являются электронная почта и служба оповещений Windows (имя службы - Оповещатель (Messenger)). Существуют и другие способы доставки, но они редко бывают реализованы непосредственно в антивирусе, поэтому о них речь пойдет позже при рассмотрении подсистемы диагностики в системе администрирования.
Стоит отметить, что наличие встроенных в корпоративный антивирус для рабочих станций возможностей уведомления по сети обычно характерно для тех производителей, у которых система администрирования не является бесплатной, а поставляется и лицензируется как отдельный продукт. У производителей, предлагающих систему администрирования бесплатно, сам по себе антивирус, как правило, сетевые уведомления отправлять не может.
Пример. Антивирус Касперского Personal и Personal Pro имеют только локальные возможности уведомления. Причем для различных событий используются различные инструменты: при обнаружении вируса на экране может отображаться диалоговое окно с выбором варианта действия, при смене состояния антивируса (устаревание баз, запуск задач и т.п.) отображаются всплывающие подсказки в системной панели и меняется статус антивируса в главном окне интерфейса.
Антивирус Касперского для Windows Workstations обладает теми же возможностями, что и персональные версии. Поскольку Kaspersky Administration Kit является бесплатным и обладает всеми необходимыми средствами для организации сетевых уведомлений, альтернативная реализация этой возможности в антивирусе для рабочих станций отсутствует.
Хотя журналы работы и можно рассматривать как один из вариантов уведомления, все же их функции несколько шире. Если уведомления - действия разовые, не оставляющие после себя никаких следов, то журналы остаются и могут быть проанализированы для выяснения причин заражения, сбоев, неполадок и других инцидентов.
Существуют различные подходы к ведению журналов:
Преимущества есть у обоих подходов, в первом случае упрощается анализ отдельного журнала, но возникает проблема поиска нужного, во втором - сразу понятно, где искать, но сам поиск по журналу может составить проблему.
Кроме этого возможны различия в форматах хранения журналов и, как следствие, способах работы с ними. Если журналы сохраняются в обычном текстовом формате с понятными описаниями событий, их можно анализировать в любом текстовом редакторе. Но нередко журналы хранятся в служебных нечитаемых форматах и для работы с ними нужно использовать встроенные в антивирус средства.
Пример. В Антивирусе Касперского для Windows Workstations отдельный журнал создается для каждой задачи. Формат журналов - служебный и нормальная работа с ними возможна только через интерфейс антивируса.
В Антивирусе Касперского для Linux Workstations журналы создаются для различных действий (фактически, для различных
модулей) - журнал проверки,
Иногда в дополнение к событиям, в журналы записывается информация о настройках (задачи или антивируса) при которых это событие имело место. Что касается самих событий, то в них обязательно указывается дата и время, тип события, описание и перечисление важных для данного события параметров. Например, при обнаружении вируса должны указываться тип вируса и имя зараженного файла, а также предпринятое действие.
Под надежностью понимается несколько аспектов работы антивируса. Во-первых, это способность противодействовать вредоносным программам, пытающимся отключить антивирусную защиту. Во-вторых, это инструменты для защиты от необдуманных или небезопасных действий пользователя. Наконец, в-третьих, это недопущение потери данных по вине антивирусного средства.
Последние годы вредоносные программы не только маскируются и стараются остаться незамеченными, но и активно противостоят антивирусным средствам путем выгрузки из памяти соответствующих модулей, удаления файлов с дисков компьютера, блокирования доступа к серверам обновления.
Среди технологий, призванных противостоять таким действиям вирусов, можно выделить несколько основных:
Не только вредоносные программы, но и сами пользователи могут быть причиной частичного или полного отключения антивирусных средств. Имеет место распространенный предрассудок, что антивирусные средства являются основной причиной снижения производительности или появления сбоев в работе компьютера. Исходя из такого мнения, многие пользователи стремятся отключить антивирусную защиту либо отдельные ее функции каждый раз, когда они (пользователи) испытывают неудобства в работе.
С точки зрения администратора антивирусной безопасности подобные действия являются крайне нежелательными, поскольку компрометируют защиту сети в целом (речь не идет о действиях пользователей персональных антивирусов). Чтобы воспрепятствовать вмешательству пользователей в работу антивирусных средств, конечно, должны использоваться административные меры, но помимо них могут применяться и встроенные в антивирусные средства технологии ограничения действий пользователей.
К таковым могут относиться:
Дополнительные средства защиты связаны с применением системы управления и использованием политик, о чем и будет рассказано в соответствующей лекции.
Выполняя действия по предотвращению заражения и нейтрализации обнаруженных инфицированных объектов, антивирус неизбежно модифицирует файлы пользователя (при лечении или удалении зараженных файлов), что в редких случаях может привести к потере нужной информации. Чтобы этого не происходило, в ряде антивирусов применяется технология резервного копирования.
Второй важный аспект - обработка подозрительных объектов. Понятно, что лечение таких объектов невозможно в принципе, а удаление - опасно потерей данных, по причине ложного срабатывания. Разумным решением является изоляция таких объектов до выяснения обстоятельств.
Наконец, стоит учитывать такой момент как конфликты АПО с прочими программами, установленными на компьютере. Если сами модули антивируса обычно перед выпуском новой версии тщательно тестируются и в подавляющем большинстве случаев не допускают подобных конфликтов, то обновления антивирусных баз и ядра выпускаются слишком часто, чтобы их можно было должным образом протестировать. По этой причине изредка возникают проблемы совместимости, которые, впрочем, оперативно устраняются выпуском исправленных обновлений или же просто следующей версией, если обновления выходят часто.
Тем не менее, ожидая исправленной или новой версии обновлений, пользователю необходимо как-то работать, а значит должен быть механизм, позволяющий при необходимости использовать не текущую версию антивирусных баз, а последнюю корректную.
Основная идея повышения производительности состоит в исключении необязательных и/или многократных проверок. Например, при проверке по требованию происходит обращение к объектам файловой системы, что при прочих равных должно условиях вызывать также и проверку при доступе. Однако, вполне понятно, что такая двойная проверка является излишней и поэтому практически во всех антивирусных продуктах объекты, сканируемые модулем проверки по требованию, никаким другими модулями не сканируются.
Если нет смысла проверять один и тот же объект два раза подряд (что очевидно), то возникает вопрос: каков допустимый интервал между двумя последовательными проверками одного и того же объекта? Ответ лежит на поверхности: до тех пор, пока состояние системы с точки зрения проверки этого объекта не изменилось. Важными параметрами в данном случае будут:
Отследить изменения в антивирусе - задача тривиальная. Соответственно стоит вопрос об отслеживании изменений в объектах и хранении данных об условиях предыдущей проверки. Здесь как раз и используется технология расчета и анализа контрольных сумм, которая обеспечивает две характеристики:
Пример. В Антивирусе Касперского для Windows Workstations (и в других версиях Антивируса Касперского под Windows) применяются уникальные технологии iStreams и iChecker. Обе они основываются на вычислении контрольных сумм проверенных объектов и отличаются только в том, где хранятся контрольные суммы.
При использовании технологии iChecker данные об объектах сохраняются в отдельной базе, что позволяет применять данную технологию не только к объектам файловой системы, но и к вложениям почтовых сообщений (вложения, имеющие одинаковую контрольную сумму, имя, размер, дату создания и пр. считаются идентичными).
Если же используется технология iStreams, контрольные суммы сохраняются в дополнительных потоках файловой системы NTFS, что накладывает естественные ограничения на область применения данной технологии.
Кроме автоматической сортировки объектов на те, которые нужно проверять и те, которые проверять смысла нет, для повышения производительности с успехом применяются также методы ручной сортировки.
Первый этап подобной сортировки выполняют эксперты компании-производителя, определяя типы файлов, которые могут быть заражены и которые по этой причине необходимо проверять. Остальные типы файлов считаются потенциально неопасными и проверять их рекомендуется только в особых случаях - при опасениях, что машина может быть заражена неизвестным вирусом, или во время протекания масштабной эпидемии.
Пример. В Антивирусе Касперского пользователю на выбор предлагается три подхода к определению проверяемых объектов:
Последние две опции призваны обеспечить один и тот же описанный выше эффект - проверять только потенциально заражаемые объекты - но отличаются реализацией. В первом случае (по формату) тип объекта определяется исходя из его внутренней структуры. Например, EXE-файл, переименованный в файл с расширением TXT, будет корректно опознан как исполняемый и проверен.
Второй способ ту же задачу решает на основании только расширения, т. е. переименованный EXE-файл проверен не будет. Этот способ быстрее, но не так надежен. Оптимальным компромиссом между надежностью и производительностью, рекомендованным экспертами Лаборатории Касперского, является выбор проверки заражаемых объектов по формату.
Следующим этапом сортировки объектов является реализация в антивирусе инструментов для гибкой настройки перечня проверяемых объектов. Проверяемые (или исключаемые) объекты могут определять по различным признакам. Наиболее часто реализуется исключение объектов по их идентификации в файловой системе компьютера - по принадлежности к определенному диску или каталогу, по маске имени и/или расширения.
Кроме априорных подходов, когда объекты исключаются еще до начала их проверки, существуют и апостериорные - когда проверка объекта начинает выполняться и в зависимости от характеристик ее протекания принимается решение продолжать проверку (до окончания) или прекратить.
Наконец, нередко применяются способы регулировки производительности вообще не зависящие от характеристик проверяемых объектов. Так, во многих антивирусах имеется возможность задать приоритет проверки (в смысле приоритета процесса, выполняющего сканирования). Встречаются и другие подходы.
Регулировка использования системных ресурсов применяется обычно только для проверки по требованию.
На основании приведенных выше рассуждений и примеров можно сформулировать основные требования к антивирусам для рабочих станций. Понятно, что эти требования будут отличаться для рабочих станций различных классов.
Как и раньше требования будут делиться на несколько категорий:
Категории требований будут теми же, но сами требования будут менее жесткими по описанным ранее причинам:
В целом антивирусная защита серверов не так сильно отличается от защиты рабочих станций, как, например, от защиты шлюзов. Основные угрозы и технологии противодействия им остаются теми же - смещаются только акценты.
Сетевые сервера как и рабочие станции естественным образом делятся на классы, согласно используемым операционным системам:
Принцип деления обусловлен характерными для различных операционных систем вирусными угрозами и, как следствие, различными вариантами в определении основной задачи антивируса.
В случае продуктов для защиты серверов деление на персональные и сетевые продукты отсутствует - все продукты являются сетевыми (корпоративными). У многих производителей вообще нет деления корпоративных продуктов на предназначенные для рабочих станций и файловых серверов - имеется единый продукт.
Все относящиеся к серверам специфические угрозы связаны не столько с особенностями серверных операционных систем, сколько с применением уязвимого ПО, характерного для серверов.
Для серверов Windows актуальны все те же угрозы, что и для рабочих станций под Windows NT/2000/XP. Отличия заключаются только в преимущественном способе эксплуатации серверов, что выражается в ряде дополнительных атак, нехарактерных для рабочих станций.
Так, за серверами Windows редко непосредственно работают пользователи, а значит, почтовые клиенты и офисные приложения
на серверах, как правило, не используются. Как следствие, требования к защите почты на уровне почтового клиента и
дополнительные средства обнаружения
С другой стороны на серверах Windows значительно чаще, чем на рабочих станциях могут использоваться такие службы как Microsoft SQL Server и Microsoft IIS. Как и сами операционные системы производства Microsoft (и не только Microsoft), эти службы могут содержать уязвимости, чем в свое время неоднократно пользовались авторы вирусов.
Пример. В 2003 году появился и буквально пронесся по Интернету червь Net-
Пример. Еще раньше, в 2001 году, уязвимость в Microsoft IIS 5.0 была использована для распространения червем
Net-
Особенность обоих червей в том, что модуль проверки файловой системы (хоть по запросу, хоть при доступе) против
них бессилен. Эти черви не сохраняют свои копии на диск и вообще никак не проявляют своего присутствия в системе,
кроме повышенной сетевой активности. На сегодняшний день основной рекомендацией по защите является своевременная
установка патчей на операционную систему и используемое ПО. Другой подход заключается в настройке брандмауэров
таким образом, чтобы порты, используемые уязвимыми службами были недоступны извне - разумное требование в случае
защиты от Slammer, но неприемлемое для защиты от
Актуальными для серверов Windows остаются и черви, атакующие уже непосредственно уязвимые службы операционной системы, такие как Lovesan, Sasser, Mytob и др. Защита от них должна обеспечиваться комплексными мерами - использованием брандмауэров, установкой заплат, применением проверки при доступе (упомянутые черви при успешной атаке сохраняют свои файлы на жестком диске).
Учитывая характер атак, можно сделать вывод, что основными средствами защиты серверов Windows являются: модуль проверки файлов при доступе, модуль проверки файлов по требованию, модуль проверки скриптов, а основными технологиями - сигнатурный и эвристический анализ (а также поведенческий - в модуле проверки скриптов).
Специфических вирусов, способных заражать Novell Netware, нет. Существует, правда, несколько
Соответственно, антивирус для сервера Novell Netware фактически не предназначен для защиты этого сервера. В чем же тогда его функции? В предотвращении распространения вирусов. Сервера Novell Netware в большинстве своем используются именно как файловые сервера, пользователи Windows-компьютеров могут хранить на таких серверах свои файлы или же запускать программы, расположенные на томах Novell Netware. Чтобы предотвратить проникновение вирусов на общие ресурсы сервера Novell, либо запуск/чтение вирусов с таких ресурсов и нужен антивирус.
Соответственно, основные средства, применяемые в антивирусе для Novell Netware - проверка при доступе и проверка по требованию.
Из специфических технологий, применяемых в антивирусах для Novell Netware необходимо отметить блокирование станций и/или пользователей, записывающих на сервер вредоносные программы.
Про сервера Unix можно сказать все то же, что и про сервера Novell Netware. Антивирус для Unix-серверов решает не столько задачу защиты самих серверов от заражения, сколько задачу недопущения распространения вирусов через сервер. Для этого применяются все те же два основных средства:
Многие известные черви под Linux используют для распространения уязвимости не в самой операционной системе, а в
системном и прикладном ПО - в ftp-сервере wu-
В отличие от серверов Novell, где поддержка сетей Microsoft является встроенной функцией, сервера Unix по умолчанию
не приспособлены для передачи файлов по протоколу SMB/
Если обмен файлами происходит только по протоколам SMB/
Стабильная работа серверов, как правило, гораздо критичнее для сети в целом, чем функционирование отдельных рабочих станций. На серверах обрабатывается больше информации, они же зачастую являются местами постоянного хранения этой информации, в случае с серверами приложений, услугами сервера пользуется одновременно большое количество человек - все это накладывает повышенные требования к надежности и производительности антивирусного программного обеспечения, устанавливаемого на сервера. Помимо этих характеристик, важными остаются реализация управления, обновления и диагностики.
Инструменты и принципы управления, применяемые в антивирусах для серверов, в целом не отличаются от применяющихся в антивирусах для рабочих станций. Это и понятно: различия в назначении и в условиях применения не так велики. Тем не менее, определенная разница есть.
Как правило, сервера Windows предполагают автономную работу с минимальным вмешательством администраторов. Все необходимые службы и приложения настраиваются один раз и в дальнейшем работают согласно настройкам. В этой ситуации особой необходимости в наличии специализированного графического интерфейса для антивируса нет, достаточно наличия каких бы то ни было средств настройки - применяться они в любом случае будут нечасто.
Что касается управления продуктами для Unix-серверов, здесь тоже нет ничего нового: применяется веб-интерфейс либо управление посредством редактирования конфигурационных файлов и запуска задач из командной строки в telnet- или ssh-сессии.
Продукты под Novell Netware, в том числе и не только антивирусные, как правило, управляются через стандартный инструмент ConsoleOne.
Здесь вообще никакой разницы в сравнении с антивирусами для рабочих станций нет.
В антивирусах для файловых серверов, в целом, используются те же средства диагностики, что и в рабочих станциях - уведомления, отчеты. Однако иногда, для тщательной диагностики проблем производительности или других проблем, необходимо в режиме времени реального сравнивать некоторые показатели работы компьютера, в том числе и показатели работы антивируса. Такого рода диагностика куда чаще бывает нужна на серверах, чем на рабочих станциях, и поэтому соответствующие средства диагностики, если и встречаются, то в антивирусах для защиты серверов.
На практике реализация такого рода диагностики выглядит как добавление в стандартный инструмент Windows - Performance Monitor- дополнительных счетчиков, как и в случае средств для защиты шлюзов или почтовых серверов. Как правило, счетчики включают:
и т. п. статистические данные
В отношении надежности АПО для защиты серверов должно обладать теми же характеристиками, что и АПО для защиты рабочих станций:
При этом задействуются все те же технологии.
Тем не менее, повышенные требования к защите серверов должны учитываться при разработке антивирусного ПО для них, и они учитываются в виде улучшенной совместимости с другим распространенным серверным ПО. Следствием такого подхода также косвенно является урезание функционала серверного антивируса в сравнении с антивирусом для рабочих станций - чем меньше модулей содержит антивирус, тем меньше вероятность конфликтов или сбоев.
Что касается производительности, то и в этом случае антивирусное ПО для серверов использует практически те же технологии, что и АПО для рабочих станций. Но не только.
В отличие от рабочих станций, сервера нередко могут работать на многопроцессорных платформах. С одной стороны этот факт не должен вызывать проблем в работе АПО, т. е. оказывать влияние на тестирование надежности. С другой стороны, антивирус вполне может использовать многопроцессорную архитектуру для повышения скорости проверки объектов.
Пример. В Антивирусе Касперского для Windows
Соответственно, количество сканирующих ядер, загружаемых в память компьютера. равно количеству процессоров. При этом
процессоры Intel, использующие технологию
Приведенные рассуждения и примеры позволяют сформулировать требования к антивирусам для серверов. Здесь различия в назначении не так разительны, как в случае рабочих станций и поэтому можно не делить требования в соответствии с классами серверов, а отмечать различия в соответствующих пунктах:
Как уже говорилось, в больших сетях система управления является тем необходимым инструментом, который позволяет контролировать состояние системы защиты серверов и рабочих станций в целом. В штатном режиме такой подход позволяет существенно снизить затраты на обслуживание, в условиях эпидемии - позволяет оперативно корректировать настройки и удаленно командовать работой антивирусов на узлах.
Каждым антивирусным средством можно управлять непосредственно: либо локально, либо, как в случае с продуктами под Novell Netware, Linux, Unix - удаленно при частичной помощи штатных средств этих операционных систем. Любые задачи по настройке и выполнению определенных операций могут быть решены таким образом.
Однако в случае, когда похожие настройки необходимо сделать не на двух, трех, пяти или даже десяти узлах, применять независимые средства управления для каждого из узлов становится крайне неэффективно. Если же еще учесть, что большую часть узлов сети составляют компьютеры под управлением ОС Windows, и что ОС этого семейства не обладают развитыми средствами удаленного управления, позволяющими изменять настройки программ, не мешая работе пользователей, то к необходимости независимой настройки прибавляется необходимость непосредственного присутствия администратора антивирусной безопасности для выполнения этих действий. В конечном итоге, управление сколько-нибудь большим числом защищенных узлов становится задачей крайне трудоемкой и малоэффективной.
Кроме того, если в сети случается инцидент, связанный с антивирусной безопасностью, штатные средства управления антивирусным средством либо оповещают об этом локального пользователя либо просто записывают информацию в отчет. В такой ситуации между моментом, когда произошел инцидент, и моментом, когда об этом стало известно администратору, может пройти значительное время - несколько часов или даже дней. В ситуации повышенной вероятности возникновения эпидемии такие задержки недопустимы.
При возникновении внештатной ситуации как никогда важной становится возможность оперативно получать информацию о состоянии защиты на всех защищаемых узлах и своевременно вносить коррективы в настройки, а также при необходимости обновлять антивирусные базы и проводить внеплановую проверку компьютеров. Если для выполнения этих действий администратору потребуется произвести полный обход территории сети, он полностью потеряет контроль за происходящим.
Таким образом, вырисовывается необходимость в дополнительном инструменте, который позволил бы решать следующие задачи:
Фактически, необходим инструмент, который позволял бы удаленно и централизовано решать задачи управления, обновления и диагностики системы антивирусной защиты. Такой инструмент принято называть системой управления или системой администрирования. Помимо упомянутых задач система администрирования обычно включает также функции, связанные с разворачиванием системы антивирусной защиты в сети - функции удаленной установки и деинсталляции антивирусных средств.
Легко видеть, что задачи, решаемые системой администрирования, достаточно разнородны и не обязательно связаны между собой. По этой причине и система администрирования может быть легко представлена в виде совокупности нескольких подсистем, соответствующих задачам:
На практике эти подсистемы могут и не составлять единый продукт. Практически любая из подсистем может представлять собой отдельное решение.
Пример. В версии 4.5 Kaspersky Administration Kit удаленная установка была отделена от всех остальных функций системы управления и представляла собой отдельный инструмент, выполненный в виде независимого программного модуля, который, впрочем, считался частью Kaspersky Administration Kit.
В ряде антивирусов (например, Sophos) система обновления может строиться практически независимо от системы администрирования.
Также нередко (CA, eTrust, McAfee) для расширения функций системы диагностики (в первую очередь, системы уведомлений) используется отдельное решение.
Все же наиболее удачным выглядит решение, объединяющее в себе все необходимые подсистемы. Таким решением является
Kaspersky Administration Kit. Аналогичной универсальностью характеризуются продукты для управления от Symantec,
McAfee и
В данном случае требования можно сформулировать еще до обзора условий эксплуатации и применяемых технологий, поскольку в принципе требования к системе администрирования являются обобщением требований к управлению, обновлению и диагностике отдельных антивирусных комплексов:
Для того, чтобы эффективно осуществлять удаленное управление даже отдельными узлами, оснащенными антивирусным ПО, необходимо где-то хранить параметры доступа к этим узлам - адреса, идентификаторы и т.п. Т.е. вопрос о централизованном характере системы управления возникает буквально сразу же. Как показывает практика, именно централизованный вариант является наиболее удобным и эффективным, поскольку все системы управления построены по одному и тому описанному ниже принципу.
Система управления строится на базе трех компонентов:
Функции компонентов распределены следующим образом:
Защищенный узел сети с установленным агентом принято называть клиентом или клиентским компьютером того сервера управления, к которому подключен агент.
Пример. В Kaspersky Administration Kit структура решения полностью совпадает с описанной, имеются:
В других системах управления, встречаются варианты, когда сервер и консоль управления объединены в общий модуль, или же когда агент является составной частью антивируса, неотделимой от него
Совокупность всех агентов, подключенных к серверу управления принято называть
Как только возникает вопрос об изменении настроек или о запуске задач одновременно на группе компьютеров, возникает и вопрос о структуре и взаимосвязи этих групп. Сегодня можно встретить два подхода к реализации работы с группами:
Первый подход обладает большей гибкостью, при желании можно назначить задачу произвольному набору компьютеров, в зависимости от того, как складывается ситуация. Однако этот подход не позволяет эффективно отслеживать состояние настроек антивирусной защиты на узлах. Действительно, в какой-то момент времени настройки узла могут быть изменены вместе с одной группой компьютеров, в другой момент - уже с другой группой, в третий момент - индивидуально. В результате априори узнать, какие настройки используются на конкретном узле не представляется возможным, что приводит к ненужной неразберихе и потере контроля над состоянием защиты.
При втором подходе гибкость, очевидно меньше, зато появляется возможность задавать постоянные настройки для групп компьютеров и контролировать сохранение этих настроек в неизменном виде. С таким подходом уже гораздо проще отслеживать уровень защиты.
Таким образом, складывается структура элементов управления:
Для чего вообще имеет смысл объединять компьютеры в группы? По сути, цели две:
Достижение первой цели возможно в любой структуре групп: как первого, так и второго типа. Действительно, нет никакого противоречия в том, что узел входит в две группы и на нем выполняются задачи, сформированные для каждой из групп. Вторая цель достижима только в структуре с постоянными группами, составы которых не пересекаются. Это тоже вполне понятно, если для группы заданы настройки, которые должны быть справедливы для всех узлов этой группы, то для узла входящего в две группы одновременно возникает противоречие: неясно, настройки какой группы на нем будут использоваться.
Как правило, настройки заданные на уровне группы называются политикой. Отличия в этих терминах можно кратко сформулировать следующим образом: настройки - это "как есть", а политика - "как должно быть". В силу императивного характера политик, они предполагают наличие неких механизмов контроля. Практикуется два подхода:
Понятно, что такая категоричность не всегда удобна - легко представить себе ситуацию, при которой некоторые настройки должны быть зафиксированы жестко, а некоторые могут быть изменены локальными пользователями без особого ущерба качеству защиты. Большинство систем управления позволяют выборочно отмечать обязательные и необязательные параметры политики.
Пример. В Kaspersky Administration Kit используется смешанный подход. В первую очередь имеются политики, отдельные настройки которых могут быть отмечены как обязательные или необязательные. Эти настройки охватывают все аспекты работы антивирусных средств. Изменение обязательных параметров на локальных компьютерах полностью заблокировано. Но также выделяются и рекомендуемые настройки защиты, при отклонении от которых формируется уведомление администратору антивирусной безопасности. Такая реализация позволяет использовать преимущества обоих подходов.
Помимо этого, в Kaspersky Administration Kit реализована гибкая система применения политик, основанная на том, что настройки и политики четко разделяются даже на уровне локальных компьютеров и хранятся независимо. Применение политики может происходить одним из трех способов на выбор администратора:
Нередко в составе группы естественным образом выделяется подгруппа клиентов, для которых требуется незначительно изменить
политику или создать отдельную групповую задачу. В этом случае было бы удобно выделить подгруппу в отдельную группу,
являющуюся элементом исходной группы, чтобы в ней продолжали действовать групповые задачи и политики исходной группы.
Многие системы управления поддерживают такую возможность. В этом случае
Структура групп, настройки групповых задач и политик, а также нередко и данные диагностики - вся эта информация
должна так или иначе храниться на сервере и быть доступной для анализа и обработки. Как правило, для этих целей
используется внешний сервер баз данных, по сути - четвертый компонент системы управления. Чаще всего в системах
управления применятся бесплатная модификация Microsoft SQL Server 2000 - Microsoft SQL Server Desktop Engine 2000
или коротко
Пример. В Kaspersky Administration Kit также используется внешний сервер баз данных и именно
Поддерживается в Kaspersky Administration Kit и работа с полноценным Microsoft SQL Server 2000
Кроме вопроса удобства, который выражается в механизмах групп, групповых задач и политик, существует также вопрос производительности системы управления. Например, если в организации имеется несколько филиалов, каналы связи между которыми весьма ограничены, одновременное применение политики может вызвать перегрузку канала связи с филиалом.
Чтобы избежать этой ситуации используются следующие методы:
Механизм иерархии серверов управления заключается в том, что одни сервера управления могут подключаться к другим.
Соответственно подключаемый сервер будет подчиненным, а тот, к которому производится подключение - главным. При этом
степень взаимодействия между главными и
Один из вариантов взаимодействия -
Второй вариант - группы управления привязываются к серверам управления, все управление происходит прозрачно, т.е.
Применяются и другие, достаточно сложные для описания схемы реализации.
Пример. Иерархия Серверов администрирования реализована и в Kaspersky Administration Kit.
Принцип применения тот же, что и в иерархии групп - унаследованные задачи применяются ко всем клиентам подчиненного Сервера, унаследованные политики действуют также на всех клиентах, если только не переопределены на уровне групп или подгрупп подчиненного Сервера. Обязательные параметры по-прежнему переопределять нельзя и они остаются обязательными в создаваемых политиках.
Доступ к подчиненным Серверам возможен как напрямую, так и через интерфейс главного Сервера администрирования.
Еще одним фактором иерархии серверов является ее глубина. Чаще всего можно встретить двухуровневую иерархию, где есть ровно один главный сервер управления, к которому подключены все остальные сервера управления. Однако есть реализации допускающие произвольную глубину иерархии.
Немаловажным аспектом системы управления является организация доступа к ее функциям. Реализация разграничения доступа может быть самой разной. Можно выделить следующие характерные схемы:
Пример. В Kaspersky Administration Kit используется третья схема реализации. Выделяется две группы пользователей -
администраторы и операторы
Для идентификации, аутентификации и разграничения доступа используются средства Windows. Права администраторов
Необходимость подсистемы обновления, общей для всей системы защиты (во всяком случае, для третьего уровня - защиты серверов и рабочих станций), на первый взгляд не так очевидна. Действительно, при наличии на всех узлах функций обновления и при наличии централизованной системы управления не составляет труда регулярно запускать задачи обновления на клиентах и контролировать состояние антивирусных баз.
Однако, следует учитывать, что при выполнении задачи обновления передается большее количество данных, чем при распространении настроек или при выполнении других задач управления. Следовательно, основная проблема обновления в больших сетях - проблема загрузки сети. У многих производителей антивирусного ПО регулярные обновления антивирусных баз могут составлять несколько сотен килобайт или даже несколько мегабайт. Если представить, что все клиенты одновременно обратятся к внешнему источнику обновления - серверу обновлений производителя - канал доступа в Интернет будет перегружен. Более того, при таком размере обновлений могут быть перегружены даже каналы локальной сети.
Пример. Пусть размер регулярных обновлений составляет в среднем 1 Мб, и пусть в сети имеется 1000 клиентов, которые требуется обновить. Следовательно, в процессе обновления через канал доступа к Интернет должно быть передано 1000 Мб информации. Если предположить, что канал доступа имеет пропускную способность 2 Мбит/с можно вычислить, что на обновление всей сети потребуется
$$\frac{(1000\cdot 8) \text{Мбит}}{2 \text{Мбит/с}} = 4000 c$$т. е. больше одного часа.
На практике это будет означать одно из двух: либо значительная часть станций просто не получит доступа к источнику обновлений из-за перегрузки сети и не будет обновлена, либо доступ к сети Интернет другим программам и службам во время выполнения обновления будет затруднен.
Такая же проблема с загрузкой сети будет возникать и в ситуации, когда организация имеет несколько филиалов, пропускная способность линий связи между которыми ограничена.
Путей решения у этой проблемы фактически два:
Таким образом, система обновления - это набор средств и способов организации и контроля промежуточных источников обновления.
В общем случае система обновления может иметь такие типы структур:
Использование той или иной схемы диктуется размером и структурой сети организации. Так в небольших офисах вполне допустимо использование децентрализованной схемы. В сетях среднего размера, до нескольких сотен компьютеров, сосредоточенных в одной локальной сети удобно использовать централизованную схему. В крупных территориально распределенных сетях применяются иерархические или смешанные схемы, в зависимости от наличия каналов доступа к сети Интернет.
В рассмотренных схемах обновления не конкретизирована структура источников. На практике встречаются следующие их типы:
Разница между этими типами источников заключается в том, насколько легко они могут быть автоматизированы и насколько они поддаются контролю через систему управления.
Так, для обновления внутреннего FTP- или HTTP-сервера, администраторам потребуется использовать дополнительные средства для автоматической загрузки обновлений и размещения их на серверах. То же касается и общей папки сети Microsoft.
В случае с источником на базе клиента вопрос с автоматической загрузкой отпадает, однако дальнейший контроль источника обновлений в этом случае обычно отсутствует.
Наконец, наиболее функциональными источниками обновлений являются специализированные приложения, входящие, как правило, в состав системы администрирования и позволяющие контролировать размещенные на них файлы. Такие источники принято называть серверами обновления.
В силу того, что и сервера обновлений и сервера управления часто подразумевают наличие иерархической структуры (с одной и той же целью - снижение нагрузки на сеть) эти приложения бывают объединены. Иными словами, сервер управления нередко выполняет также функции и сервера обновлений.
В вопросе обновления клиентов очень важна своевременность. Антивирусные базы должны доставляться в кратчайшие сроки после их выпуска. С другой стороны, как уже было показано выше, одновременное обновление большого количества клиентов может приводить если и не к перегрузке сети (если используется эффективная система источников обновления), то по крайней мере к снижению ее эффективности. Чтобы этого не происходило, обновление в различных группах часто разносят по времени при помощи планирования запуска задач. Дополнительно используется метод случайной задержки, когда запланированные на одно время задачи стартуют не синхронно, а выдерживают паузу случайной длины в рамках заданного интервала. Например, создается расписание запуска обновления в 13:00 со случайно задержкой в пределах 20 минут.
В то же время, при начале вирусной атаки или высокой вероятности возникновения эпидемии можно пренебречь временным снижением эффективности сети ради экстренного обновления. Таким образом, возникает необходимость в двух режимах обновления:
В системах, где сервера обновления отделены от серверов управления, проталкивание обычно реализуется путем посылки через систему управления на клиенты специального сигнала о необходимости обновиться.
Задача подсистемы диагностики - предоставить администратору антивирусной безопасности максимум информации о функционировании системы защиты для обеспечения принятия решений.
Как и в случае одиночного антивируса средства диагностики можно разделить на несколько классов:
Уведомления служат для информирования администратора антивирусной безопасности о событиях, которые возможно требуют безотлагательного вмешательства: например, об обнаружении вируса.
Организация системы уведомлений характеризуется в первую очередь тем, какие каналы доставки уведомлений поддерживаются. Наиболее характерными являются:
Второй аспект реализации системы уведомлений - связь с системой управления. Как правило, система управления одновременно выполняет и функции системы уведомлений, но в тех случаях, когда система управления является платной, производитель нередко предоставляет упрощенные средства для организации доставки уведомлений. В этом случае в сети создается отдельный сервер уведомлений, который принимает сигналы о событиях от клиентов и преобразует их в уведомления различных видов.
Журналы работы, которые ведутся на клиентских компьютерах, в случае большой сети для анализа практически непригодны. Поэтому возникает вопрос о централизованном сборе и хранении информации обо всех или только о наиболее важных событиях, т. е. о централизованных журналах.
С централизованными журналами тесно связаны средства генерации отчетов о работе сети. Эти отчеты позволяют оценить ситуацию по сети в целом, выявить наиболее проблемные участки, компьютеры, определить неявные проблемы и т.д.
Пример. В Kaspersky Administration Kit реализованы следующие типы сводных отчетов:
При создании отчета может запрашиваться информация от
Как правило, отчеты генерируются администратором антивирусной безопасности вручную по необходимости. Однако некоторые отчеты вполне целесообразно генерировать на регулярной основе автоматически: например, отчет о вирусной активности.
Так же как и локальное управление всеми клиентами вызывает чрезмерные затраты времени и усилий, так и локальная установка антивирусной защиты обычно требует слишком большого количества ресурсов обслуживающего персонала. По этой причине система управления, как правило, оснащается средствами для проведения удаленной установки.
На практике встречаются следующие способы удаленной установки, отличающиеся ограничениями на условия применения и степенью вовлеченности пользователя в процесс установки:
Из всех описанных методов только форсированная установка через RPC является интерактивной и позволяет непосредственно
после запуска выяснить, успешно она прошла или нет. Все остальные методы требуют ожидания действий пользователя -
запуска программы установки, входа в систему. Даже форсированный режим установки через
Учитывая ограничения каждого из методов, для организации внедрения обычно применяется следующая схема. Сперва выполнятся форсированная установка при помощи RPC, а затем - установка другими методами на оставшиеся компьютеры. После этого анализируется информация о результатах установки и на все оставшиеся незащищенными компьютеры антивирусное ПО и агенты устанавливаются вручную.
Пример. В Kaspersky Administration Kit применяются два способа установки:
При этом, если на компьютере уже установлен Агент администрирования, на него можно установить Антивирус Касперского форсированно, независимо от операционной системы клиента и от информации о реквизитах пользователя с правами администратора на удаленном компьютере - загрузка программы установки и ее запуск производятся непосредственно Агентом администрирования, для которого требуется только связь с Сервером администрирования.
Как видно из приведенного материала, третий уровень КСАЗ является наиболее сложным с точки зрения организации и функционирования. На нем применяется наибольшее количество разнообразных технологий, как непосредственно ориентированных на борьбу с вирусными угрозами, так и призванных обеспечить управление, обновление и диагностику антивирусных средств.
Основными отличительными особенностями этого уровня являются:
Наконец, третий уровень так или иначе присутствует в любой системе антивирусной защиты, даже когда речь идет о сети без шлюзов и почтовой системы.
Третий уровень КСАЗ — это уровень защиты серверов и рабочих станций. Иногда для ясности говорят "файловых серверов и рабочих станций", чтобы не включать в категорию защищаемых объектов, например, почтовые сервера. Такая подмена не вполне оправдана.
Важно понимать, что два предыдущих уровня КСАЗ — уровень защиты шлюзов и уровень защиты почтовых систем - выполняют задачу перехвата вирусов на стадии распространения (проникновения) и никак не участвуют в защите от вредоносных программ на этапе их - программ - активации. Напротив, задача третьего уровня защиты, в первую очередь, - воспрепятствовать активации вируса и выполнения им заложенных функций.
В связи с этим отличаются и принципы, по которым определяется состав защищаемых на третьем уровне узлов. Если на уровнях защиты шлюзов и почтовых систем защищаемые узлы определялись по признаку назначения и выполняемых функций (обработка соответствующего потока информации), то на третьем уровне одним из основных признаков для включения узла в класс защищаемых является существование вредоносных программ, которые могут быть запущены (активированы) на узле.
Соответственно, третий уровень КСАЗ охватывает далеко не только сервера, выполняющие функции файловых хранилищ. К подлежащим защите на этом уровне вполне могут относиться номинальные почтовые сервера или сервера баз данных, если они используют операционную систему семейства Microsoft Windows.
Учитывая, что большинство современных вирусов попадают на компьютеры по сети, для обозначения третьего уровня КСАЗ используют также формулировку: уровень защиты сетевых серверов и рабочих станций. Несмотря на то, что такое определение уже гораздо точнее, оно тоже не является безупречным. Гипотетически можно предположить компьютер, использующий операционную систему серверного класса, предназначенный для обработки классифицированной информации и по этой причине отключенный от сети. Такой компьютер тоже необходимо защищать в рамках третьего уровня КСАЗ, поскольку поступающие через сменные носители непроверенные данные представляют собой угрозу с точки зрения вирусного заражения, а с учетом особой важности обрабатываемой информации, суммарный риск будет слишком большим, чтобы его игнорировать.
Впрочем, описанная гипотетическая ситуация достаточно редко встречается в реальных автоматизированных системах, и для практических целей можно было удовлетвориться формулировкой: третий уровень КСАЗ - это уровень защиты сетевых серверов и рабочих станций. Сетевых в данном случае означает - подключенных к сети.
Уже глядя на название, можно сделать вывод о некоторой неоднородности третьего уровня КСАЗ с точки зрения используемых средств защиты. Если общность угроз позволяет объединить сетевые сервера и рабочие станции в один уровень, то существенно разные профили использования выражаются в различных требованиях к эксплуатационным характеристикам АПО. Как следствие, достаточно часто для защиты сетевых серверов и рабочих станций используются разные продукты.
Принимая во внимание вышесказанное, естественным выглядит выделение на третьем уровне КСАЗ двух подсистем:
Однако этими подсистемами уровень не исчерпывается. Сказывается тот факт, что сетевые сервера и рабочие станции - наиболее многочисленный класс узлов в сети: в крупных организациях их количество может составлять несколько сотен, тысяч или даже десятков тысяч узлов. Встречаются и еще более крупные сети. В связи с этим возникает проблема контроля и управления защитой всех этих узлов.
Как показывает практика, ничего лучше для решения указанной проблемы, чем создание отдельной подсистемы управления, пока придумать не удалось. Таким образом третий уровень КСАЗ - уровень защиты сетевых серверов и рабочих станций - в общем случае состоит из трех подсистем:
При этом чаще всего говорят не о подсистеме управления, а о системе управления. Связано это с тем, что на других уровнях КСАЗ подсистем аналогичного назначения нет: либо функции управления входят в состав антивирусных средств (это требование-минимум), либо система управления третьего уровня КСАЗ распространяется также на средства защиты шлюзов и почтовых систем.
Далее в главе будут отдельно рассмотрены средства защиты рабочих станций, средства защиты серверов и средства управления. Для каждой из подсистем сперва проводится обзор основных угроз, условий эксплуатации и применяемых в связи с этим технологий, после чего формулируются требования к программному обеспечению данного класса.
Как можно понять из приведенных ранее примеров, подсистема защиты рабочих станций также далеко не всегда оказывается однородной в смысле используемых средств защиты. Причина тому - неоднородность самих рабочих станций с точки зрения используемых операционных систем.
Сегодня рабочими станциями могут быть компьютеры, работающие под управлением таких операционных систем:
В силу существенных архитектурных различий рабочие станции Windows обычно делят на два дополнительных подкласса:
Прямым следствием такого положения дел является наличие различных - зачастую даже по антивирусному функционалу - средств защиты для каждого из классов рабочих станций.
Как уже говорилось выше, основной причиной введения системы управления на третьем уровне является необходимость управлять большим количеством антивирусных средств. Верно и обратное, когда количество защищаемых узлов невелико, система управления, как правило, не используется.
Поэтому существуют различные версии антивирусных средств защиты рабочих станций - предназначенные для взаимодействия с системой управления и не предназначенные. Первые называют по-разному, но чаще всего - сетевыми или корпоративными версиями, иногда - управляемыми. Для вторых устоялся единый термин - персональные версии.
Продукты для защиты рабочих станций Linux/Unix или MacOS нередко вовсе не имеют сетевых (корпоративных) вариаций. Причина та же - количество таких рабочих станций, как правило, невелико.
В последние годы ситуация начала меняться и сейчас нередко можно встретить институты или правительственные организации, полностью оснащенные рабочими станциями на базе Linux. Тем не менее, во-первых, количество вирусов для этой платформы ничтожно в сравнении с количеством вирусов для Windows, а во-вторых, новые вирусы для Linux появляются также крайне редко. Результатом такого положения вещей является низкая вероятность заражения и отсутствие насущной необходимости в постоянном контроле состояния системы защиты.
Как известно, большинство современных вредоносных программ являются ОС-ориентированными, т. е. могут запускаться только на некоторых типах родственных ОС (как правило, ОС Windows). Более того, способы распространения (проникновения) также во многих случаях являются ОС-ориентированными. По этой причине рассмотренные ранее в совокупности вирусные угрозы в различной степени относятся к разным классам рабочих станций.
Большинство угроз, и это неудивительно, ориентированы на ОС семейства Windows. Под управлением ОС этого семейства функционирует львиная доля всех компьютеров в мире, что создает большой простор для деятельности авторов вирусов, на что бы эта деятельность ни была направлена - удовлетворение личных амбиций, приобретение известности, получение прибыли или всего вместе.
Для заражения компьютера под управлением Microsoft Windows применяются практически все способы проникновения и активизации. Используются всевозможные каналы проникновения, уязвимости в системных и прикладных программах, методы социальной инженерии. Соответственно, ПО для защиты рабочих станций Windows должно обладать средствами для противодействия по возможности всем видам угроз.
В конечном итоге, за редкими исключениями, чтобы запуститься, вирусу необходимо сохранить свой код на диске
компьютера-жертвы в виде файла — зараженного файла, в случае чистого вируса, либо полностью вредоносной программы,
в случаях червей и большинства
Соответственно, основные средства из состава антивирусного комплекса для рабочих станций Windows направлены на предотвращение записи вредоносного кода на диски компьютера, на предотвращение запуска вредоносных программ, а также на проверку хранящихся на дисках (постоянных, сменных, сетевых) файлов - нет ли в них вредоносного кода. Последняя функция нужна для того, чтобы при запуске (или сразу после установки) антивируса удостовериться в отсутствии вирусов на компьютере - функции предотвращения в последствии позволяют сохранить этот status quo.
Как уже отмечалось в классификации антивирусов, средства проверки файловой системы бывают двух видов:
Реализация подобных средств может быть различной. Это могут быть независимые модули, либо различные функции одного и того же модуля. Модуль проверки при доступе, который по понятным причинам должен постоянно находиться в памяти компьютера в зависимости от применяемых технологий может быть выполнен в виде приложения, службы или драйвера файловой системы. Эффективность при этом растет в порядке перечисления.
Кроме того, что на момент установки или запуска антивируса вредоносные программы могут находиться на дисках, они могут находиться также и в памяти компьютера. Соответственно, имеется необходимость в проверке памяти. Особенности архитектуры операционной системы Windows таковы, что отслеживать изменения в памяти на лету попросту невозможно. В связи с этим функции проверки памяти выполняются сканером по требованию.
С точки зрения применяемых технологий обнаружения вирусов, основной упор при проверке объектов памяти и файловой системы
делается на
Тем не менее, в некоторых специфических случаях применение поведенческого анализа не только оправдано, но и является более эффективным методом предотвращения запуска новых вирусов, чем эвристический анализ.
Стоит сказать, что современные вирусы крайне редко пытаются записать данные в загрузочные сектора или в BIOS.
Эпоха
Если в случае исполняемых файлов, подозрительные операции выделить достаточно сложно в силу очень большого разнообразия этих файлов и решаемых ими задач, то сфера применения макросов в документах Microsoft Office и других офисных пакетов, достаточно ограничена - чаще всего они используются для сокращения времени на выполнение рутинных операций или же для придания дополнительной функциональности документам. В большинстве случаев действие макроса распространяется только на документ, в состав которого он входит, а взаимодействие с другими документами чаще всего ограничивается операциями чтения. Следовательно, активные действия связанные с файловыми операциями или с записью в другие документы, могут вызывать обоснованные подозрения.
Нерассмотренным остался метод анализа изменений (контрольных сумм). Здесь необходимо отметить, что для обнаружения вирусов этот метод в современных условиях уже не годится. Даже в системном каталоге Windows количество файлов может достигать нескольких тысяч. При этом обновления ОС и ряда приложений регулярно приводят к изменениям в составе и версиях хранящихся там файлов. Анализ изменений на дисках в целом - задача еще более трудоемкая и плохо автоматизируемая.
Конечно, опытный специалист на основании данных об изменениях в файловой системе мог бы с большой вероятностью определить признаки заражения неизвестным вирусом. Но количество времени, необходимое на такой анализ, делают его с одной стороны невозможным в сколько-нибудь больших сетях, а с другой стороны нерентабельным в сетях небольшого размера или в единичных случаях - из-за стоимости услуг по привлечению высококвалифицированного специалиста.
Тем не менее, даже если анализ контрольных сумм не позволяет определить факт наличия вируса в системе, он позволяет определить факт отсутствия вирусов в файлах, контрольная сумма которых осталась неизменной. Об использовании метода сравнения контрольных сумм в таком качестве будет рассказано при рассмотрении эксплуатационных характеристик антивирусных продуктов.
Одним из наиболее часто используемых каналов проникновения вредоносных программ по прежнему остается электронная почта. И хотя для предотвращения пересылки зараженных писем имеются специализированные средства антивирусной защиты уровня почтовых систем, существует множество ситуаций, когда такие средства по тем или иным причинам не используются.
В связи с этим, антивирус для рабочих станций Windows должен обладать собственными средствами защиты от вирусов, приходящих по почте.
Нужно отметить, что с большинством таких вирусов вполне справляются стандартные средства проверки файловой системы, поскольку находящийся во вложении вирус, даже будучи запущенным пользователем, все равно сначала сохраняется на диск во временный каталог, и только потом загружается в память. В момент сохранения он будет обнаружен и обезврежен средством проверки при доступе.
Для чего же в таком случае нужны и нужны ли вообще дополнительные средства проверки почты? В первую очередь для повышения производительности и надежности. Не секрет, что наибольшее "замедление" работы компьютера связано именно с работой постоянной защиты файловой системы. По этой причине многие пользователи отключают эту защиту вовсе или неоправданно снижают уровень защиты в настройках. Модуль защиты почты серьезного влияния на производительность не оказывает и может работать едва ли не с максимальными настройками, перекрывая один из наиболее опасных, с точки зрения распространения вирусов, потоков.
В силу того, что задача постоянной защиты файлов не проверяет архивы, только задача постоянной защиты почты может помешать отправке письма с инфицированным вложением, что также немаловажно.
По сути, локальный модуль проверки почтовых сообщений играет роль отсутствующего антивируса на почтовом сервере - он снижает нагрузку на другие модули проверки и уменьшает общую вероятность заражения. Например, некоторые черви используют уязвимости в почтовых клиентах для автоматического запуска зараженного вложения. Если проверка файловой системы по каким-то причинам отключена, получение такого червя означало бы немедленное заражение, не будь в составе антивирусного комплекса модуля проверки почты.
Кроме этого, не следует забывать, что любой вирус, даже находящийся в архиве или почтовой базе, представляет
собой потенциальную угрозу. Если вирус уже так или иначе проник на компьютер и ожидает, что пользователь сам его
запустит, это рано или поздно может случиться. Полная проверка компьютера проводится, как правило, не так часто:
раз в неделю, а то и реже, чтобы можно было быть уверенным в своевременном обнаружении и удалении вируса внутри
архива и/или почтовой базы. А значит, есть шанс, что вирус будет запущен пользователем хотя бы по причине
небрежности или случайной ошибки. Использование модуля проверки почты позволяет не допустить появления в
почтовой базе зараженных объектов и предотвратить возникновение потенциально
Есть и еще одна опасность. Как известно, в ответ на то, что антивирусы стали проверять заархивированные вложения, многие вредоносные программы стали распространяться в защищенных паролем архивах, указывая пароль в теле сообщения. В отсутствие модуля проверки почты, такие письма будут беспрепятственно попадать в почтовый ящик с все тем же риском быть запущенными. Но в этом случае даже проверка по требованию может не обнаружить такие вирусы, если не включена или не реализована проверка в архивах, защищенных паролем.
С точки зрения технологий, используемых в модулях проверки почты, можно выделить два направления в которых ведутся разработки:
Преимущества первого способа состоят в том, что проверяются все почтовые сообщения, обрабатываемые почтовым клиентом, независимо от используемых протоколов. С другой стороны, обеспечить необходимую интеграцию со всеми возможными почтовыми клиентами - задача практически неразрешимая. Поэтому используется второй способ, когда модуль проверки перехватывает соединения по некоторым почтовым протоколам, вычленяет из потока данных объекты, которые могут быть заражены, и проверяет их.
Каждый из способов имеет свои преимущества и недостатки. Интеграция обычно поддерживается с очень ограниченным числом почтовых клиентов, например, только с клиентом Microsoft Outlook. С другой стороны, способ перехвата соединений также ограничен в числе поддерживаемых протоколов - как правило, это только протоколы SMTP и POP.
Наравне с почтой, и в последнее время особенно часто, для проникновения на компьютер вредоносные программы используют поток данных непосредственно из Интернет. Соответствующие угрозы можно разделить на несколько классов:
С угрозами первых двух типов успешно справляется средство проверки файловой системы при доступе - загруженный файл будет проверен в момент записи на диск. Кроме этого могут использоваться и другие технологии.
Так, большинство менеджеров загрузки обладают возможностью запускать антивирусную проверку всех загружаемых файлов. Для эффективного использования этой возможности антивирус должен поддерживать передачу объектов для проверки и параметров проверки через командную строку.
Для защиты от использования на веб-страницах вредоносных скриптов, инициирующих несанкционированную загрузку и выполнение программ может использоваться специальный компонент проверки скриптов. Как известно, для выполнения скриптов, написанных на языках VBScript и JavaScript в ОС семейства Windows используется специальный компонент - Windows Script Host, допускающий интеграцию внешних фильтров. В некоторых антивирусах реализован отдельный модуль, проверяющий все скрипты, выполняемые посредством Windows Script Host, обеспечивая защиту не только от веб-страниц, но также от содержащих скрипты писем в html-формате и просто от сохраненных на диске скриптов.
Удаленная атака на сетевые службы является более серьезной проблемой, которую стандартными антивирусными средствами решить не удается - постоянный контроль адресного пространства в ОС Windows невозможен. Для защиты от подобных атак в антивирусные средства интегрируется часть функций персональных брандмауэров либо полноценный персональный брандмауэр. Таким образом, антивирус превращается в более сложный и многофункциональный программный продукт, способный отслеживать сетевые соединения и блокировать атаки на переполнение буфера, которые чаще всего и используются для удаленного внедрения и выполнения кода.
В целом же защиту от атак на сетевые службы следует обеспечивать не антивирусными средствами, а установкой обновлений, устраняющих уязвимости. В крупных компаниях такой подход должен быть закреплен организационными мерами в рамках комплексного подхода к построению системы антивирусной защиты.
В отличие от рабочих станций Windows, вредоносных программ, угрожающих заражением непосредственно рабочим станциям под управлением Unix или MacOS крайне мало. В большинстве своем это либо так называемые proof-of-concept (доказательство возможности) вирусы, либо вирусы, использующие весьма специфические уязвимости. Первые не встречаются в "диком виде" и на практике опасности не представляют. Что касается вторых, то они способны поражать только системы с очень специфическим набором свойств (например, с установленным прикладным ПО определенной версии) и, как правило, не угрожают актуальным версиям ОС и соответствующих программ.
В связи с этим антивирусы для таких рабочих станций предназначены не столько для предотвращения заражения, сколько для недопущения распространения вредоносных программ. Зараженный файл, скопированный с Windows-машины на Unix-машину, не может нанести вреда Unix-машине, но остается зараженным и, будучи скопированным назад на Windows-машину (ту же или любую другую), представляет собой опасность.
Следовательно, антивирус для рабочих станций под управлением ОС, отличных от Microsoft Windows, не нуждается в большинстве модулей и технологий, применяемых для защиты рабочих станций Windows. Как правило, оказывается достаточно средства проверки по запросу, для регулярной проверки файловой системы или же для нерегулярной проверки отдельных файлов или папок.
Если же на Unix-машине имеется ресурс, активно используемый для хранения и передачи файлов пользователями рабочих станций Windows, это означает, что такая Unix-система относится к классу серверных и требует соответствующих назначению средств защиты.
Кроме того, что антивирус должен эффективно защищать компьютер от вирусных угроз, он также должен обеспечивать:
Задача обновления — обеспечить связь между разработчиками и антивирусным продуктом. Специфика антивирусной защиты
такова, что по мере обнаружения и изучения новых видов и типов угроз, антивирус постоянно нуждается в обновлениях,
позволяющих ему эффективно противостоять этим угрозам. В основном это касается обновления
Сегодня ежедневно появляется несколько десятков, а то и сотен новых вредоносных программ. Практически все они
требуют внесения изменений в антивирусные базы, даже те, которые обнаруживаются при помощи эвристического анализа,
поскольку обнаружение
Никогда заранее неизвестно, в какой момент может появиться вредоносная программа, которая потребует внесения изменений в алгоритмическую часть антивируса, т. е. в антивирусное ядро. С другой стороны, когда она появляется, необходимо оперативно предоставить механизмы защиты всем пользователям, чтобы локализовать эпидемию - ждать выпуска новой версии нет времени. В связи с этим, механизм обновления должен подразумевать обновление как сигнатур - антивирусной базы, - так и антивирусного ядра.
Не стоит забывать и о том, что в модулях антивируса могут быть обнаружены ошибки, требующие устранения. В этом случае могут выпускаться специальные заплаты, устраняющие ошибки. Процесс загрузки заплат бывает автоматизированным или нет. Во втором случае пользователь должен самостоятельно загружать исправления с сайта производителя и устанавливать их. На практике это означает, что многие (если не большинство) пользователи заплату не установят, создавая тем самым предпосылки к возникновению эпидемий, т. к. заплата может устранять в том числе и уязвимости в самом антивирусе, открывающие лазейки для нейтрализации антивирусной защиты вредоносной программой. Следовательно, автоматическая загрузка и установка заплат является предпочтительной.
Обновления антивирусных баз и само антивирусное ядро могут быть как зависящими от операционной системы, так и не зависящими. В первом случае антивирусы одного производителя, установленные на разные платформы (Windows, Unix), будут загружать различные обновления. Во втором случае, обновления будут одинаковыми, что позволит сэкономить на объеме загружаемой из Интернет информации - достаточно будет один раз загрузить обновления с сайта производителя и поместить их в общедоступный ресурс внутри сети.
Возможность размещения обновлений на общедоступном ресурсе внутри сети приводит к вопросу о допустимых способах организации этого ресурса. Стандартом де-факто в антивирусной индустрии является поддержка антивирусными средствами обновления из HTTP-, FTP- или локального (сетевого) ресурса.
Реализация управления связана с двумя аспектами - структурой инструментов управления и организацией доступа к этим инструментам. К инструментам управления относятся настройки и задачи.
Настройки — это значения параметров, определяющих характер выполнения тех или иных действий
Задачи — это именованные действия, связанные с используемыми в антивирусе средствами и характеризующиеся индивидуальными настройками выполнения
Пример. В Антивирусе Касперского для Windows Workstations существуют следующие типы задач:
Количество создаваемых задач проверки по требованию не ограниченно. В то же время в Антивирусе Касперского для Linux Workstations задачи как инструмент отсутствуют. Есть только настройки выполнения обновления, проверки по требованию
С точки зрения доступа к инструментам управления выделяются следующие средства:
Можно отметить, что для антивирусов под Windows штатным способом управления является локальный - через графический интерфейс. Развитых средств удаленного доступа в ОС Windows нет, а точнее эти средства применяются преимущественно в серверных системах, а в пользовательских версиях Windows эти средства если и есть, то очень ограничены (речь идет об инструменте Remote Desktop).
В антивирусах для Unix-систем, напротив, используется преимущественно удаленный доступ: либо через веб-интерфейс, либо через telnet- или ssh-клиент.
Пример. В Антивирусе Касперского для Windows Workstations имеется графический интерфейс и интерфейс командной строки. Настройки продукта в целом и отдельных задач хранятся в xml-файлах, которые подписаны и не предназначены для непосредственного редактирования. В реестр Windows вынесены лишь некоторые настройки антивирусного ядра, не касающиеся антивирусных функций
В Антивирусе Касперского для Linux Workstations используются конфигурационные файлы, интерфейс командной строки и веб-интерфейс.
Диагностика состояния и результатов функционирования антивируса проявляется в двух плоскостях:
Уведомления бывают двух видов: локальные и сетевые. Локальные могут выражаться в виде информационных окон, всплывающих сообщений в системной панели, в виде изменения статуса антивируса (в той же системной панели или в окне интерфейса). В какой-то мере локальным уведомлением может считаться запись в журнал.
Сетевые уведомления предназначены для уведомления не пользователя, а администратора антивирусной безопасности, отвечающего за защиту сети в целом. Следовательно, сетевые уведомления могут быть реализованы только в сетевой (корпоративной) версии антивируса, в персональной версии сетевые уведомления не имеют смысла.
Наиболее распространенными способами доставки сетевых уведомлений являются электронная почта и служба оповещений Windows (имя службы - Оповещатель (Messenger)). Существуют и другие способы доставки, но они редко бывают реализованы непосредственно в антивирусе, поэтому о них речь пойдет позже при рассмотрении подсистемы диагностики в системе администрирования.
Стоит отметить, что наличие встроенных в корпоративный антивирус для рабочих станций возможностей уведомления по сети обычно характерно для тех производителей, у которых система администрирования не является бесплатной, а поставляется и лицензируется как отдельный продукт. У производителей, предлагающих систему администрирования бесплатно, сам по себе антивирус, как правило, сетевые уведомления отправлять не может.
Пример. Антивирус Касперского Personal и Personal Pro имеют только локальные возможности уведомления. Причем для различных событий используются различные инструменты: при обнаружении вируса на экране может отображаться диалоговое окно с выбором варианта действия, при смене состояния антивируса (устаревание баз, запуск задач и т.п.) отображаются всплывающие подсказки в системной панели и меняется статус антивируса в главном окне интерфейса.
Антивирус Касперского для Windows Workstations обладает теми же возможностями, что и персональные версии. Поскольку Kaspersky Administration Kit является бесплатным и обладает всеми необходимыми средствами для организации сетевых уведомлений, альтернативная реализация этой возможности в антивирусе для рабочих станций отсутствует.
Хотя журналы работы и можно рассматривать как один из вариантов уведомления, все же их функции несколько шире. Если уведомления - действия разовые, не оставляющие после себя никаких следов, то журналы остаются и могут быть проанализированы для выяснения причин заражения, сбоев, неполадок и других инцидентов.
Существуют различные подходы к ведению журналов:
Преимущества есть у обоих подходов, в первом случае упрощается анализ отдельного журнала, но возникает проблема поиска нужного, во втором - сразу понятно, где искать, но сам поиск по журналу может составить проблему.
Кроме этого возможны различия в форматах хранения журналов и, как следствие, способах работы с ними. Если журналы сохраняются в обычном текстовом формате с понятными описаниями событий, их можно анализировать в любом текстовом редакторе. Но нередко журналы хранятся в служебных нечитаемых форматах и для работы с ними нужно использовать встроенные в антивирус средства.
Пример. В Антивирусе Касперского для Windows Workstations отдельный журнал создается для каждой задачи. Формат журналов - служебный и нормальная работа с ними возможна только через интерфейс антивируса.
В Антивирусе Касперского для Linux Workstations журналы создаются для различных действий (фактически, для различных
модулей) - журнал проверки,
Иногда в дополнение к событиям, в журналы записывается информация о настройках (задачи или антивируса) при которых это событие имело место. Что касается самих событий, то в них обязательно указывается дата и время, тип события, описание и перечисление важных для данного события параметров. Например, при обнаружении вируса должны указываться тип вируса и имя зараженного файла, а также предпринятое действие.
Под надежностью понимается несколько аспектов работы антивируса. Во-первых, это способность противодействовать вредоносным программам, пытающимся отключить антивирусную защиту. Во-вторых, это инструменты для защиты от необдуманных или небезопасных действий пользователя. Наконец, в-третьих, это недопущение потери данных по вине антивирусного средства.
Последние годы вредоносные программы не только маскируются и стараются остаться незамеченными, но и активно противостоят антивирусным средствам путем выгрузки из памяти соответствующих модулей, удаления файлов с дисков компьютера, блокирования доступа к серверам обновления.
Среди технологий, призванных противостоять таким действиям вирусов, можно выделить несколько основных:
Не только вредоносные программы, но и сами пользователи могут быть причиной частичного или полного отключения антивирусных средств. Имеет место распространенный предрассудок, что антивирусные средства являются основной причиной снижения производительности или появления сбоев в работе компьютера. Исходя из такого мнения, многие пользователи стремятся отключить антивирусную защиту либо отдельные ее функции каждый раз, когда они (пользователи) испытывают неудобства в работе.
С точки зрения администратора антивирусной безопасности подобные действия являются крайне нежелательными, поскольку компрометируют защиту сети в целом (речь не идет о действиях пользователей персональных антивирусов). Чтобы воспрепятствовать вмешательству пользователей в работу антивирусных средств, конечно, должны использоваться административные меры, но помимо них могут применяться и встроенные в антивирусные средства технологии ограничения действий пользователей.
К таковым могут относиться:
Дополнительные средства защиты связаны с применением системы управления и использованием политик, о чем и будет рассказано в соответствующей лекции.
Выполняя действия по предотвращению заражения и нейтрализации обнаруженных инфицированных объектов, антивирус неизбежно модифицирует файлы пользователя (при лечении или удалении зараженных файлов), что в редких случаях может привести к потере нужной информации. Чтобы этого не происходило, в ряде антивирусов применяется технология резервного копирования.
Второй важный аспект - обработка подозрительных объектов. Понятно, что лечение таких объектов невозможно в принципе, а удаление - опасно потерей данных, по причине ложного срабатывания. Разумным решением является изоляция таких объектов до выяснения обстоятельств.
Наконец, стоит учитывать такой момент как конфликты АПО с прочими программами, установленными на компьютере. Если сами модули антивируса обычно перед выпуском новой версии тщательно тестируются и в подавляющем большинстве случаев не допускают подобных конфликтов, то обновления антивирусных баз и ядра выпускаются слишком часто, чтобы их можно было должным образом протестировать. По этой причине изредка возникают проблемы совместимости, которые, впрочем, оперативно устраняются выпуском исправленных обновлений или же просто следующей версией, если обновления выходят часто.
Тем не менее, ожидая исправленной или новой версии обновлений, пользователю необходимо как-то работать, а значит должен быть механизм, позволяющий при необходимости использовать не текущую версию антивирусных баз, а последнюю корректную.
Основная идея повышения производительности состоит в исключении необязательных и/или многократных проверок. Например, при проверке по требованию происходит обращение к объектам файловой системы, что при прочих равных должно условиях вызывать также и проверку при доступе. Однако, вполне понятно, что такая двойная проверка является излишней и поэтому практически во всех антивирусных продуктах объекты, сканируемые модулем проверки по требованию, никаким другими модулями не сканируются.
Если нет смысла проверять один и тот же объект два раза подряд (что очевидно), то возникает вопрос: каков допустимый интервал между двумя последовательными проверками одного и того же объекта? Ответ лежит на поверхности: до тех пор, пока состояние системы с точки зрения проверки этого объекта не изменилось. Важными параметрами в данном случае будут:
Отследить изменения в антивирусе - задача тривиальная. Соответственно стоит вопрос об отслеживании изменений в объектах и хранении данных об условиях предыдущей проверки. Здесь как раз и используется технология расчета и анализа контрольных сумм, которая обеспечивает две характеристики:
Пример. В Антивирусе Касперского для Windows Workstations (и в других версиях Антивируса Касперского под Windows) применяются уникальные технологии iStreams и iChecker. Обе они основываются на вычислении контрольных сумм проверенных объектов и отличаются только в том, где хранятся контрольные суммы.
При использовании технологии iChecker данные об объектах сохраняются в отдельной базе, что позволяет применять данную технологию не только к объектам файловой системы, но и к вложениям почтовых сообщений (вложения, имеющие одинаковую контрольную сумму, имя, размер, дату создания и пр. считаются идентичными).
Если же используется технология iStreams, контрольные суммы сохраняются в дополнительных потоках файловой системы NTFS, что накладывает естественные ограничения на область применения данной технологии.
Кроме автоматической сортировки объектов на те, которые нужно проверять и те, которые проверять смысла нет, для повышения производительности с успехом применяются также методы ручной сортировки.
Первый этап подобной сортировки выполняют эксперты компании-производителя, определяя типы файлов, которые могут быть заражены и которые по этой причине необходимо проверять. Остальные типы файлов считаются потенциально неопасными и проверять их рекомендуется только в особых случаях - при опасениях, что машина может быть заражена неизвестным вирусом, или во время протекания масштабной эпидемии.
Пример. В Антивирусе Касперского пользователю на выбор предлагается три подхода к определению проверяемых объектов:
Последние две опции призваны обеспечить один и тот же описанный выше эффект - проверять только потенциально заражаемые объекты - но отличаются реализацией. В первом случае (по формату) тип объекта определяется исходя из его внутренней структуры. Например, EXE-файл, переименованный в файл с расширением TXT, будет корректно опознан как исполняемый и проверен.
Второй способ ту же задачу решает на основании только расширения, т. е. переименованный EXE-файл проверен не будет. Этот способ быстрее, но не так надежен. Оптимальным компромиссом между надежностью и производительностью, рекомендованным экспертами Лаборатории Касперского, является выбор проверки заражаемых объектов по формату.
Следующим этапом сортировки объектов является реализация в антивирусе инструментов для гибкой настройки перечня проверяемых объектов. Проверяемые (или исключаемые) объекты могут определять по различным признакам. Наиболее часто реализуется исключение объектов по их идентификации в файловой системе компьютера - по принадлежности к определенному диску или каталогу, по маске имени и/или расширения.
Кроме априорных подходов, когда объекты исключаются еще до начала их проверки, существуют и апостериорные - когда проверка объекта начинает выполняться и в зависимости от характеристик ее протекания принимается решение продолжать проверку (до окончания) или прекратить.
Наконец, нередко применяются способы регулировки производительности вообще не зависящие от характеристик проверяемых объектов. Так, во многих антивирусах имеется возможность задать приоритет проверки (в смысле приоритета процесса, выполняющего сканирования). Встречаются и другие подходы.
Регулировка использования системных ресурсов применяется обычно только для проверки по требованию.
На основании приведенных выше рассуждений и примеров можно сформулировать основные требования к антивирусам для рабочих станций. Понятно, что эти требования будут отличаться для рабочих станций различных классов.
Как и раньше требования будут делиться на несколько категорий:
Категории требований будут теми же, но сами требования будут менее жесткими по описанным ранее причинам:
В целом антивирусная защита серверов не так сильно отличается от защиты рабочих станций, как, например, от защиты шлюзов. Основные угрозы и технологии противодействия им остаются теми же - смещаются только акценты.
Сетевые сервера как и рабочие станции естественным образом делятся на классы, согласно используемым операционным системам:
Принцип деления обусловлен характерными для различных операционных систем вирусными угрозами и, как следствие, различными вариантами в определении основной задачи антивируса.
В случае продуктов для защиты серверов деление на персональные и сетевые продукты отсутствует - все продукты являются сетевыми (корпоративными). У многих производителей вообще нет деления корпоративных продуктов на предназначенные для рабочих станций и файловых серверов - имеется единый продукт.
Все относящиеся к серверам специфические угрозы связаны не столько с особенностями серверных операционных систем, сколько с применением уязвимого ПО, характерного для серверов.
Для серверов Windows актуальны все те же угрозы, что и для рабочих станций под Windows NT/2000/XP. Отличия заключаются только в преимущественном способе эксплуатации серверов, что выражается в ряде дополнительных атак, нехарактерных для рабочих станций.
Так, за серверами Windows редко непосредственно работают пользователи, а значит, почтовые клиенты и офисные приложения
на серверах, как правило, не используются. Как следствие, требования к защите почты на уровне почтового клиента и
дополнительные средства обнаружения
С другой стороны на серверах Windows значительно чаще, чем на рабочих станциях могут использоваться такие службы как Microsoft SQL Server и Microsoft IIS. Как и сами операционные системы производства Microsoft (и не только Microsoft), эти службы могут содержать уязвимости, чем в свое время неоднократно пользовались авторы вирусов.
Пример. В 2003 году появился и буквально пронесся по Интернету червь Net-
Пример. Еще раньше, в 2001 году, уязвимость в Microsoft IIS 5.0 была использована для распространения червем
Net-
Особенность обоих червей в том, что модуль проверки файловой системы (хоть по запросу, хоть при доступе) против
них бессилен. Эти черви не сохраняют свои копии на диск и вообще никак не проявляют своего присутствия в системе,
кроме повышенной сетевой активности. На сегодняшний день основной рекомендацией по защите является своевременная
установка патчей на операционную систему и используемое ПО. Другой подход заключается в настройке брандмауэров
таким образом, чтобы порты, используемые уязвимыми службами были недоступны извне - разумное требование в случае
защиты от Slammer, но неприемлемое для защиты от
Актуальными для серверов Windows остаются и черви, атакующие уже непосредственно уязвимые службы операционной системы, такие как Lovesan, Sasser, Mytob и др. Защита от них должна обеспечиваться комплексными мерами - использованием брандмауэров, установкой заплат, применением проверки при доступе (упомянутые черви при успешной атаке сохраняют свои файлы на жестком диске).
Учитывая характер атак, можно сделать вывод, что основными средствами защиты серверов Windows являются: модуль проверки файлов при доступе, модуль проверки файлов по требованию, модуль проверки скриптов, а основными технологиями - сигнатурный и эвристический анализ (а также поведенческий - в модуле проверки скриптов).
Специфических вирусов, способных заражать Novell Netware, нет. Существует, правда, несколько
Соответственно, антивирус для сервера Novell Netware фактически не предназначен для защиты этого сервера. В чем же тогда его функции? В предотвращении распространения вирусов. Сервера Novell Netware в большинстве своем используются именно как файловые сервера, пользователи Windows-компьютеров могут хранить на таких серверах свои файлы или же запускать программы, расположенные на томах Novell Netware. Чтобы предотвратить проникновение вирусов на общие ресурсы сервера Novell, либо запуск/чтение вирусов с таких ресурсов и нужен антивирус.
Соответственно, основные средства, применяемые в антивирусе для Novell Netware - проверка при доступе и проверка по требованию.
Из специфических технологий, применяемых в антивирусах для Novell Netware необходимо отметить блокирование станций и/или пользователей, записывающих на сервер вредоносные программы.
Про сервера Unix можно сказать все то же, что и про сервера Novell Netware. Антивирус для Unix-серверов решает не столько задачу защиты самих серверов от заражения, сколько задачу недопущения распространения вирусов через сервер. Для этого применяются все те же два основных средства:
Многие известные черви под Linux используют для распространения уязвимости не в самой операционной системе, а в
системном и прикладном ПО - в ftp-сервере wu-
В отличие от серверов Novell, где поддержка сетей Microsoft является встроенной функцией, сервера Unix по умолчанию
не приспособлены для передачи файлов по протоколу SMB/
Если обмен файлами происходит только по протоколам SMB/
Стабильная работа серверов, как правило, гораздо критичнее для сети в целом, чем функционирование отдельных рабочих станций. На серверах обрабатывается больше информации, они же зачастую являются местами постоянного хранения этой информации, в случае с серверами приложений, услугами сервера пользуется одновременно большое количество человек - все это накладывает повышенные требования к надежности и производительности антивирусного программного обеспечения, устанавливаемого на сервера. Помимо этих характеристик, важными остаются реализация управления, обновления и диагностики.
Инструменты и принципы управления, применяемые в антивирусах для серверов, в целом не отличаются от применяющихся в антивирусах для рабочих станций. Это и понятно: различия в назначении и в условиях применения не так велики. Тем не менее, определенная разница есть.
Как правило, сервера Windows предполагают автономную работу с минимальным вмешательством администраторов. Все необходимые службы и приложения настраиваются один раз и в дальнейшем работают согласно настройкам. В этой ситуации особой необходимости в наличии специализированного графического интерфейса для антивируса нет, достаточно наличия каких бы то ни было средств настройки - применяться они в любом случае будут нечасто.
Что касается управления продуктами для Unix-серверов, здесь тоже нет ничего нового: применяется веб-интерфейс либо управление посредством редактирования конфигурационных файлов и запуска задач из командной строки в telnet- или ssh-сессии.
Продукты под Novell Netware, в том числе и не только антивирусные, как правило, управляются через стандартный инструмент ConsoleOne.
Здесь вообще никакой разницы в сравнении с антивирусами для рабочих станций нет.
В антивирусах для файловых серверов, в целом, используются те же средства диагностики, что и в рабочих станциях - уведомления, отчеты. Однако иногда, для тщательной диагностики проблем производительности или других проблем, необходимо в режиме времени реального сравнивать некоторые показатели работы компьютера, в том числе и показатели работы антивируса. Такого рода диагностика куда чаще бывает нужна на серверах, чем на рабочих станциях, и поэтому соответствующие средства диагностики, если и встречаются, то в антивирусах для защиты серверов.
На практике реализация такого рода диагностики выглядит как добавление в стандартный инструмент Windows - Performance Monitor- дополнительных счетчиков, как и в случае средств для защиты шлюзов или почтовых серверов. Как правило, счетчики включают:
и т. п. статистические данные
В отношении надежности АПО для защиты серверов должно обладать теми же характеристиками, что и АПО для защиты рабочих станций:
При этом задействуются все те же технологии.
Тем не менее, повышенные требования к защите серверов должны учитываться при разработке антивирусного ПО для них, и они учитываются в виде улучшенной совместимости с другим распространенным серверным ПО. Следствием такого подхода также косвенно является урезание функционала серверного антивируса в сравнении с антивирусом для рабочих станций - чем меньше модулей содержит антивирус, тем меньше вероятность конфликтов или сбоев.
Что касается производительности, то и в этом случае антивирусное ПО для серверов использует практически те же технологии, что и АПО для рабочих станций. Но не только.
В отличие от рабочих станций, сервера нередко могут работать на многопроцессорных платформах. С одной стороны этот факт не должен вызывать проблем в работе АПО, т. е. оказывать влияние на тестирование надежности. С другой стороны, антивирус вполне может использовать многопроцессорную архитектуру для повышения скорости проверки объектов.
Пример. В Антивирусе Касперского для Windows
Соответственно, количество сканирующих ядер, загружаемых в память компьютера. равно количеству процессоров. При этом
процессоры Intel, использующие технологию
Приведенные рассуждения и примеры позволяют сформулировать требования к антивирусам для серверов. Здесь различия в назначении не так разительны, как в случае рабочих станций и поэтому можно не делить требования в соответствии с классами серверов, а отмечать различия в соответствующих пунктах:
Как уже говорилось, в больших сетях система управления является тем необходимым инструментом, который позволяет контролировать состояние системы защиты серверов и рабочих станций в целом. В штатном режиме такой подход позволяет существенно снизить затраты на обслуживание, в условиях эпидемии - позволяет оперативно корректировать настройки и удаленно командовать работой антивирусов на узлах.
Каждым антивирусным средством можно управлять непосредственно: либо локально, либо, как в случае с продуктами под Novell Netware, Linux, Unix - удаленно при частичной помощи штатных средств этих операционных систем. Любые задачи по настройке и выполнению определенных операций могут быть решены таким образом.
Однако в случае, когда похожие настройки необходимо сделать не на двух, трех, пяти или даже десяти узлах, применять независимые средства управления для каждого из узлов становится крайне неэффективно. Если же еще учесть, что большую часть узлов сети составляют компьютеры под управлением ОС Windows, и что ОС этого семейства не обладают развитыми средствами удаленного управления, позволяющими изменять настройки программ, не мешая работе пользователей, то к необходимости независимой настройки прибавляется необходимость непосредственного присутствия администратора антивирусной безопасности для выполнения этих действий. В конечном итоге, управление сколько-нибудь большим числом защищенных узлов становится задачей крайне трудоемкой и малоэффективной.
Кроме того, если в сети случается инцидент, связанный с антивирусной безопасностью, штатные средства управления антивирусным средством либо оповещают об этом локального пользователя либо просто записывают информацию в отчет. В такой ситуации между моментом, когда произошел инцидент, и моментом, когда об этом стало известно администратору, может пройти значительное время - несколько часов или даже дней. В ситуации повышенной вероятности возникновения эпидемии такие задержки недопустимы.
При возникновении внештатной ситуации как никогда важной становится возможность оперативно получать информацию о состоянии защиты на всех защищаемых узлах и своевременно вносить коррективы в настройки, а также при необходимости обновлять антивирусные базы и проводить внеплановую проверку компьютеров. Если для выполнения этих действий администратору потребуется произвести полный обход территории сети, он полностью потеряет контроль за происходящим.
Таким образом, вырисовывается необходимость в дополнительном инструменте, который позволил бы решать следующие задачи:
Фактически, необходим инструмент, который позволял бы удаленно и централизовано решать задачи управления, обновления и диагностики системы антивирусной защиты. Такой инструмент принято называть системой управления или системой администрирования. Помимо упомянутых задач система администрирования обычно включает также функции, связанные с разворачиванием системы антивирусной защиты в сети - функции удаленной установки и деинсталляции антивирусных средств.
Легко видеть, что задачи, решаемые системой администрирования, достаточно разнородны и не обязательно связаны между собой. По этой причине и система администрирования может быть легко представлена в виде совокупности нескольких подсистем, соответствующих задачам:
На практике эти подсистемы могут и не составлять единый продукт. Практически любая из подсистем может представлять собой отдельное решение.
Пример. В версии 4.5 Kaspersky Administration Kit удаленная установка была отделена от всех остальных функций системы управления и представляла собой отдельный инструмент, выполненный в виде независимого программного модуля, который, впрочем, считался частью Kaspersky Administration Kit.
В ряде антивирусов (например, Sophos) система обновления может строиться практически независимо от системы администрирования.
Также нередко (CA, eTrust, McAfee) для расширения функций системы диагностики (в первую очередь, системы уведомлений) используется отдельное решение.
Все же наиболее удачным выглядит решение, объединяющее в себе все необходимые подсистемы. Таким решением является
Kaspersky Administration Kit. Аналогичной универсальностью характеризуются продукты для управления от Symantec,
McAfee и
В данном случае требования можно сформулировать еще до обзора условий эксплуатации и применяемых технологий, поскольку в принципе требования к системе администрирования являются обобщением требований к управлению, обновлению и диагностике отдельных антивирусных комплексов:
Для того, чтобы эффективно осуществлять удаленное управление даже отдельными узлами, оснащенными антивирусным ПО, необходимо где-то хранить параметры доступа к этим узлам - адреса, идентификаторы и т.п. Т.е. вопрос о централизованном характере системы управления возникает буквально сразу же. Как показывает практика, именно централизованный вариант является наиболее удобным и эффективным, поскольку все системы управления построены по одному и тому описанному ниже принципу.
Система управления строится на базе трех компонентов:
Функции компонентов распределены следующим образом:
Защищенный узел сети с установленным агентом принято называть клиентом или клиентским компьютером того сервера управления, к которому подключен агент.
Пример. В Kaspersky Administration Kit структура решения полностью совпадает с описанной, имеются:
В других системах управления, встречаются варианты, когда сервер и консоль управления объединены в общий модуль, или же когда агент является составной частью антивируса, неотделимой от него
Совокупность всех агентов, подключенных к серверу управления принято называть
Как только возникает вопрос об изменении настроек или о запуске задач одновременно на группе компьютеров, возникает и вопрос о структуре и взаимосвязи этих групп. Сегодня можно встретить два подхода к реализации работы с группами:
Первый подход обладает большей гибкостью, при желании можно назначить задачу произвольному набору компьютеров, в зависимости от того, как складывается ситуация. Однако этот подход не позволяет эффективно отслеживать состояние настроек антивирусной защиты на узлах. Действительно, в какой-то момент времени настройки узла могут быть изменены вместе с одной группой компьютеров, в другой момент - уже с другой группой, в третий момент - индивидуально. В результате априори узнать, какие настройки используются на конкретном узле не представляется возможным, что приводит к ненужной неразберихе и потере контроля над состоянием защиты.
При втором подходе гибкость, очевидно меньше, зато появляется возможность задавать постоянные настройки для групп компьютеров и контролировать сохранение этих настроек в неизменном виде. С таким подходом уже гораздо проще отслеживать уровень защиты.
Таким образом, складывается структура элементов управления:
Для чего вообще имеет смысл объединять компьютеры в группы? По сути, цели две:
Достижение первой цели возможно в любой структуре групп: как первого, так и второго типа. Действительно, нет никакого противоречия в том, что узел входит в две группы и на нем выполняются задачи, сформированные для каждой из групп. Вторая цель достижима только в структуре с постоянными группами, составы которых не пересекаются. Это тоже вполне понятно, если для группы заданы настройки, которые должны быть справедливы для всех узлов этой группы, то для узла входящего в две группы одновременно возникает противоречие: неясно, настройки какой группы на нем будут использоваться.
Как правило, настройки заданные на уровне группы называются политикой. Отличия в этих терминах можно кратко сформулировать следующим образом: настройки - это "как есть", а политика - "как должно быть". В силу императивного характера политик, они предполагают наличие неких механизмов контроля. Практикуется два подхода:
Понятно, что такая категоричность не всегда удобна - легко представить себе ситуацию, при которой некоторые настройки должны быть зафиксированы жестко, а некоторые могут быть изменены локальными пользователями без особого ущерба качеству защиты. Большинство систем управления позволяют выборочно отмечать обязательные и необязательные параметры политики.
Пример. В Kaspersky Administration Kit используется смешанный подход. В первую очередь имеются политики, отдельные настройки которых могут быть отмечены как обязательные или необязательные. Эти настройки охватывают все аспекты работы антивирусных средств. Изменение обязательных параметров на локальных компьютерах полностью заблокировано. Но также выделяются и рекомендуемые настройки защиты, при отклонении от которых формируется уведомление администратору антивирусной безопасности. Такая реализация позволяет использовать преимущества обоих подходов.
Помимо этого, в Kaspersky Administration Kit реализована гибкая система применения политик, основанная на том, что настройки и политики четко разделяются даже на уровне локальных компьютеров и хранятся независимо. Применение политики может происходить одним из трех способов на выбор администратора:
Нередко в составе группы естественным образом выделяется подгруппа клиентов, для которых требуется незначительно изменить
политику или создать отдельную групповую задачу. В этом случае было бы удобно выделить подгруппу в отдельную группу,
являющуюся элементом исходной группы, чтобы в ней продолжали действовать групповые задачи и политики исходной группы.
Многие системы управления поддерживают такую возможность. В этом случае
Структура групп, настройки групповых задач и политик, а также нередко и данные диагностики - вся эта информация
должна так или иначе храниться на сервере и быть доступной для анализа и обработки. Как правило, для этих целей
используется внешний сервер баз данных, по сути - четвертый компонент системы управления. Чаще всего в системах
управления применятся бесплатная модификация Microsoft SQL Server 2000 - Microsoft SQL Server Desktop Engine 2000
или коротко
Пример. В Kaspersky Administration Kit также используется внешний сервер баз данных и именно
Поддерживается в Kaspersky Administration Kit и работа с полноценным Microsoft SQL Server 2000
Кроме вопроса удобства, который выражается в механизмах групп, групповых задач и политик, существует также вопрос производительности системы управления. Например, если в организации имеется несколько филиалов, каналы связи между которыми весьма ограничены, одновременное применение политики может вызвать перегрузку канала связи с филиалом.
Чтобы избежать этой ситуации используются следующие методы:
Механизм иерархии серверов управления заключается в том, что одни сервера управления могут подключаться к другим.
Соответственно подключаемый сервер будет подчиненным, а тот, к которому производится подключение - главным. При этом
степень взаимодействия между главными и
Один из вариантов взаимодействия -
Второй вариант - группы управления привязываются к серверам управления, все управление происходит прозрачно, т.е.
Применяются и другие, достаточно сложные для описания схемы реализации.
Пример. Иерархия Серверов администрирования реализована и в Kaspersky Administration Kit.
Принцип применения тот же, что и в иерархии групп - унаследованные задачи применяются ко всем клиентам подчиненного Сервера, унаследованные политики действуют также на всех клиентах, если только не переопределены на уровне групп или подгрупп подчиненного Сервера. Обязательные параметры по-прежнему переопределять нельзя и они остаются обязательными в создаваемых политиках.
Доступ к подчиненным Серверам возможен как напрямую, так и через интерфейс главного Сервера администрирования.
Еще одним фактором иерархии серверов является ее глубина. Чаще всего можно встретить двухуровневую иерархию, где есть ровно один главный сервер управления, к которому подключены все остальные сервера управления. Однако есть реализации допускающие произвольную глубину иерархии.
Немаловажным аспектом системы управления является организация доступа к ее функциям. Реализация разграничения доступа может быть самой разной. Можно выделить следующие характерные схемы:
Пример. В Kaspersky Administration Kit используется третья схема реализации. Выделяется две группы пользователей -
администраторы и операторы
Для идентификации, аутентификации и разграничения доступа используются средства Windows. Права администраторов
Необходимость подсистемы обновления, общей для всей системы защиты (во всяком случае, для третьего уровня - защиты серверов и рабочих станций), на первый взгляд не так очевидна. Действительно, при наличии на всех узлах функций обновления и при наличии централизованной системы управления не составляет труда регулярно запускать задачи обновления на клиентах и контролировать состояние антивирусных баз.
Однако, следует учитывать, что при выполнении задачи обновления передается большее количество данных, чем при распространении настроек или при выполнении других задач управления. Следовательно, основная проблема обновления в больших сетях - проблема загрузки сети. У многих производителей антивирусного ПО регулярные обновления антивирусных баз могут составлять несколько сотен килобайт или даже несколько мегабайт. Если представить, что все клиенты одновременно обратятся к внешнему источнику обновления - серверу обновлений производителя - канал доступа в Интернет будет перегружен. Более того, при таком размере обновлений могут быть перегружены даже каналы локальной сети.
Пример. Пусть размер регулярных обновлений составляет в среднем 1 Мб, и пусть в сети имеется 1000 клиентов, которые требуется обновить. Следовательно, в процессе обновления через канал доступа к Интернет должно быть передано 1000 Мб информации. Если предположить, что канал доступа имеет пропускную способность 2 Мбит/с можно вычислить, что на обновление всей сети потребуется
$$\frac{(1000\cdot 8) \text{Мбит}}{2 \text{Мбит/с}} = 4000 c$$т. е. больше одного часа.
На практике это будет означать одно из двух: либо значительная часть станций просто не получит доступа к источнику обновлений из-за перегрузки сети и не будет обновлена, либо доступ к сети Интернет другим программам и службам во время выполнения обновления будет затруднен.
Такая же проблема с загрузкой сети будет возникать и в ситуации, когда организация имеет несколько филиалов, пропускная способность линий связи между которыми ограничена.
Путей решения у этой проблемы фактически два:
Таким образом, система обновления - это набор средств и способов организации и контроля промежуточных источников обновления.
В общем случае система обновления может иметь такие типы структур:
Использование той или иной схемы диктуется размером и структурой сети организации. Так в небольших офисах вполне допустимо использование децентрализованной схемы. В сетях среднего размера, до нескольких сотен компьютеров, сосредоточенных в одной локальной сети удобно использовать централизованную схему. В крупных территориально распределенных сетях применяются иерархические или смешанные схемы, в зависимости от наличия каналов доступа к сети Интернет.
В рассмотренных схемах обновления не конкретизирована структура источников. На практике встречаются следующие их типы:
Разница между этими типами источников заключается в том, насколько легко они могут быть автоматизированы и насколько они поддаются контролю через систему управления.
Так, для обновления внутреннего FTP- или HTTP-сервера, администраторам потребуется использовать дополнительные средства для автоматической загрузки обновлений и размещения их на серверах. То же касается и общей папки сети Microsoft.
В случае с источником на базе клиента вопрос с автоматической загрузкой отпадает, однако дальнейший контроль источника обновлений в этом случае обычно отсутствует.
Наконец, наиболее функциональными источниками обновлений являются специализированные приложения, входящие, как правило, в состав системы администрирования и позволяющие контролировать размещенные на них файлы. Такие источники принято называть серверами обновления.
В силу того, что и сервера обновлений и сервера управления часто подразумевают наличие иерархической структуры (с одной и той же целью - снижение нагрузки на сеть) эти приложения бывают объединены. Иными словами, сервер управления нередко выполняет также функции и сервера обновлений.
В вопросе обновления клиентов очень важна своевременность. Антивирусные базы должны доставляться в кратчайшие сроки после их выпуска. С другой стороны, как уже было показано выше, одновременное обновление большого количества клиентов может приводить если и не к перегрузке сети (если используется эффективная система источников обновления), то по крайней мере к снижению ее эффективности. Чтобы этого не происходило, обновление в различных группах часто разносят по времени при помощи планирования запуска задач. Дополнительно используется метод случайной задержки, когда запланированные на одно время задачи стартуют не синхронно, а выдерживают паузу случайной длины в рамках заданного интервала. Например, создается расписание запуска обновления в 13:00 со случайно задержкой в пределах 20 минут.
В то же время, при начале вирусной атаки или высокой вероятности возникновения эпидемии можно пренебречь временным снижением эффективности сети ради экстренного обновления. Таким образом, возникает необходимость в двух режимах обновления:
В системах, где сервера обновления отделены от серверов управления, проталкивание обычно реализуется путем посылки через систему управления на клиенты специального сигнала о необходимости обновиться.
Задача подсистемы диагностики - предоставить администратору антивирусной безопасности максимум информации о функционировании системы защиты для обеспечения принятия решений.
Как и в случае одиночного антивируса средства диагностики можно разделить на несколько классов:
Уведомления служат для информирования администратора антивирусной безопасности о событиях, которые возможно требуют безотлагательного вмешательства: например, об обнаружении вируса.
Организация системы уведомлений характеризуется в первую очередь тем, какие каналы доставки уведомлений поддерживаются. Наиболее характерными являются:
Второй аспект реализации системы уведомлений - связь с системой управления. Как правило, система управления одновременно выполняет и функции системы уведомлений, но в тех случаях, когда система управления является платной, производитель нередко предоставляет упрощенные средства для организации доставки уведомлений. В этом случае в сети создается отдельный сервер уведомлений, который принимает сигналы о событиях от клиентов и преобразует их в уведомления различных видов.
Журналы работы, которые ведутся на клиентских компьютерах, в случае большой сети для анализа практически непригодны. Поэтому возникает вопрос о централизованном сборе и хранении информации обо всех или только о наиболее важных событиях, т. е. о централизованных журналах.
С централизованными журналами тесно связаны средства генерации отчетов о работе сети. Эти отчеты позволяют оценить ситуацию по сети в целом, выявить наиболее проблемные участки, компьютеры, определить неявные проблемы и т.д.
Пример. В Kaspersky Administration Kit реализованы следующие типы сводных отчетов:
При создании отчета может запрашиваться информация от
Как правило, отчеты генерируются администратором антивирусной безопасности вручную по необходимости. Однако некоторые отчеты вполне целесообразно генерировать на регулярной основе автоматически: например, отчет о вирусной активности.
Так же как и локальное управление всеми клиентами вызывает чрезмерные затраты времени и усилий, так и локальная установка антивирусной защиты обычно требует слишком большого количества ресурсов обслуживающего персонала. По этой причине система управления, как правило, оснащается средствами для проведения удаленной установки.
На практике встречаются следующие способы удаленной установки, отличающиеся ограничениями на условия применения и степенью вовлеченности пользователя в процесс установки:
Из всех описанных методов только форсированная установка через RPC является интерактивной и позволяет непосредственно
после запуска выяснить, успешно она прошла или нет. Все остальные методы требуют ожидания действий пользователя -
запуска программы установки, входа в систему. Даже форсированный режим установки через
Учитывая ограничения каждого из методов, для организации внедрения обычно применяется следующая схема. Сперва выполнятся форсированная установка при помощи RPC, а затем - установка другими методами на оставшиеся компьютеры. После этого анализируется информация о результатах установки и на все оставшиеся незащищенными компьютеры антивирусное ПО и агенты устанавливаются вручную.
Пример. В Kaspersky Administration Kit применяются два способа установки:
При этом, если на компьютере уже установлен Агент администрирования, на него можно установить Антивирус Касперского форсированно, независимо от операционной системы клиента и от информации о реквизитах пользователя с правами администратора на удаленном компьютере - загрузка программы установки и ее запуск производятся непосредственно Агентом администрирования, для которого требуется только связь с Сервером администрирования.
Как видно из приведенного материала, третий уровень КСАЗ является наиболее сложным с точки зрения организации и функционирования. На нем применяется наибольшее количество разнообразных технологий, как непосредственно ориентированных на борьбу с вирусными угрозами, так и призванных обеспечить управление, обновление и диагностику антивирусных средств.
Основными отличительными особенностями этого уровня являются:
Наконец, третий уровень так или иначе присутствует в любой системе антивирусной защиты, даже когда речь идет о сети без шлюзов и почтовой системы.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.