はじめに

「うちのような規模のサービスは、攻撃者に狙われないだろう」。そう考えている方は少なくありません。しかし実際には、インターネットに公開されたWebサービスは、規模や知名度に関係なく日常的に攻撃を受けています。

先日、当社がセキュリティ対策と運用保守を担当して調査したクライアント企業様のWebサービスに、過去短時間に大量の不正アクセスを浴びせる「総当たり型」のサイバー攻撃が届いておりました。

結論からお伝えすると、侵入や情報漏えいは一切ありませんでした。本記事では、この実例をもとに次の内容をわかりやすく解説させていただきます。

  • どんな相手が、どんな攻撃を仕掛けてきたのか
  • 何重もの防御で、どうやって止めたのか
  • 攻撃の手口から学ぶ「さらに防御を強くするポイント」
  • 今日から確認できるセキュリティ対策チェックリスト

※保護と防御の仕組みの秘匿のため、サービス名、日時、アクセス数、防御設定の詳細などは伏せ、一部の表現をぼかしています。

事件の概要：夜間に届いた1通のアラート

最初に異変を知らせたのは、Webサービスに組み込んでいた攻撃検知の自動通知でした。サーバーに不正な命令を実行させようとするアクセスを検知した、という知らせです。

すぐにアクセス記録（ログ）を調べたところ、状況は次のとおりでした。

項目内容
攻撃の形短時間に大量のアクセスを送りつける総当たり型
攻撃の規模数分間で数千回規模
狙われた場所公開Webサイト、API、テスト環境
侵入・情報漏えいなし

攻撃してきたのは「人」ではなく「自動プログラム」

攻撃元を調べると、次のような特徴がありました。

  • 海外のクラウドサーバーから送信：海外のデータセンターで借りられたクラウドサーバーでした。クラウドは誰でも契約できるため、攻撃の拠点として悪用されることがあります。
  • 有名なロボットになりすまし：1回ごとに名乗りを変え、検索エンジンやAIサービスのロボットになりすましていました。もちろん本物ではありません。
  • 無差別型：特定の会社を狙ったというより、インターネット上のサイトを片っ端から試して回る「自動スキャナ」でした。

たとえるなら、街中のビルのドアを片っ端から回して、鍵のかけ忘れを探している泥棒です。狙われる理由は「そこにサイトがあるから」。規模の大小は関係ありません。

どんな攻撃が来たのか

アクセスの中身を分類すると、次のような攻撃が含まれていました（★の数は、全体に占める多さの目安です）。

攻撃の種類平たく言うと多さ
秘密ファイルの探索パスワードなどを書いた設定ファイルが、うっかり公開されていないか探す★★★
鍵ファイルの探索クラウドサービスやサーバーにログインするための「合鍵」ファイルを探す★★★
開発ツールの脆弱性の悪用開発用ツールの既知の欠陥を突いて、サーバー内のファイルを読もうとする★★☆
コマンド実行（コマンドインジェクション）入力欄にサーバーへの命令を紛れ込ませる★☆☆
管理画面の探索よく使われるCMSなどの管理画面や設定ファイルを探す★☆☆
フォルダをさかのぼる読み出し「1つ上の階層へ」を繰り返し、非公開の場所に抜けようとする★☆☆
SQLインジェクション・XSSデータベースやブラウザを誤作動させる文字列を送る★☆☆

注目したいのは、攻撃の大半が「秘密のファイルがうっかり置かれていないか」を探すものだったことです。攻撃者の狙いは、パスワードやクラウドの鍵です。これを盗めば、サーバーを勝手に使って仮想通貨を採掘したり、データを抜き出したりできるからです。

同じ攻撃を受けた際にどうやって防いだのか：5つの関所

Webサービスをビルにたとえると、攻撃は正面ゲートから奥の窓口まで、何段階もの関所を通り抜ける必要があります。今回の攻撃は、次の5つの関所のいずれかで止まりました。

関所たとえ実際の仕組み
① 入口の警備員凶器を持った人をゲートで止めるクラウドのWAF（Webアプリケーションファイアウォール）
② 関係者フロアの鍵社員証がないと入れないテスト環境の認証
③ 受付の手荷物検査警備員の目をすり抜けた危険物を見つけるアプリケーション内蔵のWAF
④ 窓口の整理券同じ人が何度も並び直したら待ってもらうレート制限（回数制限）
⑤ そもそも無い部屋金庫室がなければ盗めない秘密情報を公開領域に置かない設計

トップページなど、もともと誰でも見られるページが表示されたアクセスもありましたが、公開している情報が見えただけなので問題はありません。

① 入口の警備員：クラウドのWAF

サーバーに届く前に、クラウド側のWAFがアクセスの中身を検査し、明らかに危険な文字列を含むアクセスを門前払いしました。

ポイントはサーバーに届く前に止めることです。サーバーに負荷がかからず、万が一アプリケーションに欠陥があっても、攻撃がそこまで到達しません。

② 関係者フロアの鍵：テスト環境の認証

開発中の機能を試す「テスト環境」は、本番より防御が手薄になりがちで、攻撃者にとって格好の入口です。今回のサービスではテスト環境を関係者しか開けない設定にしていたため、攻撃は中身を見られずに終わりました。

③ 受付の手荷物検査：アプリ内蔵のWAF

入口の検査だけで、すべての攻撃を止められるとは限りません。今回も入口をすり抜けた一部の攻撃がありましたが、アプリケーション自身に組み込んだ2段目の検査がそれを見つけて拒否し、同時に管理者へ自動で通知しました。冒頭のアラートは、この関所から届いたものです。

「1つの防御が破られても、次の防御で止める」。これを多層防御と呼び、セキュリティ対策の基本的な考え方として存在します。

④ 窓口の整理券：レート制限

同じ相手から一定の回数を超えるアクセスが続くと、それ以降は中身を確認する前にお断りする仕組みです。今回の攻撃も途中から次々と断られていました。総当たり型の攻撃に対して、とても効果的です。

⑤ そもそも無い部屋：秘密情報を置かない設計

実は、最も多くの攻撃を無力化したのはこの関所です。

このサービスでは、パスワードや鍵のファイルを外部から見える場所に一切置いていません。攻撃者がどんな名前で探しても、「そのページは存在しません」と返るだけです。

「盗まれて困るものは、そもそも置かない」。地味ですが、最も確実な対策です。

「侵入されていない」をどう確かめたか

攻撃を検知しても、「本当に防げたのか」を確かめなければ安心はできません。今回は次の4つの観点で確認し、侵入はなかったと判断しました。

  1. 秘密ファイルを1件も渡していない：鍵やパスワードを求めたアクセスは、すべて「拒否」または「存在しない」で終わっていた
  2. 攻撃が成功した痕跡がない：攻撃が成功した場合に現れるはずの痕跡が、どの記録にも見つからなかった
  3. 命令を実行する仕組み自体がない：プログラムを確認し、外部からの入力でサーバーの命令を動かす処理がないことを確かめた
  4. サーバーに異常がない：攻撃の最中もエラーは発生せず、応答も通常どおりだった

アラートが鳴ったときに慌ててサーバーを止めるのではなく、記録にもとづいて冷静に被害の有無を判定する。これもセキュリティ運用の大切な仕事です。

攻撃の手口から学ぶ、さらに防御を強くするポイント

今回の攻撃は防げましたが、攻撃の手口を分析すると、より巧妙な攻撃にも備えるための強化ポイントが見えてきます。多くのWebサービスで見落とされがちな観点をご紹介します。

1. アクセス元の判定を「偽装できない方法」で行う

自動ブロックや回数制限は、「どこからのアクセスか」をもとに動きます。しかし中継機器を経由する構成では、作り方によってはアクセス元の情報を攻撃者が偽ることができ、ブロックをすり抜けられるおそれがあります。信頼できる情報だけをもとに判定しているか、一度確認しておきましょう。

2. 秘密ファイル探しは「入口」で止める

存在しないファイルへのアクセスには実害こそありませんが、サーバーに無駄な負荷がかかり、記録の中に埋もれてしまいます。正規の利用者がまず触らない場所へのアクセスは、入口で遮断して記録するのが効果的です。

3. テスト環境にも本番と同じ水準の防御

テスト環境は「本番ではないから」と後回しにされがちです。しかし攻撃者から見れば、本番と同じ価値のある入口です。認証だけでなく、入口の検査も本番と同じ水準でそろえておくことをおすすめします。

4. 防御ルールの「抜け」を定期的に点検する

WAFは導入して終わりではありません。攻撃の手口は日々変わるため、攻撃の種類ごとに対応するルールがそろっているかを定期的に見直す必要があります。

5. 設定は「コード」で管理し、本番とのズレをなくす

セキュリティ設定を管理画面から手作業で変えていると、手元の設定ファイルと本番の設定が少しずつズレていきます。ズレに気づかないまま設定を入れ直すと、大事な制限が消えてしまうことがあります。設定をコードとして管理し、自動テストでズレを検知する仕組みが有効です。

6. 回数制限は「厳しすぎず、緩すぎず」

回数制限は、厳しすぎれば正規のお客様を締め出し、緩すぎれば攻撃を見逃します。会社や携帯電話の回線では、多くの人が同じアドレスを共有していることもあります。実際のアクセス状況を分析し、サービスごとに最適な値を決めて見直し続けることが大切です。

今日からできる：Webサービスのセキュリティ対策チェックリスト

自社のWebサービスについて、次の項目を確認してみてください。

  • サーバーの前段にWAFを設置している
  • アプリケーション側にも入力チェックの仕組みがある（多層防御）
  • パスワードや鍵のファイルを、公開領域に置いていない
  • テスト環境・開発環境にも、認証とWAFを設定している
  • 同じ相手からの大量アクセスを制限している
  • 攻撃を検知したら、担当者に自動で通知が届く
  • アクセスログを保存し、いつでも調べられる状態にしている
  • アクセス元の判定を、偽装できない方法で行っている
  • WAFのルールや設定を定期的に見直している
  • 攻撃を受けたときに「被害の有無」を判定できる担当者と手順がある

1つでも当てはまらない項目があれば、見直しをおすすめします。

まとめ

  • インターネットに公開したWebサービスは、規模に関係なく自動化された攻撃を日常的に受けている
  • 今回は、入口のWAF・認証・アプリ内の検査・回数制限・「秘密を置かない設計」という5つの関所で、総当たり型の攻撃をすべて防いだ
  • 防げた場合でも、攻撃の手口を分析すると次の攻撃に備えた強化ポイントが見つかる
  • セキュリティ対策は「導入して終わり」ではなく、監視・調査・改善を回し続ける運用こそが本番

セキュリティ対策のご相談は、株式会社NUP WHITEへ

「自社のサービスは大丈夫だろうか」「アラートが届いても、何を調べればいいかわからない」「WAFは入れたものの、設定が適切か自信がない」 当社の情報セキュリティ対策運用保守は、サーベイ&システム構築、運用保守を一括提供するセキュリティソリューションです。

  • セキュリティサーベイ：システム構成やログを診断して脆弱性とリスクを洗い出し、優先順位を付けた改善計画をご提案します
  • システム構築：WAFの設計・導入、認証やアクセス制御の強化、ログ監視とアラート通知の仕組みづくりを行います
  • 運用保守：攻撃アラートの調査、被害の有無の判定とご報告、防御ルールの継続的な見直しまで伴走します

本記事でご紹介したような攻撃の調査・防御・改善を、御社のWebサービスでも実施いたします。

セキュリティ対策について相談する →