CrowdSec で fail2ban を置き換える

きっかけは侵入ではなく、うるささだった。

うちの nginx は netdata に繋いであり、異常があれば Discord に飛ぶ。こんな見た目で、その時点の Top IP と Top Path まで一緒に貼ってくれる。

診断情報は十分すぎるほど親切だ。問題はそれが一日に数百から数千回鳴ることで、しかもその大半は自分のサービスに何かあったわけではない。スキャナーが /wp-login.php や /.env、ありとあらゆる .php エンドポイントを叩いて出る 4xx である。うちのサイトに PHP など一つもないのだが、向こうはそれを知らないし、気にもしていない。ただ叩き続ける。

(上の一枚はむしろ数少ない「本当に何かあった」ときのもので、/api/spotify/audio-features が五分間で 9968 回叩かれている。あれは自分のコードがループしていた。IP は伏せた。あれはこちらの出口アドレスだからだ。)

当時このマシンにはすでに fail2ban が入っていて、数字も立派だった。

614 個も BAN したと聞けば役立っているように思える。だがその通知の列を眺めていて、一つ気づいた。相手はずっと IP を変えている。一つ潰しても、次は別の回線から来る。この調子で BAN し続けて、そもそも終わりはあるのだろうか。

この記事は、そのあと CrowdSec に乗り換えた一部始終である。なぜこの状況では fail2ban より向いているのか、構築で踏んだ三つの落とし穴、このマシンが六日間で実際に何を止めたのか、そして自分自身を三回締め出した話(三回目がいちばん間抜けで、いちばん書く価値がある)。最後は自作の Discord 解除 bot について。自分の防御に締め出されているとき、SSH こそまさに繋がらないものだからだ。

このマシンの構成#

あとに出てくる落とし穴も自己 BAN も構成に依存するので、先に環境をはっきりさせておく。

後半に効いてくる点をいくつか。

• すべて一台の物理マシンで動いている。自宅の固定回線に固定 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 を BAN する。

IP を回してくる相手に対して、これはモグラ叩きだ。新しい IP はどれもこちらにとって初対面で、ゼロから閾値まで積み上げないと BAN されない。そしてその頃には、もう一巡スキャンし終えている。

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

六日間で 1619 件#

これがこのマシンの直近六日間の実数である(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、Alibaba Cloud、Hetzner。スキャナーは時間課金の VM 上で動いている。一台潰したところで、別の一台を立ち上げるのは数秒の話で、しかも IP は変わる。

これが最初の疑問へのデータ側からの答えになる。IP を BAN する道では、相手のコストのほうがこちらよりはるかに安い。そしてまさにそこがコミュニティブロックリストの価値でもある。新しく立ち上がったその 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 全体を永久に BAN されないようにする。

# /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 で自分を出す#

三回に共通する厄介さはこれだ。BAN を解除するには、まず入れなければならない。そしてこちらが遮断されているとき、まさに繋がらないのが SSH である。

当時の代替手段はスマホだった。Termux で繋ぐ。普段はかなり気に入っていて、必要なものは一通り揃っている。だが外出先で、片手で、タッチキーボードで sudo cscli decisions delete --ip ... のようなコマンドを打ち、しかもその前に表全体から自分の IP を見分ける必要がある。体験としてはとても良いとは言えない。

さらに事態を面倒にすることがもう一つある。CrowdSec は誰を BAN したか既定では通知してくれない。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 だったら、こちらもきっと同じくらい長く気づかなかっただろう。乗り換えるなら綺麗に乗り換え、そして新しいほうが本当に動いていることを確認する。

一枚のチェックリスト#