Отладка атак Hydra

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

💡 Этот учебник переведен с английского с помощью ИИ. Чтобы просмотреть оригинал, вы можете перейти на английский оригинал

Введение

В этом практическом занятии вы научитесь отлаживать атаки Hydra, настраивая Telnet-сервер и анализируя отладочную информацию Hydra. Практическое занятие сосредоточено на понимании поведения Hydra во время атаки с помощью подробной отладочной информации.

Сначала вы настроите Telnet-сервер на виртуальной машине LabEx с использованием xinetd для управления Telnet-сервисом. Это включает в себя установку telnetd и xinetd, настройку xinetd для управления Telnet-соединениями и перезапуск службы xinetd. Затем вы запустите Hydra в отладочном режиме с использованием флага -d для генерации подробного вывода. Наконец, вы проанализируете этот отладочный вывод, чтобы понять процесс атаки и выявить возможные проблемы.


Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL hydra(("Hydra")) -.-> hydra/HydraGroup(["Hydra"]) hydra/HydraGroup -.-> hydra/installation("Installation and Setup") hydra/HydraGroup -.-> hydra/verbose_mode("Verbose Mode Usage") hydra/HydraGroup -.-> hydra/troubleshooting("Basic Troubleshooting") subgraph Lab Skills hydra/installation -.-> lab-550766{{"Отладка атак Hydra"}} hydra/verbose_mode -.-> lab-550766{{"Отладка атак Hydra"}} hydra/troubleshooting -.-> lab-550766{{"Отладка атак Hydra"}} end

Настройка Telnet-сервера

На этом этапе мы настроим Telnet-сервер на виртуальной машине LabEx. Telnet - это сетеевой протокол, используемый для обеспечения двусторонней интерактивной текстовой связи с использованием виртуального терминального соединения. Хотя Telnet обычно считается небезопасным из-за отсутствия шифрования, он может быть полезен для тестирования и демонстрации в контролируемой среде, такой как наша виртуальная машина LabEx.

Поскольку виртуальная машина LabEx использует контейнеры Docker, мы не можем напрямую использовать systemctl для управления службами. Вместо этого мы будем использовать xinetd для управления Telnet-сервисом. xinetd (расширенный интернет-демон) - это суперсерверный демон, который прослушивает входящие сетевые соединения и запускает соответствующую службу.

Сначала установим пакеты telnetd и xinetd. Откройте терминал на виртуальной машине LabEx и выполните следующую команду:

sudo apt update
sudo apt install telnetd xinetd -y

Эта команда обновляет списки пакетов и устанавливает пакеты telnetd (демон Telnet-сервера) и xinetd. Флаг -y автоматически отвечает "да" на все запросы во время установки.

Далее нам нужно настроить xinetd для управления Telnet-сервисом. Создайте файл конфигурации для Telnet в директории /etc/xinetd.d/. Используйте nano для создания и редактирования файла:

sudo nano /etc/xinetd.d/telnet

Вставьте следующую конфигурацию в редактор nano:

service telnet
{
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = no
}

Эта конфигурация сообщает xinetd прослушивать Telnet-соединения, запускать сервер /usr/sbin/in.telnetd от имени root и записывать в журнал ошибки соединения. disable = no гарантирует, что служба включена.

Нажмите Ctrl+X, затем Y, а затем Enter, чтобы сохранить файл и выйти из nano.

Теперь перезапустите службу xinetd, чтобы применить изменения. Поскольку мы не можем использовать systemctl, мы воспользуемся обходным путем, отправив сигнал HUP процессу xinetd. Сначала найдите идентификатор процесса xinetd:

ps -ef | grep xinetd

Вы должны увидеть вывод, похожий на следующий:

root       1234  1     0 10:00 ?        00:00:00 /usr/sbin/xinetd -stayalive -pidfile /run/xinetd.pid
labex      5678  5600  0 10:01 pts/0    00:00:00 grep --color=auto xinetd

Обратите внимание на идентификатор процесса xinetd (в этом примере это 1234). Замените 1234 на фактический идентификатор процесса из вашего вывода в следующей команде:

sudo kill -HUP 1234

Эта команда отправляет сигнал HUP процессу xinetd, заставляя его перезагрузить свою конфигурацию.

Наконец, убедимся, что Telnet-сервер запущен. Вы можете попробовать подключиться к нему с той же машины, используя команду telnet. Поскольку клиент telnet может не быть установлен по умолчанию, мы будем использовать netcat для тестирования соединения.

nc localhost 23

Если Telnet-сервер запущен, вы должны увидеть пустой экран или приглашение Telnet. Затем вы можете закрыть соединение, набрав Ctrl+], а затем quit. Если вы получаете сообщение "Connection refused", проверьте шаги выше еще раз.

Запуск в отладочном режиме с флагом -d

На этом этапе мы настроим xinetd для запуска Telnet-сервера в отладочном режиме. Запуск в отладочном режиме может предоставить ценную информацию о работе сервера, которая может быть полезна для устранения неполадок и понимания его работы.

Чтобы включить отладочный режим, нам нужно изменить файл конфигурации xinetd для Telnet, который мы создали на предыдущем этапе. Откройте файл /etc/xinetd.d/telnet с помощью nano:

sudo nano /etc/xinetd.d/telnet

Измените строку server, добавив опцию -d для включения отладочного режима. Теперь строка должна выглядеть следующим образом:

        server          = /usr/sbin/in.telnetd -d

Опция -d сообщает in.telnetd запуститься в отладочном режиме, обеспечивая более подробный вывод.

Нажмите Ctrl+X, затем Y, а затем Enter, чтобы сохранить файл и выйти из nano.

Теперь перезапустите службу xinetd, чтобы применить изменения. Как и раньше, мы будем использовать команду kill -HUP. Сначала найдите идентификатор процесса xinetd:

ps -ef | grep xinetd

Обратите внимание на идентификатор процесса xinetd (например, 1234). Замените 1234 на фактический идентификатор процесса из вашего вывода в следующей команде:

sudo kill -HUP 1234

Эта команда отправляет сигнал HUP процессу xinetd, заставляя его перезагрузить свою конфигурацию, теперь с Telnet-сервером, работающим в отладочном режиме.

Чтобы наблюдать отладочный вывод, нам нужно перенаправить стандартный вывод xinetd в файл. Однако xinetd сам по себе не выводит информацию напрямую в файл. Отладочный вывод от in.telnetd -d будет отправлен в системные журналы. Мы можем отслеживать эти журналы с помощью команды tail -f.

Откройте новое окно или вкладку терминала. В этом новом терминале выполните следующую команду для отслеживания системных журналов:

sudo tail -f /var/log/syslog

Теперь вернитесь в исходный терминал и попробуйте подключиться к Telnet-серверу с помощью netcat:

nc localhost 23

После подключения (и отключения с помощью Ctrl+] и последующего ввода quit) вернитесь в терминал, где вы запустили команду tail -f /var/log/syslog. Вы должны увидеть отладочный вывод от in.telnetd, связанный с соединением. Этот вывод предоставит информацию о деятельности Telnet-сервера, например, о установке и завершении соединения.

Анализ отладочного вывода

На этом этапе мы проанализируем отладочный вывод, сгенерированный Telnet-сервером при работе в отладочном режиме. Понимание этого вывода поможет вам диагностировать проблемы, понять протокол Telnet и, возможно, выявить уязвимости.

Как вы видели на предыдущем этапе, отладочный вывод записывается в системный журнал (/var/log/syslog). Рассмотрим некоторые типичные строки отладочного вывода и их значение.

Сначала убедитесь, что вы по-прежнему отслеживаете системный журнал в отдельном окне терминала:

sudo tail -f /var/log/syslog

Затем подключитесь к Telnet-серверу с помощью netcat в исходном терминале:

nc localhost 23

Введите несколько символов, а затем отключитесь, набрав Ctrl+], а затем quit.

Теперь рассмотрите вывод в терминале с syslog. Вы должны увидеть строки, похожие на следующие (точный вывод может отличаться):

Oct 26 14:30:00 labex in.telnetd[1234]: connect from ::1
Oct 26 14:30:00 labex in.telnetd[1234]: telnetd: sock_host_addr: ::1
Oct 26 14:30:05 labex in.telnetd[1234]: ttloop: client wrote 5 bytes
Oct 26 14:30:05 labex in.telnetd[1234]: recv: got IAC
Oct 26 14:30:05 labex in.telnetd[1234]: recv: IAC SB
Oct 26 14:30:05 labex in.telnetd[1234]: recv: got IAC SE
Oct 26 14:30:10 labex in.telnetd[1234]: ttloop: client wrote 6 bytes
Oct 26 14:30:10 labex in.telnetd[1234]: recv: got IAC
Oct 26 14:30:10 labex in.telnetd[1234]: recv: IAC SB
Oct 26 14:30:10 labex in.telnetd[1234]: recv: got IAC SE
Oct 26 14:30:15 labex in.telnetd[1234]: Exit on signal 15

Разберём некоторые из этих строк:

  • connect from ::1: Это означает, что соединение было установлено с IPv6-адреса петли (::1), который эквивалентен 127.0.0.1 для IPv4.
  • telnetd: sock_host_addr: ::1: Это подтверждает исходный адрес соединения.
  • ttloop: client wrote 5 bytes: Это показывает, что клиент (ваша сессия netcat) отправил 5 байт данных на сервер.
  • recv: got IAC: IAC означает "Interpret As Command" (Интерпретировать как команду). Telnet использует специальные управляющие коды, и IAC является префиксом для этих кодов.
  • recv: IAC SB и recv: got IAC SE: SB означает "Subnegotiation Begin" (Начало подпереговоров), а SE означает "Subnegotiation End" (Конец подпереговоров). Эти строки показывают, что клиент и сервер проводят переговоры по настройкам.
  • Exit on signal 15: Это означает, что процесс telnetd завершился после получения сигнала 15, который является сигналом по умолчанию, отправляемым командой kill без указания номера сигнала. Это произошло, когда вы закрыли соединение netcat.

Анализируя этот отладочный вывод, вы можете получить представление о протоколе Telnet и о том, как сервер обрабатывает соединения и данные. Эта информация может быть ценной для анализа безопасности, устранения неполадок и понимания сетевого взаимодействия.

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

Резюме

В этом лабораторном занятии мы начали с настройки Telnet-сервера на виртуальной машине LabEx с использованием xinetd для управления службой telnetd. Это включало установку необходимых пакетов (telnetd и xinetd) и настройку xinetd для прослушивания Telnet-соединений и запуска демона Telnet-сервера.

Был создан файл конфигурации /etc/xinetd.d/telnet и заполнен настройками для включения Telnet-службы, указания исполняемого файла сервера и обработки журнала соединений. Наконец, служба xinetd была перезапущена, чтобы применить изменения в конфигурации и подготовить Telnet-сервер к тестированию.