«У меня там миллиарды»: как мы изолировали «Умный Дом» от телефона с банковским приложением

Если мошенник взломает Умный Дом, он пойдёт дальше по Wi-Fi, войдёт в мой телефон и доберётся до банковских счетов. Там, на секундочку, миллиарды...

На последней фразе заказчик улыбнулся. Автоматика системы «Умный Дом» в доме ему была нужна, но облака, голосовые помощники и удалённое управление доверия не вызывали. От нас он хотел понять, есть ли у домашнего оборудования путь к его личным устройствам.

В проекте были проводная шина, IP-шлюз и локальный сервер визуализации. Управление с личного телефона обсуждалось, но заказчик согласился на отдельный планшет. Для автоматики мы предусмотрели локальную работу без постоянного выхода в интернет и соединений с личной сетью.

Здесь описаны проектные решения и программа приёмки. Адрес объекта и модели оборудования не раскрываются.

Что входит в проект «Умного Дома»
Список функций легко растёт: к свету добавляются шторы, климат, бытовая техника и мультимедиа. Для каждой функции следует определить конкретную команду, исполнительное устройство и поведение при отказе. Фраза «управление климатом» этих вопросов не закрывает. В таблице собраны типовые функции и связи со смежными разделами. Состав интеграций и права управления выбирают для конкретного дома.

В выбранной схеме камеры и регистратор остаются в своём сегменте, без видеопотока в автоматику (далее - «Умный Дом»). Системы пожарной безопасности выполняют свои функции независимо от бытовых сценариев. Наличие общего экрана само по себе не даёт ему права отключать защиту или снимать объект с охраны.

Что автоматика должна передать смежникам
У автоматики системы «Умный Дом» есть собственный комплект документации. Он опирается на решения разделов: ЭОМ, ОВиК, ВК и СС, а смежным разделам нужны встречные задания: питание устройств, кабельные трассы, место в щитах и интерфейсы оборудования. В рабочем комплекте нужны:

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

2. Чертежи: структурные схемы, планы оборудования и трасс, схемы щитов и подключений, маркировка кабелей и клемм.

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

4. Спецификация и задания смежникам. К сдаче их дополняют актуальные конфигурации, резервные копии, инструкции и программа приёмки.

На защите от протечки легко увидеть, где расходятся разделы. Датчик обнаружил воду, контроллер выдал команду, а перекрыть воду нечем: электроприводной кран не попал в проект ВК. Или кран есть, но питание к нему не предусмотрели. В задании нужны место установки, тип привода, питание, сигнал положения и согласованный порядок повторного открытия. Одной пиктограммы крана на планшете мало.

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

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

Что защищать внутри дома
Банковских реквизитов в командах освещения нет, но у автоматики есть другие ценные данные: расписания, события датчиков, сценарии присутствия и сервисные учётные записи. По ним можно узнать, когда дом пустует. Несанкционированные команды тоже имеют последствия: изменить отопление, поднять шторы или открыть подключённый привод.

Между выключателем и банковским приложением
В сценарии заказчика есть несколько отдельных переходов. IP-шлюз и сервер визуализации работают в компьютерной сети. Захватив один из этих узлов, злоумышленник получит точку для дальнейших действий в пределах доступных соединений. Дальше в этой цепочке остаётся личное устройство со своей защитой.

Android изолирует приложения с помощью UID и других механизмов защиты; iOS ограничивает сторонние приложения песочницей. Обычное приложение управления светом не получает права читать данные банковского приложения. Выход из песочницы через уязвимость ОС и кража данных через фишинг или выданные разрешения требуют разных способов защиты. Механизмы описаны в Android Application Sandbox и Apple Platform Security.

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

Сегментация сокращает возможности перемещения между устройствами после компрометации одного из них. Тот же принцип описывает NCSC в рекомендациях по lateral movement. Защита личного телефона и банковской учётной записи, в том числе от фишинга, остаётся отдельной задачей.

Пять зон и правила между ними
В проекте мы оставили проводные клавиши, датчики и исполнительные устройства на нижнем уровне. Локальные функции нужно запрограммировать так, чтобы они не зависели от сервера визуализации. Шлюзу, серверу и устройству управления нужна IP-сеть; для них выделили отдельный сегмент.

Межзонные соединения проходят через фаервол с политикой запрета по умолчанию, default deny. Сервисное окно временно меняет эту политику для конкретного соединения. DNS, синхронизацию времени и другие нужные службы тоже заносят в таблицу обмена; широкое правило «доступ к домашней сети» для них не требуется.

Где одного VLAN недостаточно
Сервер и планшет в одном VLAN обычно обмениваются кадрами через коммутатор, минуя IP-маршрутизацию. Поэтому правило в inet forward на роутере не заставит планшет обращаться только к одному порту сервера. Для такого ограничения нужен фаервол на сервере, ACL на коммутаторе или отдельный маршрутизируемый сегмент для планшета. Изоляцию остальных узлов внутри зоны проверяют отдельно. Различие между маршрутизируемым трафиком и трафиком к самому узлу описано в документации Netfilter hooks.

Ниже учебный фрагмент для нового стенда: личная и гостевая зоны выходят в интернет, все остальные межзонные соединения закрыты. Имена интерфейсов условные; wan0 предполагается только внешним интерфейсом, без маршрутов к другим локальным сетям. IPv6-транзит здесь явно запрещён.

Это только фильтрация транзита. Настройки VLAN, защита самого роутера (input), его исходящий трафик (output), VPN, DHCP/DNS и NAT в пример не входят. На рабочее устройство его нельзя накладывать без проверки существующих правил. Логику цепочек и состояний соединений можно сверить в документации nftables: chains, conntrack.

KNX Secure защищает разные участки
Проводная шина сама по себе не гарантирует защиту команд. Для KNX нужно различать два механизма. KNX IP Secure защищает KNX-связь на IP-участке; обычные телеграммы на TP-линии от этого не становятся зашифрованными. KNX Data Secure защищает обмен между совместимыми конечными устройствами. Для него нужны поддержка у участников обмена и корректные настройки в ETS.

Поддержку Secure проверяют по выбранным устройствам и настройкам проекта. Для HDL границы IP-сегмента задаются по тому же принципу. По модели и прошивке шлюза отдельно проверяют роли пользователей, шифрование и возможность отключить ненужные службы, например HTTP, Telnet или FTP.

Отдельный планшет и цена этого решения
Заказчик выбрал управление с настенных панелей и отдельного планшета без банковских приложений, личной почты и SIM-карты. Планшет подключается к автоматике Умного Дома; его доступ к серверу ограничивается на уровне сети или самого сервера, как описано выше. Пароль администратора на нём не нужен.

С отдельным планшетом удобства меньше: ещё одно устройство нужно держать под рукой и заряжать. Управление с личного телефона через разрешённый интерфейс сервера избавляет от этого, но создаёт связь между зонами и меняет модель угроз. Здесь заказчик согласился на отдельное устройство и отсутствие управления из поездки. В другом доме такой компромисс пришлось бы обсуждать заново.

Для Wi-Fi, к которому подключается планшет, скрытый SSID и список разрешённых MAC-адресов за самостоятельный барьер не считаем. Основную защиту дают шифрование, контроль подключения и правила обмена.

Облака и голосовые помощники в выбранный вариант не вошли. Обычный push на внешний телефон тоже требует внешнего канала. В закрытом режиме остаются сообщения на локальной панели и журнал; если понадобятся уведомления снаружи, придётся отдельно спроектировать их доставку и состав передаваемых данных.

Как открыть доступ технику и закрыть его обратно
Для обслуживания предусмотрен временный VPN с отдельной учётной записью или ключом специалиста. Владелец разрешает сеанс, фаервол пропускает только нужные соединения. Прямые пробросы портов управления автоматикой не нужны; UPnP отключён. Если VPN завершается на роутере, его вход во время работ относится к input, а доступ из VPN к устройствам проверяется отдельно.

После работ нужно закрыть доступ, завершить активный VPN-сеанс и проверить уже установленные соединения. В конфигурации с общим established,related accept удаление одного разрешающего правила не обязательно оборвёт действующий сеанс: потребуется закрыть туннель и при необходимости удалить связанные состояния conntrack. Учётные записи должны быть персональными, чтобы увольнение сотрудника не оставляло за ним общий пароль admin.

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

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

Заводские общие пароли меняют, права владельца, техника и обычного пользователя разделяют там, где оборудование это поддерживает. Проект ETS и конфигурации шлюзов передают владельцу в защищённом виде. Для KNX Secure в комплект входят нужные проектные данные и ключи, с отдельным порядком доступа к ним. Копию надо открыть и проверить: зашифрованный архив без известного пароля восстановить систему не поможет.

Для проверки требований к устройствам полезны NIST IR 8259A и ETSI EN 303 645 V3.1.3. Они описывают базовые меры: управление доступом и конфигурацией, защиту данных, обновления и отказ от универсальных заводских паролей.

С журналами легко переборщить в другую сторону: удалить всё ради лозунга «никакого сбора данных». История входов и изменений настроек пригодится, когда придётся разбирать инцидент. Эти события и ошибки сохраняют локально, задают срок хранения и права доступа. Передачу телеметрии производителю рассматривают отдельно.

Что произойдёт при ошибочной команде или отказе
Для климата нужны допустимые уставки и приоритеты команд, для приводов с длительным ходом нужны ограничения времени работы. Штатные защиты оборудования должны сохраняться при сбое визуализации. Ограничение, записанное в захваченном контроллере, нельзя считать независимой защитой от этого же контроллера.

В проекте предусмотрено отключение IP-шлюза без снятия питания с проводной шины. Но локальная работа сохранится только у функций, которые действительно не зависят от отключённого узла. Это проверяют для каждого сценария. Закрываемый шкаф ограничивает доступ к оборудованию; доступные разъёмы, панели и участки шины за его пределами остаются отдельными точками риска.

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

1. Отключить канал провайдера, затем отдельно Wi-Fi, сервер визуализации и IP-шлюз. Зафиксировать, какие функции сохранились в каждом режиме и совпадает ли результат с ТЗ.

2. Проверить связи между зонами в обоих направлениях, включая IPv6, если он используется. Проверять нужные протоколы и порты: отсутствие ответа на ping ещё не доказывает изоляцию.

3. Из сети автоматики проверить запрет выхода наружу, в том числе через DNS и прокси на роутере. Убедиться, что нет второго шлюза, модема или другого обходного подключения.

4. Проверить ограничения внутри сегмента: планшет обращается только к нужным службам, камеры работают с регистратором, а административные интерфейсы недоступны обычному пользователю.

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

6. Открыть сервисное окно и убедиться, что доступен только нужный узел. После закрытия проверить прекращение активного сеанса, запрет нового входа и наличие события в журнале.

7. Открыть резервные копии штатными средствами, проверить дату, пароль и комплектность. При наличии стенда выполнить пробное восстановление.

8. Проверить согласованные реакции на протечку, потерю связи и недопустимую уставку. Отдельно проверить ручное управление и штатные защиты оборудования.

Результаты заносят в протокол с версиями конфигураций и прошивок. Владелец получает схему сети, таблицу разрешённых соединений, список учётных записей и комплект для восстановления.

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