1

現在、Web アプリケーションのセキュリティ レイヤーを強化しています。ログイン ブルート フォース保護の実装についていくつか質問があります。

  • ユーザー/IP ごとの失敗したログインのカウンターを保存するには、どのストレージを使用すればよいですか? 単純な APC/Memcache エントリで十分でしょうか?それとも、ログインごとに追加の SQL クエリまたはファイル書き込みを意味する、より安定した永続的なストレージ方法が必要でしょうか? または、それらをセッション エントリに格納することもできます (私のセッションは Memcache によって処理されるため、まったく同じです)。

  • システム全体のカウンターに関する同じ質問 (分散されたブルート フォース試行の場合にログインのロックダウンまたは制限をトリガーするため...)? ここでの永続性はより重要だと思いますが、ログインごとにクエリ/書き込みを行うことも意味します。

  • 検出されたログイン ブルート フォース試行に対する適切な応答は何でしょうか? 404 エラー、503 サービスを利用できませんを返す必要がありますか? または、 IPTables/Netfilter を介して攻撃者の IP を DROPing または TARPITing することでさらに深くなりますか? 私は実際に検出されたブルート フォースの試みについて話しているのであって、ユーザーが自分のパスを思い出すことができないためにログインに失敗した場合ではありません。

当初は、キャッシュ ストレージ (APC/Memcache) でカウンターを格納するのに十分だと考えていましたが、キャッシュが何らかの理由で失敗し、この防御層が無効になるのではないかと心配しています。

他のすべての考慮事項については、 What-is-the-best-distributed-brute-force-countermeasureやNumber-of-attempts-to-brute-force-an-average-passwordなどの素晴らしい投稿を既に読んでいますが、お気軽にアドバイスをいただければ幸いです。

4

1 に答える 1

0

まず、データの正しい範囲を特定してから、速度と最適化に悩まされる必要があります。

あなたが言ったように、キャッシュストレージは失敗するかもしれません。これは、データのスコープがキャッシュよりも広いことを明確に示しています。したがって、そこに保存しないでください。データベースは良い代替手段です。

さて、速度が気になる場合（そしてそうあるべきです）、プロセスを最適化する時が来ました。すでにキャッシュレイヤーがあるので、それを使用してこの余分な読み取りクエリをキャッシュします。一方、これは全体的なユーザーエクスペリエンスに影響を与えない例外的なケースであるため、追加の更新クエリについて気にする必要はありません。

3番目の質問については、検出されたブルートフォース攻撃に対する応答の種類は重要ではありません。重要なのは時間です。たとえば、20秒の遅延で応答します。これは、この生涯でブルートフォースを不可能にするのに十分なはずです。

于 2012-04-11T08:50:09.583 に答える