TomoyaVPSについて調べていると、契約したばかりのデフォルトの状態が一番狙われやすい、という話が繰り返し出てきました。
これがとても気になったので、最低限のセキュリティ対策を調べ、「なぜそれをやるのか」を理解した上で、今回もAIにサポートしてもらいながら作業を進めていきました。
VPSを契約すると、みな一律で同じ初期状態からスタートします。デフォルトのポート（22番）や、rootという決まったユーザー名での認証方法——これは便利な反面、「みんな同じ」だからこそ、そこを狙ってスパムボットや乗っ取りボットが常に巡回し、パスワードの総当たりを試みてくる、というのが今回知った怖さでした。
そこで今回は、デフォルトの状態から抜け出し、自分だけのサーバーにしていくという方針でセキュリティ対策を進めていきます。
進めていく中で他にも知るべきリスクは色々あると思いますが、今回はまず必要最低限のところまでを実践しました。全体的には割とスムーズに進みましたが、新しいコマンドへの戸惑いや、SSHのポート変更まわりで大きくつまずいた場面があったので、そこも正直に共有していきます。
今回のロードマップ
今回行うのは、以下の7ステップです。
- OSを最新の状態にする
- 作業用の一般ユーザーを作る
- そのユーザーで接続できることを確認する
- rootでの直接ログインを禁止する
- パスワード認証を無効化し、鍵認証のみにする
- SSHのポート番号を変更する
- ファイアウォールで不要なポートを閉じる
ターミナルでエラーが出ても、焦らずどっしり構えてください。
焦っていろいろ消してしまうと、自分自身がサーバーから締め出されてしまうリスクがあります。
この記事の通りに進める場合、時間制限は特にないので、安心してゆっくり進めてください。コマンドの打ち間違えや、ご自身のサーバー環境に応じた読み替えは適宜行ってください。
※操作・設定は自己責任で行ってください。
OSを最新の状態にする
ここはコマンドを打つだけで、スムーズに進みました。
apt update
apt upgrade -yupgradeの方は5分程度時間がかかりましたが、僕は特にやることはなく、進んでいく様子をただ眺めているだけでした。拍子抜けするくらい、あっさり完了しました。
一般ユーザーを作り、そのユーザーで接続を確認する
ここでは、root以外に自分専用の一般ユーザーを新たに作り、それをメインの接続先にしていく、ということを学びました。
rootはどのVPSにも存在する【デフォルトの入口】なので一番狙われやすく、自分でカスタマイズしたアカウントを作って管理者として使うことで、そのセキュリティの穴を塞ぐことができました。
adduser tomoya<自身のカスタマイズした名前を利用してください> ※新しい一般ユーザーの追加
usermod -aG sudo tomoya ※追加したユーザーに管理者権限の付与
groups tomoya ※確認。sudoという文字が結果に含まれていればOK- New password: → 新しいパスワードを入力（rootとは別の、新しいパスワードにしてください。画面には何も表示されませんが、ちゃんと入力されています）
- Retype new password: → 確認のため同じものをもう一度
- その後、フルネームや電話番号などを聞かれますが、すべて空欄のままEnterでスキップして問題ありません
- 最後に「Is the information correct? [Y/n]」と聞かれるので
Yを入力してEnter
ここで学んだ、今回の【鉄則】とも言える考え方があります。
1つのターミナルだけで作業を進めず、2つ目のターミナルを新しく開いて確認するということです。
2つ目で万が一うまくいかなくても、1つ目が生きていればそこから元に戻せます。
この「保険を残しながら進める」という感覚は、この後のすべてのステップで貫きました。
rsync --archive --chown=tomoya:tomoya ~/.ssh /home/tomoya ※rootの鍵を新しいユーザーにも使えるようにする
ssh -i 鍵ファイルのパス tomoya@サーバーのIPアドレス ※別ターミナルで接続確認
sudo whoami ※管理者権限（sudo）がちゃんと使えるか確認多少の緊張感はありつつも、ここまではスムーズに接続を確認できました。
rsync補足：「rootが持っているSSHの鍵情報（.sshフォルダ）を、そのままtomoyaのフォルダにコピーして、持ち主をtomoyaに変更する」というコマンドです。これで、今使っている同じ秘密鍵ファイルで、tomoyaとしてもログインできるようになります。
補足：#はroot＝管理者、$は一般ユーザーの印
rootでの直接ログインを禁止する
一般ユーザーでの接続を確認した後、いよいよrootの直接ログインを禁止するステップに進みます。
Tomoyaここで初めて、nanoという設定ファイルを編集するためのエディタを使いました。
sudo nano /etc/ssh/sshd_config ※nanoエディタ設定ファイルを開くCtrl + Wで検索モードになるので、PermitRootLoginを検索し該当項目をnoに書き換え、保存。その後、必ず文法チェックと反映を挟みます。
保存して閉じる
Ctrl + O（保存）→ そのままEnterCtrl + X（nanoを閉じる）
sudo sshd -t ※文法チェック
sudo systemctl restart ssh ※反映
Tomoya見慣れないエディタで多少の不安はありましたが、提案された手順通りに進めることで、初めてでも無事に完了させることができました。
AIにサポートしてもらうことで、新しい領域の体験をこんなにもスムーズに行えるのか、という感動です。
本来であれば、必要に迫られなければ避けてしまうようなことですし、行うにしても根気や責任が求められます。それでもエラーが起きると戸惑いや諦めに陥りやすく、修正するのも一苦労です。
しかしAIにサポートしてもらうことで、初心者でも成功体験を積みやすいと感じました。VPSに限らず、様々なことへの参入障壁が今、大幅に下がっているのだと実感します。
普通なら最初の段階で挫折してしまうくらい難しいことでも、サポートを受けながら進められる——大きな時代の変化を感じた瞬間でした。
パスワード認証を無効化し、鍵認証のみにする
ここではパスワードによる総当たり攻撃そのものを無効化するために、SSHキーのみでの認証方式に切り替えます。自分が保管している鍵ファイルでしかログインできなくなる、今回で一番効果の大きい一手のようです。
sudo nano /etc/ssh/sshd_configPasswordAuthenticationをnoに書き換え。
続いて鍵認証が有効になっているかも確認。PubkeyAuthentication yesとなっていればOKです
先程と同じように保存し文法チェックと反映、そして別ターミナルでの動作確認、という流れで行いました。
sudo sshd -t
sudo systemctl restart sshこのステップを終えた頃には、VPSでの作業の【基本の型】が見えてきました。
何かを変更したら、保存→文法チェック→反映→別ターミナルでの動作確認、を徹底する。
Tomoyaこれを守ることで、確実に変更を完了させられるのだと感じます。
とても丁寧なフローで、安心して進められました。
SSHのポート番号を変更する（今回一番のつまずき）
次に、デフォルトのポート（22番）から変更するステップです。ここで大きくつまずきました。
前のステップと同様にnanoから設定を行いましたが、今回は書き換えではなく、新しい行としてポートを追加し、保険を残しながら進めました。
Port 22
Port XXXXX ※自身の任意の番号(1024〜65535の範囲)保存してチェック、反映。
ポートの変更にあたっては、以前Connection timed outの原因になっていたXserver側のパケットフィルターも設定し直しました。今回は「SSH」ではなく「カスタム・単一・自分の指定したポート番号」で追加しています。
その後、別ターミナルで動作確認をしたところ、今度はConnection refusedというエラーになりました。
少しパニックになりましたが、原因をAIに教えてもらったところ、「Ubuntuには、SSHをsystemdのソケット機能で管理する仕組みがあり、これが有効になっていると、設定ファイルを書き換えただけでは反映されない」ということがわかりました。これも、デフォルトの仕組みだからこそ起きうるエラーでした。
sudo ss -tlnp | grep ssh ※待ち受けポートの確認
systemctl status ssh.socket ※ソケット機能の状態を確認待ち受けポートとソケットの状態を確認し、ソケットがactiveになっていることを確認したことで、原因はほぼ確信に変わりました。
sudo systemctl disable --now ssh.socket ※socketの停止
sudo systemctl enable --now ssh.service ※serviceの有効化
sudo systemctl restart ssh.service ※再読み込みソケットを無効化してSSHサービスに切り替え、反映させたあと、もう一度待ち受けポートを確認し、再度動作確認をしたところ、無事に新しいポートへの接続を確認できました。
その後、nanoで22番の行を削除して反映し、パケットフィルターからも22番のルールを削除して完了です。
途中、自分がどこかでコードの記入をミスったのかと少し焦りましたが、原因は自分のミスではなくシステムのデフォルトの仕組みにあった、というのは新しい気づきでした。
自分では思いつかないところに原因が隠れていることもあるのだと痛感します。AIがいなければ、あのままかなり長い間沼にハマっていただろうと思うと、今でも少し肝が冷えます。
ファイアウォールで不要なポートを閉じる
最後に、ファイアウォールを有効化し、SSH以外の余計なポートも塞いで、サーバー全体をシンプルに守ります。
Tomoyaここは地雷を踏む可能性もあったので、慎重に進めました。
sudo ufw allow XXXXX/tcp ※新しいSSHポートを「許可」に登録
sudo ufw show added ※設定内容を確認
sudo ufw enable ※ファイアウォールを有効化
sudo ufw status ※状態を確認自分が使っているSSHポートのみに限定して許可することで、セキュリティを一律に強固にできます。
Tomoyaステータスと、ポートが確実に設定されているかを何度も確かめながら有効化しました。
ここもスムーズに完了しましたが、失敗すると締め出しを食らうリスクがあったので、緊張しながらの作業でした。
最終確認：再起動しても大丈夫か
最後に、サーバーを再起動して、ここまでの設定がちゃんと引き継がれているかを確認しました。
再起動前の最終チェックリスト
再起動すると、今設定した内容がすべて「本当に有効な状態か」が試されます。念のため、今のウィンドウで以下を確認してから進めます。
sudo ufw status
sudo ss -tlnp | grep sshufw statusで新ポートのみ許可されているss -tlnpで新ポートのみ待ち受けている
この2つが確認できていれば大丈夫
sudo reboot ※再起動自信はありましたが、もしもの事を考えると原因を見直す必要も出てくるので、無事に新しいポートで繋がった時は、心底ほっとしました。
これで、今回のセキュリティ対策は完了です。
まとめ
一つひとつの作業は、決して難しいものではありませんでした。
それよりも「順番」と「保険を残しながら進める」という考え方の方が重要だったと感じています。
これは開発全般にも通じる学びでした。何かを変更した後は、構文のエラーチェックや型チェック、セキュリティやバグのチェックといったフローを通過して初めて公開に繋げられる。それらすべてを含めて「開発」と呼ぶのだな、と感じました。
初期設定は狙われやすい、という話はVPSに限らず色々な場面で共通しているように思います。かといって、よくわからないまま色々動かしてしまうのも怖い、と感じる人は多いはずです。ここをAIにサポートしてもらうことで、「何を動かして、何を動かさないか」を自分で選びながら設定していくことができます。フルに活用することで、自分の視野も広がり、できることもどんどん増えていくのだと思います。AIを使うことで、普段はできなかったことができるようになる——これは自分の成長にも繋がっていて、その恩恵をしっかり受けている実感があります。
次回は、Node.js編に進む予定です。お楽しみに。
コメント