VPSセキュリティ強化ガイド
見落としがちな6つの設定
SSHの鍵認証やファイアウォールは設定済み――でも、それだけで安全とは限りません。
この記事では、VPS運用で見落としがちなセキュリティ設定を実際のサーバーで発見・修正した経験をもとに解説します。
こんな人向けの記事です
- VPSの基本的なSSH設定は完了している
- Docker + Nginx + UFW の構成でWebサービスを公開している
- セキュリティ対策が十分か不安がある
- サーバーのセキュリティ監査をしたい
セキュリティ監査の進め方
セキュリティ対策は「設定して終わり」ではなく、定期的な監査が重要です。以下のコマンドで現状を確認しましょう。
# 未適用のアップデートを確認
apt list --upgradable 2>/dev/null | wc -l
# SSHの設定を確認
grep -E "^[^#]" /etc/ssh/sshd_config
# 開いているポートを確認
sudo ss -tlnp
# UFWの状態を確認
sudo ufw status verbose
# Fail2Banの状態を確認
sudo fail2ban-client status sshd
# シェルアクセス可能なユーザーを確認
grep -E "/bin/(bash|sh|zsh)" /etc/passwd
# カーネルのセキュリティパラメータを確認
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.all.send_redirects問題1: セキュリティアップデートの未適用
何が問題か
OSやパッケージのセキュリティアップデートが適用されていないと、既知の脆弱性を突かれるリスクがあります。特にlibc6やlibgnutls30、openssh-serverなどの重要パッケージが古いままだと危険です。
確認方法
# アップデート可能なパッケージの一覧
apt list --upgradable
# セキュリティアップデートのみ確認
apt list --upgradable 2>/dev/null | grep -i security対処方法
sudo apt update
sudo apt upgrade -y注意
カーネルのアップデートが含まれる場合、再起動が必要なことがあります。needrestart コマンドで確認できます。
問題2: 自動セキュリティ更新の未設定
何が問題か
手動でアップデートするだけでは、セキュリティパッチの適用が遅れがちになります。unattended-upgradesを導入することで、セキュリティアップデートを自動的に適用できます。
確認方法
# インストール状況を確認
dpkg -l | grep unattended-upgrades
# サービスの状態を確認
systemctl is-active unattended-upgrades対処方法
# インストール
sudo apt install unattended-upgrades apt-listchanges -y自動更新の設定ファイルを作成します。
# /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Origins-Pattern {
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Debian,codename=${distro_codename}-security,label=Debian-Security";
};
Unattended-Upgrade::AutoFixInterruptedDpkg "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";# 有効化
sudo systemctl enable unattended-upgrades
sudo systemctl start unattended-upgradesAutomatic-Reboot を "false" にしておくと、カーネルアップデート時に勝手に再起動されません。再起動のタイミングは手動で管理できます。
問題3: DockerポートがUFWをバイパスして外部公開
何が問題か
これは最も見落としやすく、最も危険な問題です。
Dockerはコンテナのポート公開時にiptablesルールを直接操作します。つまり、UFWで制限していてもDockerのポートは素通りしてしまいます。
例えば、以下のようなdocker-compose設定をしていると：
# docker-compose.yml（危険な例）
ports:
- "8080:8000" # 0.0.0.0:8080 で公開される
- "3000:3000" # 0.0.0.0:3000 で公開されるUFWで8080と3000を許可していなくても、外部から直接アクセスできてしまいます。Nginxのリバースプロキシを経由せずに、アプリケーションに直接到達できるということです。
確認方法
# Dockerが公開しているポートを確認
docker ps --format "{{.Names}}: {{.Ports}}"
# iptablesのDOCKERチェーンを確認
sudo iptables -L DOCKER -n
# 0.0.0.0 でリッスンしているポートを確認
sudo ss -tlnp | grep "0.0.0.0"対処方法
ポートバインドを 127.0.0.1（localhost）に制限します。
# docker-compose.yml（安全な例）
ports:
- "127.0.0.1:8080:8000" # localhost のみ
- "127.0.0.1:3000:3000" # localhost のみ変更後、コンテナを再起動します。
docker compose down && docker compose up -d
# 確認: 127.0.0.1 にバインドされていることを確認
sudo ss -tlnp | grep -E "(3000|8080)"
# LISTEN 127.0.0.1:8080 ... （OK）
# LISTEN 127.0.0.1:3000 ... （OK）重要
この設定変更後も、Nginx経由のアクセス（80/443ポート）は正常に動作します。Nginxは同じサーバー上で動いているため、127.0.0.1のポートに問題なく接続できます。
問題4: カーネルパラメータの未設定
何が問題か
Linuxカーネルにはネットワークセキュリティに関するパラメータがあり、デフォルトでは必ずしも安全な値になっていません。
| パラメータ | 危険な値 | 安全な値 | 効果 |
|---|---|---|---|
rp_filter |
0 | 1 | IPスプーフィング防止 |
accept_redirects |
1 | 0 | ICMP リダイレクト攻撃防止 |
send_redirects |
1 | 0 | MITM攻撃の防止 |
log_martians |
0 | 1 | 不審なパケットのログ記録 |
accept_source_route |
1 | 0 | ソースルーティング攻撃の防止 |
対処方法
設定ファイルを作成して永続化します。
# /etc/sysctl.d/99-security.conf
# IPスプーフィング防止
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# ICMPリダイレクト無効化
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
# SYN flood対策
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
# ブロードキャストping無視
net.ipv4.icmp_echo_ignore_broadcasts = 1
# 不審なパケットをログ
net.ipv4.conf.all.log_martians = 1
# ソースルーティング無効化
net.ipv4.conf.all.accept_source_route = 0# 設定を適用
sudo sysctl -p /etc/sysctl.d/99-security.conf問題5: X11Forwardingの有効化
何が問題か
X11Forwardingは、SSH経由でGUIアプリケーションを転送する機能です。VPSサーバーではGUIを使わないため、不要な攻撃面を増やすだけです。
対処方法
# /etc/ssh/sshd_config の該当行を変更
X11Forwarding no
# SSHを再読み込み
sudo systemctl reload sshd問題6: Nginxのバージョン情報露出
何が問題か
デフォルトでは、NginxのHTTPレスポンスヘッダーにバージョン情報が含まれます。バージョンが特定されると、既知の脆弱性を狙った攻撃を受けるリスクが高まります。
対処方法
# /etc/nginx/nginx.conf（httpブロック内）
server_tokens off;
# テストして再読み込み
sudo nginx -t && sudo systemctl reload nginxセキュリティチェックリスト
| カテゴリ | チェック項目 | 確認コマンド |
|---|---|---|
| アップデート | 未適用のセキュリティパッチがないか | apt list --upgradable |
| アップデート | 自動更新が有効か | systemctl is-active unattended-upgrades |
| SSH | パスワード認証が無効か | grep PasswordAuthentication /etc/ssh/sshd_config |
| ファイアウォール | UFWが有効か | sudo ufw status |
| Fail2Ban | Fail2Banが稼働しているか | sudo fail2ban-client status sshd |
| Docker | ポートが127.0.0.1にバインドされているか | docker ps --format "{{.Ports}}" |
| カーネル | rp_filterが有効か | sysctl net.ipv4.conf.all.rp_filter |
| SSL | 証明書の有効期限 | sudo certbot certificates |
まとめ
| 問題 | リスク | 対処 |
|---|---|---|
| セキュリティアップデート未適用 | 既知の脆弱性を突かれる | apt upgrade + unattended-upgrades |
| DockerポートがUFWバイパス | Nginxを迂回して直接アクセスされる | 127.0.0.1: でバインド |
| カーネルパラメータ未設定 | IPスプーフィング・MITM攻撃 | /etc/sysctl.d/99-security.conf |
| X11Forwarding有効 | 不要な攻撃面 | sshd_configで無効化 |
| Nginxバージョン露出 | 脆弱性の特定を助ける | server_tokens off |
セキュリティは一度設定して終わりではありません。定期的にチェックリストを使って監査を行い、新しい脆弱性情報にも目を配りましょう。