DDoS 공격과 일반적인 트래픽 폭증을 구분하는 방법

웹서비스의 트래픽이 갑자기 평소의 몇 배로 증가하면 가장 먼저 “DDoS 공격인가?”라는 생각이 들 수 있다.

하지만 트래픽이 증가했다는 사실만으로 DDoS라고 판단할 수는 없다. 이벤트, 광고, 검색 노출, 뉴스나 커뮤니티 유입처럼 정상적인 이유로도 Request와 Connection은 짧은 시간에 크게 증가할 수 있다.

반대로 DDoS 공격도 단순히 대역폭만 크게 증가하는 형태로 발생하는 것은 아니다. HTTP 요청 자체는 정상처럼 보이지만 특정 URI에 대량으로 집중되는 Layer 7 공격도 존재한다.

실제 운영자가 확인해야 할 것은 단순한 트래픽 양이 아니라 평소와 비교해 트래픽의 양과 구성, Connection 상태, 요청 패턴, 서버 자원이 어떻게 달라졌는가이다. AWS Shield 역시 애플리케이션 계층 공격 탐지에서 현재 트래픽을 과거 Baseline과 비교하면서 전체 Volume뿐 아니라 Traffic Composition의 변화까지 사용한다.

1. 트래픽이 증가했다고 모두 DDoS는 아니다

정상적인 트래픽 폭증과 DDoS는 서버 입장에서는 처음에 비슷하게 보일 수 있다.

둘 다 다음과 같은 현상을 만들 수 있다.

Request 증가
    ↓
Connection 증가
    ↓
Network 사용량 증가
    ↓
CPU / Application 부하 증가
    ↓
응답시간 증가

예를 들어 쇼핑몰에서 이벤트가 시작되거나 특정 글이 검색 상위에 노출되면 실제 사용자가 동시에 접속하면서 Request가 급증할 수 있다.

이것은 서버에는 부담이 되지만 공격은 아니다.

DDoS는 다수의 Source에서 의도적으로 대량의 트래픽이나 요청을 발생시켜 정상 사용자가 서비스를 이용하기 어렵게 만드는 공격이다.

따라서 판단 기준은 단순히

트래픽 증가 = DDoS

가 아니라

현재 트래픽
    ↓
평소 Baseline과 비교
    ↓
요청 패턴 변화 확인
    ↓
Connection / Network 확인
    ↓
서비스 영향 확인

순서로 접근하는 것이 좋다.

2. DDoS는 어느 계층에서 발생하는지도 구분해야 한다

DDoS를 분석할 때 중요한 것은 공격이 어느 계층을 대상으로 하는가이다.

네트워크 또는 전송 계층의 공격은 대량의 Packet이나 Connection을 이용해 네트워크 또는 서버의 처리 능력을 소모시키는 형태다.

반면 Layer 7 DDoS는 HTTP GET이나 POST처럼 웹서버가 실제로 처리해야 하는 요청을 대량으로 발생시킬 수 있다. Google Cloud 역시 HTTP GET Flood, POST Flood와 같은 고빈도 HTTP 활동을 Layer 7 DDoS 사례로 설명한다.

구조적으로 보면 차이가 있다.

L3 / L4 공격

Internet
   ↓
대량 Packet / Connection
   ↓
Network / Kernel
   ↓
Service 영향

L7 공격

Internet
   ↓
HTTP Request
   ↓
Nginx
   ↓
Application
   ↓
Database

특히 Layer 7에서는 요청 하나하나만 보면 정상 HTTP Request처럼 보일 수도 있다.

그래서 Access Log 한 줄만 보고 정상과 공격을 구분하기 어려운 경우가 많다.

3. 실제 서버에서는 어떤 증상이 나타날까?

DDoS나 대규모 트래픽이 발생하면 가장 먼저 사용자가 체감하는 것은 응답 지연이다.

공격이나 트래픽의 형태에 따라 다음과 같은 증상이 함께 나타날 수 있다.

Network Traffic 급증
Request Per Second 증가
TCP Connection 증가
응답시간 증가
CPU 사용률 상승
5xx 오류 증가
Backend 지연
정상 사용자 접속 실패

CISA도 DDoS의 주요 징후로 서비스 이용 불가 또는 심각한 지연, 네트워크 혼잡, 평소와 다른 Traffic Pattern 등을 제시한다.

다만 이러한 증상 역시 DDoS만의 고유한 현상은 아니다.

정상적인 대규모 사용자 유입에서도 CPU와 Connection, Network 사용량은 올라갈 수 있다.

따라서 증상만 가지고 판단하지 않고 원인을 계속 좁혀야 한다.

4. 가장 먼저 평소의 Baseline과 비교한다

운영 환경에서 DDoS를 판단할 때 가장 중요한 자료 중 하나가 평소 서버 상태다.

예를 들어 정상 시간대의 서버가 다음과 같다고 가정해 보자.

평균 Request : 500 RPS
평균 Connection : 1,000
평균 Network : 100 Mbps
평균 CPU : 35%

어느 순간 RPS가 크게 증가했다고 해서 바로 공격으로 판단할 수는 없다.

먼저 “평소 어느 정도였는가?”를 확인해야 한다.

Google Cloud Armor에서도 최근 정상적인 요청량과 비교해 RPS가 갑자기 증가하는 현상을 별도로 탐지하지만, 이런 Traffic Spike 자체는 잠재적인 공격을 조사하기 위한 신호이지 그 자체가 DDoS라는 의미는 아니다.

여기에 이벤트나 광고 집행처럼 예상할 수 있는 원인이 있는지도 확인해야 한다.

정상 트래픽과 비정상 트래픽을 구분하려면 절대 수치보다 정상 상태에서 얼마나 벗어났는지를 먼저 보는 것이 중요하다.

5. Access Log에서 요청 패턴을 확인한다

웹서비스라면 Nginx Access Log를 이용해 트래픽의 성격을 확인할 수 있다.

먼저 Source IP별 Request 수를 확인한다.

awk '{print $1}' /var/log/nginx/access.log \
| sort | uniq -c | sort -nr | head

이 명령은 특정 Source에 요청이 집중되어 있는지 확인하기 위한 것이다.

하지만 특정 IP가 많다는 이유만으로 공격이라고 판단해서는 안 된다.

Load Balancer나 CDN, Reverse Proxy 환경에서는 실제 사용자 IP 대신 Proxy IP가 로그에 보일 수도 있다.

다음으로 URI별 Request 수를 확인한다.

awk '{print $7}' /var/log/nginx/access.log \
| sort | uniq -c | sort -nr | head

정상적인 사용자 증가라면 여러 페이지와 리소스로 요청이 분산되는 경우가 많다.

반대로 특정 API나 로그인 페이지처럼 서버 자원을 많이 사용하는 URI 한 곳에 비정상적으로 Request가 집중된다면 추가 확인이 필요하다.

다만 이것 역시 공격 여부를 단독으로 판단하는 기준은 아니다.

서비스 특성상 정상 사용자가 특정 URI에 집중될 수도 있기 때문이다.

6. TCP Connection과 Network 상태도 같이 본다

HTTP Log만 봐서는 Network 계층에서 어떤 일이 발생하는지 알 수 없다.

현재 Socket 상태는 다음처럼 확인할 수 있다.

ss -s

ss -s는 Socket 전체 통계를 빠르게 확인할 때 유용하다. ss는 Linux에서 Socket 상태와 TCP 정보를 확인할 수 있는 도구다.

TCP 상태를 조금 더 자세히 보려면 다음과 같이 확인할 수 있다.

ss -tan

여기에서는 단순 Connection 개수뿐 아니라 특정 TCP 상태가 비정상적으로 증가했는지도 확인한다.

Network Interface 사용량 역시 중요하다.

sysstat이 설치된 환경이라면 다음과 같이 확인할 수 있다.

sar -n DEV 1

이때 운영자가 확인해야 할 흐름은 다음과 같다.

Request 증가
    ↓
TCP Connection 증가?
    ↓
Network 사용량 증가?
    ↓
CPU도 같이 증가?
    ↓
Backend까지 느려졌는가?

이 과정을 통해 문제가 웹 요청 수준인지, Connection 수준인지, Network 대역폭 자체가 포화되고 있는지 범위를 좁힐 수 있다.

7. 정상 폭증과 DDoS를 판단할 때 무엇을 봐야 할까?

실제 운영에서는 하나의 지표가 아니라 여러 특징을 같이 비교해야 한다.

정상 사용자 유입이라면 보통 실제 서비스 이용 흐름이 나타난다.

메인 페이지
   ↓
상세 페이지
   ↓
API
   ↓
이미지 / CSS
   ↓
다른 페이지

반면 비정상 트래픽에서는 특정 URI 또는 특정 형태의 Request가 지나치게 반복될 수 있다.

또 다음 항목을 함께 본다.

요청 증가 시점
Source IP 분포
URI 분포
HTTP Method
Status Code
Connection 상태
Network 사용량
CPU 사용률
Backend 응답시간

특히 Source IP가 많다는 사실만으로 DDoS라고 판단해서도 안 된다.

정상적인 대규모 서비스 역시 수많은 사용자 IP에서 동시에 접속한다.

반대로 Layer 7 공격은 정상적인 HTTP 요청과 매우 비슷하게 만들어질 수 있기 때문에 단순 IP 차단만으로 구분하기 어려울 수도 있다. Google Cloud도 L7 DDoS에서는 개별 요청이 정상적인 완전한 HTTP Request처럼 보여 실시간 구분이 어려울 수 있다고 설명한다.

결국 중요한 것은 Traffic Volume과 Traffic Pattern을 함께 보는 것이다.

8. Access Log가 정상이라고 DDoS가 아닌 것은 아니다

여기서 운영자가 놓치기 쉬운 중요한 부분이 있다.

네트워크 대역폭이 서버 앞단에서 이미 포화되고 있다면 Nginx까지 Request가 정상적으로 도달하지 못할 수 있다.

구조적으로는 다음과 같다.

Internet
   ↓
대량 Traffic
   ↓
Network 구간 포화
   X
Nginx

이 경우 사용자는 사이트에 접속하지 못하지만 Access Log에는 생각보다 많은 요청이 남지 않을 수도 있다.

따라서

Access Log 급증 없음
= DDoS 아님

이라고 판단하면 안 된다.

Network Traffic과 Packet 수준 지표, Load Balancer나 CDN, Firewall 같은 서버 앞단의 Monitoring 정보까지 확인해야 한다.

이것이 웹서버 로그만 분석하는 것과 실제 DDoS 장애 분석의 중요한 차이다.

9. 원인에 따라 대응 방법도 달라져야 한다

정상적인 사용자 폭증과 DDoS는 대응 방향이 완전히 다르다.

정상적인 사용자 증가라면 트래픽을 차단하는 것이 아니라 서버가 더 많은 요청을 처리할 수 있도록 해야 한다.

예를 들면 Cache 적용, Application 병목 제거, Scale-out, CDN 활용 등을 검토할 수 있다.

반대로 특정 HTTP Request가 비정상적으로 반복된다면 Rate Limiting이나 WAF 정책을 검토할 수 있다.

Nginx에는 Request 처리 속도를 제한하는 limit_req 기능이 있다. 공식 문서에서는 지정한 Key, 예를 들어 Client IP 기준으로 요청 처리 Rate를 제한할 수 있도록 제공한다.

limit_req_zone $binary_remote_addr
               zone=perip:10m
               rate=10r/s;

그러나 이 값을 그대로 운영 서버에 적용해서는 안 된다.

NAT 뒤에 많은 사용자가 있거나 Reverse Proxy 환경에서 실제 Client IP 처리가 제대로 되지 않았다면 정상 사용자까지 함께 제한할 수 있기 때문이다.

또 Network 대역폭 자체를 소진시키는 대규모 공격이라면 서버 내부의 Nginx 설정만으로 해결하기 어렵다.

이 경우에는 CDN, Cloud DDoS Protection, ISP 또는 상위 Network 계층에서 공격 Traffic을 서버에 도달하기 전에 처리하는 구조가 필요하다.

10. 정리

DDoS 공격과 정상적인 트래픽 폭증은 처음에는 매우 비슷하게 보일 수 있다.

둘 다 Request와 Connection을 증가시키고 CPU와 Network 사용량을 높이며 서비스 응답시간을 느리게 만들 수 있기 때문이다.

따라서 트래픽이 증가했다는 사실 하나만으로 DDoS를 판단해서는 안 된다.

실제 운영에서는 다음 순서로 확인하는 것이 좋다.

트래픽 증가 확인
       ↓
평소 Baseline과 비교
       ↓
Source / URI 패턴 분석
       ↓
TCP Connection 확인
       ↓
Network 사용량 확인
       ↓
CPU / Backend 영향 확인
       ↓
정상 유입인지 공격인지 판단
       ↓
원인에 맞는 대응

특히 웹서버 Access Log만 보고 결론을 내리지 않는 것이 중요하다.

Layer 7 공격은 정상 HTTP Request처럼 보일 수 있고, 반대로 Network 계층에서 Traffic이 막히면 Nginx까지 요청이 도달하지 않아 Access Log에 충분한 흔적이 남지 않을 수도 있다.

결국 운영자가 확인해야 하는 것은 단순한 Traffic Volume이 아니다.

평소와 비교해 트래픽의 양과 구성은 어떻게 변했는지, Connection과 Network는 어떤 상태인지, 그리고 그 변화가 실제 정상 사용자에게 어떤 영향을 주고 있는지를 하나의 흐름으로 연결해서 판단하는 것이 DDoS 분석의 핵심이다.