Linuxサーバーのパスワードが甘いとどうなる？SSH攻撃の実態と対策

 リナックスマスター.JPの宮崎智広です。
いつもありがとうございます。

SSHの設定方法をネットで調べて、記事の通りにやった。
鍵認証も設定した。ポートも変えた。

でも、その設定で本当に安全ですか？

ネットの情報は「やり方」は教えてくれます。
でも「その設定で何が防げて、何が防げないのか」までは教えてくれません。

もうひとつ、聞いてもいいですか？

あなたは今まで、検証用のLinuxサーバーを立てたとき、パスワードを「test123」や「server01」に設定したことはありませんか？

「検証用だし」「外からアクセスしないし」「あとで変えればいいし」。

心当たりがある方、正直に手を挙げてください。......はい、実は私も若い頃にやっています。そして、セミナーで3,100名以上を指導してきた中で、受講生の半数以上が同じことをやっていました。

でも、これは「玄関マットの下に鍵を隠して外出する」のと同じ行為です。

しかも相手は近所の空き巣じゃありません。世界中のボット（自動攻撃プログラム）が、24時間365日、あなたのサーバーのIPアドレスに向かってパスワードを片っ端から試し続けています。

この記事では、15年以上Linuxサーバーを運用してきた経験から、「パスワードが甘いサーバーに何が起きるのか」のリアルと、SSH攻撃を確実に防ぐ4つの対策を解説します。

あなたのサーバーは「今この瞬間」も攻撃されている

「うちのサーバーなんて誰も狙わないでしょ」

セミナーで受講生からこの言葉を聞くたびに、私はその場でログを見せるようにしています。見せた瞬間、顔色が変わる人がほとんどです。

あなたのサーバーでも、以下のコマンドを叩いてみてください。
インターネットに公開しているサーバーなら、見覚えのないIPアドレスからの大量のログイン試行が記録されているはずです。

実際のログは、こんな感じです。
3秒おき。root、admin、test、sato、oracle、postgres......。ありがちなユーザー名を片っ端から試しています。

これは人間がキーボードを打っているわけではありません。ボットによる完全自動の攻撃です。休憩もなし、寝ることもなし、24時間365日ひたすら回し続けます。

私自身の話をすると、新しいサーバーを構築してインターネットに公開したとき、SSHポートを開放して数時間後にログを見たら、もう不正ログインの試行が始まっていました。「もう来てるのか」と呆れたのを今でも覚えています。

これがインターネットの現実です。「うちは小規模だから」「検証用だから」は関係ありません。攻撃者にとっては、IPアドレスが存在する＝スキャン対象です。個人サーバーも企業サーバーも同じ土俵に立たされています。

攻撃に使われるパスワードのワードリストは80万語以上と言われています。一般的な英和辞典が約5万語ですから、その16倍のパターンを延々と試してくるわけです。「server123」程度のパスワードなら、ものの数分で突破されます。

パスワードが甘いとどうなるか｜3つの被害パターン

「で、実際にパスワードが破られたら何が起きるの？」

よく聞かれる質問です。答えは「あなたが想像しているより、ずっとひどいことが起きます」。15年の運用経験で実際に見聞きしてきた事例を3つ紹介します。

1. 踏み台にされる（スパム送信・他サーバーへの攻撃）

これが一番多いパターンです。

侵入されたサーバーにボットが仕込まれ、他のサーバーへのDDoS攻撃（分散型サービス妨害攻撃）やスパムメール送信に利用されます。

Tsunami DDoSボットに代表されるマルウェアは、SSHで侵入したLinuxサーバーに自動でインストールされ、攻撃者の指令に従って大量のトラフィックを送りつけます。

つまり、あなたのサーバーが「加害者」になるということです。

被害を受けた側から損害賠償を請求される可能性もあります。「自分は何もしていない」は通用しません。サーバーの管理責任を問われます。最悪の場合、取引先からの信頼を失い、事業そのものに影響が出ます。

2. 仮想通貨マイニングに利用される

近年急増しているのが、侵入したサーバーで仮想通貨のマイニング（採掘）を行うケースです。

XMRig CoinMinerなどのマイニングソフトが勝手にインストールされ、サーバーのCPUを100%食いつぶします。Webサイトの表示が遅くなる、処理がやたら重い、ファンがうるさい。こういう症状が出たら要注意です。
電気代が跳ね上がるだけでなく、本来のサービスが正常に動かなくなります。しかも気づかないまま数か月間マイニングに使われていた、という事例も珍しくありません。

3. データを盗まれる・改ざんされる

サーバー上のデータが丸ごと持ち出される危険があります。顧客情報、メールデータ、データベースの中身、設定ファイルに書かれたパスワード。

攻撃者がroot権限を取得すれば、サーバー上の全てのファイルにアクセスできます。さらに、盗んだ認証情報を使って別のサーバーやサービスにも侵入する「クレデンシャルスタッフィング」（流出した認証情報の使い回し攻撃）に発展するケースも増えています。

Webサイトの改ざんも深刻です。企業のホームページがフィッシングサイトに書き換えられたり、マルウェアを配布するページにされたりすれば、あなたのサイトの訪問者にまで被害が広がります。

SSH攻撃を防ぐ4つの対策

ここからは、私がサーバーを構築するときに必ず行っている対策を紹介します。セミナーでも、この手順をそのまま受講生に実践してもらっています。

順番も大事です。上から優先度が高い順に並べています。

1. パスワード認証を無効化し、鍵認証にする

最も効果が高く、最優先で実施すべき対策です。

パスワード認証の代わりに、SSH鍵認証（公開鍵認証）を使います。例えるなら、パスワード認証は「合言葉」で家に入る仕組みで、鍵認証は「物理的な鍵」を持っている人だけが入れる仕組みです。合言葉は推測できますが、鍵を複製するのはほぼ不可能です。

鍵認証は「秘密鍵」と「公開鍵」のペアを使う認証方式です。秘密鍵はあなたのPC上にだけ存在し、ネットワーク上を流れることはありません。3,000文字以上のランダムな鍵と、10文字程度のパスワードでは、セキュリティ強度が桁違いです。
鍵が正しく登録されたら、sshd_configでパスワード認証を無効にします。
【重要】設定を変更する前に、必ず「今つないでいるSSH接続を切らない」でください。別のターミナルから新しく接続を試して、鍵認証でログインできることを確認してから、古い接続を閉じます。

この「別ターミナルで接続テスト」は、現場のプロが絶対に省かない手順です。設定を間違えて自分が締め出されたら、データセンターに物理的に行くしかなくなります。私はこの確認を「命綱を離す前に新しい命綱をつかめ」と受講生に伝えています。

パスワード認証を無効にすると、ブルートフォース攻撃は完全に無意味になります。攻撃者がどんなパスワードを試しても、サーバーは「パスワード認証は受け付けていません」と返すだけです。

2. rootログインを禁止する

rootで直接SSHログインできる状態は非常に危険です。万が一突破されたら、サーバーを完全に乗っ取られます。
一般ユーザーでログインしてから、sudoでroot権限に切り替える運用にします。これで攻撃者が突破しなければならない壁が2枚になります。ユーザー名の推測と、そのユーザーの認証を両方クリアしなければ侵入できません。

3. SSHポート番号を変更する

SSHのデフォルトポートは22番です。攻撃者のボットはまず22番を狙います。ポート番号を変えるだけで、自動攻撃の大半を回避できます。
ただし、ポート変更は「鍵を玄関マットの下ではなく、植木鉢の下に隠す」程度の対策です。本気で探せば見つかります。あくまで他の対策と組み合わせてください。とはいえ、ログに記録される不正アクセスの量が激減するので、運用上のメリットは大きいです。

4. fail2banで不正アクセスを自動ブロック

fail2ban（フェイルツーバン）は、不正なログイン試行を検知して、そのIPアドレスを自動的にブロックするツールです。
デフォルト設定では、5回ログインに失敗したIPアドレスを10分間ブロックします。この設定はカスタマイズ可能で、私は3回失敗で1時間ブロックに変更しています。

パスワード認証を無効にしている場合でも、fail2banは入れておく価値があります。不正な接続試行そのものを減らし、ログをきれいに保つ効果があるからです。

「検証用だから」が一番危ない｜私が目の前で見たサーバー事故

ここで、私が実際に目の前で見た「パスワードの甘さが原因の事故」を話します。

ある受講生の方が、学習用に構築したLinuxサーバーをインターネットに公開していました。「検証用だから」と、rootのパスワードを「server123」に設定していたそうです。鍵認証は「あとで設定するつもりだった」と。

セミナーの翌日、「サーバーが重くて何も動かないんです」という連絡をもらいました。

リモートで一緒にサーバーを見ました。topコマンドを叩いた瞬間、画面いっぱいに見覚えのないプロセスが並んでいました。CPU使用率は100%に張り付いたまま。受講生の方と二人で、しばらく無言で画面を見つめていました。

仮想通貨のマイニングソフトが仕込まれていました。

さらにログを追うと、そのサーバーから海外のIPアドレスに対して大量の通信が発生していました。踏み台としても使われていた可能性が高い状況です。

結局、OSからクリーンインストールし直すことになりました。学習用のデータも全て失いました。

この受講生の方は、決して技術力がない人ではありません。ただ「検証用だからまだいいか」という油断があっただけです。

私はこの話をセミナーで必ずします。そして毎回、会場の空気が変わります。「自分も同じことをしている」と気づく人が、必ず何人かいるからです。

教訓は3つです。

・「検証用」でもインターネットに公開する以上、セキュリティ対策は必須
・パスワード認証を有効にするなら、最低でも鍵認証と併用する
・異変に気づける監視の仕組み（topの定期確認、ログ監視）を入れておく

攻撃者にとって、あなたのサーバーが検証用か本番用かは関係ありません。IPアドレスが存在すれば、等しく「侵入可能なターゲット」です。

よくある質問

Q. クラウド（AWSやAzure）なら安全ですか？

いいえ。クラウドだから安全、ということはありません。

AWSやAzureが責任を持つのは物理インフラまでです。OS（Linux）から上のセキュリティ設定は全て利用者の責任です（責任共有モデル）。

むしろ、AWSのEC2はデフォルトで鍵認証が有効です。ここに「便利だから」とパスワード認証を追加するのは絶対にやめてください。セキュリティグループでSSHの接続元IPを制限することも忘れずに。

Q. パスワードを複雑にすれば大丈夫ですか？

複雑なパスワードは最低限の対策ですが、それだけでは足りません。

ボットネットの進化により分散型の攻撃が可能になっていますし、「P@ssw0rd」のような一般的な置換パターンも辞書に登録済みです。パスワード認証そのものを無効にして、鍵認証に切り替えるのが根本的な解決策です。

Q. SSHポート変更だけではダメですか？

ポート変更は効果がありますが、それだけでは不十分です。ポートスキャンツールを使えば、変更後のポート番号はすぐに特定されます。鍵認証の設定やrootログイン禁止と組み合わせて、初めて効果を発揮します。

Q. fail2banとパスワード認証無効化、両方必要ですか？

パスワード認証を無効にしていればブルートフォース攻撃は無意味になりますが、fail2banには別のメリットがあります。不正な接続試行そのものをブロックすることで、ログのノイズを減らし、本当に注意が必要なイベントを見つけやすくなります。両方導入することをおすすめします。

まとめ

対策	効果	優先度
パスワード認証を無効化し、鍵認証にする	ブルートフォース攻撃を完全に無効化	最優先
rootログインを禁止する（PermitRootLogin no）	root権限の直接奪取を防止	高
SSHポート番号を変更する	自動攻撃ボットの大半を回避	中
fail2banで不正IPを自動ブロック	不正アクセスの遮断とログの浄化	中

SSHのパスワード認証を有効にしたままインターネットにサーバーを公開するのは、玄関の鍵を開けっ放しにしているのと同じです。

「検証用だから」「小さいサーバーだから」。この油断が一番危険です。私はセミナーで何度もその結果を見てきました。

まずは鍵認証の設定とパスワード認証の無効化。ここから始めてください。これだけでブルートフォース攻撃は完全に無効化されます。
P.S
セミナーでは、SSH鍵認証の設定やファイアウォールの構築も、実際に手を動かしながら学べます。「セキュリティは大事だと分かっているけど、何から手をつければいいか分からない」という方こそ、体系的に学べる環境が必要です。
【Linuxセミナー】リナックスマスタープロセミナー

[Linuxサーバー構築の全体像｜初心者が知っておくべき手順と現場のリアル]
[「とりあえず再起動」が危険な理由｜プロのトラブル初動を現役講師が解説]



---

• 前のページへ：「動いてるつもり」が一番怖い｜cronジョブの落とし穴と3つの対策
• この記事の属するカテゴリ：Linux学習ガイドへ戻る