アカウント名:
パスワード:
異常アクセス数の検知もしてないようなシステムなら、どんな暗証番号にしてても多少前後しようがすぐ当たるよ。
検知システムくわしくないんだけど、パスワードスプレー攻撃でも検知はできるもの？アカウント一件あたりの試行回数は少なくなるんですよね？
リバースブルートフォース対策は、同一IPアドレスからの失敗繰り返しで、そのIPアドレスを遮断する、とかですね。で、特定IPアドレス遮断は、DDoSのようにアクセス元が分散されたらもう検知できない。
そんな場合でも、ブラウザの指紋とか使えば対策できそうだけど、そういう検知をやってるところがあるかは知らない。攻撃側も本当のブラウザでアクセスするわけじゃないから、指紋が変わるようにリクエスト情報に乱数要素をいれたら、それでもどうしようもないかな。
攻撃が始まったら失敗回数が跳ね上がるから検知はできるのでは。でも検知できたとしてどうするんだろう？ログイン止めたらサービス止めるのと同じだし。BOT群からのIPアドレス遮断を厳しくやると、BOTに寄生されたアホは自業自得としても、無関係のユーザがIPSごと影響が出そうだし、2chみたいな巻き添えと思われるアクセス拒否を経験したこともない。大手は常にそういう攻撃にさらされていると思うから、何かしら方法はあるんだと思うけど。
ログイン成功でも失敗でも1秒ぐらいは時間がかかるようにするだけでもだいぶ効果ありそう攻撃受けてるときならばもちょっと伸ばしてもいいか
同一IPならね。そうじゃないなら、リバースの場合は1回しかトライしないから遅延は効果ない。
正規ユーザも含め全部遅らせるっていうアイデアです
攻撃者は応答待って順序アクセスするわけじゃないし、Botネット使うならリンクを自分が張るわけでもない。司令をバラ撒いて成功報告を待つだけ。Botノード一つが処理するリクエスト数はたかが知れているのでBotノード側のリンク数も問題にはならない。
正規ユーザがログイン遅くて苛つくだけかと。
単位時間あたりのクラック成功数がかなり減ると思いますよ
単位時間あたりに開始する攻撃試行数が同じなら同じですよ。攻撃全体の開始から結果確定の開始までが遅延時間分遅くなるけれど、結果の確定が開始したら単位時間内に試行開始した数だけ結果が得られます。むしろサーバ側でのセッション数のほうが厳しくなるでしょうね。
単位時間に受け付けるセッション数を制限する場合でも、正規ユーザは幾らか待たされた時点で別時間帯へ移動するので、ログイン試行数辺りの攻撃の比率が上がってしまいますね。正規ユーザが弾かれない状態っていうのは攻撃側の消費セッション数を超える許容セッション数を設定した時のみです。正規ユーザがまともに使えないなら攻撃者の為にサービスするような物ですし、正規ユーザが不便を受けないようなら既に攻撃者の需要は満たしているでしょう。
そら攻撃回数が同じならね
？？？同一IPアドレスからの多量ログイン要求とかは楽に弾けるから、ボットネットなどを使って分散して多量のログイン要求してるってのが前提だよね？その状況でログイン処理に1秒ディレイを入れると何がどうなって攻撃回数が減ると主張してるの？
ボットネットのノード数より攻撃対象口座数の方が数倍以上のオーダで大きいと仮定するってーならそう言うべきだし、それ言わずに理屈は言わないけど攻撃回数が減るから効果があるんだ！とか言われても話になりませんがな。
串経由だとIP判定は厳しい。認証エラー検知しても特定対象のみブロックは難しいしサービス停止はさすがに無理。認証後の時間設定しても攻撃者は多数のPC（もしくはツール？内で複数セッション）を使うだろうからn秒後に処理がずれるだけで正規ユーザに怒られない程度の遅延では対処としては弱いかも。
同じパスワードで何度もアクセスしてますね、が難しいのも今回の苦労の点。
全通り試すのに十分なぐらいセッションが使われてればそうなんですけど、100台とかで期待クラック時間が数分、とかの時は効きそうな気がしません?0.1秒が1秒になれば10倍クラックにかかる時間が伸びますし
何なら「セキュリティ確認中です…」とか出して10秒かけたっていいかも
ドラクエ10みたいなネトゲがそのパターン。攻撃者は並列処理でいくし、普通のユーザーがイライラするだけｗ
こんなレベルで戦ってる人たちに10秒遅延させますねｗｗｗｗとか言ったら殴られるぞ。https://blog.ideamans.com/2019/03/web-performance-phrases.html [ideamans.com]
たとえば工場のラインを想像してもらえると分かるけど、時間がかかる製品も稼働してしまえば時間がかかるのは最初だけで、その後は毎日生産何万台って事もできるわけ。
今回はバッチなりなんなりでずーっとPC認証させておけばよいのでときどき様子見して成功した口座を犯人がログインして残高いっぱい引き出せば成功なの。10秒なんて痛くもないわけ。
横からですまんが教えてやろうトライにかかる時間が1/100になれば同じ時間かけて攻撃されても被害は1/100になるんや、すごいだろう?1万件の被害が100件になる採算ラインを割るならもう攻撃もされなくなるんやで!!びっくりだよなぁなんと工場もそうなんだ!!大量にラインがあっても制作にかかる時間が1分のものは100分のものより100倍もたくさん作れるんだよこれまたびっくりだよねだからトヨタとかも速度を重視してるんだよくわかったかな?
ぜんぜんわかんない#3890973は工場のラインのこといってるんだろうなってわかる。工場のラインって書いてるしな
IPの検知・自動遮断は、実際組み込んだこともある（商用サービス）。
遮断の期間は数時間とか？それぐらいなら遮断されたアドレスを割り振られた無関係のユーザが拒否られることも少なそう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:0)
異常アクセス数の検知もしてないようなシステムなら、どんな暗証番号にしてても多少前後しようがすぐ当たるよ。
Re: (スコア:0)
検知システムくわしくないんだけど、パスワードスプレー攻撃でも検知はできるもの？アカウント一件あたりの試行回数は少なくなるんですよね？
Re: (スコア:0)
リバースブルートフォース対策は、同一IPアドレスからの失敗繰り返しで、そのIPアドレスを遮断する、とかですね。
で、特定IPアドレス遮断は、DDoSのようにアクセス元が分散されたらもう検知できない。
そんな場合でも、ブラウザの指紋とか使えば対策できそうだけど、そういう検知をやってるところがあるかは知らない。
攻撃側も本当のブラウザでアクセスするわけじゃないから、指紋が変わるようにリクエスト情報に乱数要素をいれたら、それでもどうしようもないかな。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:0)
攻撃が始まったら失敗回数が跳ね上がるから検知はできるのでは。でも検知できたとしてどうするんだろう？
ログイン止めたらサービス止めるのと同じだし。
BOT群からのIPアドレス遮断を厳しくやると、BOTに寄生されたアホは自業自得としても、
無関係のユーザがIPSごと影響が出そうだし、2chみたいな巻き添えと思われるアクセス拒否を経験したこともない。
大手は常にそういう攻撃にさらされていると思うから、何かしら方法はあるんだと思うけど。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:2)
ログイン成功でも失敗でも1秒ぐらいは時間がかかるようにするだけでもだいぶ効果ありそう
攻撃受けてるときならばもちょっと伸ばしてもいいか
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:1)
同一IPならね。そうじゃないなら、リバースの場合は1回しかトライしないから遅延は効果ない。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:2)
正規ユーザも含め全部遅らせるっていうアイデアです
Re: (スコア:0)
攻撃者は応答待って順序アクセスするわけじゃないし、
Botネット使うならリンクを自分が張るわけでもない。
司令をバラ撒いて成功報告を待つだけ。
Botノード一つが処理するリクエスト数はたかが知れているので
Botノード側のリンク数も問題にはならない。
正規ユーザがログイン遅くて苛つくだけかと。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:2)
単位時間あたりのクラック成功数がかなり減ると思いますよ
Re: (スコア:0)
単位時間あたりに開始する攻撃試行数が同じなら同じですよ。
攻撃全体の開始から結果確定の開始までが遅延時間分遅くなるけれど、
結果の確定が開始したら単位時間内に試行開始した数だけ結果が得られます。
むしろサーバ側でのセッション数のほうが厳しくなるでしょうね。
単位時間に受け付けるセッション数を制限する場合でも、
正規ユーザは幾らか待たされた時点で別時間帯へ移動するので、
ログイン試行数辺りの攻撃の比率が上がってしまいますね。
正規ユーザが弾かれない状態っていうのは
攻撃側の消費セッション数を超える許容セッション数を設定した時のみです。
正規ユーザがまともに使えないなら攻撃者の為にサービスするような物ですし、
正規ユーザが不便を受けないようなら既に攻撃者の需要は満たしているでしょう。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:2)
そら攻撃回数が同じならね
Re: (スコア:0)
？？？
同一IPアドレスからの多量ログイン要求とかは楽に弾けるから、
ボットネットなどを使って分散して多量のログイン要求してるってのが前提だよね？
その状況でログイン処理に1秒ディレイを入れると何がどうなって攻撃回数が減ると主張してるの？
ボットネットのノード数より攻撃対象口座数の方が数倍以上のオーダで大きいと仮定するってーならそう言うべきだし、それ言わずに理屈は言わないけど攻撃回数が減るから効果があるんだ！とか言われても話になりませんがな。
Re: (スコア:0)
串経由だとIP判定は厳しい。
認証エラー検知しても特定対象のみブロックは難しいしサービス停止はさすがに無理。
認証後の時間設定しても
攻撃者は多数のPC（もしくはツール？内で複数セッション）を使うだろうから
n秒後に処理がずれるだけで
正規ユーザに怒られない程度の遅延では対処としては弱いかも。
同じパスワードで何度もアクセスしてますね、が難しいのも今回の苦労の点。
Re:8文字以下なら偏りなんかほとんど意味ないでしょ (スコア:2)
全通り試すのに十分なぐらいセッションが使われてればそうなんですけど、
100台とかで期待クラック時間が数分、とかの時は効きそうな気がしません?
0.1秒が1秒になれば10倍クラックにかかる時間が伸びますし
何なら「セキュリティ確認中です…」とか出して10秒かけたっていいかも
Re: (スコア:0)
ドラクエ10みたいなネトゲがそのパターン。攻撃者は並列処理でいくし、普通のユーザーがイライラするだけｗ
Re: (スコア:0)
こんなレベルで戦ってる人たちに10秒遅延させますねｗｗｗｗとか言ったら殴られるぞ。
https://blog.ideamans.com/2019/03/web-performance-phrases.html [ideamans.com]
Re: (スコア:0)
たとえば工場のラインを想像してもらえると分かるけど、
時間がかかる製品も稼働してしまえば時間がかかるのは最初だけで、
その後は毎日生産何万台って事もできるわけ。
今回はバッチなりなんなりでずーっとPC認証させておけばよいので
ときどき様子見して成功した口座を犯人がログインして残高いっぱい引き出せば成功なの。
10秒なんて痛くもないわけ。
Re: (スコア:0)
横からですまんが教えてやろう
トライにかかる時間が1/100になれば同じ時間かけて攻撃されても被害は1/100になるんや、すごいだろう?
1万件の被害が100件になる
採算ラインを割るならもう攻撃もされなくなるんやで!!
びっくりだよなぁ
なんと工場もそうなんだ!!
大量にラインがあっても制作にかかる時間が1分のものは100分のものより100倍もたくさん作れるんだよ
これまたびっくりだよね
だからトヨタとかも速度を重視してるんだ
よくわかったかな?
Re: (スコア:0)
ぜんぜんわかんない
#3890973は工場のラインのこといってるんだろうなってわかる。工場のラインって書いてるしな
Re: (スコア:0)
IPの検知・自動遮断は、実際組み込んだこともある（商用サービス）。
Re: (スコア:0)
遮断の期間は数時間とか？それぐらいなら遮断されたアドレスを割り振られた無関係のユーザが拒否られることも少なそう。