Wi-Cat / Wive-NG
340 subscribers
65 photos
14 files
56 links
Wireless Cat LLC (https://wi-cat.ru , https://wikidevi.wi-cat.ru).

Новости, статьи, анонсы относительно операционной сиcтемы Wive-NG, беспроводного оборудования, а так же темы затрагивающие Wi-Fi (802.11) в общем.
Download Telegram
Участились жалобы на якобы взломы домашних роутеров. Цель взлома - использование как узлы бот сетей и/или для амплификации DDOS.

Давайте всё же повторим простые правила что бы этого избежать от более критичных к менее:
1) web/ssh иные службы не следует разрешать с WAN без необходимости, либо делать это только с конкреnных IP
2) все пароли должны быть сложными (анализ данных в репортах показал что 99,9999% случаев либо были пароли по умолчанию, либо словарные). Не стоит думать, что если вы не разрешили доступ с WAN то можно не менять реквизиты доступа к админке.
3) Большинство "взломов" роутеров осуществляется со скомпроментированных устройств под управлением Windows уже из локальной сети. Т.е. просто смотрят адрес шлюза и стучатся туда на Web или SSH... Поэтому реквизиты доступа должны быть изменены при настройке в обязательном порядке!
4) пароль на WiFI должен быть весьма сложным. Особенно если вам пришлось (в силу кривости клиентов) отключить PMF.
5) Ни разу не обновлённое ПО. Тут всё просто. Не смотря на то что уязвимости критичные находят достаточно редко, всё же стоит как минимум в момент установки обновить софт. Это в сотни раз снизит вероятность взлома ботами (никто не будет вас ломать вручную ибо это ну ооочень дорого, а вот автоматом...).
6) Никаких WEP/WPA1 от слова НИКОГДА. В 2022г это аналогично сетям без пароля вообще

Список не полный. То что бы не взрывать мозг ограничимся хотя бы этим.

P.S. Ни одного именно взлома (в полном смысле слова) пока выявлено не было.Во всех случаях были проблемы именно с паролями (либо дефолт либо словарные) и чаще всего доступ разрешённый с WAN без фильтрации. На вопросы зачем и почему - ответа не последовало.
Прилетело и нашей площадке на которой хостятся DNS и Wi-Cat.RU.

Поэтому если у вас возникли проблемы с доступом к сервисам Wi-Cat просьба просто подождать. Уверен админы площадки отобьются от атак. На худой конец перенесу хостинг DNS на личные сервера где уже всё тихо. ;)

#DDOS
Добавил тему на форуме с расширенной инфой. Так же там можно предложить какие модели и каких вендоров стоит поддержать в первую очередь исходя из критериев. https://wi-cat.ru/forums/topic/757/#postid-10295
Продолжается адовый DDOS на NIC.RU где расположены наши DNS сервера.

Во избежание потери доступа к системе обновлений, викидеви и сайту wi-cat стоит в настройках DNS сервера в UI Wive прописать (как локальные записи) минимальный набор:

up1.wi-cat.ru - 188.44.109.70
wi-cat.ru - 91.189.114.7
wikidevi.wi-cat.ru - 5.172.21.43

Если до понедельника админы NIC.RU не победят, придётся уносить DNS сервера...
Wi-Cat / Wive-NG pinned Deleted message
Wi-Cat / Wive-NG pinned Deleted message
Финализируем 4.4.х ветку.

Релиз 4.4.10:
1) обновлены openssl, dropbear chillispot, ipt_netflow
2) бэкпорт ряда исправлений из текущего мэинлайна ядра (сеть/память)
2) добавлен профиль для поддержки hotspot сервиса от WiFly
3) в график на странице информации о радио интерфейсе добавлена возможность отображения SNR
4) ряд других мелких исправления в web интерфейсе

Кстати, DNS у хостера вроде отпустило, будем надеяться не повториться.
4.4.11
1) устранена уязвимость в библиотеке zlib CVE-2018-25032
2) в драйверах всех поддерживаемых радиочипов исправлена установка WMM очереди по умолчанию

zlib в wive используется например трансмишн, ntfs-3g, nginx и т.д.

Не смотря на то, что эту уязвимость будут пытаться эксплуатировать (а главное смогут это сделать удалённо например атакуя nginx), лучше всё же обновиться.

Тем более никаких действий кроме как нажать кнопку обновить от пользователя не требуется. ;)

Обновление не требует каких-либо дополнительных действий от пользователя кроме собственно нажатия кнопки обновить.
Упс. Забыл обещанный одному из постоянных клиентов фикс актуальный только для pptp/l2tp на доступе, когда адрес сервера задан как ip. Да и то не всегда.

В командировке релизится всегда так, вот что значит работа в не приспособленном для этого месте (записочек с заметочками перед глазами нет и склероз во всей красе =))).

3 строчки кода в ините. Тем кто обновился на 4.4.12 или у кого на доступе не PPTP/L2TP (что скорее всего так ибо эти протоколы нынче большая редкость на доступе) или просто всё работает как нужно можно игнорировать 4.4.13. Правка достаточно специфичная, просто если сейчас не войдёт в релиз потом долго придётся человеку ждать (выделяется 4.5.х ветка). Потому собираю микро 4.4.13 релиз сейчас.

Готово ;)
Плановый 4.5.7 релиз.

1. обновлен uclibc-ng, бэкпорт некоторых правок из текущего mainline ядра (5.17.3)
2. продолжена переделка инита, избавились от необходимости в service скрипте (подготовка к интеграции ENT функционала)
3. получен и задействован PEN (58734) для snmp
4. для упрощения конфигурирования страницы с базовыми настройками сетевых интерфейсов объединены в одну (будет ещё дорабатываться)
5. временно убрано требование к минимальной версии протокола в SMB (вылезли проблемы совместимости с некоторыми системами)

Да и вообще весна... 😸
Пора открывать сезон....
Релиз 4.6.13.
1) исправлена уязвимость в Uclibc-NG позволяющая «отравить» локальный кэш DNS (ICS-VU-638779, CERT/CC VU#473698)
2) обновлены до последних версий openssl/dnsmasq/dropbear/lldpd/zabbix
3) произведена миграция на net-snmpd для реализации требования поддержки SNMPv3. Поддержка пока начальная. Специфичные для Wive MIB будут реализованы в процессе подготовки ENT устройств в ближайшие несколько месяцев.
4) доработки WEBUI для сокращения числа необходимых применений настроек
5) реализован софтовый оффлоад операций Linux Bridge (bridge fastpath)
6) бэкпорт исправлений в сетевой подсистеме из mainline ядра
В ближайшие пол года основная работа по Wive будет сосредоточена в направлении SMB и Enterprise устройств и связанного с этим функционала.

Домашние устройства так же будут получать обновления компонентов и исправления уязвимостей. Изменения в функционале домашнего оборудования будут приостановлены, что бы избежать потенциальных регрессий, да и в общем-то всё запрашиваемое заказчиками в ключе SOHO уже сделано.
5.0.9 Released. Описание разделим на 2 краткие части (в ближайшее время это будет постоянной практикой).

Изменения для всех устройств и изменения для AX и/или ENT.

Все устройства:
1) обновление компонентов ПО (radvd, ntfs-3g, dropbear, dnsmasq)
2) бэкпорты некоторых фиксов из mainline ядра
3) исправлены редкие утечки дескрипторов
4) множественные мелкие правки и продолжение избавления от рудиментов (например вызовов iwpriv из nginx) не меняющих логику
Для ENT устройств.
1) в web добавлена возможность управления ACK таймаутами (необходимо для outoor устройсв при построении длинных линков)
2) некоторые настройки радио стали доступны для изменения отдельно по бэндам
3) добавлены некоторые специфичные для режима клиента опции на странице Client/Repeater
4) начальная реализация проф интерфейса для управления и диагностики подключений клиентской части включая средства для контроля и удобной юстировки антенны.
5) в драйвере 7915 добавлены вызовы необходимые для реализации п4, а так же множественные попутные правки огрехов в части диагностических данных и мелкие оптимизации
Корректирующий релиз 5.0.14:
ENT/AX:

1. Добавлена возможность гибко настраивать RATE`ты для тех или иных режимов и типов фрэймов (будет расширяться)
2. В драйвер добавлена расширенная статистика, подумаем как красиво оформить в UI

ВСЕ:
1. DUO-F попытка исправить плавающую проблему с произвольным отключением клиентов (проявляется крайне редко, мне пока повторить не удалось, разбираемся)
2. DUO-F/ONE-F исправлен эффект гонки после некоторого времени работы если к 2.4ГГц подключен Xiaomi Mi6
3. Несколько бэкпортов фиксов из текущего мэинлайн ядра
5.0.16 Небольшой корректирующий релиз финализирующий 5.0.х ветку
1. обновлён openssl
2. исправлена работа cwmp в некоторых кейзах
3. mt79x5: временно отключено MU-MIMO в Upload (проблема с задержками перед посылкой первого фрейма после выхода клиента из сна, нужно репортить MTK, проблема в микрокоде который закрыт)
4. продолжен разбор полётов по проблеме некоторых клиентов с DUO-F, надеюсь удалось зафиксить окончательно Если нет, то будет ещё один релиз 5.0.х ветки (закроем её только когда проблема будет решена)
5.0.17
1) доработана логика обработки ситуации потери связи при выходе из зоны обслуживания АП и возвращения назад, ради уменьшения времени когда АП вновь сможет "пустить" клиента не дожидаясь истечения "ageout" таймаута
2) исправлена ошибка приводившая в редких случаях к тому, что запись для того или иного клиента в PMK cache не могла быть обновлена с первого раза
3) для DUO-F продолжена война с выше обозначенной проблемой, будем надеяться победа
4) обновлён микрокод mt7613 (duo-f)
Принято решение временно переключить DUO-F на 4.6.14 версию в системе обновлений. Проблема не сдаётся. Благо на текущий момент достигнута повторяемость в стерильных условиях, работаем.