Пока вы ищете билеты на самолет, графана выпустила провайдер для управления алертами через терраформ
https://grafana.com/blog/2022/09/20/grafana-alerts-as-code-get-started-with-terraform-and-grafana-alerting/

Ansible - must have для тех, кто поднимает рабочее окружения на регулярной основе

Он нужен, если вы хотите:

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

Преимущества Ansible:
+ Никаких агентов и дополнительного ПO;
+ большое количество модулей;
+ команды пишутся на YAML, интуитивно понятном языке;
+ быстрое и простое погружение.

Зачем обучаться Ansible в Слёрме?

Курс дает базу, которая помогает экономить время и силы. Это не только теория, это кейсы спикера, его набитые шишки, а также 78 тестовых и 46 практических заданий на стендах в личном кабинете.

На курсе вы:

— Узнаете как работать с переменными, как писать плейбуки и роли;
— Развернете LEMP стек, PostgreSQL и Mongo кластеры,
задеплоите Flask приложение;
— Напишите свой модуль для Ansible;
— Настроите IaC в Gitlab;
— Разберетесь с работой с облаками и enterprise решениями.

➡️Пройти 2 первых урока курса бесплатно

Большинство из нас пользуется 64-разрядными системами. В таких системах процессы работают с адресным пространством размером 2^64 байт (16 эксабайт или 16 млн ТБ). Многие из читателей имеют столько памяти в системе? Как получается, что процесс видит 16 ЭБ памяти, когда в системе её намного меньше? Как получается, что относительно небольшая физическая память так интенсивно используется программами и не позволяет читать чужие данные? Как распределяется между процессами физическая память?

На эти вопросы отвечает книга Operating Systems. Three easy pieces. До её прочтения я слабо представлял себе работу ОС. А теперь представляю ещё хуже, зато более системно 😁 Вы ведь знакомы с этим чувством, когда начинаешь изучать что-то новое и открываешь новую пропасть в своих знаниях, которую придется заполнять ещё долгие годы?

Во время чтения книги появилась идея написать серию постов о работе ОС. Хочу начать с виртуальной памяти, так как мне её работа показалась очень элегантной и эффективной.

Кратко и маленькими частями эти посты будут выходить в этом телеграм канале, а потом появится один большой пост в блоге


Итак,

=== Виртуальная память в Linux. Часть 0 ===

Чем хороша виртуализация памяти: прозрачность, эффективность, изоляция

- Прозрачность (transparency ). Virtual memory реализована операционной системой абсолютно незаметно для процессов. Программы не знают что там происходит с памятью. Они думают, что владеют всей памятью в системе и не заботятся об изоляции от других проессов

- Эффективность (efficiency). Программисту не нужно думать о том, как и где хранить переменные, потому что виртуальное адресное пространство огромно. Жизнь становится проще, если не нужно задумываться о работе с низкоуровненвыми абстракциями. ОС делает виртуализацию максимально эффективной по времени и размеру. Благодаря работе с железом ОС делает этот процесс ещё лучше (MMU, TLB)

- Изоляция. ОС обеспечивает изоляцию адресных пространств. Один процесс не может обратиться к памяти другого. Спцеиально или из-за бага


#OS #OSTEP #memory #vm

Instagram упал
https://downdetector.com/status/instagram/

=== Виртуальная память в Linux. Часть 1.1 ===

Давным давно системы были однозадачными и вся память была доступна одному процессу. Не надо было беспокоиться о приватности данных и безопасности. Потом наступила эра многозадачности: компьютером стали пользоваться одновоременно несколько человек. Каждый запускает свои программы. Ранние реализации просто отдавали всю память процессу, а когда приходил другой процесс - содержимое памяти первого сбрасывалось на диск и в неё загружались данные нового процесса.

Очевидно, что запись и чтение с диска - операция затратная и куча времени бесполезно расходовалась на это. Нужен был новый, более эффективный
процесс.

#OS #OSTEP #memory #vm

=== Виртуальная память в Linux. Часть 1.2 ===

Этот процесс называется Sharing. Это использование одной физической памяти одновременно несколькими процессами. У каждого процесса есть своё адресное пространство

Адресное пространство (Address Space) - память, которую видит процесс. В 32 разрядных системах это 2^32 байт (4 ГБ), в 64 разрядных 2^64 Б (16 ЭБ). Очевидно, что физическая память не имеет отношения к объёму адресного пространства. Не у каждого из нас ведь есть 16 ЭБ RAM. Это всего лишь абстракция, предоставляемая операционной системой

Сам Address Space делится на три части:
- Code. Код процесса

- Heap. Куча. Начинается сразу после кода и растет вниз (от stack к 2^32 в 32-разрядных системах)

- Stack. Стек. Начинается с конца адресного простарнства и растет вверх (с 2^32 в 32-разрядных системах до конца кучи)

#OS #OSTEP #memory #vm

=== Виртуальная память в Linux. Часть 1.3 ===

Как видно на картинке процесс считает, что адресация его памяти начинается с ноля. КАЖДЫЙ процесс так считает. И все они одновременно работают в физической памяти

Как ОС создаёт эту иллюзию приватного огромного адресного пространства, начинающего с нуля для каждого процесса, на единой, не всегда большой физической памяти?

#OS #OSTEP #memory #vm

Перевели официальный FAQ MITRE ATT&CK

(финализировали все формулировки)

Перевод опубликован в статье на Хабр и в разделе Вопросы и ответы на сайте сообщества.

Переводили

— Антон Шипулин, сооснователь RUSCADASEC
— Олег Скулкин, Руководитель лаборатории цифровой криминалистики и исследования вредоносного кода Group-IB
— Илья Енин, SOC Analyst Team Lead, Kaspersky Lab
— Ольга Моск, редактор, переводчик, менеджер проектов Positive Technologies
— Евгений Зудилин
— Даниил Югославский, волонтер Russians for Ukraine

Архив

Оригинальные сообщения доступны в дискуссионной комнате. Веб-версия обсуждения сохранена для индексации поисковыми системами. Zip-архив обсуждения сохранен для обеспечения целостности (неизменности), которая гарантируется хеш-функцией SHA-256:

$ shasum -a 256 archive/dc_4.zip
4b350895f49ffd77018d75e71e83115142b3c7240f80334c2ba4cdb596f7d49c  archive/dc_4.zip

📩 Подписаться 📩

=== Виртуальная память в Linux. Часть 2. Стек, куча и код ===

В прошлый раз мы увидели, что адресное пространство процесса делится на три части: код, куча и стек. Рассмотрим их подробнее.

- Code. Первая часть адресного пространства. Начинается с 0. Тут содержится код исполняемой программы. Эта часть памяти может быть доступна другим процессам. Ведь таким образом мы можем сэкономить память при запуске нескольких идентичных процессов

- Heap. Начинается сразу после кода и растет вниз. Система заранее не знает сколько памяти нужно выделить по heap. Да и это было бы неэффективно. Поэтому под heap выделяется какая-то инициализационнная часть памяти. Когда процессу понадобится больше памяти для heap, он запросит её у ОС через системный вызов malloc(). Heap эксплицитен. Память для него нужно выделять в программе явно и чистить после себя. Освобождается память системным вызовом free(). В heap хранятся связанные списки, хэш таблицы, деревья и другие структуры данных

- Stack. Начинается с конца адресного пространства и растет вверх. Стек управляется компилятором имплицитно. Поэтому он называется автоматической памятью. Когда функция выполнилась, она вернула значение и компилятор деаллоцировал память. В стеке хранятся локальные переменные, параметры функций и возвращаемые адреса


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

Конечно, адресное пространство - всего лишь абстракция, предоставляемая процессам со стороны ОС. Вся память, которую видит процесс - абстракция. Поэтому она и называется виртуальной памятью (Virtual Memory). Адреса виртуальной памяти указывают на память физическую. Преобразованием виртуальных адресов в физические занимается ОС с помощью различных аппаратных ухищрений

#OS #OSTEP #memory #vm

Каждое ядро CPU имеет два регистра: base (базовый) и bound (граничный).

- В base регистре лежит смещение. Физический адрес = виртуальный адрес + base

- bound регистр указывает на границу физической памяти процесса. Если адрес, к которому обращается процесс выходит за границу, указанную в bound регистре, вызывается исключение и процесс завершашется

Пример:

Address Space Size 4 KB
Loaded in phys address 16 KB
• Virtual Address 0 → Physical Address 16 KB
• VA 1 KB → PA 17 KB
• VA 3000 → PA 19384
• VA 4400 → Fault (out of bounds)

Регистры - часть CPU и работу по релокации делает CPU. Часть процессора, которая занимается работой с памятью называется Memory Management Unit (MMU). Чем сложнее эта работа, тем более сложным будет MMU

Проблемы:
- При создании процесса ОС должна найти место в физ памяти для размещения там адресного пространства процесса. То есть нужно иметь список свободного места (free list)

- После завершения процесса нужно освободить его место в физ памяти и записать обратно в free list

- У ЦПУ только одна пара бэйз-баунд регистров. При конекст свитчинге нужно сохранить куда-то бэйз и баунд текущего процесса и считать откуда-то эти регистры нового процесса. Procss Control Block (PCB)

- Доступ к регистрам привилигрованный. Только кернел режим ОС может ими управлять. Если бы это мог делать обычный процесс, он бы мог перезаписать значения регистров и читать/писать чужую память

- Мы смогли создать независимую память для каждого процесса и изолировать её. Но т.к. аллоцируем всё адресное пространство, то аллоцируемое, но неиспользуемое место между хипом и стеком простаивает впустую, как видно на рис. 15.2. Это называется внутренней фрагментацией

В следующей части попробуем решить эти проблемы

#OS #OSTEP #memory #vm

В обзоре KazHackStan я упоминал доклад Вадима Шелест об инфраструктуре для RedTeam.
А сегодня увидел ссылку на детальный пост о деплое инфры в Linode с помощью Terraform. Пост будет полезен как админам/девопсам, так и безопасникам.

- Знакомые с IaC и Terraform могут найти для себя новое про инфру для RedTeam
- А security специалисты поглубже узнают про IaC

#terraform #redteam #security #nebula #cobaltstrike #caddy #iac

IP адреса Google
https://www.gstatic.com/ipranges/goog.txt
#google #ip #network

=== Виртуальная память в Linux. Часть 4. Сегментация ===

Для предовтарщения внутренней фрагментации можно вместо одной пары регистров использовать три. По паре на каждый сегмент адресного пространства: код, стек, хип

Получаем такую структуру в MMU

Segment | Base | Size
---——----|—------|-------
Code | 32K | 2K
Heap | 34K | 2K
Stack | 28K | 2K

Я не буду пересказывать тут как система обращается к разным сегментам памяти. Интересующиеся могут почитать об этом в книге

Иногда требуется шарить некоторые сегменты между адрес спейсами. Например шаринг сегмента с кодом. Для этого используется protection bit. Выставив его в read-only мы позволим читать из сегмента другим процессам

Итак, сегментация позволила нам не расходовать впустую огромные куски памяти с минимальным оверхедом на трансляцию

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

Другими словами, наша модель использования адресного пространства не совсем соответствует тому, как работает сегментация. Таким образом, нам необходимо найти новые решения

#OS #OSTEP #memory #vm

https://habr.com/ru/company/pt/blog/690716/

#security #bughunt

Слышали про honeypot?
Это специально оставленная брешь в системе, которую с большой вероятностью найдет хакер и наследит там. По этим следам мгновенно будет понятно, что система находится под атакой и админы должны усилить бдительность.

canarytokens - генератор артефактов, при открытии которых приходит алерт на электронную почту

Из артефактов:
- URL
- DNS
- AWS key
- MS Office document
- kubeconfig
- PDF
- EXE/DLL
- WireGuard config
- Дампы баз данных
- ...

#honeypot #security