Forwarded from НеКасперский
Wake up
Полистали ленту новостей за последнюю неделю и не сдержались не сделать конспирологический пост про большого брата.
Windows 11 ОС теперь автоматически включает резервное копирование ваших данных в OneDrive, предварительно выделив для вас место в облаке. Естественно, никакого разрешения Microsoft спрашивать у вас не собираются. Для этого они даже изменили свою политику конфиденциальности.
Ну и ладно, казалось бы, что плохого в резервной копии. Дело в том, что в корпорации весьма специфично относятся к данным пользователей на фоне своего отставания в сфере ИИ. Так, руководитель отдела AI в Microsoft заявил, что использовать пользовательский контент для обучения ИИ — это ок. Более того, он пользовательский контент называет «бесплатным». Кроме того, Мустафа Сулейман считает бесплатным и весь остальной контент, который можно найти в сети. Для его использования, по его мнению, не должно быть ограничений.
Есть загвоздка: резервное копирование включается при подключении устройства к сети. Видимо, чтобы минимизировать количество офлайн-устройств Microsoft убрали со своего сайта инструкцию по настройке локальной учётной записи, заменив её на противоположную, повествующую о том, как выйти из локальной учётки.
Полагаем, что незазорно обучать ИИ и на логах в роде Recall, баги в котором серьёзно беспокоят общественность.
Вроде ничего нового — Microsoft крадёт ваши данные. Но удивляет то, как открыто они сейчас это делают.
НеКасперский
Полистали ленту новостей за последнюю неделю и не сдержались не сделать конспирологический пост про большого брата.
Windows 11 ОС теперь автоматически включает резервное копирование ваших данных в OneDrive, предварительно выделив для вас место в облаке. Естественно, никакого разрешения Microsoft спрашивать у вас не собираются. Для этого они даже изменили свою политику конфиденциальности.
Ну и ладно, казалось бы, что плохого в резервной копии. Дело в том, что в корпорации весьма специфично относятся к данным пользователей на фоне своего отставания в сфере ИИ. Так, руководитель отдела AI в Microsoft заявил, что использовать пользовательский контент для обучения ИИ — это ок. Более того, он пользовательский контент называет «бесплатным». Кроме того, Мустафа Сулейман считает бесплатным и весь остальной контент, который можно найти в сети. Для его использования, по его мнению, не должно быть ограничений.
Есть загвоздка: резервное копирование включается при подключении устройства к сети. Видимо, чтобы минимизировать количество офлайн-устройств Microsoft убрали со своего сайта инструкцию по настройке локальной учётной записи, заменив её на противоположную, повествующую о том, как выйти из локальной учётки.
Полагаем, что незазорно обучать ИИ и на логах в роде Recall, баги в котором серьёзно беспокоят общественность.
Вроде ничего нового — Microsoft крадёт ваши данные. Но удивляет то, как открыто они сейчас это делают.
НеКасперский
Полезные сайты о кибербезопасности
киберзож.рф — о способах защиты себя и близких от киберугроз
кибер-буллинг.рф — об умении противостоять интернет-травле
выучисвоюроль.рф — о том, как распознавать телефонных мошенников и правильно действовать при их звонках
прокачайскиллзащиты.рф — о создании защищённых паролей и определении фишинга
киберзож.рф — о способах защиты себя и близких от киберугроз
кибер-буллинг.рф — об умении противостоять интернет-травле
выучисвоюроль.рф — о том, как распознавать телефонных мошенников и правильно действовать при их звонках
прокачайскиллзащиты.рф — о создании защищённых паролей и определении фишинга
Forwarded from Максим Горшенин | imaxai
#cpu
Копипаста с Хабр: Крупица истины в безумном заявлении «в России нет и не может быть чипов» и что из нее следует
Тут был диспут пару дней назад на фейсбуке с социологом Алексеем Рощиным, в котором он сделал совершенно безумное заявление "в России нет и не может быть чипов, а если что-то и есть, то оно на два поколения устарело"
Понятно, что в России чипы есть, например микроконтроллер MIK32 АМУР, выпущенный в Зеленограде на основе процессорного ядра от питерской компании Syntacore. Причем если сравнивать Амур с STM32 U0 2024 года (низкопотребляющий микроконтроллер от мирового лидера на 90 нм, 56 MHz), то нельзя сказать что российское "на два поколения устарело"
У микроконтроллеров крутость не в нанометрах (чип на 3 нм все равно не выдержит рядом с горячим автомобильным двигателем), а в системных и микроархитектурных решениях (трюки для экономии динамического энергопотребления, эффективный DMA, даже AI расширения в стиле ARM Ethos-U55)
Учитывая, что Рощин - человек не безумный, я попытался понять, что он имеет в виду, и кажется понял. Мира микроконтроллеров и встроенных процессоров для него не существует (гуманитарии-социологи не задумываются что микроконтроллеры с RTOS ныне есть и в утюгах), а чипы для него - это компьютеры с Windows, которые используют "все"
И вот если смотреть с такой дефиницией, то я с Рощиным совершенно соглашусь. В России нет, не было и никогда не будет конкурентоспособных процессоров архитектуры x86-64 на которых можно нормально (то бишь без медленной симуляции с QEMU и без бинарной трансляции) пускать Microsoft Windows. Неудачные бенчмарки Эльбруса в Сбербанке - это наглядная демонстрация тупиковости такой идеи
Но тут главная фишка не в недостатке экспертизы по проектированию процессоров в России (хотя и в ней тоже), а в том, что паровоз технологии x86-64 вкупе с Windows очень давно ушел. У Windows 30 лет назад, у x86 - 40 лет назад. Хотя x86 немного омолодили в 1990-е годы - за счет внедрения динамического конвейера в PentiumPro в 1996 году и 64-битности от AMD потом
Но попытки повторить все тупиковые решения и недокументированные совместимости, которые скопились в x86 с 1978 года / Intel 8086/8088 (который в свою очередь содержит бессмысленные сейчас совместимости с 8080 от 1974-го года, например H/L регистром) - это даже при наличии идеально подготовленных инженеров означало бы ковыряние тысяч инженеров во всякой ерунде многие годы и все равно бы не привело к успеху. То же самое ядро и приложения Windows
Путь России, Китая и другой зарождающейся мировой альтернативы - это линуксные компьютеры на RISC-V. Там можно легально, конструктивно и эффективно использовать открытые решения со всего мира, на основе которых строить свои
А x86-64 с Windows - это умирающие технологии, несмотря на миллиарды пользователей в мире и несмотря на то, что они умирать будут еще сто лет. Поднимать глаза к потолку что этого у России нет и не будет - это как ругать Нигерию, что та не может скопировать компьютеры на процессоре IBM Z
Не слышали о таком? Это современное продолжение IBM 360, которые СССР скопировал как ЕС ЭВМ в 1960-е годы. Да, оно еще живо!!! Работает в банках, которые не сошли c этого паровоза за 80 лет. Но повторять его не нужно
UPD: Самые дотошные могут спросить "а почему вы не вспоминаете про советские клоны 8086/186/286 на которых можно было запускать MS-DOS?" Я думал всунуть упоминание о них в какой-то форме в свою заметку, но потом решил что эта ветка дискуссии не способствует просветлению (последовательные, не конвейерные, 16-битные, не хочу даже углубляться в protected-mode versus real mode и можно ли было запустить Windows 2.1 aka Windows/286 на малоиспользуемом советском клоне 286-го)
@imaxairu Подписаться
Копипаста с Хабр: Крупица истины в безумном заявлении «в России нет и не может быть чипов» и что из нее следует
Тут был диспут пару дней назад на фейсбуке с социологом Алексеем Рощиным, в котором он сделал совершенно безумное заявление "в России нет и не может быть чипов, а если что-то и есть, то оно на два поколения устарело"
Понятно, что в России чипы есть, например микроконтроллер MIK32 АМУР, выпущенный в Зеленограде на основе процессорного ядра от питерской компании Syntacore. Причем если сравнивать Амур с STM32 U0 2024 года (низкопотребляющий микроконтроллер от мирового лидера на 90 нм, 56 MHz), то нельзя сказать что российское "на два поколения устарело"
У микроконтроллеров крутость не в нанометрах (чип на 3 нм все равно не выдержит рядом с горячим автомобильным двигателем), а в системных и микроархитектурных решениях (трюки для экономии динамического энергопотребления, эффективный DMA, даже AI расширения в стиле ARM Ethos-U55)
Учитывая, что Рощин - человек не безумный, я попытался понять, что он имеет в виду, и кажется понял. Мира микроконтроллеров и встроенных процессоров для него не существует (гуманитарии-социологи не задумываются что микроконтроллеры с RTOS ныне есть и в утюгах), а чипы для него - это компьютеры с Windows, которые используют "все"
И вот если смотреть с такой дефиницией, то я с Рощиным совершенно соглашусь. В России нет, не было и никогда не будет конкурентоспособных процессоров архитектуры x86-64 на которых можно нормально (то бишь без медленной симуляции с QEMU и без бинарной трансляции) пускать Microsoft Windows. Неудачные бенчмарки Эльбруса в Сбербанке - это наглядная демонстрация тупиковости такой идеи
Но тут главная фишка не в недостатке экспертизы по проектированию процессоров в России (хотя и в ней тоже), а в том, что паровоз технологии x86-64 вкупе с Windows очень давно ушел. У Windows 30 лет назад, у x86 - 40 лет назад. Хотя x86 немного омолодили в 1990-е годы - за счет внедрения динамического конвейера в PentiumPro в 1996 году и 64-битности от AMD потом
Но попытки повторить все тупиковые решения и недокументированные совместимости, которые скопились в x86 с 1978 года / Intel 8086/8088 (который в свою очередь содержит бессмысленные сейчас совместимости с 8080 от 1974-го года, например H/L регистром) - это даже при наличии идеально подготовленных инженеров означало бы ковыряние тысяч инженеров во всякой ерунде многие годы и все равно бы не привело к успеху. То же самое ядро и приложения Windows
Путь России, Китая и другой зарождающейся мировой альтернативы - это линуксные компьютеры на RISC-V. Там можно легально, конструктивно и эффективно использовать открытые решения со всего мира, на основе которых строить свои
А x86-64 с Windows - это умирающие технологии, несмотря на миллиарды пользователей в мире и несмотря на то, что они умирать будут еще сто лет. Поднимать глаза к потолку что этого у России нет и не будет - это как ругать Нигерию, что та не может скопировать компьютеры на процессоре IBM Z
Не слышали о таком? Это современное продолжение IBM 360, которые СССР скопировал как ЕС ЭВМ в 1960-е годы. Да, оно еще живо!!! Работает в банках, которые не сошли c этого паровоза за 80 лет. Но повторять его не нужно
UPD: Самые дотошные могут спросить "а почему вы не вспоминаете про советские клоны 8086/186/286 на которых можно было запускать MS-DOS?" Я думал всунуть упоминание о них в какой-то форме в свою заметку, но потом решил что эта ветка дискуссии не способствует просветлению (последовательные, не конвейерные, 16-битные, не хочу даже углубляться в protected-mode versus real mode и можно ли было запустить Windows 2.1 aka Windows/286 на малоиспользуемом советском клоне 286-го)
@imaxairu Подписаться
Forwarded from ServerAdmin.ru
Я уже давно использую заметки с канала как свои шпаргалки. Всё полезное из личных заметок перенёс сюда, плюс оформил всё это аккуратно и дополнил. Когда ищу какую-то информацию, в первую очередь иду сюда, ищу по тегам или содержимому.
Обнаружил, что тут нет заметки про tcpdump, хотя личная шпаргалка по этой программе у меня есть. Переношу сюда. По tcpdump можно много всего написать, материала море. Я напишу кратко, только те команды, что использую сам. Их немного. Tcpdump использую редко, если есть острая необходимость.
Я ко всем командам добавляю ключ
📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:
Если запустить программу без ключей, то трафик будет захвачен с первого активного интерфейса из списка выше.
📌 Слушаем все интерфейсы:
Или только конкретный:
📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:
По аналогии исключается любой другой трафик по портам. Если убираем слово not, то слушаем трафик только указанного порта.
📌 Пакеты к определённому адресату или адресатам:
Комбинация порта и адресата:
Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,
📌 Смотрим конкретный протокол или исключаем его и не только:
На этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:
На основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:
Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:
Протокол IP, адрес источника и порт > адрес получателя и его порт.
#network
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
Обнаружил, что тут нет заметки про tcpdump, хотя личная шпаргалка по этой программе у меня есть. Переношу сюда. По tcpdump можно много всего написать, материала море. Я напишу кратко, только те команды, что использую сам. Их немного. Tcpdump использую редко, если есть острая необходимость.
Я ко всем командам добавляю ключ
-nn, чтобы не резолвить IP адреса в домены и не заменять номера портов именем протокола. Мне это мешает. 📌 Список сетевых интерфейсов, с которых tcpdump может смотреть пакеты:
# tcpdump -DЕсли запустить программу без ключей, то трафик будет захвачен с первого активного интерфейса из списка выше.
📌 Слушаем все интерфейсы:
# tcpdump -nn -i anyИли только конкретный:
# tcpdump -nn -i ens3📌 Исключаем SSH протокол. Если в трафике, на который мы смотрим, будет SSH соединение, то оно забивает весь вывод своей активностью. Глазами уже не разобрать. Исключаю его по номеру порта:
# tcpdump -nn -i any port not 22По аналогии исключается любой другой трафик по портам. Если убираем слово not, то слушаем трафик только указанного порта.
📌 Пакеты к определённому адресату или адресатам:
# tcpdump -nn dst 8.8.8.8# tcpdump -nn dst 8.8.8.8 or dst 8.8.4.4Комбинация порта и адресата:
# tcpdump -nn dst 8.8.8.8 and port 53Подобным образом можно комбинировать любые параметры: src, dst, port и т.д. с помощью операторов and, or, not,
📌 Смотрим конкретный протокол или исключаем его и не только:
# tcpdump arp -nn -i any# tcpdump not arp -nn -i any# tcpdump not arp and not icmp -nn -i anyНа этом всё. Лично мне этих команд в повседневной деятельности достаточно. Не припоминаю, чтобы хоть раз использовал что-то ещё. Если надо проанализировать большой список, то просто направляю вывод в файл:
# tcpdump -nn -i any > ~/tcpdump.txtНа основе приведённых выше примеров можно посмотреть, к примеру, на SIP трафик по VPN туннелю от конкретного пользователя к VOIP серверу:
# tcpdump -nn -i tun4 src 10.1.4.23 and dst 10.1.3.205 and port 5060Если не знакомы с tcpdump, рекомендую обязательно познакомиться и научиться пользоваться. Это не трудно, хоть на первый взгляд вывод выглядит жутковато и запутанно. Сильно в нём разбираться чаще всего не нужно, а важно увидеть какие пакеты и куда направляются. Это очень помогает в отладке. Чаще всего достаточно вот этого в выводе:
IP 10.8.2.2.13083 > 10.8.2.3.8118Протокол IP, адрес источника и порт > адрес получателя и его порт.
#network
Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
Forwarded from opennet.ru
Релиз Proxmox VE 8.3, дистрибутива для организации работы виртуальных серверов https://opennet.ru/62273/
www.opennet.ru
Релиз Proxmox VE 8.3, дистрибутива для организации работы виртуальных серверов
Опубликован релиз Proxmox Virtual Environment 8.3, специализированного Linux-дистрибутива на базе Debian GNU/Linux, нацеленного на развертывание и обслуживание виртуальных серверов с использованием LXC и KVM, и способного выступить в роли замены таких продуктов…
Сервис VK Видео теперь доступен на отдельном домене vkvideo.ru.
Forwarded from ServerAdmin.ru
В недавнем цикле статей по LVM в комментариях всплывали вопросы так называемого Bit Rot или битового гниения. Это когда на носитель записан бит 1 или 0, а со временем по разным причинам он поменял своё значение. В конечном счёте эти изменения ведут к тому, что нужный файл хоть и нормально прочитается, но окажется "битым". Причём подвержены этим ошибкам все типы устройств хранения - от лент и CD до современных SSD. Я проверял свои старые записанные CD диски. Многие из них хоть и прочитались, но часть данных была безвозвратно утеряна или повреждена.
Защита от этого явления начинается с того, что данные у вас должны храниться в нескольких экземплярах. Если экземпляр один, то даже если вы узнаете о том, что файл побился, вам это никак не поможет.
Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.
Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.
Важно понимать, что подобный контроль - не бесплатная операция. Она занимает системные ресурсы, как процессора, так и диска. И чем больше нагрузка на диск, тем больше ресурсов нужно. Перечисленные выше ФС обладают не только функциональностью контроля хэшей, но и многими другими, которые не обязательно будут нужны, но ресурсы они потребляют. Плюс, в них могут быть свои ошибки с вероятностью возникновения выше, чем Bit Rot. И стоит не забывать, что даже если вы возьмёте хранилище с ZFS или Ceph с контролем целостности файлов, это не освобождает вас от хранения этих же файлов где-то ещё.
Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.
Таким образом мне не понятны претензии к Mdadm, Lvm или обычным файловым системам типа Ext4 или Xfs. Следить за целостностью файлов - не их задача. Где-то это будет слишком накладно, а где-то вообще не нужно. Если вам это необходимо, возьмите отдельный инструмент. В основном это актуально для долговременных хранилищ с холодными архивами.
☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.
❓Для меня остался открытым другой вопрос. А как вообще понять, что у нас в хранилище файлы исправны, откроются и прочитаются? Как проверить изначальный источник правды для всех остальных копий?
#backup
Защита от этого явления начинается с того, что данные у вас должны храниться в нескольких экземплярах. Если экземпляр один, то даже если вы узнаете о том, что файл побился, вам это никак не поможет.
Проще всего следить за целостностью файлов с помощью подсчёта контрольных сумм по тем или иным алгоритмам (CRC, MD5, SHA1 и т.д.) Есть много бесплатного софта, который автоматически может это выполнять и сравнивать по расписанию. В Linux такой софт обычно используется для контроля за системными файлами, чтобы определять несанкционированное изменение. Пример - Afick, Tripwire. Если у вас лежат файлы, с ними никто не работает, но изменилась контрольная сумма, значит возникли проблемы. Необходимо то же самое проверить на другом хранилище этих же файлов и если там контрольная сумма не менялась, значит тот файл оригинальный и стоит его восстановить из этой копии.
Некоторые файловые системы выполняют такие проверки в автоматическом режиме. Это заложено в их архитектуру. Пример - ZFS, Btrfs, ReiserFS, Ceph. Все эти файловые системы могут не только контролировать изменения, но и выполнять автоматическое восстановление повреждённых файлов, если хранилища на их основе собраны с избыточностью данных. То есть каждый файл хранится как минимум в двух или более копиях, для каждой из которых посчитана и сохранена контрольная сумма.
Важно понимать, что подобный контроль - не бесплатная операция. Она занимает системные ресурсы, как процессора, так и диска. И чем больше нагрузка на диск, тем больше ресурсов нужно. Перечисленные выше ФС обладают не только функциональностью контроля хэшей, но и многими другими, которые не обязательно будут нужны, но ресурсы они потребляют. Плюс, в них могут быть свои ошибки с вероятностью возникновения выше, чем Bit Rot. И стоит не забывать, что даже если вы возьмёте хранилище с ZFS или Ceph с контролем целостности файлов, это не освобождает вас от хранения этих же файлов где-то ещё.
Есть и другой механизм защиты файлов в Linux на основе контроля целостности - DM-integrity. С его помощью можно блочное устройство превратить в устройство с контролем целостности. А дальше с ним можно работать как с обычным диском - создавать разделы, тома Mdadm или Lvm. В случае нарушения целостности файла такое устройство будет возвращать Input/output error. Mdadm или LVM будут пытаться автоматически восстановить файл из копии, если хранилище обладает избыточностью данных, то есть собран рейд соответствующего уровня.
Таким образом мне не понятны претензии к Mdadm, Lvm или обычным файловым системам типа Ext4 или Xfs. Следить за целостностью файлов - не их задача. Где-то это будет слишком накладно, а где-то вообще не нужно. Если вам это необходимо, возьмите отдельный инструмент. В основном это актуально для долговременных хранилищ с холодными архивами.
☝️ Самая надёжная защита от Bit Rot - множественные копии. И тут очень важно соблюдать один принцип. Делать копию надо не от копии, а от оригинала данных. У вас есть исходное хранилище с данными, где они регулярно меняются. С него вы снимаете первый бэкап. Второй бэкап для другого хранилища надо снимать не с первого бэкапа, а тоже с исходного сервера. Иначе вы на все зависимые сервера принесёте битые файлы с первого бэкапа.
❓Для меня остался открытым другой вопрос. А как вообще понять, что у нас в хранилище файлы исправны, откроются и прочитаются? Как проверить изначальный источник правды для всех остальных копий?
#backup
Forwarded from opennet.ru
Состоялась встреча Билла Гейтса, Дэйва Катлера и Линуса Торвальдса https://opennet.ru/63440/
www.opennet.ru
Состоялась встреча Билла Гейтса, Дэйва Катлера и Линуса Торвальдса
Марк Руссинович, автор драйвера NTFS для DOS и технический директор Microsoft Azure, устроил совместный ужин Билла Гейтса, Дэйва Катлера и Линуса Торвальдса. Это была первая встреча Линуса с основателем компании Microsoft и создателем операционных систем…
Forwarded from opennet.ru
В завтрашнем обновлении Windows Server будет нарушена совместимость с Samba https://opennet.ru/63540/
www.opennet.ru
В завтрашнем обновлении Windows Server будет нарушена совместимость с Samba
Сформированы внеплановые обновления Samba 4.22.3 и 4.21.7, решающие проблему с нарушением совместимости серверов Samba с завтрашним обновлением Windows Server. В случае, если не установить предложенные корректирующие обновления, серверы Samba не смогут функционировать…
Компания Keenetic обнаружила волну взломов своих устройств. Расследование показало, что злоумышленники, используя автоматические сканеры, находят роутеры со слабыми паролями и открытым удалённым доступом.
В последние месяцы в Telegram-группе Keenetic участились жалобы пользователей на появление странной учётной записи adminr (мимикрирующей под стандартную admin). На взломанных устройствах злоумышленники поднимают VPN-сервер, что несёт дополнительные риски: в случае совершения противоправных действий через такой VPN, первым под подозрение попадёт владелец устройства.
Опрос пострадавших показал, что они использовали удалённый доступ к устройству и весьма слабые пароли (вплоть доadmin/admin). При этом прошивка не препятствует открытию удалённого доступа со слабым паролем.
В обновлении KeeneticOS 4.3.6.3 эта уязвимость устранена. Открыть публичный доступ к веб-интерфейсу не удастся, пока не будет установлен стойкий пароль.
Кроме того, компания приняла спорное решение запустить процесс обновления всех роутеров, даже тех, у которых автоматическое обновление было отключено в настройках.
Update: спустя некоторое время компания объяснила свои действия:
Для усиления безопасности в целом и обеспечения непрерывной защиты данных пользователей будет проведено обязательное обновление программного обеспечения для устройств, работающих на KeeneticOS версии ниже 4.3, в соответствии со статьей 6 Лицензионного соглашения с конечным пользователем и в соответствии с Законом ЕС о киберустойчивости (CRA). Это обновление включает улучшенные меры безопасности, инструменты для создания более надежных паролей и исправления критических ошибок, которые повышают стабильность системы и защищают учетные записи пользователей.
Мы приносим искренние извинения за неудобства, которые могут быть вызваны этим обновлением. Чтобы свести к минимуму перебои в работе, мы стараемся проводить обновление в нерабочее время.
В последние месяцы в Telegram-группе Keenetic участились жалобы пользователей на появление странной учётной записи adminr (мимикрирующей под стандартную admin). На взломанных устройствах злоумышленники поднимают VPN-сервер, что несёт дополнительные риски: в случае совершения противоправных действий через такой VPN, первым под подозрение попадёт владелец устройства.
Опрос пострадавших показал, что они использовали удалённый доступ к устройству и весьма слабые пароли (вплоть доadmin/admin). При этом прошивка не препятствует открытию удалённого доступа со слабым паролем.
В обновлении KeeneticOS 4.3.6.3 эта уязвимость устранена. Открыть публичный доступ к веб-интерфейсу не удастся, пока не будет установлен стойкий пароль.
Кроме того, компания приняла спорное решение запустить процесс обновления всех роутеров, даже тех, у которых автоматическое обновление было отключено в настройках.
Update: спустя некоторое время компания объяснила свои действия:
Для усиления безопасности в целом и обеспечения непрерывной защиты данных пользователей будет проведено обязательное обновление программного обеспечения для устройств, работающих на KeeneticOS версии ниже 4.3, в соответствии со статьей 6 Лицензионного соглашения с конечным пользователем и в соответствии с Законом ЕС о киберустойчивости (CRA). Это обновление включает улучшенные меры безопасности, инструменты для создания более надежных паролей и исправления критических ошибок, которые повышают стабильность системы и защищают учетные записи пользователей.
Мы приносим искренние извинения за неудобства, которые могут быть вызваны этим обновлением. Чтобы свести к минимуму перебои в работе, мы стараемся проводить обновление в нерабочее время.