玄関の鍵を「開けっ放し」にしていないか？ SSHブルートフォースからサーバーを守る現場の鉄則
深夜、ふとログを確認すると auth.log が真っ赤に染まっている——。世界中のどこかのボットネットが、君のサーバーの TCP/22 を執拗に叩き続けている。エンジニアなら誰もが一度は経験する、いわゆる「SSHブルートフォース攻撃」の洗礼だ。
今日は、教科書的な「セキュリティを強化しましょう」という抽象論ではなく、現場で我々が血を流しながら学んできた、SSHの防御術について話をしよう。
1. なぜ「パスワード認証」が最大の脆弱性なのか
SSH（Secure Shell）は、RFC 4251で定義された極めて強力なプロトコルだ。しかし、どんなに暗号化が強固でも、玄関の鍵が「推測可能なパスワード」であれば、それは無意味だ。
攻撃者は、辞書攻撃や総当たり攻撃（ブルートフォース）で、何万通りものパスワードを叩き込んでくる。君がどれほど複雑なパスワードを設定しても、相手は機械だ。疲れることもなければ、諦めることもない。
現場の教訓：パスワード認証は「即刻無効化」が正解だ。
2. 実践：SSH防御の「三種の神器」
まずは、/etc/ssh/sshd_config を開いてほしい。設定を変更したら、必ず sshd -t で構文チェックを行い、systemctl restart sshd を忘れないこと。
設定の核となる記述例
# /etc/ssh/sshd_config の設定例
# 1. ルートログインを禁止（踏み台にされても権限を制限する）
PermitRootLogin no
# 2. パスワード認証を完全に無効化（公開鍵認証のみ許可）
PasswordAuthentication no
# 3. チャレンジレスポンス認証も無効化
ChallengeResponseAuthentication no
# 4. 空パスワードを許可しない
PermitEmptyPasswords noこれだけで、ブルートフォース攻撃の99%は無効化できる。なぜなら、攻撃者は「パスワードを入力するプロンプト」すら表示されず、接続を拒否されるからだ。
3. 動的防御：Fail2banによる「門前払い」の自動化
設定を固めても、無駄な通信がパケットフィルターや認証プロセスを叩き続けるのはリソースの無駄だ。そこで登場するのが Fail2ban である。
Fail2banは、認証失敗のログをリアルタイムで監視し、閾値を超えた IPアドレス を iptables や nftables で自動的にブロックする。
# /etc/fail2ban/jail.local の設定例
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3 # 3回失敗したらアウト
bantime = 3600 # 1時間はブロックするこの仕組みは、いわば「怪しい奴を自動的に入り口でブラックリストに載せる門番」だ。実運用では、誤って自分自身をブロックしないよう ignoreip で社内ネットワークや開発者の固定IPをホワイトリストに入れておくのが定石だ。
4. 運用サイドが知っておくべき「SSH通信の裏側」
エンジニアとして、クライアント側から ssh を叩く際や、自動化ツールで接続する際の挙動も理解しておこう。
例えば、Pythonの paramiko ライブラリを使ってSSH接続を自動化する場合、コード内には絶対にパスワードをハードコードしてはいけない。常に SSHKey を使用すること。
import paramiko
# 鍵認証を用いた接続のサンプル
key = paramiko.RSAKey.from_private_key_file("/home/user/.ssh/id_rsa")
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
# 接続時に鍵を渡す
client.connect(hostname='your.server.ip', username='deploy', pkey=key)
print("セキュアな接続が確立されました")
client.close()5. まとめ：セキュリティは「多層」で考える
SSHのポートを空けておくことは、インターネットという荒野に自分の部屋を置くようなものだ。今回の対策をまとめるとこうなる。
1. 認証の強靭化: PasswordAuthentication no にし、RSAやEd25519の鍵認証を強制する。
2. 攻撃の無力化: Fail2ban で機械的な試行を遮断する。
3. 境界の最小化: 必要であれば SSH のポート番号を変更する（セキュリティ・バイ・オブスキュリティだが、ログのノイズ軽減には有効だ）。
セキュリティに「絶対」はない。だが、これらの設定を行うだけで、君のサーバーは「簡単に食い荒らせるカモ」から、「手を出すにはコストが見合わない堅牢な要塞」へと変わる。
サーバーのログが平穏を取り戻したとき、君はまた一つ、エンジニアとしての確かな「盾」を手に入れたことになるはずだ。何かトラブルがあれば、いつでもログを確認し、パケットの流れを追うこと。それが、最強の防衛術なのだから。
コメント