AIを使った攻撃に備える、サーバーの基本対策4つ

なぜ基本対策を見直すのか

インターネットに公開されたサーバーには、自動のログイン試行や弱点探しが日常的に届きます。これは以前からあることですが、AIのような道具は、攻撃する側の調べものや準備を手助けすることにも使われ得ます。

どのような道具が使われる場合でも、次のような基本の弱点は狙われやすいところです。

• 更新されていないソフト
• パスワードで入れる管理用の入口
• 開けたままになっている不要な入口

サーバーの基本対策4つ

どの対策も、まず「確認」をして、できていない場合だけ「設定」をしてください。設定を変える前には、必ずバックアップを取ってください。

1. 対策 1SSHのパスワードログインとrootログインを止めるまず確認

   SSH（サーバーを遠隔で操作するための入口）にパスワードで入れる状態だと、推測による侵入を許すおそれがあります。鍵認証（手元のパソコンにある秘密の鍵ファイルで本人確認する方式）で入るようにし、パスワードでのログインと、管理者アカウント（root）での直接ログインを止めます。

   確認：実際に効いている設定を表示します。

   sudo sshd -T | grep -Ei '^(passwordauthentication|permitrootlogin|kbdinteractiveauthentication) '

   3つとも no なら、パスワード認証・キーボード対話認証・rootの直接ログインを無効にする設定になっています。鍵認証で入れることは、別の画面から新しく接続して確かめてください。

   設定する前の必須条件：root以外の管理用ユーザーで、鍵を使ってログインでき、sudo も使えることを確かめてください。これができないまま設定すると、締め出されます。

   設定の例：次の内容のファイルを作ります。

   # /etc/ssh/sshd_config.d/01-hardening.conf
   PasswordAuthentication no
   KbdInteractiveAuthentication no
   PermitRootLogin no

   書き間違いがないかを確認し、問題がなかった場合だけ設定を読み込み直します。

   sudo sshd -t && sudo systemctl reload ssh

   • Ubuntu 22.10 以降で使われている「ソケット起動」の環境では、ssh.socket が接続を待ち受け、ssh.service がまだ起動していない場合があります。今回の検証環境では、この状態で /run/sshd が無いために、確認や構文チェックのコマンドが Missing privilege separation directory: /run/sshd と表示して失敗しました。対処の例としては、systemctl status ssh で今の状態を記録し、意図して止めているのではないことを確かめてから、sudo systemctl start ssh で起動し、もう一度確認します。
   • SSHの設定は、原則として先に読み込まれた値が優先されます。ただし、Include の位置や Match（接続条件ごとの設定）も関係するため、ファイル名だけで優先されるとは限りません。/etc/ssh/sshd_config.d/ の別のファイル（例：クラウドの初期設定の 50-cloud-init.conf）に PasswordAuthentication yes が残っていないかも見て、必ず上の「確認」のコマンドで実際の値を確かめてください。
   • Match などの条件付きの設定がある場合は、sudo sshd -T -C user=ユーザー名,host=接続元,addr=接続元IP のように、接続条件ごとに確認してください。
   • 多要素認証などでキーボード対話認証を使っている環境では、この例をそのまま使わないでください。今の認証方式に合わせて設定を見直す必要があります。
   • 手元のパソコンの鍵ファイルは、パスフレーズ（鍵のパスワード）をつけて保管し、他人に渡さないでください。

2. 対策 2外から届く入口（ポート）を必要なものに絞る

   サーバーの中で動いているプログラムが、意図せず外から接続できる状態になっていることがあります。ファイアウォール（通してよい通信だけを通す仕組み）で、必要な入口だけを許可します。一般的なWebサーバーの構成例では、SSH（22番）とWeb（80番・443番）です。

   確認：ファイアウォールの状態と、接続を待ち受けているプログラムを表示します。

   sudo ufw status verbose       # 「Status: active」と、許可しているルールの一覧
   sudo ss -tlnp                 # TCPで待ち受けているプログラムの一覧
   sudo ss -ulnp                 # UDPで待ち受けているプログラムの一覧

   ss の一覧は「サーバーの中で待ち受けているもの」です。外から実際に届くかどうかは、ファイアウォールやVPS会社の設定によって変わります。0.0.0.0 や [::] で待ち受けているものは、外から届く可能性があるものとして確認してください。

   有効にする前に確認すること：

   • SSHが実際に待ち受けているポート番号（上の ss の結果で確認）。下の例は、SSHが標準の22番で動いている場合のものです。番号を変えている場合は、その番号を先に許可してください。
   • すでにあるルール（sudo ufw status numbered）。default deny incoming を設定しても、すでにある広い許可ルールは消えません。不要なルールは個別に削除します。
   • ほかに必要なサービスと、IPv6 の扱い（/etc/default/ufw の IPV6 の設定）。

   設定の例（SSHが22番の場合）：SSHを許可してから有効にします（順番を逆にすると締め出されます）。

   sudo ufw default deny incoming
   sudo ufw default allow outgoing
   sudo ufw allow 22/tcp
   sudo ufw allow 80,443/tcp
   sudo ufw enable

   • Webアプリは 127.0.0.1（サーバーの内側だけ）で待ち受けるように設定し、外への公開は Webサーバー（Caddy・Nginx など）を中継させて行います。
   • データベースは、原則として外に公開しません。必要なアプリからの内側の接続だけに限ってください。
   • Docker でポートを公開すると、ufw の設定を通らずに外から届く場合があります。Docker を使っている場合は、公開の設定（-p 127.0.0.1:8080:80 のように内側に限定するなど）も確認してください。
   • VPS会社の管理画面に「パケットフィルター」などの機能がある場合は、そちらでも入口を絞ると二重の守りになります。

3. 対策 3セキュリティ更新を自動にし、反映まで確かめる

   手作業の更新だけに頼らず、OSのセキュリティ更新が自動で入るようにします。ただし、「自動更新の仕組みが動いていること」と「更新が予定どおり成功していること」は別です。両方を確かめます。

   確認：

   # 1. 自動更新を動かすタイマー（定期実行）が予定どおり動いているか
   systemctl list-timers --all apt-daily.timer apt-daily-upgrade.timer
   
   # 2. 実際に効いている自動更新の設定（実行の間隔・更新の対象）
   apt-config dump | grep -E 'APT::Periodic|Unattended-Upgrade::'
   
   # 3. 最近の実行記録（エラーが出ていないか）
   sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
   
   # 4. 更新を実際には適用しない「試し実行」
   sudo unattended-upgrade --dry-run --debug

   4つめは、更新を適用せずに、どの更新が対象になるかを表示する確認です。表示されるエラーや、対象になっている配布元（リポジトリ）の設定も読んでください。

   設定の例：

   sudo apt install unattended-upgrades
   sudo dpkg-reconfigure -plow unattended-upgrades   # 「はい」を選ぶ

   見落としやすい点：更新が「入った」だけでは効いていないことがあります

   • カーネル（OSの中心部分）の更新は、サーバーを再起動するまで古いものが動き続けます。長いあいだ再起動していないサーバーでは、修正が効いていないことがあります。
   • 基本ライブラリなどの更新は、それを使っているサービスを再起動すれば反映できる場合もあります。どれを再起動すべきかは、needrestart などの道具で確かめられます。
   • /var/run/reboot-required というファイルがあれば再起動が必要な目安になります。ただし、このファイルが無いことだけで「再起動は不要」とは言い切れません。
   • /boot に新しいカーネルが入っていても、次の起動で必ずそれに切り替わるとは限りません。再起動したあとに uname -r で、実際に動いているカーネルを確かめてください。
   • コンテナ（Dockerなど）の中のOSを更新しても、サーバー本体のカーネルは更新されません。両者は分けて管理します。

   ls /var/run/reboot-required 2>/dev/null && echo "再起動が必要です"
   uname -r                      # 今動いているカーネル

   再起動は、利用者の少ない時間に計画して行ってください。再起動のあと、Webサイトやアプリが自動で起動し直すことも確かめておきます。

   • 自動更新の対象は、主にOSに含まれるソフトです。別に入れたPHP・Node.jsのパッケージ・WordPressのプラグインなどは対象外のことが多いため、それぞれ別に更新を確認してください（PHPの重大な脆弱性の解説も参考にしてください）。

4. 対策 4ログイン失敗を繰り返す接続元を一定時間遮断する

   fail2ban（ふぇいるつーばん：ログの記録を見て、設定した条件に合う接続元を一定時間ブロックするソフト）を使うと、短い時間にログイン失敗を繰り返す接続元を自動で遮断できます。

   確認：

   systemctl is-active fail2ban                     # active なら動いている
   sudo fail2ban-client status sshd                 # SSHの見張りと、いまブロックしている数

   設定の例：すでにある jail.local を上書きしないよう、別のファイルとして作ります。

   sudo apt install fail2ban

   # /etc/fail2ban/jail.d/sshd.local
   [sshd]
   enabled = true
   # 10分以内に5回失敗すると、1時間遮断
   maxretry = 5
   findtime = 10m
   bantime = 1h

   fail2ban の設定ファイルでは、値の後ろに # でメモを書くことはできません。メモは上の例のように別の行に書いてください。

   設定の確認が成功した場合だけ、再起動して状態を見ます。

   sudo fail2ban-client -t
   # 確認が成功した場合だけ実行
   sudo systemctl restart fail2ban
   sudo fail2ban-client status sshd
   
   # 実際に使われている値を確認
   sudo fail2ban-client get sshd maxretry
   sudo fail2ban-client get sshd findtime
   sudo fail2ban-client get sshd bantime

   • fail2ban-client -t は、値の書き方が間違っていても「OK」と表示することがあります（その場合は WARNING Wrong value for 'maxretry' のように、既定の値に置き換えたことが表示されます）。WARNING が出ていないかを読み、実際の値を上の get のコマンドで確かめてください。
   • 遮断の試験は、自分が管理する検証用の環境で行ってください。復旧用のコンソールと解除の方法（sudo fail2ban-client set sshd unbanip 接続元IP）を確保し、唯一の管理用の接続元や、ほかの利用者と共有している接続元IPでは試さないでください。
   • 遮断されるかを試すときは、別の機械から試してください。サーバー自身からの接続は、自分を遮断しないための設定（ignoreself、既定で有効）により対象外になります。
   • ログを journal（systemd の記録）だけに残している環境では、backend = systemd などの設定や、必要なパッケージの確認が要ることがあります。一律に追加せず、お使いの環境のログの残し方に合わせてください。
   • SSHのポート番号を変えている場合は、fail2ban 側のポート設定も合わせてください。
   • fail2ban は補助の守りです。多数の接続元から少しずつ行われる試行などは止めきれません。主役は対策1の設定です。
   • 会社の固定IPなど、自分の接続元がブロックされないように ignoreip に登録しておくこともできます。

4つの対策とあわせて行いたいこと

• 管理画面の二段階認証：VPS会社・ドメイン管理・決済サービス・ソースコード管理（GitHubなど）の管理画面には、二段階認証を設定します。
• 偽メールへの注意：管理画面には、メールのリンクからではなく、ブックマークや公式アプリから入るようにします。
• アプリケーションの更新と点検：WordPress・PHP・Node.js のパッケージなど、OS以外のソフトも更新し、入力のチェックなど作りの面の弱点も点検します。
• 使っていないサービスは止める：動いているだけで攻撃の入口になります。古い試作のアプリや管理ツールは停止・削除します。
• 秘密の情報を表に出さない：APIキーやパスワードは、ソースコードや公開フォルダに置かず、漏れたときにすぐ作り直せるようにしておきます。
• バックアップと復元の練習：サーバーの外にもバックアップを置き、実際に戻せるかを確かめておきます。
• 記録（ログ）を見る習慣：アクセス記録やログインの記録を定期的に見て、「いつもと違う」に早く気づけるようにします。

参考にした公式情報

設定方法の詳細や最新の情報は、各公式の資料でご確認ください（2026年10月26日に確認）。

• OpenSSH：sshd_config マニュアルPasswordAuthentication・PermitRootLogin・Include・Match などの設定・英語
• OpenSSH：sshd マニュアル-t（構文確認）・-T／-C（実際の設定の表示）・英語
• Ubuntu Server ドキュメント：Firewalls（ufw）英語
• Ubuntu コミュニティヘルプ：UFW英語
• Docker Docs：Packet filtering and firewallsDocker の公開ポートと ufw の関係・英語
• Ubuntu Server ドキュメント：Automatic updatesunattended-upgrades とタイマーの設定・英語
• Debian Wiki：UnattendedUpgrades英語
• fail2ban 公式リポジトリ設定ファイルの書き方（jail.conf の説明）・英語
• IPA：中小企業の情報セキュリティ対策ガイドライン日本語

更新履歴

• 2026年10月26日　公開

このページは一般的な情報提供を目的としています。個別のシステムの安全性を保証するものではありません。設定の変更は、ご自分の環境に合わせて、バックアップを取ったうえで行ってください。対応についてお困りの場合は、ご利用のサーバー会社・制作会社、または専門家にご相談ください。