UFWでファイアウォールを設定する【iptablesからの移行】

※本ページには広告（アフィリエイトプログラム等）が含まれます。

※本ページには広告（アフィリエイトプログラム等）が含まれます。数値は 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 日間の集計

集計はこのコマンドで出せます。自分のサーバーでも 1 回叩いてみてください。

$ journalctl --since "-7d" --no-pager -o cat \
  | grep -ci "authentication failure\|Invalid user"
3519

SSH 以外のポートも探索される

エラーログのパターンを集計すると、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 を分散させる

1 つの IP あたりの頻度が閾値を下回っていれば、limit は素通しします。7 日で 3,519 件という数字は、まさにこの形で積み上がったものです。

本命はパスワード認証の無効化

遮断を積むより先にやるべきはこちらです。鍵認証のみにすれば、パスワードの総当たりは何回来ても全部失敗します。

# /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password
MaxAuthTries 3

設定を書き換えたら、いまの接続を切らずに別のターミナルでログインできることを確認してください。ここでも締め出し事故が起きます。

常駐の遮断ツールを足すかどうか

メモリで選ぶ

鍵認証のみにしていれば防御力はすでに足りています。それでも遮断ツールを入れる理由は、ログと接続のノイズを減らすことです。だとすれば、常駐コストが判断材料になります。

手元の環境では 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 のユニットファイルにまとめています。