はじめに
Nikto は、人気のあるオープンソースのウェブサーバースキャナーであり、6700 を超える潜在的に危険なファイル/プログラム、1250 を超えるサーバーの古いバージョン、270 を超えるサーバーのバージョン固有の問題など、複数の項目に対してウェブサーバーに対して包括的なテストを実行します。
Nikto は強力ですが、スキャンが失敗したり、予期しない結果を生成したり、さらに詳しい調査が必要になったりすることがあります。このような状況では、Nikto のデバッグ機能が非常に役立ちます。これにより、送信されている正確な HTTP リクエストと受信した応答を確認でき、ネットワークの問題、サーバーの設定ミス、またはスキャン自体の問題を特定するのに役立ちます。
この実験では、Nikto のデバッグオプションを使用して、ウェブ脆弱性スキャンを効果的にトラブルシューティングし、理解する方法を学びます。
-debug オプションを使用したスキャンの実行
このステップでは、-debug オプションを使用して基本的な Nikto スキャンを実行します。このオプションは非常に冗長な出力を提供し、Nikto によって送信されたすべてのリクエストとサーバーからの対応する応答の詳細を表示します。これは、あらゆるスキャンのトラブルシューティングにおける最初で最も重要なステップです。
まず、~/project ディレクトリにいることを確認してください。スキャン対象として、127.0.0.1 のポート 8000 で実行されるシンプルなウェブサーバーをすでにセットアップしています。
以下のコマンドを実行して、ローカルウェブサーバーに対して -debug オプション付きで Nikto を実行します。
nikto -h http://127.0.0.1:8000 -debug
大量の出力がスクロールして表示されます。これがデバッグ情報です。標準の Nikto スキャン結果に、詳細なリクエストと応答データが混在しています。
出力の一部は、生の HTTP 通信を示す以下のようなものになります。
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 127.0.0.1
+ Target Hostname: 127.0.0.1
+ Target Port: 8000
+ Start Time: ...
---------------------------------------------------------------------------
+ Server: SimpleHTTP/0.6 Python/3.10.12
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ No CGI directories found (use '-C all' to force check all possible dirs)
DEBUG: User-Agent is 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36'
DEBUG: Request -> 127.0.0.1:8000
GET / HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Accept-Encoding: gzip,deflate
Accept: */*
DEBUG: Response -> 127.0.0.1:8000
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/3.10.12
Date: ...
Content-type: text/html; charset=utf-8
Content-Length: 36
Last-Modified: ...
DEBUG: Received: <h1>Welcome to the Test Site</h1>
... (many more lines) ...
この詳細な表示は、Nikto が正確に何をテストしているかを理解するために不可欠です。
詳細なリクエストとレスポンス情報の確認
このステップでは、前のステップで生成された出力を詳しく見ていきます。デバッグ情報の量は膨大になる可能性があるため、less のようなページャーツールを使用してレビューすると便利です。
コマンドを再度実行しますが、今回は出力を less にパイプします。これにより、一度に 1 ページずつ出力をスクロールできます。
nikto -h http://127.0.0.1:8000 -debug | less
出力が less に表示されたら、以下のキーを使用してナビゲートできます。
- 矢印キー または j/k で上下にスクロールします。
- Page Up/Page Down または スペースバー でページ単位で移動します。
- q で終了し、コマンドプロンプトに戻ります。
スクロールしながら、各テストのデバッグ出力の以下の重要な部分に注意してください。
DEBUG: Request ->: このセクションには、メソッド (GET、POST など)、URI、およびすべてのヘッダーを含む、送信されている正確な HTTP リクエストが表示されます。DEBUG: Response ->: これには、HTTP ステータスコード (例：200 OK、404 Not Found) を含むサーバーのレスポンスヘッダーが表示されます。DEBUG: Received:: これには、サーバーからの HTTP レスポンスのボディが表示されます。
この情報を調べることで、サーバーが期待どおりに応答しているか、ファイアウォールがリクエストをブロックしているか、または Nikto が応答を正しく解釈しているかを確認できます。
観察が終了したら、q を押して less を終了してください。
デバッグ出力をファイルにリダイレクトして後で分析する
このステップでは、冗長なデバッグ出力をファイルに保存する方法を学びます。長時間のスキャンや複雑なスキャンの場合、リアルタイムで出力を分析するのは現実的ではありません。ファイルに保存することで、オフラインでの分析、検索、チームメンバーとの共有が可能になります。
Nikto のデバッグ情報は標準エラー出力 (STDERR) ストリームに送信され、通常の（標準的な）結果は標準出力 (STDOUT) に送信されます。すべてをキャプチャするには、両方のストリームをファイルにリダイレクトする必要があります。
以下のコマンドを使用してスキャンを実行し、すべての出力を debug_output.txt という名前のファイルに保存します。
nikto -h http://127.0.0.1:8000 -debug > debug_output.txt 2>&1
リダイレクト部分を分解してみましょう。
>: これは標準出力のリダイレクト演算子です。STDOUT をdebug_output.txtに送信します。2>&1: これは STDERR (ファイルディスクリプタ 2) を STDOUT (ファイルディスクリプタ 1) と同じ場所、つまりファイルにリダイレクトします。
コマンドが完了したら、ファイルが作成されたことを確認します。
ls -l debug_output.txt
出力にファイルが表示されるはずです。
-rw-r--r-- 1 labex labex ... ... debug_output.txt
これで、詳細なレビューのためにスキャンとそのデバッグ情報の永続的な記録を持つことができます。less を終了するには q を押してください。
スキャンデータベースの構文をチェックするために -dbcheck を使用する
このステップでは、-dbcheck オプションを使用します。これはスキャンを実行しない診断ツールであり、代わりに Nikto の内部データベースとプラグインの構文をチェックします。Nikto がクラッシュしたり、起動に失敗したり、異常な動作をしたりする場合、自身のファイルが破損していないことを確認するためにデータベースチェックを実行するのが良い最初のステップです。
データベースには、Nikto が実行するすべての脆弱性チェックの定義が含まれています。これらのファイルのうちの 1 つに構文エラーがあると、テストがサイレントに失敗したり、プログラム全体がクラッシュしたりする可能性があります。
チェックを実行するには、次のコマンドを実行します。
nikto -dbcheck
Nikto はプラグインファイルとデータベースを解析します。すべてが正しければ、エラーが見つからなかったことを確認する出力が表示されます。
- Nikto v2.5.0
---------------------------------------------------------------------------
+ DBCheck: Parsing database '/var/lib/nikto/plugins/db_variables'
+ DBCheck: Parsing database '/var/lib/nikto/plugins/db_tests'
... (さらに多くの行) ...
+ DBCheck: 0 error(s) found in database.
エラーが見つかった場合、出力は特定のファイルと行番号を指し示し、問題の修正（または必要に応じて Nikto の再インストール）に役立ちます。このシンプルなコマンドは、ツールのトラブルシューティング中に多くの時間を節約できます。
デバッグ出力を使用してスキャン失敗のトラブルシューティングを行う
このステップでは、学んだことを実践的なトラブルシューティングシナリオに適用します。一般的な問題、つまりターゲットホストに到達できないためにスキャンが失敗するという状況をシミュレートします。デバッグ出力がない場合、原因がすぐに明らかにならないことがあります。
ローカルネットワーク上の存在しない IP アドレス 10.255.255.1 をスキャンしようとします。また、スキャンがすぐに終了するように -maxtime 10s も使用します。
次のコマンドを実行します。
nikto -h 10.255.255.1 -maxtime 10s -debug
出力を注意深く観察してください。ホストが存在しないため、Nikto は接続を確立できません。デバッグ出力は、これらの接続試行と失敗を明確に示します。
デバッグログ全体に、次のようなエラーメッセージが散在しているのがわかります。
- Nikto v2.5.0
---------------------------------------------------------------------------
+ Target IP: 10.255.255.1
+ Target Hostname: 10.255.255.1
+ Target Port: 80
+ Start Time: ...
---------------------------------------------------------------------------
+ Server: No banner retrieved
DEBUG: Request -> 10.255.255.1:80
GET / HTTP/1.1
Host: 10.255.255.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Accept-Encoding: gzip,deflate
Accept: */*
+ ERROR: Cannot connect to 10.255.255.1:80 (No route to host)
...
ここでの重要なメッセージは ERROR: Cannot connect... (No route to host) です。これは、問題が Web サーバーの設定や Nikto のバグではなく、根本的なネットワーク接続の問題であることをすぐに示しています。ターゲットに到達できないため、スキャンは「失敗」しています。これは、-debug オプションが問題の根本原因を迅速に診断するために必要なコンテキストを提供する方法を示しています。
まとめ
この実験では、Nikto のウェブサーバースキャンのデバッグとトラブルシューティングに不可欠なテクニックを学びました。
まず、-debug オプションを使用して詳細なリクエストとレスポンスデータを表示し、スキャナーの動作を明確に把握しました。次に、この出力をファイルにリダイレクトしてオフライン分析を行う方法を学びました。また、-dbcheck ユーティリティを使用して Nikto 自身のデータベースファイルの整合性を検証しました。これは、ツール自体のトラブルシューティングにおいて重要なステップです。最後に、これらのスキルを実際のシナリオに適用し、ネットワーク接続の問題がスキャン失敗の原因であることを迅速に特定しました。
これらのスキルを習得したことで、問題の診断と解決能力が向上し、Nikto スキャンが効果的かつ信頼性の高いものになることを保証できます。
