
지금까지 총 6편에 걸쳐 AWS WAF의 실무 활용법을 다뤄왔습니다.기본 개념부터 로그 분석, 자동 대응, 고급 룰 작성법까지 이어온 이 시리즈의 마지막 글에서는 실제 운영 환경에서 무엇을 남기고, 어떻게 자동화 구조를 유지해야 하는지를 정리해보겠습니다.📌 1. 지금까지 우리가 구축한 AWS WAF 구조이번 시리즈에서 다룬 주요 요소들을 다시 짚어보면 다음과 같습니다. 기본 WebACL 구성과 Managed Rule 설정 Count 모드를 활용한 룰 사전 점검 CloudWatch Logs, Kinesis, Lambda 연계를 통한 로그 기반 대응 RegexPatternSet, Header 조건 등 고급 탐지 방식 활용 IPSet 자동 갱신 및 오탐 방지를 위한 캐싱 구조이러한 구성은 단순 필터..

AWS WAF를 적용한 뒤에도 공격 트래픽이 꾸준히 유입된다면, 룰 자체가 우회를 허용하고 있을 가능성이 큽니다.특히 URI 인코딩, Query 파라미터 변조, User-Agent 위장 등의 기법은 단순한 룰 필터링으로는 잡히지 않는 경우가 많습니다.이번 글에서는 AWS WAF에서 우회 공격 트래픽까지 탐지하고 차단할 수 있는 고급 룰 구성 전략을 실무 중심으로 정리합니다.RegexPatternSet, Header 검사, 쿠키 필터링 등 잘 알려지지 않은 기능까지 활용해, 보다 정밀한 보안 정책을 수립해보세요.🔎 1. 인코딩 우회 탐지 – URLDecode, Base64 처리많은 공격자들이 URI나 파라미터에 인코딩을 섞어 필터 우회를 시도합니다.예: /login → %2flogin, 또는 ../ → ..

🤔 허용과 차단 사이, 사용자 검증이 필요할 때AWS WAF를 설정하다 보면 단순한 허용(Allow) 또는 차단(Block)만으로는 대응하기 애매한 요청을 마주하게 됩니다. 예를 들어, 로그인 페이지에서 반복적인 접근이 있는데 IP 자체는 처음 보는 경우, 혹은 게시판에 하루 수십 건씩 게시글을 등록하는 비정상적인 접근 같은 상황이죠.이럴 때 가장 유용한 기능이 바로 CAPTCHA와 Challenge 액션입니다. 봇인지 사람인지 확인하면서도 사용자 경험을 해치지 않는 대응이 가능하죠.🔐 CAPTCHA와 Challenge, 뭐가 다를까?CAPTCHA는 사용자의 브라우저에 테스트를 띄워 사람인지 확인하는 전통적인 방식입니다. 구글 리캡차처럼 이미지를 클릭하거나 글자를 입력하는 과정을 요구하죠...

AWS WAF 운영 중 탐지된 로그를 어떻게 룰에 반영할 수 있을까요? Count 모드 → Block 전환까지의 실무 기준과 루틴을 정리했습니다. ··· 📁 Count → 차단, 그 사이에는 기준이 있어야 한다 실무에서는 신규 룰을 무조건 차단(Block)으로 적용하지 않습니다. Count 모드로 탐지부터 먼저 시작하고, 일정 기간 로그를 관찰한 후 판단합니다. 그런데 언제 차단으로 전환할 것인가? 이 질문에 답이 없으면 WAF는 언제까지나 탐지만 하는 도구로 머물게 됩니다. ··· 🔹 실무에서 쓰이는 전환 기준 예시 ✔ 동일한 탐지 label이 7일 이상 반복 탐지됨 ✔ 탐지된 경로가 민감 경로(login, admin ..