1. 서론 — DMZ에는 보안 모니터링의 “사각지대”가 있다 #

클라우드 사업자나 호스팅 사업자에게 공개 웹 서버나 리버스 프록시와 같은 DMZ(비무장지대)의 서버는 가장 노출되기 쉬운 곳입니다.

이러한 장소에서도 syslog 전송으로 로그를 집약해오는 구성은 드물지 않습니다. 하지만 여기에 중요한 전제가 있습니다:

BASTION의 DMZ Agent는 이 “Agent 자체가 침해될 수도 있다”는 전제에 입각하여 설계되었습니다. 본 기사에서는 그 “Agent 비신뢰 모델”과 이를 뒷받침하는 검증 엔진의 설계를 해설합니다.

2. 왜 기존 EDR이나 SIEM Agent로는 불충분한가 #

EDR(Endpoint Detection & Response)이나 SIEM 제품의 Agent 기능으로도 엔드포인트의 이상 탐지는 가능합니다. 다만, 이들 제품의 대부분은 다음과 같은 전제에 서 있습니다:

1. Agent는 신뢰할 수 있다(=서버 측에서 발행한 서명된 바이너리이므로)
2. Agent에서 전송되는 이벤트는 정확하다(=Agent 내부에서 검증 완료되었으므로)
3. Agent가 조용하면 해당 서버는 안전하다(=이상이 있으면 Agent가 통지할 것이므로)

이러한 전제는 평시에는 유효하지만, 침해된 DMZ 서버에서는 모두 무너집니다:

1. 서명된 바이너리라도 root 권한을 탈취당하면 Agent 프로세스 자체를 변조할 수 있다
2. Agent 내부의 이벤트 검증 로직을 공격자가 파악하면 검증을 통과하는 “위조 이벤트”를 생성할 수 있다
3. Agent를 종료하고 다른 가짜 Agent를 실행하면 “정상적인 침묵”을 연출할 수 있다

BASTION은 이러한 허점을 모두 차단하는 설계입니다.

3. Agent 비신뢰 모델 — 3가지 책임 분리 #

BASTION의 Agent와 중앙 서버(AI-SLOG)의 관계는 다음 3가지 책임으로 명확히 분리되어 있습니다.

핵심은 “탐지”와 “검증”이 물리적으로 분리되어 있다는 것입니다. Agent가 “공격을 탐지했다”고 통지해 와도 AI-SLOG는 이를 그대로 믿지 않습니다. 반드시 별도 경로로 동일 서버에서 직접 수집한 원본 로그를 사용하여 독립적으로 검증합니다.

     DMZ 서버                         AI-SLOG (내부)
   ┌──────────────┐                ┌──────────────┐
   │  Agent       │── WebSocket ──→│ 수신         │
   │  ・로그 모니터링│    (이벤트)    │              │
   │  ・1차 탐지   │                │   ↓          │
   │              │                │ 검증 엔진    │←─ 원본 로그
   │  ・차단      │←── WebSocket ──│   ↓          │  (rsyslog 경유)
   │   실행만     │   (block 명령) │ 명령 전송    │
   └──────────────┘                └──────────────┘
   ↑                                ↑
   Agent가 거짓을 말해도            원본 로그와 대조하여
   차단 이상의 일은 할 수 없다      불일치 시 이벤트 폐기

4. 검증 엔진 — Agent 이벤트를 원본 로그로 대조한다 #

검증 엔진은 Agent로부터 도착한 이벤트가 “사실”인지 여부를 독립적으로 확인하는 구조입니다.

Agent로부터의 이벤트 예시(공격 탐지 통지):

{
  "agent_id": "dmz-web-01",
  "event_type": "vuln_scan_detected",
  "src_ip": "203.0.113.42",
  "target": "/.env",
  "timestamp": "2026-05-13T10:23:45+09:00",
  "evidence_lines": [
    "203.0.113.42 GET /.env HTTP/1.1 404",
    "203.0.113.42 GET /.git/config HTTP/1.1 404",
    "203.0.113.42 GET /wp-admin HTTP/1.1 404"
  ]
}

이 이벤트를 수신한 AI-SLOG는 다음 단계를 통해 검증합니다:

1. 원본 로그 획득: 해당 DMZ 서버의 Apache/Nginx 로그를 rsyslog 경유로 별도 수집 완료
2. 해당 타임스탬프 주변 검색: 이벤트의 timestamp ±30초 범위에서 동일 IP의 요청 검색
3. evidence_lines와의 대조: Agent가 언급한 3개 행이 실제 로그에 존재하는지 확인
4. 불일치 시 폐기: 1행이라도 일치하지 않으면, 이 이벤트는 「조작 가능성」으로 간주하여 폐기하고 경고 알림

Agent가 정직하게 작동한다면, evidence_lines는 실제 로그와 일치하므로 문제없이 검증을 통과합니다. Agent가 공격자에게 탈취당해 위조 이벤트를 전송하더라도, 원본 로그와의 대조를 통해 쉽게 차단할 수 있습니다.

중요한 것은, 원본 로그 취득 경로와 Agent 이벤트 경로가 완전히 분리되어 있다는 점입니다. rsyslog 경유 로그 전송은 Agent 프로세스와는 별개의 경로로 동작하며, Agent를 제어하게 된 공격자라도 내부측 rsyslog 수신을 변조할 수 없습니다.

5. Agent의 권한 설계 — 할 수 있는 것을 최소한으로 #

Agent 자체에 부여하는 권한도 극한까지 제한하고 있습니다.

특히 중요한 것은, 「차단 해제를 Agent가 할 수 없다」는 설계입니다. 공격자가 Agent를 제어하게 되더라도, 자신의 IP 차단을 해제하여 재침입할 수 없습니다.

그렇다면, 오탐으로 차단된 정상 사용자는 어떻게 해제되는가? 그것은 뒤에서 설명할 「24시간 자동 소멸」과 AI-SLOG 측에서의 수동 해제 명령 두 가지 경로로 대응합니다.

6. 하트비트 동결 — 정지 시 안전 장치 #

「Agent가 조용하면 안전하다」는 전제는 신뢰하지 않는다고 적었습니다. 그렇다면 실제로 Agent가 멈춰있는 상태를 BASTION은 어떻게 처리할까요?

각 Agent는 주기적으로 하트비트를 AI-SLOG에 전송합니다. 이것이 일정 시간 끊기면, BASTION은 다음과 같은 동작을 취합니다:

1. 해당 Agent로부터의 신규 이벤트를 전부 동결(처리하지 않고 폐기)
2. Slack으로 운영자에게 알림
3. Agent 재시작 + 하트비트 복구까지 이벤트 수신 중단

이것은 「Agent가 조용히 허위 정보를 계속 흘려보내는」공격 시나리오에 대한 대책입니다. 공격자가 하트비트만 계속 보내고 실제 로그 전송을 중단하는 수법도 고려할 수 있지만, 그 경우 별도 경로인 rsyslog 측에서 「로그가 갑자기 멈췄다」는 것을 감지할 수 있습니다.

즉, Agent의 상태를 판단하는 경로를 의도적으로 다원화했습니다.

7. 24시간 자동 소멸 — 차단의 영구화 방지 #

Agent가 실행하는 차단(ufw deny 등)은 반드시 24시간 후 자동 소멸되도록 설계되어 있습니다.

# Agent 측의 cron.hourly
/opt/bastion-agent/bastion-ufw-prune.sh
# → ufw의 코멘트에 내장된 타임스탬프에서 경과 시간 판정
# → 24시간을 초과한 엔트리는 ufw delete로 삭제
# → AI-SLOG 측의 해제 지시를 기다리지 않음 (Agent 로컬에서 자율 동작)

이 설계의 의도는 3가지입니다:

1. 오탐의 영구화 방지: 일시적 오탐으로 차단되더라도 방치하면 24시간 후 복구됨
2. Agent가 해제 권한을 가질 필요가 없음: 자동 소멸이 있으므로 Agent에게 「해제하는」권한을 줄 필요가 없음
3. AI-SLOG에 대한 의존성 감소: 소멸 처리는 Agent 로컬에서 완결. AI-SLOG가 다운되어도 문제없음

같은 공격자가 24시간 후 재접속하면, 당연히 다시 탐지되어 차단됩니다. 공격자가 활동을 계속하는 한, 차단도 지속적으로 발동됩니다.

8. 구현상의 판단 — 왜 WebSocket을 선택했는가 #

Agent와 AI-SLOG 간 통신은 WebSocket으로 구현하고 있습니다. 그 이유를 공유합니다.

특히 중요한 것은, 「Agent → AI-SLOG의 이벤트 전송」과 「AI-SLOG → Agent의 차단 명령」을 1개 커넥션으로 처리할 수 있다는 점입니다. 이를 통해 방화벽 너머 통신이 단순화되고 운영 부담이 대폭 줄어듭니다.

또한, HAProxy 등의 표준적인 리버스 프록시로 종단할 수 있어(HTTP와 동일한 시맨틱), TLS 종단이나 인증 연계도 기존 자산으로 완결됩니다.

9. 설계상의 트레이드오프와 제약 #

솔직히 말하면, 이 구조에도 제약이 있습니다.

1. 검증 엔진의 계산 비용: Agent로부터의 이벤트를 건별로 원본 로그와 대조하므로, 이벤트 양이 많으면 처리 시간이 증가한다. BASTION에서는 evidence_lines를 3~5행으로 제한하고, 검색 범위를 시간 윈도우로 좁혀 비용을 억제하고 있다.

2. 원본 로그 취득 경로의 이중화: 검증 엔진은 rsyslog 경유 로그를 사용하지만, rsyslog 자체가 멈추면 검증이 불가능해진다. 이에 대해서는 rsyslog 자체의 생존 감시를 별도로 구현하여, 중단 시 즉시 알림을 발생시키는 구성으로 대응하고 있다.

3. 검증 로직의 공개성: 검증 로직의 상세를 공개하면, 공격자가 이를 회피할 수 있는 위조 이벤트를 설계할 수 있다. 따라서 구체적인 검증 알고리즘은 비공개(본 문서에서는 개념만 설명).

4. 차단 해제의 운영 부담: Agent에게 해제 권한을 부여하지 않았기 때문에, 오차단을 즉시 해제하려면 AI-SLOG 측에서의 조작이 필요하다. 이는 「24시간 기다림 or 운영자가 수동 조작」의 양자택일이 된다.

이는 “침해된 Agent를 신뢰하지 않는다”는 대전제에서 도출되는 필연적인 트레이드오프입니다. 편의성과 보안의 균형을 명확히 보안 쪽으로 기울인 설계입니다.

10. 실제 운영에서의 효과 — 자사 환경에서의 실증 #

BASTION의 DMZ Agent는 현재 3대의 공개 웹 서버에서 프로덕션 환경에서 가동 중입니다. 본 기사 작성 시점에서:

• Agent rejected events: 0건(검증에서 폐기된 이벤트 없음 = 모두 정규 이벤트)
• Agent heartbeat anomalies: 0건(하트비트 단절 제로)
• 오탐지 건수: 0건(자사IP/거래처IP 차단 실적 제로)
• 24시간 자동 실효로 인한 의도하지 않은 해제: 0건(모두 예상대로 동작)

이는 “Agent가 성실하게 동작하고 있기 때문에 검증을 통과하고 있는” 상태이며, 침해가 발생했을 때 비로소 비신뢰 모델이 본령을 발휘하는 구조입니다. 평소에는 조용히 작동하며 문제 발생 시 운영자를 보호하는 설계입니다.

11. 향후 발전 #

Agent와 검증 엔진은 현 상태로도 충분히 실용 영역에 있지만, 더욱 개선할 여지가 있습니다.

• Go 언어 이식: 현재 Python으로 구현된 Agent를 Go로 이식하여 단일 바이너리로 배포 가능하게 만들기(고객 환경으로의 배포가 용이해짐)
• 서명 검증: Agent 바이너리의 서명과 기동 시 자기 검증 로직 추가
• 감사 로그의 블록체인화: 검증 엔진의 판정 이력을 변조 불가능한 형태로 기록하는 구조(고객 감사 대응)
• 다중 검증 경로: rsyslog뿐만 아니라 SNMP나 네트워크 플로우 정보도 활용한 다중 검증

이러한 기능들은 순차적으로 구현할 예정입니다.