웹방화벽해제 전에 오탐부터 확인하는 방법

얼마 전 관리자 화면에서 저장 버튼만 누르면 403 오류가 난다는 연락을 받았다. 웹방화벽을 끄면 바로 해결될 것 같았지만, 이벤트 기록을 보니 특정 규칙이 긴 입력값을 공격으로 잘못 판단하고 있었다. 해당 규칙의 적용 범위를 좁히자 저장은 정상으로 돌아왔고 나머지 방어 규칙은 계속 작동했다. 웹방화벽해제를 요청받을 때 내가 먼저 확인하는 건 바로 이 지점이다.

403 오류가 곧 웹방화벽 차단은 아니다

웹방화벽은 요청이 서버에 도착하기 전에 내용을 검사한다. 공격으로 판단하면 차단하거나 추가 인증을 요구한다. 그런데 화면에 403이 떴다는 사실만으로 차단 주체를 단정할 수는 없다. 웹서버의 접근 권한 설정, 애플리케이션의 로그인 검사, 프록시 설정도 같은 상태 코드를 돌려줄 수 있다. 요청이 너무 많을 때 보이는 429 역시 웹방화벽 규칙일 수도, 애플리케이션의 요청 제한일 수도 있다.

먼저 실패한 시각과 요청 경로, 요청 방식, 응답 상태 코드를 적는다. 그다음 웹방화벽 이벤트와 웹서버 접근 기록을 같은 시간대에서 대조한다. 웹방화벽에는 차단 이벤트가 있는데 원본 서버에는 해당 요청이 없다면 앞단에서 막힌 경우가 유력하다. 반대로 원본 서버까지 요청이 들어왔다면 서버나 애플리케이션 기록을 더 봐야 한다. 프록시가 여러 층이면 각 장비의 시간이 같은 기준으로 기록되는지도 확인한다. 시계가 몇 분만 어긋나도 서로 다른 요청을 같은 사고로 착각하기 쉽다.

해제 범위는 재현한 요청만큼만 잡는다

차단 이벤트를 찾았다면 어떤 규칙이 무엇을 보고 반응했는지 살핀다. 관리자 저장 화면의 특정 입력란에서만 발생하는지, 로그인 시도 전체에서 발생하는지에 따라 조치가 달라진다. 정상 요청이라고 확인한 뒤에는 해당 규칙을 그 경로 또는 기능에 한해 예외 처리할 수 있는지 먼저 본다. 서비스 전체에서 웹방화벽을 끄는 설정은 정상 요청도 통과시키지만 실제 공격 요청도 함께 통과시킨다.

운영할 때는 아래 항목을 한 묶음으로 기록해 두면 변경 범위가 흐려지지 않는다.

재현 시각, 요청 경로와 방식, 차단된 규칙 식별자
실제 사용자의 요청인지 확인한 근거와 영향을 받는 기능
예외를 적용할 경로, 규칙, 요청 방식과 유지할 기간
변경 전 설정값, 되돌릴 방법, 변경 담당자

아이피 주소 하나를 허용 목록에 넣는 방법도 있지만 항상 안전한 선택은 아니다. 사무실과 공용망에서는 여러 사람이 같은 외부 아이피를 쓸 수 있고, 이동 중인 사용자는 주소가 바뀐다. 허용 목록이 방화벽의 다른 검사를 건너뛰게 만드는 방식인지도 제품 설정에서 확인해야 한다. 단순히 특정 사용자에게만 열었다고 생각했는데 더 넓은 트래픽이 검사를 피하는 경우가 있다.

변경 전후에는 정상 요청과 차단 요청을 같이 본다

설정을 바꾸기 전에 현재 규칙과 예외 목록을 저장한다. 가능하면 실제 서비스와 같은 규칙을 적용한 시험 환경에서 먼저 재현한다. 운영 환경에서 바로 수정해야 한다면 한 번에 한 항목만 바꾸고, 오류가 났던 요청을 다시 보낸다. 화면이 열린다는 사실만 확인하지 말고 저장 결과가 실제로 반영됐는지까지 봐야 한다.

반대쪽 확인도 필요하다. 예를 들어 관리자 저장 요청에 예외를 줬다면 일반 공개 화면과 로그인 경로의 차단 기록이 평소처럼 남는지 살핀다. 시험용 요청으로 검증할 때는 공격 문자열을 무작정 서비스에 반복 전송하기보다, 운영 중인 방화벽이 제공하는 시험 기능이나 통제된 환경을 쓰는 편이 낫다. 변경 직후 10~30분 동안 같은 규칙의 차단 건수, 오류율, 원본 서버의 요청량을 비교하면 예상보다 넓게 열린 설정을 빨리 발견할 수 있다. 트래픽이 적은 사이트라면 다음 실제 이용 시간대까지 확인해야 한다.

급하게 전체 차단을 풀어야 할 때의 순서

주문이나 로그인처럼 중요한 기능이 전부 멈췄고 원인이 웹방화벽이라는 기록도 확인됐다면, 일시적으로 검사 범위를 줄여 서비스를 복구해야 할 수 있다. 이때도 먼저 문제가 된 규칙이나 해당 기능만 조정할 수 있는지 본다. 전체 기능을 중지해야 한다면 시작 시각과 복구 예정 시각을 남기고, 원본 서버 접근 제한과 관리자 계정 보호 상태를 확인한 뒤 진행한다. 복구 후에는 누가 언제 원래 설정으로 되돌릴지 담당자를 정해 둬야 한다.

나는 장애 대응 중에 만든 예외를 며칠 뒤 다시 확인한다. 긴급한 순간에는 넓게 열 수밖에 없었다고 해도, 원인이 특정 입력값이나 배포 변경으로 밝혀지면 그에 맞춰 범위를 다시 좁힐 수 있다. 웹방화벽은 켜짐과 꺼짐 중 하나를 고르는 장치라기보다, 정상 요청이 지나가는 길을 확인하며 규칙을 다듬어 쓰는 장치에 가깝다.