☰

NGINX: 無条件の一括リダイレクトを発行するサーバー上の明らかに偽のトラフィックをどのように処理しますか?

tag-icon • tag-icon linux nginx web-server
NGINX: 無条件の一括リダイレクトを発行するサーバー上の明らかに偽のトラフィックをどのように処理しますか?

NGinx を設定しようとして、かなり興味深い問題に遭遇しました。私は、NGinx 1.13.8 を使用して、すべてを HTTPS 経由で提供する小さな Web サーバーを実行しています。このような構成ではよくあることですが、ポート 80 もリッスンし、そこにあるすべてのリクエストを同じ URI でポート 443 に一括リダイレクトします。これを実現するには、次の構成フラグメントを使用します。

location / {
    return 301 https://$server_name$request_uri;
}

これ自体は、私の目的には十分機能していました。しかし、明らかに偽物で簡単に識別できるトラフィック (ランダムな IP から 1,000 件の新規接続が最大で発生する約 5 分間のランダムな期間。すべて User-Agent ヘッダーに共通のプレフィックスがあり、すべてまったく同じリクエスト ( HEAD / HTTP/1.1) を行い、タイムアウトするまで接続を開いたままにし、リダイレクトにはまったく従いません) が発生し始めました。

理想的には、これらの接続が識別されるとすぐに閉じて、無駄になるリソースの量を最小限に抑えたいと考えています。現在、これを実現するために、次の変更された構成フラグメントを思いつきました。

location / {
    return 301 https://$server_name$request_uri;
}

location = / {
    if ($method = "HEAD") {
        set $drop M;
    }
    if ($http_user_agent ~* "Dalvik/2.1.0 (Linux U ") {
        set $drop "U${drop}";
    }
    if ($drop = "UM") {
        return 444;
    }
}

ただし、これは機能していないようです (ログには、トラフィックの急増がすべて 301 を返すことがまだ示されています)。また、最初のロケーション ブロック内で、あまり具体的でない一致 (User-Agent ヘッダーまたはメソッドの包括的な一致のみ) も試しましたが、これも機能していないようです。

そこで、2つの質問があります。

  1. なぜこれが機能しないのでしょうか?
  2. ファイアウォールでのディープ パケット インスペクションを必要としない、このトラフィックを処理するより良い方法はありますか?

関連情報