봇으로 의심되는 IP를 차단한 후 어떤 것을 확인해야 할까요?

Summary

(작성 필요)

봇 공격은 비즈니스의 카테고리를 가리지 않지만, 이번 콘텐츠에서는 쇼핑몰의 상품 조회 요청이 갑자기 늘어난 상황을 가정해보도록 하겠습니다. 운영팀은 비정상적으로 많은 요청을 보내 봇으로 의심되는 IP를 찾아 차단합니다. 해당 IP의 비정상적인 요청은 멈추지만 잠시 뒤 다른 IP에서 비슷한 요청이 이어집니다.

IP 차단은 봇을 사용하는 것을 의심되는 주소의 접근을 제한하는 대응 수단입니다. 하지만 공격자가 여러 IP에 요청을 나누거나 접속 경로를 바꾸게 되면, 한 주소를 막은 뒤에도 계속 의심스러운 요청이 이어질 수 있습니다. 소프트웨어 보안 향상을 목표로 하는 비영리 단체인 OWASP 역시 IP 차단을 크리덴셜 스터핑 등의 봇 공격에서 유일한 방법은 아니라고 보며, 이러한 차단을 봇 공격의 주된 방어 수단으로 삼지 않을 것을 권고하고 있습니다.

그렇다면 봇으로 의심되는 IP를 차단한 다음에는 무엇을 확인해야 할까요?

한 네트워크에서 사라진 IP 요청이 다른 곳에서 나타났습니다.

지난 10월, Cloudflare는 Y 데이터센터 장애 전후의 트래픽을 분석한 글을 공개했습니다. 이 분석에서 눈에 띄는 것은 특정 고객을 향한 봇 요청의 변화였는데요.

한 온라인 도박 서비스 고객 계정으로 유입되던 특정 봇 요청이 장애 직후 끊긴 것 입니다. 그런데 같은 시점, 다른 호스팅 사업자의 네트워크에서 동일한 특성을 가진 요청이 나타났습니다. TLS 연결 지문인 JA4, 특이한 요청 경로와 HTTP 헤더, 사용자 에이전트 문자열이 일치하는 것을 확인할 수 있었고 Cloudflare는 이를 자동화 작업이 다른 호스팅 사업자로 이동한 정황으로 분석했습니다.

이 사례는 네트워크 장애 이후 자동화 요청의 이동을 관측한 분석입니다. 다만 출발 IP 가 바뀐 요청을 살펴볼 때, 해당 I 무엇을 비교할 수 있는지는 보여줍니다. 접속 주소 외에 요청에 남아 있던 여러 특성을 통해 해당 요청의 연속성을 파악할 수 있었습니다.

그렇다면 기업은 접속 IP가 달라진 상황에서 무엇을 기준으로 의심스러운 자동화 요청을 구분해야 할까요?

IP주소와 함께 요청이 남기는 특성을 함께 살펴봐야합니다.

IP 주소는 요청의 출발지를 확인하는 정보입니다. 하지만 앞선 사례에서는 출발 네트워크가 바뀐 뒤에도 요청 경로와 연결 특성이 이어졌습니다. 해당 네트워크의 요청량만 봤다면 이러한 변화를 파악하기 어려웠을 것입니다.

요청에는 접속 주소 외에도 분석할 수 있는 정보가 있습니다. 어떤 경로에 접근했는지, 어떤 헤더를 보냈는지, 연결을 어떤 방식으로 시작했는지 등입니다. 예를 들어 JA4는 TLS 연결을 시작할 때 나타나는 클라이언트의 특성을 바탕으로 만든 지문으로, 비슷한 연결 특성을 가진 요청을 묶어 살펴보는 데 활용됩니다.

이를 서비스 운영에 적용하면 질문도 달라집니다. ‘어느 IP에서 요청이 많이 들어오는가?’에 더해, ‘서로 다른 IP에서 이전의 의심스러운 요청과 유사한 특성이 반복되는가?’를 살펴보는 것입니다.

다만 공통된 지문이 곧 같은 공격자를 뜻하는 것은 아닙니다. Cloudflare 문서에서도 서로 다른 사용자와 기기의 모바일 앱 요청이 같은 JA3 지문을 가질 수 있다고 설명합니다. 연결 지문은 분석 단서이며, 개인이나 공격자의 신원을 확정하는 정보로 해석해서는 안 됩니다.

접속 주소에 요청의 특성을 더해 판단해야 합니다

IP는 출발지에 관한 정보를 제공하지만, 그것만으로 요청의 목적이나 정상 여부가 모두 설명되지는 않습니다. 봇 탐지에서는 요청 헤더, 세션 특성, 브라우저 신호처럼 여러 정보를 함께 활용합니다. Cloudflare의 봇 탐지 문서도 이러한 복수의 요청 특성을 분석 대상으로 설명합니다.

실무에서는 다음 질문을 출발점으로 삼을 수 있습니다.

다만 공통된 특성이 있다는 이유만으로 동일한 공격자라고 확정해서는 안 됩니다. OWASP는 브라우저·기기 지문을 구성하는 정보가 위조될 수 있고, 정상 사용자도 여러 기기와 브라우저를 이용할 수 있다고 설명합니다. 여러 신호와 서비스 맥락을 종합해 판단해야 하는 이유입니다.

차단 이후에는 보호 대상 기능의 변화를 확인하세요

OWASP는 각 방어 수단에서 탐지·완화한 공격량을 기록하고, 지표를 통해 방어 실패나 미탐지 공격, 정책 변경의 영향을 확인하도록 권고합니다.

이를 서비스 운영에 적용한다면, 차단 결과와 서비스 상태를 나란히 보는 방식이 유용합니다. 상품 조회를 보호했다면 의심스러운 반복 조회와 응답 지연의 변화를, 로그인을 보호했다면 비정상 시도와 정상 고객의 로그인 성공 여부를 함께 확인하는 것입니다.

이때 ‘차단 건수가 늘었다’는 결과만으로 효과를 단정하기보다, 전체 유입량과 보호 대상 기능의 요청량을 함께 비교하는 것이 좋습니다. 캠페인 유입이나 시간대별 수요 변화도 지표에 영향을 줄 수 있으므로, 정책 적용 전후에 비교할 조건을 정해 두면 판단에 도움이 될 수 있습니다.

BotManager는 여러 탐지 신호를 결합해 봇을 판단합니다

에스티씨랩의 BotManager는 공개된 기술 설명에서 상호작용, 체류 시간, URL 접근 패턴, 렌더링 특성, 브라우저 정보의 불일치, 자동화 도구의 조작 흔적 등 여러 신호를 종합해 스크래핑 여부를 판단한다고 설명합니다. 단일 조건 대신 누적 점수를 활용하고, 고객사 환경에 따라 민감도를 조절하는 방식입니다.

탐지 방식에 대한 자세한 설명은 「데이터 주권 확보를 위한 강력한 스크래핑 대응 전략」에서 확인할 수 있습니다.

IP 차단 이후에도 같은 문제가 반복된다면, 현재 정책이 어떤 출발지를 막고 있는지에 더해 어떤 자동화 행동을 확인하고 있는지 점검해 보세요. 접속 경로가 달라진 뒤에도 보호 대상 기능의 상태를 살펴보는 것이 다음 대응의 출발점이 될 수 있습니다.

FAQ

Q. IP 차단은 봇 대응에 효과가 없나요?

IP 차단은 단순한 공격을 중단시키는 데 효과가 있을 수 있습니다. 다만 여러 IP에 분산되는 공격에는 한계가 있으므로 다른 탐지·방어 수단과 함께 활용해야 합니다.

Q. IP별 요청 수를 제한해도 봇 공격이 계속될 수 있나요?

그럴 수 있습니다. 개별 IP의 요청량이 제한 기준보다 낮아도, 다수의 IP에서 요청이 합쳐지면 전체 공격 규모는 클 수 있습니다. Akamai도 스크래핑 봇이 호출 속도를 늦추고 여러 주소로 요청을 분산해 요청 제한을 피할 수 있다고 설명합니다.

Q. IP가 달라도 브라우저 특성이 같으면 같은 공격자인가요?

그 정보만으로 확정할 수는 없습니다. 요청 경로, 시간적 패턴, 세션 및 브라우저 신호 등을 함께 살펴야 하며, 일부 특성은 위조될 수도 있습니다.

Q. 봇 차단 정책을 적용한 뒤에는 무엇을 확인해야 하나요?

탐지·차단량과 함께 보호 대상 기능의 비정상 요청, 오류·지연, 정상 고객의 이용 결과를 확인하는 것이 좋습니다. 서비스별 비교 기간과 지표를 미리 정해 두면 정책 적용 이후의 변화를 해석하기 쉬워집니다.