서론: 웹 애플리케이션 방화벽(WAF) 로그로 ‘비정상 접속’이 보이는 순간
“비정상 접속 시도”를 확인하려고 WAF 로그를 펼치면, 생각보다 많은 이벤트가 한꺼번에 보이는 경우가 많습니다. 그중에는 실제 공격도 있지만, 자동화된 크롤러나 잘못된 설정, 정상 사용자의 오작동이 섞여 들어가기도 합니다. 그래서 WAF 로그 분석은 단순히 차단 건수만 세는 작업이 아니라, 어떤 흐름으로 들어왔고 무엇을 노렸는지 맥락을 정리하는 과정에 가깝습니다. 이 글은 WAF 로그에서 비정상 접속 시도를 해석하는 순서를 “처음 확인할 것 → 분류 → 판단 → 후속 조치” 흐름으로 정리합니다.
1) WAF 로그에서 먼저 봐야 하는 핵심 필드와 읽는 순서
요청이 ‘누가, 언제, 어디로’ 들어왔는지부터 정리
분석의 출발점은 단순합니다. 시간대(timestamp), 출발지 IP, 요청 메서드(GET/POST 등), 요청 URI(경로), 응답 코드(200/403/404/500 등)를 먼저 묶어 봅니다. 여기서 “동일 IP가 짧은 시간에 여러 URI를 훑는지”, “특정 URI에만 집착하는지” 같은 패턴이 드러납니다, 초반에 이 기본 축이 정리되지 않으면, 룰 이름이나 시그니처만 보고 과잉 판단하기 쉬워집니다.
차단/탐지/우회 여부: action과 정책 매칭을 확인
WAF 로그에는 보통 action(allow, block, monitor, challenge 등)과 어떤 정책/룰에 걸렸는지가 같이 남습니다. 여기서 중요한 건 “차단되었느냐”보다 “왜 그렇게 처리되었느냐”입니다. 동일한 공격 패턴이라도 운영 정책상 탐지만 하고 통과시키는 구간이 있을 수 있고, 반대로 정상 요청이 특정 룰에 의해 차단되는 오탐도 흔합니다, action과 룰 id, 룰 그룹, 매칭된 파라미터를 같이 보면서 사건의 성격을 잡는 편이 안정적입니다.
헤더·파라미터·바디 중 ‘어디에서’ 의심 신호가 나왔는지
비정상 접속은 흔히 쿼리스트링, POST 파라미터, 쿠키, User-Agent, Referer 같은 입력 지점에서 드러납니다. 로그에 “matchedData” 또는 “matchedVariable”처럼 어떤 입력이 룰에 걸렸는지 남는다면 우선순위를 크게 올려서 봐야 합니다. 예를 들어 URI는 평범한데 특정 파라미터 값이 SQL 키워드를 포함한다면, 목적이 비교적 명확해집니다. 반대로 User-Agent만 특이하고 파라미터는 비어 있다면, 단순 스캔이나 봇 트래픽일 가능성이 커집니다.
원본 IP와 프록시 체인: X-Forwarded-For를 그대로 믿지 않기
클라우드나 CDN, 리버스 프록시를 사용하는 환경에서는 X-Forwarded-For(XFF)나 True-Client-IP 같은 헤더가 함께 기록됩니다. 그렇지만 이 값은 신뢰할 수 있는 프록시 구간에서만 의미가 있고, 외부에서 임의로 조작될 수도 있습니다. 그래서 “WAF가 신뢰하는 프록시 목록”과 “실제 소스 IP 필드”가 어떻게 구성되는지 먼저 확인해야 합니다. 이 전제가 흔들리면, 차단 목록을 만들 때 엉뚱한 IP를 잡는 일이 생깁니다.
2) 비정상 접속 시도의 대표 패턴과 WAF 로그에서 보이는 흔적
스캐닝과 디렉터리 브루트포스: 404가 폭발하는 흐름
가장 흔한 비정상 접속은 “어디가 열려 있는지 찾는” 스캔입니다. 로그에서는 짧은 시간에 /admin, /wp-login.php, /.env, /phpmyadmin 같은 경로가 연속으로 찍히고, 응답은 404 또는 403이 반복되는 식으로 나타납니다. 정상 사용자는 보통 한두 개의 페이지를 따라 이동다만, 스캐너는 수십~수백 개의 흔한 경로를 기계적으로 요청합니다. 이때는 URI 다양도, 초당 요청 수, 동일 IP의 실패 비율이 핵심 지표가 됩니다.
SQL 인젝션 시도: 파라미터에 ‘의미 없는 문장’이 들어온다
SQLi는 WAF에서 가장 자주 탐지되는 유형 중 하나입니다, 로그에는 쿼리스트링이나 post 값에 or 1=1, union select, sleep(), benchmark 같은 패턴이 포함되어 매칭되는 경우가 많습니다. 정상 사용자 입력에서도 따옴표나 특수문자가 들어갈 수 있으니, 단순 키워드 포함만으로 결론을 내리기보다는 “해당 파라미터가 원래 숫자만 받는지”, “같은 IP가 다양한 파라미터를 바꿔가며 반복하는지”를 같이 봅니다. 동일한 계정/세션으로 여러 엔드포인트에서 유사한 페이로드가 나오면 의도성이 강해집니다.
XSS 시도: 스크립트 조각이 입력값에 섞여 들어가는 경우
XSS는 <script>, onerror=, javascript: 같은 흔한 패턴으로 탐지되지만, 인코딩을 섞어 우회하려는 시도도 많습니다. WAF 로그에서 “URL 인코딩된 문자열”, “HTML 엔티티 형태”, “이상하게 긴 입력”이 반복되면 한 번 더 의심해 볼 만합니다. 가령 검색어, 게시글, 댓글, 프로필 등 사용자 입력이 저장되거나 렌더링되는 구간에서 이런 요청이 집중되면 위험도가 올라갑니다. 반대로 단일 이벤트로만 끝나고 재현이 되지 않는다면, 봇이 무작위로 던진 탐색성 트래픽일 수도 있습니다.
로그인 크리덴셜 스터핑: 200/302가 섞인 실패 패턴
비정상 접속은 반드시 403으로만 나타나지 않습니다, 크리덴셜 스터핑이나 무차별 로그인 시도는 로그인 엔드포인트(/login, /signin, /oauth/token 등)에 post가 반복되고, 응답이 200 또는 302로 돌아오는 경우도 많습니다. 실패 시에도 200을 주는 서비스가 흔하기 때문입니다. 그래서 이 유형은 WAF 로그만으로는 한계가 있고, 애플리케이션 로그인 실패 로그, 계정 잠금 이벤트, 인증 서버 로그와 함께 묶어 봐야 윤곽이 잡힙니다.
봇/자동화 트래픽: User-Agent와 요청 리듬이 힌트
정상 브라우저는 리소스(이미지. Js, css) 요청이 함께 따라오고, 세션 쿠키도 자연스럽게 유지됩니다. 반면 자동화 도구는 특정 API만 두드리거나, User-Agent가 비어 있거나, 동일한 헤더 구성을 그대로 복제하는 경향이 있습니다. 이러한 wAF 로그에서 “리소스 요청이 거의 없는데 POST만 반복”하거나, “쿠키가 매번 새로 생기는” 흐름은 자동화 가능성을 높여 줍니다. 다만 모바일 앱이나 외부 파트너 연동도 비슷하게 보일 수 있어, 허용 목록과 트래픽 출처를 함께 검토하는 편이 안전합니다.
취약점 익스플로잇 탐색: 특정 CVE 흔적이 경로에 묻어난다
특정 프레임워크나 CMS를 겨냥한 공격은 경로 자체가 힌트가 됩니다. 예를 들어 워드프레스 플러그인 경로, 특정 관리자 페이지, 잘 알려진 디버그 엔드포인트가 반복적으로 호출됩니다. WAF 룰 이름에 CVE 번호가 포함되어 있거나, 공격 문자열이 특정 취약점 PoC와 유사하게 남는 경우도 있습니다. 이런 이벤트는 “우리 서비스가 해당 기술 스택을 쓰는지”부터 확인해야 하고, 사용하지 않는 경로라면 차단 및 속도 제한으로 대응하되 과도한 리소스 투입은 줄이는 쪽이 현실적입니다.
3) 로그를 ‘사건’으로 묶는 분석 절차: 분류 → 우선순위 → 검증
1단계: 단건 이벤트가 아니라 세션/행위 단위로 묶기
WAF는 요청 단위로 로그를 남기기 때문에, 그대로 보면 잡음이 많습니다. 같은 IP, 같은 User-Agent, 비슷한 시간 창(예: 5분), 동일한 URI 패턴을 기준으로 묶으면 “한 사람이 무엇을 하려 했는지”가 보입니다. 이때 요청 수, 실패 비율, 서로 다른 엔드포인트로의 확장 여부를 함께 계산하면 스캔과 실제 공격 시도를 구분하기 쉬워집니다. 운영 현장에서는 이 묶음이 곧 조사 티켓의 단위가 되는 경우가 많습니다.
2단계: 위험도는 ‘성공 가능성’과 ‘영향 범위’로 나눠 판단
비정상 접속이 많다고 해서 모두 같은 위험은 아닙니다. 예를 들어 없는 경로를 두드리는 스캔은 시끄럽지만 성공 가능성은 낮고, 실제 존재하는 업로드 API에 대한 우회 시도는 빈도는 낮아도 영향이 큰데, 이 구분은 [심리 실험] ‘거의 성공’ 연출이 착각을 강화하는 과정을 추적하다에서 말하는 자극의 크기보다 맥락과 결과 가능성이 판단을 좌우하는 구조와 닮아 있습니다. 따라서 실제 존재하는 엔드포인트인지, 인증 전 구간인지 후 구간인지, 데이터 변경 요청인지 조회 요청인지를 기준으로 우선순위를 정해야 하며, 차단 건수가 많아도 처리 순서는 달라질 수 있습니다.
3단계: 오탐을 줄이는 검증 포인트 세 가지
첫째, 해당 요청이 정상 기능에서 발생할 수 있는 입력인지 확인합니다. 둘째, 같은 패턴이 여러 사용자/여러 국가에서 동시에 발생하는지 봅니다. 셋째, 애플리케이션 로그에서 실제 오류나 예외가 동반되었는지 확인합니다. 흥미로운 점은 wAF만 보고 결론을 내리면 “정상 사용자 차단” 같은 운영 사고로 이어질 수 있으니, 최소한의 교차 검증 루틴을 정해 두는 편이 좋습니다.
4단계: 커뮤니티형 운영에서 자주 하는 ‘신뢰 판단’ 흐름을 적용
참여형 서비스나 커뮤니티는 신규 유입이 많고, 외부 링크를 통해 갑자기 트래픽이 몰리기도 합니다. 이때 특정 IP 대역을 공격으로 단정해 막아버리면, 정상 이용자까지 같이 끊길 수 있습니다. 그래서 “반복성, 자동화 징후, 실패율, 행동 다양도” 같은 지표로 신뢰도를 점수화하듯 보는 방식이 실무에서 자주 쓰입니다, 결국 차단은 기술 판단이면서도 운영 판단이어서, 로그 해석이 곧 서비스 품질과 연결됩니다.
4) 대응과 개선: 차단만이 아니라 ‘재발 비용’을 줄이는 방향
즉시 대응: IP 차단보다 속도 제한과 챌린지의 활용
비정상 접속이 확인되면 가장 먼저 떠오르는 건 IP 차단이지만, 공격자는 IP를 쉽게 바꿀 수 있습니다. 반면 속도 제한(rate limit)이나 일정 조건에서의 챌린지(추가 검증)는 자동화 트래픽을 줄이는 데 실효성이 있는 편입니다, 특히 로그인, 비밀번호 재설정, 검색 api처럼 남용되기 쉬운 엔드포인트는 “정상 사용 흐름을 크게 해치지 않는 범위”에서 제한을 거는 것이 현실적인 선택입니다. WAF 정책도 한 번에 강하게 바꾸기보다, 탐지 모드에서 관찰한 뒤 단계적으로 강화하는 편이 안정적입니다.
정책 튜닝: 어떤 룰이 자주 울리는지부터 정리
WAF 로그를 보면 특정 룰이 유독 자주 매칭되는 경우가 있습니다. 이때는 그 룰이 일례로 공격을 많이 막고 있는지, 아니면 우리 서비스 입력 특성과 충돌해 오탐을 내는지 구분해야 합니다. 자주 울리는 파라미터가 무엇인지, 특정 페이지에서만 발생하는지, 특정 국가/네트워크에서만 발생하는지 같은 조건을 붙여 보면 튜닝 방향이 잡힙니다. 튜닝의 목표는 “탐지율을 무조건 올리는 것”이 아니라, 운영자가 해석할 수 있는 신호 대 잡음 비율을 올리는 데 있습니다.
로그 운영: 보관, 검색, 공유가 쉬워야 분석이 지속된다
비정상 접속 분석은 한 번으로 끝나지 않고, 비슷한 패턴이 반복되면서 누적 지식이 됩니다. 그래서 로그 보관 기간, 검색 쿼리 템플릿, 사건 단위로 남기는 메모 같은 운영 체계가 중요합니다. 팀 내에서 “이 룰은 이런 상황에서 오탐이 잦다” 같은 합의가 쌓이면, 다음 분석 속도가 눈에 띄게 빨라집니다. 포인트나 보상 같은 활동 체계가 있는 커뮤니티라면, 신고나 제보가 들어왔을 때 로그로 빠르게 확인해 신뢰를 확보하는 흐름도 자연스럽게 만들어집니다.
사후 점검: WAF 밖의 보안 기본기를 함께 확인
WAF가 공격을 막아도, 근본 원인이 남아 있으면 비슷한 시도가 계속 들어옵니다. 입력값 검증, 파라미터 타입 고정, 인증/인가 점검, 에러 메시지 단순화 같은 애플리케이션 보안 기본기를 함께 점검하는 이유가 여기에 있습니다. 또한 관리자 페이지 노출, 디버그 엔드포인트, 불필요한 레거시 경로처럼 “공격자가 좋아하는 표면”을 줄이면 WAF 로그 자체가 훨씬 조용해집니다, 결국 좋은 대응은 차단 로그를 늘리는 게 아니라, 공격자가 시도할 이유를 줄이는 방향으로 수렴합니다.
요약하면, WAF 로그로 비정상 접속 시도를 분석할 때는 먼저 기본 필드로 트래픽의 뼈대를 잡고, 대표 패턴으로 분류한 뒤, 사건 단위로 묶어 우선순위를 세우는 흐름이 가장 효율적입니다. 차단 여부만 보지 말고 “어떤 입력이 어디에서 매칭됐는지”를 확인하면 오탐과 실제 공격을 가르는 감이 생깁니다. 마지막으로 대응은 IP 차단에만 기대기보다 속도 제한, 정책 튜닝, 애플리케이션 개선까지 연결될 때 비용 대비 효과가 좋아집니다. 이런 관점으로 로그를 읽으면, 비정상 접속을 단순한 소음이 아니라 운영과 보안을 함께 정리하는 신호로 해석할 수 있습니다.
