• Немного статистики: по данным statcounter процент использования Linux и MacOS на десктопах летит в космос!

• Если месяц назад процент использования Linux составлял 7.53%, то сейчас он вырос до 8.88%. Такой показатель был достигнут впервые!

• MacOS также фиксирует рекорд - доля использования составляет 15.31%. В прошлом месяце этот показатель был на уровне 7.61%.

• А вот у окошек случился отрицательный рост - начиная с июля процент использования упал с 71.18% до 62.67%. Такого еще не было.

• К слову, в России ситуация с окошками аналогичная - в июле процент использования был на уровне 91.12%, а сейчас он составляет 76.13%.

➡ Статистика по миру.
➡ Статистика по РФ.

#Статистика #Linux

• Доброе утро 🫠

#Понедельник

🤭 Инженер Google Cloud устроил сбой, случайно отключив от сети оборудование, которое обслуживал - об этом инциденте написали в блоге Google Cloud.

• Проблему зафиксировали в 07:41 по тихоокеанскому времени. В разгар инцидента объем трафика в пострадавшей области упал на 100%, виртуальные машины были недоступны. Сбой повлиял на работу Compute Engine, Kubernetes Engine, Cloud Run / Google App Engine, AlloyDB для PostgreSQL, Google Cloud Bigtable, BigQuery, Google SecOps SOAR и множества других сервисов.

• Их работу удалось восстановить только через 4 часа, в 11:52. Как объяснили в компании, причиной стало отключение оптоволоконных кабелей: инженер последовательно отключил все кабели в течение 13 минут, по всей видимости, невнимательно прочитав инструкцию.

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

➡️ https://status.cloud.google.com/incidents/J5ia5t9p3g9Q5Wi7r8Ev

#Новости

📺 "Умные" телевизоры LG записывают ваши разговоры и сканируют локальные сети.

• Gamers Nexus совместно с Level1Techs выкатили расследование о телевизорах LG Smart TV. По их данным, протестированные модели записывают звук при выключенном экране, хранят записи локально и отправляют их на серверы при первом появлении устройства в сети. А еще "умные" телевизоры сканируют локальную сеть и осуществляют поиск других устройств: телефоны, ПК, принтеры, гаджеты и элементы умного дома. Кроме того, они собирают сведения о соседних Wi-Fi-сетях, включая названия сетей и уровень сигнала.

• Также исследователи написали в LG о том, что нашли уязвимость в webOS, которая позволяет выполнить произвольный код на устройстве, что может помочь атакующему получить не только контроль над ТВ, но и над другими устройствами в домашней сети.

• Масштаб проблемы: по всему миру эксплуатируется около 216 млн. умных телевизоров LG. Если учитывать другие устройства, которые телевизоры сканируют в локальных сетях, компания LG фактически имеет доступ к примерно 363 млн устройств только в США.

➡️ Исследование было опубликовано на YT и за 1 день его посмотрели более 1.8 млн. человек: https://youtu.be/6IFVTcM28KA

• Авторы исследования рекомендуют отключать телевизоры LG от сети и использовать для онлайн-сервисов отдельные устройства. Сама компания LG на публикацию пока никак не отреагировала.

#Новости #Security #Исследование

• Когда вы вводите в браузере имя сервера или доменное имя сайта, выполняете ping или запускаете любое удаленное приложение, операционка должна преобразовать указанные имена в IP-адреса. Этот процесс называется разрешением доменного имени. На первый взгляд он может показаться весьма прозрачным, однако за ним скрывается многослойный механизм.

• По ссылкам ниже можно найти 4 крутых лонгрида, которые описывают работу DNS в Linux:

➡Часть 1: от getaddrinfo до resolv.conf - статья посвящена низкоуровневой архитектуре разрешения имен. Поговорим о том, как устроен этот процесс в Linux на уровне ядра, различных библиотек C и системных вызовов.

➡Часть 2: все уровни DNS-кэширования - во второй части описано общее представление того, как устроено кэширование DNS записей - ключевой механизм, который напрямую влияет на производительность, надежность и поведение приложений при смене IP-адресов.

➡Часть 3: Разбираемся с resolv.conf, systemd-resolved, NetworkManager и другими - разберем, как взаимодействуют различные резолверы (glibc, systemd-resolved, dnsmasq, NetworkManager), что происходит, когда /etc/resolv.conf указывает на 127.0.0.53, и как понять, кто реально управляет вашим DNS в системе.

➡Часть 4: DNS в контейнерах - каждая контейнерная платформа - Docker, Podman, Kubernetes - реализует собственную DNS-архитектуру со специфическими особенностями, преимуществами и подводными камнями. Понимание этих различий критически важно для построения надежных и производительных контейнерных инфраструктур. С чем мы и попробуем разобраться в этой статье.

#DNS #Linux

• Хороший лонгрид про анализ Wi-Fi трафика опубликован на хабре. Тут очень много полезной информации, включая описание стандартов, инструментов для анализа трафика, ну и сам разбор работы Wi-Fi на канальном уровне.

➡️ https://habr.com/ru/post/1077474

• Дополнительно ⬇

➡Как выглядит современный Wi-Fi и что влияет на его безопасность [Часть 1], [Часть 2] - вы узнаете, как атакуют современный Wi-Fi и какие эффективные методы необходимо использовать для защиты беспроводных сетей.
➡Большой FAQ про Wi-Fi: хороший чек-лист, который содержит ответы на всевозможные вопросы, которые так или иначе связанны с Wi-Fi. Автор на протяжении 20 лет занимается беспроводными технологиями и начал вести данный список еще в самом начале своей карьеры.
➡Анализ безопасности Wi-Fi: подробное исследование методологии взлома протоколов WPA2-Personal / Enterprise и WPA3 (какие атаки и уязвимости существуют, и какой инструментарий применяется для их эксплуатации).
➡Пентест Wi-Fi: полезный чек-лист, который содержит актуальные советы и хитрости на тему пентеста Wi-Fi сетей.
➡Инструменты для пентеста Wi-Fi: продолжение поста выше, статья включает в себя максимально полный список инструментов для анализа защищенности Wi-Fi.
➡Useful Wireless Links: учебные пособия, справочники, калькуляторы, софт, гаджеты и многое другое.

#WiFi

🇯🇵 Япония пыталась создать операционную систему для всего мира, но затем вмешалось правительство США.

• В 1984 году исследователь Токийского университета Кен Сакамура запустил проект TRON (The Real‑time Operating system Nucleus) - инициативу по созданию семейства операционных систем реального времени с открытым исходным кодом ядра. Подпроект BTRON был упомянут в отчете США о торговых барьерах и фактически закрыт, прежде чем смог попасть в школы по всей Японии. Одновременно с этим подпроект ITRON стал одной из самых распространенных ОС в истории.

• Сакамура хотел создать вертикально интегрированную вычислительную архитектуру, на которой Япония могла бы построить всю свою цифровую инфраструктуру: от микроконтроллера в стиральной машине до рабочей станции. Проект TRON включал пять подархитектур: ITRON для встроенных систем реального времени, BTRON для ПК, CTRON для мэйнфреймов и телекоммуникационных коммутаторов, MTRON для межсистемной координации и аппаратная реализация ядра реального времени STRON.

• В рамках проекта разработали собственную процессорную архитектуру — TRON VLSI, которую Hitachi задействовала для серии чипов Gmicro/200. Эти процессоры использовали некоторые японские рабочие станции и встроенные системы.

• Также команда Сакамуры разработала свою раскладку клавиатуры TRON, предназначенную для эффективного ввода японского текста с символами программирования. Кроме того, исследователи Токийского университета создали шину для периферийных устройств реального времени под названием micro‑BTRON, основанную на стандарте IEEE 802.5 и предназначавшуюся в качестве альтернативы MIDI для подключения периферийных устройств. Однако шина так и не была включена в коммерческий продукт.

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

• В 1986 году создали TRON Association, в которую вошли Hitachi, Mitsubishi, Fujitsu, NEC, Matsushita, Toshiba и другие крупные японские компании. Также к проекту присоединились некоторые иностранные компании. TRON распространялся без лицензионных отчислений, а его спецификации были открытыми, что обеспечило широкое проникновение ITRON. Правительство Японии поддержало проект в рамках национальной технологической стратегии.

• Основная идея BTRON заключалась в том, что базовым объектом, с которым пользователь работает на ПК, должны быть не файл и не приложение, а типизированная часть документа (document part). Это был блок содержимого с постоянным идентификатором и объявленным типом. Такие части могли содержать другие части, и те же механизмы, которые позволяли встроить рисунок в отчет или использоваться для встраивания самого отчета в рабочее пространство. В таком случае для документа верхнего уровня не требовалось создавать какой‑то особый тип файла. Эта модель встречалась во всем интерфейсе.

• BTRON также использовала модель файловой системы под названием real‑body/pseudo‑body, которая заменила древовидную иерархию каталогов произвольным ориентированным графом. Один и тот же файл мог находиться сразу в нескольких местах без дублирования данных: связи между ним и этими местами хранились самой системой, а не в виде символических ссылок или ярлыков. Формат TRON Application Databus передает структурированные данные между приложениями, используя сегментную структуру с общим заголовком. Ячейка электронной таблицы и абзац текста могут быть объединены в один документ, поэтому пользователю не нужно задумываться о форматах файлов.

• Приложения могли игнорировать неподдерживаемые типы данных, что делало совместимость ключевым аспектом системы.

• BTRON была доступна в ограниченном количестве японских продуктов, например, в КПК BrainPad Tipo от Seiko Instruments.

• Весной 1989 года Торговое представительство США посвятило TRON раздел отчета о торговых барьерах. Американские власти были обеспокоены влиянием японского правительства на рынок с целью поддержки TRON. В отчете были указаны два рынка, на которых TRON получал преимущества благодаря государственной поддержке.

• Первый - индустрия образовательных ПК. Министерство образования Японии и Министерство международной торговли и промышленности Японии разрабатывали стандартную спецификацию для компьютеров, внедряемых в средние школы по всей стране. Спецификация строилась на основе TRON. Второй - цифровая коммуникационная сеть следующего поколения компании NTT, которая планировала использовать CTRON. Хотя несколько американских компаний были членами TRON Association, ни одна из них не имела возможности продавать продукцию на базе TRON ни на одном из этих рынков.

• TRON Association направила письменный протест американскому правительству, и США организовали инспекционную группу для расследования. По словам Сакамуры, вопрос был закрыт, когда представитель США по торговым вопросам заявил, что расследование не выявило угрозы со стороны BTRON. Американская сторона принесла извинения за неудобства. Однако к июню 1989 года программа по внедрению TRON в японские школы уже была прекращена.

• Японские производители сочли спор как сигнал о том, что TRON вызвала недовольство правительства США, поэтому сохранение связи с проектом могло угрожать бизнесу японских компаний в Америке. Последние массово отказались от разработки ПК на базе TRON.

• Если BTRON свернули, то ITRON продолжала распространяться по миру. ITRON, а позже T‑Kernel, использовались в цифровых фотоаппаратах, блоках управления двигателями автомобилей, мобильных телефонах, оборудовании для автоматизации производства и бытовой технике. В конце 1990-х годов TRON даже получила собственную спецификацию Java, которая объединила ядро реального времени ITRON со средой выполнения Java от Sun.

➡ Источники [1],[2].

#Разное

• Еще одна история - 31 января 2017 года инженер GitLab, чиня реплику PostgreSQL, выполнил rm -rf каталога данных не на вторичном сервере, а на основном (классика). Команду остановили через пару секунд, но из 300 ГБ осталось только 4,5 ГБ. А вот дальше началось самое интересное...

• Дампы pg_dump создавались бинарниками версии 9.2 против PostgreSQL 9.6, из-за несовпадения major-версий завершались ошибкой, свежих дампов в S3 не было, а письма об ошибках отклонялись из-за DMARC. GitLab спас ручной LVM-снапшот, сделанный за шесть часов до инцидента для совершенно другой задачи. Однако были потеряны данные, созданные между 17:20 и 00:00 UTC, а это как минимум 5 тыс. проектов, 5 тыс. комментариев и около 700 пользователей.

➡ https://about.gitlab.com/blog/postmortem-of-database-outage

• А когда вы в последний раз проверяли свои бэкапы?

#Разное