Forwarded from linkmeup
Forwarded from Технологический Болт Генона
Извините, но мы продолжаем 🌝
Ссылка на запрос для получения списка действий пользователя на GitHub
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPTSBnaXRodWJfZXZlbnRzIFdIRVJFIGFjdG9yX2xvZ2luPSdKaWFUNzUnIE9SREVSIEJZIGZpbGVfdGltZSBERVND
Там возвращается не всё, потому что были собраны данные об активности и выяснилось, что первые странные действия этого пользователя появились ещё в 2021 году
Everything I Know About the Xz Backdoor
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Ссылка на запрос для получения списка действий пользователя на GitHub
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPTSBnaXRodWJfZXZlbnRzIFdIRVJFIGFjdG9yX2xvZ2luPSdKaWFUNzUnIE9SREVSIEJZIGZpbGVfdGltZSBERVND
Там возвращается не всё, потому что были собраны данные об активности и выяснилось, что первые странные действия этого пользователя появились ещё в 2021 году
The first commits they make are not to xz, but they are deeply suspicious. Specifically, they open a PR in libarchive: Added error text to warning when untaring with bsdtar. This commit does a little more than it says. It replaces safe_fprint with an unsafe variant, potentially introducing another vulnerability. The code was merged without any discussion, and lives on to this day (patched).
Everything I Know About the Xz Backdoor
https://boehs.org/node/everything-i-know-about-the-xz-backdoor
https://youtube.com/playlist?list=PLJcGJBfGQVIjy5CJ8tjnPJImDMymWBEo0&si=nN_8MdSDrIXgg8QH
Курс лекций по Операционным Системам
#OS
Курс лекций по Операционным Системам
#OS
Forwarded from Кубертатный период (Pavel Klyuev)
Челик проходил интервью в Google на позицию Senior Site Reliability Engineer, SE (System Engineering) и любезно записал все вопросы и ответы на них с рассуждениями
https://prepare.sh/engineering/devops/google/
Там есть и другие интервью на другие позиции
https://prepare.sh/engineering/devops/google/
Там есть и другие интервью на другие позиции
Forwarded from linkmeup
На случай если вам скучно и вдруг захочется почитать про организацию в линуксе замудрённого page cache.
https://biriukov.dev/docs/page-cache/0-linux-page-cache-for-sre/
https://biriukov.dev/docs/page-cache/0-linux-page-cache-for-sre/
Viacheslav Biriukov
Linux Page Cache for SRE
SRE deep dive into Linux Page Cache # In this series of articles, I would like to talk about Linux Page Cache. I believe that the following knowledge of the theory and tools is essential and crucial for every SRE. This understanding can help both in usual…
Forwarded from linkmeup
Безбожники запихали Doom в htop.
Кому мерзость, но покажите ещё, можно посмотреть самому https://github.com/0x0mer/doom-htop
Кому мерзость, но покажите ещё, можно посмотреть самому https://github.com/0x0mer/doom-htop
rsync
article 1: Scenarios https://michael.stapelberg.ch/posts/2022-06-18-rsync-article-1-scenarios/
article 2: Surroundings https://michael.stapelberg.ch/posts/2022-07-02-rsync-surroundings/
article 3: How does rsync work?
https://michael.stapelberg.ch/posts/2022-07-02-rsync-how-does-it-work/
#rsync
article 1: Scenarios https://michael.stapelberg.ch/posts/2022-06-18-rsync-article-1-scenarios/
article 2: Surroundings https://michael.stapelberg.ch/posts/2022-07-02-rsync-surroundings/
article 3: How does rsync work?
https://michael.stapelberg.ch/posts/2022-07-02-rsync-how-does-it-work/
#rsync
Michael Stapelberg
rsync, article 1: Scenarios
This post is the first article in a series of blog posts about rsync, see the Series Overview.
To motivate why it makes sense to look at rsync, I present three scenarios for which I have come to appreciate rsync: DokuWiki transfers, Software deployment and…
To motivate why it makes sense to look at rsync, I present three scenarios for which I have come to appreciate rsync: DokuWiki transfers, Software deployment and…
Forwarded from DOFH - DevOps from hell
Пример ненадёжности хеш функций:
Разница строк - в одном бите.
#ЗпН
%
echo -n TEXTCOLLBYfGiJUETHQ4hAcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak | md5sum
faad49866e9498fc1719f5289e7a0269 -
% echo -n TEXTCOLLBYfGiJUETHQ4hEcKSMd5zYpgqf1YRDhkmxHkhPWptrkoyz28wnI9V0aHeAuaKnak | md5sum
faad49866e9498fc1719f5289e7a0269
-
Разница строк - в одном бите.
#ЗпН
Forwarded from linkmeup
Ребятки решили сделать разным CNI больно и запустили тест на 40 Гбит/с ибо интересно же, кто что может выдать в 2024.
Самое интересное на мой взгляд:
- Без eBPF забудь про многопоточку
- Универсального комбайна, который хорошо молотит любой вид нагрузки, так и не изобрели
- Свои варианты применения есть и у куброутера, и у силиума, и калико, и так далее. Просто не надо брать бездумно по названию
https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-40gbit-s-network-2024-156f085a5e4e
Самое интересное на мой взгляд:
- Без eBPF забудь про многопоточку
- Универсального комбайна, который хорошо молотит любой вид нагрузки, так и не изобрели
- Свои варианты применения есть и у куброутера, и у силиума, и калико, и так далее. Просто не надо брать бездумно по названию
https://itnext.io/benchmark-results-of-kubernetes-network-plugins-cni-over-40gbit-s-network-2024-156f085a5e4e
Medium
Benchmark results of Kubernetes network plugins (CNI) over 40Gbit/s network [2024]
This article is a new run of my previous benchmark (2020, 2019 and 2018), now running Kubernetes 1.26 and Ubuntu 22.04 with CNI version…
Forwarded from k8s (in)security (r0binak)
Если вам захотелось посмотреть как выглядит ваш
По сути это небольшой
ETCD
внутри, то инструмент ETCD Keeper может с этим помочь.По сути это небольшой
web ETCD client
с возможностью просматривать, добавлять, обновлять или удалять ноды, а также сами ключи и их значения. Есть поддержка как v2
так и v3
версии.https://ymmt2005.hatenablog.com/entry/2019/08/10/Writing_and_testing_Kubernetes_webhooks_using_Kubebuilder_v2
#k8s #kubernetes #webhook #tresting
#k8s #kubernetes #webhook #tresting
Blog of @ymmt2005
Writing and testing Kubernetes webhooks using Kubebuilder v2 - Blog of @ymmt2005
Recently, I am leading a project to re-design our on-premise data centers using Kubernetes. Inevitably there are opportunities to develop Kubernetes native appl…
Forwarded from Bash Days | Linux | DevOps (Роман Шубин)
✨ Ты - самый счастливый человек на планете!
Почему? Потому, что сейчас узнаешь про ONLY.
Частенько возникала необходимость разрешить пользователю запускать только определенные команды по ssh. То есть явно указать ему белый список таких команд.
Городили мы конечно знатные велосипеды с помощью костылей, rbash, симлинков, chroot и т.п.
Все эти костыли были неудобные и какие-то пиздец сложно поддерживаемые. Но решение было найдено и вполне элегантное. Всё ужеукрадено придумано за нас.
Для затравки:
Думаю идею ты понял. Пользователь подключается по ssh и может выполнить только 3 команды rsync, ls, cat.
И тут большой плюс - пользователь не получает интерактивную оболочку, то есть всё сводится к выполнению подобной конструкции:
Команда ls находится в белом списке и успешно отработает при подключении по ssh, а дальше сессия завершится.
Нехер ему на сервере делать. Есть список команд, вот пусть ими и довольствуется без интерактива.
✔️ Теперь подробности
ONLY это НЕ какая-то встроенная команда в Linux, это Bash скрипт, который аккуратно лежит в
1. Берем only из репы
2. Кидаем его в
3. Ставим chmod +x чтобы запускался
4. Делаем пару ключей для работы
P = пустая парольная фраза
f = задаем имя ключа
Содержимое ключа only pub добавляем в authorized_keys нужному пользователю, а private key отдаем, тому кто будет подключаться к серверу.
Да, файл authorized_keys у меня выглядит примерно так:
То есть запрещаем всякую лишнюю хуйню. Ну и добавляем в белый список команды, которые будем позволять запускать этому пользователю.
Важная штука, потребуется файл с правилами, называется .onlyrules. Забирай тут.
Этот файл нужно также скопировать в папку, того пользователя, которого ограничиваем, например в
Правила нужны, чтобы еще сильнее ограничить пользователя на ввод команд, этакие лимиты на регулярках и sed.
Короче это фильтры на аргументы, ключи и т.п. Можно не заморачиваться и просто обернуть нужные команды между
Все файлы из этого поста можешь взять в нашей репе. А историю создания этой пепяки и мельчайшие подробности, можешь почитать тут кстати очень занятно чтиво, правда на английском, да и похер.
Лично мне эта штука понравилась, раздал тестировщикам ключики, теперь они сами могут своих вонючих демонов перезапускать, без блуждания по серверу и фраз — да блядь, я что-то нажал и всё сломалось!
Такие дела. Увидимся!
tags: #bash #linux #utils
@ВАSНDАYS | BАSHDАYS.CОM
Почему? Потому, что сейчас узнаешь про ONLY.
Частенько возникала необходимость разрешить пользователю запускать только определенные команды по ssh. То есть явно указать ему белый список таких команд.
Городили мы конечно знатные велосипеды с помощью костылей, rbash, симлинков, chroot и т.п.
Кстати про chroot писал в этом посте, почитай на досуге, мож где применишь.
Все эти костыли были неудобные и какие-то пиздец сложно поддерживаемые. Но решение было найдено и вполне элегантное. Всё уже
Для затравки:
/home/user/.ssh/authorized_keys
command="only rsync ls cat" ssh-rsa AAAAB3Nza
Думаю идею ты понял. Пользователь подключается по ssh и может выполнить только 3 команды rsync, ls, cat.
И тут большой плюс - пользователь не получает интерактивную оболочку, то есть всё сводится к выполнению подобной конструкции:
ssh user@bashdays.ru ls /home/user/
Команда ls находится в белом списке и успешно отработает при подключении по ssh, а дальше сессия завершится.
Нехер ему на сервере делать. Есть список команд, вот пусть ими и довольствуется без интерактива.
ONLY это НЕ какая-то встроенная команда в Linux, это Bash скрипт, который аккуратно лежит в
/usr/local/sbin
, положить его туда ты должен самостоятельно.1. Берем only из репы
2. Кидаем его в
/usr/local/sbin/only
3. Ставим chmod +x чтобы запускался
4. Делаем пару ключей для работы
ssh-keygen -P "" -f only
P = пустая парольная фраза
f = задаем имя ключа
Содержимое ключа only pub добавляем в authorized_keys нужному пользователю, а private key отдаем, тому кто будет подключаться к серверу.
Да, файл authorized_keys у меня выглядит примерно так:
command="only rsync cat ls", no-agent-forwarding, no-port-forwarding, no-pty, no-user-rc, no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAA
То есть запрещаем всякую лишнюю хуйню. Ну и добавляем в белый список команды, которые будем позволять запускать этому пользователю.
Важная штука, потребуется файл с правилами, называется .onlyrules. Забирай тут.
Этот файл нужно также скопировать в папку, того пользователя, которого ограничиваем, например в
/home/user/.onlyrules
Правила нужны, чтобы еще сильнее ограничить пользователя на ввод команд, этакие лимиты на регулярках и sed.
\:^ls$:{p;q}
\:^who$:{p;q}
Короче это фильтры на аргументы, ключи и т.п. Можно не заморачиваться и просто обернуть нужные команды между
\:^ и $:{p;q}
.Бонусом, в папке пользователя можешь разместить файл .onlyrc и затюнить всякие информационные сообщения. Но автор не рекомендует этого делать и использовать only без этого файла.
Все файлы из этого поста можешь взять в нашей репе. А историю создания этой пепяки и мельчайшие подробности, можешь почитать тут кстати очень занятно чтиво, правда на английском, да и похер.
Лично мне эта штука понравилась, раздал тестировщикам ключики, теперь они сами могут своих вонючих демонов перезапускать, без блуждания по серверу и фраз — да блядь, я что-то нажал и всё сломалось!
Такие дела. Увидимся!
tags: #bash #linux #utils
@ВАSНDАYS | BАSHDАYS.CОM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Нарыл (Pavel Sorokin)
Есть такая общеизвестная проблема когда делаешь non-root в k8s: контейнерам нужно биндить порты до 1024, что по умолчанию в Linux запрещено.
Лично по-моему само по себе такое ограничение - архитектурная ошибка в Linux, которая привела к куче проблем и сложностей: сервису, например nginx, нужно стартовать от рута, забиндить порт, а потом дропнуть лишние привилегии. Что уже само по себе звучит не безопасно и разумеется приводило к множеству LPE. А профит с точки зрения ИБ крайне сомнительный. Может быть он был когда на одном сервере одновременно крутился важный сайт на 80 порту и еще сидели руками какие-то непривилегированные пользователи, но сейчас это кажется бесполезным чуть более чем полностью (попробуйте меня переубедить :D)
Параметр ядра net.ipv4.ip_unprivileged_port_start позволяет управлять этим поведением в Linux. Если его установить в значение 0, то любому пользователю будет доступен биндинг любых портов. Параметр net.ipv4.ip_unprivileged_port_start относится к сетевому неймспейсу и у каждого контейнера свой.
При внедрении non-root можно добавлять securityContext.sysctls (net.ipv4.ip_unprivileged_port_start=0) в манифесты, но это требует модификации всех манифестов.
И вот я тут обнаружил что есть другой путь - в конфиге containerd есть опция enable_unprivileged_ports, которая устанавливает net.ipv4.ip_unprivileged_port_start в 0 для всех создаваемых контейнеров.
Другими словами можно поменять один параметр на всех нодах и не возиться с манифестами.
Лично по-моему само по себе такое ограничение - архитектурная ошибка в Linux, которая привела к куче проблем и сложностей: сервису, например nginx, нужно стартовать от рута, забиндить порт, а потом дропнуть лишние привилегии. Что уже само по себе звучит не безопасно и разумеется приводило к множеству LPE. А профит с точки зрения ИБ крайне сомнительный. Может быть он был когда на одном сервере одновременно крутился важный сайт на 80 порту и еще сидели руками какие-то непривилегированные пользователи, но сейчас это кажется бесполезным чуть более чем полностью (попробуйте меня переубедить :D)
Параметр ядра net.ipv4.ip_unprivileged_port_start позволяет управлять этим поведением в Linux. Если его установить в значение 0, то любому пользователю будет доступен биндинг любых портов. Параметр net.ipv4.ip_unprivileged_port_start относится к сетевому неймспейсу и у каждого контейнера свой.
При внедрении non-root можно добавлять securityContext.sysctls (net.ipv4.ip_unprivileged_port_start=0) в манифесты, но это требует модификации всех манифестов.
И вот я тут обнаружил что есть другой путь - в конфиге containerd есть опция enable_unprivileged_ports, которая устанавливает net.ipv4.ip_unprivileged_port_start в 0 для всех создаваемых контейнеров.
Другими словами можно поменять один параметр на всех нодах и не возиться с манифестами.
Forwarded from GitHub'ненько
Robusta KRR
Robusta KRR (Kubernetes Resource Recommender) is a CLI tool for optimizing resource allocation in Kubernetes clusters. It gathers pod usage data from Prometheus and recommends requests and limits for CPU and memory. This reduces costs and improves performance.
#k8s #devops #cloud #resources
https://github.com/robusta-dev/krr
Robusta KRR (Kubernetes Resource Recommender) is a CLI tool for optimizing resource allocation in Kubernetes clusters. It gathers pod usage data from Prometheus and recommends requests and limits for CPU and memory. This reduces costs and improves performance.
#k8s #devops #cloud #resources
https://github.com/robusta-dev/krr