크롤링

#네트워크/웹

크롤링을 수행하는 방법과 서비스들이 크롤링을 감지하고 차단하는 방어책들, 그 기나긴 싸움과 경향성에 대해서 정리해본다.
크롤링 대상 시스템은 HTTP 기반 웹 시스템이라고 가정한다.

정적 크롤링과 동적 크롤링

크롤링은 크게 2가지 방식으로 나뉜다.

정적 크롤링

정적 크롤링은 스크래핑(scrapping)이라고도 한다.
어찌되었든 모든 사이트는 API로 데이터를 내려준다.

저기서 필요한 API만 API 클라이언트로 호출하고, 그 응답값을 파싱해서 적절히 수집하는 것이다.

그런데 이런 정적 크롤링은 리소스를 최소한으로 소모하고 매우 빠르다는 장점이 있지만, 사이트에 따라서는 구현하기가 굉장히 번거롭거나, 혹은 차단을 회피하기 어렵게 만들어져있을 수도 있다.

B. 동적 크롤링

동적 크롤링은 그에 대한 대안으로, 진짜 브라우저나 가벼운 브라우저 구현을 사용해서 사이트를 직접 열고, 그 데이터를 가져오는 방법을 말한다. 대표적인 구현체로는 셀레니움, puppeteer, playwright 등이 있다.

셀레니움은 대부분의 언어에서 사용 가능하지만, puppeteer를 비롯한 여타 엔진들은 node.js 환경에서 제공된다. 그래서 사실 크롤링을 한다고 하면 nodejs 환경을 선택하는게 대안이 많은 편이다.
각각이 동작 방식이 조금씩 다르고, 경우에 따라서 크롤러 차단 패턴을 회피하기에 용이한 이점이 있을 수도 있다.

headless 모드
그런데 또, 사이트를 직접 화면으로 열고 렌더링하는건 리소스 소모가 극심한 문제가 있다. 그래서 이런 크롤링 엔진들은 headless 모드란걸 통해서 화면 처리를 생략하는 기능을 제공한다. 이걸 써야 그나마 조금 빨라지고 리소스 소모를 줄일 수 있다.

자 그럼, 이제부터는 서비스들이 크롤러를 감지하고 차단하는 방법론들을 하나씩 다뤄보겠다.

서버 환경 구성 (with Rust hyper)

일단 방어자의 입장에서도 확인을 하기 위해서, 크롤링 대상이 되는 모형 서버도 하나 띄우겠다.
언어는 Rust로 선택했다. 특별한 이유는 없다.

[package]
name = "just_test"
version = "0.1.0"
edition = "2021"

[dependencies]
hyper = { version = "1", features = ["full"] }
tokio = { version = "1", features = ["full"] }
http-body-util = "0.1"
hyper-util = { version = "0.1", features = ["full"] }
flate2 = "1.0"

use std::convert::Infallible;
use std::net::SocketAddr;

use http_body_util::Full;
use hyper::body::Bytes;
use hyper::server::conn::http1;
use hyper::service::service_fn;
use hyper::{Request, Response, StatusCode};
use hyper_util::rt::TokioIo;
use tokio::net::TcpListener;

async fn hello(_: Request<hyper::body::Incoming>) -> Result<Response<Full<Bytes>>, Infallible> {
    let response = Response::builder()
        .status(StatusCode::OK)
        .body(Full::new(Bytes::from(
            "<html><body><h1>OK</h1></body></html>",
        )))
        .unwrap();

    Ok(response)
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let addr = SocketAddr::from(([0, 0, 0, 0], 3333));

    let listener = TcpListener::bind(addr).await?;

    loop {
        let (stream, _) = listener.accept().await?;

        let io = TokioIo::new(stream);

        tokio::task::spawn(async move {
            if let Err(err) = http1::Builder::new()
                .serve_connection(io, service_fn(hello))
                .await
            {
                println!("Error serving connection: {:?}", err);
            }
        });
    }
}

그리고 실행하면

일단 잘 돈다.

그리고 공격자, 크롤러는 nodejs 환경을 사용하겠다.

이것도 마찬가지로 잘 긁어올 것이다.

이제 크롤러를 막아보자.

User-Agent 기반 차단

예전부터 굉장히 많이 사용했던 방법이다.
요즘에는 이걸 중점으로 막지는 않지만, 여전히 아무튼 없으면 막히는 경우가 많다.

브라우저가 사이트에 진입한다면 기본적으로 던지는 요청 헤더들이 있다.
그 중 대표적인 것이 브라우저 속성을 나타내는 User-Agent다.

브라우저를 사용해서 동적 크롤링을 할 경우에는 이것도 브라우저와 동등하게 넣어줘서 문제가 없지만, HTTP client를 써서 찌른다면 이상한 값이 포함되거나 아예 안갈 수도 있다.

예를 들어, 클라이언트 라이브러리인 axios의 경우에는 User-Agent 헤더로 자기주장을 한다.
헤더를 명시하지 않아도 알아서 저렇게 암시적으로 보내는 숨은 동작들이 숨어있다.

특히 User-Agent에 axios/1.7.9처럼 버전이 박혀있는건 너무 뻔하다.

이건 nodejs/axios만 그런건 아니고, 대부분 언어들의 HTTP client 라이브러리들이 다 저런 동작을 가지고 있다.
이 문제를 해결하려면 User-Agent 헤더를 명시적으로 null로 보내서 아예 사라지게 하거나, 아니면 진짜 브라우저에서 보내는 User-Agent를 똑같이 보내주는 방법이 있다.
보통은 후자가 더 좋은 선택이다.

그리고 예전에는 같은 User-Agent로 과도한 요청이 들어오면 해당 User-Agent와 IP 쌍으로 차단을 거는 경우가 있었다. 이럴 때는 User-Agent를 랜덤으로 할당해서 회피하면 회피가 됐는데, 요즘은 그런 곳이 거의 없을 것이다.

IP 기반 차단

이래나저래나 크롤러를 막는 가장 강력한 방법 중 하나는 IP 기반으로 통제를 가하는 것이다.

서버는 당연히 클라이언트의 공인 IP를 알 수 있고, 특정 IP에서 과도한 요청이나 의심스러운 요청 패턴이 발견되면 차단을 먹일 수 있다.
공인 IP는 바꿔가면서 사용하기 어렵기 때문에 대부분의 상황에서 유효한 방법이고, 또 대부분의 크롤러 탐지 시스템들은 IP에 기반한 차단을 수행한다.

물론 그렇다고 해서 회피 방법이 없는건 또 아니다.
공인 IP를 여기저기서 잔뜩 긁어모아서 돌아가면서 쏘면 또 되는거기 때문이다.

AWS, GCP 같은 퍼블릭 클라우드 서비스를 쓴다면, 인스턴스를 띄울때마다 새로운 공인 IP를 발급받는다. 차단당하면 새로 재시작해서 찌르면 또 되는 것이다.
게다가 AWS Lambda, GCP Function 같은 서버리스 서비스들은 실행될때마다 무작위의 위치에서 무작위의 공인 IP를 가지고서 동작한다. 이런걸 프록시로 쓰는 것도 쓸만한 방법이다.

근데 그렇다고 해서 클라우드로 찌르는 것도 만능은 아니다.
AWS 같은 유명한 클라우드 서비스들의 IP 대역은 정해져있고 잘 알려져있다. 그러니까, 그 대역을 통째로 사전에 차단해버리면 되는 것이다. 실제로 많은 크롤러 탐지 솔루션들이 자체적인 IP 블랙리스트를 들고서 차단을 먹인다. 그래서 요즘은 AWS IP로 접근이 안되는 서비스들이 꽤 있다.

CAPTCHA

근데 의심스러운 패턴이 발견되었다고 해서, 무작정 차단을 걸어버리는 것도 마냥 좋은 방법이라고 볼 수는 없다.
진짜 일반 사용자인데 어쩌다 찍혀서 억울하게 차단당할 수도 있고, 공인 IP에 함께 묶인 무고한 피해자들이 생길 수 있기 때문이다.

그래서 많은 크롤러 차단 솔루션들은 IP에 차단을 걸때, 사람임을 확인해서 차단을 풀어주는 시스템을 도입했다.
그게 바로 CAPTCHA라는 시스템이다.

프로그램이 하기 어렵고, 사람은 쉽게 할 수 있는 문제를 출제해서, 그걸 풀면 차단을 풀어주는 것이다.

초기에는 다 저렇게 그냥 꾹 누르는 캡챠라서 풀기 쉬웠다. 그냥 셀레니움 띄워서 좌표 찍고 클릭만 해도 되는 것이기 때문이다.

그런데 요즘에는 무슨 드래그해서 퍼즐을 푸는 것도 있고, 방향 맞추는 것도 있고, 일반적으로 처리하기 어려운 캡챠들이 많아져서 공격자 입장에서는 매우 어려운 경우가 많아졌다.

이것도 요즘은 딥러닝 기반으로 뚫는 시도도 있고 계속해서 창과 방패의 싸움이 지속되긴 하는데, 대체로는 방어자가 좀 더 유리한 것 같다.

쿠키 기반의 패턴 추적

많은 사이트는 쿠키를 기반으로 사용자의 패턴을 추적할 수 있다.
그리고 쿠키가 없으면 접근을 아예 제한하기도 한다.

예를 들면, 쿠키가 같은데 갑자기 사용자의 IP 주소가 한국에서 미국 IP로 바뀐다거나 하면 바로 의심스러운 사용이라고 판단할 수 있다.
그래서 실제로 그런짓을 하면 차단당하는 사이트가 매우 많다.

이벤트 추적

사용자의 하드웨어 기반 행동으로 크롤러를 식별하는 방법도 있다.

마우스 이동, 클릭, 키 입력 등에 리스너를 등록해서, 충분한 마우스 동작 이벤트와 함께 사이트 이동이 된다면 정상적인 사용자로 판단하고, 마우스 클릭 이벤트가 없는데 사이트 이동만 되면 크롤링으로 판단하고 차단을 먹이는 것이다.

실제로 Cloudflare가 적극 활용하는 방법이다.

크롤러 탐지 기법: Fingerprinting

크롤러를 탐지하는 방법은 여러가지가 있는데, 또 흔하게 사용하는 접근법이 Fingerprint라는 기법이다.

쉽게 말해 이건 해당 요청자를 식별할 수 있는 고유번호 같은걸 만들어내는 것인데, 계층이 몇가지가 있다.
여기서 다루지 않은 것도 몇가지가 더 있다.
아우튼 요지는, 생성된 fingerprinting을 기반으로 흑마술을 쥐어짜서 크롤러가 하는 거짓말을 식별하는 것에 있다.

TLS 프로토콜 수준 Fingerprinting

TLS 핸드셰이크로 암호화 작업을 하는 시점에 패킷들을 분석해서 Fingerprint를 만드는 기법이다.
이건 단순히 사용자를 고유하게 식별하는게 그치는게 아니라, 실제로 브라우저 말고 이상한 클라이언트로 접근했는지까지도 확인할 수 있다.
일반적인 브라우저가 TLS 암호화를 처리하는 방식과, 기타 클라이언트들이 TLS를 처리하는 방식이 대체로 달라서 가능한 부분이다.

그래서 User-Agent에 들어있는 브라우저 정보와, TLS Fingerprint로 알아낸 브라우저 정보가 일치하는지를 알아내고, 다르다면 크롤러로 판단해서 차단을 먹일 수 있는 것이다. 대표적으로 Cloudflare가 이렇게 한다.

Canvas 기반 Fingerprinting

canvas나 기타 하드웨어 정보 등을 활용하면 해당 머신이나 브라우저에서는 거의 고유한 값을 얻을 수 있다.
아래는 그에 대한 간단한 예제 코드다.

function generateFingerprintFromCanvas() {
  // canvas 생성
  const canvas = document.createElement("canvas");
  const ctx = canvas.getContext("2d");
  const txt = "abz190#$%^@£éú";

  ctx.fillStyle = "rgb(255,0,255)";
  ctx.beginPath();
  ctx.rect(20, 20, 150, 100);
  ctx.fill();
  ctx.stroke();
  ctx.closePath();
  ctx.beginPath();
  ctx.fillStyle = "rgb(0,255,255)";
  ctx.arc(50, 50, 50, 0, Math.PI * 2, true);
  ctx.fill();
  ctx.stroke();
  ctx.closePath();

  ctx.textBaseline = "top";
  ctx.font = '17px "Arial 17"';
  ctx.textBaseline = "alphabetic";
  ctx.fillStyle = "rgb(255,5,5)";
  ctx.rotate(0.03);
  ctx.fillText(txt, 4, 17);
  ctx.fillStyle = "rgb(155,255,5)";
  ctx.shadowBlur = 8;
  ctx.shadowColor = "red";
  ctx.fillRect(20, 12, 100, 5);

  const src = canvas.toDataURL();
  return src;
}
generateFingerprintFromCanvas();

이건 진짜 대충 만들어져있는거라 큰 의미는 없는데, 아무튼 device 수준에서 불변인 값을 만들 수 있다는 것이다.

Cloudflare의 경우에는 접속 기록을 기반으로 User-Agent와 canvas fingerprint 기록을 쌓아놨다가, User-Agent와 canvas fingerprint 값 쌍이 일치하지 않으면 크롤러로 감지하는 트릭을 사용한다.

헤드리스 브라우저 감지 (puppeteer)

이것도 하나의 예시만 들어보겠다. 끝도 없이 나오기 때문이다.

서버에서 뿌려주는 클라이언트측 스크립트에 헤드리스 브라우저에만 존재하는 값을 감지하는 코드를 심으면, 이 또한 강력한 크롤링 방어법이 될 수 있다.

웹드라이버 활성화 같은 것은 통상 브라우저에서는 없으나, puppeteer 같은 헤드리스 브라우저에는 true로 존재하는 값이다.
그래서 저걸 감지하면 로그도 찍고 차단도 찍게 만들었다.

차단 API는 대충 이렇게 뚫었다.

그리고 브라우저에서 띄우면

아무 문제 없이 동작하지만

퍼펫티어로 띄우면

import puppeteer from "puppeteer";

async function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function main() {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();

  await page.goto("http://localhost:3333");
  await sleep(1000);

  await page.setViewport({ width: 1080, height: 1024 });

  const textContent = await page.evaluate(() => {
    return document.querySelector("h1")?.textContent;
  });

  console.log(textContent);
}

main();

바로 웹드라이버가 감지돼서 차단 스크립트가 동작할 것이다.

이건 비단 헤드리스 모드에만 해당되는건 아니고, headless 모드를 끄고 켜도 마찬가지다.
그리고 셀레니움과 puppeteer를 포함한 대부분의 크롤링용 브라우저가 전부 이 문제가 존재한다.

이 문제에 한해서라면 해결법이 없는건 아니다. 스크립트를 우겨넣어서 동적으로 저 값을 조작시킬 수도 있고, 실행시에 플래그를 넣어서 webdriver가 비활성화된것처럼 보이게 할 수 있다.

하지만 문제는, 이런 탐지법이 꽤 다양하고, 지금도 보고되고 있다는 것이다.
헤드리스 브라우저 환경에만 존재하는 특수한 동작이나 값들이 너무 많다보니 여기도 창과 방패의 싸움이 지속되고 있다.

그래서 이런 클라이언트측 검증을 피하는 것에 한해서는 아예 헤드리스 브라우저를 쓰지 않고 HTTP Client로 정적 파싱을 하는게 효과적일 수 있다. 스크립트 동작이 안되니까...!

다음은 방금 사용한 예제 코드다.

import puppeteer from "puppeteer";

async function sleep(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function main() {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();

  await page.goto("http://localhost:3333");
  await sleep(1000);

  await page.setViewport({ width: 1080, height: 1024 });

  const textContent = await page.evaluate(() => {
    return document.querySelector("h1")?.textContent;
  });

  console.log(textContent);
}

main();

use std::convert::Infallible;
use std::net::SocketAddr;

use http_body_util::Full;
use hyper::body::Bytes;
use hyper::server::conn::http1;
use hyper::service::service_fn;
use hyper::{Request, Response, StatusCode};
use hyper_util::rt::TokioIo;
use tokio::net::TcpListener;

const DETECT_PUPPETEER_SCRIPT: &str = r#"
<script>
let isBot = false;

if (navigator.webdriver) {
    console.log(1)
    isBot = true;
}

if (isBot) {
	console.log("Your bot has been detected!")
    fetch("/banned");
}
</script>
"#;

async fn hello(
    request: Request<hyper::body::Incoming>,
) -> Result<Response<Full<Bytes>>, Infallible> {
    let path = request.uri().path();
    if path == "/banned" {
        println!("차단됨!!");

        let response = Response::builder()
            .status(StatusCode::OK)
            .body(Full::new(Bytes::from(
                "<html><body><h1>Banned</h1></body></html>",
            )))
            .unwrap();

        return Ok(response);
    }

    request.headers().iter().for_each(|(name, value)| {
        println!("HEADER {}: {}", name.as_str(), value.to_str().unwrap());
    });

    let response_body = format!("<html><body><h1>OK</h1></body>{DETECT_PUPPETEER_SCRIPT}</html>")
        .as_bytes()
        .to_vec();

    let response = Response::builder()
        .status(StatusCode::OK)
        .body(Full::new(Bytes::from(response_body)))
        .unwrap();

    Ok(response)
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let addr = SocketAddr::from(([0, 0, 0, 0], 3333));

    let listener = TcpListener::bind(addr).await?;

    loop {
        let (stream, _) = listener.accept().await?;

        let ip = stream.peer_addr()?.ip();
        println!("Connection from: {}", ip);

        let io = TokioIo::new(stream);

        tokio::task::spawn(async move {
            if let Err(err) = http1::Builder::new()
                .serve_connection(io, service_fn(hello))
                .await
            {
                println!("Error serving connection: {:?}", err);
            }
        });
    }
}

크롤링 대상 사이트가 이런 방어법을 한두가지만 쓴다면 어떻게 뚫을 수 있겠지만, 이 모든 방어법을 적용해놨다면 뚫기가 정말 어려울 것이다.

이 앞은 험난한 길이다.

참조
https://medium.com/@mayankchandel2567/how-does-cloudflare-bot-detection-work-d77179756cdc
https://murraycole.com/posts/web-crawling-stealth
https://deviceandbrowserinfo.com/learning_zone/articles/detecting-headless-chrome-puppeteer-2024
https://medium.com/@mayankchandel2567/exploring-methods-of-evading-datadomes-bot-protection-a-comprehensive-guide-for-2023-ef5274ee1698
https://piprogramming.org/articles/How-to-make-Selenium-undetectable-and-stealth--7-Ways-to-hide-your-Bot-Automation-from-Detection-0000000017.html
https://dev.gmarket.com/94