웹 방화벽 보안 정책 세우는 방법

얼마 전 로그인 장애를 확인했는데 서버 자원은 한가했습니다. 원인은 전날 켠 웹 방화벽 규칙이었습니다. 회사 회선 하나로 접속하던 직원들의 로그인 요청이 같은 IP에서 몰리자 공격으로 판단한 겁니다. 웹 방화벽은 규칙을 많이 켠다고 안전해지지 않습니다. 정상 요청을 막지 않으면서 위험한 요청을 가려내는 순서가 중요합니다.

먼저 정상 트래픽을 숫자로 잡습니다

웹 방화벽 보안 정책을 만들기 전에 최소 일주일치 접속 기록을 봅니다. 시간대별 요청 수, 로그인과 검색 같은 주요 경로의 요청 수, 정상 이용자의 최대 요청 빈도를 따로 확인합니다. 월 방문자 수만으로는 차단 기준을 정하기 어렵습니다. 같은 10만 방문이라도 하루 종일 고르게 들어오는 사이트와 행사 시작 10분에 몰리는 사이트는 필요한 기준이 다릅니다.

예를 들어 평소 분당 100건이던 로그인 요청이 특정 시간에 400건까지 올라왔다고 해도, 그 자체로 공격은 아닙니다. 성공한 로그인 비율, 실패가 발생한 계정 수, 동일 IP의 반복 여부를 함께 봐야 합니다. 사무실이나 이동통신망처럼 여러 사람이 한 IP를 공유하는 환경도 있습니다. IP별 요청 수 하나만 보고 차단하면 정상 이용자가 함께 막힙니다.

• 전체 요청량과 로그인·검색·관리 화면의 요청량을 나눠 기록합니다.
• 가장 바쁜 시간의 정상 요청 빈도와 응답 지연을 확인합니다.
• 점검 도구, 결제 알림, 앱 연동 요청처럼 자동으로 들어오는 정상 트래픽을 표시합니다.

공통 규칙은 관찰한 뒤 차단합니다

운영을 시작할 때는 검증된 관리형 규칙을 기본으로 두되, 새 규칙의 동작을 먼저 기록 모드로 설정하는 편이 안전합니다. 며칠 동안 어떤 요청이 걸리는지 확인하고 정상 이용자의 요청이 섞여 있으면 해당 규칙이나 적용 경로를 조정합니다. AWS WAF의 기록 모드처럼 실제 차단 없이 일치한 요청을 확인할 수 있는 기능이 이때 유용합니다.

특히 게시판의 코드 예시, 검색어, 파일 업로드는 공격 문자열과 비슷한 내용을 정상적으로 받을 수 있습니다. 게시글에 데이터베이스 명령어가 들어갔다는 이유만으로 글쓰기 전체를 막으면 서비스 장애가 됩니다. 오탐이 나오면 방화벽을 통째로 끄기보다 어떤 규칙이 어느 경로에서 걸렸는지 찾습니다. 예외는 필요한 경로와 요청 방식에만 좁게 적용하고, 만료일과 담당자를 남겨 둡니다.

규칙 순서도 확인해야 합니다. 앞선 허용 규칙이 뒤의 검사까지 건너뛰게 만드는 제품이라면 넓은 허용 조건 하나가 여러 보호 규칙을 무력화할 수 있습니다. 정책 적용 후에는 정상 로그인, 글쓰기, 파일 업로드, 결제 흐름을 직접 실행해 봅니다. 차단 건수만 늘고 정상 요청의 실패율도 함께 오른다면 정책을 다시 손봐야 합니다.

속도 제한은 기능별로 다르게 둡니다

속도 제한은 사이트 전체에 숫자 하나를 걸기보다 비용이 큰 기능에 먼저 적용합니다. 로그인, 비밀번호 재설정, 검색, 파일 생성 요청은 성격이 다릅니다. 예를 들어 로그인 경로에 5분 동안 IP당 60건을 관찰 기준으로 걸 수는 있습니다. 다만 이 숫자는 권장 기본값이 아닙니다. 실제 정상 사용량과 공유 IP 비율을 보고 조정해야 합니다.

로그인 공격은 IP를 바꿔 가며 들어올 수도 있어 IP 제한만으로 끝나지 않습니다. 계정별 실패 횟수, 짧은 시간에 시도한 계정 수, 인증 성공 여부를 같이 확인하는 편이 낫습니다. 반대로 검색은 사용자가 화면을 빠르게 넘길 때 요청이 연속으로 발생할 수 있습니다. 무조건 차단하기보다 먼저 서버가 감당할 수 있는 요청량과 검색 기능의 응답 시간을 측정합니다.

국가 단위 차단도 신중해야 합니다. 해외 이용자가 거의 없는 서비스에는 도움이 될 수 있지만, 출장 중인 관리자나 해외 결제 이용자까지 막을 수 있습니다. 공격이 몰린다는 이유만으로 넓게 차단하기 전에 영향받는 정상 이용자가 있는지 접속 기록으로 확인합니다.

장애가 나면 방화벽 기록과 서버 기록을 같이 봅니다

웹 방화벽에서 요청을 막으면 애플리케이션 서버에는 해당 요청이 남지 않을 수 있습니다. 그래서 장애를 조사할 때 서버 기록만 보면 원인을 놓칩니다. 발생 시각, 요청 경로, 적용된 규칙, 방화벽 동작, 응답 코드를 한 줄로 이어서 봐야 합니다. OWASP도 보안 기록이 실제 조사에 쓰이도록 필요한 맥락을 남기고 민감한 정보의 기록은 피하도록 안내합니다. 비밀번호나 인증 정보 전체를 로그에 남길 필요는 없습니다.

현장에서 확인하는 순서는 단순합니다. 먼저 장애가 특정 기능에만 있는지 확인하고, 같은 시각의 방화벽 차단 증가와 서버 오류 증가를 비교합니다. 최근 바꾼 규칙이 있다면 해당 규칙을 기록 모드로 되돌린 뒤 정상 요청이 회복되는지 봅니다. 되돌린 시간과 이유를 남기면 다음 변경 때 같은 실수를 줄일 수 있습니다.

• 정책 변경 전에는 현재 설정을 내보내고 복구 방법을 확인합니다.
• 차단 급증, 로그인 성공률 하락, 정상 요청의 오류 증가에 알림을 겁니다.
• 원본 서버에 직접 접속할 수 있다면 방화벽 우회 경로가 되는지 점검합니다.

요금보다 운영할 수 있는 정책이 중요합니다

작은 사이트라면 비싼 보안 상품부터 살 이유는 적습니다. 기본 방화벽 규칙, 필요한 경로의 속도 제한, 접속 기록 확인만으로 시작할 수 있는 구간이 많습니다. 대신 상품을 고를 때는 월 요청량뿐 아니라 규칙 수, 기록 보관과 조회 비용, 초과 요금도 확인해야 합니다. 트래픽이 늘었을 때 기록 비용이 예상보다 커지는 경우가 있습니다.

방화벽은 애플리케이션의 권한 검사나 백업을 대신하지 못합니다. 관리자 계정 보호, 소프트웨어 갱신, 복구 가능한 백업을 함께 운영해야 합니다. 제가 보는 좋은 정책은 차단 건수가 많은 정책이 아니라, 장애가 났을 때 어떤 규칙이 왜 작동했는지 바로 설명하고 안전하게 되돌릴 수 있는 정책입니다.