모두
모두콘텐츠
얼마 전 작은 쇼핑몰 서버에서 로그인 시도가 갑자기 늘었다. 접속량만 보면 서버를 키워야 할 것 같았지만, 실제로는 몇 개의 경로에 반복 요청이 몰리고 있었다. 이런 경우 웹방화벽을 붙이면 서버 증설보다 적은 비용으로 부담을 줄일 수 있다. 다만 규칙을 켜는 것보다 정상 주문과 로그인을 막지 않도록 배치하고 확인하는 일이 더 중요하다.
먼저 어디에 설치할지 정한다
웹방화벽은 웹 요청의 경로, 매개변수, 헤더 등을 보고 의심스러운 요청을 차단한다. 서버 포트를 막는 일반 방화벽과 역할이 다르고, 모든 대용량 공격을 막는 장비도 아니다. 설치 방식은 크게 두 가지다. 외부 서비스가 방문자와 원본 서버 사이에서 요청을 검사하게 하거나, VPS의 웹서버 앞단에 방화벽 모듈을 두는 방식이다.
공유 웹호스팅처럼 서버 설정 권한이 없다면 외부 서비스를 쓰는 편이 현실적이다. VPS에서 웹서버 설정을 직접 관리한다면 모듈 방식도 가능하다. 다만 규칙 처리에 필요한 메모리와 CPU가 같은 서버 자원을 쓴다. 하루 10만 페이지뷰를 24시간으로 나누면 평균은 초당 약 1.2페이지뷰다. 피크가 평균의 10배이고 페이지마다 동적 요청이 3번 발생한다면 대략 초당 36건을 기준으로 부하를 살펴볼 수 있다. 실제 피크와 요청 수는 접속 로그로 확인해야 한다. 이 정도 규모에서 방화벽 때문에 무조건 고가 서버로 옮길 이유는 없다.
적용 전에 복구할 길부터 만든다
설치를 시작하기 전 웹서버 설정과 방화벽 설정을 백업하고, 현재 DNS 값과 인증서 구성을 기록한다. 주문, 로그인, 관리자 접속, 파일 업로드처럼 막히면 곧바로 문제가 되는 기능도 목록으로 적어 둔다. 적용 후 장애가 나면 어느 설정을 되돌릴지 알아야 한다. 백업 파일이 있다는 것만으로는 부족하다. 설정을 복원하는 명령과 담당자가 접근할 수 있는 경로까지 확인해야 한다.
외부 서비스를 쓴다면 방문자부터 방화벽, 원본 서버까지 연결이 어떻게 이어지는지 먼저 확인한다. 방화벽 구간에만 암호화를 적용하고 원본 서버로 가는 구간을 평문으로 두지 않는다. 원본 서버의 인증서 유효 기간과 이름 일치 여부도 확인한다. 원본 서버 주소가 공개돼 있으면 공격자가 방화벽을 거치지 않고 직접 접속할 수 있다. 정상 경로가 작동하는 것을 확인한 뒤 원본의 웹 접속을 방화벽 서비스가 사용하는 주소 범위로 제한한다. 관리 접속과 상태 점검 경로는 별도로 확보하고, 서비스가 주소 범위를 바꿀 때 반영할 절차도 필요하다.
차단보다 기록 모드로 먼저 검증한다
서버 모듈 방식이라면 웹서버 종류와 버전에 맞는 모듈을 설치하고 설정 파일의 문법 검사부터 통과시킨다. 일반적인 공격 탐지 규칙을 불러온 뒤에는 바로 전체 차단을 켜지 않는다. 기록만 남기는 모드에서 정상 요청이 어떤 규칙에 걸리는지 본다. 외부 서비스 방식도 처음에는 관리형 규칙을 낮은 강도로 적용하거나 기록을 확인할 수 있는 설정부터 시작하는 편이 안전하다.
특히 로그인, 검색, 게시판 글쓰기, 결제 콜백, 파일 업로드는 직접 실행해 봐야 한다. 검색어에 기호가 들어가거나 게시글에 코드 조각이 포함되면 공격으로 오인할 수 있다. 차단 기록에서는 요청 시간, 경로, 규칙 번호, 처리 결과를 함께 본다. 정상 기능이 막힌다면 방화벽 전체를 끄기보다 해당 경로와 규칙의 조합을 좁혀 조정한다. 반대로 로그인 경로에 짧은 시간 동안 수백 건의 실패가 쌓인다면 속도 제한을 검토할 만하다. 관리자 자신의 접속만 성공하는 것으로 검증을 끝내면 고객이 쓰는 경로를 놓치기 쉽다.
전환 후에는 원인별로 확인한다
DNS를 바꾸는 방식이라면 방문자가 적은 시간에 전환하고, 이전 설정을 바로 복원할 수 있게 둔다. 설정한 캐시 시간이 짧아도 일부 이용자에게는 전환 전 정보가 더 오래 남을 수 있다. 전환 직후에는 정상 페이지 응답, 로그인, 주문 완료와 함께 방화벽의 차단 건수, 원본 서버의 오류율, 응답 시간을 비교한다. 차단 건수만 늘고 원본 서버의 요청이 줄었다면 기대한 동작일 수 있지만, 주문 실패까지 늘었다면 규칙을 다시 봐야 한다.
장애가 나면 순서를 고정해 두는 게 빠르다. 접속 자체가 안 되면 DNS와 인증서, 방화벽에서 원본으로 이어지는 연결을 확인한다. 일부 기능만 실패하면 해당 요청의 차단 기록을 찾는다. 오류 응답이 늘었는데 차단 기록이 없다면 원본 서버의 웹서버와 애플리케이션 로그를 본다. 외부 서비스를 붙인 뒤 접속자 주소가 모두 방화벽 주소로 기록된다면 실제 접속자 주소를 전달하는 헤더 설정도 점검해야 한다. 이 헤더는 신뢰하는 프록시에서 온 요청에만 적용해야 주소를 속이는 요청을 막을 수 있다.
운영하면서 가장 자주 보는 실패는 설치 자체보다 예외 규칙을 넓게 풀어 둔 뒤 잊는 경우다. 작은 사이트라면 기본 규칙과 제한적인 속도 제어만으로도 시작할 수 있다. 한 번에 많은 규칙을 켜기보다 기록을 보고 필요한 차단을 하나씩 더하는 편이 장애가 났을 때 원인을 찾기도 쉽다.
