Termux — популярная среда для практического пентеста на Android: установка инструментов, автоматизация сценариев и сбор телеметрии на устройстве. При этом важно соблюдать правовые рамки: любые проверки должны проводиться только на системах, на которые у вас есть явное разрешение (внутренние стенды, собственные приложения, согласованные тестовые контуры).
В этой статье мы рассмотрим безопасный и контролируемый подход к тестированию мобильных приложений в Termux с использованием Metasploit, sqlmap и Burp Suite, а также организацию headless‑режима для автоматизации. Акцент — на легитимной методологии, предварительном согласовании, ограничении воздействия и правильной фиксации результатов.
Правовые и этические рамки
Перед любыми активными действиями убедитесь, что:
- у вас есть письменное/документированное разрешение на тестирование (или это полностью ваш стенд);
- тест выполняется в согласованных пределах (время, цели, объём данных);
- запрещены действия, которые могут повлечь ущерб: DoS‑атаки, эксплуатация без необходимости, массовое сканирование чужих диапазонов.
Если цель — аудит своего приложения, часто оптимально выделить отдельный тестовый контур: staging/qa окружение, копию базы данных, изолированную сеть.
Подготовка среды Termux
Рекомендуемый базовый сценарий подготовки:
pkg update && pkg upgrade -y
pkg install -y git curl wget proot-distro openssh python python-pip clang openssl
Далее — подготовка инструментов для анализа трафика и автоматизации:
pkg install -y termux-tools
pip install --upgrade pip
Для headless‑подхода важно заранее продумать:
- как вы будете сохранять артефакты (логи, дампы запросов, отчёты);
- где будет запущен прокси/интерфейс (например, на отдельной машине) и как Termux будет маршрутизировать трафик;
- как вы ограничите скорость/нагрузку на тестируемый сервис.
Сетевая схема: изолированный контур и локальная сеть
Чтобы тесты были управляемыми и безопасными, целесообразно создать локальную сеть для стенда (например, через VPN/виртуальную сеть для объединения устройств в одну подсеть, именно для организации локального взаимодействия, а не для обхода ограничений).
Принцип:
- Termux‑устройство и тестируемый сервис находятся в одной изолированной сети;
- доступ ограничен firewall’ом;
- логирование включено на стороне приложения/прокси.
Burp Suite в headless‑режиме: перехват и воспроизводимость
Для большинства мобильных проверок критично качественно воспроизводить HTTP/S‑запросы. Вариантов два:
- Использовать Burp Suite на отдельной машине (часто это практичнее) и настроить доверие сертификату на устройстве;
- Автоматизировать работу с импортом/экспортом сессий и сохранением данных.
Типовой процесс для перехвата трафика:
- Поднять Burp и настроить listener на нужном интерфейсе.
- Установить сертификат CA на устройство (или использовать штатные механизмы доверия в стенде).
- Зафиксировать базовую последовательность действий в приложении.
Пример сохранения конфигурации и использования экспорта сессий зависит от вашей редакции Burp Suite, но в рамках автоматизации обычно полезны:
- экспорт Burp project;
- сохранение HAR/Raw HTTP (если поддерживается вашим workflow);
- сегментация данных по эндпоинтам и параметрам.
Metasploit: автоматизация только в рамках разрешённого тестового плана
Metasploit — мощная среда. В легитимном процессе её применяют не как «универсальный взломщик», а как фреймворк для воспроизводимых проверок по заранее определённым мишеням и сигнатурам.
Важно: активные модули запускайте только по согласованным условиям и с учётом ограничений нагрузки.
Базовые шаги при работе с Metasploit в Termux обычно включают:
# Пример: запуск msfconsole (если установлен корректный пакет/окружение)
msfconsole
Дальше — работа по стратегии «сначала разведка, затем проверка в допустимых пределах». В рамках headless‑подхода полезны:
- скриптовая привязка модулей;
- автоматическое сохранение отчётов (логи);
- контроль параметров эксплуатации (timeouts, rate limit — если применимо).
sqlmap: проверка инъекций и корректное управление рисками
sqlmap предназначен для тестирования SQL‑уязвимостей. При автоматизации в Termux критично:
- не сканировать «всё подряд» без разрешения;
- не выполнять деструктивные операции;
- ограничивать объём запросов и глубину проверки;
- сохранять воспроизводимый план атаки (request/response, параметры, URL, заголовки).
Запуск в стиле «мягкой» валидации часто начинают с ограниченных проверок:
# Пример формата команды для проверки (подставьте свои параметры из тестового контура)
sqlmap -u "https://target.example/app" \
--data "param1=1&vulnParam=2" \
--batch --level=2 --risk=1 \
--threads=2 --timeout=10
Для headless‑режима важно, чтобы sqlmap сохранял вывод в файл:
sqlmap -u "https://target.example/app" \
--data "param1=1&vulnParam=2" \
--batch --level=2 --risk=1 \
--threads=2 --timeout=10 \
--output-dir ./artifacts/sqlmap
Рекомендуемая практика: сначала подтвердить наличие уязвимости на уровне «есть/нет», затем — в рамках согласованного плана — перейти к оценке влияния.
Интеграция workflow: от Burp к sqlmap и Metasploit
На практике эффективность достигается связкой:
- Burp — перехват и нормализация запросов, выделение параметров, сбор токенов/заголовков;
- sqlmap — воспроизводимые проверки инъекций на основе реальных запросов;
- Metasploit — проверки эксплойт‑поверхностей и сервисов, строго по согласованным целям.
Пример упорядоченного процесса (high-level):
- В Burp воспроизведите действие приложения (логин, открытие страницы, запрос конкретного API).
- Сформируйте «минимально необходимый» набор запросов для повторной отправки.
- Используйте эти данные для запуска sqlmap в режиме ограниченного воздействия.
- При необходимости переключайтесь на Metasploit только для проверок в пределах конкретной поверхности (например, специфичный сервис/версия/эндпоинт).
Ключ — дисциплина артефактов: любой запуск должен сопровождаться фиксированными входными данными и логами.
Headless‑режим: как организовать автоматизацию без GUI
Под headless‑режимом обычно понимают отсутствие ручных действий в момент проверки: запуск скриптов, сбор логов, сохранение результатов в файлы.
На стороне Termux это реализуется через:
- пакетирование команд в сценарии;
- единый каталог артефактов;
- логирование stdout/stderr;
- структуру результатов по датам/целям.
Пример простого «скриптового» каркаса:
mkdir -p ./artifacts/{burp,sqlmap,metasploit}
date > ./artifacts/run-info.txt
# sqlmap
sqlmap ... > ./artifacts/sqlmap/sqlmap.log 2>&1
# условно: запуск msfconsole через командный скрипт (если применимо в вашем workflow)
# msfconsole -q -r ./scripts/msf.rc > ./artifacts/metasploit/msf.log 2>&1
Если Burp запускается на отдельной машине, Termux‑часть остаётся «клиентом перехвата»: вы запускаете тест‑сценарии приложения и фиксируете трафик, а затем переносите артефакты на рабочую станцию.
Контроль нагрузки и безопасность тестовых данных
Чтобы тестирование не превратилось в инцидент:
- ограничивайте скорость запросов и количество потоков;
- используйте staging‑копии данных;
- маскируйте PII (персональные данные) в логах;
- включайте мониторинг: CPU/память/ошибки сервера, чтобы остановить тест при деградации.
Сбор доказательств и оформление отчёта
Профессиональный отчёт обычно включает:
- описание цели и границ теста;
- методологию (какие классы проверок выполнены);
- входные данные: URL/эндпоинты, параметры, сценарии действий;
- результаты: подтверждение, трейс/лог, временные метки;
- рекомендации по исправлению и регресс‑план.
Практически полезно хранить всё в одном дереве:
./artifacts/
run-info.txt
burp/
.burpproj
.log
sqlmap/
sqlmap.log
output
metasploit/
msf.log
evidence/
requests.txt
responses.har
Частые ошибки при автоматизации в Termux
- Отсутствие разрешения на тест и выход за рамки стенда.
- Слишком агрессивные параметры (высокие уровни risk/threads без необходимости).
- Нет воспроизводимости: нет сохранённых входных запросов из Burp.
- Смешение данных: логирование без структурирования по целям и датам.
- Неучтён TLS/сертификаты при перехвате — из-за этого тесты могут дать ложные результаты.
Заключение
Тестирование безопасности мобильных приложений в Termux с использованием Metasploit, sqlmap и Burp Suite в headless‑подходе возможно и эффективно, если выстраивать процесс грамотно: согласовать цели, обеспечить изолированный тестовый контур, фиксировать артефакты и ограничивать воздействие. Такой подход повышает воспроизводимость проверок и качество доказательств, а также снижает риски для тестируемых систем.
Если вам нужен аудит мобильного приложения или вы хотите настроить безопасный workflow для регулярных проверок (включая интеграцию перехвата трафика, автоматизацию и оформление отчётов), обратитесь в РыбинскЛАБ — мы поможем организовать процесс и провести работы в рамках требований заказчика и законодательства РФ.