DOCS · USER GUIDE

에이전트 격리와 아웃바운드 방화벽 운영

격리된 에이전트가 클라우드 메타데이터나 내부망에 함부로 접근하지 못하도록 VM에서 나가는 트래픽을 호스트 측에서 통제하는 아웃바운드 방화벽 운영 실습 가이드이다. 기본 모드는 클라우드 메타데이터를 통한 자격증명 탈취를 차단하고 더 엄격한 강화 모드에서는 내부 사설망 접근까지 막는다. 정책은 운영 중에도 재시작 없이 변경 적용이 가능하다.

최종 수정 · 2026년 7월 28일

1 · 개요

에이전트는 스스로 판단해 외부로 네트워크 요청을 보낸다. 그리고 바로 그 자율성이 보안 위험의 출발점이다. 프롬프트 인젝션에 조종당하거나 도구가 오작동하면 에이전트가 의도치 않은 목적지로 요청을 보낼 수 있기 때문이다. 그중 가장 위험한 표적은 클라우드 메타데이터 서비스이다. AWS·Google Cloud·Azure를 비롯한 주요 클라우드는 이 서비스를 링크로컬 주소 169.254.169.254에서 공통으로 제공하며 흔히 IMDS(Instance Metadata Service)라고 부른다. 이 주소에는 인스턴스에 부여된 클라우드 자격증명이 노출되어 있어 에이전트가 여기에 접근하면 계정 전체를 위협하는 키가 유출될 수 있다. 더욱이 공격자는 동일한 경로를 통해 사내 네트워크나 DB 같은 내부 자원으로 침투를 확대할 수 있기 때문에 각별한 주의가 필요하다.

Vantisso의 에이전트는 이미 Firecracker MicroVM 안에 격리되어 실행된다. 하지만 격리만으로는 이런 위협을 막을 수 없다. VM에는 여전히 바깥으로 나가는 네트워크 경로가 열려 있기 때문이다. 아웃바운드 방화벽은 바로 이 경로를 호스트 측에서 통제한다. VM이 아니라 호스트에서 동작하므로 VM 안의 에이전트는 이 방화벽을 우회하거나 끌 수 없고 메타데이터 차단(imds)은 별도 설정 없이 기본으로 항상 켜져 있도록 유지한다.

VM에서 나가는 두 갈래 경로

VM에서 나가는 트래픽은 두 갈래로 나뉜다. 하나는 호스트의 게이트웨이 IP(10.0.1.1)가 제공하는 서비스, 즉 컨트롤 플레인 API와 MCP 게이트웨이로 향하는 경로이고, 다른 하나는 외부로 라우팅되어 나가는 경로이다. 아웃바운드 방화벽은 커널의 FORWARD 체인에서 외부로 나가는 트래픽만 검사하고 필터링을 적용한다. 호스트 서비스로 향하는 트래픽은 INPUT 체인을 지나므로 여기서 설정된 방화벽의 영향을 전혀 받지 않는다. 그래서 에이전트 팀의 협업이나 MCP 도구 호출은 어떤 방화벽 정책을 적용하는지와 무관하게 항상 동일하게 동작할 수 있다.

방화벽 정책은 세 가지 모드로 제공되는데 off는 필터를 완전히 끄고, imds는 클라우드 메타데이터 대역만 차단하며(기본 설정), strict는 클라우드 메타데이터에 더해 모든 사설망과 루프백까지 차단한다. 환경 변수 VANTISSO_NET_EGRESS를 이용하여 설정하며 실행 중에도 API를 이용해 재시작 없이 바로 변경 적용이 가능하다.

2 · 기본 정책 모드

새로 설치한 Vantisso는 아웃바운드 방화벽 정책이 기본 모드인 imds로 설정되어 있다. 이 모드는 VM에서 링크로컬 대역 169.254.0.0/16으로 나가는 모든 라우팅 트래픽을 차단한다. 이 네트워크 대역에는 클라우드 메타데이터 주소 169.254.169.254가 포함되므로 자격증명 탈취 경로가 처음부터 막혀 있는 셈이다. 10.0.1.0/24 브리지에 연결된 VM 간의 통신은 링크로컬 주소를 쓸 일이 없으므로 이 대역 전체를 막아도 VM 상호 통신은 영향을 받지 않는다.

정책 적용 여부 확인

데몬 시작 시 자동 작성되는 로그 기록을 확인한다.

# daemon startup log
msg="vm egress policy configured" mode=imds chain=VANTISSO_EGRESS allow=[] applied=true

또는 컨트롤 플레인 API를 이용해서도 현재 적용된 정책을 조회할 수 있다.

curl -s http://localhost:3000/net/egress
# → {"mode":"imds","allow":[],"available":true,"applied":true,"modes":["off","imds","strict"]}

응답의 available은 정책을 적용·변경할 iptables가 호스트에 있는지를 나타내고 applied는 보고된 모드의 규칙이 실제로 모두 설치됐는지를 나타낸다. modes는 선택할 수 있는 정책 모드의 전체 목록(off·imds·strict)이다. 어떤 모드가 유효한지는 서버가 정하므로 Vantisso UI는 모드 선택 대상을 이 API 호출을 통해 받은 리스트를 기준으로 생성한다.

3 · 강화 정책 모드

IMDS 접근 차단만으로는 충분하지 않은 환경도 있다. 대표적으로 에이전트를 실행하는 호스트가 사내 네트워크, 내부 데이터베이스, 그 밖의 내부 서비스 같은 신뢰 경계 안쪽 시스템과 네트워크로 연결되어 있는 경우가 그에 해당한다. VM에서 나가는 트래픽은 이 호스트를 거쳐 라우팅되기 때문에 보안적으로 침해 당한 에이전트가 이 경로를 타고 내부 시스템까지 침투를 확대할 수 있다. 따라서 strict 강화 모드는 기본 모드의 IMDS 접근 차단에 더해 모든 사설망 대역과 루프백 접근까지도 차단한다.

strict는 아래 예시와 같이 환경 변수로 설정하거나 다음 섹션에서 다룰 실행 중 API 호출로 설정할 수 있다. 환경 변수는 데몬이 시작할 때 한 번만 반영되므로 만일 값을 변경하려면 데몬을 재시작해야 반영된다는 점에 유의할 것.

# systemd: add a drop-in, then restart the daemon.
#   under [Service]:  Environment=VANTISSO_NET_EGRESS=strict
sudo systemctl edit vantisso
sudo systemctl restart vantisso

4 · 예외 허용 리스트

strict 모드가 정작 필요한 내부 목적지까지 모두 막아 버리는 문제도 고려해야 한다. 예를 들어 에이전트가 사내의 특정 API나 아티팩트 저장소 하나만은 반드시 사용해야 한다면 그 대역만 예외로 열어 줄 수 있어야 하는 것이다. 이를 위해서 Vantisso는 VANTISSO_NET_EGRESS_ALLOW 설정에 쉼표로 구분한 CIDR 목록을 지정해서 차단 예외 허용을 지원한다.

# strict mode only. Add these to the daemon's systemd unit ([Service] section),
# then restart the daemon:
#   Environment=VANTISSO_NET_EGRESS=strict
#   Environment=VANTISSO_NET_EGRESS_ALLOW=10.5.0.0/16,192.168.9.0/24

허용목록의 각 대역은 차단 규칙보다 앞에 위치해서 우선하므로 명시적으로 허용된 목적지는 뒤따르는 차단 필터 조건과 무관하게 통과된다. 이 설정은 strict 모드에서만 의미가 있다는 것에 유의할 것. imds나 off 모드에서는 이 허용 리스트가 제공되더라도 무시된다.

• 잘못된 CIDR 배제 — 파싱할 수 없는 항목만 경고와 함께 무시되며 나머지 유효한 항목은 그대로 적용된다.
• IMDS 대역 허용 요청은 원천 거부 — 169.254.0.0/16을 다시 여는 CIDR(포괄적인 0.0.0.0/0 포함)은 IMDS 차단을 무력화하므로 예외 허용을 요청하더라도 기각된다.

5 · 무중단 정책 변경

방화벽 정책을 테스트해 보거나 보안 사고 발생 시 대응할 때는 데몬을 재시작하지 않고 정책 변경을 즉시 적용할 수 있어야 한다. Vantisso가 제공하는 관리자(operator) 전용 API인 GET/PUT /net/egress를 이용해서 실행 중인 데몬의 아웃바운드 방화벽 정책을 재시작 없이 조회하고 변경할 수 있다.

# Switch to strict, allowing one internal target, without a restart:
curl -s -X PUT http://localhost:3000/net/egress \
  -H 'Content-Type: application/json' \
  -d '{"mode":"strict","allow":["10.5.0.0/16"]}'
# → {"mode":"strict","allow":["10.5.0.0/16"],"available":true,"applied":true,"modes":["off","imds","strict"]}

정책 설정 변경 시도할 때 모드가 off·imds·strict 중 하나가 아니거나, CIDR를 파싱할 수 없거나, CIDR가 클라우드 메타데이터 대역과 겹치거나, off 모드가 아닌데 iptables가 없는 등의 이유로 검증에 실패하면 400을 반환하고 기존 정책은 그대로 유지된다. 잘못된 요청 때문에 방화벽이 열린 채로 방치되는 문제는 발생하지 않게 설계되어 있다.

off로 바꾸면 FORWARD에서 방화벽으로 향하던 점프가 제거되어 오버헤드가 전혀 남지 않는다. 다만 이는 v0.8.8 이전의 무제한 동작으로 되돌아가는 것이므로, IMDS 노출을 감수할 분명한 이유가 있을 때만 사용한다.

6 · IP 주소 위조 방지

아웃바운드 방화벽과 MCP 게이트웨이는 모두 요청을 보낸 에이전트 VM의 소스 IP로 누구인지 식별한다. 이때 이 신원 식별이 유효하려면 한 에이전트 VM이 다른 에이전트 VM의 IP 주소를 이용해서 사칭하지 못하게 막아야 한다. 디폴트로 활성화되는 VANTISSO_NET_ANTISPOOF 기능은 각 VM의 브리지 포트를 배정된 MAC과 IP 주소에 L2 레벨에서 고정으로 바인딩해서 IP 주소 사칭을 원천적으로 차단한다.

동작 방식은 간단하다. 각 TAP 인터페이스에 대해 소스 MAC이 일치할 때만 ARP를 허용하고(이게 없으면 게스트가 게이트웨이를 찾지 못해 연결 자체가 끊김), 소스 MAC과 소스 IP 둘 다 일치할 때만 IPv4 트래픽을 허용하며, 그 외에는 위조로 간주해 모두 폐기한다. 이 규칙들은 ebtables의 전용 체인(VANTISSO_AS)에 저장되고 각 포트에만 적용되므로 다른 VM이나 호스트 트래픽에 미치는 간섭이나 영향은 없다.

7 · 운영과 트러블슈팅

변경 사항이 반영되는 시점

점검 순서

1. API 호출로 현재 정책 확인: GET /net/egress에서 mode가 의도한 값이고 applied가 true인지 확인한다.
2. 시작 로그의 설정 출력 확인: vm egress policy configured 라인에 mode·applied, 그리고 per-TAP anti-spoof enabled 내용이 포함되어 있는지 확인한다.
3. 실제 적용 규칙 확인: 호스트에서 sudo iptables -t filter -nL VANTISSO_EGRESS 명령 실행으로 설치된 DROP/RETURN 규칙을 확인하고 sudo ebtables -t filter -L VANTISSO_AS 명령 실행으로 anti-spoof 내용을 확인한다.