DDOS 공격을 받았을 때 서버를 살리는 방법

얼마 전 사이트가 느려졌다는 연락을 받고 로그를 열었는데, 첫 요청부터 서버가 버티지 못하는 상황은 아니었다. 평소보다 요청이 늘긴 했지만 진짜 문제는 로그인 페이지로 들어온 요청이 매번 데이터베이스를 조회하도록 만든 설정이었다. DDOS 대응은 서버 사양을 올리기 전에 어디에서 막히는지 확인하는 일부터 시작한다.

먼저 장애가 난 지점을 확인한다

페이지가 열리지 않는다고 모두 DDOS는 아니다. 서버 한 대의 CPU가 꽉 찬 것인지, 회선이 포화된 것인지, 특정 경로의 요청이 급증한 것인지에 따라 조치가 달라진다. 평소 수치가 없으면 공격 여부도 판단하기 어렵다. 최소한 초당 요청 수, 동시 연결 수, 회선 사용량, CPU와 메모리, 응답 시간, 오류 비율을 함께 본다.

예를 들어 평소 초당 20건, 바쁜 시간에도 60건 정도 처리하던 사이트가 갑자기 500건을 받는다면 이상 징후다. 다만 그날 행사를 시작했다면 정상 유입일 수도 있다. 요청 경로와 사용자 행동을 같이 확인해야 한다. 같은 주소로 짧은 시간에 요청이 몰리고 세션 유지나 페이지 이동이 거의 없다면 방어가 필요한 쪽에 무게가 실린다.

• 회선 사용량이 한계에 가까우면 호스팅 업체나 상위 네트워크의 대응이 필요하다. 서버 안에서 차단 규칙을 추가해도 트래픽은 이미 회선을 지나왔다.
• 회선은 여유가 있는데 CPU나 데이터베이스 연결 수가 치솟으면 웹 요청을 처리하는 단계에서 막힐 가능성이 크다.
• 오류가 403 또는 429로 늘었다면 방어 규칙이 정상 방문자까지 막고 있는지 확인한다. 502 또는 503이 늘었다면 원본 서버 상태도 함께 봐야 한다.

도메인 설정이나 인증서 문제로 접속이 끊긴 경우도 있다. 여러 지역에서 같은 증상이 나는지, 원본 서버는 살아 있는지부터 분리해서 확인하면 엉뚱한 규칙을 급히 추가하는 일을 줄일 수 있다.

공격 종류에 맞춰 막는 위치를 고른다

대량의 패킷으로 회선을 채우는 공격과 로그인 페이지를 반복 호출하는 공격은 막는 위치가 다르다. 앞쪽은 호스팅 업체의 네트워크 보호나 트래픽 분산 서비스가 맡아야 한다. 뒤쪽은 캐시, 웹 방화벽, 요청 횟수 제한이 효과적일 수 있다. 작은 VPS의 방화벽만 믿고 대량 트래픽을 받으면 서버에 도착하기도 전에 회선이 먼저 막힌다.

웹 요청이 문제라면 정상 방문자가 많이 쓰는 경로와 부담이 큰 경로를 나눈다. 이미지나 공개 글은 캐시해 원본 서버까지 오는 요청을 줄인다. 로그인, 검색, 주문 조회처럼 매번 서버 작업이 필요한 경로에는 별도 제한을 건다. 전체 사이트에 똑같이 강한 제한을 걸면 공격은 줄어도 실제 이용자가 함께 막힐 수 있다.

숫자는 서비스의 평소 사용량으로 잡는다. 가령 일반 방문자는 검색을 1분에 몇 번만 쓰는데 특정 출발지에서 수백 번 호출한다면 검색 경로의 제한 기준을 낮출 근거가 된다. 반대로 사무실이나 학교의 여러 사람이 하나의 공인 주소를 공유할 수 있으므로 주소 하나만 기준으로 영구 차단하는 방식은 조심해야 한다. AWS와 Cloudflare의 운영 문서도 평소 지표를 보고 요청 제한을 조정하며, 원본 서버로 직접 들어오는 경로를 통제하도록 안내한다.

접속이 끊겼다면 이 순서로 움직인다

실제 장애 중에는 설정을 한꺼번에 바꾸지 않는 편이 낫다. 무엇이 효과가 있었는지 알 수 없고, 되돌릴 때도 꼬인다. 저는 먼저 시간대와 증상을 기록하고 지표 화면과 로그를 보존한다. 이어 회선 포화인지 웹 요청 급증인지 판단한 뒤, 필요한 곳에만 임시 규칙을 적용한다.

• 회선이 포화됐다면 호스팅 업체에 공격 시작 시각, 대상 서버, 트래픽 규모와 유형을 전달하고 상위망 차단이나 우회가 가능한지 확인한다.
• 특정 경로가 집중 공격을 받는다면 그 경로에 요청 횟수 제한을 걸고 정상 요청의 실패율을 같이 본다.
• 캐시 가능한 응답은 캐시하고, 비용이 큰 기능은 상황에 따라 잠시 제한한다. 결제나 관리자 기능은 영향 범위를 먼저 확인한다.
• 규칙을 적용한 뒤에는 요청 수만 보지 말고 실제 페이지 접속, 로그인, 주요 기능이 되는지 외부 환경에서 점검한다.

원본 서버의 주소가 이미 알려져 있으면 앞단에서 공격을 막아도 서버로 직접 요청이 들어올 수 있다. 원본 서버가 사용하는 네트워크 규칙을 점검해 승인된 경로로만 웹 요청을 받도록 해야 한다. 이때 서버 관리 접속까지 막지 않도록 관리 경로를 먼저 확인한다.

평소에 준비할 것은 큰 요금제가 아니다

월 방문자가 적은 블로그라면 비싼 전용 방어 상품부터 계약할 이유는 드물다. 기본 제공되는 네트워크 보호 범위와 트래픽 분산 서비스의 무료 또는 저가 기능을 확인하고, 실제 병목에 맞춰 추가 비용을 판단하면 된다. 요금표의 대역폭 숫자만 보지 말고 정상 시간대의 초당 요청 수와 동시 접속 수, 공격 중 원본 서버에 남는 요청 수를 비교해야 한다.

운영 전에는 평소 지표를 며칠 이상 남기고 경고 기준을 잡는다. 로그인과 검색 같은 경로의 제한 규칙은 정상 이용자가 있는 시간에 검증한다. 백업도 별도로 유지한다. 백업이 DDOS를 막지는 못하지만, 장애 중 설정을 되돌리거나 다른 서버로 복구해야 할 때 없으면 선택지가 급격히 줄어든다. 설정 파일과 데이터베이스를 함께 백업하고 복구 절차를 한 번 실행해 본 기록이 필요하다.

공격이 끝난 뒤에는 어느 단계가 먼저 막혔는지 다시 본다. 회선이 버텼는데 데이터베이스가 멈췄다면 더 큰 서버보다 캐시나 쿼리 개선이 먼저일 수 있다. 반대로 서버 자원은 남았는데 회선이 포화됐다면 서버 증설로는 해결되지 않는다. DDOS에 대비한 지출은 그 차이를 확인한 다음에 결정하는 게 낫다.