アカウント名:
パスワード:
異常アクセス数の検知もしてないようなシステムなら、どんな暗証番号にしてても多少前後しようがすぐ当たるよ。
検知システムくわしくないんだけど、パスワードスプレー攻撃でも検知はできるもの？アカウント一件あたりの試行回数は少なくなるんですよね？
リバースブルートフォース対策は、同一IPアドレスからの失敗繰り返しで、そのIPアドレスを遮断する、とかですね。で、特定IPアドレス遮断は、DDoSのようにアクセス元が分散されたらもう検知できない。
そんな場合でも、ブラウザの指紋とか使えば対策できそうだけど、そういう検知をやってるところがあるかは知らない。攻撃側も本当のブラウザでアクセスするわけじゃないから、指紋が変わるようにリクエスト情報に乱数要素をいれたら、それでもどうしようもないかな。
攻撃が始まったら失敗回数が跳ね上がるから検知はできるのでは。でも検知できたとしてどうするんだろう？ログイン止めたらサービス止めるのと同じだし。BOT群からのIPアドレス遮断を厳しくやると、BOTに寄生されたアホは自業自得としても、無関係のユーザがIPSごと影響が出そうだし、2chみたいな巻き添えと思われるアクセス拒否を経験したこともない。大手は常にそういう攻撃にさらされていると思うから、何かしら方法はあるんだと思うけど。
ログイン成功でも失敗でも1秒ぐらいは時間がかかるようにするだけでもだいぶ効果ありそう攻撃受けてるときならばもちょっと伸ばしてもいいか
同一IPならね。そうじゃないなら、リバースの場合は1回しかトライしないから遅延は効果ない。
正規ユーザも含め全部遅らせるっていうアイデアです
攻撃者は応答待って順序アクセスするわけじゃないし、Botネット使うならリンクを自分が張るわけでもない。司令をバラ撒いて成功報告を待つだけ。Botノード一つが処理するリクエスト数はたかが知れているのでBotノード側のリンク数も問題にはならない。
正規ユーザがログイン遅くて苛つくだけかと。
単位時間あたりのクラック成功数がかなり減ると思いますよ
単位時間あたりに開始する攻撃試行数が同じなら同じですよ。攻撃全体の開始から結果確定の開始までが遅延時間分遅くなるけれど、結果の確定が開始したら単位時間内に試行開始した数だけ結果が得られます。むしろサーバ側でのセッション数のほうが厳しくなるでしょうね。
単位時間に受け付けるセッション数を制限する場合でも、正規ユーザは幾らか待たされた時点で別時間帯へ移動するので、ログイン試行数辺りの攻撃の比率が上がってしまいますね。正規ユーザが弾かれない状態っていうのは攻撃側の消費セッション数を超える許容セッション数を設定した時のみです。正規ユーザがまともに使えないなら攻撃者の為にサービスするような物ですし、正規ユーザが不便を受けないようなら既に攻撃者の需要は満たしているでしょう。
そら攻撃回数が同じならね
？？？同一IPアドレスからの多量ログイン要求とかは楽に弾けるから、ボットネットなどを使って分散して多量のログイン要求してるってのが前提だよね？その状況でログイン処理に1秒ディレイを入れると何がどうなって攻撃回数が減ると主張してるの？
ボットネットのノード数より攻撃対象口座数の方が数倍以上のオーダで大きいと仮定するってーならそう言うべきだし、それ言わずに理屈は言わないけど攻撃回数が減るから効果があるんだ！とか言われても話になりませんがな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:0)
異常アクセス数の検知もしてないようなシステムなら、どんな暗証番号にしてても多少前後しようがすぐ当たるよ。
Re: (スコア:0)
検知システムくわしくないんだけど、パスワードスプレー攻撃でも検知はできるもの？アカウント一件あたりの試行回数は少なくなるんですよね？
Re: (スコア:0)
リバースブルートフォース対策は、同一IPアドレスからの失敗繰り返しで、そのIPアドレスを遮断する、とかですね。
で、特定IPアドレス遮断は、DDoSのようにアクセス元が分散されたらもう検知できない。
そんな場合でも、ブラウザの指紋とか使えば対策できそうだけど、そういう検知をやってるところがあるかは知らない。
攻撃側も本当のブラウザでアクセスするわけじゃないから、指紋が変わるようにリクエスト情報に乱数要素をいれたら、それでもどうしようもないかな。
Re: (スコア:0)
攻撃が始まったら失敗回数が跳ね上がるから検知はできるのでは。でも検知できたとしてどうするんだろう？
ログイン止めたらサービス止めるのと同じだし。
BOT群からのIPアドレス遮断を厳しくやると、BOTに寄生されたアホは自業自得としても、
無関係のユーザがIPSごと影響が出そうだし、2chみたいな巻き添えと思われるアクセス拒否を経験したこともない。
大手は常にそういう攻撃にさらされていると思うから、何かしら方法はあるんだと思うけど。
Re: (スコア:2)
ログイン成功でも失敗でも1秒ぐらいは時間がかかるようにするだけでもだいぶ効果ありそう
攻撃受けてるときならばもちょっと伸ばしてもいいか
Re: (スコア:1)
同一IPならね。そうじゃないなら、リバースの場合は1回しかトライしないから遅延は効果ない。
Re: (スコア:2)
正規ユーザも含め全部遅らせるっていうアイデアです
Re: (スコア:0)
攻撃者は応答待って順序アクセスするわけじゃないし、
Botネット使うならリンクを自分が張るわけでもない。
司令をバラ撒いて成功報告を待つだけ。
Botノード一つが処理するリクエスト数はたかが知れているので
Botノード側のリンク数も問題にはならない。
正規ユーザがログイン遅くて苛つくだけかと。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:2)
単位時間あたりのクラック成功数がかなり減ると思いますよ
Re: (スコア:0)
単位時間あたりに開始する攻撃試行数が同じなら同じですよ。
攻撃全体の開始から結果確定の開始までが遅延時間分遅くなるけれど、
結果の確定が開始したら単位時間内に試行開始した数だけ結果が得られます。
むしろサーバ側でのセッション数のほうが厳しくなるでしょうね。
単位時間に受け付けるセッション数を制限する場合でも、
正規ユーザは幾らか待たされた時点で別時間帯へ移動するので、
ログイン試行数辺りの攻撃の比率が上がってしまいますね。
正規ユーザが弾かれない状態っていうのは
攻撃側の消費セッション数を超える許容セッション数を設定した時のみです。
正規ユーザがまともに使えないなら攻撃者の為にサービスするような物ですし、
正規ユーザが不便を受けないようなら既に攻撃者の需要は満たしているでしょう。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:2)
そら攻撃回数が同じならね
Re: (スコア:0)
？？？
同一IPアドレスからの多量ログイン要求とかは楽に弾けるから、
ボットネットなどを使って分散して多量のログイン要求してるってのが前提だよね？
その状況でログイン処理に1秒ディレイを入れると何がどうなって攻撃回数が減ると主張してるの？
ボットネットのノード数より攻撃対象口座数の方が数倍以上のオーダで大きいと仮定するってーならそう言うべきだし、それ言わずに理屈は言わないけど攻撃回数が減るから効果があるんだ！とか言われても話になりませんがな。