SSH要塞化のリアル：ポート変更とFail2Banは「気休め」か「必須の防壁」か
現場でインシデント対応をしていると、朝一番に「サーバーが重い」というアラートが飛んでくることがあります。調査してみると、/var/log/auth.log が数ギガバイトに膨れ上がり、世界中のボットネットから数秒間隔で辞書攻撃（Brute Force）を受けている……。こんな光景は、もはや日常茶飯事です。
「SSHのポート22を変えても意味がない」「Fail2Banなんて気休めだ」というエンジニアもいますが、それは半分正解で半分間違いです。これらは「高度な標的型攻撃」を防ぐものではなく、「掃き溜めのような自動化された無差別攻撃」をフィルタリングし、ログのノイズを消して本当の脅威を可視化するための必須の防壁なのです。
今日は、泥臭い運用現場で生き残るための「SSH要塞化」の勘所を伝授します。
—
1. なぜ「ポート変更」と「動的ブロッキング」が必要なのか
攻撃者は、Nmap等のスキャナを使って世界中のIPアドレスに対し、ポート22が空いているかを確認し、即座にブルートフォースを開始します。
- ポート変更の真意: 22番ポートを狙い撃ちする「低IQなボット」を排除し、ログをクリーンに保つためです。
- Fail2Banの真意: 3回ログインに失敗したIPをファイアウォール（iptables/nftables）レベルで即座に遮断し、攻撃のリソースを枯渇させるためです。
これらを実装することで、あなたのサーバーは「攻撃対象リスト」から、少なくとも「割に合わないターゲット」へと格上げされます。
—
2. 実装：SSH設定の要塞化
まずは /etc/ssh/sshd_config を編集します。ポート番号はデフォルトの22から、1024〜65535の範囲でランダムな値に変更してください。
# /etc/ssh/sshd_config の抜粋
# 標準の22番ポートから変更（例：50022）
Port 50022
# ルートログインの禁止（鉄則）
PermitRootLogin no
# パスワード認証を無効化し、公開鍵認証のみにする
PasswordAuthentication no
PubkeyAuthentication yes
# 認証試行回数を制限
MaxAuthTries 3設定を反映させたら sudo systemctl restart sshd を忘れずに。必ず現在のセッションを切断する前に、別のターミナルで新しいポートで接続できるか確認してください。 これを怠ると、自分自身をロックアウトする悲劇が待っています。
—
3. Fail2Banによる動的ブロッキングの実装
Fail2Banは、ログを監視して「怪しいIP」を見つける番人です。以下の設定で、SSHのログイン失敗を検知して即座に遮断します。
/etc/fail2ban/jail.local の設定サンプル
[sshd]
enabled = true
port = 50022
filter = sshd
# 3回失敗したらアウト
maxretry = 3
# 1時間遮断する（攻撃者はすぐ諦めて他へ移ります）
bantime = 3600
# ログパスを指定
logpath = /var/log/auth.logこの設定により、攻撃者は3回失敗した瞬間にファイアウォールの「ブラックリスト」に放り込まれます。
—
4. 運用エンジニアへの警鐘：これだけで安心か？
ここからが本題です。ポートを変え、Fail2Banを入れても、「鍵認証の秘密鍵が漏洩している」あるいは「OSやミドルウェアに既知の脆弱性が放置されている」状態では、セキュリティは崩壊します。
実務で守るべき3つの鉄則
1. 秘密鍵の管理: 秘密鍵は絶対にリポジトリにコミットしないこと。紛失・漏洩のリスクがある場合は即座に鍵をローテーションしてください。
2. ログの監視: Fail2Banが動いていても、時々 fail2ban-client status sshd コマンドで遮断数を確認してください。異常に多い場合は、特定の攻撃者から執拗に狙われている可能性があります。
3. 多要素認証（MFA）の導入: 可能であれば、SSH接続時にGoogle Authenticator等によるワンタイムパスワード認証を追加してください。これが現在、最強の防壁です。
—
まとめ：セキュリティは「多層防御」の積み重ね
SSHのポート変更とFail2Banは、いわば「家の鍵を二重にして、防犯カメラを設置する」ようなものです。これだけでプロの泥棒を防げるわけではありませんが、「無防備な家」を狙う泥棒を追い払うには十分すぎるほど効果的です。
セキュリティに「完璧」はありません。しかし、日々の運用でこうした「泥臭い対策」を一つ一つ積み上げることが、あなたの管理するシステムを強固にし、あなた自身のエンジニアとしての価値を証明することに繋がります。
明日からの運用で、まずは sshd_config の見直しから始めてみてください。それが、堅牢なインフラへの第一歩です。
コメント