クロールや混oticとした集中クエリからサイトを保護する

激しいカオスリクエストは、サーバーとトランスポートチャネルに大きな負荷をかけ、サイトの速度を大幅に低下させます。 スキャンの助けを借りて、サイバー犯罪者はサイトのコンテンツをコピーし、その保護の弱点を特定し、かなりの損害を引き起こします。 さらに、クロール中に行われたサイト要求もパフォーマンスに悪影響を及ぼします。 ほとんどの場合、サイトの動作が遅いという問題は、トラフィックの多い大規模なポータルに関係しています。 ただし、トラフィックが少ない場合でも、サイトは高いトラフィックにさらされる可能性があるため、小規模サイトに影響を与える可能性があります。 高負荷は、サイトを常にクロールするさまざまなロボットによって作成されます。 同時に、サイトの速度が大幅に低下するか、まったく利用できない場合があります。



サイトは 、プログラム、サードパーティのサイト、または手動でスキャンされます。 これにより、短時間で大量のリクエストが作成されます。 サイトスキャンは、ほとんどの場合、脆弱性の検索やサイトコンテンツのコピーに使用されます。



サイトをスキャンから保護するためのかなり効果的な手段は、サイトリソースへのアクセス権の制限です。 サイトの構造に関する情報は、Apacheモジュールmod_rewriteの変更リンクを隠すのに役立ちます。 また、リンクスキャンを無効にし、同時に負荷を減らすには、1人のユーザーから頻繁に送信されるリクエスト間の時間遅延を設定すると役立ちます。 スキャンや混chaとした集中リクエストに対する効果的な保護を維持するには、Webリソースの定期的な監査が必要です。



激しいカオスリクエストは、ユーザーまたはロボットからサイトページへの短時間のランダムまたは悪意のある複数のリクエストです。 たとえば、ランダムに集中する要求には、頻繁なページ更新が含まれます。 悪意のある多数のリクエストには、ユーザーによるサイトのページ上のスパムやDoS攻撃が含まれます。 混oticとした集中要求には、ブルートフォースによるパスワード選択の方法も含まれます。 パスワードは手動で、または特別なプログラムを使用して選択できます。 手動パスワードは、可能なオプションがわかっている場合にのみ選択されます。 それ以外の場合、ログインとパスワードのペアを自動的に選択する特別なプログラムが使用されます。 ブルートフォースのためのプログラム。



混oticとした集中リクエストからサイトを保護する効果的な方法には、特定の時間間隔でのリクエスト間の遅延時間の設定、ブラックリストとホワイトリストの作成、 robots.txtファイルのサイトページリクエスト間の検索エンジンの遅延時間の設定、 サイトマップファイルのページ更新周期の設定が含まれます.xml



クロールや混 oticとした集中リクエストからサイトを保護する方法の1つを実装しました。これは、一定期間内のリクエスト数をカウントし、設定されたしきい値を超えた場合の遅延時間を設定することです。 特に、この方法では、ブルートフォースに費やす時間が長すぎるため、ブルートフォースでパスワードを解読することは効果的でなく、役に立たなくなります。 内部の準備ができているphpスクリプト。

1.実装されたphpスクリプトのデータ

現在、実際には、インターネットリソースにある情報を含むコンピューター情報を保護するために、さまざまなアプローチが使用されています。 これらのアプローチは、次の特性によって定義できます。

-一般的なコンピュータセキュリティを確保するための最新の要件（開発者が提供するものを決定する要件）によって規制されている、すべての保護メカニズムのセットとパラメーターの両方に対する正式な要件の存在;

-コンピューター情報を保護するプロセスで実装される実際の保護メカニズムの存在。 Webサーバーで使用されるほとんどのスクリプトがオペレーティングシステムに組み込まれたセキュリティメカニズムを使用するか、それらで使用されるメソッドを継承するという単純な理由により、これらの保護メカニズムは、まずオペレーティングシステムに組み込まれたセキュリティ機能を含みます。 これらのメカニズムとそこで使用される方法に基づいて、Webサーバー全体の全体的な保護レベルが決定されます。

-コンピューター情報のセキュリティに対するさまざまな脅威の既存の統計。 特に、これは、すでに実行された情報リソースに対する攻撃の成功に関するデータです。 これらの統計を維持することは、Webサーバーで保護を作成するための要件のレベルを評価するだけでなく、保護対策の効果を判断するのに役立つように設計されています。



既に述べたように、サイトのクロールに対処する最も効果的な方法は、すべての種類の混oticとした集中的なリクエストと同様に、同じユーザーからのリクエスト間に時間遅延を設定することです。 ユーザーを識別するときは、Cookieを簡単に削除できるという理由で、ユーザーのIPアドレスに重点を置く必要があります。 もちろん、ユーザーのIPアドレスが動的な場合は、プロキシサーバーを使用したり、再接続したりして、ユーザーのIPアドレスを変更することもできますが、そのような操作にはかなり時間がかかります。キューは攻撃者のすべての努力を無効にします。



このサイト保護の方法は、phpスクリプトを作成して実装する必要があります。 この種のスクリプトを使用すると、クローラープログラムを使用したサイトのスキャンからの保護に役立ち、同時にサイトのクロールを「手動で」大幅に遅くするのに役立ちます。 さらに、このようなスクリプトを使用すると、さまざまな種類の混chaとした集中的な要求からサイトのすべてのページに優れたセキュリティが提供され、Webサーバー機器の負荷を減らすことができます。



開発したスクリプトは構成できるはずです。 特に、スクリプトパラメータの一部を事前に変更する可能性を予測する必要があります。 言い換えれば、スクリプトには次のものが必要です。

-ユーザーのIPアドレスをブロックする時間を構成する機能。

-ユーザーアクティビティをチェックする時間間隔、つまり、特定のユーザーから受信したリクエストの数を保持する時間を設定する機能。

-1人のユーザーが特定の時間間隔内にサイトのページに送信できるリクエストの数を設定する機能。

-「常に許可されるIPアドレス」のリストを作成する機能。 このリストに含まれるIPアドレスはブロックされません。

-「常に禁止されているIPアドレス」のリストを作成する機能。 スクリプトは、リストされているIPアドレスを常にブロックします。



このようなphpスクリプトを作成して使用する利点は次のように考えることができます。

-データベースサーバーに送信されるリクエスト数の大幅な削減。

-Webサーバーでの着信および発信トラフィックの大幅な節約。

-スクリプトの最も重要なパラメーターの便利で柔軟な設定の可用性。

-ユーザーによるWebサーバーの負荷を大幅に削減する機能。

-このリソースに十分なページがある場合、サイトに投稿されたすべての情報をコピーすることは非常に困難または不可能になります。



phpスクリプトの形式で作成された、開発されたサイトセキュリティシステムのロジックを図に示します。











スクリプトを開発する過程で重要な点は、受信した情報を保存する方法の選択です。 私たちの場合、これらは現在のユーザーのIPアドレスです。 この情報は、データベースまたはハードドライブに保存できます。 開発したスクリプトの作業を高速化し、より安定させるために、キャッシュディレクトリを使用して現在のユーザーのIPアドレスを保存します。



これらのディレクトリの1つに、スクリプトはアクティブのIPアドレスを格納します。この時点で、このディレクトリはアクティブと呼ばれます。 また、別のディレクトリに、一時的にブロックされたユーザーのIPアドレスを含む名前のファイルを追加します（ブロックディレクトリ）。



IPアドレスに加えて、スクリプトの実行プロセスでは、ユーザーアクティビティに関する情報も必要です。 これを行うために、ユーザーが特定の期間に「最初の」アクティビティを示したときに、ユーザーのIPアドレスを含むファイルの名前に正確なシステム時間を追加します。 特定の（事前に定義された）期間で初めて、サイトページにリクエストを送信しました。 特定の時間間隔内のユーザーがスクリプト内のサイトページに送信されたリクエストの所定数を超える場合、スクリプトはアクティブユーザーのディレクトリからIPアドレスを含むファイルを削除します。 次に、ブロックされたIPアドレスを含むディレクトリに、新しいファイル（ブロックされたユーザーのIPアドレスを含む名前）を書き込みます。 したがって、127.0.0.1_1302615293、195.80.91.151_1302615389、95.30.17.60_1302615457、77.39.54.104_ 1302615504などの名前のファイルは、キャッシュディレクトリ（アクティブおよびブロック）に一時的に保存されます。



下部のスラッシュまでのファイル名にはアクティブなユーザーのIPアドレスが含まれ、下部のスラッシュの後に、ファイル名にアクティブになった（つまり、リソースページにリクエストを送信したか、ブロックされた）正確なシステム時間が入力されます。



それとは別に、ディレクトリをキャッシュする場合、つまり アクティブフォルダとブロックフォルダでは、ファイルの所有者または777のアクセス許可を設定する必要があります。つまり、サーバーで指定されたこれらのフォルダの属性は、スクリプトに書き込み権、読み取り権、実行権を与える必要があります。 すべてのユーザーグループに777権限を設定する必要があります。



さらに、サイト管理者が提供しない場合に備えて、別の例外を提供する必要があります。 実際、このような状況では、スクリプトは使用できません。つまり、サイトをクロールおよび混chaとした集中的な要求から保護することは、少なくとも破産になります。 言い換えると、スクリプトの操作中に、キャッシングディレクトリの読み取りおよび書き込みの機能の有無を確認することが不可欠です。



現在のユーザーに関する情報（特にIPアドレスに関する情報）は、スーパーグローバル配列$ _SERVER []から取得します。 この配列は、Webサーバーによって作成されます。 さまざまな環境変数の値が含まれています。 ユーザーのIPアドレスを操作するには、$ _SERVER []スーパーグローバル配列に含まれる次の環境変数を使用する必要があります。

-$ _SERVER ['HTTP_X_FORWARDED_FOR'];

-$ _SERVER ['HTTP_CLIENT_IP'];

-$ _SERVER ['HTTP_X_CLUSTER_CLIENT_IP'];

-$ _SERVER ['HTTP_PROXY_USER'];

-$ _SERVER ['REMOTE_ADDR']。



環境変数$ _SERVER ['HTTP_X_FORWARDED_FOR']は、クライアントがプロキシサーバーを使用している場合、クライアントのIPアドレスを決定する機会を提供します。 環境変数$ _SERVER ['HTTP_CLIENT_IP']を使用すると、クライアントがプロキシサーバーを使用していない場合、インターネット上で動作するようにクライアントのIPアドレスを取得できます。 環境変数$ _SERVER ['HTTP_X_CLUSTER_CLIENT_IP']は、サイトがサーバーとクライアント間の安全な接続を提供する暗号化プロトコルSSLを使用しない場合、クライアントのIPアドレスを取得することを可能にします。 環境変数$ _SERVER ['HTTP_PROXY_USER']を使用すると、プロキシサーバーを使用するクライアントのIPアドレスを決定できます。



環境変数$ _SERVER ['REMOTE_ADDR']を使用すると、リモートユーザーのIPアドレスを取得できます。 ローカルマシンでのテスト中、このIPアドレスは127.0.0.1になります。 同時に、ネットワーク上で、この変数は、クライアントのIPアドレス、またはユーザーが使用した最後のプロキシサーバー（このクライアントがWebサーバーに到達した）のIPアドレスを返します。 したがって、$ _SERVER []配列のさまざまな環境変数（上記で使用したすべての変数）を同時に使用すると、ユーザーが何らかの方法で「マスク」しようとしても、ユーザーの実際のIPアドレスを特定できます。またはプロキシサーバー。



ネストレベルに関係なく、サイトの任意のページでスクリプトを安定して動作させるために、キャッシングディレクトリ（アクティブおよびブロック）へのパスを絶対形式に減らす機能を使用します。 このアプローチを使用すると、サイトの任意のページからスクリプトを実行でき、ページの1つへのスクリプトで指定されたキャッシュディレクトリへの相対相対パスが間違っていることがわかります。



すでに述べたように、開発されたスクリプトは構成できるはずです。 特に、スクリプトパラメータの一部を変更する可能性を予測する必要があります（ユーザーのIPアドレスをブロックする時間、リソースページに送信されるリクエストの数の時間間隔、およびこの時間間隔で許可されるリクエストの数が考慮されます）。 これらのパラメータは、定数を使用してスクリプトで最初に設定されます。



特に、スクリプト内のこのような定数は、次のパラメーターを示します。

-秒単位で示されるユーザーのIPアドレスのブロック時間（const blockSeconds）。

-1人のユーザーからサイトのページへのリクエストが考慮される時間間隔。 この間隔も秒単位で示されます（const intervalSeconds）。

-特定の期間（const intervalTimes）に1人のユーザーが送信できるWebサイトページへのリクエストの数。

それとは別に、スクリプトでは、文字列データを含むそのような配列を定義する必要があります。

-「常に許可されるIPアドレスのリスト」に含まれるIPアドレスの値の配列（パブリック配列宣言public static $ alwaysActive = array（ ''））;

-「常に禁止されているIPアドレスのリスト」に含まれているIPアドレスの値の配列（配列public static $ alwaysBlock = array（ ''）の宣言）。

スクリプトが正しく機能するため、およびデバッグのために、スクリプト内にいくつかのフラグが存在するようにする必要があります。 このようなフラグを使用すると、サイトコンテンツをスキャンやさまざまな混chaとした要求から保護するプロセスにも役立ちます。 これらのフラグは次のとおりです。

-常にアクティブなユーザーに接続する機能のフラグ（const isAlwaysActive）。

-常にブロックされているユーザーを接続する機能のフラグ（const isAlwaysBlock）。

開発したスクリプトには、TBlockIpクラスが1つ含まれています。 このクラスには次のメソッドが含まれます。

-checkIp（）。 このメソッドは、ユーザーのIPアドレスをブロックまたはアクティビティのためにチェックする機能を実装します。 この場合、「常に許可されるIPアドレス」のリストに含まれるIPアドレスはスキップされ、「常に禁止されるIPアドレス」のリストに含まれるIPアドレスは逆にブロックされます。 ユーザーIPアドレスが可能なIPアドレスの配列に見つからない場合、スクリプトは新しいアクティブなIPアドレスの識別子を作成します。

-_getIp（）。 この方法により、すべての可能なIPアドレスから選択されたユーザーの現在のIPアドレスを取得できます（目的のクライアントIPアドレスが検出されるまでフィルタリングが実行されます）。 メソッドは受信したIPアドレスを返します。



最終的に、開発されたスクリプトは、サイトをスキャンするプロセスに対抗するのに役立つ効果的なツールと見なすことができ、すべての種類の混oticとした集中的な要求に対する予防手段にもなります。 開発されたスクリプトでは、同じユーザーからのリクエスト間の時間遅延の設定があります。 ユーザーを識別するとき、主な焦点はIPアドレスにあります。 その理由は簡単です。事実は、攻撃者のコンピューターからCookieを簡単に削除できるため、Cookieを使用してリソース保護を構築できないことです。



もちろん、ユーザーのIPアドレスも、たとえばプロキシサーバーを使用して変更できます。 攻撃者に対するこの可能性を排除するために、スクリプトは環境変数を使用します。環境変数は、ユーザーの実際のIPアドレスを識別するのに役立ちます。 ユーザーが特定の期間内にサイトのページへの要求の確立された制限を超えると、このIPアドレスがブロックされます。 開発されたスクリプトは、スキャンからのサイトの保護、および混chaとした集中リクエストからの保護に関連する、割り当てられたすべての機能を実行します。

2リストプログラム

<?php /** *     ip-. */ class TBlockIp { /** *    . */ const blockSeconds = 60; /** *    . */ const intervalSeconds = 15; /** *      . */ const intervalTimes = 3; /** *     . */ const isAlwaysActive = true; /** *     . */ const isAlwaysBlock = true; /** *      . */ const pathActive = 'active'; /** *      . */ const pathBlock = 'block'; /** *     . */ const pathIsAbsolute = false; /** *    . */ public static $alwaysActive = array( '172.16.1.1', ); /** *    . */ public static $alwaysBlock = array( '172.16.1.1', ); /** *   ip-    . */ public static function checkIp() { //  ip- $ip_address = self::_getIp(); //     if (in_array($ip_address, self::$alwaysActive) && self::isAlwaysActive) { return; } //     if (in_array($ip_address, self::$alwaysBlock) && self::isAlwaysBlock) { echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">'; echo '<html xmlns="http://www.w3.org/1999/xhtml">'; echo '<head>'; echo '<title> </title>'; echo '<meta http-equiv="content-type" content="text/html; charset=utf-8" />'; echo '</head>'; echo '<body>'; echo '<p style="background:#ccc;border:solid 1px #aaa;margin:30px au-to;padding:20px;text-align:center;width:700px">'; echo '   .<br />'; echo '</p>'; echo '</body>'; echo '</html>'; exit; } //     $path_active = self::pathActive; $path_block = self::pathBlock; //        if (!self::pathIsAbsolute) { $path_active = str_replace('\\' , '/', dirname(__FILE__) . '/' . $path_active . '/'); $path_block = str_replace('\\' , '/', dirname(__FILE__) . '/' . $path_block . '/'); } //      if (!is_writable($path_active)) { die('         .'); } if (!is_writable($path_block)) { die('         .'); } //   ip- $is_active = false; if ($dir = opendir($path_active)) { while (false !== ($filename = readdir($dir))) { //  ip +    ip if (preg_match('#^(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})_(\d+)$#', $filename, $matches)) { if ($matches[2] >= time() - self::intervalSeconds) { if ($matches[1] == $ip_address) { $times = intval(trim(file_get_contents($path_active . $filename))); if ($times >= self::intervalTimes - 1) { touch($path_block . $filename); unlink($path_active . $filename); } else { file_put_contents($path_active . $filename, $times + 1); } $is_active = true; } } else { unlink($path_active . $filename); } } } closedir($dir); } //   ip- $is_block = false; if ($dir = opendir($path_block)) { while (false !== ($filename = readdir($dir))) { //  ip +    ip if (preg_match('#^(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})_(\d+)$#', $filename, $matches)) { if ($matches[2] >= time() - self::blockSeconds) { if ($matches[1] == $ip_address) { $is_block = true; $time_block = $matches[2] - (time() - self::blockSeconds) + 1; } } else { unlink($path_block . $filename); } } } closedir($dir); } // ip-  if ($is_block) { header('HTTP/1.0 502 Bad Gateway'); echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">'; echo '<html xmlns="http://www.w3.org/1999/xhtml">'; echo '<head>'; echo '<title>502 Bad Gateway</title>'; echo '<meta http-equiv="content-type" content="text/html; charset=utf-8" />'; echo '</head>'; echo '<body>'; echo '<h1 style="text-align:center">502 Bad Gateway</h1>'; echo '<p style="background:#ccc;border:solid 1px #aaa;margin:30px au-to;padding:20px;text-align:center;width:700px">'; echo ' ,   , -    .<br />'; echo '  .  ' . $time_block . ' ()    .'; echo '</p>'; echo '</body>'; echo '</html>'; exit; } //    ip- if (!$is_active) { touch($path_active . $ip_address . '_' . time()); } } /** *    ip-   . */ private static function _getIp() { // ip-   $ip_address = '127.0.0.1'; //   ip- $addrs = array(); //    ip- if (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) { //   ip-   - foreach (array_reverse(explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])) as $value) { $value = trim($value); //  ip- if (preg_match('#^\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3}$#', $value)) { $addrs[] = $value; } } } //  ip- if (isset($_SERVER['HTTP_CLIENT_IP'])) { $addrs[] = $_SERVER['HTTP_CLIENT_IP']; } //  ip- if (isset($_SERVER['HTTP_X_CLUSTER_CLIENT_IP'])) { $addrs[] = $_SERVER['HTTP_X_CLUSTER_CLIENT_IP']; } //  ip- if (isset($_SERVER['HTTP_PROXY_USER'])) { $addrs[] = $_SERVER['HTTP_PROXY_USER']; } //  ip- if (isset($_SERVER['REMOTE_ADDR'])) { $addrs[] = $_SERVER['REMOTE_ADDR']; } //   ip-,    foreach ($addrs as $value) { //  ip- if (preg_match('#^(\d{1,3}).(\d{1,3}).(\d{1,3}).(\d{1,3})$#', $value, $matches)) { $value = $matches[1] . '.' . $matches[2] . '.' . $matches[3] . '.' . $matches[4]; if ('...' != $value) { $ip_address = $value; break; } } } //   ip- return $ip_address; } } //   ip- TBlockIp::checkIp();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトは、インデックスページに直接埋め込むか、インデックスファイルの先頭に呼び出しを含めることでphpファイルに個別に埋め込むことができます。



サイトインデックスファイルでの実装例。 インデックスファイルの最上部に記述します（ページエンコーディングが正しく表示されるようにエンコーディングパラメータを設定した後に可能です）。

 include '/block/index.php';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、ルートに「block」フォルダー、「active」フォルダーと「block」フォルダー、および「index.php」ファイルを作成する必要があります（ここでは上記のコードをコピーします）。

3サイトに埋め込まれたphpスクリプトのテスト

記述されたコードの表示とその後のテストは、PHPスクリプトの開発における最も重要な段階の1つです。 この段階では、Webのプログラミングに携わる開発者は見逃しがちです。 実際のところ、記述されたスクリプトを2、3回実行するのは非常に簡単で、正常に機能することに注意してください。 同時に、これはよくある間違いです。 結局、作成されたスクリプトは徹底的な分析またはテストの対象となる必要があります。



開発したphpスクリプトとアプリケーションプログラムの主な違いは、非常に広い範囲の人々がWebアプリケーションで作業することです。 このような状況では、さまざまなWebアプリケーションの使用に完全に精通していることをユーザーに頼るべきではありません。 ユーザーに巨大なガイドやクイックリファレンスを提供することはできません。 そのため、開発されたWebアプリケーションは、自己文書化だけでなく、自明でなければなりません。 開発したphpスクリプトを実装するときは、さまざまな状況での動作をテストするだけでなく、あらゆる種類の使用方法を考慮する必要があります。



経験のあるユーザーやプログラマーにとって、経験の浅いユーザーが経験する問題を理解することはしばしば困難です。 問題を解決する1つの方法は、一般的なユーザーのアクションを代表するテスターを見つけることです。 過去には、次のアプローチが使用されていました。最初に、開発されたWebアプリケーションのベータ版が市場にリリースされました。 ほとんどのエラーが修正されたと思われる後、このアプリケーションは少数のユーザー向けに公開されたため、着信トラフィックの強度が小さくなります。 この種のテストの後、開発者は、開発したシステムを使用するためのデータとオプションのさまざまな組み合わせを取得しますが、開発者は[13、394]についても推測しませんでした。



作成されたphpスクリプトは、実際に作成されたとおりに実行する必要があります。 この作業で開発および作成されたphpスクリプトに関連して、これを言うことができます：ユーザーが特定の期間（デフォルトでは15秒）、指定されたリクエスト数（デフォルトでは3リクエスト）以上をサイトのページに送信でき、スクリプトがそのIPをブロックしない場合-アドレス、そしてエラーが書かれたWebアプリケーションの仕事に忍び込んだ。 一般に、テストは、記述されたphpスクリプトの予想される動作と実際の動作の間に存在するこのような不整合を特定しようとするアクティビティです。 開発者は、スクリプトの動作の不整合と、開発中の不正な動作を特定することにより、ユーザーがこの種のスクリプトの動作に遭遇する可能性を大幅に減らすことができます。 プログラム（この場合は、書かれたphpスクリプト）を手動で、または専用のオンラインサービスを使用してテストできます。

3.1手動テスト

記述されたphpスクリプトを手動でテストする場合、スクリプトが割り当てられたタスクを実行するかどうかを確認する必要があります。 特に、特定の期間に頻度が許容限度を超えた場合、同じユーザーからのサイトページへのリクエストの数を制限しますか。 スクリプトのパフォーマンスをテストするには、まず、サイトコードにスクリプトを埋め込む必要があります。 これを行うには、次の言語構成を使用できます。

include "block / index.php";



これを含めると、スクリプトはブロックフォルダーに配置されます。 サイトコンテンツ管理システムが、ページのいわゆるフレンドリーURLの作成を使用する場合、つまり 人間の認識に便利なWebアドレス（この場合、/ news / sport / 2003/10 /などのマルチレベル構造の作成）、またはフォルダーのルートとは異なるアドレス（/ newsなど）でページをロードします/sport.php）、スクリプトのアドレスを正しく指定する必要があります。 このような状況では、スクリプトへの絶対パスが示される場合があります。



書かれたphpスクリプトのテスト自体は、サイトのページにリクエストを送信することで構成されます。 テストプロセスでは、作成されたスクリプトが特定の期間（デフォルト-15秒）に指定された最大リクエスト数（デフォルト-3リクエスト）をスキップするかどうかを確認する必要があります。 まず、スクリプトがその主な機能にどのように対処するかを確認する必要があります。 同じユーザーからのサイトページへの集中的な要求を直接ブロックします。 サイトのページに送信できるリクエストの数を確認すると、割り当てられた15秒以内に、サイトのページに3つ以上のリクエストを送信することはできません。 特に、ユーザーが3つ以上の要求を送信すると、図に示すように、一時ロックに関するメッセージを受信します。











したがって、テストでは、スクリプトが意図したとおりに機能することが示されました。特定の時間間隔で1人のユーザーからのリクエスト数が指定されたインジケーター（デフォルト-3リクエスト）を超えると、特定の時間（デフォルトでは1分間）ユーザーをブロックします） テストの次の段階は、書かれたphpスクリプトの個々の機能の操作性を検証することです。 特に、テストユーザーのIPアドレスが「常に許可されるIPアドレス」のリストに追加された場合、スクリプトがどのように機能するかを確認する必要があります。 また、テストユーザーのIPアドレスが「常に禁止されているIPアドレス」のリストに追加された場合のスクリプトの動作を確認する必要があります。



テストユーザーのIPアドレスを「常に許可されるIPアドレス」のリストに追加すると、サイトのページに送信されるリクエストの数の制限がなくなり、リンクをたどる（またはページを更新する）ことができます。 つまり、「常に許可されるIPアドレス」のリストが正しく機能する必要があります。 テストユーザーのIPアドレスを「常に禁止されているIPアドレス」のリストに追加した後、サイトページへの少なくとも1つの要求の送信が失敗しました。 図に示すように、Webリソースのコンテンツの代わりに、ブラウザにブロッキングメッセージが表示されます。











つまり、「常に禁止されているIPアドレス」のリストが実行する必要がある機能は正しく機能しています。 この機能は、IPアドレスが「常に禁止されているIPアドレス」のリストに含まれているユーザーを完全にブロックします。 したがって、「常に許可されたIPアドレス」のリストと「常に禁止されたIPアドレス」のリストを使用して実装されるアクセス制御の機能は正しく動作し、スクリプトは当初の意図どおりに動作します。 つまり、このスクリプトは、「常に許可されるIPアドレス」のリストにIPアドレスが含まれるユーザーにサイトのページへの無制限のアクセスを提供し、「常に禁止されるIPアドレス」のリストにIPアドレスが含まれるユーザーへのアクセスを完全に禁止します。 書かれたphpスクリプトを手動でテストすると、スクリプトのすべての機能、したがってスクリプト自体が正しく機能することが示されました。 元々考えられていた通りです。

3.2オンラインサービスを使用したテスト

オンラインサービスを使用して記述されたphpスクリプトをテストすると、サイトのページを読み込むために必要なトラフィックの正確な量を見つけることができ、さまざまな自動サービスまたはプログラムによって送信されるリクエストの記述されたphpスクリプトの「スループット」を正確に決定するのにも役立ちます。 スクリプトのタスクの1つは、クローラープログラムを使用したスキャンからサイトを保護することであるため、最後のパラメーターは非常に重要です。 このようなテストは、必要なトラフィック量とプロセッサ時間についての結論だけでなく、サイトで提示された情報が自動モードでページを要求するソフトウェアツールで利用可能かどうかについても結論を出すのに役立ちます。 まず、さまざまな接続速度でのサイトのページの平均読み込み時間を推定します。 また、ユーザーがロードしたページのサイズを推定します。 この種のテストを実施するには、 analyze.websiteoptimization.comにあるオンラインサービスを使用します。 サービスによって定義されたロード済みページのサイズを図に示します：











テストするサイトは1ページのみで構成されており、そのサイズは1511バイトであるため、0.51秒（56 Kの接続速度）または0.21秒（1.44 Mbpsのユーザー接続速度）でロードされます。 。 さまざまなユーザー接続速度でのページ読み込み速度を図に示します。











図の情報からわかるように、最低の接続速度（14.4 K）でも、サイトのページは非常に速く（1.4秒で）ロードされます。 同時に、ユーザーの接続速度が非常に高い場合（特に1.44 Mbps）、ページは文字通り即座に（0.21秒で）ロードされます。 このリソースのダウンロード速度は、パケット損失率に合わせて調整されます（この比率は0.7です）。 また、ページの読み込みごとに平均0.2秒に等しい遅延時間も考慮に入れます。 接続速度の大幅な増加がページのロード時間の同等の大幅な短縮につながらない理由を説明するのは、これらのパラメーターです。 このサービスは、サイトのページをロードするための主要なパラメーターを評価することに加えて、サイトの分析の一般的な結果、そしてもちろん、サイトのページをロードするためのすべてのパラメーターを改善することを目的とした推奨事項も提供することに注意してください。 サービスの分析結果と推奨事項を図に示します：











図からわかるように、分析されたすべてのパラメーターのテスト対象サイトのすべてのインジケーターは、通常の制限内にあります。 特に、このサービスでは、サイトページの数、ページ上のオブジェクト、およびこれらのページとオブジェクトのサイズが許容範囲内であることを明記しています。 サイトは分析されたすべてのパラメーターの基準を満たしているため、取得したデータに基づいて、テストしたサイトの最適化は必要ありません。 つまり、サイト（またはサイトページ）からダウンロードされる情報の量は非常に少なく、Webサーバーとユーザーの両方のリソースを節約できます。 つまり 開発されたスクリプトはサイトをロードせず、実際、その存在は目立ちません。 テストを強調するもの。 サイトのページの読み込み速度、および他のスクリプトの利用可能性の確認は、 www.pr-cy.ruなどのオンラインサービスを使用して実行できます。 このオンラインサービスを使用して行われたテストの結果を図に示します。











ご覧のとおり、平均ダウンロード速度30.31 Kb / sで取得したデータから、ページの読み込み時間は0.05秒です。 同時に、平均速度37.89 Kb / sでは、ページの読み込み時間はすでに0.04秒です。 同時に、この作業で開発されたスクリプトは、同じIPアドレスからのサイトのページへの3つ以上のリクエストをブロックし、それにより不必要な作業負荷を減らし、試行を複雑にするか、サイトのパスワードを選択できないようにすることをテストが示しました

3.3サイトに埋め込まれたphpスクリプトのテスト結果

テストでは、開発されたphpスクリプトが最初に割り当てられた機能にうまく対応して、サイトをスキャンから保護し、1人のユーザーからの混chaとした集中的な要求やブルートフォース攻撃から保護することを示しました。 特に、サイトの手動テストでは、特定の時間間隔でのこれらのリクエストの数が所定の制限を超えた場合、スクリプトが1つのIPアドレスからサイトのページへのリクエストをブロックすることが示されました。 さらに、このテストでは、スクリプトのすべての機能、特に「常に許可されるIPアドレス」と「常に禁止されるIPアドレス」のリストを操作する機能が正常に機能することが示されました。 つまり、開発されたスクリプトは、「常に許可されるIPアドレス」のリストにIPアドレスが含まれるユーザーにサイトのすべてのページへの無制限のアクセスを提供し、「常に禁止されるIPアドレス」のリストにあるIPアドレスを持つユーザーへのアクセスを完全に禁止します「。



開発されたphpスクリプトが埋め込まれているサイトのテストでは、分析されたすべてのパラメーターに対するテストされたサイトのすべてのインジケーターが通常の制限内にあることが示されました。 特に、このサービスでは、サイトページの数、ページ上のオブジェクト、およびこれらのページとオブジェクトのサイズが許容範囲内であることを明記しています。 サイトは分析されたすべてのパラメーターの基準を満たしているため、取得したデータに基づいて、テストしたサイトの最適化は必要ありません。 つまり、サイト（またはサイトページ）からダウンロードされる情報の量は非常に少なく、Webサーバーとユーザーの両方のリソースを節約できます。 以前は、スクリプトは英語と英語の単語を学習するためのサイトで使用されていましたが、後でより深刻な保護対策が講じられました。 ただし、最初は、このスクリプトにより安価なホスティングの負荷が大幅に削減され、1日あたり5000以上のホストのトラフィックでサイトをねじることができました。



さらに、サイトをテストすると、テストしたサイトのページ読み込み速度が非常に速いことがわかりました。 また、このオンラインサービスのIPアドレスから送信された要求の数が開発されたスクリプトで許可されている制限を超えた場合、スクリプトはサイトのテストをブロックしました（スクリプトに設定された1つのIPアドレスからの要求の最大数は15秒で3要求です）。



つまり、クロールや混andとした集中クエリからサイトを保護することは、当初の想定どおりに機能します。 つまり、1つのIPアドレスから発信されたリクエストの数（ユーザーのIPアドレスが「常に許可されるIPアドレス」のリストまたは「常に禁止されるIPアドレス」のリストにない場合）は、特定の時間間隔で、ブラウザ、プログラムを使用してリクエストが送信されたかどうか、またはリクエストの送信時にプロキシサーバーが使用されたかどうかにかかわらず、ユーザーのIPアドレスは一時的にブロックされます（ユーザーの実際のIPアドレスをマスクするため）。