Managed Ruleset 켜고 오탐(False Positive) 줄이기

 

Managed Ruleset 켜고 오탐 줄이기

관리형 규칙(Managed Ruleset)은 Cloudflare가 미리 만들어 둔 보안 규칙 묶음입니다. 켜기만 하면 알려진 공격이 걸러지니 편합니다. 문제는 켠 다음입니다. 정상적인 내 작업까지 막히기 시작합니다.

안녕하세요, 코딩하는 안다형입니다. 이런 현상을 오탐(False Positive)이라고 합니다. 이 글에서는 오탐을 방어를 유지한 채 줄이는 방법을 정리했습니다. 핵심은 규칙 세트를 통째로 끄지 않는 것입니다.

3줄 요약
1. 오탐이 나면 보안 이벤트 로그에서 Rule ID를 찾는 것이 첫걸음입니다.
2. 규칙 세트 전체를 끄지 말고 그 Rule ID만, 그 경로에서만 예외로 두세요.
3. 예외를 넣은 뒤에는 다시 로그를 확인합니다. 한 번에 끝나는 경우는 드뭅니다.

 

오탐 줄이는 순서: 로그 확인, 규칙 특정, 범위 지정, 재확인

오탐은 왜 생기나

관리형 규칙은 공격에서 흔히 보이는 문자열 패턴을 찾습니다. 그런데 그 패턴이 정상 콘텐츠에도 들어갈 수 있습니다.

• 기술 블로그에서 SQL 예제를 쓸 때: 본문에 SELECT나 UNION 같은 단어가 들어갑니다. 규칙은 이걸 인젝션 시도로 볼 수 있습니다.
• HTML이나 스크립트 코드를 글에 넣을 때: 태그 문자열이 XSS 패턴과 겹칩니다.
• 이미지나 파일을 업로드할 때: 요청 본문이 커지고 형태가 특이해 검사에 걸립니다.
• API를 호출할 때: JSON 본문의 특정 문자 조합이 패턴에 걸립니다.

즉 오탐은 버그가 아니라 규칙의 성질입니다. 넓게 잡으면 놓치는 공격이 줄지만 오탐이 늘고, 좁게 잡으면 반대가 됩니다. 그래서 내 사이트에 맞게 조정하는 작업이 따라와야 합니다.

1단계. 로그에서 원인 찾기

가장 중요한 단계입니다. 추측하지 말고 기록을 보세요.

1. Cloudflare 대시보드에서 보안 → 이벤트로 들어갑니다.
2. 차단이 일어난 시간대로 범위를 좁힙니다.
3. 해당 항목을 펼치면 규칙 이름과 Rule ID, 그리고 어떤 필드가 걸렸는지가 나옵니다.
4. 요청 경로도 함께 확인합니다. 예외 범위를 정할 때 필요합니다.

방문자가 차단 화면을 봤다고 알려 왔다면 화면의 Ray ID를 받아 두세요. 그 값으로 검색하면 해당 요청 한 건을 바로 찾을 수 있습니다.

2단계. 예외의 범위를 최대한 좁히기

여기서 판단이 갈립니다. 급하다고 규칙 세트를 통째로 끄면 방어가 사라집니다. 아래로 갈수록 안전한 방법입니다.

• 가장 나쁨: 관리형 규칙 세트를 전부 끕니다. 오탐은 사라지지만 방어도 사라집니다.
• 나쁨: 문제가 된 규칙을 사이트 전체에서 끕니다. 그 공격 유형에 대해 무방비가 됩니다.
• 좋음: 문제가 된 규칙을 해당 경로에서만 끕니다. 나머지 페이지는 계속 보호됩니다.
• 가장 좋음: 해당 경로 + 내 IP 처럼 조건을 겹쳐 좁힙니다. 공격자가 같은 경로로 와도 여전히 막힙니다.

예를 들어 글 저장이 막혔다면, 규칙 전체를 끄는 대신 에디터 저장 경로에서 그 Rule ID만 건너뛰게 하는 식입니다.

3단계. 예외를 만드는 두 가지 방법

방법 1. 관리형 규칙 화면에서 직접 조정

유료 플랜에서 관리형 규칙 세트를 쓴다면, 규칙 목록에서 해당 Rule ID를 찾아 동작을 끄거나 조치를 낮출 수 있습니다. 예외 조건을 함께 지정할 수 있어 가장 깔끔합니다.

방법 2. Skip 규칙 만들기 (무료에서도 가능)

사용자 정의 규칙에서 Skip 조치를 쓰면, 조건에 맞는 요청에 대해 이후의 보안 검사를 건너뛸 수 있습니다. 표현식은 이런 형태입니다.

(http.request.uri.path contains "/wp-admin/post.php" and ip.src eq 내IP주소)

여기에 조치로 Skip을 선택하고, 건너뛸 대상으로 관리형 규칙을 지정합니다. 중요한 점이 하나 있습니다. Skip 규칙은 차단 규칙보다 위에 두어야 합니다. 규칙은 위에서 아래로 평가되기 때문입니다.

무료 플랜은 사용자 정의 규칙 개수가 제한되니, 이 Skip 규칙 하나에 필요한 예외를 모아 담는 것도 방법입니다.

 

오탐이 자주 나는 상황과 조치 정리표

오탐이 자주 나는 상황

• 글 저장이 막힘: HTML과 스크립트 탐지 규칙입니다. 에디터 경로를 예외로 둡니다.
• 이미지 업로드 실패: 파일 업로드 검사입니다. 업로드 경로를 예외로 둡니다.
• API 호출 거부: 요청 본문 검사입니다. API 경로를 예외로 둡니다.
• 로그인 반복 실패: 무차별 대입 방어입니다. 관리자 IP를 허용합니다.
• 특정 단어로 차단: SQL 키워드 오탐입니다. 해당 Rule ID만 끕니다.

예외를 넣은 뒤 반드시 확인할 것

예외를 만들고 끝내면 위험합니다. 두 가지를 확인하세요.

• 막혔던 기능이 정상 동작하는가: 글 저장, 업로드 등 실제로 해보세요.
• 다른 조건에서는 여전히 막히는가: 휴대폰 데이터처럼 다른 네트워크로 접속해 해당 경로를 시도해 보세요. 여기서도 통과된다면 예외를 너무 넓게 잡은 것입니다.

그리고 며칠 뒤 로그를 다시 보세요. 같은 규칙에서 다른 경로의 오탐이 새로 보이는 경우가 흔합니다. 오탐 조정은 한 번에 끝나지 않고 몇 차례 반복하며 다듬는 작업입니다.

이건 하지 마세요

• 규칙 세트를 통째로 끄기: 가장 흔하고 가장 위험한 대응입니다. 방어가 통째로 사라집니다.
• 보안 수준을 최저로 낮춰 해결: 증상은 사라지지만 원인은 그대로이고 전체 방어가 약해집니다.
• Rule ID 확인 없이 예외 만들기: 엉뚱한 규칙을 끄게 됩니다. 로그부터 보세요.
• Skip 규칙을 차단 규칙 아래에 두기: 위에서 이미 차단되어 Skip이 실행되지 않습니다.
• 예외를 만들고 검증 없이 끝내기: 너무 넓게 열렸는지 확인해야 합니다.

자주 묻는 질문

Q. 무료 플랜에서도 관리형 규칙을 조정할 수 있나요?

규칙 세트 자체를 세밀하게 조정하는 것은 유료 구간입니다. 다만 사용자 정의 Skip 규칙으로 특정 조건의 요청을 검사에서 제외하는 방식은 무료에서도 가능합니다.

Q. 오탐이 무서워서 아예 안 켜는 건 어떤가요?

권하지 않습니다. 오탐은 조정할 수 있는 문제이고, 방어가 없는 상태는 조정할 수 없는 문제입니다. 조치를 Managed Challenge로 낮춰 시작하면 피해를 줄이면서 관찰할 수 있습니다.

Q. Rule ID가 로그에 안 보입니다.

항목을 펼쳐야 상세가 나옵니다. 그래도 없다면 관리형 규칙이 아니라 보안 수준이나 봇 차단에 걸린 것일 수 있습니다. 로그의 서비스 항목을 확인해 어디서 차단됐는지 먼저 구분하세요.

Q. 예외를 넣었는데도 계속 막힙니다.

세 가지를 확인하세요. 규칙 순서(Skip이 위에 있는지), 경로 표기(대소문자와 슬래시), 다른 규칙(속도 제한이나 봇 차단에 별도로 걸렸는지)입니다.

Q. 방문자가 차단됐다고 연락이 왔습니다.

화면에 표시된 Ray ID를 받으세요. 보안 이벤트에서 그 값으로 검색하면 해당 요청의 규칙과 조건을 정확히 볼 수 있습니다. 추측보다 훨씬 빠릅니다.

Q. 오탐 조정은 얼마나 자주 해야 하나요?

규칙을 켠 직후 일주일 정도는 로그를 자주 보고, 안정되면 월 단위로 훑어보면 충분합니다. 사이트에 새 기능을 붙였을 때는 다시 확인하세요.

마무리

정리하면 로그에서 Rule ID 확인 → 경로와 조건을 좁혀 예외 생성 → 기능과 방어를 함께 검증 → 며칠 뒤 재확인 순서입니다.

기억할 한 줄은 이겁니다. 오탐의 해결책은 규칙을 끄는 것이 아니라 좁히는 것입니다. 다음 글에서는 관리자 페이지가 막혀 자기 자신이 잠겼을 때 안전하게 푸는 방법을 다루겠습니다.

 

함께 보면 좋은 글

• 웹호스팅 · VPS · 클라우드 뭘 골라야 할까
• 티스토리 2차 도메인 연결하는 방법
• 그누보드 메일 발송 설정하는 방법