В статье не предусматривал раздел для быстрого перехода по якорному содержанию, поскольку статья также выходит на сайте opensophy, где есть TOC-панель справа. Хабру в копилку идею создать слева меню с TOC-панелью.(думаю это хорошая фича чтобы не писать содержание всё время в тексте)
Про /sys — не стал делать упоминание, поскольку о нём больше и подробнее будет возможно в следующих частях серии по Linux.
Здравствуйте! Тут многое зависит от контекста использования системы. В типичном администрировании — да, зомби явление +/- редкое. А вот если тестировать сторонние инструменты какие-нибудь, то могу из личного опыта сказать: проверял несколько инструментов на базе Puppeteer, 2 из 5 оказались с багом в управлении дочерними процессами и стабильно плодили зомби(не прям много но всё же.)
Здравствуйте! Согласен, это хороший нюанс. В статье я только кратко упомянул, что в env могут лежать чувствительные данные, но не стал углубляться в вопросы доступа через /proc и особенности контейнерных окружений, счёл эту информацию на другую часть статьи по безопасности Linux.
Автор, горжусь вами! У меня почти похожая история(буквально тоже начинал с дизайна, потом веб и теперь devsecops изучаю.) Буду рад если совместно в будущем что-нибудь сделаем :)
Здравствуйте! Насчёт IMEI я в теории чисто написал (поэтому написал что нужен какой-то слой) — имел в виду что нужен какой-то идентификатор устройства.
Здравствуйте! Да, Вы правильно всё поняли. Насчёт DDoS: тестировал на своём оборудовании тысячи незавершённых рукопожатий — в основном страдает CPU. Rate limit + Fail2ban неплохо сработали, но при распределённой атаке (к примеру с тысяч IP банить поштучно уже малоэффективно я думаю), пока не нашел ещё варианты как реализовать более мощнее слой против DDoS.
Насколько я знаю, в самом сертификате нет, нужен слой который будет привязывать сертификат к устройству. Как пример Аппаратные ключи и хранилища или по IMEI
Если у вас есть вопросы по mTLS или предложения/идеи по дополнительному тестированию сервера на возможные векторы атак — пишите в комментариях. Интересные и новые методы атак, предложенные вами, я добавлю в статью вместе с результатами.
Здравствуйте! Да, вы правильно уловили проблему, пример получился скорее демонстрацией механики проверки прав ядром, чем реальной схемы использования групп.
Смысл того примера был показать, что права owner/group не суммируются: если процесс является владельцем файла, ядро использует только owner-биты и до group уже не доходит. Я уточню в статье отдельно, чтобы пример с ivan не создавал впечатление, будто группы «не работают как ожидается». Большое спасибо!
Важное примечание: В этой статье намеренно остановились на «продвинутой базе». Тема прав доступа в контексте безопасности продолжится в следующих частях серии (и немного разберем их ещё в логи и мониторинг.)
Здравствуйте! Упомянул их в итогах с примерами инструментов намеренно без глубокого разбора, потому что там всё +/- интуитивно: SCA смотришь зависимости, DAST гоняешь по живому стенду. Хотелось сфокусироваться на связке SAST + LLM, которая менее очевидна и требует объяснения.
В текущем виде скрипта — да. Планирую доработать его и добавить поддержку работы с Docker labels, чтобы не было необходимости переходить полностью на file provider.
Для nginx, скорее всего, будет отдельный скрипт, так как там логика интеграции отличается.
Да, с Docker это всё можно использовать. Если у вас Dokploy — в скрипте уже есть готовый пресет, просто в 6) Настройка путей выберите p1.
Если обычный Traefik, то выберите p2 / p3 или укажите свой путь вручную. ПРИМЕР:
Захожу в настройку путей
Выбираю пункт "Dynamic-конфиги Traefik" написав "1" в выбор, далее пишу свой путь где находиться у меня конфиги траефик
Сначала нужно развернуть сам сервис и Traefik с HTTPS, потом в скрипте создать CA, добавить сервис через [patch], и после этого создать сертификат.(можно иначе сделать - создать полностью новый(Добавить сервис [new]) но я предпочитаю через [patch] т.к я потом могу удостовериться что сервис работает по https.
В конце(после создания сертификата) появится путь к файлам, вам нужен client.p12 — его нужно импортировать в браузер в настройки сертификатов. В Chrome / Edge это обычно: Настройки → Безопасность → Управление сертификатами, в Firefox: Настройки → Privacy & Security → Certificates → Import.
пример пути для chrome: chrome://certificate-manager/clientcerts/platformclientcerts
mTLS решает задачу аутентификации на транспортном уровне для доступа к ресурсу. Случайно блокировать часть стандартного TLS... Очень глупо. Даже не знаю по какой причине могут это сделать 😁
Отличный проект и интересная идея! Было бы здорово увидеть демонстрацию его работы в действии. Небольшой пример или скринкаст помогли бы читателям наглядно оценить функционал и убедиться в эффективности решения.
По разному(ну смотря для чего и по ситуации). через getent — никак. Именно "откуда вообще может прийти запись" я смотрел через /etc/nsswitch.conf, но есть и те кто смотрит через инструменты sssctl / strace
Если не против то ссылку на вашу статью внесу в статью, как дополнение к ошибкам в ATS, хотя бы такое ру-исследование будет в статье, на которое как пример можно опираться. 😁
Здравствуйте! Спасибо за замечание :)
В статье не предусматривал раздел для быстрого перехода по якорному содержанию, поскольку статья также выходит на сайте opensophy, где есть TOC-панель справа. Хабру в копилку идею создать слева меню с TOC-панелью.(думаю это хорошая фича чтобы не писать содержание всё время в тексте)
Про /sys — не стал делать упоминание, поскольку о нём больше и подробнее будет возможно в следующих частях серии по Linux.
Здравствуйте! Тут многое зависит от контекста использования системы. В типичном администрировании — да, зомби явление +/- редкое. А вот если тестировать сторонние инструменты какие-нибудь, то могу из личного опыта сказать: проверял несколько инструментов на базе Puppeteer, 2 из 5 оказались с багом в управлении дочерними процессами и стабильно плодили зомби(не прям много но всё же.)
Здравствуйте! Согласен, это хороший нюанс. В статье я только кратко упомянул, что в env могут лежать чувствительные данные, но не стал углубляться в вопросы доступа через /proc и особенности контейнерных окружений, счёл эту информацию на другую часть статьи по безопасности Linux.
Автор, горжусь вами! У меня почти похожая история(буквально тоже начинал с дизайна, потом веб и теперь devsecops изучаю.) Буду рад если совместно в будущем что-нибудь сделаем :)
Здравствуйте! Насчёт IMEI я в теории чисто написал (поэтому написал что нужен какой-то слой) — имел в виду что нужен какой-то идентификатор устройства.
Здравствуйте! Да, Вы правильно всё поняли. Насчёт DDoS: тестировал на своём оборудовании тысячи незавершённых рукопожатий — в основном страдает CPU. Rate limit + Fail2ban неплохо сработали, но при распределённой атаке (к примеру с тысяч IP банить поштучно уже малоэффективно я думаю), пока не нашел ещё варианты как реализовать более мощнее слой против DDoS.
Насколько я знаю, в самом сертификате нет, нужен слой который будет привязывать сертификат к устройству. Как пример Аппаратные ключи и хранилища или по IMEI
Если у вас есть вопросы по mTLS или предложения/идеи по дополнительному тестированию сервера на возможные векторы атак — пишите в комментариях. Интересные и новые методы атак, предложенные вами, я добавлю в статью вместе с результатами.
Спасибо за замечание! Добавил в раздел 4 объяснение разницы между +x и +X.
Здравствуйте! Да, вы правильно уловили проблему, пример получился скорее демонстрацией механики проверки прав ядром, чем реальной схемы использования групп.
Смысл того примера был показать, что права owner/group не суммируются: если процесс является владельцем файла, ядро использует только owner-биты и до group уже не доходит. Я уточню в статье отдельно, чтобы пример с ivan не создавал впечатление, будто группы «не работают как ожидается». Большое спасибо!
Важное примечание: В этой статье намеренно остановились на «продвинутой базе». Тема прав доступа в контексте безопасности продолжится в следующих частях серии (и немного разберем их ещё в логи и мониторинг.)
Нет конечно, это глупость полная что всё одним файлом:)
Вам прислать репозиторий или так неприязнь к вайбкоду написали?
Здравствуйте! Упомянул их в итогах с примерами инструментов намеренно без глубокого разбора, потому что там всё +/- интуитивно: SCA смотришь зависимости, DAST гоняешь по живому стенду. Хотелось сфокусироваться на связке SAST + LLM, которая менее очевидна и требует объяснения.
Статью переименовал на Вайбкод и безопасность: как не задеплоить уязвимости вместе с фичами и изменил обложку ( мемную обложку всерьез восприняли и даже влипили -1 в карму...)
В текущем виде скрипта — да.
Планирую доработать его и добавить поддержку работы с Docker labels, чтобы не было необходимости переходить полностью на file provider.
Для nginx, скорее всего, будет отдельный скрипт, так как там логика интеграции отличается.
Здравствуйте! Спасибо большое за звезду :)
Да, с Docker это всё можно использовать. Если у вас Dokploy — в скрипте уже есть готовый пресет, просто в 6) Настройка путей выберите
p1.Если обычный Traefik, то выберите
p2/p3или укажите свой путь вручную. ПРИМЕР:Захожу в настройку путей
Выбираю пункт "Dynamic-конфиги Traefik" написав "1" в выбор, далее пишу свой путь где находиться у меня конфиги траефик
Сначала нужно развернуть сам сервис и Traefik с HTTPS, потом в скрипте создать CA, добавить сервис через [patch], и после этого создать сертификат.(можно иначе сделать - создать полностью новый(Добавить сервис [new]) но я предпочитаю через [patch] т.к я потом могу удостовериться что сервис работает по https.
В конце(после создания сертификата) появится путь к файлам, вам нужен client.p12 — его нужно импортировать в браузер в настройки сертификатов. В Chrome / Edge это обычно: Настройки → Безопасность → Управление сертификатами, в Firefox: Настройки → Privacy & Security → Certificates → Import.
пример пути для chrome: chrome://certificate-manager/clientcerts/platformclientcerts
mTLS решает задачу аутентификации на транспортном уровне для доступа к ресурсу. Случайно блокировать часть стандартного TLS... Очень глупо. Даже не знаю по какой причине могут это сделать 😁
Отличный проект и интересная идея! Было бы здорово увидеть демонстрацию его работы в действии. Небольшой пример или скринкаст помогли бы читателям наглядно оценить функционал и убедиться в эффективности решения.
Отличная идея. Продолжение будет!)
По разному(ну смотря для чего и по ситуации). через
getent— никак. Именно "откуда вообще может прийти запись" я смотрел через /etc/nsswitch.conf, но есть и те кто смотрит через инструментыsssctl/straceНедавно писал про баг ATS (приводил как пример там один.)
Если не против то ссылку на вашу статью внесу в статью, как дополнение к ошибкам в ATS, хотя бы такое ру-исследование будет в статье, на которое как пример можно опираться. 😁