踏み台サーバー（Bastion）は「最後の聖域」ではない。だからこそ、鉄壁でなければならない。
現場でインシデント対応をしていると、決まって遭遇する光景がある。「踏み台サーバーがあるから大丈夫だと思っていた」というエンジニアの悲痛な叫びだ。
多くの開発チームが、パブリックサブネットにポツンと置かれたSSHサーバーを「管理用の入り口」として信頼しきっている。だが、攻撃者にとってその踏み台は、「一度突破すれば、社内ネットワークという広大な遊び場への鍵束が手に入る宝箱」に他ならない。
今日は、教科書的な「不要なサービスを止めろ」という説教は省略する。その一歩先、現実の攻撃手法と、それを鼻で笑って弾き返すための「実戦的な要塞化」について話そう。
なぜ踏み台は「最初の標的」になるのか
攻撃者は、踏み台サーバーに対して以下のような泥臭い攻撃を仕掛けてくる。
1. 辞書攻撃・総当たり: 22番ポート（SSH）をスキャンし、rootログインや脆弱なパスワードを狙う。
2. 鍵の窃取: 開発者のローカルPCがマルウェアに感染し、~/.ssh/id_rsaが盗まれる。
3. セッションハイジャック: 踏み台を経由した先のサーバーへの通信を盗聴・乗っ取り。
これらを防ぐための唯一の正解は、「踏み台をインターネットから隔離し、アクセスを完全に制御すること」だ。
1. ネットワークの要塞化：IP制限とゼロトラスト的アプローチ
まず、踏み台サーバーをパブリックサブネットに置く発想を捨てろ。どうしても置く必要があるなら、せめてSecurity Groupで世界中からのアクセスを拒否せよ。
理想は AWS Systems Manager (SSM) Session Manager の利用だ。これを使えば、SSHポート（22番）を全開放する必要はなくなる。
AWS IAM ポリシー設定（最小権限の原則）
特定のユーザーのみが踏み台にアクセスできるよう、IAMで厳格に制御する。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:StartSession"
],
"Resource": [
"arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abcdef1234567890"
],
"Condition": {
"StringEquals": {
"aws:SourceIp": ["203.0.113.0/24"]
}
}
}
]
}*※ aws:SourceIpでオフィスからのアクセスのみを許可することで、万が一認証情報が漏れても、自宅やカフェからの侵入を物理的に弾ける。*
2. Linux OSのハーデニング：不要な「入り口」を潰す
OSレベルでは、攻撃者が足場を固めるのを防ぐために、シェルアクセスを制限し、ログを外部へ強制退避させる。
/etc/ssh/sshd_config の要塞化設定
デフォルト設定のまま運用するのは、鍵のかかっていない玄関を開けておくのと同じだ。
# パスワード認証を禁止（鍵認証のみに強制）
PasswordAuthentication no
# rootログインを禁止
PermitRootLogin no
# 不要なポートフォワーディングを制限
AllowTcpForwarding yes
# X11転送を無効化（攻撃の足場にされやすいため）
X11Forwarding no
# アイドルタイムアウト設定（600秒＝10分で自動切断）
ClientAliveInterval 600
ClientAliveCountMax 03. SSHログのリアルタイム監視と自動遮断（Fail2Ban）
「パスワードを試されたらどうするか」という問いに対する答えは、「即座に遮断する」ことだ。fail2banを導入し、数回のログイン失敗でそのIPをファイアウォール（iptables）から追放せよ。
# /etc/fail2ban/jail.local の設定例
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
# 3回失敗したら1時間ブロック
maxretry = 3
bantime = 36004. 踏み台を超えた先の「隠蔽」：セッション管理
踏み台にログインした後の挙動も追跡が必要だ。scriptコマンドを使って、全操作ログをクラウド上のログストレージ（CloudWatch Logs等）へ転送する設定を入れろ。
/etc/profile への追記（操作ログの強制記録）
全ユーザーの操作履歴を改ざん不可能な場所へ送るための泥臭いテクニックだ。
# ログイン時にログを取得開始する
if [ -z "$SESSION_LOG_STARTED" ]; then
export SESSION_LOG_STARTED=1
# ユーザー名と日時を付与してログファイルを作成
script -f /var/log/session_logs/$(whoami)_$(date +%Y%m%d_%H%M%S).log
fi最後に：セキュリティは「設定」ではなく「文化」だ
ここまで設定しても、一番の脆弱性は常に「人」にある。秘密鍵をSlackに貼る、authorized_keysを安易に共有する、そんな運用が続けば、どんな強固な設定も紙屑になる。
「面倒くさい」と感じる設定こそが、実は最も攻撃者が嫌がる壁だ。今日紹介した設定は、明日からすぐに適用できる。踏み台を「単なる通り道」ではなく、「攻撃者が最初に絶望する場所」に変えること。それが、真のエンジニアが守るべきプロの誇りだ。
何か不明点があれば、またいつでも聞いてくれ。現場で叩き上げられた知識こそが、君のシステムを守る唯一の盾になる。
コメント