❌

Reading view

Протухшие сертификаты, нулевой keystore и потерянная «@»: воскрешаем Huawei SANEX9510 без перезагрузки базы

Система стояла мёртвой десять месяцев, пока платная поддержка искала причину. Я поднял её за три дня. Оказалось, что «просто протухли сертификаты» было семью независимыми поломками: keystore на 0 байт, зашифрованный пароль с потерянной первой «@», приватный ключ, который не понимает родной OpenSSL продукта, и утёкшие соединения к Sybase IQ. Разбираем слой за слоем, без ребута и без сброса паролей.

Читать далее
  •  

Управляемый DTLS-прокси на Rust: решения, ошибки и цена упрощения

В первой части я рассказывал, как, почти не зная Rust, взялся за UDP/DTLS-прокси для системы управления 300 тыс. устройств и поручил большую часть реализации ИИ. Тогда я сосредоточился на том, как меняется работа инженера, когда код пишет модель.

Теперь — техническая сторона этой истории: почему локальная таблица маршрутов в XDP теряла рукопожатия, как прокси без общего хранилища находит владельца DTLS-сессии и почему 26-байтовый CID с HMAC и подписанный PPv2 уступили более простым решениям. Расскажу, какие компромиссы пришлось принять и какие ошибки удалось обнаружить на испытаниях.

Читать далее
  •  

NFS нельзя оставлять открытым: шифрование, отказоустойчивость и никакого VIP

NFS часто выбирают за простоту: развернул сервер, опубликовал каталог, смонтировал его на клиентах – и файловый сервис готов. Но когда хранилище попадает в критичный контур, одной такой конфигурации уже недостаточно.

Требования к информационной безопасности и высокой доступности ставят новые инженерные вопросы. Как зашифровать NFS-трафик, не меняя приложения? Как обеспечить актуальность данных на резервном узле? Кто и в какой последовательности поднимает сервисы после аварии? И как переключить клиентов без виртуального IP (VIP)?

Привет, Хабр! Меня зовут Егор Шманев, я системный инженер в К2Тех. В статье расскажу, как мы решили эти задачи и что потребовалось, чтобы отдельные компоненты заработали как единый файловый сервис.

Читать далее
  •  

Семь с половиной часов: как Go закрывал дыру в ключах eMudhra и что сделать у себя

17 октября Mozilla заблокировала восемь промежуточных CA eMudhra: их приватные ключи были меньше 256 и восстанавливались из сертификата за микросекунды. Команда Go выпустила 1.27.3 и 1.26.10 меньше чем за семь с половиной часов, и это первый релиз по новому треку URGENT.

Разбираем хронологию из поста Go Security и дополняем её: восстанавливаем слабый ECDSA-ключ на Go, объясняем, почему из-за кросс-подписей не помогает удалить корень, собираем deny-list по SPKI через VerifyConnection и разбираемся, что не так с отзывом сертификатов в Linux.

Читать далее
  •  
❌