diff --git a/projects/benilux/README.md b/projects/benilux/README.md index 2465dba..b991b75 100644 --- a/projects/benilux/README.md +++ b/projects/benilux/README.md @@ -91,6 +91,10 @@ aliases: [Benilux, benilux, Бенелюкс, "OpenWrt Benilux"] - **2026-05-20** — компрометация через WAN-SSH brute-force; роутер несколько часов рассылал спам и брутил чужие SSH. Закрыто, см. [[decisions/2026-05-20-benelux-compromise]]. +## Планы / концепции + +- [[wifi-segmentation-concept]] — сегментация Wi-Fi на хозяев / персонал / гостей (UniFi VLAN + firewall на Cudy). Черновик 2026-06-01, внедрение отложено. + ## Aliases для FTS `Benilux`, `Бенелюкс`, `OpenWrt Benilux`, `100.70.207.97`, `Истра-Benelux`, `КП Бенелюкс`, `Александр Бенелюкс`. diff --git a/projects/benilux/wifi-segmentation-concept.md b/projects/benilux/wifi-segmentation-concept.md new file mode 100644 index 0000000..e585358 --- /dev/null +++ b/projects/benilux/wifi-segmentation-concept.md @@ -0,0 +1,176 @@ +--- +date: 2026-06-01 +type: concept +status: draft +tags: [benilux, unifi, vlan, segmentation, wifi, security, openwrt] +aliases: [Бенелюкс сегментация WiFi, Benelux WiFi segmentation] +--- + +# Концепция: сегментация Wi-Fi в Бенелюксе (хозяева / персонал / гости) + +> **Статус — ЧЕРНОВИК-КОНЦЕПЦИЯ.** Изменения в боевую сеть НЕ внесены. +> Внедрять по фазам, в согласованное окно, с проверкой и откатом на каждом шаге. +> +> **Решения Олега (2026-06-01):** персонал = **только интернет** (без принтера/папки); podkop для гостей/персонала — **решается при внедрении**; внедрение **отложено** — пока согласуем концепцию с Александром. + +## 1. Задача + +Александр хочет развести по разным сетям и правилам три категории пользователей: +- **Хозяева** — расширенный доступ ко всему (умный дом, камеры, NAS, медиа, принтеры, интернет). +- **Домработники / персонал** — только интернет. Без умного дома, камер, принтеров, хозяйских устройств. +- **Гости** — только интернет, изоляция от всех и друг от друга. + +Сейчас **все на одном SSID `Kesco-Home` в одной плоской сети `192.168.1.0/24`** — ноутбуки хозяев, телефоны гостей, камеры, KNX, охранка Paradox, Miele, NAS видят друг друга на L2. + +### ⚠️ Поправка по «DoS из-за работников» +Задокументированный инцидент [[../../decisions/2026-05-20-benelux-compromise]] — **внешний** брут WAN-SSH (`1qaz!QAZ`) → спам-релей с публичного IP. Это **не работники**. Он уже закрыт (SSH с WAN снят, PasswordAuth off, nft-drop). «Тормоза сети» у клиента = следствие того релея либо забивание канала кем-то изнутри. Сегментация **не про тот инцидент**, но закрывает другой реальный класс угроз: скомпрометированный гость / уволенный работник / заражённое IoT внутри LAN. Дополнительно от «внутреннего DoS» (забивание канала) защищает SQM + rate-limit (см. §6). + +## 2. Текущее состояние (риски плоской сети) + +- Один L2-домен: телефон гостя в одном бродкаст-сегменте с камерами Protect, KNX/Jung, Wirenboard, охранкой Paradox `192.168.1.12`, NAS, хозяйскими маками. +- Один общий PSK на всех → уволили работника = надо менять пароль всем, включая хозяев. +- ~55 устройств, куча IoT с заводскими прошивками (Reolink ×5, Imilab/Xiaomi, Dahua, Miele ×2, Mi TV) — типичные цели ботнетов; любое из них видит хозяйские ноуты. +- UniFi-управление (Cloud Key, свитчи, точки) в той же подсети, что и пользователи. + +## 3. Архитектурная особенность объекта (читать перед внедрением!) + +**Шлюз — Cudy TR3000 (OpenWrt), а НЕ UniFi.** USG удалён. Значит роли: + +| Слой | Делает | Что именно | +|------|--------|-----------| +| **UniFi** (Cloud Key + AP + свитчи) | контроль Wi-Fi | SSID, тег VLAN на SSID, client-isolation на точке, bandwidth-профили | +| **Cudy / OpenWrt** | роутинг + безопасность | терминация VLAN (802.1q), DHCP на каждую подсеть, **inter-VLAN firewall (вся изоляция)**, NAT, rate-limit, SQM | + +Следствия, которые ломают «накликать в UniFi и забыть»: +1. Сети VLAN20/30/40 в контроллере UniFi создаются типом **«VLAN Only»** — без UniFi-DHCP и без UniFi-gateway. DHCP/шлюз отдаёт Cudy. Иначе — двойной DHCP и конфликт. +2. **Транк Cudy ↔ US-24-Pro** должен нести теги 20/30/40 (native = VLAN1 хозяев). Порты UniFi по умолчанию пропускают все сети («All»), но **native network порта должен совпасть** с VLAN1. Это точка №1 для ошибок. +3. Весь путь кадра «AP → промежуточные свитчи → Cudy» должен пропускать теги (trunk «All» на всех аплинках). +4. VLAN ID на UniFi-сети ДОЛЖЕН совпадать с подсетью на Cudy (VLAN20→192.168.20.1 и т.д.). +5. Captive-portal для гостей у UniFi работает в **AP-enforced** режиме (точка сама перехватывает) — он не требует UniFi-шлюза, так что доступен. Но для Фазы 1 достаточно отдельного PSK. + +## 4. Целевая модель — 4 сегмента + +| VLAN | Сегмент | Подсеть (на Cudy) | SSID | Шифрование | Кто | +|------|---------|-------------------|------|-----------|-----| +| 1 (native) | **Owners + инфраструктура** | `192.168.1.0/24` (как есть) | `Kesco-Home` | WPA2/WPA3-PSK | хозяева, умный дом, камеры, NAS, принтеры, UniFi-mgmt | +| 20 | **Staff (домработники)** | `192.168.20.0/24` | `Kesco-Staff` | WPA2-PSK (свой пароль) | персонал | +| 30 | **Guest (гости)** | `192.168.30.0/24` | `Kesco-Guest` | WPA2/WPA3-PSK или captive | гости | +| 40 | **IoT** (Фаза 2) | `192.168.40.0/24` | — (в осн. проводные) / `Kesco-IoT` | WPA2-PSK | камеры не-UniFi, KNX-шлюзы, Miele, ТВ, бытовуха | + +Подсети `.20/.30/.40` сейчас свободны и НЕ анонсируются в NetBird (коллизий с Знаменское/НИИКН по `192.168.1.0/24` не добавляют). Третий октет = VLAN ID — мнемонично. + +**Принцип Фазы 1 (хирургический):** **не трогаем** `192.168.1.0/24` — хозяева, умный дом, камеры, статические IP, KNX, охранка, сканирование в папку, медиа остаются как есть и продолжают работать. Только **добавляем** два изолированных сегмента Staff + Guest. Минимальный риск для рабочей инфры. + +```mermaid +graph TD + WAN[Интернет / WAN] --> CUDY[Cudy TR3000 / OpenWrt
шлюз · DHCP · firewall · podkop] + CUDY -->|trunk: native VLAN1 + tag 20,30,40| SW[UniFi US-24-Pro
+ 7 свитчей] + SW --> APS[13× UniFi U6 AP
по комнатам] + + APS -.SSID Kesco-Home / VLAN1.-> OWN[👑 Хозяева + инфра
192.168.1.0/24
доступ ко всему] + APS -.SSID Kesco-Staff / VLAN20.-> STAFF[🧹 Персонал
192.168.20.0/24
интернет + принтер] + APS -.SSID Kesco-Guest / VLAN30.-> GUEST[👥 Гости
192.168.30.0/24
только интернет, изоляция] + APS -.VLAN40 Фаза2.-> IOT[📷 IoT / камеры / KNX
192.168.40.0/24] + + OWN ==>|разрешено| STAFF + OWN ==>|разрешено| GUEST + OWN ==>|разрешено| IOT + STAFF -.X блок.-> OWN + GUEST -.X блок.-> OWN + GUEST -.X блок.-> STAFF + IOT -.X блок.-> OWN + + classDef own fill:#d4edda,stroke:#28a745 + classDef staff fill:#fff3cd,stroke:#ffc107 + classDef guest fill:#f8d7da,stroke:#dc3545 + classDef iot fill:#d1ecf1,stroke:#17a2b8 + class OWN own + class STAFF staff + class GUEST guest + class IOT iot +``` + +## 5. Матрица доступа (firewall на Cudy) + +| Источник ↓ \ Назначение → | Интернет | Owners LAN | Staff | Guest | IoT | Принтер M775 | UniFi mgmt | +|---|---|---|---|---|---|---|---| +| **Owners** | ✅ (podkop) | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| **Staff** | ✅ | ❌ | (изоляция*) | ❌ | ❌ | ❌ (по запросу→§10) | ❌ | +| **Guest** | ✅ | ❌ | ❌ | ❌ (client-isolation) | ❌ | ❌ | ❌ | +| **IoT** | ⚠️ мин. | ❌ | ❌ | ❌ | (изоляция*) | ❌ | ❌ | + +\* client-isolation внутри сегмента: гости не видят друг друга (L2 на AP + L3 reject на Cudy). Для Staff — на выбор (изолировать безопаснее; если нужен общий доступ к принтеру по mDNS — нужен avahi-reflector только до IP принтера). + +**На входе в DHCP/DNS:** Staff/Guest зонам разрешён только `udp/67-68` (DHCP) и `53` (DNS) к Cudy — больше ничего к самому роутеру (LuCI/SSH/Clash-API `:9090` закрыты от этих зон). + +**podkop (обход блокировок):** +- Owners — через podkop (как сейчас). +- Staff — прямой интернет без podkop (меньше нагрузки на туннель). [развилка] +- Guest — по желанию хозяев: прямой ИЛИ через podkop, если хотят чтобы у гостей соцсети/YouTube открывались. [развилка] + +## 6. Anti-DoS / комфорт канала + +«DoS» в быту = кто-то забил канал или открыл тысячи соединений. Меры: +1. **SQM/cake на WAN Cudy** — честное разделение полосы, один клиент не задушит остальных. Лучшая защита от «внутреннего DoS». +2. **Bandwidth-профили UniFi** (User Group) на SSID: Guest напр. 20/20 Мбит/с на клиента, Staff 50/50, Owners без лимита. +3. **nftables conntrack-лимит** на Cudy: `ct count` per-IP + SYN-rate limit на forward из Guest/Staff (заслон от шторма соединений). +4. **Client-isolation** на гостевом WLAN (L2) — гости не атакуют друг друга и не сканируют сегмент. +5. WAN уже закрыт после инцидента (это и была настоящая «атака»). Доступ к роутеру (SSH/LuCI) — только LAN/NetBird. + +## 7. Операционный плюс — посегментная ротация паролей + +Отдельный PSK на каждый SSID. Уволили работника → меняете **только `Kesco-Staff`**, хозяев и гостей не трогаете. Гостям можно давать временный пароль / ваучер captive-portal и менять хоть еженедельно. Это и есть «разные правила» на входе. + +## 8. План внедрения по фазам (с проверками) + +### Фаза 0 — подготовка (без даунтайма) +- [ ] Бэкап: UniFi (контроллер → Settings → Backup) + Cudy (`/etc/config` tar, особенно `network`, `firewall`, `dhcp`). +- [ ] Свериться live: число LAN-портов Cudy и какой порт идёт в US-24-Pro; текущая разметка транка. +- [ ] Проверка: восстановление из бэкапа понятно и доступно. + +### Фаза 1 — Guest + Staff (целевой результат запроса, низкий риск) +1. **Cudy**: интерфейсы `staff` (VLAN20, 192.168.20.1/24) и `guest` (VLAN30, 192.168.30.1/24); DHCP-пулы; firewall-зоны по матрице §5; SQM на WAN. + - *Проверка:* с тестового устройства в каждом VLAN — есть IP/DNS/интернет; **нет** пинга в `192.168.1.0/24`; нет доступа к LuCI/SSH Cudy. +2. **Транк**: порт Cudy→US-24-Pro = native VLAN1 + tagged 20,30; на UniFi аплинки «All». + - *Проверка:* теги доходят до AP (клиент Staff/Guest получает адрес из нужной подсети, не из .1). +3. **UniFi**: сети `Staff`/`Guest` тип **VLAN Only** (ID 20/30); SSID `Kesco-Staff`, `Kesco-Guest` со своими PSK; на Guest — client-isolation + bandwidth-профиль. Staff по умолчанию = только интернет (принтер НЕ открываем). + - *Проверка:* подключение к каждому SSID, попадание в правильный VLAN, изоляция, скорость-кап. +4. **Документация**: обновить [[../../claude-memory/benelux-topology]] и [[README]]; пароли в [[credentials]]. + +### Фаза 2 — вынос IoT (рекомендуется, средний риск, отдельное окно) +- Перенести камеры не-UniFi (Reolink/Dahua/Xiaomi), KNX-шлюзы, Miele, ТВ в VLAN40; firewall: `Owners→IoT` allow, `IoT→*` reject (кроме нужного облака/NTP). +- ⚠️ Аккуратно: умный дом (Wirenboard/KNX) и охранка Paradox могут зависеть от L2-связности с хозяйскими контроллерами — проверять покомпонентно, не разом. Камеры UniFi Protect живут на Cloud Key и логически отдельны. +- *Это и есть главный реальный анти-ботнет/анти-DoS выигрыш* — заражённое IoT перестаёт видеть хозяев. + +### Фаза 3 — mgmt VLAN (опционально) +- Вынести UniFi-управление (Cloud Key, свитчи, точки) в отдельный VLAN. Риск потери управления при ошибке → только когда §1-2 устоялись. + +## 9. Риски и откат + +| Риск | Митигирование | +|------|---------------| +| Ошибка в транке → пропал Wi-Fi/управление | Бэкап Cudy+UniFi; менять в окне; доступ к Cudy по NetBird (`100.70.207.97`) независимо от LAN | +| Двойной DHCP (UniFi поднял свой) | Сети в UniFi строго «VLAN Only» | +| Сломался умный дом при выносе IoT (Фаза 2) | Делать Фазу 2 отдельно, покомпонентно, с проверкой KNX/Paradox | +| Потеря удалённого доступа | NetBird на Cudy + LuCI по ключу не зависят от сегментации | +| Native VLAN mismatch | Явно задать native=VLAN1 на обоих концах транка | + +Откат: восстановить `/etc/config/{network,firewall,dhcp}` на Cudy + UniFi из бэкапа → возврат к плоской сети за минуты. + +## 10. Открытые вопросы + +**Решено (2026-06-01):** +- ✅ **Персонал = только интернет.** Принтер/папка/музыка не открываем. Если позже понадобится печать — точечный allow Staff→`192.168.1.148:631/9100/443`, обсудить отдельно. +- ⏸ **podkop для гостей/персонала** — решаем при внедрении (по умолчанию: хозяева через podkop, остальные прямой интернет). +- ⏸ **Объём** — сейчас только концепция, внедрение после согласования с Александром. + +**Ещё уточнить перед стартом:** +1. **Масштаб Фазы 1:** подтверждаем «не трогаем `192.168.1.0/24`, только добавляем Staff+Guest»? (рекомендую — да) +2. **IoT (Фаза 2):** включаем в план этого захода или строго Фаза 1? +3. **Captive-portal для гостей** (ваучеры, приветствие) или достаточно отдельного PSK на `Kesco-Guest`? + +## Связано +- [[README]] — топология объекта +- [[../../claude-memory/benelux-topology]] — полная инвентаризация UniFi +- [[../../decisions/2026-05-20-benelux-compromise]] — инцидент (внешний, не работники) +- [[credentials]] — доступы Cudy/UniFi