Креативный админ 🎹

Типичный 🥸 Сисадмин

Коллега поделился по-настоящему странной проблемой, с которой столкнулся после обновления нескольких виртуальных машин Ubuntu Server. Эта история – отличный пример того, какими непредсказуемыми могут быть трудовые будни, и как важно иногда просто сравнить конфиги.

Началось все с рутинной задачи: обновления старых Ubuntu серверов. Два из них, работавшие на версии 18.04, потребовали двух последовательных циклов do-release-upgrade. Однако после второго апгрейда, до версии 22.04, обе эти виртуальные машины наотрез отказались нормально загружаться, просто зависая на старте. Логи намекали на проблемы с монтированием корневого раздела /dev/vda1.

Самое мистическое в этой ситуации было то, что если загрузиться в консоль восстановления, а затем выбрать опцию "продолжить обычную загрузку", система волшебным образом стартовала и работала как ни в чем не бывало. Две из двадцати виртуальных машин демонстрировали идентичное поведение, что добавляло загадочности. Админ перепробовал многое: проверил конфигурации, вручную обновил тип виртуальной машины, пересобрал initramfs, обновил GRUB – но ничего не помогало, кроме этого странного обходного пути через rescue-консоль. Подозрение падало на конфигурацию самой ВМ, так как даже live-образ Ubuntu 22.04 на этих машинах загружался с трудом.

В ходе поисков решения были отброшены различные гипотезы: нехватка места на /boot, проблемы с fstab или udev (хотя и пробовались разные варианты монтирования), ошибки файловой системы. Kernel panic при обычной загрузке указывал на невозможность найти корневой раздел, который, тем не менее, прекрасно находился при старте через rescue-режим.

Разгадка пришла, когда автор сделал то, что, по его собственному признанию, "нужно было сделать еще прошлой ночью": он сравнил (diff) XML-файл конфигурации проблемной виртуальной машины (/etc/libvirt/qemu/server.xml) с аналогичным файлом работающей ВМ. И вот оно! В секции <video> у проблемных машин был указан тип модели vmvga. Простое изменение `vmvga` на `qxl` немедленно решило проблему! Виртуальные машины стали загружаться штатно.

Как именно конфигурация виртуальной видеокарты могла повлиять на доступ к диску при загрузке – остается небольшой загадкой, но это яркий пример того, что при крупных обновлениях операционных систем могут меняться поддержка или поведение различных моделей виртуального оборудования. Старые конфигурации виртуальных машин не всегда переносятся без сюрпризов.

Linux / Линукс 🥸

Исследователи из Akamai нашли способ вырубать криптомайнерские ботнеты, не трогая легитимные пулы. В отчёте описаны две техники, которые используют особенности протокола Stratum и политики самих пулов. Всё сводится к тому, чтобы валить прокси или кошелёк злоумышленника через фродовые действия, имитируя поведение майнера.

Первая методика — "bad shares". Она работает, если у атакующего используется прокси-сервер между ботами и пулом. Исследователи подключаются к этому прокси как будто обычные майнеры и начинают слать плохие шары (некорректные результаты). Прокси не валидирует их как надо и пробрасывает в пул. В ответ пул банит прокси, и вся ботнет-сеть идёт на паузу — загрузка CPU у жертвы падает с 100% до нуля.

Вторая техника нацелена на ситуации, когда майнер напрямую подключён к публичному пулу без прокси. Если кошелёк связан более чем с 1000 активных воркеров, пул может временно заблокировать его. Akamai использовали инструмент, который запускает более 1000 соединений с одним и тем же кошельком. В результате — часовой бан кошелька, остановка добычи. Правда, тут всё откатывается, как только атака прекращается.

Для этого Akamai разработали собственный тул XMRogue, который маскируется под легитимного майнера, шлёт плохие шары и сносит прокси или кошелёк с пула. Всё это уже протестировано на Monero, но подход можно адаптировать и под другие коины.

Легитимный майнер поправит кошелёк и IP за пару минут. А вот ботнету с десятками тысяч узлов придётся делать рефакторинг всей архитектуры. И как показывает практика, у дешёвых криптоопераций на это просто нет рук.

Типичный 😎 Сисадмин

🔍 США может закрутить гайки TSMC, Samsung и Hynix в Китае

США рассматривают вариант отзыва спецразрешений на поставки технологий и оборудования для заводов TSMC, Samsung и SK Hynix в КНР. Если статус Validated End User (VEU) аннулируют, производителям чипов придётся пробираться к американскому «железу» через бюрократические дебри.

Речь идёт об оборудовании, необходимом для выпуска полупроводников — от смартфонов до серверов. Рынок уже отреагировал: поставщики техники в минусе, а акции Micron (прямой конкурент) — в плюсе.

Сами производители пока молчат. А власти США называют это «подготовкой на случай провала торгового соглашения» и обещают больше контроля ради «равных условий». Поставки редкоземельных из Китая тоже под вопросом — без них полупроводниковая отрасль не поедет.

Типичный 🥸 Сисадмин

Когда разраб спрашивает, почему его контейнер не стартует. Даю ему шанс почитать логи 😬

Типичный 🌚 Сисадмин

🎹 Хакеры эксплуатируют неправильно настроенные Docker API, чтобы майнить криптовалюту через Tor. В атаке задействованы открытые Docker-инстансы, к которым можно подключиться извне. Первая стадия — получение списка контейнеров с IP 198.199.72[.]27. Если контейнеров нет, создаётся новый на базе alpine, а внутрь монтируется /hostroot, то есть корень хост-системы. Это даёт злоумышленнику возможность модифицировать файлы на хосте и выйти за пределы контейнера.

Внутри нового контейнера запускается Base64-зашифрованный скрипт, который ставит Tor и тянет дальнейшие инструкции с onion-домена. Весь трафик, включая DNS-запросы, уходит через socks5h, что затрудняет отслеживание и блокировку C&C-инфраструктуры. После разворачивания запускается docker-init.sh, который проверяет наличие примонтированного /hostroot, настраивает удалённый доступ по SSH с root-правами и добавляет ключ злоумышленника в ~/.ssh/authorized_keys.

Дальше ставятся masscan, libpcap, zstd, torsocks и отправляется информация о системе на C&C. В завершение загружается бинарник-дроппер, который запускает XMRig с готовой конфигурацией, кошельком и пулом.

Атаки нацелены на компании в сфере технологий, финансов и здравоохранения. Это продолжение общей тенденции — использовать дыры в облачной инфраструктуре для криптоджекинга. Параллельно с этим, исследователи из Wiz нашли сотни валидных секретов в .env, mcp.json, AI-конфигах и ноутбуках Jupyter, включая данные от Fortune 100 компаний. Всё это превращается в подарок для атакующих — особенно если ноутбук содержит результаты кода, связанные с конкретной организацией.

Контейнер с Tor и майнером? Ну хоть не WordPress с phpMyAdmin — уже прогресс 🎩

Типичный 🥸 Сисадмин

Почему люди ждут бесплатной IT-помощи? 😩

Коллега поднял наболевшую тему о том, почему многие ожидают от IT-специалистов бесплатной помощи так, будто это само собой разумеющееся?

Да и айтишники в этой беде не одиноки. Действительно, механики, врачи (особенно стоматологи, урологи и ветеринары), юристы и даже историки регулярно сталкиваются с просьбами быстренько помочь или просто посоветовать в нерабочее время и бесплатно.

Многие айтишники нашли спасение в священном бартере – обмене услугами с друзьями и знакомыми других профессий (сосед – механик, я ему с компьютерами, он мне с машиной – идеально!). Такой подход работает, когда обе стороны ценят навыки друг друга и готовы к взаимовыгодному сотрудничеству.

Чтобы отбиться от назойливых просьб, бывалые выработали целый арсенал отмазок. Я встречал такой топ: "Извини, я работаю с серверным оборудованием в дата-центрах, про домашний Windows/MacOS я мало что знаю" (классика, даже если это не совсем правда), "Я специализируюсь на бэкенд-коде, а не на пользовательской стороне" или "Моя экспертиза – хранилища данных на сотни дисков, для домашнего ПК могу лишь посоветовать купить M2 SSD". Ну и конечно, фраза "Мой час стоит 5к, минимальный заказ – 2 часа. Какая у вас проблема?" часто действует отрезвляюще.

Со временем многие приходят к необходимости устанавливать четкие границы и учиться говорить "нет". Особенно утомляют просьбы от дальних знакомых или ситуации, когда родственники дарят твои профессиональные услуги своим друзьям без твоего ведома. Защита личного времени становится приоритетом для тех, кто и так почти 24/7 на связи по рабочим вопросам.

Однако не все так категорично. Помогать друзьям и близким – это нормально, ведь в этом и заключается дружба. "Я спрашиваю друзей-финансистов про инвестиции и проценты, они меня – про IT. Ключевое здесь – взаимность и разумные пределы. Одно дело – ответить на вопрос или дать совет, и совсем другое – выполнять полноценную работу бесплатно, особенно если это занимает много времени.

Но в конечном счете проблема не столько в специфике IT, сколько в людях и их желании получить что-то бесплатно, особенно если это касается нематериального интеллектуального труда. Важно ценить свой труд и время, уметь устанавливать границы, развивать взаимовыгодный бартер и помнить, что вы не обязаны быть круглосуточной бесплатной техподдержкой для всего мира.

А как вы справляетесь с такими просьбами? 👇

IT-Мемасы от Эникея 🫡

🎭 История о утечке 16 миллиардов паролей — это не про кибератаку. Это 100% спектакль на который повелись.

Всё началось с материала на Cybernews: мол, крупнейшая в истории база с паролями, 16 миллиардов строк, взлом гигантов вроде Google и Apple. Мгновенно подхватили медиа, в LinkdIn полетели экспертные комментарии, а отдельные вендоры уже готовили лендинги под SEO. Вот только проблема — никаких подтверждений нет. Скриншоты — аж три ШТУКИ. Исходников нет. Фидов нет. Верификации — ноль. Сам исследователь (Bob Diachenko) признал, что это просто подборка старых дампов, собранных за несколько лет.

Многие эксперты из Sophos, Rapid7 и Recorded Future сходятся во мнении, что это, скорее всего, агрегация старых, давно известных дампов с добавлением небольшого количества новых данных. Сам Дьяченко позже признал, что данные представляют собой кумулятивные записи, обнаруженные с начала года, а не результат единичной мега-утечки. Никаких сырых файлов или верифицированных фидов для независимого анализа предоставлено не было, что заставило SANS Institute заявить: "это не проходит проверку на вшивость".

Даже если сама история липа, урок очевиден: инфостилеры воруют миллиарды учёток ежегодно. В 2024 году они слили 2,1 млрд паролей — это две трети всех украденных данных. Всё ещё используешь один пароль и без MFA? 🎩

Разумные головы призывают к умеренности. Хайп мешает обсуждению реальных угроз. “Кричать волки!” в третий раз — плохая идея. Становится сложно донести, где реально беда, а где очередной повод для хайпа.

В итоге остались: три скрина, ноль доказательств, куча комментариев и мем про "Журналисты и СМИ на это набросились, как изголодавшийся пёс на кибер-буккаке-вечеринке". Комментаторы как всегда — культурно, по делу 🐶

Кстати, да. MFA включить. И парольник настроить. Это не хайп — это базовая гигиена. Хотя старый пароль никогда не подводит. Он просто уходит к следующему владельцу 😬

Типичный 🥸 Сисадмин

И да, Google уже официально заявил, что никакой утечки с их стороны не было. Представитель компании сообщил CyberScoop, что данные не связаны с каким-либо взломом инфраструктуры Google. То есть упоминание Google в этой утечке 16 миллиардов паролей — просто вброс.

A Google spokesperson told CyberScoop the issue did not stem from a data breach.

Apple, к слову, вообще не ответила на запрос.

Так что на сегодня из доказательств всего три скрина.

Типичный 🥸 Сисадмин

🙄 Microsoft сообщила о новых проблемах, которые мешают нормальной работе браузера Chrome в Windows

Обе неполадки связаны с функцией родительского контроля Family Safety, предназначенной для создания безопасной среды в интернете для детей.

Оказалось, что Family Safety не всегда корректно блокирует Chrome. Система использует чёрный список браузеров, куда вносятся конкретные версии программ. Однако Microsoft признала, что последние версии Chrome и некоторых других браузеров не были добавлены в этот список, из-за чего дети могли обходить ограничения. Сейчас компания обновляет перечень блокируемых приложений.

Кроме того, пользователи столкнулись с зависанием Chrome на компьютерах с включённым Family Safety. Вместо стандартного уведомления с запросом разрешения на запуск браузер просто перестаёт отвечать. Microsoft выяснила, что проблема возникает, если в настройках Family Safety отключены отчёты о действиях. Временно решить её можно, включив эту функцию, но компания ищет более надёжное решение.

Типичный 🥸 Сисадмин

Так выглядит фуллстек-админ 😬

Типичный 🥸 Сисадмин

Типичный 😎 Сисадмин

Прекрасный день, чтобы заруинить инфраструктуру 😎

Типичный 🥸 Сисадмин

Ностальгия...

«Скоро должно закончиться, прогрессбар достигает 99%»... как вдруг электричество отключается 😬

Типичный 🥸 Сисадмин

Пользователь сделал для защиты дома от "электромагнитных импульсов" ⚡️

Типичный 🏥 Сисадмин

Юбилейный Баг MySQL отмечает 20 Лет 🎉

Знаменитому багу в MySQL (номер 11472, "Triggers not executed following foreign key updates/deletes\Триггеры не срабатывают при каскадных операциях по внешнему ключу") исполнилось 20 лет! Зарегистрированный в июне 2005 с серьезностью S2 (Serious), он до сих пор радует разработчиков. Суть в том, что при каскадном обновлении/удалении данных триггеры на связанных таблицах не выполняются, что может нарушать целостность данных (ACID).

Команда MySQL обещала исправить это еще в версии 5.1, но вместо этого просто задокументировала как особенность: "cascaded foreign key actions do not activate triggers". Комментарии к багу полны боли и иронии ("этот баг старше меня", "для нас это стало последней каплей"). Примечательно, что и в MariaDB он не решен. Кто-то винит Oracle в недостаточном внимании, кто-то считает, что лучше не трогать, чтобы не сломать что-то еще 😏

Рейтинг DB-Engines подтверждает снижение популярности MySQL и рост PostgreSQL.

```
Каждый раз, когда кто-то натыкается на этот баг в MySQL, где-то в мире один PostgreSQL-админ загадочно улыбается 😊

Типичный 🥸 Сисадмин