※本ページには広告（アフィリエイトプログラム等）が含まれます。
※本ページには広告（アフィリエイトプログラム等）が含まれます。数値は 2026年8月16日時点で運用中の VPS（Debian 12・メモリ 958MB）から採取した実測値です。攻撃元の IP は伏せています。
🎯 結論：既定は全部拒否。SSH は 7 日で 3,519 件叩かれていた
結論から書きます。UFW の設定自体は数行で終わります。本題は「どれだけ叩かれているか」を知ったうえで、遮断を積むかどうかです。
手元の VPS で直近 7 日間のログを集計したところ、認証失敗と不正ユーザーの試行が 3,519 件ありました。1 日あたり約 503 件、1 時間あたり約 21 件です。何も公開していないサーバーでもこの数字が出ます。
- ✅ 既定は全部拒否 →
default deny incomingから始める - ✅ 有効化の前に SSH を許可 → 順番を間違えると自分が締め出される
- ⚠️ ufw の
limitは分散攻撃に無力 → 同一 IP しか見ていない - ✅ 鍵認証のみにする → パスワードを無効化すれば試行は全部失敗する
- 🔑 常駐の遮断ツールは軽いものを → 実測で 3.2MB（メモリ 958MB の箱では重要）
実測：どれだけ叩かれているか
7 日間の集計
| 項目 | 7 日間 | 1 日あたり |
|---|---|---|
| 認証失敗・不正ユーザーの試行 | 3,519 件 | 約 503 件 |
| 鍵交換前に切断された接続 | 139 件 | 約 20 件 |
| 遮断ツールがブロックした回数 | 45 回 | 約 6 回 |
集計はこのコマンドで出せます。自分のサーバーでも 1 回叩いてみてください。
$ journalctl --since "-7d" --no-pager -o cat \
| grep -ci "authentication failure\|Invalid user"
3519SSH 以外のポートも探索される
エラーログのパターンを集計すると、SSH ポートに向けてまったく別のプロトコルを投げてくる試行が見つかります。
error: kex_exchange_identification: client sent invalid protocol identifier "GET / HTTP/1.0"
error: kex_exchange_identification: client sent invalid protocol identifier "\026\003\001\001"前者は HTTP、後者は TLS のハンドシェイク（0x16 0x03 0x01）です。ポート番号を変えていても、片っ端から総当たりされていることが分かります。「非標準ポートにしたから安全」は成り立ちません。
だから既定は拒否から始める
この状況で「必要なものだけ塞ぐ」という発想は無理があります。全部拒否してから、必要なものだけ開けるのが唯一まわる運用です。
UFW の基本
既定ポリシーを決める
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing入ってくる通信は全部拒否、出ていく通信は許可。これが出発点です。
⛔ 有効化の順番を間違えない
いちばん多い事故がこれです。SSH を許可する前に有効化すると、その瞬間に自分が締め出されます。
# 1. 先に SSH を許可する（ポートを変更しているなら実際の番号で）
$ sudo ufw allow 22/tcp
# 2. それから有効化
$ sudo ufw enable⚠️ コンソール（VNC など）から入れる手段を確保してから作業してください。SSH しか経路が無い状態でこの順番を間違えると、復旧手段がなくなります。
状態を確認する
$ sudo ufw status verbose
$ sudo ufw status numbered # 番号付き（削除に使う）
$ sudo ufw delete 3 # 番号で削除⚠️ ufw の limit は分散攻撃に効かない
limit が見ているもの
UFW には接続数を制限する limit があります。
$ sudo ufw limit 22/tcpただし、これが見ているのは同一 IP からの 30 秒間に 6 接続までという条件だけです。
攻撃側は IP を分散させる
| 攻撃の形 | limit の効果 |
|---|---|
| 1 つの IP から高速に連打 | 効く |
| 多数の IP から低速に分散 | ⛔ 効かない |
1 つの IP あたりの頻度が閾値を下回っていれば、limit は素通しします。7 日で 3,519 件という数字は、まさにこの形で積み上がったものです。
本命はパスワード認証の無効化
遮断を積むより先にやるべきはこちらです。鍵認証のみにすれば、パスワードの総当たりは何回来ても全部失敗します。
# /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
MaxAuthTries 3⚠️ 設定を書き換えたら、いまの接続を切らずに別のターミナルでログインできることを確認してください。ここでも締め出し事故が起きます。
常駐の遮断ツールを足すかどうか
メモリで選ぶ
鍵認証のみにしていれば防御力はすでに足りています。それでも遮断ツールを入れる理由はログと接続のノイズを減らすことです。だとすれば、常駐コストが判断材料になります。
| ツール | 常駐メモリ | 958MB の箱での判断 |
|---|---|---|
| sshguard（C 実装） | 実測 3.2MB | ✅ 十分軽い |
| fail2ban（Python 常駐） | 一般に数十 MB | ⚠️ 防御力は変わらないのに重い |
手元の環境では sshguard を採用しています。実測で 3.2MB、7 日間で 45 回の遮断が記録されていました。
nftables と衝突させない
遮断ツールは自分でファイアウォールのルールを書き換えます。UFW と別々にルールを触ると衝突するので、バックエンドを合わせてください。sshguard なら nftables のセットを使う設定にすれば、UFW と競合しません。
入れても防御力は上がらない
⚠️ ここは誤解しないでください。鍵認証のみにした時点で、パスワード総当たりは全部失敗しています。遮断ツールが減らすのはログの量とプロセスの生成回数であって、突破されるリスクではありません。
ログを有効にする
UFW のログ
$ sudo ufw logging on
$ sudo ufw logging medium # off / low / medium / high / full拒否したパケットが記録されます。full は本当にログが溢れるので、常用するなら low か medium にしてください。
ログが増えすぎないように
手元の環境では journal が 503.5MB を占めていました。ログを増やす設定を入れるなら、SystemMaxUse の上限とセットで考えてください。
読み方
ログの量が増えると、今度は「何を見ればいいか」が問題になります。集計してノイズを落とす手順はAI を使ったログの切り分けにまとめています。
よくある質問
Q1. 何も公開していないサーバーでも攻撃されますか？
結論：されます。手元の VPS では直近 7 日間で認証失敗・不正ユーザーの試行が 3,519 件（1 日約 503 件）記録されていました。IP アドレスが割り当てられた時点で探索の対象になります。
Q2. SSH のポートを変えれば安全ですか？
結論：それだけでは不十分です。ポートを変更した環境でも、SSH ポートに HTTP リクエストや TLS ハンドシェイクを投げてくる試行が記録されています。片っ端から総当たりされているためで、ポート変更はノイズを減らす効果しかありません。
Q3. ufw の limit を入れれば十分ですか？
結論：不十分です。limit は同一 IP からの 30 秒 / 6 接続しか見ていません。多数の IP から低速に分散してくる攻撃には素通しになります。本命はパスワード認証の無効化です。
Q4. fail2ban と sshguard はどちらがいいですか？
結論：メモリの少ない VPS では sshguard です。手元の環境では実測 3.2MB で常駐し、7 日間に 45 回の遮断を記録していました。fail2ban は Python 常駐のぶん重く、鍵認証のみにしていれば防御力に差はありません。
Q5. ufw を有効にしたら SSH が切れました
結論：有効化の前に SSH の許可を入れていなかったためです。sudo ufw allow 22/tcp（ポート変更済みならその番号）を先に実行してから enable してください。作業前にコンソール経由の復旧手段を確保しておくのが確実です。
Q6. ログはどの水準にすべきですか？
結論：low か medium です。full はログが溢れます。手元の環境では journal がすでに 503.5MB を占めていたので、SystemMaxUse の上限設定とセットで考えてください。
まとめ
UFW の設定は数行で終わります。難しいのは設定ではなく、どこまで積むかの判断です。実測を見れば優先順位ははっきりします。
- 🎯 まず → 既定拒否 ＋ SSH 許可 → 有効化（この順番）
- 🎯 次に → パスワード認証を無効化（これで総当たりは全部失敗する）
- 🎯 最後に → 軽い遮断ツールでノイズを減らす（3.2MB の実績）
数値は 2026年8月16日時点で運用中の VPS から採取したものです。初期設定の全体像はさくらの VPS の初期セットアップ、ログの読み方はAI を使ったログの切り分け、常駐サービスの管理はsystemd のユニットファイルにまとめています。