모두
모두콘텐츠
얼마 전 작은 쇼핑몰에서 로그인 시도가 급증해 웹방화벽을 붙였는데, 정작 주문이 막혀 전화가 왔습니다. 공격 요청도 걸러졌지만 정상적인 결제 요청까지 차단된 겁니다. 웹방화벽은 켜는 것보다 어디에 두고 어떤 요청을 막을지 정하는 일이 더 중요합니다.
먼저 웹방화벽이 막을 수 있는 문제를 구분합니다
웹방화벽은 브라우저와 웹서버 사이에서 요청을 검사합니다. 로그인 주소를 반복해서 두드리거나, 입력값에 공격 패턴을 섞거나, 특정 경로에 비정상적으로 많은 요청을 보내는 상황에 대응할 수 있습니다. 일반적인 서버 방화벽이 포트와 접속 대상을 주로 다룬다면 웹방화벽은 요청 경로, 헤더, 입력값 같은 웹 요청의 내용을 봅니다.
그렇다고 서버 문제를 대신 해결해 주지는 않습니다. 관리 프로그램의 취약점, 잘못 열린 관리자 계정, 유출된 비밀번호는 따로 고쳐야 합니다. 디스크가 가득 차거나 데이터베이스가 느려서 생기는 장애에도 효과가 없습니다. 대규모 트래픽 공격은 회선과 네트워크 단계의 방어 능력도 함께 봐야 합니다. 웹방화벽 하나를 붙였다는 이유로 백업이나 업데이트를 미루면 사고 지점만 바뀝니다.
처음부터 유료 상품이 필요한 사이트는 생각보다 적습니다. 방문자가 적고 로그인이나 결제 기능이 없다면, 서버 업데이트와 관리자 계정 보호, 백업 확인이 먼저입니다. 반대로 로그인·회원가입·검색·주문처럼 요청이 집중되는 기능이 있고 공격 로그가 반복된다면 웹방화벽의 효용을 판단할 근거가 생깁니다.
트래픽보다 요청 수와 피크를 계산합니다
요금제를 볼 때 월 방문자 수만 적혀 있으면 판단하기 어렵습니다. 웹방화벽은 상품에 따라 검사한 요청 수, 적용 규칙, 로그 보관량 등에 비용이 붙습니다. 페이지 한 번을 열 때 문서·이미지·스크립트 등 요청이 몇 건 나가는지부터 확인해야 합니다. 캐시된 파일을 과금 요청에 포함하는지도 서비스마다 다르니 청구 기준을 읽어야 합니다.
예를 들어 하루 10만 페이지뷰에 페이지당 요청이 평균 20건이면 하루 요청은 약 200만 건입니다. 하루 평균으로 나누면 초당 약 23건이지만, 특정 시간대에 10배가 몰리면 초당 230건 안팎을 처리해야 합니다. 이 수치는 요금제 비교를 위한 출발점입니다. 실제로는 접속 로그에서 가장 바쁜 5분의 요청 수와 로그인·검색 경로의 비중을 따로 보는 편이 정확합니다.
호스팅 공유 상품이라면 서버 앞단에 제공되는 기본 보안 기능부터 확인하면 됩니다. 별도 웹방화벽 비용이 서버 요금보다 커지는 작은 사이트도 있습니다. VPS에 직접 웹방화벽을 설치할 수도 있지만, 규칙 업데이트와 오탐 대응, 로그 저장 공간까지 운영자가 맡아야 합니다. 관리할 시간이 없다면 저렴한 자체 설치가 실제로는 더 비쌀 수 있습니다.
차단 전에 로그로 정상 요청을 확인합니다
새 규칙을 한꺼번에 차단 모드로 켜면 고객이 먼저 문제를 발견할 수 있습니다. 저는 로그인, 회원가입, 게시글 작성, 파일 업로드, 결제처럼 입력값이 많은 경로를 목록으로 적고 실제 요청을 재현합니다. 가능하다면 처음에는 탐지 또는 기록 모드로 두고 규칙별 적중 로그를 봅니다. OWASP의 코어 룰셋처럼 널리 쓰이는 규칙도 사이트 기능에 맞춰 조정해야 합니다.
- 차단된 요청에서 경로, 시간, 규칙 번호, 응답 코드를 확인합니다. 개인정보가 담긴 요청 본문은 로그에 과하게 남기지 않습니다.
- 정상 요청이 걸렸다면 사이트 전체를 허용하지 말고 해당 경로와 규칙으로 예외 범위를 좁힙니다.
- 로그인 시도 제한은 일반 페이지와 분리합니다. 여러 이용자가 한 공인 IP를 공유할 수 있어 IP만으로 세게 막으면 정상 이용자도 묶입니다.
- 적용 직후에는 주문·문의·관리자 작업을 직접 시험하고, 이후에도 차단율과 오류율을 함께 봅니다.
특히 검색어나 게시글에는 코드처럼 보이는 문자열이 정상적으로 들어올 수 있습니다. 규칙 적중 건수만 늘었다고 방어가 잘되는 것은 아닙니다. 차단이 늘어난 시각에 주문 완료율이나 로그인 성공률이 떨어졌다면 오탐부터 의심합니다. 문제가 생겼을 때 바로 이전 설정으로 돌릴 수 있도록 규칙 변경 시각과 담당자도 남겨둡니다.
우회 경로와 장애 대응 순서를 점검합니다
외부 웹방화벽을 앞에 세웠는데 원본 서버에 직접 접속할 수 있으면 공격자는 검사 단계를 건너뛸 수 있습니다. 원본 서버는 웹방화벽에서 오는 연결만 받도록 제한하고, 관리 접속은 별도 경로로 운영하는 편이 안전합니다. 중계 장비가 전달한 방문자 IP를 서버에서 사용할 때도 신뢰할 중계 장비만 지정해야 합니다. 아무 요청에나 담긴 IP 헤더를 믿으면 로그와 접속 제한이 틀어집니다.
장애가 나면 순서를 고정해 두는 게 빠릅니다. 먼저 웹방화벽의 차단 로그와 응답 코드를 확인하고, 다음으로 원본 서버까지 요청이 도착했는지 봅니다. 원본에 도착했다면 웹서버와 애플리케이션 로그, 데이터베이스 상태를 확인합니다. 원본에 도착하지 않았다면 규칙, 접속 제한, 인증서와 연결 설정을 봅니다. 이 순서가 없으면 웹방화벽 탓으로만 돌리다가 실제 장애를 늦게 찾습니다.
웹방화벽을 도입해도 백업 복구 시험은 남습니다. 차단 규칙은 잘못된 요청을 줄이는 장치이지 삭제된 데이터나 손상된 서버를 되돌리는 장치가 아닙니다. 작은 사이트라면 기본 보안 설정과 검증된 백업으로 충분한 시기가 길 수 있습니다. 요청이 늘고 공격 양상이 확인될 때, 그 로그를 근거로 필요한 규칙과 요금제를 하나씩 더하는 편이 운영에도 비용에도 맞습니다.
