私たちは認証 URL への絶え間ない攻撃に対処してきました。1 日に何百万ものリクエストが発生しており、彼らはパスワードをブルートフォース攻撃しようとしていると推測します。
サーバーのファイアウォールで IP をブロックすると、数秒後に別の IP から攻撃が再開されます。
最終的に、rack-attack によるスロットリングとカスタム コードを組み合わせて実装し、ファイアウォールで IP を動的にブロックしました。しかし、ソフトウェアのセキュリティが強化されるにつれて、攻撃者も強化され、攻撃者が行うすべてのリクエストが異なる IP から実行され、IP ごとに 1 回の呼び出しが行われ、1 秒あたりにまだ数回発生しています。以前ほど多くはありませんが、依然として問題です。
今、これを防ぐために他に何ができるか考えています。Recaptcha を試しましたが、すぐに月間クォータを使い果たしてしまい、誰もログインできなくなりました。
Nginx レート リミッターを検討していますが、私の見るところ、これも IP を使用しているようです。現在はリクエストごとに IP がローテーションされるため、これを機能させる方法はありますか?
これに対処する方法について他に何か提案はありますか? 皆さんの中に同じことを経験した人がいるかもしれません。
スタック: Nginx および Rails 4、Ubuntu 16。
答え1
レート制限により、大量のパスワード スプレー攻撃の一部をフィルタリングできるので、役に立ちます。ただし、攻撃者が多数の IP アドレスを持ち、それらをすばやく切り替え、リクエストを人間のレートに制限している場合、IP ベースのレート制限だけでは機能しません。
recaptcha を試しましたが、すぐに月間クォータを使い果たしてしまい、誰もログインできなくなりました。
CAPTCHAサービスの料金を支払い、1か月間規模でどのように機能するかを観察します。価格設定が気に入らない場合は、代替案。hキャプチャたとえば、 には基本的な無料枠があります。
もっと根本的には、パスワードをハードウェア セキュリティ キーや生体認証などのより優れたものに置き換えます。または、少なくともパスワードに追加の認証要素を追加します。これを行うための標準が存在します。具体的には FIDO2 です。また、ユーザーと対話しない認証情報の場合、SSH キー、x509 証明書、または生成された API キーも、ユーザーが選択したパスワードよりも優れています。