AWSでEC2を新規に立てた場合、SSHのパスワード認証はデフォルトで無効化されています。
そのため、「SSHのブルートフォース攻撃なんて、自分には関係ない」と感じている方も多いかもしれません。
では、
「もしSSHパスワード認証を有効化してしまった場合、実際に何が起きるのか？」
本記事ではこの疑問に答えるため、あえて危険な構成を再現します。
- EC2でSSHのパスワード認証を意図的に有効化
- Kali Linux を使って解析を再現
※本記事の検証は、すべて運営者が管理するAWS EC2上でのみ実施しています。
SSHブルートフォース攻撃の仕組み
SSHブルートフォース攻撃の本質は非常に単純です。
- 22番ポートが開いているIPを探す
- よく使われるユーザー名を試す
- パスワードを総当たり、または辞書攻撃
- 成功したら即座に侵入
ここで重要なのは、攻撃者はあなた個人を狙っていないという点です。
- EC2
- オンプレサーバ
- VPS
区別はありません。
「IP + 22番が開いている」
それだけで対象になります。
検証環境の構成（AWS EC2 / Kali Linux）
本記事では、以下の環境を用いて検証を行います。
- AWS EC2（Amazon Linux 2023）
- セキュリティグループで22番ポートをフルオープンで開放
- SSHのパスワード認証を 意図的に有効化
- Kali Linux で解析
繰り返しになりますが、検証対象は運営者が管理するEC2のみです。
※AWS EC2ではSSHのパスワード認証はデフォルトで無効になっているため安心してください。
EC2でSSHパスワード認証を意図的に有効化する
推奨されていませんが、検証のために以下を行います。
- SSH設定でパスワード認証を有効化
SSH設定ファイルを編集する
まず、SSHの設定ファイルを編集し、PasswordAuthenticationをyesにします。
sudo vi /etc/ssh/sshd_config
パスワードログイン可能なユーザーを用意する
Amazon Linux2023 では、ec2-user に パスワードが設定されていません。
そのため、パスワードを設定します。
sudo passwd ec2-userSSHデーモンを再起動する
設定変更を反映させるため、SSHサービスを再起動します。
sudo systemctl restart sshdこの時点で、EC2は意図的に危険な状態になります。
ローカルからパスワード認証で接続できるか確認
別ターミナル、または別端末から以下を実行します。
ssh ec2-user@<EC2のパブリックIP>以下のようにパスワード入力をしてSSH接続できれば成功です。
この構成がどれほど危険かを、以降の章で確認します。
Kali Linux を使った攻撃の再現
次に、攻撃者視点を再現します。
Kali Linux から SSH ポートの到達性を確認
まず、Kali Linux からnmapを使用して対象のEC2 に対して、22番ポートが外部から到達可能か を確認します。
nmap -p 22 <EC2のパブリックIP>
この時点で分かるのは、次の事実だけです。
- EC2 に 22番ポートで通信可能
- SSH サービスが稼働している
- ファイアウォールや SG では遮断されていない
まだ、この段階ではパスワード認証が有効かどうかは分かりません。
SSH 接続試行時の挙動を観測する
次に、SSH 接続を試みた際の サーバー側の応答挙動 を観測します。
※ユーザー名は存在しそうなもの（例：ec2-user）
ssh -vvv ec2-user@<EC2のパブリックIP>この ssh -vvv デバッグログから重要な部分を抜粋します。
- TCP/22 に接続でき、SSHハンドシェイクが完了している
debug1: Connection established.
...
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.7- サーバーが「受け付ける認証方式」の一覧に password が含まれている
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
...
debug1: Next authentication method: password
ec2-user@xxx.xxx.xxx.xxx's password:- クライアントに鍵がないため、結果的にパスワード認証へフォールバックしている。「鍵認証のみ」の構成なら、ここで
passwordに進まずPermission denied (publickey).で終わる
no such identity: /home/tsunomaru/.ssh/id_rsa: No such file or directory
...
Next authentication method: password外部から「鍵認証のみ」か「パスワード認証も有効か」はログを突き合わせて判断可能 です。
ここまでわかってしまえばあとはパスワードの総当たり攻撃でサーバーに侵入することができてしまいます。
EC2 側で確認できる変化
EC2 側では以下のログが確認できます。
AmazonLinux2023では以下コマンドで確認できます。
sudo journalctl -u sshd- SSH がインターネットに公開されている(フルオープン)
Server listening on 0.0.0.0 port 22.
Server listening on :: port 22.- 外部IPからの接続試行
Connection closed by xxx.xxx.xxx.xxx port 53636 [preauth]- 鍵交換（KEX）段階で失敗している接続
Unable to negotiate with xxx.xxx.xxx.xxx port 35000: no matching host key type found
kex_exchange_identification: Connection closed by remote host- パスワード認証が実際に試され、成功したログ
※ 接続元が管理者の想定していないグローバルIPであった場合、
第三者による不正ログインの可能性が高い。
Accepted password for ec2-user from xxx.xxx.xxx.xxx port 53644 ssh2
pam_unix(sshd:session): session opened for user ec2-userログを確認すると、外部IPからの SSH 接続試行は
認証の成否に関係なく、常時発生していることが分かります。
認証前で切断されるケースも多いですが、パスワード認証が有効な場合、実際にログインが成立する例も確認できます。
実際に侵入が成立するまでの流れ
条件が揃うと、侵入は驚くほどあっさり成立します。
- 正しいユーザー名
- 推測可能なパスワード
- SSHパスワード認証が有効
この3点が揃った瞬間、
EC2は「自分だけのサーバー」ではなくなります。
以降は、
- 任意コマンド実行
- 情報の窃取
- マルウェア設置
- 踏み台化
すべて現実的なリスクになります。
なぜSSHは閉じ、SSMに移行すべきなのか
ここまでの検証から、結論は明確です。
- SSH（22番ポート）をインターネットに晒さない or フルオープンではなくIP制限する
- SSHパスワード認証を有効にしない
- 操作履歴を残す
これを満たすのが、AWS Systems Manager（SSM）です。
SSMを使えば、
- SSHポート不要
- PEMファイル不要
- IAM制御
- 操作ログが AWS CloudTrail に残る
「便利だから」ではなく、設計として安全だから 移行すべきです。
まとめ：EC2のSSH設計で本当に守るべきこと
- SSHブルートフォース攻撃は「理論」ではなく「現実」
- パスワード認証を有効にした瞬間、侵入は時間の問題
- SSHを前提にしない設計が必要 → SSMへ移行しましょう！
サーバーを守るとは、「頑張って監視すること」ではなく攻撃されない前提を作ることです。
