したがって、私のサーバーはサービス拒否攻撃を受けている可能性があると思います。
pingdom (Web サイト監視) から、午前 3 時頃から Web サイトが利用できなくなったという通知を受けました。今日早朝、Apache エラー ログの確認を開始したところ、次のようなエラーが大量に表示されました。
AH00485: スコアボードがいっぱいです。MaxRequestWorkers に達していません
また、PHP-FPM プロセス プールでは頻繁に追加のサーバーを生成する必要があることもわかりました。
[pool www] はビジー状態です (pm.start_servers または pm.min/max_spare_servers を増やす必要があるかもしれません)。8 個の子サーバーを生成しています。
Apacheの設定でMaxRequestWorkersを増やしたり、他の対策を試みましたが、Apacheのエラーログのスコアボードエラーは解消されませんでした。そこで、私の判断に反して、このスレッドそして設定最小スペアスレッドそして最大スペアスレッドに等しい最大リクエストワーカー数これらの変更により、スコアボードのエラーが解消されたようです。
また、明らかに使用されていない 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 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時頃、突然何かが変わったようです。
何かアドバイスがあれば、ぜひお願いします。まずここで検索して、この他のスレッドしかし、これは私のバージョンとは異なり、prefork モードで実行されている Apache のバージョンが異なります。また、そのスレッドのわずかな情報からどのようにして SlowLoris の診断が導かれたのかはわかりません。
編集: 質問をもっと正確に表現する必要があるようです:
1) サーバーの応答性を回復するにはどうすればいいでしょうか。明らかに、ApacheワーカーがRモードは何らかの問題の症状です。
2) 実際の問題をより具体的に特定するために実行できる、信頼できる一連の手順はありますか?
3) マシンが DoS 攻撃を受けているかどうかを確認する方法はありますか?
答え1
スコアボード上の接続数を数えるだけでは、クライアントが失礼な態度を取ったり、接続をフォローアップしていないことを知るには不十分です。これは劇的な増加です。つまり、Web アプリが非常に人気になったか、誰かがばかげたリクエストをしているということです。
1 秒あたりに完了したリクエストのレートを確認します。Web アプリが適切に動作していると仮定すると、その数のワーカーでは非常に高いレートになるはずです。ユーザーが利用できる帯域幅、サーバーの負荷、データベースなどの関連コンポーネントのパフォーマンスなど、Web サーバーのパフォーマンスのあらゆる側面を確認します。リソース不足によるパフォーマンスの問題があれば修正します。
Web ポートに接続された IP アドレスの分布を分析します。1 つの IP が何百もの接続をすべて実行するのは珍しいことですが、IPv4 NAT ではこれが複雑になります。ソース アドレスの ISP を特定します。IP アドレスのセキュリティ レピュテーション スコアを確認し、巨大な NAT であるかどうかを確認します。
監視を継続しながら、受信リクエストのパケット キャプチャを実行します。正常に動作するクライアントからの HTTP リクエストが少なくともいくつか表示されるはずです。クライアントが接続してそのまま待機している場合は、SlowLoris スタイルのリソース枯渇に少し似ています。
リンクされた回答のチューニング推奨事項を検討してください。 Linux では、sysctl などを使用してタイムアウトを少し減らすことを net.ipv4.tcp_fin_timeout = 10試してみるとよいでしょう。
この Web サーバーをセキュリティ重視の負荷分散プロキシの背後に配置することを検討してください。Web アプリケーション ファイアウォール機能を使用すると、リクエストを巧みにフィルタリングできます。水平方向にスケーリングすると、より多くのリクエストを処理できるようになります。
答え2
マシンが DoS 攻撃を受けているかどうかを確認する方法はありますか?
DoSサービス拒否です。
攻撃危害を加える目的で実行される敵対的な行為です。
（受動的攻撃それを理解していない人が使う矛盾表現である受け身行動の欠如、つまり定義上は不作為を意味し、侵略(定義上も) 敵対的な行動を意味します。しかし、もちろんそれはまた別の話です。
これら 2 つの間には、DoS ではあるものの敵対的な行為という点では攻撃ではないというギャップがあります。たとえば、F5 キーがユーザーのキーボード上で動かなくなった場合、対策を講じない限り DoS が発生する可能性がありますが、害を及ぼす意図を持って実行される敵対的な行為としては攻撃ではありません。一方、ユーザーが DoS が発生することを知りながら意図的にそのキーを押し続ける場合は、攻撃になります。
それで、あなたの質問に答えると、意図があることを証明できない限り、確実に判断するのは明らかに不可能です。リソース不足、つまり過負荷が原因でサービスの中断が発生した場合、それが DoS であるかどうかを判断することは可能です。