IPアドレスに基づいて特定のページを提供することは可能ですか？

8

私は自分が所有する2つのWordPressサイトに対するブルートフォース攻撃の標的にされてきました。攻撃者は古き良きXML-RPCを使用して、ブルートフォースパスワード攻撃を増幅しています。幸い、私たちは非常によく生成されたパスワードを持っているので、彼がこれまでどこにでもアクセスすることはないと思います。

私はiptablesを使用して彼が再びポップアップするたびに（常に同じ仮想クラウドプロバイダーから）要求をブロックしましたが、サーバーを変更して、彼のIPアドレスがページを要求するたびに、彼に応答を返すようにします命を得るために。リクエストのほとんどはPOSTであるため、理想的には、応答ヘッダーを変更して、「次回は幸運を祈る」などの内容を含めるようにします。または同等に満足できる何か。

これは可能ですか？私はApacheの専門家とはほど遠いので、これを実装するのがどれほど難しいかはわかりません。しかし、それが私に数時間かかるとしても、満足は貴重です。

参考までに、私はWordpress 4.7.3をホストするApache 2.4.18でUbuntu 16.04.2 LTSを実行しています。

apache-2.4 http-headers

— アウレリウス
ソース

「常に同じ仮想クラウドプロバイダーから」 OVH？なんらかの理由で多くのスクリプトキディがサービスを使用していることに気づきました。

— hd。

いいえ、online.net ...これまでのところ、私の虐待レポートの1つに応答していません。また、初めて嫌がらせリクエストを送信したところ、苦情が自動的にお客様に転送されることがわかりました。したがって、彼は私の個人的なウェブサイトをどのように見つけたのか。良い仕事、online.net ....

— アウレリウス

25

fail2banを適切なjailと共にインストールして、それで完了です。見られない可能性が最も高いので、カスタムレスポンスを指定する必要はありません。

— EEAA
ソース

1

確かに。しかし、これは間違いなく私がずっとやりたかったことです。たとえ彼がそれを見たことがないとしても、その可能性だけで私は一生懸命に笑い、私は泣きそうになります。

— Aurelius

14

まあ：1）私見は、スクリプトキディにささいな侮辱を表示する方法を理解することはここではトピック外です。2）これを行うと、apacheリソースが消費されますが、fail2ban / iptablesは上流のリクエストをブロックするため、アプリケーションで処理する必要はありません。

— EEAA

1

確かに。しかし、私は永久禁止の前に少し楽しみたいです。ささいなことでも、ほんとに笑いたいだけなのですが、これは業務をしている人がサーバーを使っている人の要望です。

— Aurelius

4

@Aurelius、あなたがIPを知っていて、この人がマスクしていない場合は、アプリ自体、この場合はphpでこれを実行しないのはなぜですか。IP xx.xx.xx.xxであるかどうか、および応答でスクリプトを強制終了するだけであるかどうかを確認してくださいdie("blah blah");

— Miguel

答えとして受け入れられました。これは、主にfail2banについて知らなかったためです。上記のMiguelの回答と以下のBlackWebWolfの回答は、どちらも調査対象です。

— Aurelius

5

考えられる攻撃を元に戻す可能性があります。iptablesを使用して、クラウドプロバイダー（アドレス範囲）を別のポートにリダイレクトします。プレーンヘッダーであっても、攻撃者に応答を提供します。

Apacheでは、例によってヘッダーを変更できます。

Header set GetOut "Better luck next time!"

— BlackWebWolf
ソース

へへへ！今それが私が話していることです。良いアイデア！これを調べます。

— Aurelius

5

この戦略はおそらく応答を逆火します。攻撃者は何が機能して何が機能していないかを知ることができるため、サイレントでリクエストを何も通知せずに渡して、ボット攻撃ソフトウェアのアラートフラグを作動させない方がはるかに優れています。たとえば、リクエストされたページのHTMLを返すのが理想的です。彼らはあなたが彼らを捕まえたことを決して知らず、何も起こらず、あなたのサイトはより安全です。彼らに知らせたいという衝動に抵抗します。それは常に間違いです。問題をデバッグするのに役立ちます。あなたの場合、より動的なIP範囲などに切り替えるだけで、問題の解決がはるかに難しくなります。

— Lizardx 2017年

1

あなたは正しい、それは推奨されません-それはおそらく危険です。ハニーポットを使用した戦略は常に優れていますが、問題は明確でした-攻撃者をトロールする方法:)

— BlackWebWolf 2017年

それが間違いかどうかは気にしません-fail2banをインストールしたので、彼はとにかく禁止されます。彼が実際にどこにでも行くことを私は強く疑います。私の知る限り、WordPressの最近のリリースで実際にこのセキュリティバグが修正されましたか？言うまでもなく、20文字を超えるパスワードをブルートフォースで強制する...ええ、私たちの宇宙の存続期間中には発生しません。

— Aurelius

これは、phpの非推奨のmysql_拡張機能を実装する方法を尋ねる人に似ていますが、実際の答えは正しく実行することを意味するため、その答えは間違っています。私たちの多くが過去にも行ってきた概念であり、トローリングのような反応は大きなネガティブ以外のものであり、修正する必要があります。これは重大な間違いであり、その間違い、人は質問が間違っていた理由をすぐに理解するでしょう。

— Lizardx 2017年

3

これは、Apache用のサードパーティのWAFモジュールであるModSecurityを使用すると非常に簡単です。ただし、ルール言語の構文を学習する必要があります。

また、ModSecurityを使用して、まったく応答せずに接続をドロップすることもできます。

他の人が示唆しているように、これだけのためにModSecurityをインストールすると、応答が無視される可能性が高いため、やり過ぎになる可能性があります。

— バリー・ポラード
ソース

2

私はfail2banを使用し、既知の悪用場所からのリクエストをドロップします。また、攻撃者のサービスプロバイダーのせいではないと思われる場合は、攻撃を悪用メールアドレスに報告してください。

攻撃者の速度を低下させるものを作ることに時間を費やしたい場合は、ターピットを作ってみるとよいでしょう。最初に、もちろん攻撃がどこから来ているのかを知る必要があります。次に、Apacheを使用して、リクエストをip（範囲？）から特定のスクリプトにリダイレクトできます。私自身は試していませんが、これでうまくいくかもしれません。次に、たとえば、15秒ごとにドット（または/ dev / nullの何か）を出力するスクリプトを実装して、攻撃者の接続を無期限に開いたままにします。

攻撃者はスクリプトを使用してサイトを攻撃している可能性が高いため、攻撃が停止していることに気付くまでに時間がかかる場合があります。接続はすべてアクティブに見えるため、タイムアウトは発生せず、リクエストはその場で拒否されません。

問題は、あなたが時間とリソースを、より重要な懸念事項としておそらく役に立たないもの、つまりログインの保護に費やすことです。どこを攻撃すればいいかわからないときは、攻撃するのは難しいです。以下のいくつかを検討してください。

ログインページへのアクセスを制限します（イントラネットのみですか？IP範囲？vpn？その他？）。
ログインにreCaptchaまたはその他の確認用の質問を追加します。
多要素認証を使用します。
ログインページを非表示にします。可能であれば、メインページからリンクしないでください。また、/ loginやその他のわかりやすい場所を使用しないでください。

— コミュニティ
ソース

情報をありがとう！したがって、明確にするために、A）ログインできる2人のユーザーはランダムに生成された長いパスワードを持っています。B）ログインページに一種のキャプチャがあります。C）そのページへのアクセスを防ぐために.htaccessを機能させようとしています。ただし、.htaccessの標準は何度も変更されているようです。私は至る所で異なる構文を見続けており、今のところhtaccessはほとんど機能していません。

— Aurelius

また、すべての攻撃をonline.netに報告しましたが、まったく応答がありませんでした。

— Aurelius

htaccessの便利なヒント：stackoverflow.com/questions/6441578/…（ダイジェスト認証を強くお勧めします）。

このページのコメントを見ると、ダイジェストは素晴らしいアイデアのように思えませんか？httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

— Aurelius

1

参りました。はい、ダイジェスト認証を使用していたときから、httpsがどこにもないことを思い出しました。htaccesパスワードを使用しない理由は、それが長期的な解決策ではないためです。公開の1週間前に何かを非表示にするために使用してもかまいませんが、日常的に使用する場合は、別のレベルのパスワードは必要ありません。それほど安全ではありません。公共のインターネットにまったく表示されないリソースが配置されている場合、私たちは正しい軌道に乗っています。