디도스 공격 방어를 위해 서버부터 점검하는 방법

얼마 전 작은 쇼핑몰의 접속 장애를 봤는데, 운영자는 디도스 공격을 의심하고 바로 서버 증설부터 하려 했다. 그런데 기록을 확인하니 특정 상품 페이지로 요청이 몰렸고, 서버보다 먼저 데이터베이스 연결 수가 한계에 닿았다. 공격이 맞더라도 장비를 키우는 것만으로 해결되지 않는 경우가 많다. 어디에서 막히는지 알아야 비용도 덜 든다.

먼저 트래픽과 서버 부하를 나눠 본다

디도스 공격 방어의 첫 단계는 회선이 찼는지, 웹서버가 바쁜지 구분하는 일이다. 외부에서 들어오는 트래픽이 회선 한계에 가까우면 서버 설정을 바꿔도 요청이 서버까지 도착하지 못한다. 반대로 회선에는 여유가 있는데 응답 시간이 길어지고 오류가 늘면 웹서버, 애플리케이션, 데이터베이스 쪽을 봐야 한다.

예를 들어 평소 초당 20건을 처리하던 사이트에 초당 2,000건이 들어왔다고 하자. 전송량은 크지 않아도 검색이나 로그인처럼 계산이 많은 요청이면 작은 서버는 금방 멈춘다. 반대로 초당 요청 수가 적어 보여도 큰 패킷이 회선을 채우면 서버 자원을 늘려 봐야 소용이 없다. 요청 수, 들어오는 전송량, 응답 시간, 오류 비율을 같은 시간대에 놓고 비교하는 이유다.

확인할 기록은 웹서버 접근 기록과 오류 기록, CPU·메모리 사용량, 네트워크 사용량이다. 정상 이용자가 몰린 행사 시간과 비교하면 판단이 조금 쉬워진다. 다만 접속 주소 하나만 보고 공격이라고 단정하면 안 된다. 여러 사람이 같은 통신망을 쓰기도 하고, 공격 요청이 여러 곳에서 나뉘어 들어오기도 한다.

회선이 막히면 호스팅 업체와 먼저 움직인다

회선 대역폭을 넘는 공격은 사이트 안쪽의 방화벽만으로 처리하기 어렵다. 100메가비트 회선에 그보다 훨씬 큰 트래픽이 들어오면 서버가 차단 규칙을 실행하기 전에 입구가 막힌다. 이런 상황에서는 호스팅 업체나 상위 네트워크 사업자에게 공격 완화 지원 범위, 적용까지 걸리는 시간, 추가 비용을 확인해야 한다.

트래픽을 앞단에서 받아 걸러 주는 서비스도 선택지다. 다만 가입만 하면 끝나는 구조는 아니다. 원본 서버가 직접 접속되는 상태라면 공격자가 앞단을 거치지 않고 서버를 때릴 수 있다. 앞단을 붙인 뒤에는 원본 서버가 허용된 경로에서 오는 요청만 받도록 제한하고, 기존에 공개된 접속 정보도 점검해야 한다. 작업 중 설정을 잘못 바꾸면 정상 이용자까지 막히므로 접속 확인 절차를 미리 적어 두는 편이 좋다.

저렴한 호스팅을 쓰는 작은 사이트라면 평소부터 비싼 방어 상품을 유지할 필요는 없을 수 있다. 대신 업체가 공격 중 어떤 조치를 제공하는지, 임시 차단이나 우회가 가능한지 계약 전에 확인해야 한다. 월 요금만 비교하다가 장애가 난 뒤 지원 범위를 처음 알게 되는 일이 꽤 많다.

웹 요청은 한꺼번에 막지 말고 단계적으로 제한한다

로그인, 검색, 장바구니처럼 서버 작업량이 큰 경로에는 요청 속도 제한을 먼저 검토한다. 기준은 사이트의 실제 사용량으로 잡아야 한다. 평소 최대치가 초당 30건인 경로에 갑자기 500건이 들어온다면 의심할 만하지만, 전체 방문자에게 일괄적으로 낮은 제한을 걸면 정상 이용자가 먼저 불편을 겪는다.

나는 보통 읽기만 하는 페이지와 계산이 많은 경로를 따로 본다. 반복 요청이 많은 경로에는 짧은 시간 단위의 제한을 적용하고, 같은 요청에 같은 내용을 돌려줄 수 있다면 캐시를 쓴다. 로그인에는 실패 횟수 제한도 필요하다. 규칙을 넣은 뒤에는 차단된 요청 수뿐 아니라 정상 주문이나 로그인 성공률도 함께 확인한다. 차단 숫자만 늘어난다고 방어가 잘되는 것은 아니다.

긴급 상황에서 특정 지역이나 통신망을 통째로 막고 싶어질 수 있다. 그런데 실제 고객이 섞여 있을 가능성이 있다. 먼저 요청 경로, 응답 코드, 반복 간격을 보고 범위를 좁히는 편이 안전하다. 공격 양상이 바뀌면 규칙도 다시 봐야 한다.

장애 절차는 공격 전에 만들어 둔다

공격 중에는 평소 쉬운 변경도 위험해진다. DNS 설정을 급히 바꾸거나 서버를 옮기다가 인증서, 방화벽, 원본 연결 설정이 어긋날 수 있다. 현재 설정을 기록하고, 변경할 사람과 되돌릴 방법을 정해 두면 시간을 아낄 수 있다. 백업은 디도스 공격을 막는 수단은 아니지만, 대응 과정에서 설정을 망가뜨렸을 때 복구할 수 있게 해 준다. 백업 파일이 있는지만 보지 말고 복원 시험까지 해 둬야 한다.

실제로 장애가 나면 나는 먼저 외부 접속 가능 여부와 회선 사용량을 확인하고, 다음으로 웹서버 오류와 자원 사용량을 본다. 회선 문제면 업체에 바로 연락하고, 웹 요청 문제면 부담이 큰 경로부터 제한한다. 조치한 시각과 지표 변화도 남긴다. 그래야 효과가 없는 규칙을 빨리 걷어낼 수 있다.

작은 사이트일수록 거창한 장비보다 관측할 지표 네 가지와 연락할 업체, 되돌릴 수 있는 설정이 더 쓸모 있다. 평소 트래픽의 범위를 알고 있으면 공격이 왔을 때 무엇이 비정상인지 훨씬 빨리 보인다.