2

nginx プロキシの背後で Django サーバーを実行しています。現在、を読んでリモートアドレスを特定しようとしていますrequest.META['REMOTE_ADDR']。より正確には、ユーザーのパスワードをブルート フォースしようとする試みをレート制限するアプリ (Django-brutebuster) がこれを行っています。

Django は nginx の背後にあるため、REMOTE_ADDRは Nginx のアドレス (127.0.0.1) であるため、あまり役に立ちません。また、ブルートバスターの観点からは全員が同じ IP にいるため、意図的にパスワードを誤って推測することで、アプリケーションを DOS に開放します。

このフォーラムで同様の質問を見つけました。

パズルのピースは上記で見つけることができると思います。しかし、それらはまた、新しい攻撃ベクトルへの適用を可能にするものでもあると思います。具体的には、何らかの理由で Django が nginx の背後で実行されていない場合、X-something ヘッダーを自動的にチェックすると、クライアントからこれらのスプーフィングが開かれます。

上記の質問と回答のいずれにも、「これを行うための正しい唯一の方法」(TM) への言及がないように見えることは、私にとっては少し驚くべきことです。Django には、この問題に対する標準的な解決策がありませんか? それがなければ、少なくともセキュリティ上の問題を引き起こさない解決策を思いつくことができるでしょうか?

4

1 に答える 1

1

"The Right & Only Way To Do This" (TM) の問題点は、アプリケーションと展開構成の両方に指示を与える必要があることです。

Django には以前はSetRemoteAddrFromForwardedForミドルウェアがありましたが、「このメカニズムでは汎用的に使用するには十分な信頼性を持たせることができない」という理由で削除されました ( django 1.1 のリリース ノートで確認できます) 。

問題を正しく説明しました。通常、Django アプリが受け取るすべてのヘッダーを信頼することはできません。このようなヘッダーの状況は、展開に固有すぎるため、一般的な解決策がありません。

このようなヘッダーを保護するには、nginx/haproxy/whatever でこのヘッダーの設定を強制する必要があります。

于 2013-04-04T14:55:58.690 に答える