Публичный Wi-Fi и рабочие доступы: чем рискует разработчик

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

Что видно в общей сети

• Имена сайтов, к которым вы подключаетесь: DNS-запросы и имя сервера в начале TLS-соединения (SNI) передаются открыто, если не включены шифрованный DNS и Encrypted Client Hello.
• Весь незашифрованный трафик: HTTP-страницы, старые API без TLS, локальные инструменты, открытые по HTTP.
• Сам факт и объём соединений с вашими серверами.
• Широковещательные объявления вашей системы: имя компьютера, общие папки и сервисы, которые анонсируют себя через mDNS и NetBIOS.

При этом содержимое HTTPS-соединений и SSH-сессий соседи прочитать не могут. Риск не в том, что шифрование взломают, а в том, что вас незаметно уведут на поддельный узел или вы сами отправите что-то без шифрования.

Основные атаки в открытой сети

Перед входом в сеть часто открывается страница авторизации. Вводите там только то, что просит заведение, и никогда не вводите рабочие пароли: страницу контролирует владелец сети.

Локальные сервисы: главный риск для разработчика

На ноутбуке разработчика работают базы данных, dev-серверы и админки. Дома это безопасно, а в общей сети к ним может подключиться любой сосед, если сервис слушает не только 127.0.0.1. Проверьте, какие порты открыты:

# macOS
lsof -nP -iTCP -sTCP:LISTEN
# Linux
ss -tlnp
# Windows (PowerShell)
Get-NetTCPConnection -State Listen

Адрес 0.0.0.0, :: или * в выводе означает, что сервис доступен со всех интерфейсов, в том числе из Wi-Fi. Частые примеры:

• Docker: -p 5432:5432 публикует порт на всех интерфейсах. Пишите -p 127.0.0.1:5432:5432. На Linux Docker добавляет свои правила iptables раньше ufw, поэтому ufw такой порт не закроет.
• python3 -m http.server по умолчанию слушает все интерфейсы. Добавляйте --bind 127.0.0.1.
• Флаг --host у dev-серверов вроде Vite открывает их в локальную сеть. В чужом Wi-Fi запускайте без него.
• Если вы когда-то перенастроили Jupyter, Redis или базу данных на 0.0.0.0 ради доступа с другого устройства, верните 127.0.0.1 перед поездкой.
• На macOS приёмник AirPlay слушает порты 5000 и 7000. Если в поездке он не нужен, выключите его в системных настройках.

Межсетевой экран и профиль сети

• macOS: включите межсетевой экран в системных настройках, раздел «Сеть». Из терминала: sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setglobalstate on. Ключ --setstealthmode on включает скрытый режим, в котором система не отвечает на сканирование.
• Windows: при подключении выберите профиль «Общедоступная сеть». В нём строже правила межсетевого экрана и выключено сетевое обнаружение.
• Linux: sudo ufw default deny incoming и sudo ufw enable. Помните, что опубликованные порты Docker этим не закрываются.
• Выключите общий доступ к файлам, AirDrop для всех и удалённый вход, если они не нужны прямо сейчас.
• Включите случайный MAC-адрес для Wi-Fi: в iOS и macOS это частный адрес Wi-Fi, в Windows случайные аппаратные адреса, в Android случайный MAC. Так сеть не связывает ваши визиты между собой.

SSH: не игнорируйте предупреждение о ключе хоста

Сообщение REMOTE HOST IDENTIFICATION HAS CHANGED в чужой сети нельзя пропускать. Оно может означать, что вы подключаетесь не к своему серверу. Сверьте отпечаток ключа с тем, что видели раньше или в панели хостинга, и только потом обновляйте known_hosts.

Отпечаток смотрите на самом сервере через веб-консоль хостинга, а не через подозрительное соединение:

# на сервере
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
# на ноутбуке, после проверки: удалить старую запись
ssh-keygen -R your-server.example

GitHub, GitLab и другие хостинги публикуют отпечатки своих ключей в документации. Если ssh спрашивает о новом ключе для github.com, сверьте его с ними, прежде чем отвечать yes.

Для своих серверов отпечатки можно опубликовать в DNS записями SSHFP и включить на клиенте VerifyHostKeyDNS yes. Надёжно это работает только для зоны, подписанной DNSSEC, иначе подменить можно и сам DNS-ответ.

Ключи, токены и сессии

• Защитите SSH-ключ паролем и добавляйте его в агент с ограничением времени: ssh-add -t 1h ~/.ssh/id_ed25519.
• Аппаратный ключ FIDO2 (ssh-keygen -t ed25519-sk) требует касания при каждом входе, а скопированный файл ключа без самого устройства бесполезен.
• Не включайте ForwardAgent yes для всех хостов: администратор промежуточного сервера сможет пользоваться вашим агентом. Для прыжка через бастион есть ProxyJump.
• Включите двухфакторную аутентификацию на GitHub, в облаках и у регистратора доменов.
• Выбирайте токены с ограниченным сроком и правами, например fine-grained токены GitHub, и короткие сессии облачных CLI вместо постоянных ключей.
• Храните долгоживущие токены в менеджере секретов или системной связке ключей, а не в открытых .env на рабочем столе.
• Не открывайте рабочие панели и API по туннелям без TLS.
• Проверьте адреса удалённых репозиториев (git remote -v): старый протокол git:// не шифрует данные и не проверяет сервер. Используйте HTTPS или SSH.

Шифрованный DNS и HTTPS

Шифрованный DNS скрывает от сети, какие имена вы запрашиваете, и не даёт подменить ответ. Его можно включить в браузере, в Chrome и Firefox это параметр защищённого DNS, или во всей системе. В Windows 11 DNS over HTTPS задаётся в свойствах сетевого подключения, в Linux с systemd-resolved через DNSOverTLS=yes в /etc/systemd/resolved.conf. На macOS и iOS системный шифрованный DNS настраивается профилем конфигурации, в Android для этого есть параметр частного DNS (Private DNS).

Включите в браузере режим «только HTTPS». Тогда попытка открыть сайт без шифрования закончится предупреждением, а не тихой загрузкой.

Если сеть ведёт себя подозрительно

Тревожные признаки: браузер ругается на сертификат хорошо знакомого сайта (NET::ERR_CERT_AUTHORITY_INVALID в Chrome, SEC_ERROR_UNKNOWN_ISSUER в Firefox), ssh сообщает о смене ключа хоста, известный сайт вдруг открывается по HTTP. Отдельный случай: страница авторизации просит установить сертификат или профиль конфигурации. Никогда этого не делайте: установленный корневой сертификат позволяет владельцу сети читать ваш HTTPS-трафик.

• Не нажимайте «всё равно перейти» и не отвечайте yes на новый ключ хоста.
• Отключитесь от сети и перейдите на раздачу интернета с телефона.
• Если успели ввести пароль или токен на подозрительной странице, смените пароль и отзовите токен сразу, а не по возвращении домой.
• Проверьте в настройках системы, не появилось ли новых сертификатов или профилей, которые вы не устанавливали.

Коротко: минимальный набор в поездке

• Включённый межсетевой экран, профиль публичной сети и выключенный общий доступ к файлам.
• Сервисы разработки слушают только 127.0.0.1, порты Docker опубликованы на localhost.
• Шифрованный DNS и режим «только HTTPS» в браузере.
• Предупреждение о смене ключа хоста SSH означает стоп и проверку отпечатка.
• Ключи с паролем, токены с коротким сроком, двухфакторная аутентификация.
• Если есть выбор, раздайте интернет с телефона вместо открытой сети.
• Защищённое подключение для всего трафика, пока вы в чужой сети. Соседям по Wi-Fi тогда виден только зашифрованный канал, а не ваши сайты и сервисы.