Информационная безопасность

Некоторые контейнеры (docker, например) могут внутри себя использовать iptables. Это означает, что и port knocking можно реализовать прямо в контейнере. Популярные вопросы: зачем нужен port knocking и какой смысл делать его в контейнере? Port knocking может снизить обнаружение сервиса (вместо попыток бороться с последствиями, когда сервис уже обнаружен: брутфорс, эксплуатация уязвимости). В случаях, когда нельзя использовать ACL. Особенно актуально в условиях, когда компании не успевают оперативно устранять уязвимости. В контейнере эта мера может быть полезной как подстраховка: если firewall (на хостовой системе или роутере) внезапно ослабнут правила защиты. Также это поможет разгрузить правила firewall хостовой системы.
Безусловно, port knocking, как и любая технология, не является "серебряной пулей". И в общем смысле не является заменителем какой-то другой. Но, используя port knocking совместно с другими решениями, можно существенно повысить безопасность сервисов. Внедрение данной защиты также потенциально увеличит доступное время для устранения уязвимости (пока её не начнут пытаться эксплуатировать на защищаемом сервисе). Использование port knocking также приводит к уменьшению логов. А, значит, логи проще обрабатывать. Кроме того, эта мера поможет решить проблему безопасности: доступности портов контейнеров NotCVE-2025-0001 (если используется docker версии ниже 28).
О проблемах на практике при внедрении port knocking, вариантах решения самых частых проблем и нюансах использования в docker контейнерах рассказано в этой статье. Сам скрипт для использования port knocking в docker контейнере тут.

Интересное продолжение истории о получении CVE для уязвимости в блокчейне Hyperledger Fabric. Разработчики не признают уязвимость. Это при том, что они внесли изменения, устраняющие проблему. Когда я им сообщил, что по моему обращению в MITRE присвоен идентификатор CVE - сказали, что нужно отозвать CVE: код ведь работал так, как и задумано. Как я понял, разработчики сочли, что MITRE создали идентификатор CVE автоматически, не вникая в суть моего обращения (что противоречит практике моих знакомых, у которых MITRE в ряде случаев запрашивало дополнительные данные перед назначением CVE). По этой причине, разработчики пытаются оспорить CVE (UPD: судя по обновлению от 12.09.2024, оспорить не вышло). Видимо, про уязвимость небезопасного дизайна из OWASP Top 10, они не слышали. Кроме того, по классификации, уязвимость попадает в OWASP Smart Contract Top 10: Timestamp Dependence. Допускаю, что разработчики об этом не знают. К сожалению, я им сообщить этого не могу: моё обращение на HackerOne разработчики закрыли, что заблокировало возможность мне добавлять текст к обращению. Я, кстати, не слышал, чтоб какой-либо идентификатор CVE был аннулирован. UPD: бывают отозванные CVE: CVE-2023-4881.

Лично у меня от этой истории сложилось такое впечатление: разработчики считают, что только они вправе определять: что является уязвимостью, а что - нет. Игнорируя при этом сложившуюся практику взаимодействия исследователей безопасности с MITRE.

Подробности - в статье "Как я зарегистрировал CVE и разозлил вендора"

Манипуляция временем транзакции в блокчейне Hyperledger Fabric - уязвимость (теперь официально).
Мне удалось добиться назначения идентификатора CVE (CVE-2024-45244) уязвимости, связанной с манипуляцием времени транзакции (о чём писал на Хабре) в блокчейне с открытым исходным кодом Hyperledger Fabric. Разработчик выпустил исправление, но не счёл это уязвимостью (о чём я узнал в переписке, по моему обращению на HackerOne). В итоге, мне пришлось самостоятельно заниматься процессом назначения CVE (воспользовавшись найденной мной на Хабре статьёй). Между обращением в MITRE и назначением CVE прошло чуть менее 2-х недель. UPD 13.09.2024 разработчик пытался оспорить, что это уязвимость - не вышло (подробнее в статье Как я зарегистрировал CVE и разозлил вендора).

Согласно результатам голосования на моём докладе на конференции по кибербезопасности OFFZONE, все участники согласились, что манипуляция временем транзакции является уязвимостью. Исправление сделали в версии 3.0.0 (в ветке 2.5.х продолжили выпускать версии без исправления). В качестве защиты, можно воспользоваться моей open source разработкой.

Блокчейн активно используется в разных сферах: цифровые валюты центробанков (Беларусии, Нигерии), операторами информационных систем цифровых финансовых активов, электронное голосование, энергетика, здравоохранение и др.

Опять про замедление ютуба
Сначала факты:
Некий депутат заявил, что скорость ютуба снизилась и снизится еще сильнее
https://t.me/Hinshtein/7276
Потом он же объяснил, что связано это с техническими проблемами, а не санкциями органов власти в РФ https://t.me/Hinshtein/7280
Однако в последующие дни (где-то с 28 июля) ютуб на десктопе у многих действительно стал показывать видео сильно медленнее и воспроизводить только видео в формате 144p. Причем проблема коснулась именно просмотра через браузер, на в мобильном приложении вроде как таких проблем не было.

Возникает вопрос: что это было?
1) Некоторые говорили, что ютуб тестирует какие-то технологии для борьбы с блокировщиками рекламы, но реального подтверждения этому я не нашел. То есть борьба с блокировщиками конечно ведется, но на территории РФ рекламу и так не показывают, а лично я блокировщиками рекламы не пользуюсь вообще.
2) Роскомнадзор решил по тестировать технологии замедления, а потом посмотрели на реакцию народа, и решили убрать это замедление.
3) Могла быть и инициатива Ростелекома, как единого магистрального провайдера.

В пользу причины 2 говорит то, что замедление устранялось включением GoodBuyDPI, который работает для обхода ТСПУ. Хотя это и не отменяет инициативы провайдера.