インシデント発生！その時、お前の「初動」が運命を分ける
いいか、よく聞け。セキュリティの世界で一番怖いのは「攻撃を受けている」ことじゃない。「攻撃を受けていることに気づかず、現場を汚染し続けること」だ。
OWASP Top 10の脆弱性が突かれたとき、焦ってサーバーを再起動したり、ログを消したりするエンジニアが後を絶たない。それは犯人に「証拠隠滅のチャンス」を与え、お前自身の首を絞める行為だ。今日は、プロとして最低限守るべき「証拠保全」と、同じ過ちを二度と繰り返さないための「防御実装」について、現場の作法を叩き込んでやる。
—
1. 現場の鉄則：証拠保全（フォレンジック）の優先順位
攻撃を検知した瞬間、お前の脳内優先順位を以下のように書き換えろ。
1. 揮発性データの回収（メモリダンプ）
2. ログの隔離とバックアップ
3. ネットワークトラフィックの保存（PCAP）
ここでの合言葉は「Chain of Custody（証拠の連鎖）」だ。誰が、いつ、どのデータを取得し、どう管理したかを記録しろ。これがなきゃ、法廷やクライアントへの報告で「その証拠は改ざんされてないと言い切れるか？」と突っ込まれて終わりだ。
具体的な初動手順
- メモリダンプ:
LiMEやVolatilityを使う。OSを再起動するな。メモリ上の通信コネクションや、注入された悪意あるプロセスを掴む唯一のチャンスだ。 - ログ抽出:
/var/log/配下をそのままコピーするな。sha256sumでハッシュ値を計算し、別メディアへ保存しろ。 - 権限の固定: 調査中は対象サーバーへのSSHログインを制限し、調査用アカウントのみに限定しろ。
—
2. 脆弱性の盲点：SQLインジェクションを例にした防御戦略
OWASP Top 10の常連、SQLインジェクション。いまだに「エスケープすれば大丈夫」と思っているやつはいないよな？ 現代の防御は、「DBドライバへのパラメータ受け渡し」が全てだ。
不適切な実装（絶対やるな）
// 最悪な例：ユーザー入力をそのまま文字列結合
$sql = “SELECT FROM users WHERE username = ‘” . $_POST[‘user’] . “‘”;
$db->query($sql);
セキュアな実装（PDO/プレースホルダ）
// 正しい実装：クエリとデータを分離し、DBエンジン側で解釈させる
$stmt = $pdo->prepare(‘SELECT FROM users WHERE username = :username’);
$stmt->execute([‘username’ => $_POST[‘user’]]);
$user = $stmt->fetch();
これだけで、攻撃者がどれだけ巧妙なSQLクエリを送り込もうが、ただの「文字列」としてしか扱われない。これが防御の基本だ。
—
3. インフラ・レイヤーでの鉄壁（Nginx WAF設定）
アプリの修正は時間がかかる。だが、インフラ側の設定なら即座に反映できる。Nginxの mod_security やクラウドWAFのルール設定で、攻撃の入り口を塞げ。
Nginxでの基本的なレート制限（DoS/ブルートフォース対策）
nginx.conf に以下の設定を入れ、異常なリクエストを叩き落とせ。
IPごとのリクエストレートを制限（1秒間に10回まで）
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
server {
location /login {
limit_req zone=one burst=5 nodelay;
# ここで特定のUAや不正なリクエストパターンを拒否
if ($http_user_agent ~ (sqlmap|nikto|nmap)) {
return 403;
}
}
}
—
4. 最後に：エンジニアとしてのマインドセット
技術は日々進化するが、攻撃者の動機は変わらない。「楽に、金になる、あるいは目立つ」ことだ。お前たちが作るコード一つ一つが、誰かの生活や企業の信頼を守る盾になる。
インシデントは起きてからどう動くかも大事だが、「ログが出力されていない」「ログがローテートされて消えていた」という初歩的なミスが、実は一番の致命傷になる。
- ログは外部サーバー（SIEM等）へリアルタイム転送しろ。
- 権限管理（IAM）は「最小権限の原則」を徹底しろ。
- 疑わしきは調査しろ。
現場で「面倒くさい」と感じる作業こそが、最強のセキュリティになる。それがわかれば、今日からお前も一流のエンジニアだ。
もし何かあったら、またここへ戻ってこい。背中は俺が守ってやる。だが、まずはコードを磨け。それが一番の防波堤だ。
コメント