EICAR 테스트 파일은 바이러스 백신 시스템의 기능을 테스트하는 데 사용되었습니다. 오늘날 거의 모든 AV 시스템은 EICAR를 "테스트" 바이러스로 표시합니다. 이 역사적인 테스트 바이러스에 대한 자세한 내용을 보려면 다음을 클릭하십시오.여기.
현재EICAR테스트 파일은 테스트용으로만 적합합니다.있음AV 솔루션이지만 엔진 파일이나 DAT 파일을 확인하지 않습니다.최신성. 즉, 10년이 넘은 DAT 파일이 있을 수 있는 시스템의 기능 테스트를 수행하는 이유는 무엇입니까? 시간이 지남에 따라 매일 출시되는 바이러스의 양으로 인해 EICAR 서명은 테스트 도구로서의 가치를 잃습니다.
즉, AV 관리 솔루션과 함께 작동하는 효과적인 테스트가 되려면 EICAR을 업데이트/수정해야 한다고 생각합니다.
serverfault의 일부 사람들은 이 질문의 이전 개정판에 응답했습니다.
답변자에게:다음 사항에 집중하세요.
이 수정된 질문은 다음과 같습니다. 테스트 AV 시스템의 기능.
관리 솔루션은 배포된 내용과 현장에서 테스트하지 않으므로 대응하지 마십시오. 관리 솔루션은 어떤 방식으로든 결함이 있을 수 있다고 보고합니다. 예를 들어 운영자 오류로 인해 기계가 일상적인 AV 관리에 포함되지 않을 수 있습니다. 때로는 AV가 다른 회사나 그룹에서 관리되는 경우도 있습니다. '관리'에 대한 귀하의 입장이 무엇이든 이는 배포 후 "테스트" IMHO에서는 포함되지 않습니다. 이 질문은 실제 바이러스를 사용하지 않고 실제 테스트에 관한 것입니다. 이는 원래 EICAR의 의도입니다.
저는 조건에 따라 바이러스 백신 엔진이 응답하도록 하는 XML blob이 첨부된 새로운 EICAR 파일 형식을 제안합니다.
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에 대한 배경 지식이 있다면 내가 하는 일은 TDD의 원칙을 내 인프라에 적용하는 것뿐이라는 것을 알 수 있습니다.
당신의 경험과 접촉을 바탕으로 이 아이디어를 어떻게 실현할 수 있습니까?
답변1
귀하가 추구하는 것(귀하의 통제를 받지 않는 시스템의 맥락에서)은 단순히 AV 소프트웨어 자체에 대한 또 다른 취약점을 야기할 수 있기 때문에 실행 가능하지 않을 것입니다. 즉, 최신 바이러스를 탐지할 수 있는지 여부를 결정하기 위해 시스템을 조사하는 것이 가능해집니다. 테스트가 실패하면 과도한 의심을 불러일으키지 않고 바이러스가 감지되지 않은 채 전송될 수 있습니다.
EICAR 테스트는 이제 폐기될 때가 됐다. 내가 본 대부분의 AV 소프트웨어는 이를 감지하도록 하드 코딩되었거나 서명이 있어서 "테스트"가 전혀 쓸모가 없게 되었습니다.
답변2
업계에서 매달 새로운 EICAR 파일을 만들지는 의문입니다. 시간과 자원 낭비입니다. 문제에 대한 해결책은 보고서를 실행하고 업데이트가 필요한 클라이언트를 확인할 수 있도록 Symantec 또는 Sophos와 같은 중앙 집중식 AV를 구입하는 것입니다.
답변3
EICAR 파일 자체는 바이러스 백신 존재 여부를 테스트하지 않습니다. 이는 테스트 목적의 도구로 사용하기 쉽습니다(따라서 라이브 바이러스에 대한 테스트를 알 수 없습니다).
엔진 및 정의 업데이트를 모니터링하고 관리하는 방법은 많습니다(DAT 용어를 사용하고 있으므로 McAfee를 사용한다고 가정합니다).
모든 기업용 바이러스 백신에는 중앙 관리 콘솔이 있습니다. McAffee의 경우 ePolicy Orchestrator(또는 현재 SMB 소프트웨어라고 불리는 모든 소프트웨어)를 확인하세요.
답변4
위의 답변은 중앙 집중식 관리 콘솔을 가리키는 것입니다. 일반적으로 이것이 가장 좋은 대답입니다. 수동적 모니터링에 대한 귀하의 주장은 이해하지만 귀하의 근거가 약간 벗어난 것 같습니다. 제가 작업한 중앙 솔루션은 클라이언트가 업데이트를 받았다고 가정하지 않습니다. 클라이언트가 말하는 정의 날짜/버전으로 콘솔의 정보를 업데이트합니다. 이는 다른 방식으로 클라이언트 시스템에 직접 요청하는 것만큼 정확합니다. 실제로 발생할 수 있는 최악의 상황은 업데이트된 DAT를 계속 전송하지만 클라이언트로부터의 반환 통신이 끊어지고 클라이언트가 실제로 가지고 있는 것보다 더 오래된 정의 날짜가 콘솔에 표시되는 콘솔의 고장입니다.
그러나 그렇게 할 수 없는 경우(배포 후 시스템을 제어할 수 없는 경우 등) 사용하는 AV 소프트웨어가 해당 정보를 보관하는 위치를 찾아볼 수 있습니다.
SAV CE에 대해 이 작업을 수행해야 할 때 클라이언트 시스템의 레지스트리를 쿼리하여 현재 AV 정의 버전을 찾을 수 있었고 날짜도 마찬가지라고 생각합니다. McAfee DAT 파일의 경우 DAT가 보관된 디렉터리의 위치를 확인하고 해당 디렉터리에서 최신 DAT 파일의 생성 날짜 또는 마지막 수정 날짜를 찾는 스크립트를 가질 수 있습니다.