導入
さくらのVPSにモダンな商用Linuxディストリビューションである「AlmaLinux 9」を導入し、WordPressを刷新してからしばらくが経ちました。
共有サーバーと違い、VPSは「root権限が自分にある＝自由度が高い」反面、「インフラのセキュリティとサーバー容量の保守はすべて自己責任」というエンジニアとしての腕が試される環境です。
今回は、24時間執拗に送りつけられてくる海外スパムボットの総当たり攻撃（ブルートフォースアタック）をOSの入り口（firewalld）で完全にシャットアウトする「SSH要塞化パッチ」の実装と、将来のサーバーダウン（500エラー）を防ぐための「ストレージ容量のデバッグ」を行ったので、その全コマンドと手順を備忘録としてまとめます。
ステップ1：22番ポートの閉鎖とSSHの隠蔽（要塞化）
サーバーを開設した初期状態のままだと、SSHの接続ポートはデフォルトの「22番」になっています。ここには世界中のボットから秒間何十回もの不正アクセス試行が届き、CPUリソースの無駄遣いやログの肥大化の原因になります。
そこで、ポート番号を独自の5桁（例: 54321、実際には別のポートにしています）に変更し、Windowsのデスクトップからバッチファイルをダブルクリックするだけで一発ログインできる環境を構築しました。
🛠️ 1. firewalld（ファイアウォール）の新ポート開放
現在の22番接続を維持したまま（作業中に締め出されるバグを防ぐためのセーフティネット）、新しいポートを通すパッチを当てます。
サーバ内にて以下のコマンドを実行。
# 独自の5桁ポート（例: 54321）を恒久的に許可
sudo firewall-cmd --permanent --add-port=54321/tcp
sudo firewall-cmd --reload
# portsの欄に指定した番号があるか確認
sudo firewall-cmd --list-all
🛠️ 2. SSH設定ファイル（sshd_config）の書き換え
サーバ内にて以下のコマンドを実行。
sudo vi /etc/ssh/sshd_config
ファイル内の Port 22 の下（または最下部）に Port 54321 を追記し、SSHサービスを再起動します。
エディタで以下の設定を追記。
Port 22
Port 54321
サーバ内にて以下のコマンドを実行。
# 設定を再起動して反映
sudo systemctl restart sshd
この設定をした後、設定ミスによる接続ブロックを防止するため、今サーバ内に接続するコマンドは閉じずに後続の確認を行います。
🛠️ 3. Windows側にダブルクリック起動用バッチを作成
Windows側で alma-connect.bat というファイルを作成し、以下のコードを仕込みます。これにより、秘密鍵（Ed25519）を明示しなくても、Windowsの自動探索機能と連動してスマートに一発ログインできるようカプセル化しました。
自端末で以下を作成し、alma-connect.batという名称で保存
@echo off
ssh -p 54321 -i "~\.ssh\id_ed25519" alma@【サーバーIP】
pause
新ポートでのログイン成功を確認後、古い22番ポートの閉鎖パッチを適用してエントランスを完全に要塞化しました。
サーバ内に接続しているターミナルから以下を実施
# ファイアウォールから標準の22番（ssh）の許可を恒久的に削除
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload
これ以降、22番ポートへの攻撃はOSのカーネル手前でパケットごとすべて消滅するようになります。
実行後、alma-connect.bat を実行し、サーバ内に接続できていればOK。
失敗している場合は、sshd_config Port 22 を復旧させます。
ステップ2：パスワード認証の完全禁止（鍵認証のみに制限）
ポートを変更しても、万が一ポートスキャンで番号を割り出された場合を想定し、「パスワード入力によるログイン」という裏口そのものをシステム的に封鎖します。
💻 パスワード拒否パッチの適用
サーバ内にて以下コマンドを実行
sudo vi /etc/ssh/sshd_config
ファイル内の該当項目を no に書き換えます。
エディタにて以下の編集を行い保存
PasswordAuthentication no
タイプミスによるSSH起動不能バグを防ぐため、構文チェック（テスト）を挟んでから適用するのがエンジニアの鉄則です。
# 構文チェック（何も出なければ正常）
sudo sshd -t
# SSHサービスを再起動
sudo systemctl restart sshd
🧪 門前払いデバッグ（検証結果）
Windows側から、あえて鍵認証をオフにしてパスワードだけで接続を試みるデバッグコマンドを実行します。
自端末で以下コマンドを実行
ssh -o PubkeyAuthentication=no -p 54321 alma@【サーバーIP】
結果：
PS C:\Users\[ユーザ名]> ssh -o PubkeyAuthentication=no -p 54321 alma@xxx.xxx.xxx.xxx
alma@xxx.xxx.xxx.xxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).「publickey,gssapi-keyex,gssapi-with-mic」にPW認証がなくなりました。
パスワード入力欄すら表示されず、サーバー側から即座に「門前払い（アクセス拒否）」されています。これで、物理的に秘密鍵を所有している端末以外からは地球上の誰もログインできない鉄壁のコンフィグが確定しました。
ステップ3：ストレージデータ枯渇リスクのデバッグ
サーバーの要塞化が完了したため、次は運用保守の最重要項目である「ディスク容量（データ枯渇リスク）」の健康診断（スキャン）を行いました。 長年WordPressを運用していると、アクセス解析（WP Statistics）の過去ログやシステムログ（/var/log）が勝手に肥大化し、ディスクを食いつぶしてMySQLがクラッシュする原因になるためです。
🔍 1. マクロ視点でのディスク使用量確認
現在のディスクがどれくらい逼迫しているかを調べます。
df -h
結果： 全体の容量 99GB に対し、使用量はわずか 2.2GB（全体の3%）。残り92GBという、現時点では信じられないほど健全で超安全圏なバッファが確保されていることが判明しました。初期構築時にOSのパッケージを最小構成（ミニマル）でデプロイした恩恵がここに現れています。
🔍 2. ミドルウェア・アプリケーション層（/var）のミクロ分析
将来的に容量を圧迫する「隠れたノイズ」の予兆を検知するため、データが蓄積する /var ディレクトリの内訳をさらに深掘り（デバッグ）しました。
sudo du -sh /var/* 2>/dev/null | sort -rh
デバッグ結果（内訳）：
408M /var/www：WordPress本体とアップロード画像。ゴミファイルもなく非常にコンパクト。258M /var/lib：MySQLデータベース実体。WP Statisticsのログ肥大化（バグ）も起きておらず健全。101M /var/log：システムおよびWebサーバーのログ。Linuxの自動ログ破棄スケジュール（logrotate）が完璧に機能している証拠。
すべてのセクターをスキャンした結果、「今すぐ削除しなければいけない無駄なデータは『ゼロ』である」 という完璧な結果に。未来の肥大化の犯人候補すら見当たらない、非常に美しいシステム状態であることが証明されました。
まとめ：ホワイトボックスだからこそ得られる「安心感」
今回のインフラ刷新とセキュリティ・容量デバッグを経て、以下のような「最強の個人ブログ運用環境」が完成しました。
- SELinuxは「Disabled（無効）」にすることで余計なエラーの壁と戦うコストを永久にゼロにし、執筆に100%集中できる環境を確保。
- その代わり、「SSHの5桁ポート隠蔽」と「パスワード認証の完全拒否」によって、OS層の防御力を最高値まで要塞化。
- ディスク容量の内訳を自らコマンドで暴いた（ホワイトボックス化した）ことで、「今後数年はメンテナンスフリーで記事を量産しても絶対にクラッシュしない」という絶対的な安心感を獲得。
ブラックボックスなプラグインや設定に頼りすぎず、LinuxカーネルやOSの設定ファイルの挙動を自分で100%コントロールする楽しさこそ、VPS運用の醍醐味だと改めて実感しました。
運用しているサーバがある方は、是非この機会にAlmaLinuxやRHEL系VPSのセキュリティ設定と容量の肥大化などのチェックをしてみてはいかがでしょうか。
