Hacker News Digest

Yandex Cloud столкнулся с масштабным сбоем, начавшимся 11 октября в 1:00 по GMT и продолжавшимся до момента публикации обновления 12 октября в 16:16 GMT. Платформа работала в ограниченном режиме, а затем перешла в режим чрезвычайной ситуации, что повлияло на доступность практически всех ключевых сервисов: Compute Cloud, VPC, Object Storage, IAM, Managed Service for Kubernetes, Monitoring, базы данных (PostgreSQL, ClickHouse, MySQL, Valkey, YDB), сетевые сервисы (Network и Application Load Balancer, Cloud Interconnect, Cloud DNS), инструменты разработки (Cloud Functions, API Gateway, Cloud Desktop, Managed Service for GitLab, SourceCraft), ИИ и аналитика (YandexGPT API, Yandex Query, Yandex AI Studio, Yandex MPP Analytics Engine), а также вспомогательные системы (Cloud Logging, Audit Trails, SmartCaptcha, Cloud Backup, Yandex Cloud Console, Yandex Cloud Billing, Yandex Cloud Router, Yandex Cloud Quota Manager и многие другие). Техническая поддержка работала в усиленном режиме, но время ответа увеличивалось из-за высокой нагрузки.

Компания рекомендовала пользователям использовать альтернативные площадки для хостинга и резервирования ресурсов, а также рассматривать другие платформы для быстрого развертывания и обеспечения избыточности. Квоты на дополнительные ресурсы оставались приостановленными. Обновления публиковались несколько раз в день: сначала планировались на 11 октября в 18:00 и 19:00 МСК, затем на 12 октября в 11:00 и 19:00 МСК, а следующее — на 13 октября в 11:00 МСК. Восстановление шло круглосуточно, но полное возвращение к нормальной работе заняло значительное время из-за масштаба инцидента.

Атака на дата‐центр Yandex Cloud вызвала масштабные перебои в российских сервисах: пользователи не могли вызвать такси, заказать еду, а POS‐системы в розничных сетях перестали работать. Yandex получил положительные отзывы за прозрачную коммуникацию через статус‐страницу и своевременные обновления. Атаки на дата‐центры становятся частью военных действий: в сентябре Россия подверглась более чем 10 ударам по украинским телеком‐центрам, теперь Украина отвечает ударами по российским дата‐центрам. Это подчёркивает рост дата‐центров как целей в современных конфликтах и глобальную уязвимость крупных облачных провайдеров — аналогичные инциденты отмечались с AWS на Ближнем Востоке. Потеря инфраструктуры и талантов в России ускоряется: ИТ‐отрасль теряет как специалистов, так и физические объекты, что может ослабить её конкурентоспособность и отразиться на экономике на месяцы при выводе из строя трёх стратегических дата‐центров. В ответ на уязвимость крупных объектов обсуждается переход к децентрализации: рост сетей небольших дата‐центров и распределённых систем, а также вопросы о размещении инфраструктуры под землёй или в защищённых местах. Технический интерес к мониторингу демонстрирует ссылка на график соединения AS200350 (YandexCloud), показывающий деградацию сети в реальном времени.

Tailscale ускоряется за счёт снижения памяти и улучшения обработки пакетов. На Linux и Android теперь не копируются маленькие пакеты (например, 1 KiB) в отдельные 64 KiB буферы — вместо этого они остаются в едином буфере, где их границы помечаются, что экономит память и ускоряет обработку на ~5%. Одновременно сокращены длины очередей пакетов, что уменьшает задержки и освобождает память без потери устойчивости к всплескам трафика. Эти изменения уже частично реализованы и войдут в стабильный релиз v1.104 клиента.

Параллельно разрабатывается мульти-очередная технология для повышения пропускной способности в сценариях с подсетями, коннекторами приложений и выходными узлами — её выпуск запланирован после v1.104. Также тестируется кэширование netmap как флаг функции, которое станет стандартным в v1.104 для десктопов и позже для мобильных клиентов. Чтобы пользователи могли объективно оценивать производительность, Tailscale разрабатывает собственный набор инструментов для мониторинга и тестирования, который будет понимать специфику его сети: distinguish между DERP и прямыми соединениями, оценивать пользу пир-релеев и отслеживать динамику маршрутов — чего не умеют общие утилиты из-за привязки к точкам, жёсткости workflows и отсутствия поддержки QUIC/HTTP/3. Пользователей приглашают повлиять на развитие этого инструментария через опрос.

Tailscale проще в настройке, чем raw WireGuard: автоматизирует NAT-трансверс, DNS и управление ключами, что делает его удобным для не-технических пользователей и динамических сред (CI-джобы). Пользователи отмечают, что он позволяет подключаться к серверам без открытия портов, упрощая безопасный доступ к внутренним сервисам. Однако Tailscale критикуют за производительность на высоких нагрузках и высокое потребление батареи на iOS, что ограничивает его практическое применение. На Windows и macOS скорость не превышает 1 Гбит/с, на Linux — до 10 Гбит/с даже в синтетических тестах, что делает его неконкурентоспособным для высокопроизводительных сценариев. Потребление батареи на iOS вынуждает пользователей вручную управлять подключением, нивелируя преимущества автоматизации. Спор о скорости: некоторые утверждают, что raw WireGuard быстрее и стабильнее, особенно с динамическим DNS; другие отмечают, что Tailscale решает проблемы с забыванием конфигурации и сложностью поддержки после простоя. Также обсуждается отсутствие аппаратного ускорения криптографии в Tailscale, что ограничивает масштабируемость до сотен Гбит/с и может потребовать смены протокола (например, на IPsec с PQ). Однако ChaCha20-Poly1305 в WireGuard уже быстр и может быть оптимизирован через SIMD, что снижает необходимость в аппаратном ускорении. Дополнительные ограничения: Tailscale не поддерживает мультиузловые прокси, требуя отдельных контейнеров для устройств без прямой интеграции; не работает на микроконтроллерах, хотя это было бы идеально для IoT; не позволяет отключать принудительное исключение Android-приложений из VPN без вмешательства разработчика, что противоречит пользовательскому контролю. Предлагается добавить гибкость в выбор маршрутов через DERP (a→b→c) для снижения задержек при невозможности прямого соединения. На Linux и Android оптимизации (устранение копирования малых пакетов, сокращение очередей) дают ~5% прироста производительности, но не применимы на macOS и Windows из-за отсутствия ядерных аналогов. Tailscale уже давно отошёл от спецификации WireGuard, внося собственные улучшения, но создавая разрыв в ожиданиях совместимости. Использование батарейных устройств как exit-узлов неэффективно и противоречит рекомендациям по энергосбережению.

GLM 5.3-flash — это открытая, быстрая и дешёвая модель ИИ, которую можно запустить на обычном оборудовании за 5–15 тыс. долларов, а с оптимизациями — даже на будущем M5 Mac Studio за 9,5 тыс. долларов. Её ключевая опасность: после удаления механизмов отказа (abliteration) модель готова выполнять любые вредоносные задачи — от взлома инфраструктуры до инструкций по созданию взрывных устройств — без ограничений. Это делает её доступным инструментом для кибератак в руках любого, кто скачает её с Hugging Face.

Угроза реальна: проекты вроде Glasswing и Daybreak пытаются использовать передовой ИИ для поиска и исправления уязвимостей в масштабах всей индустрии, но время ограничено — защита должна опережать атаку. Автор призывает к немедленным действиям: ускорить патчинг, сократить embargo-периоды, инвестировать в безопасность цепочек поставок, аудит зависимостей, защиту в глубине (сегментация сети, резервные копии, учения по реагированию) и постоянный мониторинг развития открытых моделей. Даже если угроза кажется преувеличенной, это шанс поднять уровень безопасности на unprecedented уровень — и им нужно воспользоваться, пока есть время.

Угроза от LLM — не в новизне информации, а в снижении порога доступа к вредоносным инструкциям и ускорении эксплуатации уязвимостей, что делает текущие меры безопасности устаревшими. Время на защиту сократилось до менее чем года — атаки ведутся на GPU-кластерах, а не на локальных машинах. Упростите стек: используйте минимально необходимые компоненты. WordPress безопасен, но плагины и темы — основной источник уязвимостей, как и любые сложные зависимости. Откажитесь от C/C++ для нового кода — Rust и Go исключают буферные переполнения, снижая атакуемость на порядок. Перейдите на микроядерные ОС: Linux и Windows не выдержат атак с LLM из-за бесконечных патчей и устаревшего оборудования. Применяйте избыточные контрольные механизмы: WAF, мониторинг приложений, резервные копии — это база, а не опция. Инвестируйте в формальную верификацию, фаззинг и memory-safe языки: LLM уже генерируют Lean-доказательства и fuzz-тесты, но критические баги в веб-браузерах и приложениях остаются вне зоны формальной проверки. Системы AuthN/AuthZ — самая уязвимая часть, которую игнорируют, хотя именно они становятся точкой входа при автоматизированных атаках. Не открывайте SSH и не отвечайте на ping — продакшн-машины должны быть невидимы в сети; доступ — только через knock-порты или полное отсутствие удалённого входа. Проблема не в LLM, а в том, что 95% разработчиков не умеют писать безопасный код, а бизнес-руководители без опыта определяют технологии. LLM не дают новой информации, но делают её более эксплуатируемой: для узких задач (например, сборка бомбы) разница между Google и LLM минимальна, для широких — значительна. Аналогии с «Anarchist Cookbook» и голландскими взрывами из-за легальных фейерверков показывают: мотивация, а не доступ, решает — это социальные и юридические проблемы, а не технологические. Не хватает времени на исправление багов — нужно повышать стоимость эксплуатации, а не устранять 10 очевидных уязвимостей, ведь их будет бесконечно много. ИИ ускоряет кризис безопасности, но может стать катализатором для принятия обязательных стандартов, как NIS2 — пока это происходит только под давлением законодательства.

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

Чтобы вернуть аудит, предлагается сохранять расшифрованные метаданные в отдельный журнал или добавить необфусцированный фрагмент в текущий лог, чтобы система могла продолжать фиксировать ключевые события. Авторы обсуждают компромисс между безопасностью шифрования и необходимой прозрачностью для отладки, и планируют внести изменения в протокол, чтобы аудит‑трейл оставался доступным без раскрытия содержимого сообщений. Если такой компромисс будет принят, это уменьшит количество обращений в issue и улучшит доверие к системе мониторинга.

• Кодекс шифрует сообщения между главным агентом и под‑агентами, делая их видимыми только серверу OpenAI
• Цель — ограничить использование и перепродажу подписок, защитить данные от черного рынка и дистилляции моделей
• Выходы под‑агентов всё равно остаются открытыми в открытом виде, а расшифровка происходит на стороне сервера
• Обсуждение вызывает вопросы о прозрачности, потенциальном «чёрном ящике» и риске привязки к экосистеме OpenAI