
私はUbuntu 20.04 LEMP (Linux、Nginx、MariaDb、PHP)ウェブサーバーを実行しています。また、MacOSクライアントマシンからnmap脆弱性テストも行っています。MacOSでは、オーマイズッシュ!プラグインを有効にしてnmap
、MacOS クライアント マシンから Ubuntu Server の脆弱性テストを実行するために、次のコマンドを発行しました。
nmap_check_for_vulns my.server.ip.address
これは、
nmap --script=vuln
サーバーの IP アドレスを指定してコマンドを発行すると、nmap は次のように報告しました。
| http-vuln-cve2011-3192:
| VULNERABLE:
| Apache byterange filter DoS
| State: VULNERABLE
| IDs: CVE:CVE-2011-3192 BID:49303
| The Apache web server is vulnerable to a denial of service attack when numerous
| overlapping byte ranges are requested.
| Disclosure date: 2011-08-19
| References:
| https://www.tenable.com/plugins/nessus/55976
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
| https://www.securityfocus.com/bid/49303
|_ https://seclists.org/fulldisclosure/2011/Aug/175
Ubuntu Server では、出力は次のようにss -lnpt
なります。
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 100 0.0.0.0:25 0.0.0.0:*
LISTEN 0 511 0.0.0.0:443 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:8125 0.0.0.0:*
LISTEN 0 100 0.0.0.0:4190 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:19999 0.0.0.0:*
LISTEN 0 100 0.0.0.0:993 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10023 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10024 0.0.0.0:*
LISTEN 0 100 127.0.0.1:10025 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:10026 0.0.0.0:*
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:*
LISTEN 0 100 0.0.0.0:587 0.0.0.0:*
LISTEN 0 128 0.0.0.0:43211 0.0.0.0:*
LISTEN 0 511 127.0.0.1:6379 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:783 0.0.0.0:*
LISTEN 0 100 0.0.0.0:143 0.0.0.0:*
LISTEN 0 511 0.0.0.0:80 0.0.0.0:*
LISTEN 0 4096 0.0.0.0:10000 0.0.0.0:*
LISTEN 0 100 0.0.0.0:465 0.0.0.0:*
LISTEN 0 128 0.0.0.0:43219 0.0.0.0:*
LISTEN 0 256 0.0.0.0:53 0.0.0.0:*
サーバー上のこの脆弱性を解消しようとしていますが、サーバーに Apache がインストールされていないため、なぜこの脆弱性が現れるのかわかりません。
私の質問は、脆弱なプログラムを見つけるにはどうしたらよいか、そしてサーバー上の脆弱性をどうやって解消すればよいかということです。
答え1
ポート 80 または 443 でリッスンしているプロセスを確認しますss -lnpt
。これがターゲットである可能性が最も高いです。
答え2
の古代 チェックこれは apache2 に固有のものではなく、apache2 でこのような DoS サーフェスを緩和する特定のアプローチにのみ固有のものです。Nginx はこれを採用していません。Nginx はデフォルトで多数の個別の範囲のリクエストに対応しますが、ヘッダー サイズの制限が適用されます。理論上、これ (またはヘッダーをそのまま転送されるもの) は、奇妙なリクエストで過剰なリソース使用に対して脆弱になる可能性があります。
max_ranges number; Default: — Context: http, server, location
このディレクティブはバージョン 1.1.2 で登場しました。
バイト範囲リクエストで許容される範囲の最大数を制限します。制限を超えるリクエストは、バイト範囲が指定されていないかのように処理されます。デフォルトでは、範囲の数は制限されません。値が 0 の場合、バイト範囲のサポートは完全に無効になります。
これは、Apache サーバーを過負荷にするために使用できる特定のトリックほど大きな問題ではありません。nginx がどこか別の場所にプロキシしていない限り (またはプロキシではなくキャッシュからほとんどのリクエストを処理することに依存していない限り)、その設定を使用して制限を明示的に追加しなくても、何もする必要はないでしょう。
最近では、(2011年以降にメンテナンスを受けた)ウェブサーバーは、単に無視サイズの合計がコンテンツの合計長を超える範囲のリクエスト- 現実世界ではほとんど応用されていないものなので、制限するよりもさらに良い緩和策です番号範囲の。
いずれにせよ、このような迷惑なリクエストをコマンドラインから手動で作成することができます。全体的なエクスプロイトは、など、数百の重複範囲の順序でヘッダー付きのリクエストを送信することですRange: bytes=1-1337,1-1338,1-1339
。応答 (ステータス 206 の場合。200 が表示された場合は、nginx はヘッダーを無視してすべてを返しています) が大幅に遅くなったかどうかを確認してください。そうすれば、確実にわかります。