In this guide we're going to take a look at how we can use cheap and "low end" hardware to build an amazing OpenBSD router with firewalling capabilities, segmented local area networks, DNS with domain blocking, DHCP and more.

We will use a setup in which the router segments the local area network (LAN) into three separate networks, one for the grown-ups in the house, one for the children, and one for public facing servers (a DMZ), such as a private web server or mail server. We will also look at how we can use DNS to block out ads, porn, and other websites on the Internet. The OpenBSD router can also be used on small to mid-size offices.

https://openbsdrouterguide.net/

#hardware #system #network

Attacking & Securing Active Directory

https://rmusser.net/docs/Active_Directory.html

#security #microsoft #activedirectory #ad

«Сравнение» linsor с ceph :)

https://linbit.com/blog/how-does-linstor-compare-to-ceph/

#ceph #linstor #sds #compair

Еще один awesome список, на это раз список содержит ссылки руководства по усилению безопасности.

https://github.com/decalage2/awesome-security-hardening

#awesome #security

Prometheus storage: technical terms for humans

https://valyala.medium.com/prometheus-storage-technical-terms-for-humans-4ab4de6c3d48

#prometheus #prom #monitoing #tsdb

📧 Email Authenticity 101: DKIM, DMARC, and SPF. И ещё вот тут неплохо так про SPF, DKIM, DMARC записи для домена. #email #dns #будничное

kubescape

Кажется уже все слышали, что NSA (National Security Agency) выпустили Kubernetes Hardening Guidance, но не все знают, что вслед за этим вышел open-source инструмент Kubescape от компании Armo для проверки кластера на соответствие этому гайду. Подобный набор проверок можно встретить в том же kubeaudit, но kubescape отличает тот факт, что правила написаны на языке OPA (Rego). Тут стоит отметить, что речь идет именно о кластере, а не о манифестах, которые хранятся в git, где может подойти любой IaC сканер вроде kics.

UPD. Исходя их сорсов, тула ходит во внешние серверы Armo за правилами. Спасибо @ttffdd

#k8s #ops

Threat Hunting with Kubernetes Audit Logs - Part 2

Вторая статья на тему обработки событий с Kubernetes API для поиска аномалий (первую можно прочитать здесь). Событий стало чуть больше и теперь они привязаны к матрице MITRE ATT&CK.

#k8s #ops

[Article][Kubernetes]
NetworkPolicy Editor: Create, Visualize, and Share Kubernetes NetworkPolicies

https://cilium.io/blog/2021/02/10/network-policy-editor

Любопытный инструмент

На недавнем ZN, играя в CTF'чик, зайдя на хост, увидел любопытный инструмент - pspy64. Раньше такого не встречал.

Запустив, понял что этот инструмент находясь в *user space* показывает все запущенные процессы системы с их cmdline и т.д. (В том числе рутовые процессы и процессы других пользователей системы).

Понял что тут примешено чутка хакерской магии, т.к. просто дампнуть процессы пользователя root мы конечно же не можем. Я понимал, что можно спарсить /proc, но это не настолько подробно и мне казалось что это весьма долго.

Так вот, я решил почитать о нем и также захотелось рассказать вам. Опишу идею кратко, а вы если захотите разберетесь глубже.

Встречайте: https://github.com/DominicBreuker/pspy

pspy - unprivileged Linux process snooping

pspy - это инструмент командной строки, предназначенный для наблюдения за процессами без необходимости получения прав root. Он позволяет просматривать команды, запущенные другими пользователями, задания cron и т.д. по мере их выполнения. Отлично подходит для исследования систем Linux в CTF. Также отлично подходит для демонстрации коллегам, почему передача секретов в качестве аргументов в командной строке - плохая идея.

Как это работает

Существуют инструменты, позволяющие перечислить все процессы, выполняемые в системах Linux, включая те, которые завершились. Например, существует forkstat. Он получает уведомления от ядра о событиях, связанных с процессами, таких как fork и exec.

Эти инструменты требуют привилегий root, но это не должно вызывать у вас ложного чувства безопасности. Ничто не мешает вам подглядывать за процессами, запущенными в системе Linux. Много информации видно в procfs до тех пор, пока процесс запущен. Единственная проблема заключается в том, что вам нужно поймать недолговечные процессы за очень короткий промежуток времени, в течение которого они живы. Сканирование каталога /proc в поисках новых PID в бесконечном цикле делает этот трюк, но потребляет много CPU.

Более скрытный способ - использовать следующий трюк. Процессы обычно обращаются к таким файлам, как библиотеки в /usr, временные файлы в /tmp, файлы журналов в /var, ... Используя API inotify, вы можете получать уведомления всякий раз, когда эти файлы создаются, изменяются, удаляются, к ним обращаются и т.д. Linux не требует прав привилегированных пользователей для работы с этим API, поскольку он необходим для многих невинных приложений (например, текстовых редакторов, показывающих актуальный проводник файлов). Таким образом, хотя пользователи без права root не могут напрямую следить за процессами, они могут следить за влиянием процессов на файловую систему.

Мы можем использовать события файловой системы как триггер для сканирования /proc, надеясь, что мы сможем сделать это достаточно быстро, чтобы поймать процессы. Именно это и делает pspy. Нет гарантии, что вы не пропустите ни одного процесса, но в моих экспериментах шансы кажутся высокими. В общем, чем дольше идут процессы, тем больше шансов их поймать.

Что сказать? Гениально!

[Перевод] Переносим философию Unix в 21 век
https://habr.com/ru/post/574778/?utm_source=habrahabr&utm_medium=rss&utm_campaign=574778
Tags: Блог компании RUVDS.com, Настройка Linux, Системное администрирование, *nix, Серверное администрирование, ruvds_перевод, ifconfig, unix, json
Author Bright_Translate #habr

Контроль доступа на основе ролей (RBAC) что об этом думают в Tailscale, но про их реализацию в самом конце. В основном это сравнение и описание принципов построения различных концепций контроля доступа, их реализация в существующих решениях, шаг за шагом приближаясь к описываемой системе. Хорошая и длинная статья по теме, если никогда не интересовались этим раньше.

Cloud Security Orienteering

Статья на тему, что нужно делать, чтобы разобраться в безопасности AWS организации, про которую ты ничего не знаешь. Приведено большое количество фреймворков в стиле awesome, такие как AWS Security Maturity Roadmap 2021, The AWS Security Reference Architecture и Cloud Penetration Testing Playbook. Плюс сам автор статьи поделился своим собственным чеклистом.

#aws #ops

Эволюция Docker. Часть 2.2
https://habr.com/ru/post/575256/?utm_source=habrahabr&utm_medium=rss&utm_campaign=575256
Tags: Программирование, Виртуализация, Go, DevOps, История IT, докер, docker, lxc, контейнеры, история it, aufs
Author nick1612 #habr

RHCSA Red Hat Enterprise Linux 8: Training and Exam Preparation Guide (EX200)

January 10, 2020

Highlights:
> Covers Red Hat Enterprise Linux 8
> Covers ALL official exam objectives for the RHCSA exam based on Red Hat Enterprise Linux 8
> Equally good for self-study and in-class training
> 81 Step-by-Step exercises
> 70 Do-It-Yourself Challenge Labs
> 375 Check Your Understanding Questions & Answers
> Concepts explained with diagrams
> Commands and options summarized in tables
> Exam tips included
> 4 Unique Sample RHCSA Exams

#Linux #Книга #RHCSA

Linux Bible, 10th Edition (2020)

Автор: Christopher Negus
Количество страниц: 928

Целевая аудитория: разработчики на Linux, программисты и любопытные пользователи.

«Библия Linux» рассказывает, как:

- приступить к работе с Linux;
- защитить системы и сети с Linux;
- реализовать автоматизацию дата-центра с помощью Ansible;
- упростить системное администрирование с помощью Cockpit;
- получить доступ к командной оболочке и писать простые скрипты;
- изучить контейнеризацию с применением Docker и Podman и, в частности, оркестрацию контейнеров с использованием Kubernetes и OpenShift;
- конфигурировать различные серверы и устранять распространенные проблемы;
- создавать виртуальные машины Linux, работающие на гипервизорах и облачных платформах.

#Linux #Книга #English

Futex (Fast Userspace Mutex) это примитив синхронизации в ядре Linux, который позволяет ждать регион памяти по какому-то значению с каким-то таймаутом. Из-за своего названия может показаться, что futex это на самом деле mutex, но это не так. Это было так в гораздо более ранней реализации, но теперь (Linux 2.6+) это просто примитив очереди ожидания (waitqueue), доступный для пользовательского пространства. Опция FUTEX_WAKE говорит: «Разбуди всех, кто ждет по этому адресу». FUTEX_WAIT говорит: «Когда я читаю ADDR, он содержит VALUE: если он все еще содержит это значение, когда вы смотрите на него, спите, пока кто-то не вызовет FUTEX_WAKE по этому адресу». А FUTEX_FD посылает все нотификации в файловый дескриптор.

Mutex из Futex можно сделать так: Два потока совместно используют некоторую память и соглашаются использовать её часть в качестве синхронизации (или блокировки). 1 означает разблокирован, 0 означает заблокирован, <0 означает заблокирован и кто-то ждет. Чтобы захватить блокировку, вы выполняете операцию atomic декремента: если он достигает 0, значит, это было 1, и у вас есть блокировка. В противном случае вы немного подождёте. Когда вы хотите снять блокировку, вы снова устанавливаете ее на 1. Это действительно быстро, если нет конфликта за блокировку и futex достаточно хорошо работает при маленьком количестве потоков борящихся за блокировку. Также ядро достаточно хитрым образом не уходит в своё пространство, когда нет contention на регион, но об этом в другом посте.

Futex используется в каждой реализации лока, в том числе glibc, abseil. Это действительно удобный интерфейс для имплементации медленных путей в локах, семафорах. Futex хоть и поменял то, как мы мыслим о локах в 2000х годах, к сожалению всё ещё существует достаточно много проблем. Некоторые из них такие:

0. Код вокруг Futex нереально сложный
1. Futex ещё всё умеет только ждать по 32 битному региону памяти, иногда это может вызывать проблемы в долгоживущих программах и некоторых имплементациях локов. Также может не подходить для embedded систем, где 32 битного адреса нет совсем
2. Futex не умеет давать подсказки по тому на какой NUMA стоит иметь регион
3. Futex не умеет ждать по многим регионам памяти одновременно

Последний недостаток как ни странно достаточно сильно бьёт по игровым движкам, например, в Windows есть WaitForMultipleObjects. Тот же wine и proton писали, что на Linux создаются большие проблемы из-за этого и им приходится из-за этого придумывать трюки с eventfd , чтобы демонстрировать то же поведение, из-за чего происходит большая нагрузка на файловые дескрипторы, которых ограниченное количество на Linux (движки репортят миллионы). В итоге получается, что некоторые игры просто не могут пойти на Linux из-за проблем синхронизации или работают медленно.

Valve, Collabora (продукты LibreOffice и тд) объединили свои силы в пропозал почти 2 года назад улучшить futex добавив futex2, где большинство упомянутых проблем решаются. У них получилось с помощью множества wait (futex_waitv) ускорить Beat Saber и Tomb Raider на 4%.

К сожалению, после года обсуждений оф. RFC оно не попало в Linux 5.15, но имеет все шансы попасть в Linux 5.16, почти ни у кого нет уже вопросов, и кажется консенсус обретён.

Я надеюсь, что выбор Arch Linux у Steam Deck от Valve был под влиянием некоторых таких изменений, Arch Linux обновляет своё ядро очень быстро и можно спокойно продолжать гнуть свою палку по переводу игр на Linux, получая сразу все фичи, что несомненно меня радует как и глубокие изменения, которые Valve делают в ядре, чтобы это произошло. Кто, если не Valve 🙂

[1] Futexes Are Tricky (советую прочитать, чтобы понять как пользоваться futex)
[2] Изначальный пропозал от Collabora и Valve
[3] Rethinking the futex API
[4] futex man page
[5] A New Futex2() System Call - André Almeida, Collabora (видео от основного контрибьютера)
[6] Linux 5.15 attempt, 5.16 attempt
[7] WIN32 WaitForMultipleObjects API
[8] Valve’s upcoming Steam Deck will be based on Arch Linux—not Debian
[9] Официальный RFC в ядро
[10] Glibc lock implementation
[11] C++20 atomic_wait/notify

Why NFS Sucks

This article will give an overview of NFS history, features and shortcomings, briefly compare it to other remote file systems, and present an outlook on future directions.

https://www.cc.gatech.edu/classes/AY2010/cs4210_fall/papers/nfsOLS.pdf

В продолжение моего недавнего поста про безопасность при node-based multi-tenancy - в официальном блоге Kubernetes вышла статья "Advanced Kubernetes pod to node scheduling"

В ней очень просто, понятно с примерами рассматриваются такие Use Cases для Pod-to-Node Scheduling, как :
- Running pods on nodes with dedicated hardware
- Pods colocation and codependency
- Data Locality
- High Availability and Fault Tolerance

Странно, но сценарий, связанный с ИБ отсутствует. Хотя можно придумать множество таких сценариев: распределение сервисов, что обрабатывают критичную информацию, или отделение сервисов, что часто грешат уязвимостями, или сервисы внутренней разработки отделять от сторонних разработк и т.д.

В статье рассматриваются следующие механизмы и стратегии:
- nodeSelector
- Node Affinity
- Inter-Pod Affinity
- Taints and Tolerations
- Pod Anti-Affinity

Вообще за последнее время вышло много статей по данной теме и можно сказать, что это какой-то тренд или нет ;)