Основы Kali Linux и ответственный аудит безопасности¶

Как это устроено¶

Kali Linux — дистрибутив на основе Debian, поставляемый с предустановленным инструментарием безопасности, а не другой операционной системой в каком-либо техническом смысле — всё, что в этом справочнике рассказано про управление пакетами Debian, systemd и общее поведение Linux, применимо к Kali без изменений.

Настройка изолированной лаборатории (единственный контекст, который предполагают примеры)¶

Прежде чем запускать что-либо из инструментов ниже, настройте сеть, которая не может достучаться ни до чего за пределами вашего контроля:

# На примере VirtualBox. Внутренняя (internal) сеть полностью изолирована: нет маршрута ни до
# хоста, ни до вашей LAN, ни до интернета. Подставьте имена своих VM; VM должны быть выключены.
VBoxManage modifyvm "kali" --nic1 intnet --intnet1 lab-net
VBoxManage modifyvm "metasploitable2" --nic1 intnet --intnet1 lab-net

У обеих VM ровно один адаптер — во внутренней сети, без NAT и без моста. Во внутренней сети нет DHCP-сервера, поэтому задайте каждой VM статический адрес из 192.168.56.0/24 (в этой статье цель — 192.168.56.10, Kali — 192.168.56.20). Это единственная конфигурация, которую предполагают примеры этой статьи.

Разведка: nmap¶

nmap -sV 192.168.56.10

Nmap scan report for 192.168.56.10
Host is up (0.00041s latency).
PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 2.3.4
22/tcp   open  ssh     OpenSSH 4.7p1 Debian
80/tcp   open  http    Apache httpd 2.2.8

-sV запрашивает определение версии — nmap не просто сообщает, что порт открыт, а пытается определить конкретное ПО и версию, слушающую на нём, что как раз и стало бы следующим шагом для сверки с известными уязвимостями. -sS (SYN-скан, нужен root) быстрее/незаметнее полного TCP-connect скана (-sT), поскольку никогда не завершает TCP-рукопожатие.

Процесс выявления уязвимостей¶

Ответственный процесс: определить сервис и версию (nmap -sV) → проверить, есть ли у именно этой версии известные, документированные уязвимости (через собственный changelog сервиса, базы CVE, или локальный searchsploit) → не запускать инструменты эксплуатации против того, что вы не подтвердили и по совпадению версии, и по вашей авторизации.

searchsploit vsftpd 2.3.4

searchsploit ищет по локальной, офлайн-копии базы Exploit-DB по имени/версии ПО — полезно, чтобы определить факт существования известной проблемы без необходимости сетевого доступа к базе уязвимостей (и без оповещения какого-либо мониторинга на цели, которую вы авторизованы эксплуатировать в рамках реального проекта).

Сканирование веб-приложений: nikto¶

nikto -h http://192.168.56.10

Помечает веб-сервер на предмет известных неверных конфигураций, устаревших сигнатур ПО и отсутствующих заголовков безопасности. Как и nmap, это разведка, не эксплуатация — она сообщает, что потенциально не так, что вы затем проверяете вручную, прежде чем делать какие- либо выводы.

Различия Ubuntu/Debian и RHEL-подобных систем¶

Неприменимо напрямую — сам Kali основан на Debian. Инструменты из этой статьи (nmap, nikto, searchsploit) также устанавливаются на любой дистрибутив через его собственный менеджер пакетов; ценность Kali — в предустановленности, курировании и актуальности набора, а не в уникальной доступности.

Практическое задание¶

1. Постройте изолированную лабораторную сеть, описанную выше.
2. Разверните намеренно уязвимую учебную VM (Metasploitable2 — стандартный выбор для обучения — она создана для взлома, только в изолированной сети).
3. Запустите nmap -sV против неё и определите как минимум три разных сервиса с их версиями.
4. Для одного определённого сервиса используйте searchsploit, чтобы проверить наличие известных проблем для этой точной версии, пока не запуская ни одного эксплойт-модуля.

Как проверить, что всё сделано правильно¶

• nmap -sV должен вернуть чистую таблицу сервис/версия, совпадающую с известным, задокументированным набором намеренно уязвимых сервисов Metasploitable2.
• searchsploit <service> <version> должен вернуть минимум один совпадающий результат для хорошо известных уязвимых версий, поставляемых в Metasploitable2 (эта VM существует именно затем, чтобы иметь обнаруживаемые, хорошо задокументированные проблемы для обучения).

Типичные ошибки¶

• Запуск любого скана против реального IP-адреса вместо изолированной подсети лаборатории из-за опечатки в цели или неправильно настроенной «host-only» сети, которая на самом деле мостовая. Дважды проверяйте ip -br addr show на самой Kali VM, что она действительно только в изолированной лабораторной подсети, прежде чем что-либо запускать.
• Трактовка находок сканера уязвимостей как подтверждённых фактов без ручной проверки — автоматические инструменты дают ложные срабатывания, и отчёт о неподтверждённых находках (в реальном авторизованном проекте) подрывает доверие клиента.
• Полный пропуск шага авторизации «просто попрактиковаться» против реального сайта, которым вы не владеете, рассуждая, что сканирование только на чтение безобидно. Обычно это не так с юридической точки зрения, независимо от технического намерения.

⚠ Опасные команды / правовые предупреждения¶

• Не запускайте ни один инструмент из этой статьи против IP-адреса или домена, которым вы не владеете или на тестирование которого у вас нет явного письменного разрешения. Это правовая граница, а не просто best practice — законы о компьютерных преступлениях в большинстве стран (американский Computer Fraud and Abuse Act, британский Computer Misuse Act и их аналоги в других странах) часто не требуют «намерения причинить вред» для состава правонарушения — самих попыток несанкционированного доступа часто достаточно.
• Фреймворки эксплуатации (Metasploit и аналоги) намеренно оставлены за рамками этой вводной статьи именно потому, что безопасный и законный запуск требует понимания авторизованного scope конкретного проекта, которое никакая обобщённая wiki-страница не может ответственно заменить.

Связанные статьи¶

• Файрвол Linux с nftables и iptables
• Харденинг SSH и аутентификация по ключам
• Сеть TCP/IP и набор команд ip

Контрольные вопросы¶

1. Почему «я только просканировал порты, никуда не заходил» ненадёжная юридическая защита в большинстве юрисдикций?
2. В чём разница между тем, что делают nmap -sS и nmap -sT на уровне TCP, и почему это важно для скрытности?
3. Почему «сканер это пометил» недостаточно, чтобы отчитаться о находке как подтверждённой в реальном проекте?
4. Какая конкретная ошибка сетевой конфигурации привела бы к тому, что «только лабораторное» упражнение случайно нацелилось на реальную внешнюю инфраструктуру?