SSHサーバーを強化するための10の重要なベストプラクティス
Secure Shell (SSH) は、リモートサーバー管理の根幹であり、安全なデータ通信、リモートコマンドライン実行、その他のネットワークサービスのための暗号化ネットワークプロトコルを提供します。しかし、その普及度の高さゆえに、攻撃者にとって格好の標的ともなっています。不適切に保護されたSSHサーバーは、重大な脆弱性を生み出し、不正アクセス、データ漏洩、システム侵害につながる可能性があります。リモートアクセス環境を保護することは、単なる良い習慣ではなく、必要不可欠なことです。
この記事では、SSHサーバーの設定を強化するための10の重要なベストプラクティスを概説します。これらの重要な設定ディレクティブ、推奨される権限設定、およびセキュリティのヒントを実装することにより、不正アクセスや、ブルートフォース攻撃、クレデンシャルスタッフィングなどの一般的な攻撃ベクトルに対するサーバーの防御を大幅に強化できます。これらのガイドラインに従うことで、リモート管理の安全性を確保し、サーバーインフラストラクチャを保護できます。
1. デフォルトのSSHポートを変更する
デフォルトのSSHポートは 22 です。これは世界的に知られており、脆弱なサーバーを探す自動化されたボットによって常にスキャンされています。デフォルトポートを変更することは、シンプルでありながら効果的な、隠蔽の層を提供します。それ自体がセキュリティ対策になるわけではありませんが、自動スキャンによるノイズを大幅に減らし、多くの日和見的な攻撃を回避するのに役立ちます。
ポートを変更するには、通常 /etc/ssh/sshd_config にある sshd_config ファイルを編集します。
sudo nano /etc/ssh/sshd_config
行 Port 22 を見つけ(または存在しない場合は追加し)、 22 を非標準の、未割り当てのポート番号(例: 2222 、 49152-65535 はユーザー/動的ポートです)に変更します。
#Port 22
Port 2222
ファイルを保存した後、SSHサービスを再起動します。新しいポートでのトラフィックを許可し、古いポートをブロックするようにファイアウォールルールを更新することを忘れないでください。
sudo systemctl restart sshd
# UFW (Uncomplicated Firewall) の場合:
sudo ufw allow 2222/tcp
sudo ufw deny 22/tcp
sudo ufw reload
# Firewalld の場合:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-port=22/tcp
sudo firewall-cmd --reload
ヒント: 設定変更をテストしている間は、必ずSSHセッションを少なくとも1つ開いたままにしておいてください。ロックアウトされた場合でも、アクティブなセッションで変更を元に戻すことができます。
2. rootログインを無効にする
SSH経由での直接のrootログインは強く推奨されません。 root ユーザーは無制限の権限を持っているため、攻撃者にとって主要な標的となります。攻撃者がrootアクセスを取得すると、システムを完全に制御されてしまいます。代わりに、一般の非特権ユーザーとしてログインし、その後 sudo を使用して管理タスクを実行してください。
sshd_config で、 PermitRootLogin ディレクティブを見つけ、値を no に設定します。
PermitRootLogin no
保存してSSHサービスを再起動します。
sudo systemctl restart sshd
3. 鍵ベース認証を使用する
パスワードベースの認証は、特にユーザーが弱いパスワードを選択した場合、ブルートフォース攻撃や辞書攻撃に対して脆弱です。SSH鍵ベース認証は、はるかに安全な代替手段です。これは、サーバーに保存される公開鍵と、ローカルマシンに保持される秘密鍵のペアである暗号鍵を使用します。一致する秘密鍵を持つクライアントのみが認証できます。
鍵ベース認証を実装する手順(概要):
- ローカルマシンで鍵ペアを生成します。
bash ssh-keygen -t ed25519 -b 4096 -C "[email protected]"ed25519はモダンで安全なアルゴリズムです。rsaも一般的であり、キー強度を高めるために-b 4096がよく使用されます。
- 公開鍵をサーバーにコピーします。
bash ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
または、手動で~/.ssh/id_ed25519.pubの内容を、ログインしたいサーバー上のユーザーの~/.ssh/authorized_keysに追記します。 -
サーバー上で正しい権限を確認します。
~/.sshディレクトリ:700(所有者のみrwx)~/.ssh/authorized_keysファイル:600(所有者のみrw)
bash chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
4. パスワード認証を無効にする
必要なすべてのユーザーに対して鍵ベース認証を正常に設定し、テストしたら、パスワード認証を完全に無効にする必要があります。これにより、ブルートフォースパスワード攻撃を不可能にし、SSHセキュリティにおける最も弱いリンクが排除されます。
sshd_config で、 PasswordAuthentication を no に設定します。
PasswordAuthentication no
保存してSSHサービスを再起動します。
sudo systemctl restart sshd
警告: アクセスが必要なすべてのユーザーに対して、鍵ベース認証が正しく機能することを確認する前に、パスワード認証を無効にしないでください。さもなければ、サーバーから締め出される危険があります。
5. ユーザーアクセスを制限する
デフォルトでは、サーバー上の任意のアカウントユーザーがSSH経由でログインを試みることができます。SSHアクセスを特定のユーザーまたはグループのみに制限することで、攻撃対象領域を最小限に抑えることができます。
sshd_config で AllowUsers または AllowGroups ディレクティブを使用します。
特定のユーザーのみを許可する場合(例: adminuser 、 devuser ):
AllowUsers adminuser devuser
特定のグループのメンバーのみを許可する場合(例: sshusers ):
AllowGroups sshusers
ヒント: 複数のユーザーがいる場合は、一般的に AllowGroups を使用する方が優れています。SSHアクセス専用のグループを作成し、許可されたユーザーをそこに追加します。
sudo groupadd sshusers
sudo usermod -aG sshusers adminuser
sudo usermod -aG sshusers devuser
変更を加えた後、保存してSSHを再起動します。
6. SSHキーに強力なパスフレーズを使用する
鍵ベース認証は堅牢ですが、秘密鍵は依然として重要な資産です。攻撃者がローカルマシンへのアクセスを取得した場合、秘密鍵を盗む可能性があります。強力なパスフレーズは秘密鍵を暗号化し、使用する前にロックを解除するためにそのパスフレーズが必要になります。これにより、たとえ鍵が盗まれたとしても、もう一つのセキュリティ層が追加され、保護されます。
SSHキーを生成する際(ステップ3を参照)、パスフレーズの入力を求められます。他のパスワードとは異なる、長く、複雑で、記憶しやすいパスフレーズを選択してください。
7. 接続レート制限を実装する (Fail2Ban)
鍵ベース認証を使用している場合でも、SSHサーバーは依然として接続試行の対象となります。 Fail2Ban のようなツールは、同じIPアドレスからの繰り返しのログイン失敗試行についてSSHログを積極的に監視し、設定された期間、ファイアウォールルールを使用してそのIPアドレスを自動的にブロックできます。
インストール(Debian/Ubuntuの例):
sudo apt update
sudo apt install fail2ban
Fail2Ban はデフォルトのSSHルールでそのまま動作しますが、 jail.conf を jail.local にコピーし、編集することで設定をカスタマイズできます。
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local
jail.local 内で、 [sshd] セクションの bantime 、 findtime 、 maxretry を調整できます。
[sshd]
enabled = true
port = 2222 # 新しいSSHポート
logpath = %(sshd_log)s
maxretry = 3
bantime = 1h # 1時間バンする
findtime = 10m # 10分以内に3回の失敗を探す
設定変更後、 Fail2Ban を再起動します。
sudo systemctl restart fail2ban
8. SSHサーバーソフトウェアを最新の状態に保つ
ソフトウェアの脆弱性は常に発見され、パッチが適用されています。古いSSHデーモンソフトウェア (OpenSSH) を実行していると、既知の悪用に対してさらされる可能性があります。セキュリティ脆弱性を修正するために、OpenSSHサーバーパッケージを含む、サーバーのソフトウェアを定期的に更新することが重要です。
# Debian/Ubuntu の場合:
sudo apt update && sudo apt upgrade
# CentOS/RHEL の場合:
sudo yum update
# または
sudo dnf update
適切な場合、セキュリティアップデートを自動的に適用するようにシステムを設定するか、手動更新のルーチンを確立してください。
9. 不審なアクティビティがないかSSHログを監視する
堅牢な予防策を講じたとしても、警戒心は重要です。SSH認証ログを定期的にレビューし、異常なパターン、ログイン失敗の試行、または不正アクセスの試行を検出してください。これは、潜在的な侵害や進行中の攻撃を特定するのに役立ちます。
SSHログは通常、以下の場所にあります。
/var/log/auth.log(Debian/Ubuntu)/var/log/secure(CentOS/RHEL)journalctlを使用する場合 (systemdシステム):
bash sudo journalctl -u sshd -f
繰り返しの認証失敗の試行、異常なIPアドレスからのログイン、または見慣れないユーザーによるログイン成功を探してください。 Logwatch や Elastic Stack (ELK) のようなツールは、大規模な環境でのログ分析とアラートを自動化できます。
10. アクセスを制限するためのファイアウォールルールを設定する
ファイアウォールは、あなたの最初の防衛線です。デフォルトでは、明示的に公開する必要があるサービスを除き、すべての着信トラフィックをブロックする必要があります。SSHの場合、これは選択したポート(例: 2222 )での接続のみを許可し、理想的には、特定の信頼できるIPアドレスまたはネットワークからのみ接続を許可することを意味します。
UFW (Uncomplicated Firewall) を使用した例:
特定のIPアドレス 192.168.1.100 からポート 2222 へのSSHを許可する:
sudo ufw allow from 192.168.1.100 to any port 2222
特定のサブネット 192.168.1.0/24 からのSSHを許可する:
sudo ufw allow from 192.168.1.0/24 to any port 2222
Firewalld (CentOS/RHEL) を使用した例:
特定のIPアドレス 192.168.1.100 からポート 2222 へのSSHを許可する:
sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port=2222 protocol="tcp" accept'
sudo firewall-cmd --reload
警告: 動的IPアドレスからサーバーを管理している場合は、厳格なファイアウォールルールには注意してください。より広範囲からのアクセスを許可するか、VPNを使用する必要があるかもしれません。
その他の強化のヒント
必須の10項目を超えて、さらにセキュリティを強化するために、これらのディレクティブを検討してください。
MaxAuthTries: 接続あたりの認証試行回数を制限します。デフォルトは6です。これを下げる(例:3)と、ブルートフォースの機会が減少します。sshd_configで設定します。
config MaxAuthTries 3LoginGraceTime: ユーザーが認証を許可される時間を制限します。デフォルトは2分です。これを下げる(例:30s)と、低速な攻撃のウィンドウが短縮されます。
config LoginGraceTime 30sClientAliveIntervalとClientAliveCountMax: アイドル状態のSSHセッションが無期限に開いたままになるのを防ぎます。ClientAliveIntervalはX秒ごとにヌルパケットを送信します。ClientAliveCountMax(デフォルト3)の応答が失われた場合、接続は終了されます。
config ClientAliveInterval 300 ClientAliveCountMax 0 # セッションを無期限に維持したい場合は、クライアント生存チェックを無効にするBanner: 認証前に警告メッセージを表示します。これは、潜在的な不正ユーザーに対する法的通知として機能します。
config Banner /etc/issue.net
希望の警告メッセージを含む/etc/issue.netファイルを作成します。
結論
SSHサーバーの強化は、一度きりの設定ではなく、継続的なプロセスです。デフォルトポートの変更やrootログインの無効化から、鍵ベース認証の強制、ファイアウォールの導入に至るまで、これら10の重要なベストプラクティスを実装することにより、リモートアクセスに対して堅牢なセキュリティ体制を確立できます。変更点を慎重にテストし、システムを最新の状態に保ち、不審なアクティビティがないかログを定期的に監視することを常に忘れないでください。一貫した警戒心が、安全で信頼性の高いリモート管理環境を維持するための鍵となります。
これらのプラクティスは、すべてのサーバー管理者にとって基礎となるものであり、一般的なサイバー脅威への露出を大幅に減らし、不正アクセスや潜在的な侵害からサーバーインフラストラクチャを保護します。