🎯 WAF가 막아주는 주요 공격 유형들

WAF가 어떤 공격들을 방어하는지 구체적으로 알아볼까요? 각 공격 유형을 이해하면 WAF의 중요성이 더욱 명확해질 거예요.

🏗️ WAF의 주요 구성 요소와 작동 원리

WAF가 어떻게 작동하는지 내부 구조를 들여다볼까요? 복잡해 보이지만 원리를 이해하면 설정과 관리가 훨씬 쉬워져요.

📋 1. 규칙 엔진 (Rule Engine)

WAF의 두뇌라고 할 수 있는 부분이에요. 미리 정의된 규칙(Rule)들을 기반으로 들어오는 HTTP 요청을 분석하고 판단해요. 규칙은 크게 세 가지 유형으로 나뉘어요:

🔍 2. 트래픽 분석 엔진

HTTP/HTTPS 요청의 모든 부분을 세밀하게 분석하는 컴포넌트예요. 다음과 같은 요소들을 검사해요:

⚙️ 3. 정책 관리 시스템

보안 정책을 정의하고 관리하는 부분이에요. 관리자는 여기서 다음과 같은 설정을 할 수 있어요:

🎚️ 보안 레벨 설정
- Paranoid (편집증 모드): 매우 엄격한 검사, 오탐 가능성 높음
- High (높음): 엄격한 보안, 일부 정상 트래픽 차단 가능
- Medium (중간): 균형잡힌 보안, 대부분의 환경에 적합
- Low (낮음): 느슨한 보안, 명확한 공격만 차단

🎭 동작 모드 설정
- Detection Only (탐지만): 공격을 탐지하고 로그만 기록, 차단하지 않음
- Prevention (차단): 공격을 탐지하고 즉시 차단
- Learning (학습): 정상 트래픽 패턴을 학습하는 모드

📊 4. 로깅 및 모니터링 시스템

모든 보안 이벤트를 기록하고 실시간으로 모니터링하는 시스템이에요. 다음과 같은 정보들이 로그에 기록돼요:

[2024-01-15 14:23:45] ALERT - SQL Injection Detected
Source IP: 192.168.1.100
Target URL: /login.php?id=1' OR '1'='1
Rule ID: 981242
Action: BLOCKED
Severity: CRITICAL
Request Headers: {
  "User-Agent": "Mozilla/5.0...",
  "Referer": "http://attacker.com"
}

이런 로그를 분석하면 공격 패턴을 파악하고 보안 정책을 개선할 수 있어요. 📈

🚀 WAF 배포 방식: 어떤 걸 선택해야 할까?

WAF를 구축하는 방법은 크게 세 가지가 있어요. 각각의 장단점을 비교해서 여러분의 환경에 맞는 방식을 선택하세요!

⚡ 실전! ModSecurity로 WAF 구축하기

이제 실제로 WAF를 설정해볼까요? 가장 인기 있는 오픈소스 WAF인 ModSecurity를 Apache 웹 서버에 설치하는 과정을 단계별로 알아볼게요. 🛠️

📦 1단계: ModSecurity 설치

Ubuntu/Debian 기반 시스템에서 설치하는 방법이에요:

# 패키지 업데이트
sudo apt update

# Apache와 ModSecurity 설치
sudo apt install apache2 libapache2-mod-security2 -y

# ModSecurity 모듈 활성화
sudo a2enmod security2

# Apache 재시작
sudo systemctl restart apache2

# 설치 확인
apachectl -M | grep security

마지막 명령어를 실행했을 때 security2_module이 보이면 성공이에요! 🎉

⚙️ 2단계: 기본 설정 파일 구성

ModSecurity의 설정 파일을 복사하고 기본 설정을 해볼게요:

# 기본 설정 파일 복사
sudo cp /etc/modsecurity/modsecurity.conf-recommended \
       /etc/modsecurity/modsecurity.conf

# 설정 파일 편집
sudo nano /etc/modsecurity/modsecurity.conf

설정 파일에서 중요한 부분들을 살펴볼까요:

# 보안 엔진 활성화 (DetectionOnly에서 On으로 변경)
SecRuleEngine On

# 요청 본문 검사 활성화
SecRequestBodyAccess On

# 응답 본문 검사 활성화 (성능 영향 있음, 필요시에만)
SecResponseBodyAccess Off

# 최대 요청 본문 크기 (13MB)
SecRequestBodyLimit 13107200

# 파일 업로드 크기 제한 (100MB)
SecRequestBodyNoFilesLimit 131072

# 로그 디렉토리 설정
SecAuditLog /var/log/apache2/modsec_audit.log

# 로그 레벨 (0=없음, 9=모두)
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# 디버그 로그 (문제 해결시 유용)
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 0

📚 3단계: OWASP Core Rule Set (CRS) 설치

OWASP CRS는 ModSecurity를 위한 포괄적인 보안 규칙 세트예요. 대부분의 일반적인 웹 공격을 방어할 수 있는 규칙들이 포함되어 있죠:

# CRS 다운로드
cd /tmp
wget https://github.com/coreruleset/coreruleset/archive/v3.3.4.tar.gz

# 압축 해제
tar -xvzf v3.3.4.tar.gz

# ModSecurity 디렉토리로 이동
sudo mv coreruleset-3.3.4 /etc/modsecurity/crs

# 기본 설정 파일 복사
cd /etc/modsecurity/crs
sudo cp crs-setup.conf.example crs-setup.conf

# Apache 설정에 CRS 포함
sudo nano /etc/apache2/mods-enabled/security2.conf

security2.conf 파일에 다음 내용을 추가하세요:

<IfModule security2_module>
    # ModSecurity 기본 설정
    Include /etc/modsecurity/modsecurity.conf
    
    # OWASP CRS 설정
    Include /etc/modsecurity/crs/crs-setup.conf
    Include /etc/modsecurity/crs/rules/*.conf
</IfModule>

🎨 4단계: 보안 레벨 설정 (Paranoia Level)

CRS는 Paranoia Level이라는 개념으로 보안 강도를 조절해요. 레벨이 높을수록 더 많은 규칙이 활성화되지만 오탐 가능성도 높아져요:

# crs-setup.conf 파일 편집
sudo nano /etc/modsecurity/crs/crs-setup.conf

# Paranoia Level 설정 (1~4)
# Level 1: 기본, 대부분의 환경에 적합
# Level 2: 추가 보안, 일부 오탐 가능
# Level 3: 높은 보안, 오탐 주의 필요
# Level 4: 최고 보안, 많은 오탐 예상

SecAction \
  "id:900000,\
   phase:1,\
   nolog,\
   pass,\
   t:none,\
   setvar:tx.paranoia_level=1"

🔧 5단계: 커스텀 규칙 작성

자신만의 보안 규칙을 작성할 수도 있어요. 예를 들어 특정 IP를 차단하거나 특정 URL 패턴을 보호하는 규칙을 만들어볼게요:

# 커스텀 규칙 파일 생성
sudo nano /etc/modsecurity/custom-rules.conf

다음은 유용한 커스텀 규칙 예시들이에요:

# 1. 특정 IP 주소 차단
SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \
    "id:1001,\
     phase:1,\
     deny,\
     status:403,\
     log,\
     msg:'Blocked IP address'"

# 2. SQL 인젝션 패턴 감지
SecRule ARGS "@rx (?i)(union.*select|insert.*into|delete.*from)" \
    "id:1002,\
     phase:2,\
     deny,\
     status:403,\
     log,\
     msg:'SQL Injection attempt detected'"

# 3. 관리자 페이지 접근 제한 (특정 IP만 허용)
SecRule REQUEST_URI "@beginsWith /admin" \
    "id:1003,\
     phase:1,\
     chain,\
     deny,\
     status:403,\
     log,\
     msg:'Admin access denied'"
    SecRule REMOTE_ADDR "!@ipMatch 10.0.0.0/8"

# 4. 파일 업로드 확장자 제한
SecRule FILES_NAMES "@rx (?i)\.(php|exe|sh|bat)$" \
    "id:1004,\
     phase:2,\
     deny,\
     status:403,\
     log,\
     msg:'Dangerous file upload blocked'"

# 5. Rate Limiting (초당 요청 제한)
SecAction "id:1005,\
           phase:1,\
           nolog,\
           pass,\
           initcol:ip=%{REMOTE_ADDR}"

SecRule IP:REQUEST_COUNT "@gt 100" \
    "id:1006,\
     phase:1,\
     deny,\
     status:429,\
     log,\
     msg:'Rate limit exceeded',\
     setvar:ip.request_count=+1"

# 6. User-Agent 검사 (봇 차단)
SecRule REQUEST_HEADERS:User-Agent "@rx (?i)(bot|crawler|spider|scraper)" \
    "id:1007,\
     phase:1,\
     deny,\
     status:403,\
     log,\
     msg:'Bot detected and blocked'"

# 7. XSS 공격 패턴 감지
SecRule ARGS "@rx (?i)(<script|javascript:|onerror=|onload=)" \
    "id:1008,\
     phase:2,\
     deny,\
     status:403,\
     log,\
     msg:'XSS attack detected'"

커스텀 규칙을 Apache 설정에 포함시키세요:

sudo nano /etc/apache2/mods-enabled/security2.conf

# 다음 줄 추가
Include /etc/modsecurity/custom-rules.conf

🧪 6단계: 테스트 및 검증

설정이 제대로 작동하는지 테스트해볼까요:

# Apache 설정 문법 검사
sudo apachectl configtest

# 문제가 없으면 Apache 재시작
sudo systemctl restart apache2

# 로그 실시간 모니터링
sudo tail -f /var/log/apache2/modsec_audit.log

이제 실제 공격을 시뮬레이션해서 WAF가 작동하는지 확인해봐요:

# SQL 인젝션 테스트
curl "http://your-domain.com/test?id=1' OR '1'='1"

# XSS 테스트
curl "http://your-domain.com/test?name=<script>alert('XSS')</script>"

# 디렉토리 트래버설 테스트
curl "http://your-domain.com/../../etc/passwd"

이런 요청들이 차단되고 로그에 기록되면 성공이에요! 🎊

☁️ AWS WAF 설정 가이드

클라우드 환경에서 가장 많이 사용되는 AWS WAF 설정 방법도 알아볼게요. AWS WAF는 CloudFront, Application Load Balancer(ALB), API Gateway와 통합해서 사용할 수 있어요.

🎬 1단계: Web ACL 생성

AWS Management Console에서 WAF & Shield 서비스로 이동한 후:

📋 2단계: 규칙 추가

AWS WAF는 다양한 방식으로 규칙을 추가할 수 있어요:

# IP 기반 차단 규칙
{
  "Name": "BlockSpecificIP",
  "Priority": 1,
  "Statement": {
    "IPSetReferenceStatement": {
      "Arn": "arn:aws:wafv2:region:account:regional/ipset/blocked-ips/..."
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BlockSpecificIP"
  }
}

# Rate limiting 규칙
{
  "Name": "RateLimitRule",
  "Priority": 2,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": {
    "Block": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitRule"
  }
}

# 특정 경로 보호 규칙
{
  "Name": "ProtectAdminPath",
  "Priority": 3,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "ByteMatchStatement": {
            "SearchString": "/admin",
            "FieldToMatch": {
              "UriPath": {}
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "LOWERCASE"
              }
            ],
            "PositionalConstraint": "STARTS_WITH"
          }
        },
        {
          "NotStatement": {
            "Statement": {
              "IPSetReferenceStatement": {
                "Arn": "arn:aws:wafv2:region:account:regional/ipset/admin-ips/..."
              }
            }
          }
        }
      ]
    }
  },
  "Action": {
    "Block": {}
  }
}

⚙️ 3단계: 기본 동작 설정

규칙에 매칭되지 않는 요청에 대한 기본 동작을 설정해요:

• Allow: 모든 트래픽 허용 (규칙으로 차단할 것만 차단)
• Block: 모든 트래픽 차단 (규칙으로 허용할 것만 허용)

대부분의 경우 Allow를 기본값으로 설정하고, 특정 공격 패턴만 차단하는 방식을 사용해요.

📊 4단계: 로깅 및 모니터링 설정

AWS WAF의 활동을 추적하고 분석하기 위한 로깅을 설정해요:

# CloudWatch Logs로 로깅 설정
aws wafv2 put-logging-configuration \
  --logging-configuration \
    ResourceArn=arn:aws:wafv2:region:account:regional/webacl/...,\
    LogDestinationConfigs=arn:aws:logs:region:account:log-group:aws-waf-logs-...

# S3로 로깅 (Kinesis Data Firehose 사용)
aws wafv2 put-logging-configuration \
  --logging-configuration \
    ResourceArn=arn:aws:wafv2:region:account:regional/webacl/...,\
    LogDestinationConfigs=arn:aws:firehose:region:account:deliverystream/aws-waf-logs-...

CloudWatch에서 다음과 같은 메트릭을 모니터링할 수 있어요:

• AllowedRequests: 허용된 요청 수
• BlockedRequests: 차단된 요청 수
• CountedRequests: 카운트만 된 요청 수
• PassedRequests: 규칙 평가를 통과한 요청 수

🎯 5단계: 실전 예시 - 완전한 Web ACL 구성

실제 프로덕션 환경에서 사용할 수 있는 완전한 Web ACL 구성 예시예요:

{
  "Name": "ProductionWebACL",
  "Scope": "REGIONAL",
  "DefaultAction": {
    "Allow": {}
  },
  "Rules": [
    {
      "Name": "AWSManagedRulesCommonRuleSet",
      "Priority": 1,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesCommonRuleSet",
          "ExcludedRules": []
        }
      },
      "OverrideAction": {
        "None": {}
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWSManagedRulesCommonRuleSet"
      }
    },
    {
      "Name": "AWSManagedRulesKnownBadInputsRuleSet",
      "Priority": 2,
      "Statement": {
        "ManagedRuleGroupStatement": {
          "VendorName": "AWS",
          "Name": "AWSManagedRulesKnownBadInputsRuleSet"
        }
      },
      "OverrideAction": {
        "None": {}
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "AWSManagedRulesKnownBadInputsRuleSet"
      }
    },
    {
      "Name": "RateLimitPerIP",
      "Priority": 3,
      "Statement": {
        "RateBasedStatement": {
          "Limit": 2000,
          "AggregateKeyType": "IP"
        }
      },
      "Action": {
        "Block": {
          "CustomResponse": {
            "ResponseCode": 429,
            "CustomResponseBodyKey": "rate-limit-exceeded"
          }
        }
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "RateLimitPerIP"
      }
    },
    {
      "Name": "GeoBlockingRule",
      "Priority": 4,
      "Statement": {
        "GeoMatchStatement": {
          "CountryCodes": ["CN", "RU", "KP"]
        }
      },
      "Action": {
        "Block": {}
      },
      "VisibilityConfig": {
        "SampledRequestsEnabled": true,
        "CloudWatchMetricsEnabled": true,
        "MetricName": "GeoBlockingRule"
      }
    }
  ],
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "ProductionWebACL"
  }
}

🔍 WAF 로그 분석과 튜닝

WAF를 설치하는 것만으로는 부족해요. 지속적인 모니터링과 튜닝이 필요하죠. 로그를 분석하고 오탐을 줄이는 방법을 알아볼게요! 📈

📊 로그 분석의 중요성

WAF 로그를 분석하면 다음과 같은 인사이트를 얻을 수 있어요:

• 공격 패턴 파악: 어떤 종류의 공격이 얼마나 자주 발생하는지
• 오탐 발견: 정상 트래픽이 잘못 차단되는 경우 식별
• 규칙 효과성: 각 규칙이 실제로 얼마나 유용한지 평가
• 트렌드 분석: 시간대별, 지역별 공격 트렌드 파악
• 보안 정책 개선: 데이터 기반의 보안 정책 수립

🔎 ModSecurity 로그 분석

ModSecurity의 감사 로그(Audit Log)는 JSON 형식으로 저장돼요. 실제 로그 예시를 볼까요:

{
  "transaction": {
    "time": "15/Jan/2024:14:23:45 +0000",
    "transaction_id": "YbJQ8CoAAQEAAHi-AAAAAA",
    "remote_address": "192.168.1.100",
    "remote_port": 54321
  },
  "request": {
    "method": "GET",
    "http_version": "HTTP/1.1",
    "uri": "/login.php?id=1' OR '1'='1",
    "headers": {
      "Host": "example.com",
      "User-Agent": "Mozilla/5.0...",
      "Accept": "*/*"
    }
  },
  "response": {
    "status": 403,
    "protocol": "HTTP/1.1"
  },
  "audit_data": {
    "messages": [
      {
        "message": "SQL Injection Attack Detected",
        "data": "Matched Data: ' OR '1'='1 found within ARGS:id",
        "file": "/etc/modsecurity/crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf",
        "line": "1234",
        "id": "942100",
        "severity": "CRITICAL",
        "tags": ["OWASP_CRS", "SQLI"]
      }
    ]
  }
}

이 로그를 분석하기 위한 유용한 명령어들이에요:

# 가장 많이 차단된 IP 주소 Top 10
cat /var/log/apache2/modsec_audit.log | \
  grep -oP '"remote_address":\s*"\K[^"]+' | \
  sort | uniq -c | sort -rn | head -10

# 가장 많이 트리거된 규칙 ID
cat /var/log/apache2/modsec_audit.log | \
  grep -oP '"id":\s*"\K[^"]+' | \
  sort | uniq -c | sort -rn | head -10

# 시간대별 공격 빈도
cat /var/log/apache2/modsec_audit.log | \
  grep -oP '"time":\s*"\K[^:]+' | \
  cut -d'/' -f1 | \
  sort | uniq -c

# 특정 규칙 ID로 필터링
cat /var/log/apache2/modsec_audit.log | \
  jq 'select(.audit_data.messages[].id == "942100")'

# 차단된 요청의 URI 패턴 분석
cat /var/log/apache2/modsec_audit.log | \
  grep -oP '"uri":\s*"\K[^"]+' | \
  sort | uniq -c | sort -rn | head -20

🎨 오탐(False Positive) 처리 방법

정상적인 트래픽이 차단되는 오탐은 사용자 경험을 해치므로 반드시 해결해야 해요. 오탐을 처리하는 여러 방법이 있어요:

# ModSecurity 설정 파일에 추가
# 규칙 ID 942100을 비활성화
SecRuleRemoveById 942100

# 여러 규칙을 한번에 비활성화
SecRuleRemoveById 942100 942110 942120

# /api/upload 경로에서만 파일 업로드 규칙 비활성화
SecRule REQUEST_URI "@beginsWith /api/upload" \
    "id:1100,\
     phase:1,\
     nolog,\
     pass,\
     ctl:ruleRemoveById=942100"

# /search 경로에서 SQL 인젝션 규칙 완화
SecRule REQUEST_URI "@beginsWith /search" \
    "id:1101,\
     phase:1,\
     nolog,\
     pass,\
     ctl:ruleRemoveTargetById=942100;ARGS:query"

# 'content' 파라미터는 HTML 태그를 포함할 수 있으므로 XSS 규칙 제외
SecRuleUpdateTargetById 941100 "!ARGS:content"

# 여러 파라미터를 한번에 제외
SecRuleUpdateTargetById 941100 "!ARGS:content" "!ARGS:description"

# 특정 IP 주소 화이트리스트
SecRule REMOTE_ADDR "@ipMatch 10.0.0.0/8,172.16.0.0/12" \
    "id:1200,\
     phase:1,\
     nolog,\
     pass,\
     ctl:ruleEngine=Off"

# 특정 IP에서 오는 요청은 모든 규칙 비활성화
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/modsecurity/whitelist-ips.txt" \
    "id:1201,\
     phase:1,\
     nolog,\
     pass,\
     ctl:ruleEngine=Off"

📈 성능 모니터링과 최적화

WAF는 모든 HTTP 요청을 검사하므로 성능에 영향을 줄 수 있어요. 성능을 모니터링하고 최적화하는 방법이에요:

# Apache 상태 모듈 활성화
sudo a2enmod status

# server-status 페이지 설정
sudo nano /etc/apache2/mods-enabled/status.conf

status.conf에 다음 내용 추가:

<Location "/server-status">
    SetHandler server-status
    Require ip 127.0.0.1
</Location>

이제 http://localhost/server-status에서 실시간 성능 지표를 확인할 수 있어요.

성능 최적화 팁:

• 응답 본문 검사 비활성화: SecResponseBodyAccess Off (필요한 경우만 On)
• 로그 레벨 조정: 프로덕션에서는 SecDebugLogLevel 0
• 불필요한 규칙 제거: 사용하지 않는 CRS 규칙 파일 제외
• 정규표현식 최적화: 복잡한 정규표현식은 성능 저하의 주범
• 캐싱 활용: 정적 콘텐츠는 WAF 검사 전에 캐시에서 서빙

🛠️ 고급 WAF 활용 전략

기본적인 설정을 넘어서 WAF를 더욱 효과적으로 활용하는 고급 전략들을 알아볼게요! 🚀

🤖 머신러닝 기반 위협 탐지

최신 WAF 솔루션들은 머신러닝을 활용해서 새로운 공격 패턴을 자동으로 학습하고 탐지해요. AWS WAF의 경우 Fraud Control이나 Bot Control 같은 기능을 제공하죠.

{
  "Name": "BotControlRule",
  "Priority": 10,
  "Statement": {
    "ManagedRuleGroupStatement": {
      "VendorName": "AWS",
      "Name": "AWSManagedRulesBotControlRuleSet",
      "ManagedRuleGroupConfigs": [
        {
          "AWSManagedRulesBotControlRuleSet": {
            "InspectionLevel": "COMMON"
          }
        }
      ]
    }
  },
  "OverrideAction": {
    "None": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "BotControlRule"
  }
}

🔐 API 보안 강화

RESTful API나 GraphQL API를 보호하기 위한 특별한 WAF 설정이 필요해요:

# JSON 페이로드 크기 제한
SecRule REQUEST_HEADERS:Content-Type "@contains application/json" \
    "id:2001,\
     phase:1,\
     chain,\
     pass,\
     nolog"
    SecRule REQUEST_BODY "@gt 1048576" \
        "deny,\
         status:413,\
         msg:'JSON payload too large'"

# API 키 검증
SecRule REQUEST_URI "@beginsWith /api/" \
    "id:2002,\
     phase:1,\
     chain,\
     deny,\
     status:401,\
     msg:'Missing or invalid API key'"
    SecRule &REQUEST_HEADERS:X-API-Key "@eq 0"

# Rate limiting (API별로 다른 제한)
SecRule REQUEST_URI "@beginsWith /api/public" \
    "id:2003,\
     phase:1,\
     pass,\
     nolog,\
     setvar:tx.rate_limit=100"

SecRule REQUEST_URI "@beginsWith /api/premium" \
    "id:2004,\
     phase:1,\
     pass,\
     nolog,\
     setvar:tx.rate_limit=1000"

# GraphQL 쿼리 깊이 제한
SecRule REQUEST_BODY "@rx \"query\".*\{.*\{.*\{.*\{.*\{" \
    "id:2005,\
     phase:2,\
     deny,\
     status:400,\
     msg:'GraphQL query too deep'"

# SQL 인젝션 (JSON 페이로드 내부)
SecRule REQUEST_BODY "@rx (?i)(union.*select|insert.*into)" \
    "id:2006,\
     phase:2,\
     deny,\
     status:403,\
     msg:'SQL injection in JSON payload'"

🌍 지리적 차단 (Geo-blocking)

특정 국가나 지역에서 오는 트래픽을 차단하는 것도 효과적인 보안 전략이에요:

# GeoIP 데이터베이스 설치
sudo apt install libmaxminddb0 libmaxminddb-dev mmdb-bin

# GeoIP 모듈 설정
SecGeoLookupDB /usr/share/GeoIP/GeoLite2-Country.mmdb

# 특정 국가 차단
SecRule REMOTE_ADDR "@geoLookup" \
    "id:3001,\
     phase:1,\
     chain,\
     deny,\
     status:403,\
     msg:'Access denied from blocked country'"
    SecRule GEO:COUNTRY_CODE "@rx ^(CN|RU|KP)$"

# 특정 국가만 허용 (화이트리스트 방식)
SecRule REMOTE_ADDR "@geoLookup" \
    "id:3002,\
     phase:1,\
     chain,\
     deny,\
     status:403,\
     msg:'Access allowed only from specific countries'"
    SecRule GEO:COUNTRY_CODE "!@rx ^(US|KR|JP)$"

# 관리자 페이지는 특정 국가에서만 접근 허용
SecRule REQUEST_URI "@beginsWith /admin" \
    "id:3003,\
     phase:1,\
     chain,\
     deny,\
     status:403,\
     msg:'Admin access restricted by country'"
    SecRule REMOTE_ADDR "@geoLookup" \
        "chain"
    SecRule GEO:COUNTRY_CODE "!@rx ^(KR)$"

🔄 동적 IP 평판 시스템

공격을 시도한 IP 주소를 자동으로 블랙리스트에 추가하는 시스템을 구축할 수 있어요:

# 공격 시도 카운터 증가
SecRule REQUEST_URI "@rx (?i)(\.\.\/|etc\/passwd|union.*select)" \
    "id:4001,\
     phase:2,\
     pass,\
     log,\
     msg:'Attack attempt detected',\
     setvar:ip.attack_count=+1,\
     expirevar:ip.attack_count=3600"

# 3회 이상 공격 시도시 1시간 차단
SecRule IP:ATTACK_COUNT "@gt 2" \
    "id:4002,\
     phase:1,\
     deny,\
     status:403,\
     msg:'IP temporarily blocked due to multiple attack attempts',\
     setvar:ip.blocked=1,\
     expirevar:ip.blocked=3600"

# 차단된 IP 확인
SecRule IP:BLOCKED "@eq 1" \
    "id:4003,\
     phase:1,\
     deny,\
     status:403,\
     msg:'IP is currently blocked'"

📱 모바일 앱 API 보호

모바일 앱의 API를 보호하기 위한 특별한 전략이에요:

# iOS App Attestation 검증
SecRule REQUEST_HEADERS:X-App-Attestation "@rx ^[A-Za-z0-9+/=]+$" \
    "id:5001,\
     phase:1,\
     pass,\
     nolog,\
     setvar:tx.app_verified=1"

SecRule TX:APP_VERIFIED "!@eq 1" \
    "id:5002,\
     phase:1,\
     deny,\
     status:401,\
     msg:'App attestation required'"

# Android SafetyNet 검증
SecRule REQUEST_HEADERS:X-SafetyNet-Token "@rx ^[A-Za-z0-9._-]+$" \
    "id:5003,\
     phase:1,\
     pass,\
     nolog,\
     setvar:tx.safetynet_verified=1"

# 특정 인증서 지문만 허용
SecRule REQUEST_HEADERS:X-Certificate-Fingerprint \
    "!@rx ^(abc123def456|789ghi012jkl)$" \
    "id:5004,\
     phase:1,\
     deny,\
     status:403,\
     msg:'Invalid certificate fingerprint'"

# 루팅/탈옥된 디바이스 차단
SecRule REQUEST_HEADERS:X-Device-Jailbroken "@eq true" \
    "id:5005,\
     phase:1,\
     deny,\
     status:403,\
     msg:'Jailbroken/rooted devices not allowed'"

# 에뮬레이터 차단
SecRule REQUEST_HEADERS:X-Device-Emulator "@eq true" \
    "id:5006,\
     phase:1,\
     deny,\
     status:403,\
     msg:'Emulators not allowed'"

🚨 WAF 운영 시 주의사항과 베스트 프랙티스

WAF를 효과적으로 운영하기 위한 실전 노하우를 공유할게요! 💪

✅ 베스트 프랙티스

⚠️ 피해야 할 실수들

📋 WAF 운영 체크리스트

🎓 팀 교육과 역량 강화

WAF를 효과적으로 운영하려면 팀원들의 보안 역량이 중요해요:

추천 학습 리소스:
• OWASP Top 10: 웹 애플리케이션의 주요 보안 위협 이해
• ModSecurity Handbook: ModSecurity 공식 가이드
• AWS WAF Workshop: AWS 공식 핸즈온 워크샵
• SANS SEC542: 웹 애플리케이션 침투 테스트 과정
• Certified Ethical Hacker (CEH): 윤리적 해킹 자격증

실습 환경 구축:
• DVWA (Damn Vulnerable Web Application): 취약한 웹 앱으로 공격 실습
• WebGoat: OWASP의 교육용 취약한 웹 애플리케이션
• Juice Shop: 현대적인 웹 기술 스택의 취약점 학습
• HackTheBox: 실전 같은 해킹 챌린지 플랫폼

🔮 WAF의 미래와 트렌드

웹 보안 기술은 계속 진화하고 있어요. 앞으로 WAF가 어떻게 발전할지 살펴볼까요? 🚀

🤖 AI/ML 기반 지능형 WAF

인공지능과 머신러닝을 활용한 차세대 WAF가 등장하고 있어요:

• 행위 기반 이상 탐지: 정상 트래픽 패턴을 학습하고 이상 행위를 자동으로 감지
• 제로데이 공격 대응: 알려지지 않은 새로운 공격도 패턴 분석으로 탐지
• 자동 규칙 생성: 공격 패턴을 분석해서 자동으로 방어 규칙 생성
• 오탐 자동 감소: 머신러닝으로 오탐을 학습하고 자동으로 규칙 튜닝
• 예측적 방어: 공격 징후를 사전에 감지하고 선제적으로 대응

☁️ 서버리스 WAF

서버리스 아키텍처에 최적화된 WAF가 발전하고 있어요:

• Lambda@Edge WAF: CloudFront 엣지에서 실행되는 경량 WAF
• API Gateway 통합: 서버리스 API를 위한 네이티브 보안
• 이벤트 기반 방어: 공격 감지 시 자동으로 Lambda 함수 실행
• 마이크로서비스 보호: 각 마이크로서비스별 독립적인 WAF 정책

🌐 엣지 컴퓨팅과 WAF

5G와 엣지 컴퓨팅의 발전으로 WAF도 엣지로 이동하고 있어요:

• 초저지연 방어: 사용자와 가까운 엣지에서 즉시 공격 차단
• 분산 방어: 전 세계 엣지 노드에서 동시에 방어
• IoT 보안: IoT 디바이스의 API를 엣지에서 보호
• 5G 네트워크 슬라이싱: 네트워크 레벨에서 보안 정책 적용

🔐 Zero Trust 아키텍처와 WAF

Zero Trust 보안 모델이 확산되면서 WAF의 역할도 변화하고 있어요:

• 지속적인 검증: 모든 요청을 매번 검증
• 마이크로 세그멘테이션: 세밀한 접근 제어
• 컨텍스트 기반 정책: 사용자, 디바이스, 위치, 시간 등을 고려한 동적 정책
• 통합 보안 플랫폼: IAM, SIEM, SOAR과의 긴밀한 통합

📊 자동화와 DevSecOps

보안이 개발 프로세스에 통합되면서 WAF도 자동화되고 있어요:

# Infrastructure as Code로 WAF 관리
# Terraform 예시
resource "aws_wafv2_web_acl" "main" {
  name  = "production-waf"
  scope = "REGIONAL"

  default_action {
    allow {}
  }

  rule {
    name     = "RateLimitRule"
    priority = 1

    statement {
      rate_based_statement {
        limit              = 2000
        aggregate_key_type = "IP"
      }
    }

    action {
      block {}
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "RateLimitRule"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "ProductionWAF"
    sampled_requests_enabled   = true
  }
}

# CI/CD 파이프라인에 WAF 테스트 통합
# GitLab CI 예시
waf_test:
  stage: security
  script:
    - echo "Testing WAF rules..."
    - python test_waf_rules.py
    - echo "Checking for false positives..."
    - python check_false_positives.py
  only:
    - main