2026年8月から9月にかけて、SSHへの総当たり攻撃（ブルートフォース攻撃）の報告が各所で相次いでいます。IPAの「情報セキュリティ10大脅威 2026」でも「インターネット上のサービスへの不正ログイン」が個人向け脅威の常連として挙げられており、自宅サーバーや検証用VPSでもSSHのポートは常に狙われていると考えたほうがよい状況です。この記事では、fail2banのような自動遮断ツールを入れているかどうかに関わらず、journalctlとssだけで「自分のサーバーが今この瞬間、総当たり攻撃を受けているか」をその場で判定し、ufwまたはiptablesで即座に遮断する手順をまとめます。Ubuntu/Debian環境を前提にし、コマンドはそのままコピーして使えます。

なぜ「今まさに継続中かどうか」を見分ける必要があるのか

ログを後からまとめて眺めるだけでは、攻撃はとっくに終わっているか、逆に今この瞬間も継続中で放置している間に試行回数が積み上がっている、のどちらかです。対処のタイミングを分けて考える必要があります。

  • 過去のログ：統計として把握し、次の対策（鍵認証への切り替えなど）の判断材料にする
  • 今まさに継続中の試行：発見したその場で遮断する。放置すると回線・CPU負荷が上がり続け、まれに認証まわりの処理に負荷がかかる原因にもなる

Debian 13（trixie）ではOpenSSHが9.2p1から10.0p1に上がり、古い暗号アルゴリズムの削除が進んでいます。この影響で、古いSSHクライアントからの正規の接続が「認証失敗」としてログに残ることがあります。ログの見分け方を知らないと、これを総当たり攻撃と誤認したり、逆に本物の攻撃を見逃したりするので、まず「何が正常で何が異常か」を実際の出力で確認できるようにしておくことが重要です。

journalctlで「今まさに続いている」ログイン試行を見抜く

直近の失敗ログをまとめて見る

まず、直近数分の認証失敗ログを一覧します。sudoが必要ですが、設定変更は一切行わないコマンドなので安全に試せます。

sudo journalctl -u ssh --since "10 min ago" | grep "Failed password"

Ubuntu/Debianではsshサービスのユニット名は通常sshです（他のディストリではsshdになっていることが多いので、上記で何も出ない場合はsystemctl status sshとsystemctl status sshdの両方を試して実際のユニット名を確認してください）。

出力例

Sep 03 08:45:12 myserver sshd[12345]: Failed password for invalid user admin from 203.0.113.45 port 51234 ssh2
Sep 03 08:45:13 myserver sshd[12345]: Failed password for invalid user admin from 203.0.113.45 port 51244 ssh2
Sep 03 08:45:15 myserver sshd[12345]: Failed password for root from 203.0.113.45 port 51260 ssh2

判断のポイント：同一のIPアドレスから、数秒おきに、しかもadminやrootのような実在しないユーザー・管理者アカウントで失敗が連続していれば、人間の操作ミスではなく自動化された総当たりツールの可能性が高いです。逆に、自分の作業中の端末のIPから1〜2回だけ失敗している場合は、単なるパスワードの打ち間違いです。

IPごとの失敗回数を集計して規模を数値で確認する

体感ではなく数字で判断するために、直近5分間の失敗回数をIPごとに集計します。

sudo journalctl -u ssh --since "5 min ago" | grep "Failed password" | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn

出力例

     48 from 203.0.113.45
      2 from 198.51.100.9
      1 from 192.0.2.10

判断のポイント：5分間で1つのIPから数十件を超える失敗が出ていれば、ほぼ確実に自動化された総当たり攻撃です（目安として1分あたり2〜3回を超えて機械的な間隔で続いていれば要注意）。2〜3件程度は、正規ユーザーの入力ミスやOpenSSH 10.0p1へのバージョンアップに伴う古いクライアントの接続失敗である可能性があるため、慌てて遮断する必要はありません。

今この瞬間の試行をリアルタイムで監視する

集計で「継続中」と判断したら、リアルタイムに動きを追います。Ctrl+Cでいつでも止められる、システムに影響のないコマンドです。

sudo journalctl -u ssh -f | grep --line-buffered "Failed password"

数秒おきに同じIPからの失敗が流れ続けていれば、その瞬間も攻撃が進行中ということです。

ssコマンドで「今つながっている」接続元を照合する

journalctlはログイン試行の記録ですが、ssを使うと今この瞬間に張られているTCP接続そのものを見られます。両方を突き合わせることで誤認を減らせます。

sudo ss -tn sport = :22

出力例

State    Recv-Q  Send-Q  Local Address:Port    Peer Address:Port
ESTAB    0       0       10.0.0.5:22           203.0.113.45:51290
ESTAB    0       0       10.0.0.5:22           203.0.113.45:51301
ESTAB    0       0       10.0.0.5:22           198.51.100.9:44012

判断のポイント：同じPeer Address（接続元IP）から短時間に何本もの接続が張られては切れてを繰り返している場合、総当たりツールが次々に接続を試している状態です。journalctlの失敗ログと同じIPが出ていれば、その場で遮断対象と確定できます。1つのIPから1〜2本だけで、自分が今作業しているIPと一致する場合は正常な接続です。

通信先の点検をさらに広げてポート単位で確認したい場合は、ss -tulpnとlsof -iで通信先点検2026年9月版も参考にしてください。

継続中と確定したら即座に遮断する（ufw / iptables）

「特定のIPから継続中」と確定したら、その場で遮断します。どちらの方法もsudoが必要で、元に戻す方法があります。

ufwを使う場合（Ubuntuでシンプルに管理したい人向け）

sudo ufw deny from 203.0.113.45 to any port 22
sudo ufw status numbered

統計と同じIP（この例では203.0.113.45）が「DENY」として一覧に出ていれば遮断成功です。元に戻す場合は番号を確認して削除します。

sudo ufw delete deny from 203.0.113.45 to any port 22

iptablesを使う場合（Dockerを使っている・より細かく制御したい人向け）

Dockerを使う環境ではufwのルールがDockerのNAT処理と競合することがあるため、iptablesで直接ブロックするほうが確実な場合があります。

sudo iptables -A INPUT -s 203.0.113.45 -j DROP
sudo iptables -L INPUT -n --line-numbers

一覧にDROPルールが追加されていれば成功です。元に戻すには同じ条件で-D（delete）を使います。

sudo iptables -D INPUT -s 203.0.113.45 -j DROP

注意：iptablesのルールはデフォルトでは再起動すると消えます（永続化するにはiptables-persistentパッケージなどが別途必要）。今回のような「今この瞬間の攻撃を止める」応急処置としてはこの一時的な性質がむしろ都合がよく、間違えて必要な相手を遮断してしまっても再起動すれば元に戻る、という保険にもなります。恒久的に特定IPを拒否したい場合のみ永続化を検討してください。

ufwとiptables、どちらを使うべきか

状況

推奨

理由

Ubuntuでシンプルに1台管理

ufw

コマンドが直感的で状態確認もしやすい

Dockerを使っている

iptables

ufwのルールがDockerのNAT処理より後に評価され効かないことがある

Debian系で最小構成

iptables

ufwが未インストールなことが多い

なお、近年のLinuxディストリビューションではnftablesが後継のファイアウォール機構として標準になりつつありますが、Ubuntu/Debianの一般的な運用ではufw・iptablesの構文が今も現役です。今回のような単発IPの即時遮断であれば、無理にnftablesへ切り替える必要はありません。

遮断した後にやること・再発防止の次の一手

  • 遮断が効いているか再確認する：数分後にもう一度journalctl -u ssh --since "5 min ago" | grep "Failed password"を実行し、同じIPからの失敗が止まっているかを見ます
  • 単発の遮断で終わらせない：総当たり攻撃は別のIPから再開されることが多いです。頻発するなら、IPを都度手動で遮断するよりfail2ban（一定回数失敗したIPを自動でBanする定番ツール）の導入を検討したほうが手間が減ります
  • そもそも狙われにくくする：パスワード認証を無効化してSSH鍵認証のみにする、または22番以外のポートに変更するだけでも、無差別スキャン由来の試行の大部分は減らせます
  • アカウント自体を点検する：総当たりが成功していないかの最終確認として、身に覚えのないアカウントが作られていないかも見ておくと安心です。詳しくは/etc/passwd点検2026年8月版｜不審アカウント発見法を参照してください

これらは設定ファイルの変更を伴うため、今回の「その場で遮断する」応急処置とは切り分けて、余裕のあるタイミングで進めるのがおすすめです。

関連する選択肢

自動化や検証を常時動かすなら、使っていないPCを1台あてる方法もあります。新品である必要はなく、長く動かすので保証の有無の方が効いてきます。

長期保証付きで常時400種4000台の中古PCを販売【PC WRAP】

※ 広告を含みます（A8.net）。リンク経由でお申し込みがあった場合、手数料を受け取ることがあります。

まとめ

SSHへの総当たり攻撃は、journalctlで「同一IPからの機械的な連続失敗」を数字で確認し、ssで「今も接続が繰り返されているか」を照合すれば、fail2banなどの自動化ツールがなくてもその場で判定できます。継続中と分かったら、ufwまたはiptablesで該当IPを遮断すれば十分です。iptablesの遮断は再起動で消える一時的な処置なので、間違えても取り返しがつきます。まずは今回の集計コマンドを実行し、自分のサーバーの今の状態を数字で確認するところから始めてみてください。