클라우드 트래픽을 위한 적응형 '면역 시스템'을 구축한 방법
Source: Dev.to
최근에 나는 실시간 Nextcloud 인스턴스를 위한 자동 방어 시스템을 구축하는 과제를 맡게 되었다. 목표는 단순히 “악당”을 차단하는 것이 아니라 정상적인 하루가 어떤 모습인지 학습하고, 상황이 이상해지면 반응하는 시스템을 만드는 것이었다.
The Architecture: Under the Hood
이것은 진공 상태에서 실행되는 단순 스크립트가 아니다. 프로덕션 환경에서 동작하도록 실제 DevOps 아키텍처를 모방한 스택을 배포했다:
The Source: Docker에서 실행되는 Nextcloud 인스턴스.
The Proxy: JSON 접근 로그를 특정 경로에 기록하도록 구성된 Nginx.
The Bridge: Nginx(작성자)와 내 Python 데몬(읽기자) 사이에 공유되는 명명된 Docker 볼륨(HNG-nginx-logs).
The Brain: 실시간으로 이 로그들을 tail 하는 다중 모듈 Python 엔진.1. The Sliding Window: Beyond Simple Counters
대부분의 초보자는 매분 리셋되는 단순 정수 카운터를 사용한다. 이는 실수이다: 공격자가 한 분의 마지막 10초 안에 1,000개의 요청을 보낸다면, 카운터는 “피크”를 놓칠 수 있다.
나는 collections.deque를 이용한 시간 기반 슬라이딩 윈도우를 사용했다:
from collections import deque
import time
# Each IP has its own deque of timestamps
window = deque()
def process_request():
now = time.time()
window.append(now) # Add the new hit
# Eviction logic: keep only the last 60 seconds
while window and window[0] < now - 60:
window.popleft()Detection criteria (먼저 트리거되는 것이 이상 징후를 표시):
- Z‑score > 3.0 → 트래픽이 평균보다 3 표준편차 떨어져 있다.
- 5× Rule → 현재 속도가 기준 평균의 5배를 초과한다.
4. The “Zero‑Trust” Error Surge
공격자는 종종 404 Not Found(스캔) 또는 500 Internal Server Error(크래시)와 같은 오류를 남긴다.
엔진은 IP별 오류 비율을 추적한다. 만약 IP의 4xx/5xx 오류가 기준 오류 비율의 3배를 초과하면, 탐지 임계값을 Z‑score 3.0에서 1.5로 낮춰 의심의 여지를 없앤다.
5. Enforcement & The Lifecycle of a Ban
탐지는 행동이 없으면 무의미하다. 차단이 트리거되면 엔진은 직접 Linux 커널에 명령한다:
# Inject a DROP rule into iptables
iptables -I INPUT -s <IP_ADDRESS> -j DROP- Backoff schedule: 차단은 단계적으로 진행된다 — 10 분 → 30 분 → 2 시간 → 영구 차단.
- Alerting: Slack 알림이 10 초 이내에 전송되며, Z‑score, 현재 속도, 기준값이 포함된다.
6. Real‑Time Observability
실시간 메트릭 UI는 제어실 역할을 한다. Flask로 구축되고 3 초마다 새로 고침되며 전체 가시성을 제공한다:
Global req/s vs. learned effective mean/stddev.
Banned IPs with “time remaining” countdowns.
Top 10 source IPs and system health (CPU/Memory).Lessons Learned
가장 큰 교훈: DevOps는 단순히 유지보수가 아니라 관찰이다. 가장 어려운 부분은 아키텍처가 아니라 수학이었다. 나는 시스템이 성공적인 제품 출시와 실제 DDoS 공격을 구분할 수 있도록 임계값을 미세 조정하는 데 훨씬 더 많은 시간을 보냈다.
Real‑world quirk: 테스트 중에 내 Docker 게이트웨이(172.18.0.1)를 차단하게 되었다. Nginx가 Docker 브리지 내부 트래픽을 보았고, 엔진이 게이트웨이를 공격적인 공격자로 판단해 차단했다. 이로 인해 내부 CIDR 범위에 대한 보다 강력한 화이트리스트 전략을 수립해야 했으며, 최고의 수학도 특정 네트워크 현실에 기반해야 함을 증명했다.