TL;DR

  • 자체 분석을 운영하는 사이트에서 404 오류 분석 패널이 SQL 인젝션 시도로 넘쳐나자, Caddy 규칙과 429 응답으로 요청을 차단함.
  • 클라이언트 측 스크립트로 기본 방문 수와 유입 정보 등을 수집하고, 서버 요청에서는 404 오류를 확인함.
  • 404 기록은 깨진 링크와 비슷한 경로를 찾는 데 쓰이지만, 퍼저의 요청이 패널을 어지럽힘.
  • SQL 인젝션 시도는 성공하지 못했지만 다량으로 발생했고, 일부 요청은 URL에 곱셈식을 넣어 계산 결과를 확인하려는 형태임.
  • 404 오류가 10회 이상인 IP를 스캐너로 간주해 분석에서 제외하고, 존재하지 않는 경로를 추측하는 IP에는 429 응답을 보냄.

404 오류 분석과 퍼저 요청

  • 이 사이트에서 자체 분석을 운영함. 수집 항목을 최소화하면서 기본 방문 수, 유입 정보, 수정할 수도 있는 404 오류 목록을 제공하는 간단한 방식임.
  • 서버 측 분석 데이터는 잡음이 많아 대부분의 통계를 간단한 클라이언트 측 스크립트로 수집함. 서버 요청에서 확인하는 항목은 404 오류임.
  • 404 오류를 살펴보며 깨진 링크, 비슷하지만 일치하지 않는 경로, 정리할 만한 항목을 찾음.
  • 이 방식의 불편한 점은 퍼저가 온갖 요청을 보내면서 분석 패널을 가득 채운다는 것임.
  • 한동안 URL을 수동으로 제외하는 방식으로 관리할 수 있었지만, 최근 누군가 SQL 인젝션 시도를 대량으로 보내면서 대응이 어려워짐. 시도는 하나도 성공하지 못했지만 수가 많았음.

Caddy에서 SQL 구문 차단

  • 사이트는 Caddy로 제공되므로 SQL 구문과 일치하는 path_regexp를 추가해 해당 연결을 끊음.
  • 일부 요청은 URL에 곱셈식을 넣고 계산 결과가 돌아오는지 확인하는 형태였음. 확인한 바로는 Acunetix나 Invicti Web + API 등에서 하는 동작으로 보임.

내 라우터는 계산기가 아님.

404 스캐너에 대한 응답

  • Caddy 설정 변경에 더해 404 경로를 계속 추측하는 IP에 429 응답을 보냄.
  • 존재하지 않는 경로를 열거하지 말라는 방침이며, 분석에서는 404 오류가 10회 이상인 IP를 스캐너로 취급해 제외함.
  • 여전히 말이 안 되는 요청을 수동으로 제외하고 있지만, 그 수는 훨씬 줄어듦.

관련 글

  • 비표준 사이트에 standard.site 구현하기: 사이트를 Go로 작성한 뒤, 공개 웹과 연결되는 기능을 복원하고 추가하는 내용임.
  • 봇과의 싸움: 스크레이퍼 대응을 위해 국가 전체를 차단하고, 정상적인 봇을 위해 robots.txt를 갱신하며, 일부 요청에 403 응답을 보내는 내용임.
  • 2024년 돌아보기: 한 해를 돌아보며 거시적 상황이 암울하다는 점을 먼저 언급하는 내용임.