2026년 6월 15일 Cloudflare가 Ghost CMS의 블라인드 SQL 주입 취약점(CVE-2026-26980)에 대한 WAF 규칙을 배포했다고 발표했습니다. 난독화된 부울 로직 우회 시도까지 블로킹한다고 합니다.

Ghost CMS 사용자가 아니라도 눈여겨봐야 할 소식입니다. 웹 애플리케이션 취약점은 계속 나오고, Cloudflare가 잡아주지 않는 취약점도 많습니다. 자체 서버에서 웹 애플리케이션 방화벽(WAF)을 갖추면 이런 소식이 발표될 때마다 손 놓고 기다리지 않아도 됩니다.

이 글에서는 자체 서버에 ModSecurity + OWASP Core Rule Set(CRS) 조합으로 WAF를 구축하는 절차와 실무 함정을 정리합니다.

이번 CVE의 요점

  • 대상: Ghost CMS (여러 버전)
  • 유형: Blind SQL Injection
  • 난이도: 비인증 원격 공격 가능성
  • 특징: 부울 기반 시간 지연 응답을 이용해 데이터 유출

Blind SQLi는 응답 본문에 직접 데이터가 나오지 않아도, 참/거짓 응답 차이·시간 지연으로 정보를 추측하는 공격입니다. 방어가 어려운 이유는 정상 쿼리와 페이로드의 표층 차이가 작기 때문. 그래서 정교한 규칙 세트가 필요합니다.

Cloudflare WAF vs 자체 서버 WAF

Cloudflare WAF는 실시간 위협 인텔·전 세계 트래픽 신호를 기반으로 규칙을 만듭니다. 자체 서버는 그런 신호는 없지만 트래픽이 우리 손 안에 있고, 규칙을 정확히 우리 앱에 맞게 튜닝할 수 있습니다.

두 접근이 배타적이지 않습니다. Cloudflare 앞단 + 자체 서버 뒷단에 ModSecurity를 두는 다층 방어(defense-in-depth)가 이상적. Cloudflare가 걸러낸 뒤 우리 서버가 한 번 더 걸러냅니다.

ModSecurity + OWASP CRS 세팅 (Nginx)

TCP-80.NET의 일본 VPS나 전용서버에서 Ubuntu 22.04 기준으로 설명합니다.

1) ModSecurity 설치

apt update
apt install -y libmodsecurity3 libmodsecurity-dev

Nginx 커넥터는 Nginx 소스에서 빌드해야 합니다.

apt install -y nginx nginx-plus-module-modsecurity  # Nginx Plus라면
# 또는
# 오픈소스 nginx는 modsecurity-nginx 모듈을 소스 빌드
apt install -y libnginx-mod-http-modsecurity

배포판에 따라 libnginx-mod-http-modsecurity가 별도 저장소에 있을 수 있습니다.

2) OWASP Core Rule Set 다운로드

cd /etc/nginx
git clone https://github.com/coreruleset/coreruleset.git modsec-crs
cd modsec-crs
cp crs-setup.conf.example crs-setup.conf

CRS는 매년 업데이트되니 git으로 관리하고 정기적으로 pull.

3) ModSecurity 기본 설정

mkdir -p /etc/nginx/modsec
cd /etc/nginx/modsec

# 예제 conf 가져오기
wget https://raw.githubusercontent.com/SpiderLabs/ModSecurity/v3/master/modsecurity.conf-recommended \
  -O modsecurity.conf

# 감사(Audit) 모드로 시작 → 나중에 Block으로 전환
sed -i 's/SecRuleEngine DetectionOnly/SecRuleEngine On/' modsecurity.conf

4) main include 파일

# /etc/nginx/modsec/main.conf
Include /etc/nginx/modsec/modsecurity.conf
Include /etc/nginx/modsec-crs/crs-setup.conf
Include /etc/nginx/modsec-crs/rules/*.conf

5) Nginx 통합

# /etc/nginx/sites-available/example.com
server {
    listen 443 ssl http2;
    server_name example.com;

    modsecurity on;
    modsecurity_rules_file /etc/nginx/modsec/main.conf;

    # 나머지 설정
    location / {
        proxy_pass http://127.0.0.1:2368;  # Ghost CMS
    }
}

6) 재시작 및 로그 확인

nginx -t && systemctl reload nginx

# ModSecurity 감사 로그
tail -f /var/log/modsec_audit.log

# 차단된 요청 실시간 확인
grep -c "Access denied" /var/log/nginx/error.log

CRS 규칙 세트 개요

OWASP CRS는 몇 개 카테고리로 나뉩니다.

  • REQUEST-901-INITIALIZATION: 초기화·룰 예외 설정.
  • REQUEST-905-COMMON-EXCEPTIONS: 알려진 오탐 예외.
  • REQUEST-910-IP-REPUTATION: IP 평판(외부 리스트 연동).
  • REQUEST-911-METHOD-ENFORCEMENT: HTTP 메소드 제한.
  • REQUEST-913-SCANNER-DETECTION: 스캐너 봇 탐지.
  • REQUEST-920-PROTOCOL-ENFORCEMENT: HTTP 프로토콜 준수 강제.
  • REQUEST-921-PROTOCOL-ATTACK: 프로토콜 공격.
  • REQUEST-930-APPLICATION-ATTACK-LFI: 로컬 파일 포함.
  • REQUEST-931-APPLICATION-ATTACK-RFI: 원격 파일 포함.
  • REQUEST-932-APPLICATION-ATTACK-RCE: 원격 명령 실행.
  • REQUEST-933-APPLICATION-ATTACK-PHP: PHP 공격.
  • REQUEST-941-APPLICATION-ATTACK-XSS: XSS.
  • REQUEST-942-APPLICATION-ATTACK-SQLI: SQL 주입 (이번 CVE 관련).
  • REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION: 세션 고정.
  • REQUEST-949-BLOCKING-EVALUATION: 최종 차단 판정.

이번 Ghost CVE는 942 SQLi 규칙군이 대부분 잡습니다. 다만 blind SQLi의 정교한 페이로드는 놓칠 수 있어 별도 커스텀 룰 추가가 안전.

커스텀 룰 예시 — Blind SQLi 추가 방어

# /etc/nginx/modsec-crs/rules/custom-ghost-blind-sqli.conf
SecRule REQUEST_URI|ARGS "@rx (?i)(sleep\s*\(\s*[0-9]+|benchmark\s*\(|pg_sleep\s*\()" \
    "id:100001,\
    phase:2,\
    deny,\
    status:403,\
    msg:'Blind SQLi pattern detected',\
    logdata:'%{MATCHED_VAR}',\
    tag:'attack-sqli',\
    severity:CRITICAL"

sleep(), benchmark(), pg_sleep() 같은 시간 지연 함수가 URL·인자에 나타나면 차단. Blind SQLi의 대표 패턴.

튜닝 — DetectionOnly로 시작하는 이유

CRS를 처음 켜면 오탐이 반드시 나옵니다. 정상 사용자 요청이 특정 CRS 룰에 걸려 400·403이 되는 상황. 프로덕션에서 갑자기 켜면 매출 손실 직행.

권장 순서.

  1. SecRuleEngine DetectionOnly (감지만, 차단 안 함).
  2. 1~2주 정상 트래픽 관찰.
  3. modsec_audit.log에서 오탐 룰 ID 수집.
  4. 예외 규칙 작성.
  5. Paranoia Level 3~4에서 시작 → 서서히 올림(1이 관대, 4가 엄격).
  6. SecRuleEngine On 전환.

Paranoia Level 조정.

# /etc/nginx/modsec-crs/crs-setup.conf
SecAction "id:900000,\
    phase:1,\
    nolog,\
    pass,\
    t:none,\
    setvar:tx.paranoia_level=1"

1은 초보자 친화, 4는 최고 보안이지만 오탐 매우 많음. 일반 사이트는 1~2가 적정.

성능 영향

ModSecurity + CRS는 약 5~15%의 CPU·지연 오버헤드를 추가합니다. 큰 부하가 아닌 이상 무시 가능 수준. VPS 저사양이라면 걱정될 수 있지만 대부분의 웹 트래픽에서는 티가 안 납니다.

Cloudflare WAF는 엣지에서 처리하므로 원본 서버 부하가 없음. 이게 다층 방어(Cloudflare + 자체 ModSecurity)의 장점.

Ghost 사용자를 위한 즉시 조치

  • Ghost 최신 버전으로 업그레이드 (본질 조치).
  • 관리 API 접근을 IP 제한.
  • 관리자 계정 강한 비밀번호 + 2FA.
  • 정기 DB 백업 (3-2-1 원칙).
  • 자체 서버에 ModSecurity + CRS 도입 (다층 방어).

Ghost 자체는 훌륭한 CMS지만, 어떤 소프트웨어든 CVE는 나옵니다. 방어는 앱 업데이트 + 인프라 WAF의 조합이 안전합니다.

Cloudflare 없이 IP 평판까지 얹기

다음 편(위협 인텔리전스 WAF)에서 다룰 fail2ban·CrowdSec가 IP 평판 대응에 실용적입니다. ModSecurity와 조합하면 요청 페이로드 검사 + IP 평판 두 층 방어가 완성됩니다.

마무리

Cloudflare가 특정 CVE에 대응하는 WAF 규칙을 배포하는 건 반갑지만, 우리 뒤에도 안전망이 있어야 합니다. ModSecurity + CRS는 오픈소스이고 15년 넘게 검증된 조합. 하루 세팅에 서버 대부분의 웹 애플리케이션 취약점을 걸러줍니다.

TCP-80.NET의 일본 VPS·전용서버 고객 중 ModSecurity 세팅·튜닝을 함께 검토하고 싶으신 분은 @tcp80net 텔레그램으로 문의 주시면 됩니다.

출처 (Source)

이 글은 아래 Cloudflare 공식 changelog를 참고해 tcp-80.net 청중 관점에서 재구성·번역·확장했습니다. 자체 서버 WAF 구축 절차(ModSecurity + OWASP CRS·커스텀 룰·튜닝·성능 영향)는 원문에 없는 자체 추가 내용입니다.

Cloudflare 제품 옵션명·UI·WAF 규칙 목록은 시점에 따라 다를 수 있으니 최신 정보는 원문 및 Cloudflare 대시보드에서 확인하시기 바랍니다.