DoS攻撃？ Apacheワーカーの大多数が「Reading Request」モードで、昨夜サイトがダウンし、現在は遅い
そのため、サーバーでサービス拒否攻撃を受けている可能性があります。
Pingdom（ウェブサイトモニタリング）から、午前3時頃からウェブサイトが利用できなくなったという通知を受けました。今日の初めに、Apacheエラーログのチェックを開始しましたが、このエラーがたくさんありました。
AH00485：MaxRequestWorkersではなく、スコアボードがいっぱいです
また、PHP-FPMプロセスプールがより多くのサーバーを生成するために頻繁に必要であることもわかりました。
[プールwww]はビジーのようです（pm.start_serversまたはpm.min/max_spare_serversを増やす必要がある場合があります）。8人の子を生成します
私たちは、Apache confでMaxRequestWorkersと他のいくつかの救済策を増やしてみましたが、これらはApacheエラーログのスコアボードエラーを排除しなかったので、より良い判断に反して、 this thread のアドバイスに従い、設定しましたMinSpareThreadsおよびMaxSpareThreads等しい MaxRequestWorkers。これらの変更により、スコアボードエラーが解消されたようです。
明らかに使用されていないRAMがたくさんあるため、MaxRequestWorkersも大幅に増やしました。サーバーには8つのコアがあり、これらの非常に高い構成値にもかかわらず、使用していないようですそのRAMのすべて：
$ free -h
total used free shared buff/cache available
Mem: 7.8G 1.8G 2.0G 38M 4.0G 5.8G
Swap: 0B 0B 0B
Apache confのMaxRequestWorkersとphp-fpm構成のpm.max_childrenのこれらの高い値については、かなり緊張しています。
Mpm_event.confの基本構成は次のとおりです
<IfModule mpm_event_module>
StartServers 2
MinSpareThreads 800
MaxSpareThreads 800
ThreadLimit 64
ThreadsPerChild 25
ServerLimit 800
MaxRequestWorkers 800
MaxConnectionsPerChild 0
</IfModule>
次に、php-fpm confファイルの設定の一部を示します。
pm.max_children = 256
pm.start_servers = 64
pm.min_spare_servers = 64
pm.max_spare_servers = 128
基本的なサーバー情報は次のとおりです。
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2019-10-08T13:31:25
Server's Module Magic Number: 20120211:52
Server loaded: APR 1.5.2, APR-UTIL 1.5.4
Compiled using: APR 1.5.2, APR-UTIL 1.5.4
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
そして、Apache server-status出力からのデータの一部を以下に示します。
Server Version: Apache/2.4.18 (Ubuntu) OpenSSL/1.0.2g
Server MPM: event
Server Built: 2019-10-08T13:31:25
Current Time: Friday, 10-Jan-2020 22:58:55 CST
Restart Time: Friday, 10-Jan-2020 22:26:32 CST
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 32 minutes 22 seconds
Server load: 4.69 5.06 5.12
Total accesses: 78434 - Total Traffic: 1.5 GB
CPU Usage: u2970.53 s5037.34 cu0 cs0 - 412% CPU load
40.4 requests/sec - 0.8 MB/second - 19.7 kB/request
797 requests currently being processed, 3 idle workers
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
6124 28 yes 25 0 0 0 3
6125 27 yes 25 0 0 0 2
6182 30 yes 25 0 0 1 4
6210 28 yes 25 0 0 0 3
6211 29 yes 25 0 0 0 5
6266 28 yes 25 0 0 2 1
6267 25 yes 25 0 0 0 1
6269 28 no 24 1 0 1 3
6276 28 yes 25 0 0 0 3
6378 28 yes 25 0 0 0 3
6379 31 no 24 1 0 4 3
6380 27 yes 25 0 0 0 3
6384 26 yes 25 0 0 0 2
6397 28 yes 25 0 0 2 1
6405 27 yes 25 0 0 0 2
6414 26 yes 25 0 0 1 0
6423 27 no 24 1 0 1 1
6602 27 yes 25 0 0 0 3
6603 28 yes 25 0 0 0 4
6604 26 yes 25 0 0 0 1
6617 30 yes 25 0 0 0 5
6646 26 yes 25 0 0 0 2
6676 27 yes 25 0 0 0 2
6694 30 yes 25 0 0 0 5
6705 28 yes 25 0 0 0 3
6730 29 yes 25 0 0 0 4
6765 29 yes 25 0 0 0 4
6781 27 yes 25 0 0 0 2
6805 28 yes 25 0 0 0 4
6836 28 yes 25 0 0 0 3
6858 27 yes 25 0 0 0 3
6859 27 no 25 0 0 1 1
Sum 888 797 3 0 13 86
ワーカーモードの部分は最も困惑させられます。ほとんどすべてが読み取りモードです。
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
_RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRWRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR_RRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
そして最後にこれがあります：
SSL/TLS Session Cache Status:
cache type: SHMCB, shared memory: 512000 bytes, current entries: 2176
subcaches: 32, indexes per subcache: 88
time left on oldest entries' objects: avg: 220 seconds, (range: 197...243)
index usage: 77%, cache usage: 99%
total entries stored since starting: 60122
total entries replaced since starting: 0
total entries expired since starting: 0
total (pre-expiry) entries scrolled out of the cache: 57946
total retrieves since starting: 3405 hit, 59594 miss
total removes since starting: 0 hit, 0 miss
また、netstatはポート80およびポート443への3000以上の接続をいくつか示しています。
$ netstat -n | egrep ":80|443" | wc -l
3715
一体何が起こっているのですか？サーバーはより控えめな構成設定で数か月間正常に動作しています。昨日の午前3時頃に何かが突然変更されたようです。
どんなガイダンスもいただければ幸いです。私は最初にここを検索して this other thread を見つけましたが、それは私のようなイベントではなく、preforkモードで実行されているApacheの別のバージョンです。また、そのスレッドの小さな情報がどのようにしてSlowLoris診断につながったのかも理解できません。
編集私は私の質問をより正確に表現する必要があるようです：
1）サーバーの応答性を復元するにはどうすればよいですか。明らかに、Apacheワーカーが[〜＃〜] r [〜＃〜]モードでスタックすることは、いくつかの問題の兆候です。
2）実際の問題をより具体的に特定するために実行できる信頼できる一連の手順はありますか？
3）マシンがDoS攻撃を受けていることを確認する方法はありますか？
スコアボード上の接続数を数えるだけでは、クライアントが失礼であり、接続をフォローしていないことを知るには十分な証拠にはなりません。これは大幅な増加であるため、Webアプリが非常に人気を博したか、誰かがばかげたリクエストを出しているかのどちらかです。
1秒あたりに完了したリクエストの割合を確認します。 Webアプリが適切に実行されていると仮定すると、多くのワーカーでかなり高いはずです。ユーザーが利用できる帯域幅、サーバーの負荷、データベースなどの関連コンポーネントのパフォーマンスなど、Webサーバーのパフォーマンスのすべての側面を確認します。リソース不足によるパフォーマンスの問題を修正します。
Webポートに接続されているIPアドレスの分布を分析します。 IPv4 NATはこれを複雑にしますが、何百もの接続をすべて行う1つのIPは珍しいです。送信元アドレスのISPを決定します。 IPアドレスのセキュリティレピュテーションスコアをチェックし、それが巨大なNATである可能性があるかどうかを確認します。
監視を続けながら、着信要求でパケットキャプチャを実行します。正常に動作するクライアントからの少なくともいくつかのHTTPリクエストが表示されます。クライアントが接続してそこに座っているだけでは、SlowLorisスタイルのリソース枯渇に少し似ています。
リンクされた回答でチューニングの推奨事項を検討してください。 Linuxでは、sysctl net.ipv4.tcp_fin_timeout = 10を使用してタイムアウトを少し減らすことを試してみてください。
このWebサーバーをセキュリティ指向の負荷分散プロキシの背後に配置することを検討してください。 Webアプリケーションのファイアウォール機能を使用すると、巧妙な処理を行ってリクエストをフィルタリングできます。水平方向にスケーリングすると、より多くのリクエストを処理できるようになります。
マシンがDoS攻撃を受けていることを確認する方法はありますか？
DoSはサービス拒否です。
攻撃は、危害を加えるために実行される敵対的な行動です。
（パッシブアグレッションは、パッシブがアクションの欠如を意味することを理解していない人が使用するオキシモロンです-定義により、非アクション、およびアグレッション （定義上も）は敵対的な行動を意味しますが、それはもちろん別の話です。）
これら2つの間にはDoSのギャップがありますが、敵対的なアクションの観点からは攻撃ではありません。たとえば、F5がユーザーのキーボードで動かなくなった場合、対策を講じなければDoSが発生する可能性がありますが、害を及ぼすことを目的として実行される敵対的なアクションとしては攻撃ではありません。 OTOH、ユーザーがこれがDoSを引き起こすことを知っていて、意図的にそのキーが押されたままになっている場合、それは攻撃です。
ですから、あなたの質問に答えてください—意図があることを証明できない限り、確かに言うことは明らかに不可能です。リソースが不足しているためにサービスの中断が発生した場合、それがDoSであるかどうかを判断できます。