Тестовый файл EICAR использовался для функционального тестирования антивирусной системы. В его нынешнем виде почти каждая антивирусная система помечает EICAR как «тестовый» вирус. Для получения дополнительной информации об этом историческом тестовом вирусе щелкнитездесь.
В настоящее времяЭИКАРТестовый файл хорош только для тестированияприсутствиеAV-решения, но оно не проверяет наличие файла движка или файла DATактуальность. Другими словами, зачем проводить функциональный тест системы, в которой могут быть файлы DAT, которым больше 10 лет. С учетом количества вирусов, выпускаемых ежедневно, с течением времени сигнатура EICAR теряет ценность как инструмент тестирования.
При этом я считаю, что EICAR необходимо обновить/модифицировать, чтобы сделать его эффективным тестом, работающим совместно с решением по управлению AV.
Некоторые люди на serverfault ответили на более раннюю версию этого вопроса.
Для ответивших:Пожалуйста, сосредоточьтесь на следующем:
Этот пересмотренный вопрос касается тестирование функциональность AV-системы.
Пожалуйста, не отвечайте решениями по управлению, поскольку они не тестируют то, что развернуто и в полевых условиях. Отчеты по решениям по управлению могут быть некорректны тем или иным образом, например: иногда машина может не быть включена в рутинное администрирование AV из-за ошибки оператора. Иногда AV управляется другой компанией или группой. Независимо от того, какова ваша позиция по «управлению», это не учитывается при «тестировании» после развертывания IMHO. Этот вопрос касается тестирования в реальных условиях, без использования живых вирусов... что и является целью оригинального EICAR.
Я предлагаю новый формат файла EICAR с добавлением XML-блока, который будет вызывать условную реакцию антивирусного движка.
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-EXTENDED-ANTIVIRUS-TEST-FILE!$H+H*
<?xml version="1.0"?>
<engine-valid-from>2010-1-1Z</engine-valid-from>
<signature-valid-from>2010-1-1Z</signature-valid-from>
<authkey>MyTestKeyHere</authkey>
В этом примере антивирусный движок будет предупреждать только о файле EICAR, если и сигнатура, и файл движка будут равны или новее даты valid-from. Также есть пароль, который защитит использование EICAR от системного администратора.
Если у вас есть опыт в области «Test Driven Design» (TDD) для программного обеспечения, вы, возможно, поняли, что все, что я делаю, — это применяю принципы TDD к своей инфраструктуре.
Как, основываясь на вашем опыте и контактах, я могу воплотить эту идею в жизнь?
решение1
То, что вы ищете (в контексте системы, которая не находится под вашим контролем), вряд ли когда-либо станет жизнеспособным просто потому, что это откроет еще одну уязвимость для самого антивирусного ПО. То есть станет возможным проверить систему, чтобы определить, способна ли она обнаружить новейший вирус. Если тест не пройден, вирус может быть передан незамеченным, не вызывая ненужных подозрений.
Что касается теста EICAR, то от него давно пора отказаться. Большинство антивирусного ПО, которое я видел, либо жестко закодировано для его обнаружения, либо имеет для него сигнатуру, что делает этот "тест" абсолютно бесполезным.
решение2
Я сомневаюсь, что отрасль будет ежемесячно создавать для вас новый файл EICAR. Это пустая трата времени и ресурсов. Решение вашей проблемы — покупка централизованного антивируса вроде Symantec или Sophos, чтобы вы могли запустить отчет и увидеть, какие клиенты нуждаются в обновлении.
решение3
Файл EICAR сам по себе не проверяет наличие антивируса. Он просто используется как инструмент для целей тестирования (так что вы не знаете, что тестирование против живых вирусов).
Существует множество способов мониторинга и управления обновлениями движка и определений (предполагаю, что вы используете McAfee, поскольку вы используете терминологию DAT)
У каждого корпоративного антивируса есть центральная консоль управления. Для McAffee проверьте ePolicy Orchestrator (или как там называется текущее ПО SMB).
решение4
Ответы выше указывают вам на централизованную консоль управления. Обычно это лучший ответ. Я понимаю вашу точку зрения о пассивном мониторинге, но я думаю, что вы немного не в теме. Централизованные решения, с которыми я работал, не предполагают, что клиент получил обновление; они обновляют информацию в консоли в соответствии с тем, что клиент говорит о своей дате/версии определения. Это точно так же точно, как если бы вы сами запрашивали клиентскую машину каким-то другим способом. Фактически, худшее, что может произойти, — это сбой в работе консоли, при котором все еще отправляются обновленные DAT-файлы, но теряется обратная связь от клиента, и в консоли отображается более старая дата определения, чем на самом деле у клиента.
Однако если вы не можете этого сделать (машины не останутся под вашим контролем после развертывания и т. д.), то вы можете попытаться выяснить, где используемое вами антивирусное программное обеспечение хранит эту информацию.
Когда мне пришлось сделать это для SAV CE, вы могли запросить реестр клиентской машины, чтобы найти текущую версию определения AV, и, я думаю, также дату. Для файлов McAfee DAT вы могли бы узнать, где находится каталог, в котором хранятся DAT, и иметь скрипт, который ищет дату создания или последнего изменения самого нового файла DAT в этом каталоге.