# instinct: fail2banはactiveでも設定が緩いとスロー攻撃が素通りする

## 事象 (2026-06-10・Issue vvv-bots#333)

shadow は fail2ban が active なのに、48時間で SSH 攻撃 1,036 件に対し BAN がたった 2 件だった。

## 根本原因

`maxretry=5 / findtime=600 / bantime=3600` という緩い設定。現代のSSHブルートフォースは**多数IPに分散したスロー攻撃**（トップ攻撃元でも 85件/48h ≈ 1.8件/h）のため、「10分以内に5回」の閾値にほぼ届かず BAN が発動しない。「fail2ban が動いている=守られている」は誤り。**banカウンタと実際の攻撃ログ流量を突き合わせて初めて機能不全が見える**（1036 vs 2 の乖離が証拠）。

## 対処（2段構え）

1. **本命: 攻撃面の削減** — SSH 22/tcp を ufw で Tailscale 限定化（`ufw insert 1 allow from 100.64.0.0/10 to any port 22 proto tcp` → `ufw delete allow 22/tcp` の順序厳守でロックアウト防止）。適用後5分で攻撃 0 件。
2. **保険: fail2ban強化** — `/etc/fail2ban/jail.d/99-sshd-hardening.local` に `maxretry=3 / findtime=3600 / bantime=86400 / bantime.increment=true / bantime.factor=2 / bantime.maxtime=604800`。jail.d/*.local は jail.local より後に読まれるので確実に上書きできる。

## 再利用チェックリスト（新ホスト堅牢化時）

- [ ] 正規ログインが全て Tailscale 経由か確認（`journalctl -u ssh | grep Accepted` で非100.x送信元ゼロ）→ ゼロなら22のTailscale限定化は安全
- [ ] ufw は「許可追加 → 開放削除」の順序
- [ ] PermitRootLogin no（事前に root Accepted 14日ゼロ + root@利用スクリプトなしを裏取り）
- [ ] sshd変更は `sshd -t` → `systemctl reload ssh`（restartでなくreloadなら既存セッション維持）
- [ ] 効果検証: 変更後の攻撃流量カウント + 正規経路のsshdバナー到達確認（cure→shadowで `nc 100.x 22`）

## 関連
- Issue vvv-bots#333 (実施記録) / #248 / #511
- multi-host-deploy.md（5ホスト構成）