DDoS 공격을 막는 것보다 정상 사용자를 살리는 것이 더 어렵습니다

서버에 DDoS 방어가 적용되어 있다고 하면 많은 분이 공격 트래픽을 모두 차단해 주는 것으로 생각합니다.

하지만 실제 운영에서 더 어려운 문제는 공격을 막는 것보다 정상 사용자의 접속을 유지하는 것입니다.

방어 정책을 너무 느슨하게 적용하면 공격 트래픽이 서버까지 도달합니다. 반대로 정책을 너무 강하게 적용하면 정상 사용자의 패킷까지 공격으로 판단해 차단할 수 있습니다.

특히 게임 서버, 웹사이트, API 서버는 정상 트래픽의 형태가 서로 다릅니다.

게임 서버는 짧고 반복적인 TCP·UDP 패킷이 많고, 웹서비스는 HTTP·HTTPS 요청이 중심입니다. API 서버는 짧은 시간에 동일한 주소로 많은 요청이 발생하는 경우도 있습니다.

따라서 모든 서버에 동일한 방어 정책을 적용하면 문제가 생길 수 있습니다.

실제 DDoS 대응에서는 다음 항목을 함께 확인해야 합니다.

• 공격이 발생한 프로토콜과 포트
• 초당 패킷 수와 트래픽 크기
• 정상 사용자의 접속 국가와 통신사
• 서버에서 실제로 사용하는 서비스 포트
• TCP 연결 상태와 비정상 패킷 형태
• 방어 적용 후 발생하는 오탐과 접속 장애

공격 트래픽이 크다고 반드시 대응이 어려운 것도 아니고, 트래픽이 작다고 안전한 것도 아닙니다.

대역폭을 모두 채우는 공격이 아니더라도 작은 패킷이 대량으로 유입되면 네트워크 장비나 서버의 세션 처리에 부담을 줄 수 있습니다. 특정 포트나 애플리케이션의 동작 방식을 노리는 공격은 비교적 작은 규모에서도 서비스 장애를 일으킬 수 있습니다.

그래서 DDoS 방어는 단순히 장비를 연결하는 것으로 끝나지 않습니다.

공격이 발생했을 때 패킷을 분석하고, 정상 사용자의 접속 특성을 확인한 뒤, 서비스에 맞게 정책을 계속 조정해야 합니다.

HaruIDC는 서버 제공뿐 아니라 고객 서비스의 포트 구성, 정상 트래픽의 특성, 접속 장애 원인을 함께 확인하는 방향으로 인프라를 운영하고 있습니다.

모든 공격을 무조건 차단하는 것이 아니라, 공격 중에도 정상 사용자가 최대한 서비스를 이용할 수 있도록 만드는 것이 실제 DDoS 방어의 목적이라고 생각합니다.

앞으로 실제 서버와 네트워크를 운영하면서 경험한 장애 분석, 트래픽 확인 방법, DDoS 방어 정책 구성에 대해서도 하나씩 공유해 보겠습니다.

서버를 운영하면서 DDoS 방어가 적용된 이후에도 접속 장애나 핑 상승을 경험한 적이 있으신가요?

HaruIDC 공식 홈페이지