Сидим мы значит... и думаем, а как нам создать структуру DC... та не простую, а наполненную всякими OUшками, пользаками, группами... и всяким - всяким, да чтоб еще "prod-like"
По ощущениям... нужно сидеть и кодить на пшелле, но если честно эта задачка из разряда "западло" (даже с учетом LLM)😂
В итоге я пошел копаться на гите и нашел вот такую красоту:
- https://github.com/BOAScripts/Set-DummyAD
Ну и отдельное спасибо моему коллеге, который поделился еще вот таким "чудом":
- https://github.com/davidprowe/BadBlood
Теперь остается только переписать списки... на слитые "Anonymous France" древнерусских православных юзеров😁
По ощущениям... нужно сидеть и кодить на пшелле, но если честно эта задачка из разряда "западло" (даже с учетом LLM)
В итоге я пошел копаться на гите и нашел вот такую красоту:
- https://github.com/BOAScripts/Set-DummyAD
Ну и отдельное спасибо моему коллеге, который поделился еще вот таким "чудом":
- https://github.com/davidprowe/BadBlood
Теперь остается только переписать списки... на слитые "Anonymous France" древнерусских православных юзеров
Please open Telegram to view this post
VIEW IN TELEGRAM
❤17🔥8😁3
Мне кажется я этим точно должен поделится...
Сидел я тут и искал хорошенький плейлист на M*CTF и наткнулся на этот шедевр😈
- https://www.youtube.com/@AllHackingCons/videos
Тип собрал чуть ли не все "хакерские" форумы / конфы и закину все в один огромный плейлист на ютубчике.
Но на самом деле у него много чего интересного есть еще -> https://infocon.org/
Сидел я тут и искал хорошенький плейлист на M*CTF и наткнулся на этот шедевр
- https://www.youtube.com/@AllHackingCons/videos
Тип собрал чуть ли не все "хакерские" форумы / конфы и закину все в один огромный плейлист на ютубчике.
Но на самом деле у него много чего интересного есть еще -> https://infocon.org/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18❤🔥6🔥5👍1
Знаете... работа с PTLabом научила меня очень интересной мысли.
Я никогда не могу предсказать где и что у меня отстрельнет и сколько времени мне потребуется чтобы это вернуть к жизни, и так... гипотеза:
Тогда мне в голову пришла очень интересная концепция... а что если объединить Chaos Engineering, Grafana, Alert Manager.
В качестве эксперимента... я решил взять своего покемона (без её согласия)... которая замучалась решать различные поломки... что я плодил ей на различных серверах MaxPatrol 10... это и стало так называемым объектом хаоса.
Что-то типо знаете... управляемого хаоса, создай проблему по одной кнопке... и реши примерно так же, "управляемый хаос" как термин звучит очень и очень странно в силу отсутствия субъектности, но надеюсь тут сознание станет самым настоящим ключом.
Я не просто "отключал сервер" - я моделировал реальные отказы компонентов MPX с помощью Ansible, было 2 роли с переключалками (true / false) внутри:
Архитектура была примерно такой:
И знаете... это дало свои плоды, мой покемон выучился и на таких кейсах... довольно круто прокачался в плане траблшутинга, но так и не дошел... до идеи удобного алертинга и мониторинга, на новом исправлю этот недочет...🤣
В целом это и было целью... на "искусственных" примерах поднять экспертизу по траблшутинга продукта, кажется это было весело💖
Я никогда не могу предсказать где и что у меня отстрельнет и сколько времени мне потребуется чтобы это вернуть к жизни, и так... гипотеза:
"Если у нас упадёт X — сможем ли мы вовремя увидеть Y и за какое Z мы это исправим?"
Тогда мне в голову пришла очень интересная концепция... а что если объединить Chaos Engineering, Grafana, Alert Manager.
В качестве эксперимента... я решил взять своего покемона (без её согласия)... которая замучалась решать различные поломки... что я плодил ей на различных серверах MaxPatrol 10... это и стало так называемым объектом хаоса.
Что-то типо знаете... управляемого хаоса, создай проблему по одной кнопке... и реши примерно так же, "управляемый хаос" как термин звучит очень и очень странно в силу отсутствия субъектности, но надеюсь тут сознание станет самым настоящим ключом.
Я не просто "отключал сервер" - я моделировал реальные отказы компонентов MPX с помощью Ansible, было 2 роли с переключалками (true / false) внутри:
ybei_menya_maxpatrol.yml
- Останавливает агента
- Блокирует сетевой доступ к базе событий
- Удаляет конфигурационные файлы парсинга логов
- Имитирует переполнение диска
- Убивает службы на Core сервере в хаотичном порядке
- Создание X процессов на хосте, что забивает ОЗУ / ЦПУ
res_pls_maxpatrol.yml
- Восстанавливает сервисы
- Восстанавливает сетевые доступы к базе событий
- Перезапускает агент
- Проверяет целостность БД
- Подчищает то чем наспамил на хосте
- Убивает X процессы на хосте, ранее созданные для DDoSа
Архитектура была примерно такой:
[Ansible Server]
│
↓ (запускает ybei_menya_maxpatrol.yml)
[MaxPatrol 10: Collector (true), DB (false), ...] → ломается
│
↓ (метрики в Prometheus, логи в Loki)
[Grafana] → срабатывает алерт → уведомление в Telegram
│
↓ (если реакции нет > 1 часа)
[Ansible Server] → запускает res_pls_maxpatrol.yml
│
↓
[MaxPatrol 10] → восстановлен → Grafana показывает возврат к норме
И знаете... это дало свои плоды, мой покемон выучился и на таких кейсах... довольно круто прокачался в плане траблшутинга, но так и не дошел... до идеи удобного алертинга и мониторинга, на новом исправлю этот недочет...
В целом это и было целью... на "искусственных" примерах поднять экспертизу по траблшутинга продукта, кажется это было весело
Please open Telegram to view this post
VIEW IN TELEGRAM
🤓14😁9🔥6😱4❤1
Forwarded from Мишка на сервере (Mikhail Savin)
Подумай перед тем, как задавать вопрос
Привет,
Подумаешь, мелочь – но ведь большая часть коммуникации уже давно ушла в чаты, и на этом поле царят две фракции:
1. Зайчики – уверены, что стоит просто спросить «почему не запускается приложение», и им сразу прилетит точный ответ.
2. Ёжики – считают, что если вопрос неидеальный, можно спокойно отправить вопрошающего "в гугл" и гордо поправить корону эксперта.
И вот парадокс – они оба правы. Да, серьезно. Только с разных сторон.
Зайчик действительно имеет право не знать, но часто не тратит 3 минуты на то, чтобы самому понять контекст вопроса. Ёжик, в свою очередь, тратит часы на "разруливание" чужих неструктурированных вопросов, поэтому и реагирует резко.
В итоге диалог не рождается – вместо обмена смыслами мы получаем пинг-понг усталости.
А что если попробовать по-другому?
Статья HBR "The Art of Asking Smarter Questions" говорит очень простую, но сильную вещь: хорошие вопросы – это такие, которые помогают думать, а не просто получать ответ. Сама сила вопроса не в поиске решения, а в расширении угла обзора.
Вот несколько приемов, над которыми стоит подумать:
- Вместо "почему не работает", спроси "что я уже проверил, и какие предположения остались необъясненными".
- Вместо "как это починить", попробуй "какие у меня могут быть варианты, и какой из них стоит проверить сначала".
- Вместо "что мне делать", спроси "что я, возможно, упускаю в логике своей проверки".
Такой формат не делает вопрос "умным" – он делает тебя вовлеченным в поиск истины.
На этом уровне и зайчики перестают быть наивными, и ёжики – колючими. Потому что разговор становится о сути, а не об эго.
Так что давай честно: думать перед тем, как задать вопрос – не снобизм, а уважение к своему времени и времени других.
А ты как считаешь – вопрос должен быть идеальным, чтобы его задать, или достаточно просто проявить интерес и немного подумать?
#мысливслух #заметкинаполях #мягкиенавыки
Привет,
%username%! Достаточно давно коллега (Никита, привет) закинул одну простую, но редкую мысль: редко кто говорит не просто о том, что "тупых вопросов не бывает", а о том, как вообще стоит задавать вопросы. Подумаешь, мелочь – но ведь большая часть коммуникации уже давно ушла в чаты, и на этом поле царят две фракции:
1. Зайчики – уверены, что стоит просто спросить «почему не запускается приложение», и им сразу прилетит точный ответ.
2. Ёжики – считают, что если вопрос неидеальный, можно спокойно отправить вопрошающего "в гугл" и гордо поправить корону эксперта.
И вот парадокс – они оба правы. Да, серьезно. Только с разных сторон.
Зайчик действительно имеет право не знать, но часто не тратит 3 минуты на то, чтобы самому понять контекст вопроса. Ёжик, в свою очередь, тратит часы на "разруливание" чужих неструктурированных вопросов, поэтому и реагирует резко.
В итоге диалог не рождается – вместо обмена смыслами мы получаем пинг-понг усталости.
А что если попробовать по-другому?
Статья HBR "The Art of Asking Smarter Questions" говорит очень простую, но сильную вещь: хорошие вопросы – это такие, которые помогают думать, а не просто получать ответ. Сама сила вопроса не в поиске решения, а в расширении угла обзора.
Вот несколько приемов, над которыми стоит подумать:
- Вместо "почему не работает", спроси "что я уже проверил, и какие предположения остались необъясненными".
- Вместо "как это починить", попробуй "какие у меня могут быть варианты, и какой из них стоит проверить сначала".
- Вместо "что мне делать", спроси "что я, возможно, упускаю в логике своей проверки".
Такой формат не делает вопрос "умным" – он делает тебя вовлеченным в поиск истины.
На этом уровне и зайчики перестают быть наивными, и ёжики – колючими. Потому что разговор становится о сути, а не об эго.
Так что давай честно: думать перед тем, как задать вопрос – не снобизм, а уважение к своему времени и времени других.
А ты как считаешь – вопрос должен быть идеальным, чтобы его задать, или достаточно просто проявить интерес и немного подумать?
#мысливслух #заметкинаполях #мягкиенавыки
Harvard Business Review
The Art of Asking Smarter Questions
With organizations of all sorts facing increased urgency and unpredictability, being able to ask smart questions has become key. But unlike lawyers, doctors, and psychologists, business professionals are not formally trained on what kinds of questions to…
❤🔥19❤7👍2🌭1
Ну что сказать... кажется можно подвести итоги этого года...
Декабрь выдался... каким-то безумным на события, та и в целом как и весь год.
Мы провели M*CTF и знаете... провели его... во многом выше всех своих ожиданий, это было здорово, надеюсь это не был наш пик, в следующем году... сделаем еще круче😁
Спасибо большое всем ребятам, что участвовали в разработке и помогали нам организационно, думаю мы правда в этом году молодцы.
А касательно... каких-то личных итогов, многое было...
- Приглашение в IBM / RHEL
- Личное знакомство с ДеХаном и ряда очень и очень крутых экспертов
- Мой любимый PTLab и надеюсь новая фаза его развития
- Автоматизация источников
- Закончился проект который было очень сложно отпускать
- Началось что-то действительно очень крутое и новое
Короче... давайте уже по традиции этого канала:
- Спасибо всем, кто читает и интересуется всем, что тут происходит, я думаю у нас с вами много крутого впереди💖
- Я думаю все будет круто😻
- С наступающим вас, будьте умничками :3🕺
Декабрь выдался... каким-то безумным на события, та и в целом как и весь год.
Мы провели M*CTF и знаете... провели его... во многом выше всех своих ожиданий, это было здорово, надеюсь это не был наш пик, в следующем году... сделаем еще круче
Спасибо большое всем ребятам, что участвовали в разработке и помогали нам организационно, думаю мы правда в этом году молодцы.
А касательно... каких-то личных итогов, многое было...
- Приглашение в IBM / RHEL
- Личное знакомство с ДеХаном и ряда очень и очень крутых экспертов
- Мой любимый PTLab и надеюсь новая фаза его развития
- Автоматизация источников
- Закончился проект который было очень сложно отпускать
- Началось что-то действительно очень крутое и новое
Короче... давайте уже по традиции этого канала:
"местами даже хорошо... что он подходит к концу."
- Спасибо всем, кто читает и интересуется всем, что тут происходит, я думаю у нас с вами много крутого впереди
- Я думаю все будет круто
- С наступающим вас, будьте умничками :3
Please open Telegram to view this post
VIEW IN TELEGRAM
🎄36❤19❤🔥12
This media is not supported in your browser
VIEW IN TELEGRAM
Чтож... потихоньку начинаем публиковать труд, который пережил кучу итераций и мнение множества экспертов...
Сейчас хоть не стыдно показать😮
➡️ PT_LEP_Unix
Роль для настройки на источниках формата событий, правил журналирования, служб журналирования (rsyslog или syslog-ng) и отправки событий syslog через audispd.
➡️ PT_dc_policy
Роль предназначена для добавления следующих политик на контроллерах домена (DC):
- PT_Event_LogReader - политика для сбора событий с целевых хостов, добавления группы MaxPatrol Group LogReader (в ней содержится пользователь под которым идет сбор логов) в локальную группу Event Log Readers.
- PT_Registry_Audit_Settings - политика настройки SACL для записи событий доступа к реестру.
- PT_DC_Audit_Settings - политика настройки контроллеров домена под аудит.
Параметры AAP для контроллеров домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- Включение аудита LDAP-запросов.
- PT_WS_Audit_Settings - политика настройки WS-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_SRV_Audit_Settings - политика настройки Server-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_Firewall_Rules - политика добавления Firewall правил.
- PT_WS_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на WS-хостах.
- PT_SRV_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на Server-хостах.
- PT_DC_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на DC-хостах.
Создание пользователей:
- Для сбора логов с хоста с дальнейшим добавлением в группу Event Log Readers.
- Для аудита системы с дальнейшим добавлением в группу локального администратора.
- Создание спец.группы для работы с пользователем сбора логов.
- PT_file_and_folder_Generic - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры и члены домена).
- PT_file_and_folder_SYSVOL - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры домена).
Пхпхпх... да... там нет Meta и нет описания зависимостей, ближе к полному релизу... допилю все по феншую😌
Еще новостей...
- На роль PT_LEP_Unix скоро заедет большой патч... в целом я надеюсь мы скоро сможем перейти на более удобную форму распространения ролей...
- В документации скоро появится еще парочка ролей которые я наклепал за все это время... а вероятно скоро увидим и вообще все... что было сделано за это время
Сейчас хоть не стыдно показать
Роль для настройки на источниках формата событий, правил журналирования, служб журналирования (rsyslog или syslog-ng) и отправки событий syslog через audispd.
Роль предназначена для добавления следующих политик на контроллерах домена (DC):
- PT_Event_LogReader - политика для сбора событий с целевых хостов, добавления группы MaxPatrol Group LogReader (в ней содержится пользователь под которым идет сбор логов) в локальную группу Event Log Readers.
- PT_Registry_Audit_Settings - политика настройки SACL для записи событий доступа к реестру.
- PT_DC_Audit_Settings - политика настройки контроллеров домена под аудит.
Параметры AAP для контроллеров домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- Включение аудита LDAP-запросов.
- PT_WS_Audit_Settings - политика настройки WS-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_SRV_Audit_Settings - политика настройки Server-хостов под аудит.
Параметры AAP для членов домена:
- Увеличение размера хранения журналов и автоматическая перезапись событий.
- Добавление разрешения для службы NETWORK SERVICE на чтение журнала Security.
- Принудительное применение параметров расширенного аудита.
- Включение журналирования командной строки в событиях старта процессов.
- Включение журналирования исполняемого PowerShell-кода.
- PT_Firewall_Rules - политика добавления Firewall правил.
- PT_WS_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на WS-хостах.
- PT_SRV_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на Server-хостах.
- PT_DC_Audit_User - политика добавления специальной группы MaxPatrol Group AuditUser для проведения аудита системы на DC-хостах.
Создание пользователей:
- Для сбора логов с хоста с дальнейшим добавлением в группу Event Log Readers.
- Для аудита системы с дальнейшим добавлением в группу локального администратора.
- Создание спец.группы для работы с пользователем сбора логов.
- PT_file_and_folder_Generic - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры и члены домена).
- PT_file_and_folder_SYSVOL - политика настройки SACL для записи событий доступа к файлам и каталогам (Контроллеры домена).
Пхпхпх... да... там нет Meta и нет описания зависимостей, ближе к полному релизу... допилю все по феншую
Еще новостей...
- На роль PT_LEP_Unix скоро заедет большой патч... в целом я надеюсь мы скоро сможем перейти на более удобную форму распространения ролей...
- В документации скоро появится еще парочка ролей которые я наклепал за все это время... а вероятно скоро увидим и вообще все... что было сделано за это время
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18❤🔥10🎉4
Каждый раз, когда я запускал роль для развертывания + конфигурации Linux VM, Ansible думает по 15 минут. А если нужно было поднять 10+ хостов - уходит час из жизни... SSH-сессии, перезагрузки модулей, простаивающие в очереди таски… пхпхпхпхп это не автоматизация, а психотерапия с таймером.. 😢
И кажется этот момент настал... порылся в гугле, перепробовал разные стратегии... и нашел наверное самое лучшее -> Mitogen - стратегия, которая ускоряет Ansible в 3 - 10 раз.
Почему это крутотень?
1) Одно SSH-соединение вместо тысячи - Ansible традиционно открывает новую сессию для каждой задачи Mitogen оставляет один канал открытым и гоняет через него все задачи.
2) Кэширование "на лету" - модули (типа copy или file) грузятся один раз, а не по 50.
3) Параллельность работает КАК И ДОЛЖНА РАБОТАТЬ - хосты не стоят в очереди... Mitogen динамически распределяет задачи между активными соединениями -> медленные серверы не тянут за собой все.
На самом деле поюзав этого зверя... я скостил разворачивание и конфигурацию хостов с 15-и минут аж до 6 на 1 хост, пачка и совсем за ~20 минут настраивается...
Есть конечно проблемки... Mitogen работает не на все модули, но кто нам мешает допилить😊
В общем... всем кто работает с Ansible, настоятельно рекомендую... да да
➡️ Github / Документация
И кажется этот момент настал... порылся в гугле, перепробовал разные стратегии... и нашел наверное самое лучшее -> Mitogen - стратегия, которая ускоряет Ansible в 3 - 10 раз.
Почему это крутотень?
1) Одно SSH-соединение вместо тысячи - Ansible традиционно открывает новую сессию для каждой задачи Mitogen оставляет один канал открытым и гоняет через него все задачи.
2) Кэширование "на лету" - модули (типа copy или file) грузятся один раз, а не по 50.
3) Параллельность работает КАК И ДОЛЖНА РАБОТАТЬ - хосты не стоят в очереди... Mitogen динамически распределяет задачи между активными соединениями -> медленные серверы не тянут за собой все.
На самом деле поюзав этого зверя... я скостил разворачивание и конфигурацию хостов с 15-и минут аж до 6 на 1 хост, пачка и совсем за ~20 минут настраивается...
Есть конечно проблемки... Mitogen работает не на все модули, но кто нам мешает допилить
В общем... всем кто работает с Ansible, настоятельно рекомендую... да да
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15👍4🔥3👀1
Сегодня с коллегой словили довольно занятный кейс 💃
Решили на Windows 11 24H2 (OS build 26100) снять дамп LSASS. Казалось бы - рутина, никаких сюрпризов. Отключаешь Defender, вырубаешь PPL и идёшь дальше жить спокойно
Но не тут-то было
Под админом - access denied
Ладно, думаем, может SeDebugPrivilege не хватило
Пробуем уже из под SYSTEM - там-то прав точно должно быть с запасом
И снова access denied😳 😳 😳 😳 😳
Вот тут я слегка приуныл...
На десятке с таким не сталкивался: базово отключил Defender + PPL - и LSASS дампится без плясок с бубном... а тут - внезапно стена.
Поковырялись, потыкались, и в итоге решил пойти по максимально злому пути:
"если непонятно, что именно мешает - проще снести всё к чертям, протестить, а потом откатить назад"🤣
В процессе наткнулся на вот такого зверя:
🤯 https://github.com/ionuttbara/windows-defender-remover
Инструмент, конечно, топорный, но задачу свою выполнил на отлично - после прогона дамп LSASS спокойно снялся
Вот такой любопытный кейс с Windows 11
Надо будет отдельно разобраться, что именно в 11-ой блокирует дамп даже при базовом отключении Defender и PPL - явно там что-то ещё под капотом, но вот что пока не очень понимаю😳
Решили на Windows 11 24H2 (OS build 26100) снять дамп LSASS. Казалось бы - рутина, никаких сюрпризов. Отключаешь Defender, вырубаешь PPL и идёшь дальше жить спокойно
Но не тут-то было
Под админом - access denied
Ладно, думаем, может SeDebugPrivilege не хватило
Пробуем уже из под SYSTEM - там-то прав точно должно быть с запасом
И снова access denied
Вот тут я слегка приуныл...
На десятке с таким не сталкивался: базово отключил Defender + PPL - и LSASS дампится без плясок с бубном... а тут - внезапно стена.
Поковырялись, потыкались, и в итоге решил пойти по максимально злому пути:
"если непонятно, что именно мешает - проще снести всё к чертям, протестить, а потом откатить назад"
В процессе наткнулся на вот такого зверя:
Инструмент, конечно, топорный, но задачу свою выполнил на отлично - после прогона дамп LSASS спокойно снялся
Вот такой любопытный кейс с Windows 11
Надо будет отдельно разобраться, что именно в 11-ой блокирует дамп даже при базовом отключении Defender и PPL - явно там что-то ещё под капотом, но вот что пока не очень понимаю
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👍6🤔3☃1
Forwarded from Мишка на сервере (Mikhail Savin)
SREGame: живой CTF по SRE вместо скучных учебников
Привет,
Вместо симуляций тебе дают доступ к настоящему окружению: лезешь в конфиги, смотришь логи и трафик, ищешь флаги, разбираешься, почему всё упало и как это починить. По сути, это CTF в формате «боевых дежурств»: меньше теории, больше реального hands-on, который можно потом конвертировать в улучшения своих процессов, алертов и runbook’ов.
Такой формат отлично заходит:
- SRE/DevOps, которые хотят прокачать навыки расследования инцидентов без боли продакшена.
- Тимлидам и техлидам, которым нужен практический тренажёр для команды вместо абстрактных тренингов.
- Инженерам эксплуатации, которые хотят потренироваться «копать глубже»: от сети и конфигураций до приложений и инфраструктуры.
Мне нравится идея использовать подобный сервис как внутренний «полигон»: можно устраивать регулярные CTF-сессии, отрабатывать on-call сценарии, шлифовать процессы эскалации и совместно улучшать документацию и знания команды.
А как ты учишь команду разбирать инциденты: разборы полётов на сухих постмортемах или практические разборы в песочнице? Хотел(а) бы поучаствовать в таком SRE CTF сам(а) или дать его джунам/мидлам как часть онбординга? Какие форматы «боевого» обучения SRE тебе заходят лучше всего и почему?
#SRE #DevOps #OnCall #Incidents #CTF #Education #SREGame
Привет,
%username%! Если тебе надоели теоретические статьи про SRE и хочется «потрогать прод» без риска всё уронить, обрати внимание на SREGame — сервис с живым sandbox-окружением, где ты расследуешь инциденты как в реальной жизни.Вместо симуляций тебе дают доступ к настоящему окружению: лезешь в конфиги, смотришь логи и трафик, ищешь флаги, разбираешься, почему всё упало и как это починить. По сути, это CTF в формате «боевых дежурств»: меньше теории, больше реального hands-on, который можно потом конвертировать в улучшения своих процессов, алертов и runbook’ов.
Такой формат отлично заходит:
- SRE/DevOps, которые хотят прокачать навыки расследования инцидентов без боли продакшена.
- Тимлидам и техлидам, которым нужен практический тренажёр для команды вместо абстрактных тренингов.
- Инженерам эксплуатации, которые хотят потренироваться «копать глубже»: от сети и конфигураций до приложений и инфраструктуры.
Мне нравится идея использовать подобный сервис как внутренний «полигон»: можно устраивать регулярные CTF-сессии, отрабатывать on-call сценарии, шлифовать процессы эскалации и совместно улучшать документацию и знания команды.
А как ты учишь команду разбирать инциденты: разборы полётов на сухих постмортемах или практические разборы в песочнице? Хотел(а) бы поучаствовать в таком SRE CTF сам(а) или дать его джунам/мидлам как часть онбординга? Какие форматы «боевого» обучения SRE тебе заходят лучше всего и почему?
#SRE #DevOps #OnCall #Incidents #CTF #Education #SREGame
❤🔥7🔥2
Сегодня со мной произошло маленькое профессиональное "чудо" 🫠
Я наконец-то применил знания, полученные на сертификации RHCSA… спустя 6 лет
Иногда кажется, что половина того, что учишь, так и останется «на всякий случай».
А потом наступает тот самый рабочий кейс - и ты понимаешь, зачем всё это было😳
🟠 Притча о том, как я RAID воскрешал (почти)
Я наконец-то применил знания, полученные на сертификации RHCSA… спустя 6 лет
Иногда кажется, что половина того, что учишь, так и останется «на всякий случай».
А потом наступает тот самый рабочий кейс - и ты понимаешь, зачем всё это было
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥19❤8👏3🤩1🐳1
Хочу в 4 утра поделится с вами двумя вещицами:
🔊 Awesome Black Hat Arsenal
По сути это такой "священный свиток тёмной магии", только без необходимости смотреть трёхчасовой доклад с Black Hat, где чувак в худи с видом «я сейчас переверну индустрию» в конце слайда невнятно показывает ссылку на GitHub.
Это "awesome-list" для red team / pentest / exploit dev, аккуратно собранный из тулзов, которые всплывали на конференциях Black Hat.
То есть вместо сценария:
"О боже, Кенни, он опять выложил "революционный" фреймворк!"
- Погнали вручную перебивать ссылку с YouTube, пока автор листает слайд 0.7 секунды.
Ты получаешь:
"О, смотри, уже всё собрано... категории есть... инструменты есть... ссылки кликабельные (но не все😏 )... можно жить."
🪟 CVE2CAPEC
Тут мне если честно лень придумывать такое же красивое описание... поэтому я просто дам идею и описание тулы... как я это юзаю.
CVE2CAPEC - это утилита/датасет для сопоставления уязвимостей из базы MITRE с шаблонами атак CAPEC.
Идея тут такая - перевести конкретную уязвимость (CVE) в более общий "паттерн атаки" (CAPEC), чтобы понять к какому классу атак она относится.
Юзал для составления сценариев... вроде даже помогало.
По сути это такой "священный свиток тёмной магии", только без необходимости смотреть трёхчасовой доклад с Black Hat, где чувак в худи с видом «я сейчас переверну индустрию» в конце слайда невнятно показывает ссылку на GitHub.
Это "awesome-list" для red team / pentest / exploit dev, аккуратно собранный из тулзов, которые всплывали на конференциях Black Hat.
То есть вместо сценария:
"О боже, Кенни, он опять выложил "революционный" фреймворк!"
- Погнали вручную перебивать ссылку с YouTube, пока автор листает слайд 0.7 секунды.
Ты получаешь:
"О, смотри, уже всё собрано... категории есть... инструменты есть... ссылки кликабельные (но не все
Тут мне если честно лень придумывать такое же красивое описание... поэтому я просто дам идею и описание тулы... как я это юзаю.
CVE2CAPEC - это утилита/датасет для сопоставления уязвимостей из базы MITRE с шаблонами атак CAPEC.
Идея тут такая - перевести конкретную уязвимость (CVE) в более общий "паттерн атаки" (CAPEC), чтобы понять к какому классу атак она относится.
Юзал для составления сценариев... вроде даже помогало.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥13😭2
Довольно долго практикую такую вещь - выкладываю все мысли на бумагу или схемы
Очень круто помогает разгружать мозги.
Один знакомый тут заметил у меня заметочки в обсидиане... попросил выкидывать в какую-то группу.
Без понятия чем это может быть кому-то полезно, но держите, мало ли интересно.
➡️ Link
Сюда это писать не хочется, ибо кажется, что совсем не формат.
Очень круто помогает разгружать мозги.
Один знакомый тут заметил у меня заметочки в обсидиане... попросил выкидывать в какую-то группу.
Без понятия чем это может быть кому-то полезно, но держите, мало ли интересно.
Сюда это писать не хочется, ибо кажется, что совсем не формат.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13💩1🐳1
Forwarded from Golden HackSpace | Hacker notes
🔥 Ludus: Автоматизация деплоя лабораторных сред
Ludus — инструмент для создания автоматизированных лабораторных сред. Позволяет быстро разворачивать и управлять тестовыми средами для практики атак.
🌐 Официальный сайт
📦 GitLab
📚 Руководства
Связанные проекты Ludus:
1. LudusHound
Позволяет реплицировать инфраструктуру, используя данные из BloodHound.
https://specterops.io/blog/2025/07/14/ludushound-raising-bloodhound-attack-paths-to-life/
https://github.com/bagelByt3s/LudusHound
2. Деплой C2 в Ludus
C2-сервер для использования в лабораторных средах.
https://github.com/badsectorlabs/ludus_adaptix_c2
https://github.com/0xRedpoll/ludus_cobaltstrike_teamserver
3. Специализированные лаборатории
Специализированные лаборатории для изучения атак на отдельные сервисы.
SCCM: https://github.com/Synzack/ludus_sccm
ADCS: https://github.com/badsectorlabs/ludus_adcs
SCOM: https://github.com/Synzack/ludus_scom
#lab #ludus #redteam
Ludus — инструмент для создания автоматизированных лабораторных сред. Позволяет быстро разворачивать и управлять тестовыми средами для практики атак.
🌐 Официальный сайт
📦 GitLab
📚 Руководства
Связанные проекты Ludus:
1. LudusHound
Позволяет реплицировать инфраструктуру, используя данные из BloodHound.
https://specterops.io/blog/2025/07/14/ludushound-raising-bloodhound-attack-paths-to-life/
https://github.com/bagelByt3s/LudusHound
2. Деплой C2 в Ludus
C2-сервер для использования в лабораторных средах.
https://github.com/badsectorlabs/ludus_adaptix_c2
https://github.com/0xRedpoll/ludus_cobaltstrike_teamserver
3. Специализированные лаборатории
Специализированные лаборатории для изучения атак на отдельные сервисы.
SCCM: https://github.com/Synzack/ludus_sccm
ADCS: https://github.com/badsectorlabs/ludus_adcs
SCOM: https://github.com/Synzack/ludus_scom
#lab #ludus #redteam
🤔2🐳1
Forwarded from Мишка на сервере (Mikhail Savin)
Почему 100% Uptime — это иллюзия, и при чем тут демон Лапласа?
Привет,
Пьер-Симон Лаплас придумал гипотетическое существо (сверхразум), которое в любой момент времени знает точное положение и скорость абсолютно каждого атома во Вселенной, а также все действующие на них силы. Обладая такими данными, этот демон мог бы безошибочно предсказывать будущее. В его мире нет случайностей, только строгая закономерность.
Так вот, чтобы гарантировать 100% Uptime сложной распределенной системы, инженеру нужно буквально стать таким демоном Лапласа. Тебе пришлось бы заранее знать:
- Точное состояние каждого транзистора, диска и кулера на тысячах серверов;
- Маршрут и судьбу каждого сетевого пакета от мобилки пользователя до твоего балансировщика;
- Любую, даже самую безумную комбинацию пользовательского ввода;
- Случайные космические лучи, меняющие биты в памяти (bit flip), и вероятность того, что пьяный экскаваторщик перерубит магистральный кабель провайдера.
Поскольку мы не обладаем всеведением, в наших системах всегда живет хаос. В физике квантовая механика давно доказала, что демон Лапласа невозможен из-за принципа неопределенности. В нашей профессии аналогом этого закона выступает простая истина: сбои неизбежны, а энтропия всегда растет.
Именно поэтому в SRE мы осознанно отказываемся от идеи 100% надежности:
- Мы устанавливаем реалистичные SLO (например, 99.9%), чтобы честно зафиксировать допустимый уровень отказов и не обманывать ни себя, ни клиентов;
- Мы используем Error Budgets, признавая, что оставшиеся доли процента — это легальное пространство для хаоса, а также наш бюджет на релизы и эксперименты;
- Вместо попыток предвидеть вообще всё, мы строим устойчивые к отказам системы и снижаем MTTR, чтобы падать безопасно и восстанавливаться быстро.
Отказ от 100% Uptime — это не инженерная слабость. Это зрелое понимание законов природы и устройства сложных систем.
А как у тебя обстоят дела с ожиданиями бизнеса? Приходилось ли тебе отговаривать стейкхолдеров от SLA в 100% и какие аргументы ты для этого использовал? Какой самый непредсказуемый сбой или "черный лебедь" разрушил твой идеальный аптайм? Делись историями в комментариях!
#SRE #DevOps #Observability #incidents #ErrorBudget #SLO #SiteReliabilityEngineering #Architecture
Привет,
%username%! В работе SRE и при проектировании систем часто приходится сталкиваться с утопичным требованием бизнеса: «Наш сервис должен работать всегда, нам нужен 100% SLA». Звучит как отличная амбициозная цель, но на практике она недостижима. И чтобы изящно объяснить почему, отлично подходит мысленный эксперимент из начала XIX века — концепция демона Лапласа.Пьер-Симон Лаплас придумал гипотетическое существо (сверхразум), которое в любой момент времени знает точное положение и скорость абсолютно каждого атома во Вселенной, а также все действующие на них силы. Обладая такими данными, этот демон мог бы безошибочно предсказывать будущее. В его мире нет случайностей, только строгая закономерность.
Так вот, чтобы гарантировать 100% Uptime сложной распределенной системы, инженеру нужно буквально стать таким демоном Лапласа. Тебе пришлось бы заранее знать:
- Точное состояние каждого транзистора, диска и кулера на тысячах серверов;
- Маршрут и судьбу каждого сетевого пакета от мобилки пользователя до твоего балансировщика;
- Любую, даже самую безумную комбинацию пользовательского ввода;
- Случайные космические лучи, меняющие биты в памяти (bit flip), и вероятность того, что пьяный экскаваторщик перерубит магистральный кабель провайдера.
Поскольку мы не обладаем всеведением, в наших системах всегда живет хаос. В физике квантовая механика давно доказала, что демон Лапласа невозможен из-за принципа неопределенности. В нашей профессии аналогом этого закона выступает простая истина: сбои неизбежны, а энтропия всегда растет.
Именно поэтому в SRE мы осознанно отказываемся от идеи 100% надежности:
- Мы устанавливаем реалистичные SLO (например, 99.9%), чтобы честно зафиксировать допустимый уровень отказов и не обманывать ни себя, ни клиентов;
- Мы используем Error Budgets, признавая, что оставшиеся доли процента — это легальное пространство для хаоса, а также наш бюджет на релизы и эксперименты;
- Вместо попыток предвидеть вообще всё, мы строим устойчивые к отказам системы и снижаем MTTR, чтобы падать безопасно и восстанавливаться быстро.
Отказ от 100% Uptime — это не инженерная слабость. Это зрелое понимание законов природы и устройства сложных систем.
А как у тебя обстоят дела с ожиданиями бизнеса? Приходилось ли тебе отговаривать стейкхолдеров от SLA в 100% и какие аргументы ты для этого использовал? Какой самый непредсказуемый сбой или "черный лебедь" разрушил твой идеальный аптайм? Делись историями в комментариях!
#SRE #DevOps #Observability #incidents #ErrorBudget #SLO #SiteReliabilityEngineering #Architecture
👍5❤3👎2🔥1🐳1
Боже, как мне надоело, что про этот ИИ вокруг все говорят и говорят...
Куда ни зайдешь - везде одно и то же: "ИИ заменит админов", "ИИ напишет всё за тебя","ИИ теперь DevOps", "ИИ умеет в Ansible лучше людей".
И каждый раз звучит так, будто завтра можно просто отдать ему доступы в прод и уйти пить кофе😏
Но тут попалось видео Learn Linux TV, где автор нормально проверяет Claude Code на реальном Ansible-проекте.
Не на игрушечном "установи nginx" (кто-то вообще на других примерах ansible показывает?!!), а на более менее приемлемой домашней лаборатории.
И вот тут стало интереснее... я посмотрел на это все... и решил повторить на своей домашней инфре😳
Claude Code реально смог разобраться в структуре проекта, понять, где что лежит, предложить изменения, поправить существующие playbookи и в целом вести себя не как генератор случайного YAML, а как помощник, который умеет копаться в кодовой базе, ну и README он хорошо написал по моему шаблону.
Но магии, конечно, не случилось.
В какой-то момент он попытался создать новый playbook для того, что уже было реализовано в проекте... то есть классическая история... вроде умный, вроде помогает, но без ревью может наделать лишнего или вообще увести не туда.
И, честно, вывод такой: ИИ - это не замена системному администратору и не волшебная кнопка "сделай инфраструктуру".
Это скорее очень быстрый джун, которому можно дать задачу, но потом обязательно проверить, что он там наворотил☕️
Для Ansible, рефакторинга, поиска по проекту, черновиков задач и рутины - да, полезно...
Для "вот тебе прод, делай что хочешь, лишь бы оно работало" - нет, спасибо, я еще жить хочу...
Короче, ИИ не отменяет знания... он просто делает боль чуть менее больной, если рядом есть человек, который понимает, что именно надо проверить.
Связка понимающий специалист + AI агент - выглядит очень мощно
Связка джун + AI агент - выглядит очень и очень опасно для всего, до чего дотянется AI агент
Недавно еще получил доступ к AIOps от RHEL, потыкаюсь... может мнение изменится в лучшую сторону... но пока ощущение черного ящика никуда не уходит...
p.s. но ai-connect от ansible, действительно удобная штука... тут придраться сложно, так что всем кто активно юзает ansible - рекомендую
Куда ни зайдешь - везде одно и то же: "ИИ заменит админов", "ИИ напишет всё за тебя","ИИ теперь DevOps", "ИИ умеет в Ansible лучше людей".
И каждый раз звучит так, будто завтра можно просто отдать ему доступы в прод и уйти пить кофе
Но тут попалось видео Learn Linux TV, где автор нормально проверяет Claude Code на реальном Ansible-проекте.
Не на игрушечном "установи nginx" (кто-то вообще на других примерах ansible показывает?!!), а на более менее приемлемой домашней лаборатории.
И вот тут стало интереснее... я посмотрел на это все... и решил повторить на своей домашней инфре
Что я понял?
Claude Code реально смог разобраться в структуре проекта, понять, где что лежит, предложить изменения, поправить существующие playbookи и в целом вести себя не как генератор случайного YAML, а как помощник, который умеет копаться в кодовой базе, ну и README он хорошо написал по моему шаблону.
Но магии, конечно, не случилось.
В какой-то момент он попытался создать новый playbook для того, что уже было реализовано в проекте... то есть классическая история... вроде умный, вроде помогает, но без ревью может наделать лишнего или вообще увести не туда.
И, честно, вывод такой: ИИ - это не замена системному администратору и не волшебная кнопка "сделай инфраструктуру".
Это скорее очень быстрый джун, которому можно дать задачу, но потом обязательно проверить, что он там наворотил
Для Ansible, рефакторинга, поиска по проекту, черновиков задач и рутины - да, полезно...
Для "вот тебе прод, делай что хочешь, лишь бы оно работало" - нет, спасибо, я еще жить хочу...
Короче, ИИ не отменяет знания... он просто делает боль чуть менее больной, если рядом есть человек, который понимает, что именно надо проверить.
Связка понимающий специалист + AI агент - выглядит очень мощно
Связка джун + AI агент - выглядит очень и очень опасно для всего, до чего дотянется AI агент
Недавно еще получил доступ к AIOps от RHEL, потыкаюсь... может мнение изменится в лучшую сторону... но пока ощущение черного ящика никуда не уходит...
p.s. но ai-connect от ansible, действительно удобная штука... тут придраться сложно, так что всем кто активно юзает ansible - рекомендую
Please open Telegram to view this post
VIEW IN TELEGRAM
❤21😢6🔥1🐳1
Пришли ко мне с одной задачкой... ну я за неё и сел... ☕️
Обожаю Windows, обожаю ACL, обожаю права, обожаю атрибуты, обожаю моменты, когда ты вроде бы всё понял, а потом AD такая:
"Не-не-не, ты понял не всё старина"
Разбирался с dMSA при тестировании BadSuccessor-like сценариев и внезапно уперся в очень показательный нюанс... в общем вот..
🟠 Притча о том, как я разбирался с dMSA при тестировании BadSuccessor-like сценариев
Обожаю Windows, обожаю ACL, обожаю права, обожаю атрибуты, обожаю моменты, когда ты вроде бы всё понял, а потом AD такая:
"Не-не-не, ты понял не всё старина"
Разбирался с dMSA при тестировании BadSuccessor-like сценариев и внезапно уперся в очень показательный нюанс... в общем вот..
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5❤🔥2👍1🔥1🤣1
24 июля в 15:30 в Московском офисе Positive Technologies пройдет митап для начинающих специалистов. Это возможность познакомиться с коллегами Позитива, различными направлениями в компании и послушать реальный опыт коллег.
В программе:
➡️ Владимир Николаев, эксперт PT Lab, погрузит во внутрянку агентов Caldera
➡️ Андрей Михайлов, младший инженер PT Lab, расскажет, как создаются лабораторные стенды для практики
➡️ Евгений Копытин, специалист отдела анализа защищенности веб-приложений, раскроет полный потенциал SSRF
➡️ Приглашенный Спикер и тема останутся сюрпризом 🫥
А еще будет экскурсия по офису, пицца, призы за лучшие вопросы и неформальное общение🍕
Заполни форму регистрации по ссылке, если собираешься прийти
До встречи на митапе!🙂
В программе:
А еще будет экскурсия по офису, пицца, призы за лучшие вопросы и неформальное общение
Заполни форму регистрации по ссылке, если собираешься прийти
🟥 Важно: количество мест ограничено, после регистрации дождись письма с подтверждением участия и подробностями мероприятия
До встречи на митапе!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👎1
Для тех кто пропустил наш митап 😁
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ITAM
Готов прокачать скиллы в практической безопасности и узнать, как работают топовые эксперты индустрии? Открываем новый сезон мощным митапо, только разборы реальных кейсов и карьерный трек в ИБ.
Что тебя ждёт?
Здесь вы точно найдете что-то интересное для себя
Артемий Цецерский, амбассадор Standoff, эксперт отдела исследования киберугроз в Angara Security
Иван Булавин, директор платформы Standoff
Владимир Николаев, руководитель команды PTLab Positive Technologies, капитан команды BinaryBears
Андрей Кавыкин, руководитель подгруппы управления событиями ИБ Ozon
Не упусти шанс прокачаться в кибербезопасности и лично пообщаться с экспертами.
Регистрация для внешних участников доступна по ссылке. А также не забудь захватить с собой паспорт. Студентам Университета МИСИС регистрироваться не нужно.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6