donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
main
llm-wiki/raw/company-tech-blogs/file-clamav-icap-gateway-scan.md
T

10 KiB
Raw Permalink Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, status, confidence, created, last_reviewed
title source_type url archive_url related_branches related_projects tags status confidence created last_reviewed
ClamAV / ICAP — Gateway antivirus scan vs in-app scan company-tech-blog https://docs.clamav.net/manual/Usage/Scanning.html
feature-file-resource-handling-contract
ca-skeleton-operational-contract
file
clamav
antivirus
icap
gateway-scan
ca-skeleton
raw medium 2026-05-22 2026-05-27

ClamAV / ICAP — Gateway antivirus scan vs in-app scan

Layer: raw/company-tech-blogs/ — ClamAV official docs + RFC 3507 (ICAP) + AWS GuardDuty Malware Protection docs 의 verbatim 발췌. file resource handling 의 scan position 결정 근거 묶음. 주의: 본 파일은 (a) ClamAV official docs (b) RFC 3507 (official-standard) (c) AWS GuardDuty docs (official-vendor-doc) 가 섞여 있어 source_type: company-tech-blog 는 묶음 카테고리로서 보수적 분류. 개별 claim 의 strength 는 출처별로 구분.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-file-resource-handling-contract antivirus scan 의 default position = gateway 선택 근거 (ICAP 표준 + ClamAV daemon 운영 모델 + 대안 비교: in-app / post-upload async / cloud-native)
raw/project-notes/ca-skeleton-operational-contract §18. Control Plane Contract — file resource handling 의 scan position 결정 reference

컨텍스트 / 왜 저장했는지

ca-tmpl 결정: "antivirus default = scan position = gateway". 이 결정의 외부 근거가 필요. 대안(in-app, post-upload async, cloud-native scan)과의 비교 + ICAP가 gateway scan을 어떻게 표준화하는지.

출처 / Source

핵심 인용 / Key quotes (verbatim)

(ClamAV — docs.clamav.net/manual/Usage/Scanning.html)

[§clamscan vs clamdscan] "Unlike clamdscan, clamscan does not require a running clamd instance to function."

[§On-Access Scanning] "On-Access Scanning is a form of real-time protection that uses ClamD to scan files when they're accessed."

(RFC 3507 — ICAP)

[§1. Introduction] "ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services."

[§Abstract] "ICAP is, in essence, a lightweight protocol for executing a 'remote procedure call' on HTTP messages."

[§1. Introduction (examples)] "check the executable for viruses before accepting it into its cache"

[§3.2 Response modification] "The response modification method is intended for post-processing performed on an HTTP response before it is delivered to a client."

[§4.5] "Virus-checkers can certify a large fraction of files as 'clean'" + "Content filters can use Preview to decide if an HTTP entity needs to be inspected"

(AWS GuardDuty Malware Protection — docs.aws.amazon.com/guardduty/latest/ug/malware-protection.html)

[§Malware Protection for EC2] "Malware Protection for EC2 helps you detect the potential presence of malware by scanning the Amazon Elastic Block Store (Amazon EBS) volumes that are attached to Amazon Elastic Compute Cloud (Amazon EC2) instances and container workloads running on Amazon EC2."

[§GuardDuty-initiated scan] "Whenever GuardDuty generates one of the Findings that invoke GuardDuty-initiated malware scan, a malware scan initiates automatically only once every 24 hours."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
CLAMAV-ICAP-C1 clamscan 은 daemon 비의존 일회성 scan, clamdscan 은 clamd 데몬을 사용하며 On-Access Scanning 은 clamd 기반 real-time 보호 [§clamscan vs clamdscan] "Unlike clamdscan, clamscan does not require a running clamd instance to function." + [§On-Access Scanning] "On-Access Scanning is a form of real-time protection that uses ClamD to scan files when they're accessed." official-vendor-doc ClamAV 운영 모델 선택 — 일회성 vs 데몬 기반 메모의 "ICAP integrations and mail/web gateways for sustained throughput" 인용은 본 페이지에서 verbatim 미확인 — 별도 페이지 출처 필요 (현재 인용 부재)
CLAMAV-ICAP-C2 ICAP 는 HTTP 서비스에 대한 object-based content vectoring 프로토콜이며, HTTP 메시지에 대한 lightweight RPC 성격 [§1. Introduction] "ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services." + [§Abstract] "ICAP is, in essence, a lightweight protocol for executing a 'remote procedure call' on HTTP messages." official-standard HTTP gateway 단계에서 외부 adaptation service 호출 표준 ICAP 가 HTTPS 종단 (E2E TLS) 환경에서 동작한다는 뜻은 아님 — 종단 termination 필요
CLAMAV-ICAP-C3 ICAP 의 적용 예시에 바이러스 검사 / content filter / 광고 삽입 / 언어 변환이 포함되며, response modification 은 client 전달 전 후처리 단계로 정의 [§1. Introduction] "check the executable for viruses before accepting it into its cache" + [§3.2 Response modification] "The response modification method is intended for post-processing performed on an HTTP response before it is delivered to a client." + [§4.5] "Virus-checkers can certify a large fraction of files as 'clean'" official-standard gateway 단계에서 virus scan / content filter 적용 메모의 "The most common ICAP services include: virus scanning, content filtering, ad insertion, language translation." 는 verbatim 한 줄로는 RFC 본문에서 확인 안 됨 — does not prove 처리
CLAMAV-ICAP-C4 AWS GuardDuty Malware Protection for EC2 는 EC2 인스턴스에 attached 된 EBS 볼륨과 EC2 컨테이너 워크로드를 scan, GuardDuty-initiated scan 은 24시간당 1회 자동 시작 [§Malware Protection for EC2] "Malware Protection for EC2 helps you detect the potential presence of malware by scanning the Amazon Elastic Block Store (Amazon EBS) volumes that are attached to Amazon Elastic Compute Cloud (Amazon EC2) instances and container workloads running on Amazon EC2." + [§GuardDuty-initiated scan] "a malware scan initiates automatically only once every 24 hours" official-vendor-doc AWS 환경에서 EBS/EC2 malware scan 옵션 본 페이지는 "GuardDuty Malware Protection for S3" 의 직접 인용 없음 — S3 객체 자동 scan 주장은 본 인용으로 보장 안 됨 (별도 S3 페이지 확인 필요)
CLAMAV-ICAP-C5 (부재) "GuardDuty Malware Protection for S3 scans newly uploaded objects in selected buckets" 문구는 본 페이지 인용 범위에 없음 (부재 자체가 claim) needs-confirmation S3 객체 post-upload async scan 옵션 AWS 가 S3 scan 기능을 제공한다는 일반 사실 자체는 별도 페이지에 존재할 수 있으나, 본 인용으로는 미증명

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • CLAMAV-ICAP-C1: ClamAV 의 clamscan/clamdscan/On-Access 차이 (운영 모델 선택의 기반)
    • CLAMAV-ICAP-C2: ICAP 가 HTTP gateway 표준이라는 official-standard 근거
    • CLAMAV-ICAP-C3: ICAP 의 virus scan / response modification 적용 예시
    • CLAMAV-ICAP-C4: AWS GuardDuty 가 EBS/EC2 malware scan 을 제공한다는 vendor 근거
  • 이 자료가 증명하지 않는 것:
    • CLAMAV-ICAP-C5: GuardDuty Malware Protection for S3 의 정확한 동작
    • ICAP gateway scan 이 모든 상황에서 in-app scan 보다 우수하다는 일반 결론
    • large file (>100MB) 에서 ICAP 가 timeout 된다는 정량 수치
    • ca-tmpl 의 "gateway scan" 선택이 다른 결정보다 우수하다는 일반 결론 (대안 비교의 한 입력일 뿐)
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • HTTPS termination 위치 (gateway vs app) — ICAP 적용 가능성의 핵심 전제
    • ClamAV signature DB 갱신 주기 / 운영 책임 주체 (gateway team vs app team)
    • large file streaming 시 ICAP server 메모리/timeout 한계 (별도 c-icap docs 확인 필요)

메모 / Notes (내 프로젝트 해석)

검증되지 않은 내 추론은 여기에 두지 말 것 — wiki source-summary 단계에서.

  • ca-tmpl과의 매핑:
    • gateway scan (ca-tmpl 결정): ICAP 기반이 표준. Squid/NGINX/F5 등 reverse proxy 앞단에서 ClamAV가 byte stream을 in-line scan. 단점: latency 추가(파일 크기 비례), gateway 단일 장애점.
    • in-app scan (대안): Spring 안에서 ClamAV daemon에 TCP INSTREAM command 전송. 장점: traffic이 app까지는 도달하나 storage 도달 전 차단. 단점: app instance에 daemon dependency.
    • post-upload async (대안 2): S3 → Lambda(ClamAV layer) 또는 GuardDuty Malware Protection for S3. 장점: app/gateway 부담 0. 단점: scan 완료 전 객체가 bucket에 존재 → quarantine bucket 분리 필요.
  • ca-tmpl의 "default = gateway" 선택 이유 (재구성):
    • app instance scaling과 무관하게 throughput 일정.
    • in-app daemon dependency 회피 (skeleton 단계에서 ClamAV 운영 책임을 app team이 지지 않음).
  • ICAP의 약점:
    • HTTPS termination이 gateway에서 일어나야 함 (E2E TLS 환경에서는 적용 어려움).
    • large file (>100MB) scan 시 connection timeout 위험.
  • ca-tmpl이 명시한 "활성화 시 별도 worker로 분리"는 RFC 3507의 ICAP server-side 분리 모델과 호환.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink