Чеклист безопасности туннелей — гайд по аудиту

Зачем туннелям чеклист безопасности

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

Откуда берётся большинство инцидентов? Не из уязвимостей протоколов, а из человеческих ошибок: разработчик забыл ротировать токен, туннель остался работать на ночь с продакшен-базой за ним, фаервол разрешает трафик из любого источника. Структурированный чеклист устраняет эти ошибки системно.

Эта статья содержит 15-пунктный чеклист аудита безопасности для туннелей с практическими командами, примерами конфигурации и сравнением безопасных и небезопасных практик. Чеклист применим к любому инструменту туннелирования, но примеры используют fxTunnel — open-source инструмент туннелирования для HTTP, TCP и UDP. Для общего понимания того, как работают туннели, читайте «Что такое туннелирование».

15-пунктный чеклист безопасности туннелей

Ниже представлен полный чеклист. Каждый пункт включает что проверять, почему это важно и как провести проверку. Чеклист упорядочен от наиболее критичного (шифрование и аутентификация) до операционного (мониторинг и жизненный цикл).

1. Проверьте, что TLS-шифрование активно

Зачем: Без TLS весь трафик между вашей машиной и relay-сервером передаётся открытым текстом. Любой на сетевом маршруте — провайдер, оператор Wi-Fi, злоумышленник — может прочитать и модифицировать его. Подробнее об этом – в нашей статье «TLS 1.3 в туннелировании».

Как проверить:

# Проверка версии TLS для вашего туннельного эндпоинта
openssl s_client -connect your-tunnel.fxtun.dev:443 2>/dev/null | grep "Protocol"
# Ожидаемый вывод: Protocol  : TLSv1.3

# Проверка полной цепочки сертификатов
openssl s_client -connect your-tunnel.fxtun.dev:443 -showcerts 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates

fxTunnel шифрует все соединения TLS 1.3 по умолчанию — настройка не требуется.

2. Убедитесь в использовании TLS 1.3, а не TLS 1.2 или старее

Зачем: TLS 1.2 поддерживает устаревшие наборы шифров с известными уязвимостями (RC4, 3DES, CBC). TLS 1.3 полностью устраняет их и обеспечивает forward secrecy для каждой сессии.

Как проверить:

# Принудительное использование TLS 1.3 — убедитесь, что соединение успешно
openssl s_client -connect your-tunnel.fxtun.dev:443 -tls1_3 2>/dev/null | grep "Protocol"
# Ожидаемый вывод: Protocol  : TLSv1.3

# Проверка, что TLS 1.1 отклоняется
openssl s_client -connect your-tunnel.fxtun.dev:443 -tls1_1 2>&1 | grep -i "error\|alert"
# Ожидаемый вывод: handshake failure или protocol version error

3. Используйте токены аутентификации

Зачем: Без аутентификации любой, кто обнаружит ваш relay-сервер, сможет создавать туннели. Токены гарантируют, что подключаться могут только авторизованные клиенты.

Как проверить:

# Генерация токена на сервере
fxtunnel server token generate --name "dev-alice"
# -> Token: fxt_a1b2c3d4e5f6...

# Использование токена при создании туннеля
fxtunnel http 8080 --token fxt_a1b2c3d4e5f6...

# Проверка: попытка подключения без токена — должна провалиться
fxtunnel http 8080
# -> Error: authentication required

4. Никогда не хардкодьте токены в исходном коде

Зачем: Токен, закоммиченный в Git-репозиторий — это токен, утёкший всем, кто имеет доступ к репозиторию. Включая публичный GitHub, если вы случайно запушите.

Как проверить:

# Поиск утёкших токенов в кодовой базе
grep -rn "fxt_" . --include="*.sh" --include="*.yml" --include="*.yaml" \
  --include="*.env" --include="*.json" --include="Makefile"

# Правильный подход: используйте переменные окружения
export FXTUNNEL_TOKEN="fxt_a1b2c3d4e5f6..."
fxtunnel http 8080
# fxTunnel автоматически читает FXTUNNEL_TOKEN из окружения

Храните токены в менеджере секретов CI/CD (GitHub Actions secrets, GitLab CI variables, AWS Secrets Manager) и никогда в системе контроля версий.

5. Открывайте только нужный порт

Зачем: Каждый открытый порт — это поверхность атаки. Если вам нужен туннель на порт 8080, не туннелируйте всю машину. Туннель на один порт ограничивает радиус поражения в случае проблем.

Как проверить:

# Правильно: открываем только порт, который использует приложение
fxtunnel http 8080

# Неправильно: открываем несколько портов «на всякий случай»
# fxtunnel tcp 22    <- SSH открыт в интернет!
# fxtunnel tcp 5432  <- PostgreSQL открыт в интернет!

Создавайте туннели только для тех портов, которым нужен внешний доступ в данный момент.

6. Настройте правила фаервола на хосте туннеля

Зачем: Фаервол — ваша вторая линия обороны. Даже при компрометации туннеля правила фаервола предотвращают латеральное перемещение по сети.

Как проверить:

# UFW (Ubuntu/Debian) — разрешить только исходящий трафик туннеля
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow out 443/tcp comment "fxTunnel TLS connection"
sudo ufw enable
sudo ufw status verbose

# iptables — ограничить входящие соединения только localhost
sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8080 -s 127.0.0.1 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 8080 -j DROP

# Проверка: нет ли неожиданных прослушивающих портов
ss -tlnp | grep -v "127.0.0.1"

7. Используйте тестовые данные, никогда — продакшен

Зачем: Туннель создаёт публичную точку входа в ваш локальный сервис. Если этот сервис работает с продакшен-базой с реальными данными пользователей, компрометация туннеля означает утечку данных.

Как проверить:

• Убедитесь, что приложение подключено к тестовой/dev базе, а не к продакшену.
• Используйте тестовые API-ключи (Stripe test mode, sandbox-среды).
• Используйте фейковые данные пользователей (без реальных email, без реальных платёжных данных).

# Проверьте строку подключения к базе данных
env | grep DATABASE_URL
# Должно быть: DATABASE_URL=postgres://localhost:5432/myapp_test
# Не:          DATABASE_URL=postgres://prod-db.example.com/myapp_prod

8. Останавливайте туннели, когда они не используются

Зачем: Работающий туннель — это открытая дверь. Чем дольше он активен, тем больше окно для обнаружения и эксплуатации атакующим.

Как проверить:

# Список всех работающих процессов fxTunnel
ps aux | grep fxtunnel

# Остановите туннель, когда закончите
# Нажмите Ctrl+C в терминале или:
kill $(pgrep fxtunnel)

# В CI/CD: используйте timeout или явный шаг очистки
timeout 300 fxtunnel http 8080 --token "$FXTUNNEL_TOKEN" &
TUNNEL_PID=$!
# ... запустите тесты ...
kill $TUNNEL_PID

9. Проверяйте подписи вебхуков

Зачем: Даже с TLS необходимо проверять, что входящие запросы действительно приходят от ожидаемого сервиса (Stripe, GitHub, Telegram). Подписи вебхуков обеспечивают эту гарантию. Если вы настраиваете вебхуки через туннель, пошаговый разбор есть в статье «Тестирование вебхуков через туннель».

Как проверить (пример на Node.js):

const crypto = require('crypto');

function verifyStripeSignature(payload, sigHeader, secret) {
  const elements = sigHeader.split(',');
  const timestamp = elements.find(e => e.startsWith('t=')).slice(2);
  const signature = elements.find(e => e.startsWith('v1=')).slice(3);

  const signedPayload = `${timestamp}.${payload}`;
  const expected = crypto
    .createHmac('sha256', secret)
    .update(signedPayload)
    .digest('hex');

  return crypto.timingSafeEqual(
    Buffer.from(signature),
    Buffer.from(expected)
  );
}

10. Мониторьте трафик туннеля через инспектор запросов

Зачем: Нельзя защитить то, что не видишь. Мониторинг входящих запросов позволяет обнаружить неожиданные паттерны трафика, вредоносные полезные нагрузки и попытки несанкционированного доступа.

Как проверить:

fxTunnel включает встроенный инспектор запросов, который логирует каждый HTTP-запрос с полными заголовками, телом и таймингами. На платных планах (от $5/мес) инспектор также поддерживает replay — повторную отправку любого запроса для отладки.

# Запуск туннеля с включённым инспектором
fxtunnel http 8080 --inspect

# UI инспектора доступен в браузере
# -> Inspector: http://127.0.0.1:4040

Регулярно просматривайте вывод инспектора на предмет:

• Неожиданных IP-адресов источников или строк User-Agent
• Запросов к путям, которые вы не создавали
• Аномально больших тел запросов
• Массовых запросов (возможные попытки brute-force)

11. Регулярно ротируйте токены

Зачем: Токены могут утечь через логи, скриншоты, историю терминала или общие окружения. Регулярная ротация ограничивает окно уязвимости.

Как проверить:

# Отзыв старого токена
fxtunnel server token revoke --name "dev-alice"

# Генерация нового токена
fxtunnel server token generate --name "dev-alice-2026-q2"
# -> Token: fxt_x9y8z7w6v5u4...

# Обновление переменной окружения или менеджера секретов
export FXTUNNEL_TOKEN="fxt_x9y8z7w6v5u4..."

Ротируйте токены как минимум раз в квартал или немедленно при подозрении на утечку.

12. Ограничивайте доступ к туннелю по IP (где возможно)

Зачем: Если вы знаете, какие IP-адреса нуждаются в доступе к туннелю (офис, CI/CD-раннер, конкретный клиент), ограничение по IP исключает весь остальной трафик.

Как проверить:

# Ограничение на уровне фаервола (серверная сторона)
sudo ufw allow from 203.0.113.10 to any port 443 comment "Office IP"
sudo ufw allow from 198.51.100.0/24 to any port 443 comment "CI/CD subnet"
sudo ufw deny 443/tcp

# Или ограничение на уровне приложения через реверс-прокси
# Пример nginx:
# location / {
#     allow 203.0.113.10;
#     allow 198.51.100.0/24;
#     deny all;
#     proxy_pass http://localhost:8080;
# }

13. Используйте кастомные домены с проверенными сертификатами

Зачем: Случайный субдомен вроде abc123.fxtun.dev подходит для быстрого тестирования. Для демонстраций клиентам, интеграций вебхуков с валидацией отправителя или долго работающих туннелей кастомный домен с проверенным сертификатом создаёт доверие и позволяет использовать certificate pinning.

fxTunnel поддерживает кастомные домены на платных планах (от $5/мес). Сертификат выдаётся автоматически через Let’s Encrypt.

# Использование кастомного домена для туннеля
fxtunnel http 8080 --domain demo.yourcompany.com

# Проверка, что сертификат соответствует вашему домену
openssl s_client -connect demo.yourcompany.com:443 2>/dev/null | \
  openssl x509 -noout -subject
# Ожидаемый вывод: subject=CN = demo.yourcompany.com

14. Проводите аудит open-source кода перед деплоем

Зачем: Открытый код означает, что вы можете проверить реализацию безопасности. Закрытые инструменты вроде ngrok требуют доверия вендору на слово. У fxTunnel код на GitHub — проведите аудит перед деплоем.

Что проверять:

• Конфигурация TLS: минимальная версия, наборы шифров, валидация сертификатов.
• Обработка токенов: хранение, сравнение (timing-safe), отзыв.
• Поток данных: логирует ли relay-сервер содержимое трафика? (fxTunnel — нет.)
• Зависимости: актуальны ли они? Есть ли известные CVE?

# Клонирование и аудит исходного кода fxTunnel
git clone https://github.com/mephistofox/fxtun.dev.git
cd fxtun.dev

# Проверка конфигурации TLS
grep -rn "tls.Config" --include="*.go"

# Проверка известных уязвимостей в зависимостях
go list -m all | nancy sleuth
# или
govulncheck ./...

15. Документируйте конфигурацию безопасности

Зачем: Безопасность без документации — это безопасность, которая деградирует со временем. При смене состава команды недокументированные конфигурации теряются, токены перестают ротироваться, правила фаервола устаревают.

Что документировать:

• Какие порты туннелируются и зачем.
• Где хранятся токены (менеджер секретов, окружение).
• Расписание ротации токенов.
• Правила фаервола и их назначение.
• Кто имеет право создавать туннели.
• Процедура реагирования на инциденты: что делать при утечке токена или компрометации туннеля.

Безопасные vs небезопасные практики: сравнительная таблица

Применение чеклиста: пошаговое руководство

Давайте пройдём чеклист для установки fxTunnel от начала до конца.

Шаг 1: Установка и проверка клиента

# Установка fxTunnel
curl -fsSL https://fxtun.dev/install.sh | bash

# Проверка установленной версии
fxtunnel version

Шаг 2: Настройка аутентификации

# Установка токена через переменную окружения (никогда не хардкодьте)
export FXTUNNEL_TOKEN="fxt_a1b2c3d4e5f6..."

# Проверка, что токен не попал в отслеживаемые файлы
grep -rn "fxt_" . --include="*.sh" --include="*.yml" --include="*.env"
# Ожидаемый вывод: пусто

Шаг 3: Запуск туннеля с минимальной экспозицией

# Запуск HTTP-туннеля к вашему dev-серверу
fxtunnel http 3000 --inspect

Шаг 4: Проверка TLS

# В другом терминале проверьте TLS 1.3
openssl s_client -connect your-tunnel.fxtun.dev:443 -tls1_3 2>/dev/null | grep "Protocol"
# -> Protocol  : TLSv1.3

Шаг 5: Применение правил фаервола

# Заблокируйте хост — разрешите только исходящий трафик туннеля
sudo ufw default deny incoming
sudo ufw allow out 443/tcp comment "fxTunnel"
sudo ufw enable

Шаг 6: Мониторинг и остановка

# Проверьте инспектор по адресу http://127.0.0.1:4040 на предмет неожиданного трафика

# Когда закончите, остановите туннель
# Нажмите Ctrl+C или:
kill $(pgrep fxtunnel)

# Убедитесь, что процессы туннеля не остались
ps aux | grep fxtunnel

Чеклист безопасности для CI/CD-пайплайнов

Туннели в CI/CD-средах (превью-деплои, интеграционные тесты с внешними API) требуют дополнительной осторожности. Детально эта тема разобрана в статье «CI/CD и превью-окружения с туннелями».

# Пример GitHub Actions: безопасный туннель в CI/CD
name: Integration Tests
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Start application
        run: npm start &

      - name: Create tunnel with timeout
        env:
          FXTUNNEL_TOKEN: ${{ secrets.FXTUNNEL_TOKEN }}
        run: |
          # Установка fxTunnel
          curl -fsSL https://fxtun.dev/install.sh | bash

          # Запуск туннеля с таймаутом 5 минут
          timeout 300 fxtunnel http 3000 &
          sleep 5  # Ожидание инициализации туннеля

      - name: Run integration tests
        run: npm test

      # Туннель автоматически завершается после окончания джоба
      # или после 300-секундного таймаута — что наступит раньше

Ключевые правила безопасности CI/CD:

1. Храните токен в секретах CI/CD — никогда в файле воркфлоу.
2. Используйте timeout — предотвратите бесконечную работу туннелей при зависании джоба.
3. Генерируйте токены для каждого пайплайна — ротируйте токены по окружениям или веткам.
4. Явно очищайте ресурсы — не полагайтесь только на завершение процесса; проверяйте через ps.

Планы fxTunnel и функции безопасности

fxTunnel предоставляет функции безопасности на всех планах, с расширенными возможностями на платных тарифах:

Бесплатный план включает TLS 1.3 и токен-аутентификацию без ограничений по трафику. Pro (от $5/мес) добавляет кастомные домены и полный инспектор с replay, а Team (от $10/мес) поддерживает 10+ одновременных туннелей.

FAQ

Сколько проверок безопасности нужно провести перед открытием туннеля в интернет?

Начните с пяти обязательных: убедитесь, что TLS 1.3 включён, токены аутентификации настроены и не вшиты в код, открыт только нужный порт, фаервол ограничивает доступ, мониторинг или логирование работает. Дальше пройдитесь по полному чеклисту из 15 пунктов выше.

Можно ли безопасно использовать туннель в CI/CD-пайплайне?

Можно, если обращаться с токеном как с любым другим секретом: хранить в менеджере секретов CI/CD (GitHub Secrets, GitLab CI variables), не коммитить в репозиторий и убивать процесс туннеля по завершении пайплайна. У fxTunnel для этого есть флаг --token и переменная окружения FXTUNNEL_TOKEN.

Безопасно ли пробрасывать базу данных через туннель?

Для разработки и тестирования – да, при условии что TLS включён и используется токен-аутентификация. Продакшен-базу пробрасывать нельзя ни при каких обстоятельствах. При локальной работе используйте тестовые учётные данные, добавьте правила фаервола и останавливайте туннель, как только закончите.

Как проверить, что мой туннель использует TLS 1.3, а не старую версию?

Самый быстрый способ – выполнить openssl s_client -connect your-tunnel.fxtun.dev:443 и найти TLSv1.3 в строке Protocol. Ещё можно кликнуть на значок замка в браузере и посмотреть сертификат. fxTunnel по умолчанию работает через TLS 1.3, дополнительная настройка не нужна.

Чем чеклист безопасности отличается от пентеста для туннелей?

Они дополняют друг друга. Чеклист – это методичная проверка конфигурации и известных практик: шифрование, аутентификация, открытые порты, логирование. Пентест – это попытка реально взломать систему, имитируя атаки. Чеклист ловит типичные ошибки конфигурации, а пентест находит то, что всплывает только под реальной нагрузкой.