Webサイト脆弱性診断ガイド

「SSLは設定した」「ファイアウォールも入れた」——そう思っていても、外部から見ると意外な穴が残っていることは珍しくありません。

情報システム担当者であれば、こんな不安を感じたことはないでしょうか。

• Webサーバーの設定、本当にベストプラクティスに沿っている？
• SSL証明書の期限切れに気づかず、ブラウザ警告が出ていないか？
• 開発時に開けたポートが、そのまま外部に公開されていないか？
• .env や .git が外部からアクセスできる状態になっていないか？

攻撃の典型的な流れ

放置した場合のリスク

IPintelの脆弱性診断は、Webサイトのセキュリティを5つの観点から総合的にチェックします。

HTTPセキュリティヘッダーは、いわば「ブラウザへの安全指示書」です。 サーバーからブラウザに「このページはこう扱ってほしい」と伝えることで、 XSS（クロスサイトスクリプティング）やクリックジャッキングなどの攻撃を防ぎます。

チェック項目

SSL/TLS証明書は暗号化通信の「鍵」です。 この鍵が古かったり期限切れだったりすると、通信の安全性が保証できません。

チェックポイント

• 証明書の有効期限 — 期限切れはブラウザに警告を表示させ、ユーザーの信頼を失う
• TLSバージョン — TLS 1.0/1.1は既に非推奨。TLS 1.2以上が必須
• 証明書チェーン — 中間証明書が正しく設定されているか
• ドメイン名の一致 — 証明書のCN/SANとアクセスURLが一致しているか

対処のポイント

# Let's Encrypt で無料SSL証明書を取得（certbot）
sudo certbot --nginx -d example.com -d www.example.com

# 自動更新の設定確認
sudo certbot renew --dry-run

# nginx で TLS 1.0/1.1 を無効化
# /etc/nginx/conf.d/ssl.conf
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;

ポートは建物でいう「ドア」です。 必要なドア（80/443番ポートなど）だけを開けて、 不要なドアは閉じておくのがセキュリティの基本です。

特に危険なポート

対処例

# firewalld: 許可するポートを限定
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload

# iptables: DBポートを外部からブロック
sudo iptables -A INPUT -p tcp --dport 3306 -j DROP
sudo iptables -A INPUT -p tcp --dport 5432 -j DROP
sudo iptables -A INPUT -p tcp --dport 6379 -j DROP

Webサーバー上の「ドットファイル」（先頭がピリオドで始まるファイル）が 外部からアクセスできないかをチェックします。 この診断は常時実行され、約20の重要パスを確認します。

なぜ重要か

ドットファイルには.env（認証情報）、.git（ソースコード）、.ssh（SSH鍵）など、本来公開されてはならない機密情報が含まれます。 nginxのlocation ~ /\.ルールでブロックするのが一般的ですが、 設定漏れがないか外部から確認することが重要です。

チェック対象

判定ロジック

対処例（nginx）

# すべてのドットファイルへのアクセスを一括拒否
location ~ /\. {
    deny all;
    return 404;
}

# .well-known（Let's Encryptなど）は許可する場合
location ~ /\.(?!well-known) {
    deny all;
    return 404;
}

Webサーバー上に「見えてはいけないファイル」が 公開されていないかをチェックします。 約100パスを探索し、ソフト404対策（カスタム404ページを正常なレスポンスと誤検知しない処理） も実装しています。

特に危険なファイル

対処例（nginx）

# 隠しファイル（.env, .git 等）へのアクセスを拒否
location ~ /\. {
    deny all;
    return 404;
}

# バックアップファイルへのアクセスを拒否
location ~* \.(bak|sql|tar\.gz|zip|log)$ {
    deny all;
    return 404;
}

対処例（Apache/.htaccess）

# 隠しファイルへのアクセスを拒否
<FilesMatch "^\.">
    Require all denied
</FilesMatch>

# 特定ファイルへのアクセスを拒否
<FilesMatch "\.(env|bak|sql|log)$">
    Require all denied
</FilesMatch>

診断結果は100点満点の減点方式で、 A〜Fの6段階グレードで評価されます。

グレード基準

減点の仕組み

Critical: .env ファイルが公開されている

データベースパスワードやAPIキーが外部から閲覧可能な状態です。

# nginx: .envファイルへのアクセスを拒否
location = /.env {
    deny all;
    return 404;
}

# Apache: .htaccess に追記
<Files ".env">
    Require all denied
</Files>

Critical: データベースポートが外部公開

MySQL(3306)、PostgreSQL(5432)、Redis(6379)等が外部からアクセス可能です。

# ファイアウォールでDBポートを遮断
sudo firewall-cmd --permanent --remove-port=3306/tcp
sudo firewall-cmd --permanent --remove-port=5432/tcp
sudo firewall-cmd --permanent --remove-port=6379/tcp
sudo firewall-cmd --reload

# Docker の場合: ports ではなく expose を使う
# docker-compose.yml
services:
  db:
    # ports: ["3306:3306"]  ← これは外部公開される
    expose: ["3306"]         # ← コンテナ間のみ

High: HSTS が設定されていない

HTTPS接続が強制されず、HTTP経由のアクセスで中間者攻撃のリスクがあります。

# nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Medium: Content-Security-Policy が未設定

XSS攻撃に対するブラウザ側の防御が有効になっていません。段階的に導入できます。

# まずは Report-Only モードで影響を確認
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;

# 問題なければ本番適用
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';" always;

IPintelの脆弱性診断は、HTTPヘッダー・SSL/TLS・ポート・隠しファイル・ディレクトリの 5カテゴリを一括チェックし、A〜Fのグレードで総合評価します。

自分が管理するWebサイトのURLを入力するだけで、外部からどう見えているかを確認できます。