Тестовый файл EICAR использовался для функционального тестирования антивирусной системы. В настоящее время почти каждая антивирусная система помечает EICAR как «тестовый» вирус. Для получения дополнительной информации об этом историческом тестовом вирусе щелкните Вот.
В настоящее время EICAR тестовый файл подходит только для тестирования присутствие решения AV, но он не проверяет файл движка или файл DAT актуальность. Другими словами, зачем проводить функциональный тест системы, в которой могут быть файлы DAT старше 10 лет. Поскольку количество вирусов выпускается ежедневно, сигнатура EICAR теряет ценность как инструмент тестирования.
При этом я думаю, что EICAR необходимо обновить / изменить, чтобы он был эффективным тестом, работающим в сочетании с решением для управления AV.
Некоторые пользователи serverfault ответили на более раннюю версию этого вопроса.
Ответчикам: Пожалуйста, сосредоточьтесь на главном:
Этот пересмотренный вопрос касается тестирование функциональность AV-системы.
Пожалуйста, не отвечайте решениями для управления, поскольку они не проверяют, что развернуто и что используется в полевых условиях. Управленческие решения сообщают, и это может быть в той или иной мере некорректно, например: иногда машина не может быть включена в обычное администрирование AV из-за ошибки оператора. Иногда AV управляется другой компанией или группой. Независимо от того, как вы относитесь к «управлению», это не учитывается при «тестировании» после развертывания. ИМХО. Этот вопрос касается тестирования в реальном мире без использования живых вирусов ... что является целью оригинального 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 только в том случае, если и сигнатура, или файл ядра равны или новее, чем дата начала действия. Также есть пароль, который защитит использование EICAR для системного администратора.
Если у вас есть опыт работы с TDD "Test Driven Design" для программного обеспечения, вы можете понять, что все, что я делаю, - это применяю принципы TDD к своей инфраструктуре.
Исходя из вашего опыта и контактов, как я могу реализовать эту идею?
То, что вам нужно (в контексте системы, не находящейся под вашим контролем), вряд ли когда-либо станет жизнеспособным просто потому, что это откроет еще одну уязвимость против самого программного обеспечения AV. то есть стало бы возможным зондировать систему, чтобы определить, способна ли она обнаруживать последний вирус. Если тест не пройден, вирус может быть отправлен незамеченным, не вызывая чрезмерных подозрений.
Что касается теста EICAR, то от него пора отказаться. Большинство антивирусных программ, которые я видел, либо жестко запрограммированы для его обнаружения, либо имеют подпись, что делает "тест" абсолютно бесполезным.
Файл EICAR проверяет только наличие AV, он не используется для проверки актуальности. Я считаю, что самому файлу EICAR уже более десяти лет, и поэтому он «поддерживается» всем.
Решение проблемы актуальности - это то, что все уровень предприятия У AV-продуктов есть решения для. В McAfee есть ePolicy Orchestrator. Symantec имеет System Center. В Microsoft ForeFront также есть консоль отчетности. Все они полагаются на сами антивирусные движки, чтобы сообщать на базу данных о том, что они в настоящее время используют в отношении как определений, так и движков. Более сложные продукты Desktop Inventory также могут предоставлять такие услуги.
Сам файл EICAR не проверяет наличие антивируса. Его просто использовать в качестве инструмента для тестирования (так что вы не знаете, как тестировать живые вирусы).
Существует множество способов контролировать и управлять обновлениями ядра и определений (я предполагаю, что вы используете McAfee, поскольку используете терминологию DAT)
Для каждого корпоративного антивируса доступна центральная консоль управления. Для McAffee попробуйте ePolicy Orchestrator (или как там называется текущее программное обеспечение SMB).
Я сомневаюсь, что отрасль собирается ежемесячно выпускать для вас новый файл EICAR. Это пустая трата времени и ресурсов. Решением вашей проблемы является покупка централизованного антивирусного ПО, такого как Symantec или Sophos, чтобы вы могли создать отчет и увидеть, какие клиенты нуждаются в обновлении.
Ответы выше указывают вам на централизованную консоль управления. Обычно это лучший ответ. Я понимаю вашу точку зрения о пассивном мониторинге, но я думаю, что вы немного не в своей тарелке. Центральные решения, с которыми я работал, не предполагают, что клиент получил обновление; они обновляют информацию в консоли тем, что клиент сообщает о дате / версии определения. Это так же точно, как если бы вы сами задали вопрос клиентской машине каким-либо другим способом. Фактически, худшее, что может случиться, - это поломка консоли, по-прежнему отправляющая обновленные DAT-файлы, но потеря обратной связи от клиента и отображение более ранней даты определения в консоли, чем у клиента на самом деле.
Однако, если вы не можете этого сделать (машины не будут оставаться под вашим контролем после развертывания и т. Д.), Вы можете попытаться выяснить, где программное обеспечение AV, которое вы используете, хранит эту информацию.
Когда мне приходилось делать это для SAV CE, вы могли запросить реестр клиентской машины, чтобы найти текущую версию определения AV, и, я думаю, дату. Для файлов McAfee DAT вы можете узнать, в каком каталоге хранятся файлы DAT, и получить сценарий, который ищет дату создания или последнего изменения самого нового файла DAT в этом каталоге.
Вы можете отправить эту идею в http://www.eicar.org/contact/
Если я понимаю, что вы просите, это сторонний инструмент, чтобы проверить, делает ли сторонний инструмент то, что они говорят? Если да, то почему вы предлагаете полагаться на сторонний инструмент, если вы до сих пор не могли полагаться на сторонние инструменты? о_О
Я не уверен, что мы можем помочь вам «сделать это возможным». Я не могу «заставить» Эйкара делать что-нибудь больше, чем я могу «заставить» тебя что-то сделать для меня. Я обнаружил, что когда я не могу добиться чего-либо с помощью надежной третьей стороны, я делаю это сам или не делаю вообще.
Если вы хотите проверить безопасность электронной почты, вы можете попробовать Безопасность электронной почты GFIs test, хотя я считаю, что он немного устарел.
Отредактировано для добавления:
Вы продолжаете утверждать, что «EICAR нуждается в обновлении, чтобы быть актуальным». Нет, это не так. Их тестовый файл AV имеет только одну цель - «создать файл, который их (и многие другие) продукты« обнаруживают », как будто это вирус». Вот и все. В этом отношении они остаются актуальными.
Если у вас есть сторонний поставщик, который не соответствует вашим ожиданиям, вы прибегаете к соглашению об уровне обслуживания. В вашем соглашении об уровне обслуживания должно быть указано, что они делают для поддержки текущего антивирусного ПО и как они собираются доказать это вам, чтобы вы остались довольны. Ничто из того, что ваша другая сторона не делает (в этом случае вы просите EICAR сделать еще один тестовый файл, чтобы проверить, обновлен ли ваш AV), не компенсирует тот факт, что у вас нет этого прописано в SLA.