Webサーバーへの攻撃といえば、大量のパケットを送りつけて帯域幅を埋め尽くすDDoS攻撃をイメージする方が多いでしょう。しかし、ごくわずかなトラフィックでApacheなどのWebサーバーを完全にダウンさせる攻撃手法が存在します。それが「Slowloris（スローロリス）」です。

Slowlorisは「low and slow（低速で目立たない）」という特性から、従来のファイアウォールや侵入検知システムをすり抜けやすく、攻撃中はログにも記録されないため、被害に気づきにくいという特徴を持ちます。本記事では、Slowlorisの仕組みから検出方法、Apacheの具体的な設定対策、WAF・CDNによる防御まで、実務に役立つ情報を体系的に解説します。

Slowlorisとは？概要と特徴

Slowlorisとは、Webサーバーに対して不完全なHTTPリクエストを大量に送り続け、サーバーの接続リソースを枯渇させるDoS/DDoS攻撃の手法です。OSIモデルのレイヤー7（アプリケーション層）を標的とします。

名称は動きの遅い霊長類「スローロリス（slow loris）」に由来しており、その名のとおりゆっくりと、しかし確実にサーバーを機能不全に追い込む点が特徴です。2000年代半ば、ハッカー「RSnake」がHTTPプロトコルの特性に気づいたことが起源とされ、攻撃ツールとして広まったのは2009年頃です。

少ないリソースで実行可能

大規模なボットネットは不要で、1台のPCと少ない帯域幅で攻撃できます。一般的なDDoS攻撃が数万件のリクエストを必要とするのに対し、Slowlorisは数百件程度の接続でWebサーバーをダウンさせることも可能です。

検知が非常に困難

送信するトラフィックが少なく、正当なHTTPリクエストに見えるよう設計されているため、従来のファイアウォールや帯域幅監視では検出しにくいです。また、HTTPリクエストが完了しない限りサーバーのログに記録されないため、攻撃中はログエントリが残りません。

攻撃が長期間続く可能性

接続をタイムアウトさせないよう断続的にデータを送り続けることで、検知されなければ無期限に攻撃を継続できます。

Apacheに特に深刻な影響

スレッドベースで接続を処理するApacheは、接続ごとにスレッドを割り当てる仕組みのため、Slowlorisの影響を特に受けやすいです。

攻撃の仕組み・4ステップで理解する

Slowlorisがどのようにサーバーをダウンさせるのか、4つのステップで解説します。

【Step 1】不完全なHTTPリクエストで複数のTCP接続を開く

攻撃者は複数のHTTP GETリクエストを送信しますが、これらは意図的に「未完成」な状態にされています。通常のHTTPリクエストはヘッダーの末尾に「\r\n\r\n」（空行）を送ることで完了を示しますが、Slowlorisはこれを送らず、ヘッダーを途中で止めた状態にします。

【Step 2】サーバーはリクエスト完了を待ち続ける

WebサーバーはHTTPリクエストが完成するまで接続を維持します。不完全なリクエストを受け取ったサーバーは「リクエストの続きが来るはずだ」と判断し、接続を開いたまま待機状態に入ります。スレッドベースのApacheでは、この接続ごとにスレッドを占有します。

【Step 3】タイムアウト直前に断片的なヘッダーを送り続ける

Slowlorisは接続がタイムアウトして切断されないよう、一定間隔で意味のないHTTPヘッダーの断片（例：X-a: b\r\n）を送り続けます。これにより接続は「生きている」状態を保ちながら、永遠に完成しないリクエストとして維持されます。

【Step 4】接続スロットが枯渇し、正規ユーザーが接続不能になる

大量の「半開き接続」がサーバーの接続スロット・スレッドをすべて占有すると、新たな正規のリクエストを処理できなくなります。この状態がサービス拒否（DoS）です。サーバーがリソース不足でクラッシュするのではなく、接続枠が埋まることで応答不能になります。

一般的なDDoS攻撃との違い

Slowlorisは従来のDDoS攻撃と根本的に異なるアプローチを取ります。以下の比較で違いを整理します。

帯域幅消費

• 一般的なDDoS攻撃：大量のパケットで帯域幅を埋め尽くす
• Slowloris：帯域幅をほとんど消費しない

必要なリクエスト数

• 一般的なDDoS攻撃：数万件規模のリクエストが必要
• Slowloris：数百件程度の接続で十分

攻撃規模

• 一般的なDDoS攻撃：大規模なボットネットが必要なことが多い
• Slowloris：1台のマシンから実行可能

検知難度

• 一般的なDDoS攻撃：帯域幅の異常で比較的検知しやすい
• Slowloris：正常なトラフィックに見えるため検知が困難

ログへの記録

• 一般的なDDoS攻撃：攻撃ログが残りやすい
• Slowloris：リクエスト完了前はログに記録されない

攻撃対象

• 一般的なDDoS攻撃：帯域幅・ネットワーク層
• Slowloris：接続数・スレッドなどサーバーリソース（アプリケーション層）

影響を受けるWebサーバーと耐性のあるサーバー

影響を受けやすいサーバー（スレッドベース）

Slowlorisが特に影響するのは、接続ごとにスレッドやプロセスを割り当てる「スレッドベース」のWebサーバーです。接続が枯渇すると、割り当てられたすべてのスレッドが占有されてしまうためです。

• Apache 1.x / 2.x：最も影響を受けやすいサーバーの代表例。デフォルト設定では同時接続数が制限されており、Slowlorisで接続スロットを使い切られると新規リクエストを受け付けなくなります。
• Microsoft IIS（一部の設定）：スレッドプールの設定によっては影響を受ける可能性があります。
• スレッド単位で接続を処理するWebサーバー全般：構造上、Slowlorisの標的になり得ます。

影響を受けにくいサーバー（イベント駆動型）

一方、非同期・イベント駆動型のアーキテクチャを持つサーバーは、接続ごとにスレッドを割り当てないため、Slowlorisの影響を受けにくいです。

• Nginx：非同期のイベント駆動型アーキテクチャで、多数の接続を少ないリソースで処理できます。Slowlorisへの耐性が高く、Apacheの前段に置くリバースプロキシとしても推奨されます。
• LiteSpeed：同様にイベント駆動型でSlowlorisへの耐性があります。
• HAProxy：ロードバランサー・プロキシとして広く使われ、タイムアウト設定で対処できます。

Apacheを使用している場合は特に注意が必要です。後述するモジュールや設定変更で対策できますが、最も根本的な対策はNginxをリバースプロキシとして前段に配置し、不完全なリクエストをフィルタリングすることです。

Slow HTTP攻撃の分類（Slowlorisの位置づけ）

Slowlorisは、より広い攻撃カテゴリである「Slow HTTP DoS攻撃」の一種です。Slow HTTP攻撃にはいくつかの種類があり、それぞれ異なる部分を狙います。

Slow HTTP Headers Attack（Slowloris本体）

HTTPリクエストのヘッダーをゆっくり送り続け、リクエストヘッダーの完成を遅延させます。これが「Slowloris」として知られる攻撃です。

Slow HTTP POST Attack

HTTPのPOSTリクエストに大きなContent-Lengthを指定しておきながら、ボディを極めてゆっくり送信します。サーバーはPOSTデータの受信完了を待ち続け、リソースを占有されます。

Slow Read DoS Attack

正常なHTTPリクエストを送信するものの、レスポンスデータの受信を意図的に遅らせます。サーバーはレスポンス送信のためにバッファとリソースを保持し続けます。

セキュリティ機器やWAFを選定・評価する際には、「Slowlorisへの対応」だけでなく「Slow HTTP攻撃全般への対応」を確認するとよいでしょう。3種類すべてに対応しているかどうかがポイントです。

過去の被害事例

2009年 イラン選挙後の事例

Slowlorisが広く知られるようになったのは、2009年のイラン大統領選挙後です。選挙結果に抗議するハッカーグループが、イラン政府関連のWebサイトに対してSlowlorisを使ったDoS攻撃を実施し、複数のサイトをダウンさせました。この事例は、単純な攻撃ツールでも政治的・社会的に大きな影響を与えられることを示した代表的な事件として記録されています。

ハクティビズム・スモークスクリーン攻撃への悪用

Slowlorisは、政治的な主張を持つハクティビストグループが敵対するWebサイトを攻撃する際にも利用されてきました。また、より高度な侵害攻撃を実施する前段として、セキュリティ担当者の注意をWebサービスの障害対応に集中させる「スモークスクリーン」として使われるケースも報告されています。

警察庁も、ApacheのDoS脆弱性として注意喚起を実施しています。Webサービスを運営する組織においては、Slowlorisを既知の脅威として認識し、対策を講じておくことが重要です。

Slowlorisの検出方法

検出が難しい理由

Slowlorisは従来のセキュリティツールによる検出が難しいことで知られています。その主な理由は次のとおりです。

• トラフィック量が少ない：帯域幅をほとんど消費しないため、帯域幅ベースの監視では異常が検出されない
• 正常なリクエストに見える：通常のHTTPリクエストと同じ形式のため、単純なパケット検査では区別が難しい
• ログに記録されない：HTTPリクエストが完了しない限りWebサーバーのアクセスログに書き込まれないため、攻撃中の痕跡が残らない
• IDSをすり抜ける：従来のシグネチャベースの侵入検知システムでは検知できないことがある

検出に有効な指標

Slowlorisを早期発見するためには、以下の指標を継続的に監視することが重要です。

• オープン接続数の増加：通常よりも多くのTCP接続が開いたままになっていないかを監視する
• 部分的なHTTPリクエストの存在：ヘッダーが完成していないリクエストが多数存在する場合は攻撃の兆候
• 接続試行数の異常な増加：単位時間あたりの接続試行数が急増している場合は要注意
• 送信元IPごとの最大接続数：特定のIPアドレスから異常に多くの接続が来ていないかを確認する
• セッションテーブルの状態：ESTABLISHED状態の接続が異常に多く滞留していないかを監視する

IDS（侵入検知システム）で不完全なHTTPリクエストや繰り返しの接続試行などの異常パターンを検出する方法、またWAFでリクエスト頻度やパターンを分析する方法が有効です。Apache向けにはmod_noloris・mod_antilorisモジュールが攻撃者のIPアドレスを高確率で判別できます。

Apacheの具体的な対策（設定・モジュール）

現在もApacheを使用している場合、以下の設定・モジュールによる対策を実施してください。

mod_reqtimeout（推奨・標準搭載）

mod_reqtimeoutはApache 2.2.15以降に標準搭載されているモジュールで、HTTPリクエストのヘッダーおよびボディの受信タイムアウトを設定できます。Slowlorisへの対策として最初に確認すべきモジュールです。httpd.confまたは.htaccessに以下のような設定を追加します。

RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

• header=20-40：ヘッダーの受信タイムアウトを20〜40秒の範囲で設定
• body=20：ボディの受信タイムアウトを20秒に設定
• MinRate=500：最低500バイト/秒の転送速度を要求し、それ以下の接続をタイムアウト

mod_noloris・mod_antiloris

mod_nolorisとmod_antilorisは、Slowloris対策専用のApacheモジュールです。単一IPアドレスからの同時接続数を制限し、攻撃者のIPを判別してブロックします。mod_reqtimeoutと組み合わせることで、より強固な対策が可能です。

接続数・タイムアウトの設定調整

• Timeoutディレクティブの短縮：デフォルトの300秒を60秒程度に短縮することで、不完全な接続を早期に切断できます。
• KeepAliveTimeoutの短縮：HTTPキープアライブのタイムアウトを短くし、アイドル接続を素早く解放します。
• MaxClients（MaxRequestWorkers）の調整：最大同時接続数を適切に設定し、一部の接続が占有されても全体への影響を最小化します。
• LimitRequestFieldsの制限：リクエストヘッダーのフィールド数を制限し、異常なリクエストを拒否します。

インフラ・アーキテクチャによる対策

Nginxをリバースプロキシとして導入（最も効果的）

最も効果的な対策のひとつが、Apacheの前段にNginxをリバースプロキシとして配置することです。Nginxは非同期イベント駆動型のアーキテクチャを持ち、不完全なHTTPリクエストをバッファリングして完成してからApacheに転送します。これにより、Slowlorisの接続がApacheに直接届かなくなります。

NginxのデフォルトのHTTPタイムアウト設定（client_header_timeout・client_body_timeout）は比較的短く設定されているため、多くの場合そのままでSlowlorisを効果的に防御できます。

HAProxyによる接続管理

HAProxyをロードバランサーとして導入し、タイムアウト設定（timeout http-request）を適切に設定することでSlowlorisの影響を軽減できます。複数のバックエンドサーバーに接続を分散させることで、単一サーバーへの集中攻撃の影響を軽減できる点もメリットです。

サーバーの許容接続数増加（補助的対策）

Apacheの最大同時接続数を増やすことで、攻撃者がすべての接続スロットを埋めるまでの時間を稼げます。ただし、根本的な解決にはならず、攻撃者は増加した接続数に合わせて攻撃規模を拡大できるため、他の対策と組み合わせる補助的な手段として位置づけてください。

WAF・CDNによる防御

WAF（Webアプリケーションファイアウォール）

WAFはHTTPリクエストの内容・パターン・頻度を分析し、Slowlorisの特徴である「不完全なリクエスト」や「異常に遅い転送速度」を検知してブロックできます。WAFには大きく分けて次の3種類があります。

• クラウド型WAF：サーバーに到達する前にクラウド上でフィルタリング。導入が容易でサーバーへの負荷も少ない
• アプライアンス型WAF：専用ハードウェアによる高性能なフィルタリング。オンプレミス環境に適する
• ソフトウェア型WAF：Webサーバーにインストールして使用。mod_securityなどがその例

CDNによるDDoS緩和サービス

Cloudflare、Akamai、CDNetworksなどのCDN事業者は、Slowlorisを含むDoS/DDoS攻撃に対する緩和サービスを提供しています。CDNはリバースプロキシとして機能し、クライアントからのリクエストをいったんCDNのエッジサーバーで受信・バッファリングしてから送信元サーバーに転送します。

この仕組みにより、不完全なHTTPリクエストがオリジンサーバーに届く前にフィルタリングされます。Webサービスの規模が大きい場合や、自社でセキュリティ運用リソースを確保しにくい場合は、CDNのセキュリティ機能の活用が有効な選択肢です。

実践チェックリスト

自組織のWebサーバーのSlowloris対策状況を確認してください。

サーバー設定の確認

• Apacheを使用している場合、mod_reqtimeoutが有効になっているか・Timeout / KeepAliveTimeoutが適切な値（例：60秒以下）に設定されているか
• 1つのIPアドレスからの同時接続数が制限されているか（mod_noloris / mod_antiloris）
• LimitRequestFields / LimitRequestFieldSizeでリクエストヘッダーの上限を設定しているか

アーキテクチャの確認

• NginxまたはHAProxyがApacheの前段にリバースプロキシとして配置されているか
• NginxのHTTPタイムアウト設定（client_header_timeout / client_body_timeout）が適切に設定されているか
• CDN / クラウドWAFでオリジンサーバーが保護されているか

監視・検知の確認

• オープン接続数を継続的に監視しているか
• 送信元IPごとの最大接続数を監視できているか
• IDS / WAFでSlow HTTP攻撃のパターンが検知対象になっているか
• 攻撃シミュレーションツール（slowhttptest等）で定期的に自社環境をテストしているか

インシデント対応の確認

• Webサーバーが応答不能になった際の初動手順（切り離し・CDN切り替え等）が明文化されているか
• 攻撃時のIPアドレスブロック手順が整備されているか

よくある質問（FAQ）

Q. SlowlorisはHTTPS（SSL/TLS）でも有効ですか？

はい、有効です。SlowlorisはTCP接続レベルで動作するため、HTTPSであってもSSL/TLSハンドシェイク完了後のHTTPリクエストを遅延させることで同様の攻撃が可能です。HTTPSへの移行だけではSlowlorisを防げないため、サーバー設定やリバースプロキシによる対策が必要です。

Q. Nginxを使っていれば安全ですか？

Nginxはスレッドベースではないため、Slowlorisへの耐性が高いです。しかし、完全に安全とは言えません。Nginxのタイムアウト設定が適切でない場合や、Nginxの背後にApacheが動いている場合は影響を受ける可能性があります。タイムアウト設定の確認と、必要に応じたWAFの導入が推奨されます。

Q. Slowloris攻撃を受けた場合の応急処置は？

①CDNまたはリバースプロキシ経由に切り替えてオリジンサーバーへの直接アクセスを遮断する、②攻撃元IPアドレスをファイアウォールでブロックする（ただし送信元IPが偽装されている場合もある）、③mod_reqtimeoutのタイムアウト値を短縮する、の順で対応するのが現実的です。根本対策は復旧後に実施してください。

Q. Slowloris攻撃はIPアドレスを偽装しますか？

Slowlorisはサーバーとの間にTCPの3ウェイハンドシェイクが成立している接続を悪用します。そのため、完全なIPアドレス偽装（スプーフィング）は難しく、多くの場合は実際のIPアドレスや匿名化されたIPアドレス（Tor、VPNなど）が使われます。ただし、複数のIPアドレスから分散して攻撃するケースもあるため、単純なIPブロックでは対処しきれない場合があります。

Q. Slowlorisの脆弱性に対するCVEはありますか？

Slowlorisそのものに対するCVEは発行されていませんが、Slowlorisが悪用するApacheの設定的脆弱性については、改善策がApacheの公式ドキュメントやセキュリティアドバイザリで提示されています。mod_reqtimeoutの導入（Apache 2.2.15）も、Slowlorisへの対応として追加されたものです。

Q. Slowlorisへの対策状況を自社でテストする方法はありますか？

slowhttptestという無償のコマンドラインツールを使うと、Slow HTTP攻撃（Slowloris型・Slow POST型・Slow Read型）のシミュレーションを自社環境に対して実施できます。本番環境への影響に注意しながら、テスト環境や許可された環境でのみ使用してください。定期的なペネトレーションテストの一環として取り入れることを推奨します。

まとめ

Slowlorisは、大量のトラフィックを必要とせず1台のマシンから実行できる、アプリケーション層を標的としたDoS攻撃の手法です。HTTPプロトコルの基本動作を悪用し、不完全なリクエストを維持し続けることでサーバーの接続リソースを枯渇させます。攻撃中はログに記録されず、正常なトラフィックに見えることから検知が難しく、特にApacheサーバーに深刻な影響を与えます。

対策の基本は、①Apacheのmod_reqtimeoutやタイムアウト設定の見直し、②Nginxをリバースプロキシとして前段に配置、③WAF・CDNによるアプリケーション層の防御の三層で構成される多層防御です。単一の対策では不十分なケースも多いため、複数の対策を組み合わせることが重要です。

また、Slowlorisを含むSlow HTTP攻撃を模擬するツール（slowhttptest）で定期的に自社環境をテストし、対策の有効性を継続的に検証することをお勧めします。Webサービスの可用性を守るために、今日からでも設定の見直しを始めてみてください。

書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！

セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！

メルマガ登録はこちらから