こんにちは、インフラエンジニアのryuです。
勉強のためにクラウドやVPSでサーバーを1台借りて、SSHでログインできたときの感動を覚えているでしょうか。真っ黒な画面にプロンプトが出た瞬間、自分の城ができたような気分になりますよね。
ところが翌日、なんとなくログを開いてみると、見覚えのないユーザー名でのログイン失敗が延々と並んでいる。admin、test、ubuntu、root。自分では一度も打っていないはずの名前です。
「まさか、もう狙われている……？」
その感覚は正しいです。しかも狙われている理由は、あなたが有名だからでも、価値あるデータを持っているからでもありません。ただ、そこにサーバーがあったからです。
今日は、学習用のサーバーを持ち始めた人が最初につまずくこのテーマを扱います。難しいセキュリティ理論の話ではありません。公開したサーバーを最低限守るために、最初に手を動かすべきことは何か、という実務の入口の話です。
公開したサーバーは、どれくらい「見られて」いるのか？¶
まず、感覚をつかむところから始めましょう。
警察庁は、インターネット上に観測用のセンサーを置いて、そこに届く不審なアクセスの件数を毎年公表しています。令和7年上半期の集計では、脆弱性を探しにくるようなアクセスは1日・1IPアドレスあたり9,085.4件でした。前年の同じ時期からは7.5%減っていますが、それでも1つのIPアドレスに毎日9千回です。
令和6年の通年では1日・1IPアドレスあたり9,520.2件で、こちらは前年比4.1%増でした。つまり多少の増減はあっても、水準としてはずっと高いままです。
これを身近な言葉に置き換えてみます。郵便受けに毎日9千通の手紙が届いて、そのほとんどが「鍵は開いていませんか」「留守ではありませんか」と確認してくる差出人不明の手紙、という状態です。
家であれば異常事態ですが、インターネットに置いたサーバーではこれが平常運転です。
叩いているのは人ではなく、機械¶
ここで多くの初心者が誤解します。「自分のような学習用サーバーを、わざわざ人間が狙うはずがない」と考えてしまうのです。
そのとおりで、人間は狙っていません。狙っているのはプログラムです。
インターネット上のIPアドレスは、有限の空間として全部並べることができます。攻撃側は、そこを片端から機械的に叩いて、22番ポート（SSH）が開いている相手を見つけ、片端からユーザー名とパスワードの組み合わせを試します。これがブルートフォース攻撃と呼ばれるやり方です。攻撃の中身はブルートフォース攻撃とは？攻撃方法と対策を解説にまとめてあるので、あわせて読むと理解が早いはずです。
人間が相手なら「価値がなさそうだからやめておこう」という判断が働きます。プログラムには、その判断がありません。だから、立てた直後の練習用サーバーにも同じだけの試行が飛んでくるわけです。
裏を返せば、対策も機械的でかまわないということです。相手が総当たりなら、こちらは総当たりが通らない状態を作ればいい。それだけで大半は防げます。
「壊されて困るものは入っていない」は理由にならない¶
もうひとつよくある考え方が、「中身は勉強用のファイルだけだから、乗っ取られても痛くない」というものです。
けれど攻撃側から見ると、あなたのサーバーには価値があります。他人を攻撃するための踏み台として使えるからです。仮想通貨のマイニングに使われることもあれば、迷惑メールの送信元にされることもあります。
そうなると、被害を受けるのはあなたではなく、あなたのサーバーから攻撃された誰かです。クラウド事業者からアカウントを止められ、請求だけが残ることもあります。
自分のためというより、他人に迷惑をかけないために守る。この感覚は、実務に出てからも効いてくる考え方です。
現場のインフラエンジニアが、たった1台の検証サーバーにも同じ手順を求めるのは、この理由が大きいところがあります。本番かどうかではなく、インターネットに面しているかどうかで判断が変わるわけです。
学習用だから雑でいい、という線引きは存在しません。逆にいえば、練習用サーバーで身につけた手順は、そのまま本番でも通用します。
最初にやることは4つだけ¶
では何をすればいいのか。細かい設定は無数にありますが、学習用のサーバーで最初にやるべきことは、次の4つに集約できます。
| やること | 何を防ぐか | 確認に使うコマンド |
|---|---|---|
| 開いている入口を減らす | 意図しないサービスへの侵入 | ss -tulpn |
| パスワードをやめて鍵にする | 総当たりでのログイン成功 | sshd -T \| grep -i auth |
| 更新を自動で当てる | 既知の脆弱性の放置 | apt list --upgradable |
| ログを見る習慣をつける | 異常に気づかないこと | journalctl -u ssh |
順番にも意味があります。入口を減らせば試行される場所が減り、鍵にすれば試行そのものが通らなくなり、更新を当てれば「そもそも既知の穴」がなくなる。最後にログで確認する、という流れです。
入口を減らす：開いているポートを自分で把握する¶
まず、いま自分のサーバーが外向きに何を開いているのかを見ます。
# 待ち受けているTCP/UDPポートと、それを開いているプロセスを表示する
ss -tulpn
# ファイアウォールの状態を見る（Ubuntu系）
sudo ufw status verbose
# RHEL系なら firewalld
sudo firewall-cmd --list-all
ss -tulpn の出力に、自分が意図していないサービスが並んでいたら、それは閉じる候補です。試しに入れたデータベースやテスト用のWebサーバーが、0.0.0.0 で全世界に向けて待ち受けていた、というのは初心者が本当によくやる事故です。
127.0.0.1 で待ち受けていれば外からは届きません。この違いが分かるようになると、設定ファイルを読む目つきが変わります。
考え方としては、家の戸締まりと同じです。玄関の鍵を厳重にしても、勝手口と窓が開けっ放しなら意味がありません。使っていない入口は、そもそも作らないのがいちばん確実です。
学習中はあれこれ試したくなるので、入れっぱなしのミドルウェアが増えがちです。月に一度でいいので ss -tulpn を眺めて、身に覚えのない待ち受けがないかを確認する時間を作っておくと安心できます。
鍵にする：パスワード認証をやめる¶
次がいちばん効果の大きい設定です。SSHのログインを、パスワードから公開鍵認証に切り替えます。
パスワードは、当てられる可能性がゼロではありません。総当たりで9千回試されるなら、いつか当たるかもしれない。一方の公開鍵は、当てることが現実的でない長さの鍵を使います。
イメージとしては、暗証番号を4桁から、桁数が数えきれないほどの鍵に取り替えるようなものです。しかも、その鍵はサーバー側に置きません。手元のPCに秘密鍵を持ち、サーバーには対になる公開鍵だけを預けます。だから、サーバーが覗かれても入る手段は漏れません。
# 手元のPCで鍵を作る（ed25519は現在の推奨方式）
ssh-keygen -t ed25519 -C "study-server"
# 公開鍵をサーバーへ登録する
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.10
鍵でログインできることを確認してから、サーバー側の /etc/ssh/sshd_config を編集します。
PermitRootLogin prohibit-password
PasswordAuthentication no
PermitRootLogin prohibit-password は、rootのパスワードログインだけを禁じる設定です。OpenSSHでは以前からこれが既定値になっています。PasswordAuthentication no を入れると、一般ユーザーもパスワードでは入れなくなります。
設定を変えたら、いま開いているSSH接続は閉じずに、別のターミナルからログインできるか確かめてください。設定ミスで締め出されると、コンソール経由でしか復旧できなくなります。
この「もう一枚の窓を開けたまま作業する」感覚は、実務の変更作業でもそのまま使います。落ちても戻れる道を残しておく、という発想です。
更新を当てる：手作業に頼らない¶
攻撃の多くは、公表済みの脆弱性を狙います。逆にいえば、更新を当てているだけで防げるものがかなりあります。
問題は、学習用のサーバーほど更新を忘れることです。毎日触るわけではないので、気づけば数か月放置していた、ということが起きます。
だから自動にします。Ubuntuには unattended-upgrades が入っていて、セキュリティ更新を自動で適用してくれます。18.04以降はデフォルトでインストールされています。
# Ubuntu：自動更新の設定を確認・有効化する
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
# RHEL系は dnf-automatic を使う
sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer
再起動が必要な更新もあるので、カーネル更新のあとは自分で再起動する、というところまで含めて習慣にしておくといいでしょう。
ログを見る：守れているかを自分の目で確かめる¶
設定を入れたあとに、効いているかどうかを確かめる方法も持っておきたいところです。
# SSHへのログイン試行を見る（systemd系）
sudo journalctl -u ssh --since "1 hour ago" | grep -i "failed\|invalid"
# ディストリによっては認証ログのファイルを直接見る
sudo tail -n 50 /var/log/auth.log
失敗ログが並んでいても、パスワード認証を止めたあとであれば「試されたが通っていない」という記録です。攻撃が来ていること自体は止められませんが、通っていないことは確認できます。
ログの読み方そのものに自信がない場合は、原因はだいたいログに書いてある。未経験インフラエンジニアのためのログの読み方入門で基本の型を押さえておくと、この作業がぐっと楽になります。
繰り返し試行してくる相手を自動で遮断したいなら、fail2ban のような仕組みを足す手もあります。ただ、これは鍵認証に切り替えたあとの追加装備という位置づけで十分です。
守りとセットで、戻せる状態も作っておく¶
もうひとつ、学習を始めた早い段階で習慣にしておきたいことがあります。壊れたときに戻せる状態を、先に用意しておくことです。
セキュリティというと侵入を防ぐ話ばかりに目が行きますが、実務で本当に効くのは「やられても戻せる」という備えのほうです。クラウドであればスナップショットを1枚取っておくだけで、設定を壊しても数分で元に戻せます。
学習の効率という意味でも、これは大きい違いを生みます。戻せる状態があると、思い切った設定変更を試せるようになるからです。壊すのが怖い環境では、コピー＆ペースト以上のことができません。
自宅の仮想マシンで学んでいる場合も同じで、動く状態のスナップショットを1つ残してから設定をいじる、という順番を守るだけで、学習の速度がはっきり変わります。環境の作り方そのものは自宅で作るインフラ学習ラボにまとめてあります。
初心者がはまりやすい3つの勘違い¶
ここまでの内容を実際にやってみると、途中で迷う場面が出てきます。よくある勘違いを3つ挙げておきます。
ひとつめは、SSHのポート番号を22から変えれば安全になる、という考え方です。自動スキャンの多くは22番だけを見ているので、ログの量は確かに減ります。しかし、それは的を少しずらしただけで、鍵をかけたわけではありません。ログが静かになって安心してしまうぶん、かえって危ないこともあります。
ふたつめは、クラウドのセキュリティグループを設定したから、サーバー側のファイアウォールは不要だ、という考え方です。どちらか一方でも守れる場面は多いのですが、片方の設定を緩めた瞬間に無防備になります。守りは重ねるものだと考えてください。
みっつめは、セキュリティは一通り勉強してからまとめてやる、という順番です。学習用サーバーは、勉強が終わるのを待ってはくれません。今日立てたサーバーは、今日から叩かれます。
完璧な設定を目指すより、鍵認証と自動更新だけ先に入れてしまうほうが、結果的にずっと安全です。
このあたりの判断は、コマンドの暗記ではなく、仕組みの理解から生まれます。Linuxの操作そのものが不安なら、Linuxのコマンドを初心者向けに解説やviコマンドの使い方で土台を固めてから戻ってくると、設定ファイルの編集で手が止まらなくなります。
資格の勉強とも、意外につながっている¶
ここで扱った内容は、資格試験の範囲とも重なります。LPICではSSHの設定やファイアウォール、パーミッションの考え方が出題されますし、実際に手を動かした経験があると、選択肢を読んだ瞬間に情景が浮かびます。
参考書だけで覚えた知識は、試験が終わると抜けていきます。自分のサーバーで一度締め出されかけた経験は、なかなか抜けません。LPICの勉強方法と組み合わせて、机上と実機を行き来する学び方をおすすめします。
体系的に順番を追って学びたい場合は、InfraAcademyのLinuxのロードマップを眺めてみてください。今日の内容がどのあたりに位置しているのかが見えると、次に何を触ればいいかで迷わなくなります。手を動かした経験に、後から体系を重ねるのが、遠回りに見えていちばん速い順路です。
まとめ¶
学習用のサーバーは、公開した瞬間から見知らぬプログラムの訪問を受けます。警察庁の観測でも、1つのIPアドレスに毎日9千件規模の不審なアクセスが届いている状況が続いています。
けれど、やるべきことは多くありません。開いている入口を把握して減らし、パスワード認証をやめて鍵にし、更新を自動で当て、ログで確かめる。この4つで、総当たりの大部分は素通りしていきます。
そして、この一連の作業はセキュリティの勉強であると同時に、ss や journalctl、systemctl といった実務のコマンドを自然に覚える機会でもあります。守るために手を動かしたことが、そのままLinuxの理解として残っていきます。
自分のサーバーを1台持って、それを守りきる。未経験からの学習で、これほど実務に近い練習はなかなかありません。今日ログを開くところから、始めてみてはいかがでしょうか。
