Linuxサーバーのセキュリティ強化｜Ubuntuで確認する更新・SSH・公開ポート

Linuxサーバーは、サポート中のOSと更新、SSHの認証、外部へ開くポートから見直します。Ubuntuの例で、現在の管理接続とコンソール復旧経路を確保してから、一項目ずつ変更する手順を示します。ほかのディストリビューションではサービス名や設定場所を確認してください。

セキュリティ強化の主要アプローチ比較

サーバーの運用スタイルに合わせて、以下の更新管理手法を検討してください。

実行前の確認事項

設定変更による接続不能を防ぐため、作業前に以下の状態を確認してください。

1. 現在のOS情報の確認: lsb_release -a 等で、使用しているUbuntuのバージョンとサポート状況を確認します。
2. 現在のネットワーク状態: ss -lntup を使用して、現在どのプロセスがどのポートで待機しているか（IPv4/IPv6両方）を確認します。
3. 既存のファイアウォール設定: ufw status で現在のルールを確認します。
4. クラウド側の設定: クラウド環境を利用している場合、OS内部のファイアウォールだけでなく、クラウド側のセキュリティグループの設定も確認してください。
5. バックアップの準備: 重要なデータは、Kopiaによるバックアップと復元 を参考に、適切な手順でバックアップを取得しておいてください。

ソフトウェアの更新管理

脆弱性を防ぐための第一歩は、OSとパッケージを最新の状態に保つことです。

unattended-upgradesの活用

Ubuntuでは unattended-upgrades を使用して、セキュリティアップデートを自動的に適用できます。

• 適用状況の確認: ログを確認し、正しく更新が行われているか、また更新後に再起動が必要な状態になっていないかを確認してください。
• 再起動の扱い: 自動更新によってシステムが勝手に再起動される設定は、サービスの可用性に影響を与えるため、運用ルールに基づいた慎重な判断が必要です。

出典：Ubuntu公式ガイドの自動更新。有効な更新元、実行ログ、再起動設定を確認します。自動更新を有効にしただけで、すべてのソフトウェアやコンテナが更新されるとは限りません。

SSH（OpenSSH Server）のセキュリティ強化

SSHは外部からサーバーにアクセスするための主要な経路であるため、最も厳格な設定が求められます。詳細は Ubuntu公式ドキュメント を参照してください。

認証方式の変更

パスワード認証による攻撃を防ぐため、公開鍵認証への移行を推奨します。

1. 公開鍵認証のテスト: 新しい鍵を用いて、現在のセッションとは別の新しいセッションでログインができることを必ず確認してください。
2. パスワード認証の制限: 鍵認証でのログインが確認できたら、root ユーザーでの直接ログインやパスワード認証を制限します。

設定ファイルの検証と適用

設定変更を行う際は、以下の手順でエラーを防ぎます。

1. 構文チェック: 設定ファイルを編集した後、sshd -t を実行して構文に誤りがないか確認します。
2. 有効な設定値の確認: sshd -T を使用して、現在の設定ファイル（Include ディレクティブによる読み込みを含む）によって最終的にどのような設定値が適用されるかを確認します。
3. セッションの保持: 設定を反映（reload）させる際は、現在の管理用セッションを絶対に閉じないでください。万が一、新しい設定でログインできなくなった場合に備え、コンソールからの復旧手段を確保しておく必要があります。

ネットワークとファイアウォールの管理

不要なポートを閉じ、攻撃対象領域（アタックサーフェス）を最小化します。

公開ポートの確認と制限

ss -lntup を使用して、意図しないサービスが外部に公開されていないか確認します。特に、データベース（Public DB）や管理用ポート（Admin port）が外部からアクセス可能な状態になっていないか、外部のネットワークから確認を行うことが重要です。

UFWとDockerの注意点

Ubuntuの標準的なファイアウォールとして ufw がありますが、Dockerを使用している場合は注意が必要です。

• Dockerの挙動: Dockerで published ports（-p オプションなど）を使用すると、Dockerが直接 iptables を操作するため、UFWのルールを迂回してポートが公開される可能性があります。
• 多層防御: UFWだけで完全に閉じていると断言せず、クラウドのセキュリティグループやコンテナのネットワーク設定と併せて管理してください。

出典：Ubuntu公式ガイドのファイアウォールとDocker公式ガイドのパケットフィルタリング。クラウド側で許可されていても、OS側の正しい拒否を単独で上書きするわけではありません。経路全体とDockerの公開方法を確認します。

監視とログの確認

セキュリティイベントを検知するために、ログの確認を習慣化します。

• 認証失敗の確認: sudo journalctl -u ssh --since "1 hour ago" を使用して、認証に失敗したログを確認し、不審なアクセスがないか監視します。
• 補助的なツール: fail2ban は、攻撃の試行を検知して一時的に遮断する補助的なツールとして有効です。ただし、これはSSH鍵認証の代わりにはなりません。
• システムの整合性: AppArmorなどのセキュリティモジュールは、無効化せず維持するようにしてください。また、時刻同期（time sync）が正確に行われていることを確認してください。これはログの正確な記録に不可欠です。

読み取り専用の確認から始める

編集部では、停止の危険がある設定を一括投入する前に、次の確認結果を記録することを勧めます。これらは状態を見る例で、ポートや認証設定を変更しません。必要な権限と、対象OSのコマンドを確認してください。

cat /etc/os-release
sudo ss -lntup
sudo ufw status verbose
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T
sudo journalctl -u ssh --since "1 hour ago"

sshd -Tは基本設定の確認です。Match条件がある場合は接続条件に応じた有効値も確認します。ログには利用者名やIPアドレスが含まれるため、共有前に必要な範囲へ絞ってください。

編集部では、変更後も今のセッションを残し、別の接続と外部ネットワークから実際に確認してから作業を終えることを勧めます。ログイン不能なら新しい変更を止め、コンソールから元の設定へ戻します。

セキュリティ強化の実践におけるベストプラクティス

設定変更を行う際は、以下の原則を守ることでリスクを最小限に抑えられます。

• 小さな変更の積み重ね: 一括で適用する巨大なスクリプトを作成して実行するよりも、一つずつ設定を変更し、その都度動作を確認する方が安全です。
• ロールバック手順の記録: 設定を変更する際は、元の状態に戻すための手順（rollback）を必ず記録しておいてください。
• 機密情報の管理: 秘密鍵やパスワードなどの機密情報を、誤ってGitなどのバージョン管理システムにコミットしないよう、厳重に管理してください。

ネットワーク構成の設計については、VLANによるIoT分離 や 自宅ネットワーク構成図 を参考にしてください。

よくある失敗とトラブルシューティング

設定変更後にログインできなくなった

• 原因: SSHの設定ミス、またはファイアウォールによる拒否。
• 対策: コンソール（物理コンソールまたはクラウドのシリアルコンソール）からログインし、設定を元に戻すか、sshd -t でエラー箇所を特定してください。

UFWでポートを閉じたのにアクセスできてしまう

• 原因: Dockerがiptablesを直接操作している、別のインターフェースやIPv6の制限が漏れている。
• 対策: ss -lntup でプロセスを確認し、Dockerを使用している場合はコンテナ側のネットワーク設定を確認してください。

FAQ

Q1: fail2banだけでSSHの認証対策は十分ですか？

A1: いいえ。fail2banは攻撃を検知して遮断する「補助」的なツールです。セキュリティの根幹となる認証の強化（公開鍵認証への移行）を優先してください。

Q2: sshd -t と sshd -T の違いは何ですか？

A2: sshd -t は設定ファイルの構文（シンタックス）が正しいかを確認するコマンドです。一方、sshd -T は、設定ファイルや Include で読み込まれた設定が最終的にどのような値として適用されるか（有効な設定値）を表示するコマンドです。

Q3: Dockerを使っている場合、UFWの設定だけでセキュリティは十分ですか？

A3: 不十分な場合があります。DockerはUFWのルールをバイパスしてポートを公開することがあるため、クラウドのセキュリティグループやコンテナ自体の設定も併せて確認する必要があります。

Q4: セキュリティ強化の設定は、一括で自動化スクリプトにして実行するのが効率的ですか？

A4: 効率的ではありますが、リスクが高いです。一括で変更すると、どこで問題が発生したかの切り分けが困難になります。小さな変更を一つずつ行い、動作確認とロールバック手順の準備を行うことが推奨されます。

Q5: 設定変更中にSSH接続が切れたらどうすればいいですか？

A5: 設定変更を行う際は、必ず現在のセッションを維持したまま、別の新しいセッションで接続テストを行ってください。万が一の際は、コンソールアクセスによる復旧が必要です。