사이트가 갑자기 먹통이 되고 접속 로그에 낯선 IP가 쏟아지면 DDoS를 의심하게 됩니다. 이때 많이 하는 첫 대응이 서버 사양을 올리는 건데요, 대부분의 경우 그건 답이 아닙니다. 공격 유형에 따라 손써야 할 곳이 완전히 다르기 때문이에요.
회선을 막는 공격과 서버를 지치게 하는 공격
크게 두 갈래로 나뉩니다. 하나는 대역폭을 통째로 채우는 공격이에요. 쓰레기 트래픽을 어마어마하게 쏟아부어 회선 자체를 막아버립니다. 이건 서버 사양과 무관합니다. 고속도로 입구가 막혔는데 집 안 살림을 늘리는 격이라, CPU를 아무리 키워도 소용이 없어요. 회선 앞단에서 걸러내야 합니다.
다른 하나는 정상 요청처럼 보이는 공격입니다. 트래픽 양은 크지 않은데 검색이나 로그인처럼 서버가 힘들어하는 요청만 골라서 반복해요. 이건 대역폭 그래프에 잘 안 잡혀서 원인을 찾기 어렵습니다. 웹 애플리케이션 단에서 요청 패턴을 보고 걸러야 합니다.
그래서 첫 단계는 어느 쪽인지 구분하는 것이에요. 대역폭 사용량이 평소보다 폭증했는지, 아니면 트래픽은 비슷한데 CPU나 DB만 치솟는지를 보면 방향이 잡힙니다.
어디까지가 호스팅사 몫일까
대역폭을 채우는 공격은 개별 서버에서 막을 수 없습니다. 이미 트래픽이 데이터센터 회선까지 도달한 뒤라서요. 이건 데이터센터와 통신사 구간에서 걸러야 하는 영역이라 호스팅 제공자의 방어 체계가 있느냐가 결정적입니다.
반면 애플리케이션을 노리는 공격은 고객 쪽에서 할 수 있는 일이 많습니다. 요청 빈도 제한을 걸고, 무거운 페이지에 캐시를 적용하고, 로그인 같은 민감한 경로에 추가 검증을 두는 식이에요. 이런 준비가 되어 있으면 같은 공격을 받아도 버티는 정도가 다릅니다.
계약할 때 DDoS 방어가 어느 규모까지 포함되는지 확인해두시는 게 좋습니다. 기본 제공 범위를 넘어서면 별도 서비스가 필요한 경우가 있어서, 사고가 난 뒤에 알게 되면 대응이 늦어집니다.
공격받는 중에 할 일과 하지 말아야 할 일
가장 먼저 호스팅 제공자에 알리는 것입니다. 회선 구간의 상황은 그쪽에서만 볼 수 있고, 차단 조치도 그 단에서 이뤄집니다. 혼자 서버만 붙잡고 있으면 시간만 흘러갑니다.
반대로 서버 IP를 성급히 바꾸는 건 권하지 않습니다. 공격자가 도메인을 보고 있다면 새 IP도 금방 따라옵니다. 그 사이 DNS 전파 때문에 정상 이용자만 접속이 끊기는 일이 생겨요. 앞서 다룬 TTL을 평소 짧게 관리해두면 이럴 때 선택지가 넓어집니다.
그리고 로그를 남겨두세요. 공격이 지나간 뒤 어떤 경로로 무엇이 몰렸는지 분석해야 다음을 대비할 수 있습니다. 급한 마음에 로그를 지우거나 서버를 초기화하면 그 기회를 잃습니다.
TIDC는 국내 데이터센터를 직접 운영하며 DDoS 방어를 기본 제공합니다. 어느 수준까지 대비가 필요한지 서비스 성격에 맞춰 상담해드리니 편하게 문의해주세요.
