44% контейнеров живут меньше 5 минут

Написал очень кратий обзор прошедшего KazHackStan. Не удивляйтесь краткости - я не настоящий безопасник.
Но даже для таких, как я было очень интересно:
- про построение DevSecOps и AppSec

- про построение инфраструктуры для RedTeam
Видимо, тут надо пояснить: в больших компаниях служба безопасности делится на две части (или больше): BlueTeam и RedTeam. BlueTeam защищает инфру, тогда как RedTeam это что-то вроде внутренних пентестеров - они стараются пробить защиту

- про тюнинг nginx

- страшные отчеты о захардкоженных сикретах

И другое. Читатйте в блоге, может какие-то инструменты вам пригодятся

#kazhackstan #security

А! Вот ещё что забыл написать

Современные безопасники смеются над тобой, если в качестве MFA у тебя циферки, сгенеренные приложением. Про MFA через СМС даже речи не идет. Не говоря уж о том, что кто-то всё ещё живет без MFA

Ну-ка признавайтесь, как вы тут все ходите в VPN на работу!
А у кого есть хардварный ключик? Я вот задумался о покупке ubikey

И кстати, о перехвате кодов MFA тоже рассказывали на конфе

Коллеги подкинули новую напоминалку по уровням модели OSI:
- Фазан
- Купил
- Сосиску
- Теперь
- Сосёт
- Пи
- Писку

Updated

This webapp helps to find the optimal Google Compute Engine (GCE) machine type or instance in the many Google Cloud Platform (GCP) regions. A lot of information has been collected from various Google Cloud websites and different sources.

https://gcloud-compute.com/

#GCP #Cloud #Google

Шпаргалки для разных инструментов
Краткий список:
- Bash
- Vim
- RegExp
- Python
- Awk
- Docker
- YAML
- Find
- ...

#cheatsheet

Пока вы ищете билеты на самолет, графана выпустила провайдер для управления алертами через терраформ
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