본문으로 건너뛰기

안동민 개발노트

본문 시작

네트워크 보안 위협과 방어

MITM과 계층별 DDoS 위협을 이해하고 TLS·방화벽·ACL·WAF·관측을 조합한 다층 방어 전략을 세웁니다.

암호화와 인증서가 통신의 기밀성과 무결성을 보호한다면, 이 절에서는 네트워크와 애플리케이션을 노리는 대표 공격과 방어 전략을 살펴보겠습니다.

보안 방어는 보통 한 장비나 한 헤더로 끝나지 않고, 예방, 탐지, 완화, 복구를 계층별로 조합해야 합니다.


중간자 공격(MITM)

MITM(Man-In-The-Middle)은 통신하는 두 당사자 사이에 공격자가 끼어들어 트래픽을 도청하거나 변조하려는 공격입니다.

같은 Wi-Fi, 악성 프록시, DNS/ARP 조작, 위조 인증서 설치 같은 경로로 시도될 수 있습니다.

MITM은 경로 장악과 신뢰 우회를 함께 노린다

공격자는 DNS, 프록시, SSL stripping, 사설 CA 같은 지점에서 사용자를 다른 신뢰 경로로 유도한다.

  1. Client
    사용자

    Client 사용자 원래 서버에 접속하려 함

  2. Attacker
    경로 장악

    Attacker 경로 장악 DNS/프록시/공유망 조작

  3. Server
    정상 서비스

    Server 정상 서비스 TLS 인증서로 신원 증명

  4. 방어 경계

    HSTS, 인증서 검증, pinning 일부 시나리오, 안전한 DNS가 공격 경로를 줄인다.

HTTPS(TLS)는 MITM의 도청·변조 성공 가능성을 크게 낮추지만, 핵심은 단순 암호화가 아니라 서버 인증, 키 교환 무결성, 전송 데이터 보호입니다.

클라이언트가 인증서 체인과 호스트 이름을 검증하지 않거나, 사용자가 인증서 경고를 무시하거나, 기기에 악성 루트 인증서가 설치되면 보호가 약해질 수 있습니다.

HSTS는 HTTPS 강제를 통해 downgrade/SSL stripping 위험을 줄이는 데 도움이 됩니다.

TLS 1.3은 인증된 키 교환 뒤 AEAD 레코드로 데이터를 보호한다

MITM을 막는 핵심은 “암호화” 한 단어가 아니라, 인증서로 서버를 확인하고, 핸드셰이크 기록에 묶인 키를 파생한 뒤, record마다 암호화와 변조 검증을 수행하는 구조입니다.

  1. ClientHello

    클라이언트가 지원 버전, cipher suite, key_share를 보냅니다.

  2. ServerHello + Certificate

    서버는 key_share와 인증서를 보내 신원 검증 기준을 제공합니다.

  3. Finished 검증

    서명과 transcript MAC으로 핸드셰이크 변조 여부를 확인합니다.

  4. Encrypted records

    HTTP 요청/응답은 AEAD로 암호화되고 tag로 변조가 검출됩니다.

  5. 키는 한 번에 하나가 아니라 용도별로 파생된다

    key schedule 키는 한 번에 하나가 아니라 용도별로 파생된다 ECDHE secret 네트워크에 직접 보내지 않는 공유 비밀 handshake key 인증서와 Finished 메시지 보호 traffic key application data record 보호

  6. 첫 연결 이후 HTTP downgrade를 줄인다

    HSTS 첫 연결 이후 HTTP downgrade를 줄인다 브라우저가 해당 사이트를 HTTPS로만 접속하도록 기억하게 합니다.

  7. 악성 루트 인증서가 설치되면 보호가 약해진다

    root trust 악성 루트 인증서가 설치되면 보호가 약해진다 기기 신뢰 저장소와 프록시 인증서 배포 정책도 보안 경계입니다.


DDoS 공격과 계층별 방어

DDoS(Distributed Denial of Service)는 여러 출처에서 대량의 트래픽이나 비싼 요청을 보내 서버, 네트워크, 애플리케이션의 가용성을 떨어뜨리는 공격입니다.

공격 대상에 따라 L3/L4 대역폭·상태 고갈형과 L7 애플리케이션 고비용 요청형으로 나눠 볼 수 있고, 방어는 ISP/클라우드 스크러빙, Anycast/CDN, L3/L4 필터링, SYN 보호, 큐잉, L7 rate limit/WAF를 조합합니다.

DNS 증폭은 작은 위조 질의가 큰 응답으로 되돌아가는 구조다

공격자는 피해자 IP로 출발지를 속이고, 공개 resolver는 큰 DNS 응답을 피해자에게 반사한다.

  1. 1 attacker

    attacker 출발지 IP를 피해자로 위조 UDP DNS 질의는 연결 확인 없이 나가므로 스푸핑에 악용된다.

  2. 2 open resolver

    open resolver 작은 질의를 큰 응답으로 반사 ANY, DNSSEC, TXT, EDNS0 응답이 요청보다 훨씬 커진다.

  3. 3 victim

    victim 요청하지 않은 큰 응답을 대량 수신 회선 포화, DNS/웹 지연, 방화벽 상태 고갈로 이어진다.

  4. 네트워크 사업자

    스푸핑을 출구에서 차단 위조 출발지 패킷이 인터넷으로 나가지 못하게 한다.

  5. DNS 운영자

    open resolver 금지 재귀 질의는 내부/허용 대역에만 열고 응답률 제한을 둔다.

  6. 서비스 운영자

    원본 노출과 흡수 용량 관리 CDN/Anti-DDoS와 원본 IP 보호를 함께 둔다.

방어 전략대상 계층동작 방식주의점
CDN/Anti-DDoSL3-L7엣지에서 흡수·필터링·캐시원본 IP 노출과 우회 경로 차단 필요
AnycastL3같은 IP를 여러 지역에서 광고해 분산라우팅 정책과 용량 계획이 중요
Rate LimitingL7사용자·IP·토큰별 요청량 제한프록시·NAT·분산 공격에 취약할 수 있음
SYN CookiesL4연결 상태를 늦게 만들며 SYN flood 완화모든 TCP 공격을 해결하지는 않음
Ingress FilteringL3스푸핑된 출발지 주소를 네트워크 경계에서 차단운영자 간 협력이 필요
WAF/Bot 관리L7HTTP 패턴, 평판, 챌린지로 필터링오탐·우회·정상 사용자 영향 관리 필요
Blackhole RoutingL3특정 목적지 트래픽을 폐기서비스도 함께 중단될 수 있는 최후 수단

DNS amplification 같은 반사 공격은 공격자가 출발지 IP를 피해자로 위조하고, 공개된 재귀 DNS(open resolver)가 큰 DNS 응답을 피해자에게 보내게 만드는 방식입니다.

증폭률은 쿼리 타입, EDNS0, DNSSEC, 응답 크기, 서버 설정에 따라 달라집니다.

이런 공격은 서비스 앞단의 흡수 능력뿐 아니라, 네트워크 운영자의 스푸핑 차단과 open resolver 관리가 같이 필요합니다.


방화벽과 ACL

방화벽(Firewall)은 네트워크 트래픽을 규칙에 따라 허용하거나 차단합니다.

ACL은 보통 “어떤 출발지/목적지/포트/프로토콜을 허용할지”를 명시하는 규칙 목록이고, stateful firewall은 연결 상태까지 추적합니다.

방화벽은 패킷을 출발지, 목적지, 포트, 상태 순서로 판정한다

ACL은 허용/차단 목록이 아니라 조건을 순서대로 평가하는 결정 파이프라인이다.

  1. src
    출발지

    src 출발지 IP, subnet, zone

  2. dst
    목적지

    dst 목적지 service, subnet

  3. port
    프로토콜/포트

    port 프로토콜/포트 TCP 443, UDP 53

  4. state
    연결 상태

    state 연결 상태 established 여부

  5. action
    allow/deny/log

    action allow/deny/log 첫 매칭 규칙 적용

방화벽은 불필요한 노출면을 줄이는 기본 방어선이지만, 허용된 포트 안에서 발생하는 SQL Injection, XSS, 인증 우회 같은 애플리케이션 취약점까지 자동으로 해결하지는 못합니다.

암호화된 트래픽 내부를 보려면 TLS 복호화 프록시, 내부 인증서 배포, 개인정보·성능 검토가 필요합니다.

그래서 네트워크 방화벽, 보안 그룹, 세그먼테이션, WAF, 애플리케이션 보안 점검을 함께 봐야 합니다.


WAF와 보안 관측

WAF(Web Application Firewall)는 HTTP 계층에서 동작하며 요청의 URL, 헤더, 쿠키, 본문 패턴을 분석해 웹 공격을 탐지하거나 차단합니다.

일반 방화벽이 IP와 포트 중심이라면, WAF는 HTTP 대화의 내용을 다룹니다.

다만 정상 요청처럼 보이는 비즈니스 로직 남용, 인증·인가 오류, 우회 인코딩, API 스키마 미반영, 오탐과 미탐은 애플리케이션 설계와 운영 튜닝으로 함께 다뤄야 합니다.

보안 도구는 보는 지점과 실행할 수 있는 대응이 서로 다르다

요청 경로의 센서는 단계마다 다른 증거를 보고, SIEM은 그 신호를 같은 사용자·자산·시간의 사건으로 묶습니다.

  1. 1
    IDS

    alert 네트워크 관찰 지점 패킷·flow·프로토콜 signature와 anomaly를 탐지해 알립니다. 차단은 연동이 필요하고, 튜닝이 없으면 잡음이 우선순위를 흐립니다.

  2. 2
    IPS

    drop/reset 트래픽 인라인 세션 상태와 L3-L7 signature를 보고, 패치 전에도 흐름 중간에서 차단합니다. 오탐은 정상 트래픽을 막으므로 예외와 fail-open 기준이 필요합니다.

  3. 3
    WAF

    block/rate TLS 종료 뒤 HTTP method·path·header·cookie·body·API schema로 SQLi·XSS·bot을 거릅니다. challenge도 가능하지만 로직 남용과 인증·인가 오류는 앱이 해결해야 합니다.

  4. 4
    EDR

    isolate/kill 호스트 실행 지점 프로세스·파일·레지스트리·메모리·명령행과 로컬 통신을 추적합니다. 격리는 업무를 멈출 수 있고, 앞단 DDoS 흡수는 CDN·ISP의 역할입니다.

보안 도구계층역할한계
IDSL3-L7침입 징후 탐지와 알림직접 차단하지 않는 구성이 많음
IPSL3-L7탐지 후 인라인 차단오탐이면 정상 트래픽 차단 가능
WAFL7웹 공격 패턴 탐지·차단비즈니스 로직 취약점은 별도 설계 필요
SIEM전 계층로그 상관분석과 경보로그 품질과 룰 튜닝에 성능이 좌우됨
EDR엔드포인트단말 행위 기반 탐지·대응네트워크 앞단의 대량 트래픽 흡수와는 다름
rate_limiter.py
import time
from collections import defaultdict

class RateLimiter:
    """단일 프로세스 예시용 토큰 버킷 Rate Limiter"""

    def __init__(self, max_tokens, refill_rate):
        self.max_tokens = max_tokens
        self.refill_rate = refill_rate  # 초당 충전 토큰 수
        self.buckets = defaultdict(lambda: {
            "tokens": max_tokens,
            "last_refill": time.time(),
        })

    def allow_request(self, client_key):
        bucket = self.buckets[client_key]
        now = time.time()
        elapsed = now - bucket["last_refill"]
        bucket["tokens"] = min(
            self.max_tokens,
            bucket["tokens"] + elapsed * self.refill_rate,
        )
        bucket["last_refill"] = now

        if bucket["tokens"] >= 1:
            bucket["tokens"] -= 1
            return True
        return False

# 단일 인스턴스 예시: 초당 10개 요청, 버스트 최대 20개
limiter = RateLimiter(max_tokens=20, refill_rate=10)

for i in range(25):
    key = "user:42"
    if limiter.allow_request(key):
        print(f"요청 {i + 1}: 허용")
    else:
        print(f"요청 {i + 1}: 제한")

위 코드는 알고리즘 이해용입니다.

운영 환경에서는 여러 서버가 동시에 요청을 받으므로 Redis 같은 공유 저장소, 엣지 rate limit, 사용자 ID·IP·토큰 조합 키, 프록시 헤더 신뢰 정책, 모니터링을 함께 설계해야 합니다.

다음 장에서는 네트워크 이론을 코드로 직접 구현해 보는 소켓 프로그래밍을 다루겠습니다.