WAF 규칙, 차단하기 전에 집계부터

먼저 집계 모드로 2주를 돌립니다

요청 내용을 보고 차단하는 규칙은 오탐이 생깁니다. 정상 요청이 공격으로 분류되면 사용자가 서비스를 쓸 수 없게 되고, 그 원인이 방화벽이라는 사실을 찾기까지 시간이 걸립니다. 그래서 규칙을 바로 차단으로 켜지 않습니다. 1단계로 집계 모드로 설정해 어떤 요청이 규칙에 걸리는지만 기록합니다. 2단계로 2주 동안 기록을 모읍니다. 3단계로 걸린 요청을 살펴 정상 요청이 섞여 있는지 확인합니다. 4단계로 정상 요청을 걸러내는 예외를 추가합니다. 5단계에서만 차단으로 바꿉니다. 이 순서를 지키면 차단 전환 뒤 문의가 거의 생기지 않습니다.

규칙을 묶음으로 켜지 말고 하나씩 봅니다

관리형 규칙 묶음은 수십 개 규칙을 한 번에 켭니다. 편하지만 어느 규칙이 오탐을 내는지 알 수 없습니다. 그래서 묶음을 켠 뒤 집계 기록을 규칙별로 집계해 상위 항목부터 검토합니다. 대개 몇 개 규칙이 오탐의 대부분을 만듭니다. 그 규칙만 예외 처리하거나 끄면 나머지는 그대로 차단으로 쓸 수 있습니다. 또 우리 서비스의 정상 동작이 공격 패턴과 닮은 경우가 있습니다. 긴 문자열을 본문에 보내는 기능이나 특수 문자를 많이 쓰는 입력이 그렇습니다. 그런 경로는 규칙 적용 범위에서 미리 제외합니다.

오탐 비율을 금액으로 환산합니다

학습용 가정으로 계산합니다. 가정값은 월 요청 1,000,000건이고 차단 전환 뒤 오탐 비율이 0.3퍼센트라고 두겠습니다. 잘못 차단되는 요청은 3,000건입니다. 그중 일부가 문의로 이어지는데, 월 30건의 문의가 들어오고 건당 대응에 10분이 걸린다고 가정하면 300분입니다. 내부 시간 비용을 시간당 30,000원으로 가정하면 150,000원입니다. 이것이 중간 계산값입니다. 최종 손실에는 문의하지 않고 떠난 사용자의 몫이 더해지므로 실제 비용은 더 큽니다. 그래서 집계 모드 2주의 비용이 이보다 작다면 순서를 지키는 것이 합리적입니다.

차단 자체가 목적이 아닌 경우가 있습니다

결론을 뒤집는 조건은 공격의 성격입니다. 특정 주소에서 오는 단순 반복 요청이라면 규칙으로 내용을 검사하기보다 요청 수 제한이 효과적이고 오탐도 적습니다. 반대로 정상 사용자와 구분하기 어려운 분산 요청이라면 내용 기반 규칙도 요청 수 제한도 어렵고, 가입이나 인증 단계를 강화하는 쪽이 맞습니다. 그래서 규칙을 늘리기 전에 공격 유형을 분류합니다. 두 번째 조건은 비용입니다. 검사 규칙은 요청마다 비용이 발생하므로, 전체 트래픽에 모든 규칙을 적용하면 금액이 커집니다. 그래서 민감한 경로에만 범위를 좁혀 적용합니다.

서버 운영 실행 전 점검표

• 집계 모드로 2주 기록을 모은 뒤 차단으로 바꿨다
• 규칙별 집계로 오탐 상위 항목을 찾아 예외 처리했다
• 공격 패턴과 닮은 정상 경로를 적용 범위에서 제외했다
• 공격 유형을 분류하고 적용 범위를 좁혔다