Безопасен ли Wi-Fi в отеле? Краткий ответ
Wi-Fi в отеле достаточно безопасен для обычного использования на актуальном Mac, и заметно безопаснее, чем подсказывает его репутация. Классическое предупреждение, что кто-то в двух номерах от вас читает ваши пароли из воздуха, почти устарело: практически весь важный трафик шифруется от конца до конца ещё до того, как покинет ваше устройство, и macOS вместе с актуальным браузером справляются с этим без вашего участия.
Это простая версия. Нюанс в том, что шифрование защищает content, not context. Никто в сети отеля не читает ваши письма, но сеть всё равно может видеть, что ваш Mac связался с конкретным почтовым сервисом, конкретным облачным диском и конкретным корпоративным VPN в 6:40 утра, каждое утро, пять дней подряд. За долгую поездку это складывается в поведенческий след, и всё это без взлома хотя бы одного соединения.
Две вещи отличают отель от кафе. Первая, identity: страница входа обычно просит вашу фамилию и номер комнаты, чтобы оператор мог связать каждое устройство и соединение с именованным гостем, а не с анонимным человеком с кофе. Вторая, duration: визит в кафе длится сорок минут, а проживание в отеле, это дни автоматического переподключения и фоновой синхронизации, которые идут, пока вы далеко от машины.
Так что честная модель угроз, это не перехват секретов. Это три другие вещи: Mac, открытый для плоской сети, полной незнакомцев, на несколько дней; подробная временная линия трафика, привязанная к вашему имени; и возможность подключиться к сети, которая лишь выглядит как сеть отеля. На все три есть простые ответы, и ни один из них не требует паники.
Что отличает сеть отеля от других публичных Wi-Fi
Все в здании подключены к одной плоской сети. Wi‑Fi для гостей в отеле часто разворачивают без изоляции клиентов, из-за чего гость в номере 412 и гость в номере 118 оказываются в той же широковещательной области, что и вы. Ваш Mac объявляет себя через Bonjour под тем именем, которое вы ему задали, зачастую это ваше настоящее имя и модель устройства, и любая служба общего доступа, оставленная включённой после какого-то проекта, доступна всем остальным. Некоторые сети действительно корректно изолируют клиентов, но определить это снаружи невозможно, поэтому предположите, что они этого не делают.
Каптивный портал связывает трафик с гостевой идентификацией. Номер комнаты и фамилия, иногда номер программы лояльности или адрес электронной почты для более быстрого доступа. Это не обязательно злонамеренно: так отель обеспечивает один аккаунт на комнату, а в нескольких юрисдикциях оператор обязан хранить логи подключений. Это означает, что выражение «анонимная публичная сеть» здесь не применяется. Что бы ни записывала сеть, это записывается на ваше имя.
Оборудование часто старое и редко трогается. Wi‑Fi в отелях обычно устанавливают один раз подрядчиком, управляют удалённо и оставляют без внимания годами, потому что он работает. Точки доступа и шлюзовые устройства не получают патчей, прошивки отстают на несколько версий, а стандартные настройки остаются по умолчанию. Это само по себе не атака, но означает, что собственные защиты сети, включая обещанную изоляцию, могут быть неправильно настроены или просто не работают.
Порталы намеренно вмешиваются в DNS. Чтобы страница авторизации вообще появилась, шлюз должен перехватить ваши первые запросы и перенаправить их, а это означает перехват DNS. Некоторые порталы продолжают это делать и после аутентификации, а некоторые разрешают имена по своим ответам на весь период пребывания. Именно поэтому зашифрованный DNS вызывает проблемы в отелях: если ваш Mac настроен на приватный профиль DNS или на пользовательский резолвер, портал часто не может вас перенаправить и страница входа не загружается, это самая частая жалоба на Wi‑Fi в отелях.
И затем вы остаетесь. Автоподключение означает, что Mac переподключается при каждом открытии крышки без запроса. Умножьте обычную фоновую активность macOS и десятка установленных приложений на четыре или пять дней, и риск уже не ограничивается одной сессией в ненадёжной сети, а превращается в постоянное пребывание в ней.
Что уже покрывает HTTPS и какую метадату он не показывает
Начнем с хороших новостей, потому что их много. HTTPS шифрует содержание соединения: содержимое страниц, поля форм, пароли, тела сообщений, API-запросы. Современные браузеры по умолчанию используют HTTPS и отказываются тихо понижать уровень, TLS 1.3, это норма, а большинство Mac-приложений шифруют свой трафик. Кто сидит в сети отеля с захватом пакетов, видит только зашифрованные данные. Старый трюк с добычей логинов в открытой сети давно не работает.
Что шифрование не скрывает, это факт и форму каждого соединения. IP-адрес назначения всегда виден, потому что пакеты должны маршрутизироваться. DNS-запросы видны, если только вы не используете зашифрованный DNS, что порталы часто блокируют. Имя сервера в TLS-рукопожатии видно на большинстве соединений сегодня, поскольку Encrypted Client Hello еще далеко не везде. А время, размер и частота каждого обмена видны любому на пути, независимо от уровня шифра.
Собранные за несколько ночей метаданные более информативны, чем кажется. Они показывают, какие сервисы вы используете, когда проснулись, когда вышли из здания и вернулись, как долго длились ваши видеозвонки, и к какой сети вы подключались. Почтовый клиент, опрашивающий каждые пять минут, это точный сигнал присутствия. Всё это не требует чтения сообщений. Метаданные, это настоящая уязвимость в сети отеля, а не содержимое.
Также есть остаточный трафик, который вообще не защищен. Некоторые старые или заброшенные приложения все еще проверяют обновления по обычному HTTP, а обнаружение устройств в локальной сети по сути не шифруется, поэтому mDNS и Bonjour транслируют имя вашего устройства и его сервисы всей гостевой сети. Обнаружение принтеров, обмен медиа и любые сервисы доверенной домашней LAN ведут себя так же в отеле, потому что ваш Mac не знает, что сеть изменила характер.
Единственная ситуация, когда HTTPS действительно не работает, это когда кто-то его переопределяет. Если появляется предупреждение о сертификате, не кликайте по нему и, если сеть просит установить профиль или корневой сертификат для доступа, отклоните и используйте сотовую связь. Отель нуждается в номере вашей комнаты, чтобы дать вам доступ в интернет. Он не нуждается в возможности выдавать сертификаты, которым ваш Mac доверяет.
Что реально можно сделать, в порядке эффективности
Оставьте брандмауэр Mac включённым и не делитесь ничем. Это самый ценный шаг, потому что он напрямую работает с общей сетью. Включите брандмауэр в Системных настройках, Сеть, Брандмауэр, а затем включите режим скрытности в его параметрах, чтобы Mac перестал отвечать на непрошеные запросы. Затем откройте Системные настройки, Основные, Общий доступ и убедитесь, что Общий доступ к файлам, Общий экран, Общий доступ к принтерам, Удалённый вход и Удалённое управление выключены, а AirDrop установлен в режим Только контакты. И помните, что брандмауэр macOS не делает: он фильтрует только входящие соединения, и ничего в нём не ограничивает исходящие подключения ваших приложений.
Ограничьте фоновую синхронизацию на всё время пребывания. Включите режим экономии данных именно для сети отеля в Системных настройках, Wi-Fi, Детали рядом с подключённой сетью. Он надёжно приостанавливает собственные фоновые задачи Apple: загрузки обновлений ПО, загрузки из App Store, синхронизацию Фото iCloud и разные отложенные задачи. Для сторонних приложений это лишь рекомендация, которую многие разработчики так и не реализовали, поэтому также закройте или поставьте на паузу клиенты облачной синхронизации и переведите Time Machine на ручное резервное копирование. Меньше фонового трафика, меньше метаданных и меньше сюрпризов, если отель считает трафик или ограничивает скорость.
Используйте VPN для шифрования, которого иначе не получите. VPN упаковывает всё, включая DNS и метаданные соединения, о которых говорилось выше, в один туннель к одному адресу, так что подробная временная шкала сводится к одному зашифрованному сеансу. Два честных оговорки: вы переносите доверие с отеля на оператора VPN, а не убираете его, поэтому выбирайте того, чью политику логирования вы действительно читали, и VPN не мешает приложениям подключаться. Он меняет путь, а не участников. Подключайте его после очистки captive portal и включайте kill switch, если клиент его предлагает.
Решите, какие приложения вообще могут выходить в сеть. Это то, чего VPN сделать не может. Шифрование относится к передаче данных, контроль приложений относится к области охвата. В сети, в которой вы проведёте несколько дней, большинству того, что установлено на вашем Mac, нет причины выходить в сеть: браузер, почтовый клиент и VPN-клиент обычно покрывают всё, что вы собираетесь делать. Всё остальное может молчать, пока вы не уедете, и это сокращает и след метаданных, и число процессов, доступных всему остальному в этой сети.
Подключайтесь к правильной сети и правильно её отключайте. Спрашивайте у стойки точное имя сети, а не угадывайте по списку, потому что поддельная точка доступа с правдоподобным названием отеля стоит почти ничего и остаётся одной из немногих действительно распространённых атак. Относитесь к сети с названием отеля без портала или к порталу, который просит номер карты вместо номера комнаты и фамилии, как к причине остановиться. Предпочитайте гостевую сеть с паролем WPA2 или WPA3, а не полностью открытую. При выезде откройте Системные настройки, Wi-Fi, Детали и выберите Забыть эту сеть, иначе Mac молча подключится к любой сети с этим именем в любой точке мира.
Контроль того, что делает ваш Mac, пока вы спите
Закрытая крышка не значит, что Mac офлайн. macOS периодически просыпается для доступа к сети, запускает плановое обслуживание, проверяет обновления и позволяет приложениям обновляться в фоновом режиме. За четыре ночи это сотни соединений, которые вы не инициировали, сделанных, пока вы спали или были вне номера, в сети, которую вы бы назвали ненадёжной, если бы кто-то спросил. В этом нет ничего злонамеренного. macOS просто считает, что каждая Wi-Fi сеть принадлежит вам, и дома это верно, а в номере 412, нет.
Именно поэтому ответ на эту задачу должен быть в управлении по приложениям. VPN шифрует туннель, но каждое приложение всё равно разговаривает, а режим экономии данных просто вежливо просит, и многие приложения отказываются. То, что реально уменьшает риск, это заранее решить, каким нескольким приложениям можно выйти в сеть, и применять это решение автоматически, а не вспоминать его каждый вечер.
Для этого и создан NetMute. Его защита для точек доступа замечает, что вы подключились к неизвестной или ненадёжной сети, и сразу применяет строгий профиль, не дожидаясь, пока вы об этом подумаете, а ещё обрабатывает captive portal, чтобы страница входа в отель всё равно загружалась, а не блокировалась вместе со всем остальным. Профили сети привязаны к имени Wi-Fi, поэтому профиль отеля сам возвращается при следующем подключении к этой сети, а обычный домашний профиль возвращается, как только вы приезжаете домой.
В повседневной работе всё остаётся простым. Любое приложение можно заблокировать одним щелчком, временные правила истекают сами, так что если вы разрешите обновлятору выход на десять минут, это не оставит постоянную дыру, а режим белого списка меняет всё на противоположное: в сеть выходит только то, что вы указали. Если в отеле трафик тарифицируется или соединение ограничивается, лимиты по приложениям останавливают нарушителей раньше, чем они станут проблемой.
После поездки людям чаще всего полезнее всего доказательства. Мониторинг трафика в реальном времени и журналирование на уровне доменов отвечают на главный вопрос всей статьи: что именно общалось, пока вы спали. Это стоит проверить хотя бы раз, потому что список обычно длиннее, чем кто-либо ожидает, и так легче составить профиль для следующей поездки.