Отладка сканирования Nikto для устранения неполадок

Kali LinuxBeginner
Практиковаться сейчас

Введение

Nikto — популярный сканер веб-серверов с открытым исходным кодом, который выполняет комплексные тесты веб-серверов на наличие множества элементов, включая более 6700 потенциально опасных файлов/программ, проверяет устаревшие версии более чем 1250 серверов и проблемы, специфичные для версий, на более чем 270 серверах.

Хотя Nikto является мощным инструментом, сканирование иногда может завершаться неудачно, давать неожиданные результаты или требовать более глубокого изучения. В таких ситуациях функции отладки Nikto бесценны. Они позволяют видеть точные HTTP-запросы, которые отправляются, и полученные ответы, помогая выявить сетевые проблемы, неправильные конфигурации сервера или проблемы с самим сканированием.

В этой лабораторной работе вы научитесь использовать опции отладки Nikto для эффективного устранения неполадок и понимания ваших сканирований уязвимостей веб-приложений.

Запуск сканирования с опцией -debug

На этом шаге вы выполните базовое сканирование Nikto с использованием опции -debug. Эта опция предоставляет очень подробный вывод, показывая полные детали каждого запроса, отправленного Nikto, и соответствующего ответа от сервера. Это первый и наиболее важный шаг в устранении неполадок любого сканирования.

Сначала убедитесь, что вы находитесь в каталоге ~/project. Мы уже настроили простой веб-сервер, работающий на 127.0.0.1 на порту 8000, для сканирования.

Выполните следующую команду, чтобы запустить Nikto с опцией -debug против локального веб-сервера:

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). Это немедленно сообщает вам, что проблема не в конфигурации веб-сервера или ошибке в Nikto, а в фундаментальной проблеме сетевой связности. Сканирование "не удается", потому что цель недоступна. Это демонстрирует, как опция -debug предоставляет необходимый контекст для быстрой диагностики первопричины проблемы.

Резюме

В этой лабораторной работе вы изучили основные методы отладки и устранения неполадок при сканировании веб-серверов с помощью Nikto.

Вы начали с использования опции -debug для просмотра подробных данных запросов и ответов, что дало вам четкое представление о действиях сканера. Затем вы научились управлять этим выводом, перенаправляя его в файл для последующего анализа. Вы также использовали утилиту -dbcheck для проверки целостности собственных файлов баз данных Nikto, что является важным шагом при устранении неполадок самого инструмента. Наконец, вы применили эти навыки в реальном сценарии, быстро определив проблему сетевой связности как причину сбоя сканирования.

Обладая этими навыками, вы теперь лучше подготовлены к диагностике и решению проблем, обеспечивая эффективность и надежность ваших сканирований Nikto.