引言
Nikto 是一个流行的开源 Web 服务器扫描器，它针对 Web 服务器进行全面的测试，检查超过 6700 个潜在危险文件/程序，检查超过 1250 个服务器的过时版本，以及超过 270 个服务器的版本特定问题。
虽然 Nikto 功能强大，但扫描有时可能会失败、产生意外结果或需要更深入的调查。在这些情况下，Nikto 的调试功能非常宝贵。它们允许你查看发送的确切 HTTP 请求和收到的响应，帮助你精确定位网络问题、服务器配置错误或扫描本身的问题。
在本实验中，你将学习如何使用 Nikto 的调试选项来有效排查和理解你的 Web 漏洞扫描。
使用 -debug 选项运行扫描
在此步骤中，你将使用 -debug 选项执行一次基本的 Nikto 扫描。此选项提供高度详细的输出，显示 Nikto 发送的每个请求以及服务器相应响应的完整详细信息。这是排查任何扫描的第一步，也是最关键的一步。
首先，请确保你位于 ~/project 目录中。我们已经为你设置了一个简单的 Web 服务器，它运行在 127.0.0.1 的 8000 端口上，供你扫描。
执行以下命令，使用 -debug 选项针对本地 Web 服务器运行 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。这允许你一次一页地滚动浏览输出。
nikto -h http://127.0.0.1:8000 -debug | less
一旦输出出现在 less 中，你就可以使用以下按键进行导航：
- 箭头键 或 j/k 向上和向下滚动。
- Page Up/Page Down 或 空格键 按页面移动。
- q 退出并返回命令提示符。
在滚动时，请注意每个测试的调试输出中的以下关键部分：
DEBUG: Request ->: 此部分显示正在发送的确切 HTTP 请求，包括方法（GET、POST 等）、URI 和所有标头。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
现在你可以使用 cat 或 less 来检查文件内容：
less debug_output.txt
现在你拥有了扫描及其调试信息的永久记录，以便进行详细审查。完成后按 q 退出 less。
使用 -dbcheck 检查扫描数据库的语法
在此步骤中，你将使用 -dbcheck 选项。这是一个诊断工具，它不执行扫描，而是检查 Nikto 的内部数据库和插件的语法。如果 Nikto 崩溃、启动失败或行为异常，运行数据库检查是确保其自身文件未损坏的良好第一步。
数据库包含 Nikto 执行的所有漏洞检查的定义。这些文件中的语法错误可能导致测试静默失败或整个程序崩溃。
要执行检查，请运行以下命令：
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 的 bug，而是一个根本的网络连接问题。扫描“失败”是因为目标无法访问。这表明 -debug 选项提供了必要的上下文，可以快速诊断问题的根本原因。
总结
在本实验中，你学习了调试和排查 Nikto Web 服务器扫描问题的基本技术。
你首先使用 -debug 选项查看详细的请求和响应数据，从而清晰地了解扫描器的操作。然后，你学会了如何通过将输出重定向到文件进行离线分析来管理这些输出。你还使用了 -dbcheck 工具来验证 Nikto 自身数据库文件的完整性，这是排查工具本身问题的一个关键步骤。最后，你将这些技能应用到实际场景中，快速确定了网络连接问题是导致扫描失败的原因。
掌握了这些技能后，你将能更好地诊断和解决问题，确保你的 Nikto 扫描既有效又可靠。
