[Web] 봇과 봇감지, 탐지

#Robot #Web #Detection #SEO #Bot #TCP/IP #HandShake #TLS #JavaScript #Headless #Browser #Orchestration #Framework #Proxy #Latency #WebRTC #DNS #TimeZone #Captcha #PowerPoint

kiio

— 28 min read

봇에 대한 유용한 글을 발견하였고 영어라 읽기 어려워 기술 해석과 작성하면서 모두 읽었는데, 봇에 대한 매우 유익한 글이었다.

A short history of web bots and bot detection techniques · OlegWock
Did you know your favorite website can detect when you’re browsing it in public transport or when you scroll it in your bed? Moreover, this info sometimes helps them to fight bots.

봇과 봇탐지 역사에 대한 흥미로운 블로그 글.

목차

  • 간단한 봇
  • IP 평판 및 프록시
  • TCP 지문
  • TLS 지문
  • 자바스크립트
  • 헤드리스 브라우저
  • 새로운 헤드리스
  • 오케스트레이션 프레임워크
    • IPC Flooding
  • 프록시 감지
    • 레이턴시
    • WebRTC 유출
    • DNS 유출
    • 시간대
  • 캡차
    • 작업 증명
    • 행동 캡차
  • 행동 분석 시작
  • 고급 행동 분석

여기서 이야기하는 봇은 사용자를 모방하여 행동을 수행하는 프로그램 또는 단순한 정보를 수집하는 스크래퍼 의미로 사용하고 있다.

간단한 봇

기초적인 간단한 봇은 HTTP 클라이언트 라이브러리를 사용하는 curl 또는 wget 명령어를 사용한 HTTP 수집 봇이었다.

curl, wget 사용한 봇은 User-Agent 요청 헤더에 자신의 신원을 공개하므로 탐지하고 차단하는 방법은 간단하다고 한다.

GET /html HTTP/1.1
Host: httpbin.org
User-Agent: curl/8.7.1

탐지가 시작되면 봇을 업그레이드한다. curl 명령어에는 User-Agent 변경하는 옵션이 있어서 우회를 시도

curl -v -H "User-Agent: trust me" http://httpbin.org/html
GET /html HTTP/1.1
Host: httpbin.org
Accept: */*
User-Agent: trust me

User-Agent 뿐 아니라 다른 헤더로 탐지 및 차단한다면 다른 헤더도 손을 뻗게한다.
실제 브라우져를 모방해 사용자 언어. 허용된 인코딩 등등 사용자인 것처럼 시작한다.

요약

  • 봇 생성에 curl, wget 사용
  • 봇 탐지에는 User-Agent 등 의심스러운 요청 헤더 기반이다.
  • 봇 생성자는 마치 사용자 인것처럼 브라우져 사용자 헤더를 수정한다.

IP 평판 및 프록시

봇 탐지하는 방법으로 IP 주소 확인하는 방법이다. 장시간 실행, 여러 봇을 실행하거나 클라우드에 호스팅하는 것도 있다.

그렇지만 클라우드를 제공하는 업체 구글, Ocean, AWS 한정된 주소 범위를 할당 받아 사용하는 것으로 알려져 있다. 웹사이트는 클라우드 IP 요청을 받으면 봇이나 자동화된 봇으로 온 것이면 신뢰도가 낮다고 판단한다.

일부 소프트웨어는 API 사용한 수집을 허용하기도 하나, 사용자를 모방한 봇이라면 이야기가 달라진다. 클라이언트에 대한 허용 수준이 모두 다르게 동작한다.
데이터 센터 IP를 차단하고 클라이언트의 최소한의 신뢰만 제공한다.

봇이 안정적으로 작동에는 프록시가 필요하다. 공개된 IP 프록시 주소 범위는 이미 탐지에 사용되고 있다. 그렇다면 어떤 것을 사용해야하는가 주거지 프록시나 모바일 프록시를 사용 방법으로 우회를 시도한다.

웹 서비스는 IP 프록시 탐지하고 싶을 것이다. 사용자의 IP 평판을 조회하고 의심되는 포트를 열렸는지 점검(1080 포트)하고 열렸다면 포트에 대한 대응을 시작한다.

봇 생성자는 주거지 프록시와 모바일 프록시로 인해 IP가 차단될 것이다. 이미 봇이라고 의심하게 하는 위험 신호를 보냈고 웹서비스가 이를 비정상적인 동작과 접속 패턴 점검으로 인해 차단된 것으로 보인다. IP 차단 우회에는 회전 프록시(rotating proxy)이 있다. 통신사로부터 고정 IP 할당 방식이 아닌 동적 IP 할당 방식이며 매번 IP가 달라진다는 것을 이용해 프록시를 달도록 할 수 있다.

이동통신사는 많은 클라이언트의 모바일 프록시로 IP를 바꿔가며 동작한다. 공유하는 IP이므로 봇을 실행해 차단한다면 웹서비스는 IP차단세트에 대량의 IP를 등록하게 될것이다. 그렇게 되면 실제 사용자도 차단해 손실이 일어나 소극적인 태도를 보일 수 있다.

요약

  • 클라우드 업체 IP 신뢰도를 낮게함
  • 웹서비스는 프록시 IP 평판 세트가 있음.
  • IP 평판 세트로 감지 및 차단에 사용
  • 봇 사용자는 프록시 IP를 통신사로 사용
  • 웹서비스는 클라이언트가 프록시 포트를 오픈되었는지 확인하고 접속패턴 등 점검
  • 봇 사용자는 IP 차단 우회로 모바일 통신사가 발급된 IP 사용.
  • 웹 서비스는 모바일 통신사 IP 차단하면 실제 사용자도 차단될 수 있음. 대응에 소극적

TCP 지문

HTTP 요청 전 TCP 연결을 맺게한다. 운영체제별로 TCP 패킷 구성 방식이 다르다는 것을 분석해 OS를 식별한다.

예를 들어 Windows의 User-Agent 요청 헤더로 사용하고 운영체제는 저렴한 OS인 리눅스로 사용하였다면 봇인 것을 감지할 수 있다.

어떻게 감지할 수 있는 것일까? HTTP 요청 전 TCP 연결을 맺게 되고, TCP 전송 프로토콜은 세션 계층으로 운영체제가 관리하고 있다. 또한 TCP 전송은 HTTP 애플리케이션 계층 래핑된 데이터가 있다. 래핑된 데이터는 수신자가 패킷을 압축해제하고 HTTP 애플리케이션이 수신자에게 도달하게 된다.

HTTP 애플리케이션 정보의 바탕으로 윈도우인 것을 알아내었고, TCP 패킷 제어 방식이 리눅스처럼 동작하였다면 웹 서비스는 봇인 것을 감지할 수 있다.

프록시 서버 또한 TCP 지문을 변경할 수 있다. 사용자 에이전트와 일치하는 OS 프록시나 지문 변경되지 않는 프록시를 선택으로 봇을 사용한다.

요약

  • 통신한 HTTP 요청 하기 전 TCP 연결 맺음(TCP handshake, HTTP exchange)
  • HTTP와 TCP 통신 과정은 OS별로 다름.
  • HTTP 에이전트 정보와 TCP 통신 과정 각자 OS가 불일치하다면 탐지하고 차단함
  • 프록시 서버로 TCP 지문을 변경 가능함
  • 사용자 에이전트와 TCP 지문 OS와 일치하는 것을 사용하거나 지문을 변경하지 않는 프록시 선택함
    • 중요한 것은 HTTP 에이전트와 TCP 맺는 것이 OS가 같아야한다.

TLS 지문

TLS 는 통신을 암호화하는 사용하는 프로토콜. 대표적인 프로토콜이 HTTPS가 있다.

클라이언트와 서버 간 암호를 주고받고 사용할 통신 암호를 결정하는 핸드셰이크를 수행한다. 핸드셰이크가 정공적으로 수행되었다면 서로의 암호화된 통신이 가능하다.

여기서도 시스템과 브라우져가 지원하는 암호가 다를 수 있으며 TLS 버전과 TLS 확장자 차이가 있다. 이 정보를 사용하여 OS를 감지해 사용자 에이전트 정보와 일치하는 OS인지 TCP 지문처럼 추출하여 비교할 수 있다.

  • TLS 는 암호화 통신을 수행함
  • 암호를 지원되는 시스템과 브라우져의 차이가 있음
  • TLS 핸드셰이크 과정, TLS 버전과 TLS 확장자 지원도 시스템 차이도 있음
  • 사용자 에이전트 정보를 조회해 핸드셰이크, TLS버전, TLS확장자, 암호 프로토콜 일치하는지 점검하여 의심되는 봇 차단함

자바스크립트

위에서 언급한 탐지 기술은 서버 요청에 대한 응답을 생성 전에 이루어지고 있었다.
알려진 봇 탐지에는 유용하지만 충분하지 않을 수 있다.

봇 탐지의 강력한 도구로 JavaScript를 활용할 수 있다. 사용자 브라우져 정보 토대로 수집하여 서버로 다시 전송해 의심되는 봇을 판단할 수 있다.

자바스크립트를 실행하지 않는 클라이언트는 없거나 사용자가 설정해야 한다.
자바스크립트를 실행하지 않는 클라이언트가 있다면 의심 대상에 포함한다.

탐지를 피하려면 봇은 Javascript 실행해야하는 현실적인 브라우져 환경이 있어야한다.

물론 Chrome, Firefox 실제 브라우져 에이전트로 삼아 제어하는 프로젝트가 있다. HTTP 요청 대신 브라우져를 제어하여 페이지를 열거나 버튼을 클릭하는 행동을 할 수 있다.

어플리케이션 테스트로 만들어진 Selenium 프로젝트가 대표적이다. 봇 개발에도 널리 사용되고 최근에는 Puppeteer Playwright 가 있다.

Chrome DevTools 프로토콜로 Chrome를 제어하는 래핑된 API가 있다.
Playwright, Selenium은 다른 브라우져와 호환되며 주로 Chrome으로 많이 이용한다.

요약

  • 사용자 요청을 받은 서버는 응답을 보내기 전 봇을 탐지하는 기능이 충분하지 않았음.
  • 자바스크립트가 실행 안되는 클라이언트는 봇으로 의심함
  • 브라우져를 제어하는 프로젝트가 있음.
  • 브라우져 제어는 실제 페이지를 열거나 버튼 클릭하는 행동을 수행
  • Chrome DevTools 프로토콜로 직접 브라우져를 제어할 수 있음

헤드리스 브라우져

Chrome을 헤드리스 모드로 실행하는 기능이 있다. Chrome UI가 표시되지 않고 그래픽 환경이 없으므로 서버가 실행한다. Chrome의 별도 구현되어 코드로 구축되어 있는 브라우저이다. 일반 Chrome 실행해 창을 펼치는 것과 다르다.

일반 Chrome과 헤드리스 모드의 Chrome 은 차이가 있으므로 봇 사용자는 발견하는 즉시 패치한다.

  • Headless Chrome는 특수 속성 navigator.webdriver 설정이 true 값
  • 기본 사용자 에이전트에 헤드리스 모드가 포함되어있음
  • navigator.plugins 비어있으나, 일반 브라우져는 몇 가지 플러그인이 붙어있음
  • Headless Chrome는 설치된 확장 프로그램, 통신 페이지 로딩 측정에 사용하는 변수가 없음.
  • Headless Chrome은 WebGL API 에는 동일한 비디오 카드를 보고한다.

봇 사용자는 navigator.webdriver 제거하거나 패치하고 페이지 스크립트가 실행 전에는 코드 조각을 설정하여 조각이 일반 사용자처럼 덮어쓸 수 있다.

봇 사용자는 Headless Chrome를 일반 브라우져처럼 꾸미기 위해 모든 것을 패치한다. 패치되지 않는다면 쉽게 탐지되어 정체가 들통난다. 페이지 스크립트, 워커, 서비스 워커와 같은 여러 컨테스트에서 실행되니 알아두자. 이러한 컨텍스트의 힌트를 모두 패치하고 봇 탐지 업체에서 새로운 힌트를 발견된다면 봇 개발자는 그 힌트의 정체를 파악하는데 노력이 필요할 것이다.

새로운 헤드리스 모드

구글은 2021년 크롬용 새 헤드리스 모드가 개발되어 2023년 4월에 공식적으로 출시한 헤드리스 모드가 있다. 별도의 구현이 아닌 크롬 엔진 기반이기에 기존 헤드리스 크롬이 갖고 있던 단점을 가지고 있지 않아 탐지가 어려워 졌다.

오케스트레이션 프레임워크

헤드리스 모드가 만능은 아니기에 Selenium, Playwright 오케스트레이션 소프트웨어로 관리되어 자동화 탐지 영역을 제공하고 있다.

오케스트레이션 프레임워크인 Selenium, Playwright 특정 브라우져 버전을 사용하고 안정된 버전과 동일한 것이 아니므로 탐지 주요 대상이 된다. 또한 이 프레임워크는 Chrome이 아닌 Chromium 기본으로 사용한다.

오케스트레이션 자동화 프레임워크의 고유 플래그가 있으며 동작을 제어한다. 백그라운드 작업이거나 업데이트 확인, Google 계정과 동기화 해제하는 플래그를 전달해 기능을 비활성화한다. 이런 플래그 일부는 페이지의 Javascript 기능 동작을 수정할수도 있다.. 예시로 Playwright의 iframe 지연로딩 비활성화가 있다. Playwright 웹앱 테스트에 유용하나 웹사이트 제어하는 힌트가 있으므로 봇 탐지 및 감지로 제공된다.

IPC Flooding

자동화 프레임워크 플래그 중 하나로 --disable-ipc-flooding-protection 옵션이 있다. Chrome 아키텍처상에서 각 탭마다 자체 프로세스로 코드를 실행한다. 손상된 탭이 다른 탭과 중앙 프로세스와 통신하지 않아 보안 수준이 높다. 프로세스 간 상호 작용에 IPC(inter process communication) 이용한 것은 중앙 프로세스를 통해 탭 간 메시지를 전달한다.

IPC 비용이 많이 드는 작업으로 두 프로세스 모두 중단(Deadlock)될 수 있으며 사용하지 않는 것이 좋다. 크롬은 각 탭의 별도로 프로세스를 분리하여 보안과 안전성을 높였으나, 중앙 Chrome 프로세스와 통신한다면 시스템이 불안정해질 수 있다.

IPC는 주로 브라우저 내부에 사용되며 Chrome 개발자는 메시지 전송 빈도를 제어한다. 그러나 IPC 통신 트리거 되는 Javascript 몇 가지 함수가 존재한다. 예를 들어 window.history.pushState IPC 통신을 유발하는 함수이다. 이 함수는 짦은 시간에 200회 이상 호출하면 경고를 표시해주고 Chrome은 몇 초 동안 해당 함수의 모든 후속 호출을 무시한다. 그래서 악성사이트가 남용하지 않도록 Flood Protected 기능을 구현했다.

웹 사이트는 이를 이용하여 플러딩 보호가 비활성화한 사용자(봇)를 감지하고 브라우져를 과부하로 정지시켜 정보 수집을 적극적으로 방해한다.

프록시 감지

자바스크립트에서 프록시 감지 방법이 확장 되었다. 프록시를 사용해도 무조건 봇이 아니므로 클라이언트를 신뢰성을 판단하는 요소들로 사용한다.

레이턴시

지연 시간 확인부터 시작한다. TCP 핸드셰이크 통신 과정을 떠올려보자. 수신자 웹 서버는 TCP 핸드셰이크 타이밍을 확인해 지연 시간을 측정할 수 있다.그렇지만 프록시 서버는 수신자 웹 서버와 연결을 설정하기에 프록시와 웹서버 간의 지연 시간을 측정하는 것이 된다.

클라이언트-프록시-웹서버 관계에서 프록시와 웹서버 관계를 알아보았고, 클라이언트와 프록시는 어떨까? 자바스크립트를 사용하여 웹사이트의 웹소켓을 사용한 총 지연 시간(클라이언트가 프록시 거쳐 웹서버로 패킷을 전송하는 시간) 측정할 수 있다.

관찰된 TCP 핸드셰이크보다 훨씬 오래 걸린다면 둘 사이는 프록시가 있다고 신호를 주는 것이다.

WebRTC 유출

봇을 탐지하는데 사용하는 다른 방법은 WebRTC가 있다. WebRTC는 브라우져에서 실시간으로 P2P 통신하는 기술이다. 피어와 통신에는 본인과 피어의 주소를 모두 알아야 이루어진다. 이를 위한 STUN 프로토콜이 사용된다. 알려진 주소인 공개서버(STUN 서버)로 클라이언트가 자신의 IP 주소가 무엇인지 되물어보는 요청을 보낼 수 있다.

WebRTC(STUN 포함) UDP로 통해 작동한다. 그러나 대부분의 프록시는 UDP로 동작하지 않는다. 그래서 Chrome은 WebRTC 요청을 프록시가 아닌 직접 전송하여 JavaScript로 실제 IP 노출하는 방법이 있고, 자바스크립트가 웹 사이트로 전달하게 된다. 그러면 웹사이트는 최초 요청한 수신 IP와 자바스크립트에서 받은 IP를 비교해 일치하지 않으면 프록시로 판단하게 된다.

봇 개발자가 Chrome으로 UDP 지원하는 경우 RTC 요청은 프록시를 통해 라우팅 하는 설정이 필요하며, 그렇지 않다면 라우팅 하지 않도록 해주어야 한다.

DNS 유출

프록시 봇을 감지하는 또 다른 방법으로 DNS 유출로 확인하는 것이다. 프록시/VPN 이 잘못 구성하였다면 브라우져는 기본 DNS 제공업체를 사용해 도메인을 IP 주소로 변환한다. 그러나 이것을 감지하는 것은 자체 권한 네임서버를 관리가 필요하므로 구현이 어렵다.

작동 방식은 몇 개의 하위 도메인 이름을 asdf.leak.mydomain.com 하여 JavaScript로 통해 해당 도메인으로 요청을 전송합니다. 브라우져는 이 도메인에 요청을 보낸 적이 없다면 해당 도메인을 확인하는 절차를 수행한다. DNS에 요청을 보내고 수신자 DNS 는 권한 있는 네임서버로 요청을 보냅니다. DNS 리졸버는 주소와 위치 정보를 데이터베이스에 저장하여 서버의 IP 주소를 반환합니다. DNS 리졸버는 이 IP 주소 브라우저에게 반환하고 브라우저는 서버로 요청을 보내게 됩니다. 서버에서는 클라이언트 IP 주소와 위치를 저장하고 이것과 DNS 리졸버의 IP 주소 및 위치를 비교하게 됩니다.

DNS 리졸버가 구글 또는 클라우드플레어 글로벌 서비스가 아니라면 클라이언트의 ISP 에서 제공되는 DNS일 가능성이 높다. 두 리졸버의 위치를 비교해 슬로바키아 클라이언트가 이름 없는 베트남의 DNS 리졸버를 사용하였다면 의심스러우므로 클라이언트가 VPN이나 프록시를 사용하는 것은 유추할 수 있다.

VPN 제공업체가 자체 DNS 리졸버를 제공하여 위치 및 출구 게이트웨이와 일치하면 이러한 문제를 피할 수 있다. Google의 8.8.8.8, Cloudflare의 1.1.1.1 널리 알려진 DNS 리졸버를 사용하므로 어느 정도는 해결이 된다. 그러나 이러한 서비스는 위치 기반 라우팅을 구현하므로 지연 시간을 줄이기 위한 물리적으로 가까운 DNS 요청을 처리해 이로 인한 보안이 취약해질 수 있다.

시간대

브라우저 시간대를 확인하는 방법. JavaScript 는 브라우저 시간대를 가져와 서버로 전송. 서버에서 IP 위치를 기반으로 하는 시간대와 비교하게 됩니다. 두 시간대가 일치하지 않는다면 프록시를 사용하는 단서가 된다.

Captcha

봇을 감지하는 방법을 많이 다뤘지만 봇과 가장 많이 싸우는 캡챠는 언급하지 않았었다.

캡챠는 이전 방식과 달라 봇을 탐지하는 것이 아닌 봇으로부터 보호하는데 사용한다. 캡챠는 사람에게 비교적 쉽게하고, 기계에게는 불가능에 가깝도록 한다. 그림에서 노이즈가 있거나 왜곡된 그림으로 쓰여진 내용으로 추측하는 정도였다. 요즘 캡챠는 굉장히 다양한 형태로 나타내고 있다.

하지만 캡챠는 봇에게 큰 불편을 주지 못하고 있다. 캡챠 통과에는 봇이 아닌 실제 사람에게 아웃소싱으로 이용하고 있다.

저소득 국가의 근로자를 고용하여 캡챠를 풀고 개발자가 이 과정을 자동화하는 API 제공하는 서비스가 있다. 캡챠 1000개당 1~2달러 소요로 저렴한 비용으로 이용하고 있다.

작업 증명

작업 증명(PoW) 방식에는 몇 가지 캡차 프로젝트가 있다. 캡차는 사용자의 상호작용을 요구하지 않으며 기기가 캡챠 통과에 일정량의 암호화 연산을 수행을 요구한다. 이 캡챠는 봇을 차단하는 것이 아닌 봇의 자원을 소모시켜 경제적으로 실행 불가능하도록 하는 것이다.

이러한 캡차를 사용할 경우 성능이 낮은 기기 사용자에게 영향이 끼친다. 캡차 통과에 적정 작업량을 선택하는 것이 중요하며 캡차를 낮게 설정하였다면 사양이 높은 봇의 캡차를 허용하게 된다. 요즘은 서버 비용도 저렴하므로 대규모 스탬 공격을 막으려는 경우가 아니라면 작업 증명 캡차는 유용하지 않다.

행동 캡차

캡차의 또 다른 도전 과제로 행동 캡차가 있다. "나는 로봇이 아니오" 클릭하는 이상한 캡차이다. 고양이랑 개 사진도 없고 이게 전부인가? 생각이 들 정도로 간단하다. 이 캡차는 나를 믿는 걸까? 의문을 들게 할 정도로 간단한 캡차이다.

이러한 캡챠는 클라우드플레어 턴스타일 그리고 구글 리캡챠가 있다. (이 캡차는 자동차를 선택하도록 요구할 수 있다.)

사실 그들은 진심으로 여러분을 신뢰하지 않는다. 이 캡차는 봇인지 확인하는 다양한 기술을 사용하고 브라우저에서 독특한(예: navigator.webdriver) 것들을 감지하거나 작업 증명(Proof-of-Work) 문제와 행동 분석이 포함되어 있다. 그리고 이러한 결과의 바탕으로 여러분의 브라우저의 행동이 정상적인지 판단한다.

이런 서비스는 봇 탐지 서비스같지만 약간의 차이점이 있다. 클라이언트를 지속적인 모니터링보다는 웹사이트의특정 부분과 기능에 대한 관문 역할과 여러 챌린지들을 한다.

언급한 캡차 해결 서비스들은 이러한 챌린지를 물론 우회가 가능하다. 봇이 해당 서비스에 작업을 전송하면 사용자가 실제 브라우저에 페이지를 열고 챌린지를 통과하면 그만이다. 이러한 원리는 캡차가 키를 생성하고 이 키로 서버가 클라이언트에게 챌린지를 통과하였는지 확인하는데 사용한다. 키를 봇으로 전달하여 봇이 키를 사용해 웹사이트에 접근하고 작업을 이어나갈 수 있다.

행동 분석하기

이 글에서 많은 기술을 다루게 되었다. 하지만 그것은 기술이고, 웹사이트 접속에 사용하는 소프트웨어와 하드웨어에 대한 설명이었다. 봇 탐지에는 또 다른 접근법이 있다. 클라이언트의 환경의 불일치보다는 클라이언트의 행동을 파악합니다.

기계에 비해 사람은 느리고 비효율적이며 웹을 탐색하는데 우리가 수행하는 추가적인 행동을 많이 합니다. 글을 읽을 때 커서로 문장을 따라가고, 긴 글을 입력할 때에는 실수를 합니다.

기계는 1초만에 작업을 처리할 수 있는 이러한 일들을 오타도 없고 불필요한 동작도 수행하지 않습니다. 이러한 점이 기계의 정체를 드러내게 하는 것입니다. 봇 감지 서비스는 자바스크립트를 사용해 사용자 동작을 모니터링하여 사람인지 판단합니다.

예를 들어, 마우스부터 살펴봅시다. 우리의 행동에는 불필요한 마우스 움직임을 수행하고 다양한 곡선과 궤적으로 움직이지만, 봇은 이러한 것을 신경쓰지 않습니다. 다만 무언가를 클릭할 때는 마우스 움직임을 생성합니다. 봇은 클릭하고 매우 빠르게 직선으로 움직여 쉽게 감지할 수 있게됩니다. 요소의 정중앙을 클릭하고 클릭의 mousedown 이벤트 사이의 지연시간 mouseup 이 굉장히 짦습니다. 사람과 클릭하는 방식이 완전 다릅니다.

타이핑에도 봇은 일정한 고속으로 타이핑하고 이벤트 간 지연 시간 keydown, keyup 지연이 매우 짦습니다. 사람은 키를 누르고 놓는 시간과 다음 키를 누르는 시간 사이에 지연 시간이 편차가 있습니다.

봇에 무작위 지연을 적용되었더라도 (a) "충분히 긴 텍스트의 무작위 멈춤은 스펙트럼 전체에 균일하게 분포" (b) "사람이 타이핑에 발생하는 지연은 무작위가 아닌 키 사이의 거리에 따라 다름" 으로 인해 여전히 감지할 수 있게 됩니다.

모바일 기기의 봇의 특징은 기기의 움직임을 감지하지 않습니다. 모바일 브라우저는 deviceorientation 사용자의 움직이는 이벤트를 생성하고 devicemotion 10ms 마다 기기 가속도 정보가 포함된 이벤트가 발생합니다. 헤드리스 크롬은 이러한 이벤트를 발생하지 않으므로 웹사이트가 거짓말하는지 쉽게 감지할 수 있습니다. IP 주소 확인과 기능을 함께 사용하여 좋아하는 사이트에서 사용자가 침대에 누웠는지 출퇴근 중인지 판별할 수 있습니다.

봇이 지나치도록 효율적으로 작동하는 마지막 사례로는 페이지의 요소와 상호작용하는 방식에 있습니다. 사람이 어떤 버튼이 나타나기를 간절히 기다리더라도, 버튼이 나타났을 때 클릭하는데에는 수십 밀로초가 필요하고 봇이 어떤 요소가 나타나기를 기다릴 때는 즉시 클릭하도록 합니다.

고급 행동 분석

키 입력으로 지연시간을 체크하는 단순한 행동 분석으로는 한계가 있습니다. 봇들이 나은 기술로 사용하기 시작한다면 봇은 정교해지고 웹서비스는 봇 감지에 더 나은 행동들을 분석 해야합니다.

그렇지만 봇 탐지 서비스로 이점을 얻어가는 것이 있습니다. 업무에 능숙하고 실제 고객을 보유했다는 것으로 전제로 합니다. 관리하는 사이트의 많은 행동 데이터에 접근할 수 있었고, 앞 서 설명한 기법을 사용해 필터링되고 사람과 봇에서 발생할 가능성이 높은 행동만 포함된 데이터 세트를 갖게 됩니다.

이 모든 데이터로 무엇을 해볼까요? 바로 AI로 훈련시켜보는겁니다. 거대 LLM이 아닌 더 작고 구체적인 모델을 만들어볼 수 있습니다. 사람과 봇의 행동 데이터를 사용한 모델을 훈련하고 새로운 사이트의 방문자의 행동을 분류하여 점수를 매길 수 있습니다.

이 모델의 봇 탐지에 매우 효과적일 수 있지만 고급 봇에서도 모방이 어려운 인간 행동 패턴을 학습합니다. 예를 들어, 페이지 탐색시 특정 궤적으로 움직이는 경향이 있다는 것을 학습하면 타이핑때 키 입력 사이의 특정한 패턴이 있다는 것을 학습합니다.

그렇지만 이는 단순 탐지 알고리즘보다 많은 리소스와 정교한 지식이 필수로 요구됩니다. 봇 방어에도 효과를 얻을 수 있습니다. 이 글에서 설명한 봇 탐지 서비스의 최종 단계가 아닌 다른 기법들과 결합한 강력한 봇 탐지 서비스를 구성하는 요소로 자리잡게됩니다.

더 읽어볼 내용