📛 🧑🏻 🏑 「悪い」URI、スパマー、PHPシェルとの戦い-個人的な経験 🤵🏼 🌟 👨🏻‍🎤

私はすべてのウェブプログラマーがある程度同じように進んでいると信じています。私は私の個人的な経験に基づいています。私にとって、この科学の理解の初めに、最初にサイトの作成がありました。かなりの時間を経てようやく、サイトもオープンしていることに気付きました。これを行う方法を読んだ後、私は経験が浅いために自分のサイトを「入り口の庭」に変えることがどれほど簡単であるかに驚き、セキュリティに注意を払い始めました。少なくとも、ページの入力パラメーターのフィルター処理を開始しました。

第2段階では、PHPシェルなどの動物がいることに驚きました。大好きなサイトへのアクセスをブロックしたときに、カスペルスキーはこれを手伝ってくれました。次の啓示は、あなただけでなく、主催者もそれを開くことができるということでした。同時に、シェルは驚くほど規則的にサイトに表示されます。どこから来たのかはわかりません。もちろん、彼らが望むことをします。たとえば、 .htaccessファイルを編集し、所有者を含む全員の編集を閉じます。

これらのすべての啓示には一度に膨大な土曜日と日曜日がかかり、URLの書き換えに切り替え、疑わしい単語や表現の入力パラメーターを分析するための詳細なシステムを作成する必要がありました（ここで、ちなみに大失敗に見舞われました）。サイトで発生する不審なイベントについて警告し、最後に、 template.phpやwso2.phpのような他のスクリプトが起動されないように、名前に特定のプレフィックスを持つスクリプトのみを実行する許可。

覚えておく必要があることと、比較的安全なサイトを作成するためにできることは何ですか？

異なるタイプのファイルを別々のフォルダーに入れる必要がありますか？

PHPで作成された最新のサイトは通常、かなり広範なファイル構造を持っています。 include / require命令、 .cssおよび.jsファイル、およびページキャッシュに含まれる実行可能スクリプト、モジュール、またはクラスが間違いなくあります。簡単にするために、これらのファイルに限定します。

私はサブタイトルで質問されたと思う、私は肯定で答えます、それは非常に便利です。したがって、たとえば、PHPのインクルードファイルは、サーバーによる処理とブラウザーへの出力を要求するようには設計されていません。このタイプのフォルダーには、誰もが何かにアクセスすることを拒否する特別な.htaccessファイルがあります。

Deny from all

.cssおよび.jsファイルが含まれるフォルダーでは、これを購入する余裕はありませんが、これらのフォルダーの種類によってアクセスを制限できますが、これも悪くはありません。以下は、拡張子が.jsのファイルを除くすべてのファイルへのアクセスの禁止です

 Deny from all <FilesMatch "\.js$"> Allow from all </FilesMatch>

私の経験では、このような制限はサイトの実際のセキュリティに実質的に影響を与えず、一般的なTo Doリストの1ティックのみです。私自身はこれらの方法を使用していません。これについては以下で説明します。しかし、一方で、これも最小限の労力で済みます。繰り返しますが、もしクレイジーなロボットがあなたに反抗すると、それはトラクターのように突き出して、すべてを台無しにします。特定の拡張子を持つファイルのみがフォルダー内にあることがわかっている場合、悪意のあるエイリアンの検出が容易になります。

個人的に、私はもう少し進んだ。私の.cssファイルと.jsファイルは圧縮されてキャッシュされるため、ソースが置かれているフォルダーはすべてのユーザーから閉じることができます。要求されたキャッシュ自体は、ロボットが届かない可能性がある、かなり深く埋まっているフォルダーにあります。ちなみに、サイト全体に対して実行可能なスクリプトは1つしかありません。しかし、それについては後で。

非標準的な方法でフォルダに名前を付ける必要がありますか？

ところで、ここで、あなたのサイトのセキュリティを本当に高める良い方法です。事実、悪意のあるロボットはサイト上で特定の名前のフォルダーを探しています。同じことがファイルにも当てはまります。したがって、セキュリティを強化する手段の1つとして、これはフォルダーとファイルの名前を非標準のものに変更することです。独自の何かを発明し、少なくともプレフィックスを名前に付けることは価値があります。プレフィックスは間違いなくロボットの助けになります。手動でのハッキングをより困難にしたい場合は、先に進み、フォルダーとメインファイルに適切な名前（Petya、Mashaなど）を付けることをお勧めします。若いハッカーの多くは、あなたの身に何があるのかを理解しません。退屈に突入するハッカーは、頭の中にどんな種類の混乱があるのかを知りませんが。しかし、間違いなくチャンスがあります！主なことは混乱しないことです。また、かなりのチャンス。

クリアテキストでデータベースにアクセスするためのパスワードを含むconfig.phpファイル

これはまったく理解できないことです。誰もが呼ばれていることを誰もが知っているファイルがあり、プレーンテキストにはハッカーがまさに必要としているものがあります。なぜこれが行われるのですか？私の意見では、これはある種の妨害行為です。すべてのサイトのデータベースにアクセスするためにデータを暗号化し、完全に非標準の名前付きファイルに配置することを強くお勧めします。このファイルはネットワークアクセスから閉じられ、読み取り専用です。もちろん、復号化速度の最適化に取り組む必要がありますが、これも完全に解決可能です。少なくともXORは非常に高速です（記事の最後にあるVernam暗号へのリンク）。主なものは、適切な長さのキーを持ち、それをより良く隠すことです。本当に紛らわしく、非常に効果的な復号化アルゴリズムを作成し、ハッカーがキーとそれを使用するアルゴリズムの両方を見つけることができるようになるまで、ハッカーにサイトで何時間も費やすことを強制できます。独自のロギングおよび通知システムのおかげで、悪意のあるアクティビティが時間内に表示され、攻撃者のアクティビティを停止し、キー、パスワード、外観などを変更します。したがって、ハッカーの意識を失う前にスクリプトをダウンロードして処理することは非生産的です。

セキュリティPHPスクリプトの実行

非常に重要なトピック。まず、パブリックホスティングを実際に開くことができ、コード名template.phpのファイルがどこからでもサイトに表示されると言います。しばらくしてから（たとえば10分後）すばらしいログおよび通知システムが、そのようなフォルダー内のそのような新しいファイルの出現を判断し、これについての手紙を送ったとします。それは素晴らしいようです！しかし、シェルは、サイトで数時間出かけるようなものを10分間で実行できます。通り過ぎました。私たちは何を話しているのか知っています。

そして、この非常に重大なセキュリティの脆弱性は、ほとんどのエンジンに影響を及ぼします。たとえば、 my_template.phpなどの任意の名前のファイルを作成し、その中に配置します

 <?php echo 'hi!';

次に、 WordPressサイトのルートに配置して、スクリプト（スクリプト）を呼び出します。そして、おそらく動作します！あなたの挨拶が表示されます！

これは私とこの悪に対処する方法の進化が起こったものです。しかし、私は無料の（そして有料の）エンジンには取り組みませんし、私にとっても簡単です！

最初に、特定のプレフィックスを持つファイルのみを起動できるURLの書き換えを行いました。次のように機能します。疑わしい呼び出しを一切行わないサイト自体では、悪意のあるファイルがプレフィックスなしで表示されます。あなたは暗闇の中にとどまります。次は、この新たに植えられたファイルにアクセスする試みです。プレフィックスはなく、開始もされず、すぐに、それについての手紙を受け取ります。サイトにアクセスして、シェルを確認し、リクエストされたIPをブロックし、ホスティングに手紙を書き、すべての従業員を耳に抱きます。すべてがうまく終わるようです。「高度に芸術的であると同時に面白い」形式の記事へのリンクは、地下室で示す問題と解決策を説明しています。

シェルランディングがあります。これは、よりインテリジェントですが安全なアルゴリズムに従って実行されます。ホスティングログは限られた時間、ほとんどの場合1週間保存されることが知られています。攻撃者がサードパーティのファイル、つまりシェルスクリプトをサイトに配置し、1週間を少し過ぎたままにします。脆弱性が表示されていたログが消え、使用された脆弱性を特定できません。しかし、私たちの場合、数分以内に、サイトのファイル構造に見知らぬ人が出現したという通知を受け取ります。そのため、この一見洗練された移植方法は、私たちにとってより望ましいものです。

説明されたシステムは長い間私と一緒に住んでおらず、正常に交換されました。その結果、次のスキームに到達しましたが、今日ではそれが理想に近いと考えています。

そこにあったすべてのURL書き換えルールを.htaccessから削除し、サイト上の1つの切断された実行可能スクリプトにファイルが送信するルールを1つだけ残します。少なくとも名前のような特別な、接頭辞があります。 REQUEST_URIのこのスクリプトは、それが何をもたらしたかを理解し、書き換えのためにあらゆる種類のseo-actionsを実行し、制御を転送するスクリプトを決定します。もちろん、コントロールは書き換えによってではなく、ファイルをrequireステートメントに接続することによって転送されます。その結果、サイトへのアクセスは全員に許可されますが、実行可能なphpスクリプトは1つだけ実行されます。他のすべてのスクリプトは別のフォルダーにあり、ネットワーク要求から保護されており、すべての指示から拒否することで保護できます。そして、そうではないかもしれません。

ところで、このようなスキームは一部のエンジンで使用されています。しかし、すべては1万行以上のメガスクリプトindex.phpによって制御されており、このスキームはセキュリティのためではなく、略奪からコードを閉じやすくするために実装されています。

ここに私の.htaccessのルールがあります

 RewriteCond %{REQUEST_URI} !^/sitemap\.xml$ RewriteCond %{REQUEST_URI} !^/favicon\.ico$ RewriteCond %{REQUEST_URI} !^/apple-touch-icon(?:\-precomposed)?\.png$ RewriteCond %{REQUEST_URI} !^/robots\.txt$ RewriteCond %{REQUEST_URI} !^/pref_dispatch\.php$ RewriteRule ^.*$ /pref_dispatch.php [L]

私たちは間違いなく持っている特定のファイルを完全にスキップし、例外のないすべてのリクエストはphpスクリプトだけでなく、ディスパッチスクリプトに転送されることに注意してください。ところで、ディスパッチャでrobots.txtとsitemap.xmlの両方を生成し、スクリプトとして送信することができます。そして、あなたができると写真...

ディスパッチャーのチェックに合格しないURLで何が起こりますか？

「 bad uri log 」に記録されます。時々、このログを見て、禁止されているURIが禁止されているかどうか、リダイレクトするかどうかを判断します。悪いuriログは、管理領域で最も便利で面白いツールの1つとして定着しています。誰が壊れているのか、どこで壊れているのか、そして一般的に今日のハッカーにとって何がおもしろいのかがすぐにわかります。もちろん、 wp-adminとwp-configが最初の場所にあります。無料のエンジンを愛する人が考えることは何かあります。

サイトのルートからだけでなく、すべてのフォルダから収集された不良URIを作成する方法は？

bad uriログでは、 / very-bad-uri- script.phpまたは/ very-bad-uri-folder /という形式のURIが該当します。ただし、uriが/ existent-folder / very-bad-uri-folder /のように見える場合、このuriはログに記録されない可能性があります。さらに、最良の場合、エラーログには、 File does not existというような行が表示されます：/ existent-folder / very-bad-uri-folder /

/ existent-folderフォルダのすべてのユーザーに対してすべてを無効にすると、 クライアントがサーバー構成によって拒否されたなどのエラーが発生します。

どちらもあまり便利ではありません。実際、エラーログに該当する呼び出しはアクセスログに該当せず、詳細は表示されません。最も不愉快なことは、サイトで不審な活動があった場合、いかなる手紙も受け取らないことです。このような迷惑は、 / existent-folderフォルダーに .htaccessファイルがまったくないか、URLの書き換えが含まれていないために発生します。これを防ぐには、まず全員にこのフォルダーへのアクセスを許可する必要があります。つまり、 Deny From All行を削除し、次にURL書き換えを有効にします。

 RewriteEngine on RewriteBase / RewriteRule ^.*$ /badurl/ [L]

要求されたファイルは、可能なすべての詳細とともにすぐに不良uriログに直接送信されます。このイベントに関する行はアクセスログに分類され、エラーログには分類されません。警告システムから手紙を受け取りますが、もちろん、この機能をプログラムした場合は。

上記の.htaccessは、「 すべてから拒否 」機能を置き換えるのに適しています。何かをスキップする必要がある場合（jsスクリプトやスタイルシートなど）、特定の種類のファイルの要求を許可するか、スクリプトに特別な名前またはプレフィックスを付ける必要があります。さて、またはスキップされたファイルを明示的にリストしてください。しかし、生産性の面でもプログラマーとサーバーの面でもこれはすでに難しすぎると思います。

悪意のあるIP攻撃とブロック

時々、驚くほどの規則性で、サイトで攻撃が発生します。これらの攻撃の中には、特定のIPからユーザーのログインページと登録ページが鳴り、フォームを介してレターを送信し、広告を受信する攻撃があります。これはメールサーバーです。これらはほとんどの場合、「クリーン」なIPと組み合わせて機能します。これらは攻撃には使用されず、ダイヤルにのみ使用されます。スパムを処理するIPの性質を判断するために、私自身はprojecthoneypot.org Webサイトを使用し、強く宣伝しています。

このようなスパマーとの戦いは非常に簡単であることが判明しました。これらすべてのフォームをajaxで実装するだけで十分です。これだけですでに十分です。セキュリティを強化するために、PHPバックエンドがサイトから来ていない場合に呼び出されるのを防ぐことができます。

非常に大量のトラフィックは、疑わしいボットから発生します。なぜ疑わしいのですか？これらのボットがサイトに役立つかどうか、そして何年も前に使用されなくなったURLを呼び出して自分のサイトにアクセスする理由がわからないからです。一般的に、長いデッドURLの出現自体は、ボットにとって妥協的なアクションです。そのようなボットは、ほとんどの場合、robots.txtファイルを使用しないか、逆方向で使用します。つまり、表示が禁止されているアドレスのリストが存在することが破壊の理由です。ただし、これらのボットはユーザーエージェントで正直にマークします。これらのうち、 199.192.207.146という名前をエージェントに付けることができます

  Mozilla / 5.0（互換性あり; MJ12bot / v1.4.5; http://www.majestic12.co.uk/bot.php?+）

またはエージェントとの185.53.44.90

  Mozilla / 5.0（互換性あり; XoviBot / 2.0; + http：//www.xovibot.net/）

上記の例のIPは実際のものですが、これらのボットには1つのIPアドレスではなく、多くのIPアドレスがあることが明らかです。

善を装うボットもありますが、そうではないようです。ここで、たとえば、 エージェントを含む176.31.182.56

  Mozilla / 5.0（互換性; Googlebot / 2.1; + http：//www.google.com/bot.html）

私のサイトでのこのIPの効果については、それが本当にGooglebotであるという大きな疑問があります。

最後に、私は本当にbingbotが嫌いです。彼は非常にずさんです。彼は、存在しないURLのサイトに急ぐのが大好きです。彼がこれらのURLをどこでどのベースで使用するかを考えなければ、すべてがうまくいくでしょう。なぜ、彼はそれらをベースから削除しないのですか？私の態度にもかかわらず、私はこの獣をブロックしていないことは明らかです。

しかし、スパムを特に狙った攻撃はありません。リクエストは毎秒数個の速度でストリーミングでき、完全にナンセンスです。多くの場合、サイト自体への要求が台無しにされたり歪められたりし、WPがリードするエンジンを攻撃することがよくあります。一連のリクエストは、通常、1日に1つのシリーズで100から200個までです。なぜエンジンに侵入するのか-わかりました。わからない、しばしば読めない歪んだURLにサイトを反応させようとする理由。しかし、実際には、高速で多くのリクエストを送信すると、サイト自体とその近隣のホストが遅くなり、それらと戦う価値があります。

ところで、「判読不能なURL」とは何ですか？そして、これは何ですか！

 http://-.ru/bulletin_board/ad_add/+++++++++++++++++++++++++++++++++++++Result:+%ED%E5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%F0%E0%E7%EC%E5%F9%E5%ED%E8%FF;+Result:+%ED%E5+%ED%E0%F8%EB%EE%F1%FC+%F4%EE%F0%EC%FB+%E4%EB%FF+%F0%E0%E7%EC%E5%F9%E5%ED%E8_cutted

このURLでこのサイトに実際にアクセスしようとしないでください。この場合、IPは危険とマークされ、侵害されます。

まず、URLの長さは255文字を超えているため、切り捨てる必要がありました。第二に、「結果：」という語に続くすべてがデコードされます（windows 1251）が、それはナンセンスです。 XoviBot / 2.0がこのURLを要求しているのではないかと疑われており、比較的大量の場合でも常に同じです。

しかし、戦う方法は？そして、すべてを連続してブロックすることは価値がありますか？このプロセスを戦うのが困難な場合、おそらくそれは進んでいくことができますか、何らかの形でそれに適応することができますか？

残念なことに、私は悪いIPのサイクルが本質的に何であるか、悪いIPが良いものになり、良いものが悪いものになるかどうかはわかりません。したがって、ブロックする場合は、手動モードで実行します。 IP所属が私のロシア語のウェブサイトが読まれそうにない国からのものであり、活動が困難すぎる場合、これらのIPをブロックします。私は残ります。

私のセキュリティシステムには、悪いuriログだけでなく、悪いuriを引き起こしたIPログもあります。このリストでは、スパム、危険、ブロックされたIP、ブロックされていないIP、およびボットが考慮されます。

ブロックされたIPから入力すると、クライアントは特別なページに移動し、ボタンをクリックしてIPのロックを解除するよう招待されます。ボタンはajaxです。ロックレコードは自動的に「Unblocked IP」に変わります。現在、約20個のIPがブロックされています。少なくとも1つはユーザーによってロック解除されましたか？いやそうではなかった。多くの場合、すでにブロックされたIPからの呼び出しがありますか？いいえ、めったに危険にさらされていません。

何らかの方法でマークされているIPから到着するすべてのクライアントについては、要求の追加処理は実行されません。それらの場合、必須のバックスラッシュの存在はチェックされず、リダイレクトのリストはチェックされません。それらの場合、SEOアドレスの変換は機能しません。要求が完全に良好でない場合、すぐに、遅滞なく、短い別れが表示されます。

しかし最近、ブロッキングシステムを改善することができると考えています。特定のIPからの一連の要求フローが検出され、1時間ブロックされた場合、おそらく便利です。 IPブロッキングと標準送別の出力の処理時間がほぼ同じになるように、悪いuriを処理するためのスキームを既に最適化したのではないかと心配しています。

まとめ

上記では、あらゆるサイトのセキュリティの程度を大幅に高めることができるかなり単純なアクションについて説明しています。私の質問は残っています-なぜこれらの単純なものが含まれていないのですか、エンジンがないのですか？有料でも無料でもありませんか？

「悪い」URI、スパマー、PHPシェルとの戦い-個人的な経験