私のサイトを調査しているように見える訪問者をブロックする必要がありますか？
サイトのセキュリティを調査する試みがいくつか検出されました。 IPアドレスをブラックリストに登録する必要がありますか？ IPアドレスをブロックするタイミングとブロックしないタイミングを決定する際に使用する考慮事項またはトレードオフは何ですか？
原則として、このタイプの防御の収益はほぼゼロです。例外はありますが、それでもこの手法ではセキュリティがわずかしか提供されない場合があります。
ランダムに選択されたホストの徹底的な脆弱性スキャンでは、スキャンリソースの収益が非常に低くなります。その代わり、成功した攻撃者は通常、次の2つのオプションのいずれかを選択してオッズを増やします。
多数のホストで非常に少数の脆弱性をチェックします
これには、SSH、POP3、cPanel、Wordpress、Joomlaなどの一般的なサービスの不正なパスワードが含まれます。 rootパスワードが「root」またはサイト管理者パスワードが「admin」である場合、これらのドリフトネットの1つに驚くほど素早く巻き込まれることが予想されます。1つの既知の脆弱性から始めて、検索手法を使用して、ターゲットリストを最も可能性の高い被害者のみに絞り込みます。
通常、これは一般的な脆弱性データベースの1つから始まります。彼は最近の候補者を見つけ、脆弱なホストでよくある文字列を特定します。多くの場合、これは「Powered by」行、ログインリンク、または特定のURLパターンです。次に、お気に入りの検索エンジンを使用して、そのパターンに従うサイトのリストを取得します。
重要な点は、これらのどちらの場合でも、攻撃者は特定のサイトで数回以上の試行を行わないことです。彼らはすぐに成功するか、先に進むかのどちらかです。
たまにしつこい攻撃者が表示されないというわけではありません。常に誤って楽観的な個人が/ 16に対してNessusを実行していますが、そのような攻撃はその性質上自己制限的であり、非常にまれに成功します。攻撃の大部分は、特定のサーバーで実行されていないソフトウェアを標的としています。
このような攻撃は成功する可能性があります？はい。それが起こることはありますか？私は平均して1日に数台の侵害されたサーバーを扱いますが、これまでのところ、1つでもnessusスタイルのフルスペクトルスキャンからのものを見たことはありません。しかし、確率は正確にゼロではありません。そして、ランダム攻撃の世界では、統計と確率は非常に重要です。
例外は攻撃がでない場合ですランダムです。高価値または高視認性のサイトを運営している場合、特にあなたに対する多くの直接攻撃を引き付けます。 Facebook、Twitter、Hotmailなどのサイトでは、異常な量の攻撃トラフィックが発生します。このタイプのサイトを扱っている場合、おそらくすでにセキュリティを非常に真剣に考えており、アドバイスを求めていません。
SQLインジェクションに関する注意：このタイプの攻撃には、いくつかの改良が必要です。大まかなスキャンでSQLエラーメッセージをキャッチした後、攻撃者は特定のサーバーに数十のクエリを送信して、ビットを中央揃えにすることができます。したがって、理論的には、クランプダウン応答はそのような攻撃を防ぐことができますが、おそらく別のIPを使用して戻るため、おそらくそうではありません。彼はあなたのサーバーですでに警告を受けているので、ブラックリストによって阻止されることはありません。より良いアドバイスは、安っぽいソフトウェアを実行しないことです。現在、パラメーター化されていないクエリを使用するための言い訳はありません。
ブラックリストを支持する議論：攻撃者の生活を困難にする可能性もあります。これは強力な防御策ではありませんが、攻撃を調査して強力な防御策を講じるのに少し時間がかかる場合があります。
ブラックリストへの反対：動的IPアドレスの場合、それらをブラックリストに登録すると、他の無害なユーザーがブロックされる可能性があります。他の無害なユーザーをブロックしていることを知らない場合もあれば、将来的に診断が難しいエラーが発生する場合もあります。さらに、ブラックリストの管理には構成が複雑になる可能性があります。
攻撃者が（サービス拒否攻撃を仕掛けるために）サイトを過負荷にすることでサイトを混乱させようとしている場合、IPアドレスをブロックすることが正しい答えとなる可能性があります。一時的なブロックで十分な場合があります。
攻撃者が調査やスキャンだけを行っている場合は、IPアドレスをブラックリストに載せる傾向はあまりありませんが、状況ごとにトレードオフを考慮に入れて、最も意味のあることについて情報に基づいた判断を下すことができます。
編集：この回答は、ログインの総当たり攻撃を考慮せず、システムの脆弱性を悪用しようとする攻撃のみを考慮しています。もちろん、5分間に30回のログインを試行するIPを一時的に禁止することは、私には正当なようです。 /編集。
リクエストをチェックしてブロックする自動システムがない場合は、サービスをハッキングしようとするIPアドレスを禁止しないでください。それらをブロックすると、それ以上リクエストを出すことができなくなりますリークがあるかどうかはわかりません。攻撃は昼も夜も行われており、攻撃が試行されている間は、ほとんどの場合、ログを監視しません。今すぐ攻撃をブロックすれば、いつか誰かがリークを発見するでしょう。
もちろん、攻撃IPをブロックすることは、セキュリティに役立つ予防策です。これは本当のセキュリティではありませんが、早期警告を発している間、攻撃を防ぐだけです可能性があります。
これを行う自動化された方法では、自動化ツールがブロックを検出しないように、デフォルトの応答（HTTP-200応答など）を返すときに利点があります。 リクエストのログを記録するの場合、後でいずれかの試行が成功したかどうかを確認できます。
ただし、これにはいくつかの問題があります。
- 攻撃はボットネット、ハッキングされたサーバー、または動的IPから来る可能性があります。遅かれ早かれ、無害なユーザーをブロックします。攻撃が成功しないことを確認するまで、少なくとも一時的にIPを禁止します。
- 特に数百のリクエストを作成する自動化された攻撃ツールが多数あるため、検出された攻撃からのすべてのリクエストをチェックするのは大変な作業です。
- おそらく何らかの方法で検出システムに依存し始めるでしょう。この種の予防策により、安全性が高まり、システムの構成（またはコードの作成）の際のセキュリティについて考えることが少なくなります。
- 検出システムが何かを見逃していないことを確認するために、時々ログファイルを時々チェックする必要があります。
- 誤検知が発生する可能性があります。簡単な例は、POSTデータ内のアポストロフィを検出する場合（攻撃ツールがSQLインジェクションを検出しようとする可能性があります）、パスワードにアポストロフィを使用しようとしているユーザーをブロックできます。これはキャプチャで解決できるかもしれませんが、標的型攻撃もキャプチャを解決します。
全体として、攻撃の試みはブロックしません。これは良いアイデアである場合があります（おそらく、何百万人もの訪問者がいる銀行やウェブサイトなどの高セキュリティ環境）。私はそれが本当に役立つとは思いません、あるいはあなたに安心感を与えるかもしれません。
唯一の例外はDoS攻撃です。ここにはセキュリティリスクはありません。悪用されているのは処理時間または帯域幅だけなので、これをブロックしない理由はありません。それでも、一時的にレート制限または禁止するだけです。これらの攻撃はボットネットから行われる可能性が高いため、ユーザーのIPをブロックします。
それは明らかにあなたのサイトが何をしているのか、IPをブロックすることのマイナス面（実際に攻撃を行わない顧客を不注意にブロックする可能性がある）、そして何かが危険にさらされるリスクに依存します（一部のユーザーが推測しやすいパスワードをサイトに持っている可能性がありますか？）
短期間のブロックは、5分から1日までの範囲で、完全に妥当なように見えます。これにより、攻撃者は1日あたり最大1000回の試行を試みることができますが、オンライン攻撃では1秒あたり最大1000回です。確かに、パスワードを忘れた正当なユーザーをブロックしないようにする必要があります。
たとえば、個人的には、地元企業のために運営しているWebサイトで、中国/ロシアからの広範囲のIPアドレスをブロックしています。 Webサイトのsshサーバーには、存在しないユーザー名で数千回のログイン試行があったことがわかりました。彼らは私のユーザー名の推測に近づいていなかったが、ランダムな高エントロピーのパスフレーズは言うまでもなく、私はその試みに満足できなかったので、それらを続行させる理由はなかった。したがって、緩い設定でfail2banをインストールしました（5回の失敗したログイン= 30分の禁止;静的IPのホワイトリスト-必要に応じて引き続きログインできます-また、RSAキーで95％の時間ログインするため、1回の失敗したログインはまれ）。私もsshポートを22から変更しました。これはポートスキャンで簡単に無効にできる隠蔽によるセキュリティです（ハニーポットを設定することはできましたが、できませんでした）が、防御の一部であれば問題ありません。深さ。これらの変更を実装すると、過去1か月間（ログの時点まで）に攻撃の数がゼロまで減少しました。
一時的にでも、IPをブラックリストに登録する前に、状況をもう少し監視します。 D.W.によって言及された短所の他に、サイトを攻撃する深刻な試みが同じIPを数回以上使用することはないと思います。結局、なりすましはそれほど難しくありません。ただし、監視に少し時間を費やした後で、その特定のIPからの繰り返しプローブを観察する場合は、絶対にブロックすることを検討します。
もう1つ注意すべき点は、プローブの性質です。問題のIPの範囲すべてが特定の時間枠内で共通の特性を共有している場合、それらが同じ攻撃者によって作成された可能性が高くなります。
最後に、攻撃が持続している場合、および/または時間に余裕がある場合、自分でプローブを繰り返すことにより、攻撃者が何を見ているかを把握しようとします。少なくとも、自分のサイトのセキュリティに関する詳細情報を入手できます。
これは「依存する」トレードオフです。
1-アクセシビリティと攻撃者の妨害の優先順位は何ですか？
任意のブロックについて、正当な使用と攻撃者をブロックしているかどうかを判断する必要があります。たとえば、IPが顧客からのものであり、そのマシンの1つがハッキングされてスキャンされた場合、自分の足で撃ち抜くのではなく、顧客に警告してセキュリティチームと協力することができます。
2-影響は何ですか？
ネットワークを公開する有用なプロトコルがオフになっていますか？攻撃者はあなたをポートスキャンしたときに何を見ることができますか？定期的に自分自身をスキャンすることは良い習慣なので、自分が何に脆弱かを知ることができます。かなりうまくロックダウンしていれば、ここでのリスクは軽微です。
また、スキャンはどのようなダメージを与えますか？正当な使用が遅くなっていますか？
-リスクの性質は何ですか？それを管理するあなたの能力は何ですか？
典型的な古典-可用性、資産または情報の妥協、組織の評判。ポートスキャンから何を失う可能性がありますか、彼らが何かを見つけた場合何を失う可能性がありますか？
そして、あなたの人員配置とそれに対処する能力は何ですか？一部のネットワークでは、ブロックを入れるのが速くて簡単ですが、他のネットワークではかなりのデューデリジェンスが必要です。あなたがそれを間違って入れた場合、害は何ですか？
私は問題に対して、IPアドレスやfail2banを禁止するのではなく、脆弱で効果のない別のアプローチを提案します。代わりに、不明なサーバー名または場所へのすべての要求が404を返すように、Webサーバーの構成を変更することをお勧めします。nginxのこの手法については、次の場所に書きました。
https://medium.com/quiq-blog/harden-nginx-from-malicious-scanners-5bd1ca9c5a5c
現時点で最も合理的なことは、そのスキャンに従い、攻撃者がアプリケーションに脆弱なものを見つけていないことを確認することです。次に、そのIPを確認する必要があります。誰かのIPアドレスをブロックすることが常に最善の解決策とは限りません。攻撃者はNATの背後に隠れている可能性があります。そのため、彼が自分のIPをさまざまなユーザーと共有すると、訪問者を失うことになります（訪問者もブロックされます）。スキャンは無実の犠牲者からも開始できます（彼のPCはボットネットの一部である可能性があります）。ただし、次のことを確認する必要があります。
- このIPは、ボット/ウェブクローラー（ほとんど常にウェブをスキャンしている）に属していません。
- このスキャンによって生成されるトラフィックは、大きな帯域幅を生成しません（またはサーバーのパフォーマンスに影響を与えません）。