Брандмауер – Блог страуса https://ostrich.kyiv.ua Sat, 15 Nov 2025 21:49:23 +0000 uk hourly 1 https://wordpress.org/?v=6.8.3 https://ostrich.kyiv.ua/wp-content/uploads/2024/02/ostrich-150x150.png Брандмауер – Блог страуса https://ostrich.kyiv.ua 32 32 Мережева ізоляція IoT-пристроїв на Ubiquiti https://ostrich.kyiv.ua/uk/2025/11/15/%d0%bc%d0%b5%d1%80%d0%b5%d0%b6%d0%b5%d0%b2%d0%b0-%d1%96%d0%b7%d0%be%d0%bb%d1%8f%d1%86%d1%96%d1%8f-iot-%d0%bf%d1%80%d0%b8%d1%81%d1%82%d1%80%d0%be%d1%97%d0%b2-%d0%bd%d0%b0-ubiquiti/ Sat, 15 Nov 2025 21:49:19 +0000 https://ostrich.kyiv.ua/?p=1867

Пристрої розумного будинку завжди знаходяться під прицілом зловмисників, а розробники не завжди приджіляють належної уваги цій безпеці, тому в цьому дописі розкажу як убезпечити свою мережу від подібних інцидентів.

Вступ

Пристрої «розумного будинку» все частіше стають частиною нашого побуту: термостати, освітлення, розетки, камери, колонки, сигналізації, тощо. Вони зручні, але водночас – це потенційні точки проникнення зловмисника в локальну мережу.

Щоб уникнути небажаних наслідків необхідно відмежувати основні пристрої від IoT за допомогою віртуальних мереж. Мережева ізоляція пристроїв розумного будинку – це вже не просто рекомендація, а необхідність.

Історія вже бачила подібні випадки – від ботнету Mirai, який перетворив мільйони відеокамер та роутерів на зброю для DDoS-атак, до вразливостей у Wi-Fi-принтерах та Bluetooth-колонках, через які зловмисники проникали у локальні мережі користувачів. Часто джерелом небезпеки стає не сам пристрій, а його хмарний сервіс: якщо такий сервіс скомпрометовано, нападник потенційно отримує доступ до кожного підключеного девайса в усьому світі, а через нього – і до домашньої мережі власника.

Причина цього проста: дешеві або несертифіковані гаджети рідко використовують шифрування, а хмарні сервіси не завжди дотримуються стандартів безпеки. У підсумку пристрій, який здається безпечним, стає «містком» між Інтернетом і особистими даними.

Визначення взаємодії пристроїв

У моєму випадку цим пристроєм був термостат Terneo SX, який керує системою «теплої підлоги» і водночас виступає тригером за електроспоживанням у моєму проєкті Telegram бот для моніторингу електроенергії я детально описав роль термостата в цьому ланцюгу.

Після збою хмарного сервісу Terneo я вирішив повністю ізолювати цей пристрій, аби навіть у разі компрометації він не міг «бачити» мої інші пристрої в мережі.

Щоб краще розуміти як будуть між собою взаємодіяти віртуальні мережі та пристрої всередині них, я візуалізував таку схему

Термостат працює у своїй власній підмережі, має доступ до Інтернету та взаємодіє з моїм Raspberry Pi виключно по протоколу ICMP.

Мережева ізоляція

Для реалізації графічної схеми необхідно виконати такі дії:

  • Створення зони файервола
  • Створення VLAN
  • Створення SSID
  • Створення правила Firewall

В мене мережеві пристрої належать до однієї екосистеми Unifi. Для початку роботи необхідно авторизуватися в Unifi Network Application від Ubiquiti. Всі необхідні налаштування будуть відбуватися в меню Settings.

Створення зони файервола

Важливо пам’ятати про особливість маршрутизації Ubiquiti: усі мережі за замовчуванням потрапляють до зони Internal, тому для ізоляції IoT-сегменту потрібно створити власну зону – наприклад, IoT Zone – і застосовувати політику міжзонного фільтрування.

Для створення власної зони файервола необхідно перейти в розділ Policy Engine та клацнути на посилання Create Zone. В меню праворуч ввести назву зони і зберегти зміни.

Після цього можна створювати нову віртуальну мережу, яку і додамо в щойностворену зону.

Створення VLAN

Перелік існуючих віртуальних мереж та створення нових, відбувається в розділі Network. Для створення нової VLAN необхідно клацнути New Virtual Network, заповнити відповідні поля, та трошки змінити базові параметри згідно списку нижче. Поля які залишаються за замовчанням я пропущу.

  • Name – надаємо назву VLAN Thermostat
  • Router – Gateway Lite – залишаємо без зміни
  • Zone – IoT – вибираємо із списку нещодавно створену зону
  • Host Address та Netmask – прописуємо адресу підмережі та її маску, в моєму випадку це 192.168.89.30/29
  • Advanced – Manual, щоб можна було вибрати додаткові налаштування
  • VLAN ID – за замовчанням визначається наступний номер за порядком. В мене була лише одна мережа, тому друга буде мати номер 2, але це значення можна змінити на своє.
  • Isolate Network – ставимо галочку, якщо вона не встановлена, щоб мережі були ізольовані між собою
  • Allow Internet Access – ставимо галочку, щоб вся підмережа мала доступ до інтернету
  • DNS Server – краще зняти галочку і прописати публічний DNS 8.8.8.8
  • Ping Conflict Detection – можна поставити галочку

Всі інші параметри можна залишити без змін.

Візуально основні налаштування виглядають так:

Створення SSID

Оскільки термостат працює бездротово по Wi-Fi, для нього необхідно створити окрему нову назву бездротової мережі Wi-Fi. В розділі WiFi клацаємо на посилання Create New і заповнюємо відповідні поля. Як і в минулому прикладі я пропущу параметри які відображаються за замовчанням та які я не буду редагувати.

  • Name – назва SSID, я ввів IoT
  • Password – необхідно вигадати складний пароль для підключення термостата
  • Network – із випадаючого списка вибрати раніше створену віртуальну мережу Thermostat
  • Broadcasting APs – оскільки в мене лише одна точка доступу то залишаю значення All
  • Advanced – вибираю Manual, щоб можна було при потребі внести зміни
  • Enhanced IoT Connectivity – при виборі цього пункту, багато розділів автоматично стануть недоступними для редагування враховуючи особливості розумних пристроїв.
  • Client Device Isolation – важливий пункт, його треба активувати, щоб декілька пристроїв навіть в ізольованій мережі не могли між собою взаємодіяти.
  • Multicast Enhancement – я поставив галочку для оптимізації обміну даними.

Всі інші параметри можна залишити без змін.

Візуально основні налаштування виглядають так:

Створення правила Firewall

Останнім і дуже важливим пунктом налаштування є створення правила брандмауера. В розділі Policy Engine внизу сторінки, під таблицею правил, буде посилання Create Policy для стоврення нового правила.

У відкритій бічній панелі треба надати назву правилу, визначити джерело та отримучвача трафіку, вказати порти, протоколи. Я вніс наступні налаштування:

  • Name – назва правила, IoT access
  • Source Zone – Internal, адже Распбері пай та інші пристрої належать саме до цієї зони
  • Device – Rpi, тут я обмежую джерело лише своєю Raspberi Pi по будь якому порту
  • Action – Auto Allow Return Traffic, галочка щоб термостат відповідав на пінги
  • Destination Zone – IoT це зона створена раніше спеціально для розумніх пристроїв
  • IP -> Specific -> 192.168.89.29 – вказуємо конкретну адресу термостата також залишаємо значення будь якого порту
  • Protocol – ICMP, адже це протокол по якому працює PING
  • Syslog Logging – ставимо галочку, щоб логувалася активність по цьому правилу.

Після створення віртуальної мережі та цього правила, в таблицю брандмауера додалося три записи:

Після таких налаштувань, термостат працює у своєму власному VLAN, має доступ лише до Інтернету та взаємодіє з моєю Raspberry Pi виключно по протоколу ICMP.

Перевірка результата

Як і очікувалось, після налаштування ізоляції будь-які спроби пінгувати адресу термостата 192.168.89.29 завершуються тайм-аутом. Це підтверджує, що між VLAN більше немає прямого маршруту, а фаєрвол блокує будь-який трафік у напрямку IoT-зони.

ping 192.168.89.29

Pinging 192.168.89.29 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.89.29:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

У той же час Raspberry Pi має виняток у фаєрволі, тож він повинен мати змогу спілкуватися з термостатом, адже відповідає за моніторинг електроспоживання. Спроба виконати пінг з Raspberry Pi:

ping 192.168.89.29
PING 192.168.89.29 (192.168.89.29) 56(84) bytes of data.
64 bytes from 192.168.89.29: icmp_seq=1 ttl=254 time=10.3 ms
64 bytes from 192.168.89.29: icmp_seq=2 ttl=254 time=3.19 ms
64 bytes from 192.168.89.29: icmp_seq=3 ttl=254 time=7.20 ms
64 bytes from 192.168.89.29: icmp_seq=4 ttl=254 time=1.85 ms
^C
--- 192.168.89.29 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.848/5.629/10.281/3.330 ms

Тут є важливий нюанс, пов’язаний з обладнанням Ubiquiti. Автоматичні правила на кшталт Isolated Networks або IoT access (Return) не можна редагувати, а головне – вони не підтримують логування. Це означає, що навіть коли фаєрвол блокує трафік між VLAN, ці події не з’являються ані у Flow, ані у подіях, ані у системних логах.

У результаті перевірки я отримав саме ту поведінку, на яку розраховував: термостат повністю ізольований від основної мережі, взаємодіє лише з дозволеним пристроєм, а всі інші спроби доступу блокуються на фаєрволі. Це гарантує, що навіть у разі компрометації хмарного сервісу або самого пристрою, загрожена буде лише IoT-зона, не вся домашня мережа.

Висновки

Безпека розумного будинку починається не з паролів, а з архітектури. Використовуйте сертифіковані пристрої, оновлюйте їх прошивки та завжди ізолюйте IoT-девайси у власному VLAN. Для власників Ubiquiti це зробити просто – кілька VLAN-ів, окремий SSID і створні фаєрвол-правила – і ваші розумні пристрої стають безпечними навіть у разі збою їхніх хмарних сервісів.

]]>