fail2ban을 CrowdSec으로 바꾸다

시작은 침입이 아니라 소음이었다.

내 nginx는 netdata에 연결되어 있어서 이상이 있으면 Discord로 날아온다. 이렇게 생겼는데, 그 시점의 Top IP와 Top Path까지 함께 붙여준다.

진단 정보는 넘칠 만큼 친절하다. 문제는 하루에 수백에서 수천 번 울린다는 것이고, 게다가 그 대부분은 내 서비스에 문제가 생긴 게 아니었다. 스캐너가 /wp-login.php, /.env, 온갖 .php 엔드포인트를 두드려서 생기는 4xx다. 내 사이트에는 PHP가 하나도 없지만 저쪽은 그걸 모르고 신경도 쓰지 않는다. 그냥 계속 두드린다.

(위 사진은 오히려 드물게 "진짜 뭔가 있었던" 경우로, /api/spotify/audio-features가 5분 동안 9968번 맞았다. 그건 내 코드가 루프를 돌고 있었다. IP는 가렸다. 저건 내 출구 주소이기 때문이다.)

당시 이 머신에는 이미 fail2ban이 있었고, 숫자도 훌륭했다.

614개나 차단했다고 하면 쓸모 있어 보인다. 그런데 그 알림 줄을 보다가 한 가지를 깨달았다. 저쪽은 계속 IP를 바꾸고 있다. 하나를 막아도 다음은 다른 회선으로 온다. 이런 식으로 계속 차단해서 끝이 있기는 한 걸까.

이 글은 그 뒤 CrowdSec으로 갈아탄 전 과정이다. 왜 이 상황에서는 fail2ban보다 잘 맞는지, 구축하면서 밟은 세 가지 함정, 이 머신이 6일 동안 실제로 무엇을 막았는지, 그리고 내가 나 자신을 문밖에 가둔 세 번(세 번째가 가장 멍청하고 가장 쓸 가치가 있다). 마지막은 직접 만든 Discord 해제 bot 이야기다. 자기 방어에 갇혔을 때 SSH야말로 닿지 않는 그것이기 때문이다.

이 머신은 어떻게 생겼나#

뒤에 나올 함정도 자기 차단도 구조에 달려 있으니, 먼저 환경을 분명히 해두겠다.

뒤에 영향을 주는 몇 가지.

• 전부 한 대의 물리 머신에서 돌아간다. 집 고정회선에 고정 IP, 라우터가 80/443을 전달해 준다. 클라우드 로드밸런서도 없고, 문제가 생겼을 때 대신 버텨줄 두 번째 장비도 없다.
• 차단은 nftables에서 일어난다. 즉 nginx보다 앞이다. 차단된 요청은 access log에조차 남지 않고, 이쪽에서 보이는 건 연결 거부가 아니라 침묵하는 타임아웃이다. 이 위치 관계가 뒤에 나오는 모든 진단의 토대가 된다.
• CrowdSec 엔진과 bouncer는 별개다. 엔진이 nginx의 log를 읽고 판단하고, bouncer가 방화벽에서 실행한다. 그림의 점선 두 개가 그 루프다.
• nginx 뒤에는 십여 개의 서브도메인이 걸려 있다. 블로그, NAS, 모니터링, MQTT, 자잘한 도구들. 그중 어느 하나의 속도 제한이나 오류도 같은 access log로 흘러들고, 결국 CrowdSec으로 흘러든다.

본문과 관련된 게 하나 더 있다. 내 메인 도메인은 Cloudflare 그레이 클라우드(DNS만 하고 트래픽은 집으로 직결)를 쓰지만, 다른 운영자가 자기 서브도메인 하나를 오렌지 클라우드로 이쪽에 가리키고 있다. 그 경로의 출발지 IP는 Cloudflare 노드가 된다. 이 일은 교차 모니터링 글에서 한 번 나를 물었고, 자세한 건 그쪽에 썼다.

왜 fail2ban이 아닌가#

fail2ban은 망가지지 않았다. 명세대로 자기 일을 제대로 한다. 문제는 그 모델에 있다. 자기 log를 읽고, 자기 실패 횟수를 쌓고, 자기가 본 IP를 차단한다.

IP를 돌려가며 오는 상대에게 이건 두더지 잡기다. 새 IP는 모두 이쪽에 초면이라 0부터 임계값까지 쌓여야 차단되는데, 그때쯤이면 이미 한 바퀴 훑고 지나갔다.

CrowdSec은 전제를 바꿨다. 남이 이미 마주친 나쁜 IP를 그대로 가져다 쓴다.

세 번째 줄의 "bouncer에 맡김"은 실제 아키텍처 차이다. CrowdSec은 탐지와 실행을 분리했다. 엔진은 누구를 막을지 결정만 하고, 방화벽을 건드리는 건 별도의 bouncer다. 이 분리가 뒤에서 중요해진다.

나에게 결정적이었던 게 하나 더 있다. 자체 호스팅이라는 점이다. 당시 다른 선택지는 사이트를 Cloudflare 뒤에 두고 흡수시키는 것이었지만, 그건 트래픽을 남의 프록시에 맡기는 것과 같다. CrowdSec은 로컬에서 log를 읽고 로컬 방화벽에서 실행하므로 기존 구조를 전혀 건드리지 않는다.

세 가지 함정, 뿌리는 하나#

CrowdSec 설치는 두 줄이다.

curl -s https://install.crowdsec.net | sudo sh
sudo apt install -y crowdsec
sudo apt install -y crowdsec-firewall-bouncer-nftables   # Ubuntu 24.04는 기본이 nftables

그리고 하룻밤을 통째로 날렸다. 게다가 세 함정은 도미노 한 장이 넘어진 연쇄였다.

구버전  /var/lib/crowdsec/hub/...
신버전  /etc/crowdsec/hub/...

Source                          Lines read   Lines parsed
file:/var/log/nginx/access.log  41           3

고치는 법은 끊어진 링크를 정리하고 규칙 세트를 다시 설치하는 것이다.

sudo find /etc/crowdsec -xtype l -delete     # "대상이 없는" symlink만 지운다
sudo cscli hub update
sudo cscli collections install \
  crowdsecurity/nginx crowdsecurity/sshd crowdsecurity/linux \
  crowdsecurity/whitelist-good-actors --force
sudo systemctl reload crowdsec

오독하기 쉬운 진단 포인트 두 가지#

cscli metrics의 숫자는 누적값이다. 파싱률을 고쳤는데도 나아지지 않는다고 여긴 적이 있었는데, 새로 파싱된 줄이 과거 실패의 더미에 희석되고 있었을 뿐이다. reload로는 카운터가 지워지지 않고 restart라야 지워진다. "고친 뒤"의 진짜 비율을 보려면 재시작하고 다시 쌓아야 한다.

cscli explain을 쓰면 한눈에 판가름 난다. log 한 줄이 실제로 지나간 parser 사슬을 출력해 주므로 어느 단계에서 실패했는지 곧바로 보인다.

sudo cscli explain --file /var/log/nginx/access.log --type nginx | tail -25

고쳐졌다면 parser failure만 늘어선 게 아니라 crowdsecurity/nginx-logs가 초록으로 통과해 시나리오로 흘러가는 게 보여야 한다.

SSH 수집원은 하나만 남긴다#

내가 직접 조정한 게 하나 더 있다. SSH 이벤트는 /var/log/auth.log에서도 journalctl에서도 읽을 수 있는데, 둘은 같은 이벤트 묶음의 두 입구다. 둘 다 수집하면 로그인 실패가 두 번씩 세어져, 설정한 임계값보다 일찍 시나리오가 발동하고 alert 건수도 부풀려진다.

실측해 보니 양쪽 모두 261건을 파싱했지만, auth.log는 거기 닿기까지 10.13k줄을 읽어야 했고 journalctl은 330줄이면 됐다. 그래서 내 acquis.yaml은 journalctl만 남긴다.

source: journalctl
journalctl_filter:
  - "_SYSTEMD_UNIT=ssh.service"
labels:
  type: syslog

6일에 1619건#

이게 이 머신의 최근 6일 실제 수치다(cscli alerts list 전수 집계).

공격 유형별로 나누면 이렇다.

나머지 롱테일은 CVE 탐색의 행렬이다. CVE-2017-9841(PHPUnit RCE), http-cve-2021-42013, CVE-2022-41082(Exchange), thinkphp-cve-2018-20062, netgear_rce, fortinet-cve-2018-13379, jira_cve-2021-26086. 하나도 쓰지 않는데 그래도 매일 두드리러 온다.

공격은 "나쁜 사람의 컴퓨터"에서 오지 않는다#

출발지 AS의 분포야말로 가장 흥미로운 열이다.

상위 일곱은 거의 전부 클라우드 데이터센터다. Azure, DigitalOcean, 알리바바 클라우드, Hetzner. 스캐너는 시간당 과금되는 VM 위에서 돈다. 한 대를 막아도 다른 한 대를 띄우는 건 몇 초면 되고, IP도 달라진다.

이게 처음의 질문에 대한 데이터 쪽의 답이 된다. IP를 차단하는 길에서는 상대의 비용이 이쪽보다 훨씬 싸다. 그리고 바로 그 지점이 커뮤니티 차단 목록의 가치이기도 하다. 새로 띄운 그 VM은 이쪽에 오기 전에 대개 다른 누군가를 이미 때렸기 때문이다.

Origin                       active_decisions
CAPI (community blocklist)   25.21k
crowdsec (security engine)        8

차단되는 게 전부 나쁜 놈은 아니다#

분명히 해둘 세부가 하나 있다. 어느 차단 목록에 crowdsecurity/http-bad-user-agent로 막힌 167.94.146.48이 있었다. 찾아보니 Censys, 인터넷 전체를 조사하는 연구 기관의 것이었다. 같은 부류로 Shodan이 있다. 이들은 이쪽을 공격하려는 게 아니라 전 세계의 공개 서비스를 목록화하고 있다.

막을지 말지는 각자의 판단이지만, 무엇을 막고 있는지는 알아두는 게 낫다. 덧붙이자면 선의의 크롤러는 걱정하지 않아도 된다. whitelist-good-actors collection이 기본으로 설치되어 Google, Bing, 각 SEO 크롤러가 모두 화이트리스트에 있고, 게다가 User-Agent만 보는 게 아니라 정방향과 역방향 양쪽으로 검증하므로 사칭할 수 없다.

나 자신을 세 번 가뒀다#

여기가 전체에서 가장 기억할 가치가 있는 부분이다. 자동으로 차단하는 시스템은 머지않아 자기 자신을 차단한다.

Ip:<내 출구IP>  crowdsecurity/nginx-req-limit-exceeded  ban  6 events

세 가지 신호로 곧바로 판별할 수 있다#

CrowdSec에 막힌 것과 서비스가 죽은 것은 증상이 실제로 다르다.

셋이 동시에 성립하면 거의 곧장 cscli decisions list를 열고 자기를 찾아도 된다.

고치는 법은 두 층이다#

LAN에는 whitelist parser를 쓴다. s02-enrich에 parser를 하나 두어 RFC1918 전체가 영원히 차단되지 않게 한다.

# /etc/crowdsec/parsers/s02-enrich/lan-whitelist.yaml
name: koimsurai/lan-whitelist
description: "Never ban LAN / RFC1918"
whitelist:
  reason: "private LAN"
  cidr:
    - "192.168.0.0/16"
    - "10.0.0.0/8"
    - "172.16.0.0/12"

이 규칙은 지금까지 16037번 통과시켰다. 없었으면 얼마나 성가셨을지 짐작이 가는 숫자다.

공개 출구 IP에는 allowlist를 쓴다. LAN 화이트리스트는 "밖에 나가 있을 때"를 구해주지 못한다. 그때의 출발지는 공개 IP이기 때문이다.

sudo cscli allowlists create home-dev -d "내 개발 머신 IP"
sudo cscli allowlists add home-dev <당신의 출구IP>
sudo cscli allowlists inspect home-dev

Discord로 나를 꺼낸다#

세 번 모두에 공통된 성가심은 이것이다. 차단을 풀려면 먼저 들어가야 한다. 그리고 내가 막혔을 때 바로 그 안 되는 것이 SSH다.

당시의 대안은 휴대폰이었다. Termux로 붙는다. 평소에는 꽤 좋아하고 필요한 건 다 있다. 그런데 길에서, 한 손으로, 터치 키보드로 sudo cscli decisions delete --ip ... 같은 명령을 치고, 게다가 그 전에 표 전체에서 어느 IP가 나인지 가려내야 한다. 경험이라고 부르기는 어렵다.

사태를 더 성가시게 하는 게 하나 더 있다. CrowdSec은 누구를 차단했는지 기본적으로 알려주지 않는다. profiles.yaml의 notifications 줄은 전부 주석 처리되어 있어서, slack / http / email 플러그인을 직접 연결하지 않으면 아무것도 오지 않는다. 그래서 "내 시스템에 막혔다"는 사실이 먼저 알려지는 일은 없다. 안 붙는다는 걸 알아차리고, 거기서부터 추측이 시작된다.

# /etc/crowdsec/profiles.yaml —— 기본은 이렇다. 알림은 전부 주석
decisions:
 - type: ban
   duration: 4h
# notifications:
#   - slack_default
#   - http_default

그래서 기존 Discord bot에 명령 두 개를 더해 "찾기"와 "풀기"를 함께 해결하기로 했다. 그런데 여기에 구조적 문제가 있다. bot은 컨테이너 안에서 돌고 CrowdSec은 호스트 서비스라서, 컨테이너에서 호스트의 cscli에 닿을 수 없다.

docker socket이나 호스트 root 권한을 컨테이너에 넘기면 해결되지만, 그건 바깥으로 연결되는 bot에게 머신 전체의 통제권을 주는 것과 같다. 그래서 파일 큐로 바꿨다.

컨테이너가 할 수 있는 건 요청 파일을 큐에 놓는 것뿐이다. 실제로 cscli를 실행하는 건 호스트에서 root로 상주하는 watcher이고, 요청을 읽고 검증하고 실행하고 결과를 되돌려 쓴다. 설령 bot이 뚫려도 공격자가 할 수 있는 건 요청 파일을 놓는 것뿐이고, 동작도 제한되어 있어 CrowdSec의 통제권에는 닿지 못한다.

watcher의 핵심 몇 줄:

ALLOWLIST = "parole"          # 해제한 뒤 이 allowlist에도 넣어둔다
ALLOWLIST_TTL = "4h"          # 4시간만. 영구 통행증은 아니다

def valid_ip(s):
    try:
        ipaddress.ip_address(s)   # command injection 차단
        return True
    except ValueError:
        return False

if action == "unblock":
    ip = str(req.get("ip", ""))
    if not valid_ip(ip):
        return {"ok": False, "output": f"invalid ip: {ip}"}
    rc, out = run(["decisions", "delete", "--ip", ip])
    ensure_allowlist()
    run(["allowlists", "add", ALLOWLIST, ip, "-e", ALLOWLIST_TTL])

설계상의 세부 세 가지.

만들고 나니 /crowdsec_list가 현재 차단 목록을 그대로 휴대폰에 펼쳐준다. 각 줄에 IP, 발동한 시나리오, 남은 시간이 들어 있다.

자기 줄을 찾았으면 /crowdsec_unblock에 IP를 넣으면 풀린다. 응답이 parole을 몇 시간 줬는지도 알려준다.

이 목록의 IP들이 겸사겸사 보여주는 게 있다. http-cve-2021-41773, http-wordpress-scan, http-sensitive-files는 모두 앞의 통계에 나온 얼굴들이고, AS를 조회하면 또 Google Cloud와 Azure다. 예시로 가져온 이 한 무리조차 여전히 클라우드 데이터센터에서 도는 스캐너인 것이다.

그리고 전체를 성립시키는 결정적 요소는 실로 단순하다. bot 쪽에서 Discord로 연결하러 나간다. IP가 방화벽에서 DROP되어 막히는 건 "들어오는" 방향이고, bot이 이미 맺어둔 바깥 방향 연결에는 전혀 영향이 없다. 그래서 갇혀 있는 와중에도 이쪽의 명령은 제대로 닿는다.

자기 머신에 세운 web 관리 화면으로는 이게 안 된다. 쓰려면 붙어야 하는데, 바로 그 붙는 것이 안 되기 때문이다. 휴대폰 SSH는 차단을 우회하긴 하지만(모바일 회선은 다른 IP다), 그래도 휴대폰으로 온전한 명령을 쳐야 하는 건 남는다.

처음으로 돌아가서: Discord는 조용해졌나#

조용해졌다. 다만 이유는 애초에 하려던 것과 다르다.

CrowdSec을 설치하는 것과 병행해서, netdata 경고를 잠재우는 설정 파일도 준비해 뒀었다. 4xx 그룹을 silent로 돌리고 5xx와 "느려짐"만 남길 생각이었다. 다 써놨고 명령도 준비되어 있었다.

그런데 방금 들여다봤더니:

$ ls /etc/netdata/health.d/
(비어 있음)

$ ls ~/Server/netdata-web-noise-silence.conf
-rw-rw-r-- 1 timo9378 timo9378 2922  netdata-web-noise-silence.conf

그 무음 파일은 한 번도 배치된 적이 없었다. 아직 홈 디렉터리에 굴러다니고 있다. 그리고 확실히 4xx 경고에 시달린 지 오래됐다.

이유는 4xx가 알아서 사라졌기 때문이다. 지금 같은 access log에서 6038줄을 뽑아 세면 이렇다.

스캐너는 nginx에 닿기 전에 bouncer가 방화벽 층에서 drop하므로 그 404는 log에 한 줄도 남지 않는다. 4xx 비율은 자연히 임계값 아래에 머물고 경고는 발동하지 않는다.

이 결과는 원래 하려던 것보다 훨씬 낫다. 무음은 계기를 가리는 것이고, 이건 정말로 아무 일도 일어나지 않는 것이다. 만약 무음 파일을 먼저 배치했다면, 지금 정말 스캔의 물결이 와도 netdata는 잠자코 있을 테고 나는 유효한 신호 하나를 잃었을 것이다. 실제로는 울릴 때 대개 진짜 뭔가가 있다. 글머리의 그 한 장처럼, 그건 내 Spotify API가 루프를 돌고 있었다.

fail2ban은 그 뒤 어떻게 됐나#

솔직히 말하면 제대로 은퇴시키지 않았다. CrowdSec이 돌기 시작한 뒤로는 신경 쓰지 않았고, 나중에야 어색한 상태로 멈춰 있는 걸 발견했다. 서비스는 돌지 않고 설정 파일은 남아 있다.

$ systemctl is-active fail2ban
inactive
$ systemctl is-enabled fail2ban
disabled

멈춘 경위도 좀 웃긴다. LAN 화이트리스트를 넣으려고 jail.d/에 파일 하나를 뒀는데, 그 파일 때문에 부팅 시 파싱에 실패해서 그대로 올라오지 않게 됐다. 그리고 알아차리지 못했다. 그 기간 내내 CrowdSec이 막고 있어서 증상이 하나도 없었기 때문이다.

여기서의 교훈은 "fail2ban이 나쁘다"가 아니다. 이렇다. 기능이 겹치는 방어 둘을 나란히 뒀을 때 가장 위험한 건 충돌이 아니라, 양쪽 다 지키고 있다고 착각하는 것이다. 그때 멈춘 게 CrowdSec이었다면 나도 똑같이 오래 몰랐을 것이다. 갈아탈 거면 깨끗이 갈아타고, 새것이 정말 돌고 있는지 확인할 것.

한 장짜리 체크리스트#