Здравствуйте! Согласен, это хороший нюанс. В статье я только кратко упомянул, что в 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, хотя бы такое ру-исследование будет в статье, на которое как пример можно опираться. 😁
На HH такого нет(по крайней мере не замечал сколько времени сижу там). Был оочень редкий случай когда в чате бот писал подобное, но потом после этого тишина. Хотя не исключаю, возможно есть просто этим мало кто пользуется.
Общепринятой(хотя даже официальной) расшифровкой является et cetera, но про бэкронимы тоже стоит знать чтобы не столкнуться с недопониманиями(как пример видел вопрос в одном форуме про линукс и там первоначально не поняли о чём речь поскольку назвали etc как Editable Text Configuration(не буквально так но суть понятна), и чаще замечал именно этот бэкроним в обсуждении)
Здравствуйте! Согласен, это хороший нюанс. В статье я только кратко упомянул, что в 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, хотя бы такое ру-исследование будет в статье, на которое как пример можно опираться. 😁
На HH такого нет(по крайней мере не замечал сколько времени сижу там). Был оочень редкий случай когда в чате бот писал подобное, но потом после этого тишина. Хотя не исключаю, возможно есть просто этим мало кто пользуется.
Общепринятой(хотя даже официальной) расшифровкой является et cetera, но про бэкронимы тоже стоит знать чтобы не столкнуться с недопониманиями(как пример видел вопрос в одном форуме про линукс и там первоначально не поняли о чём речь поскольку назвали etc как Editable Text Configuration(не буквально так но суть понятна), и чаще замечал именно этот бэкроним в обсуждении)