IP 차단 자동화와 보안 필터 임계값 강화로 운영 안정성 개선

운영 서버에 달아둔 보안 필터를 손본 날이었다. 기능 추가라기보다는 현장에서 쓰다 보니 드러난 숫자들을 현실에 맞게 다듬는 작업이었는데, 이런 종류의 수정이 오히려 은근히 공수가 든다. 건드려야 할 지점을 찾는 것 자체가 로그 분석이고, 임계값 하나 바꾸면 어느 경로가 영향받는지 다 따라가야 하니까.

필터 처리 흐름과 이번 변경의 맥락

이 서버에 붙어 있는 보안 필터는 크게 세 가지를 담당한다. IP 기반 Rate Limit, 봇/공격 패턴 감지, 블랙리스트 자동 등록. 단계별로 거르고 통과시키는 구조다.

요청 수신
  → 화이트리스트 IP 확인
  → 봇 UA / 의심 경로 감지
  → Rate Limit 체크 (Redis 슬라이딩 윈도우)
  → 차단 / 블랙리스트 등록 / 통과

Rate Limit은 Redis 슬라이딩 윈도우로 구현되어 있다. 고정 윈도우 방식보다 경계 타이밍 이슈가 적고, 특정 1분 구간 직전에 몰아치는 요청도 잡을 수 있어서 선택한 구조다. 다만 슬라이딩 윈도우는 키 만료 관리를 잘 해줘야 메모리가 안 새는데, 이번에 임계값 조정하면서 TTL 설정도 같이 점검했다.

이번에 바뀐 내용을 표로 정리하면 이렇다.

임계값이 완화 상태로 남아 있던 건 과거에 일시적으로 풀어둔 설정이 그대로 굳어버린 것이었다. 언제부터 그랬는지 정확히 알 수 없지만, 로그를 보면 정상적으로는 설명이 안 되는 요청들이 걸러지지 않고 통과하는 패턴이 있었다. 공격 패턴 감지도 기본 UA 블랙리스트 수준에서 머물고 있었는데, 의심 경로와 페이로드 시그니처까지 확장했다.

예외 경로 처리가 핵심이었다

임계값 강화 자체보다 예외 경로를 제대로 정의하는 게 더 중요한 작업이었다. 필터를 세게 조이면 정상 트래픽도 같이 막힌다. 특히 두 가지가 문제가 됐다.

첫 번째는 헬스체크 엔드포인트. 로드 밸런서나 모니터링 시스템이 주기적으로 찌르는 경로인데, Rate Limit에 카운트가 잡히면 일정 시간 뒤에 헬스체크가 차단돼서 인스턴스가 비정상으로 표시될 수 있다. 이건 필터를 아예 스킵하도록 명시적으로 제외했다.

두 번째가 AJAX 요청 처리다. 페이지 로드 시점에 AJAX 요청이 여러 개 동시에 나가는 구조라, Rate Limit 카운트에 다 포함시키면 페이지 하나 열었는데 사용자가 바로 차단되는 상황이 생긴다. 이번에 AJAX 요청은 카운트에서 제외하는 옵션을 추가했다. 다만 이 결정은 트레이드오프가 있다. AJAX 요청만 반복적으로 때리는 공격을 Rate Limit으로는 못 잡게 되니까, 해당 패턴은 공격 시그니처 감지 쪽에서 커버하도록 분리했다.

예외 처리 목록을 코드에 하드코딩으로 박아두면 나중에 추적이 안 된다. 명시적인 설정 파일이나 상수로 관리하는 게 낫다. 어떤 경로가 왜 필터를 건너뛰는지 주석이라도 달아두는 것과 안 달아두는 것은 6개월 뒤 유지보수 난이도가 완전히 달라진다.

블랙리스트 자동 등록을 붙이면서 고려한 것들

공격성 요청 탐지 후 수동 대응은 현실적으로 느리다. 새벽에 터지면 아무도 못 잡는다. 이번에 감지 즉시 DB에 자동 등록하고 다음 요청부터 차단하는 흐름을 만들었는데, 이게 빠르게 붙이기는 쉬운데 오히려 운영 리스크가 생기는 지점이기도 하다.

자동화할 때 꼭 챙겨야 했던 것들:

• 오탐 예외 처리: 배치 작업이나 로드 테스트가 봇으로 오인될 수 있다. 특정 내부 IP나 사전 등록된 서비스 계정은 자동 등록 대상에서 제외했다.
• TTL 기반 만료: 영구 차단 대신 일정 기간 후 자동 해제되도록 했다. 오탐으로 실 사용자가 막힌 경우 TTL이 지나면 풀린다. 진짜 공격자라면 다시 잡히면 된다.
• 알림 연동: 자동 차단이 발생할 때마다 슬랙으로 알림이 간다. 자동화는 돌아가게 해두되, 무슨 일이 일어나는지는 사람이 볼 수 있어야 한다. 조용히 쌓이다가 나중에 터지는 것보다 실시간으로 파악하는 게 낫다.

자동화된 블랙리스트가 운영 중인 상태에서 "왜 접속이 안 되냐"는 문의가 들어오면, 대응 경로가 명확해야 한다. 수동 해제 인터페이스가 있어야 하고, 차단 이유가 로그에 남아야 한다. 이 부분을 처음부터 설계에 포함시키지 않으면 나중에 운영 팀이 대응하기가 힘들어진다.

작업 규모 자체는 크지 않았다. 하지만 이런 임계값 조정이나 필터 정비 작업은 미루다 보면 나중에 훨씬 큰 비용으로 돌아온다. 실제로 공격이 왔을 때 필터가 제대로 작동하지 않으면 그때 가서 급하게 고치는 건 훨씬 위험하다.