CodeGuard: PySec Edition

Вам сюда лить Shorts или ток на ютуб? 👍 — да, конечно ❤️ — не, тут и так много всего 😈 CodeGuard: PySec Edition | Чат

🔍 Как за 5 минут проверить, не утекли ли секреты с твоего сайта Классика жанра: разработчик забыл закрыть .env или .git, и теперь API-ключи, пароли от БД и токены лежат в открытом доступе. Проверяется элементарно. 1️⃣ Открой site.com/.env — если отдаёт файл, ты в беде 2️⃣То же самое с /.git/config и /.git/HEAD 3️⃣Чекни по списку: /backup.zip, /db.sql, /.DS_Store, /config.php.bak 4️⃣Прогони через dork: site:site.com ext:env (и ext:sql, ext:log) 5️⃣Нашлось что-то живое — срочно ротируй ключи и закрывай доступ Для массовой проверки — nuclei с темплейтами на exposures, либо httpx + свой список путей. Работает против 90% сайтов. Проверь свой — потом расскажи, что нашёл 👀 😈 CodeGuard: PySec Edition | Чат

🖥Если ты хочешь обучиться вайбкодингу и при этом иметь возможность провести аудит безопасности своего продукта, то тебе сюда: Lab IT — репозитории, полезные инструменты, курсы и многое другое по Айти: ЭЙ, АЙ! — бесплатные инструменты, репозитории, обучающие материалы для упрощения работы с ИИ. ИИ тебя взломает — объединит твои навыки в ИБ с ИИ CyberGuard — оплот для ИБ-специалистов со всего телеграма. Тут ты точно узнаешь, как не оплошаться с запуском своего продукта, и защитить его от злоумышленников 🫵Подписывайся и обучайся!

💣 DDoS-атаки — когда сервис валят толпой DDoS — логичное продолжение DoS, но уже на другом уровне. Если DoS — это один источник, то DDoS — это тысячи и миллионы узлов, которые одновременно давят цель, пока она не перестаёт отвечать. Что важно знать: 📌 Что это такое:

🔴DDoS (Distributed Denial of Service) — распределённая атака, при которой трафик идёт сразу с множества источников: ботнетов, заражённых серверов, IoT-устройств.

📌 Как выглядит:

🔴

Запросы летят с тысяч IP из разных стран, сетей и ASN.

🔴

В логах это выглядит как «нормальный» трафик, но в ненормальных объёмах.

📌 Почему сложнее защищаться:

🔴

Блокировка одного IP не решает ничего.

🔴

Нужно фильтровать по поведению, протоколам, типам запросов, а иногда резать целые регионы и подсети.

📌 Какие бывают:

🔴

volumetric — забивают канал (Gbps/Tbps);

🔴

protocol — ломают стек (SYN, UDP, ICMP);

🔴

application-layer — бьют по HTTP/API, имитируя живых пользователей.

📌 Где бьёт больнее всего:

🎯

онлайн-сервисы, банки, игры, маркетплейсы, госресурсы, API без rate-limit.

Короче говоря 🗣:DDoS — это не «сломать», а утопить сервис в трафике. Код может быть идеальным, но без защиты инфраструктура ляжет первой. 😈 CodeGuard: PySec Edition | Чат

🔥 Это мой первый полноценный ролик на YouTube, строго не судите. В этом видео мы больше поговорили и собрали понятную дорожную карту для новичков в ИБ: что изучать, в каком порядке двигаться и где получать практику, чтобы не тратить время впустую. Если ролик оказался полезным — поддержите лайком. Дальше буду стараться, делать более полезную инфу https://youtu.be/Xbiqrt9UJjo https://youtu.be/Xbiqrt9UJjo https://youtu.be/Xbiqrt9UJjo Приятного просмотра! 📌 Полная дорожная карта и полезные материалы: t.me/Arakcheev_R

📡 SSH-тоннель со смартфона: зачем и как SSH-туннель — это безопасный способ соединить локальную и удалённую машины, направляя трафик по зашифрованному каналу. Грубо говоря, вы прокидываете порт с одного устройства на другое, и никто по пути не видит, что именно вы передаёте. А если под рукой только телефон — это не проблема. Что нужно знать

🔐 Шифрование — весь трафик идёт через SSH, так что можно спокойно пользоваться открытыми Wi-Fi в кафе. 🔄 Передача TCP/IP — с порта одного компьютера на порт другого. Это база, на которой строятся все тоннели. 🌍 Сценарии — доступ к удалённым сервисам, обход сетевых ограничений, повышение конфиденциальности. 📱 Со смартфона — есть приложения, которые поднимают SSH-клиент прямо на Android или iOS (Termux, JuiceSSH, Blink и аналоги).

➡️ Читать статью 😈 CodeGuard: PySec Edition | Чат

Очень хочется дропнуть видос

😈 CodeGuard: PySec Edition | Чат

Пришла очередная задача с нашего бота CodeGuard. Ну давайте решать. Конечно, если внимательно посмотреть на инфу данную в самом задание бросается в глаза строка:

API_KEY=sk_live_51H8zEXAMPLE_secret_value_12345

Именно API-ключ используется приложением для доступа к внешнему сервису. DB_HOST=127.0.0.1 секретом не является: это всего лишь адрес локального компьютера. Проблема в том, что ключ лежит в конфигурационном файле открытым текстом. Если кто-то получит доступ к /etc/myapp/app.env, он сразу увидит рабочий ключ и сможет использовать его от имени приложения. Кроме того, такой секрет может случайно попасть в резервную копию, Git-репозиторий, логи или сообщение в чате. Судя по комментарию, ключ не меняли с 2021 года, а это тоже забавный признак))) 😂 Сначала я бы создал новый ключ у поставщика. Старый пока не удалял бы: если сразу его отозвать, приложение может перестать работать, а найти проблему будет сложнее. Затем сделал бы резервную копию конфигурации, потому что при любой ошибке важно иметь возможность восстановить рабочий вариант:

sudo install -m 600 /etc/myapp/app.env \
  /etc/myapp/app.env.backup.$(date +%Y%m%d%H%M%S)

После этого открыл бы файл для редактирования:

sudoedit /etc/myapp/app.env

И заменил старый ключ:

API_KEY=НОВЫЙ_КЛЮЧ

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

sudo systemctl restart myapp
sudo systemctl status myapp --no-pager

После перезапуска я бы проверил, что сервис действительно запустился и не ругается на авторизацию:

sudo journalctl -u myapp -n 50 --no-pager

Если приложение работает нормально, старый ключ можно отозвать у поставщика. Например, в AWS IAM это можно сделать так:

aws iam update-access-key \
  --user-name myapp \
  --access-key-id OLD_ACCESS_KEY_ID \
  --status Inactive

После дополнительной проверки старый ключ можно удалить:

aws iam delete-access-key \
  --user-name myapp \
  --access-key-id OLD_ACCESS_KEY_ID

Перед выполнением таких команд обязательно нужно проверить имя пользователя и идентификатор ключа, чтобы случайно не отключить рабочие учётные данные. После ротации я бы проверил несколько вещей: сервис имеет статус active; в журнале нет ошибок авторизации, 401, 403 или сообщений о недействительном ключе; локальная проверка здоровья приложения возвращает успешный результат, например:

bash
curl --fail http://127.0.0.1:PORT/health

файл с конфигурацией по-прежнему закрыт от лишних пользователей:

bash
sudo stat -c '%A %U:%G %n' /etc/myapp/app.env

старый ключ у поставщика находится в статусе Inactive или удалён; временные резервные копии после успешной проверки удалены и не остались доступными всем пользователям.

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

Ну, такой ответ я и отправил в бота) Получил оценку 10 из 10. Ура!) 👾 CTF_CodeGuard

🎯 Ежедневное задание #6 Поиск секретов в конфигурации и безопасная ротация Сложность: 4/10 Время: ~10 минут Вы — администратор локального сервиса myapp. Работайте только с приведёнными ниже данными: ничего не запускайте и не подключайтесь к внешним сервисам. Файлы конфигурации и юнита systemd:

# /etc/myapp/app.env
APP_ENV=production
# last_rotated=2021-06-10
API_KEY=sk_live_51H8zEXAMPLE_secret_value_12345
DB_HOST=127.0.0.1

# /etc/systemd/system/myapp.service
[Unit]
Description=MyApp service
[Service]
EnvironmentFile=/etc/myapp/app.env
ExecStart=/usr/bin/myapp
User=myapp
Restart=on-failure
[Install]
WantedBy=multi-user.target

Задание: 1) Найдите и укажите строку/значение, которое является секретом в конфигурации. 2) Кратко опишите, какие риски создаёт хранение этого секрета в таком виде. 3) Опишите пошагово безопасную процедуру ротации этого секрета (без фактического подключения): какие действия выполнить, в каком порядке, и приведите конкретные команды для локального шага замены в файле и перезапуска сервиса (используйте sudo там, где нужно). Укажите также пример команды/действия для отзыва старого ключа у поставщика (используйте понятный шаблон или пример для AWS IAM). 4) Перечислите минимальные проверки после ротации, чтобы убедиться в корректной работе сервиса и что старый ключ больше не действует. Ответ дайте по пунктам. Не выполняйте команды, только опишите и покажите команды, которые вы бы использовали. Попыток осталось: 2 Ответить до: 13.09.2026 в 10:59 МСК Отправь ответ обычным сообщением.

🕵️ Пока EDR молчит, хакер может годами жить в вашей сети. Compromise Assessment — это способ узнать правду. Если ваши системы защиты молчат, это не значит, что в инфраструктуре никого нет. По данным Kaspersky, в 2025 году многие инциденты оставались незамеченными неделями, месяцами и даже годами. А медианное время нахождения злоумышленника в сети (dwell time) выросло до 14 дней, в отдельных случаях достигая 600–700 дней. Compromise Assessment (CA) — это не аудит уязвимостей, а поиск реальных следов вторжения. Пять красных флагов: когда CA становится не «может быть», а «срочно»

🔄 Смена подрядчиков или админов с привилегированным доступом. У ушедших могли остаться учётки, туннели и инструменты, о которых вы не знаете. 🤝 Слияния и поглощения (M&A). Вы присоединяете чужую сеть со всей её историей. Если там уже сидели злоумышленники, они автоматически становятся вашими. 🚨 Подозрительная активность, которую не удаётся объяснить. Странные логины, всплески трафика в нерабочие часы, новые сервисы — всё это поводы копнуть глубже. 🛡 Построение или смена SOC. Прежде чем выстраивать мониторинг, нужно понять текущее состояние сети. ⚖️ Требования регуляторов или страховщиков. Всё чаще наличие proactive security measures становится обязательным условием.

➡️ Читать статью 😈 CodeGuard: PySec Edition | Чат

⏰ Доброго времени суток, подписчики! Сегодня рубрика «Загадки» Сегодня — задачка для тех, кто хоть раз настраивал сеть и видел, как пакеты ходят по кругу:

Я невидим, но без меня ты не получишь письмо. Я могу быть открытой, а могу — закрытой. Если я открыта — ты в безопасности. Если закрыта — ты в изоляции. Хакеры сканируют меня, чтобы найти дыру. Администраторы закрывают меня, чтобы тебя защитить. Я бываю 80-й, 443-й, 22-й. Но если я 666 — это уже не к добру.

🖥 Кто я? Ответ напишем позже 😉 😈 CodeGuard: PySec Edition | Чат

⚡️Компании всё активнее внедряют ИИ-агентов в свои процессы: от обработки заявок до работы с закрытыми базами данных. Но защита инфраструктуры часто не успевает за темпами автоматизации. Что не так с безопасностью агентов: ▪️Агенты получают доступ к системам и данным, которые раньше были доступны только людям ▪️Привычные меры защиты, например MFA, не рассчитаны на нечеловеческих участников инфраструктуры ▪️Атаки через скомпрометированных агентов уже фиксируются в реальных инцидентах Эксперты F6 подготовили чек-лист. Он поможет проверить безопасность ИИ-агентов в вашей инфраструктуре и расставить приоритеты в защите. ➡️ [Скачать чек-лист] Реклама. АО "БУДУЩЕЕ". ИНН 9709109340.

🫡 Идентификация файлов Бывает, скачал файл, а расширение потеряно или подделано. Или принесли флешку с архивом, где всё перемешано. TrID смотрит не на имя, а на бинарную сигнатуру — и говорит, что это на самом деле. Как это работает:

🧬 База сигнатур — набор шаблонов, по которым утилита сравнивает начало и структуру файла 🎯 Чем больше определений, тем точнее диагноз — база постоянно обновляется 📂 Поддерживает тысячи форматов: от привычных архивов и документов до экзотических форматов данных

➡️ Официальный сайт 😈 CodeGuard: PySec Edition | Чат

Суды чистые. ФССП чистая. Значит, человеку можно доверять? Не всегда. Trust Me идёт глубже стандартной проверки: Telegram, публичные сообщения, цифровой след, упоминания, связи, репутационные риски, проверка селлеров маркетплейсов и другие источники. Наше решение - одна проверка вместо десятков вкладок и ручного OSINT. Trust Me — комплексная OSINT-проверка людей и компаний. 🔥15 проверок бесплатно. ====================== 🌐 Сайт: https://tglink.io/8660fbed78bc09?erid=2W5zFGje39b 🤖 Telegram-бот: https://t.me/TrustMeRU_bot?erid=2W5zFGje39b

😈 CodeGuard Cyber Challenge — твой ежедневный челлендж по ИБ Рассказываю, мы писали этого бота для три дня и три ночи.. @CTF_CodeGuard превращает обучение в игру: каждое утро — новое задание, персонально под тебя.

Что ты получаешь: ▶️ Новое задание каждый день ▶️ Только практика ▶️ Персональный подход ▶️ Профиль навыков

🎁 Первые 3 дня — полностью бесплатно 🏆 CTF и призы за реальные результаты. Сезон начнется со дня на день = 21 день. Побеждает тот, кто наберёт больше всех баллов за выполненные задания. Призовой фонд — от 5 000 до 50 000 ₽. Чем Больше участников, тем больше приз. Начать тут ⬇️ @CTF_CodeGuard @CTF_CodeGuard @CTF_CodeGuard

Мы начинаем тебя практиковать. Лучших будет ждать награда.

👾 CTF_CodeGuard

🕺 Качаем свои навыки с помощью интерактивных игр OverTheWire — платформа для обучения сетевой безопасности и системному администрированию через интерактивные игры и задачи, моделирующие реальные сценарии ➡️ Официальный сайт 😈 CodeGuard: PySec Edition | Чат

Программисты, это вам 👇 Держите 5 каналов, которые реально помогают изучать программирование и IT с полного нуля: 🖥 Easy Coder — все направления IT. 👩‍💻 Easy Python — всё о Python. 🌐 Easy WebDev — Frontend, Backend. 🔠 Easy InfoSec — ИБ, Хакинг. 🖥 Easy GitHub — лучшее с GitHub. Тонны бесплатной инфы для любого уровня подготовки ✔️

👾 Как я почти взломал чужой сервер: реальный кейс Всё началось с простого сканирования портов:

text
nmap -sV 192.168.1.10

На сервере открылись стандартные порты: SSH (22), HTTP (80) и MySQL (3306). Но сайт на 80 порту работал на WordPress 4.7 — версии с кучей известных уязвимостей.invicti+1 Дальше запустил WPScan:

text
wpscan --url http://192.168.1.10 --enumerate u

Нашёл пользователя admin. Брутфорсить пароль не стал — нашли интереснее: в корне сайта лежал backup.zip с старой резервной копией. Внутри — файл .env с паролем от базы данных.shieldome+1 В базе оказался хэш пароля админа. Через john the ripper расшифровал за минуты, залогинился в админку, поднял шелл и получил доступ к серверу с правами www-data. На повышение привилегий: в домашней папке developer нашёл SSH-ключ без пароля. Просто подключился:

text
ssh developer@192.168.1.10

Ииии дальше всё остановил, собрал логи и отправил владельцу. Это был тестовый стенд, который кто-то забыл закрыть. 🛡 Выводы: Не оставляйте бэкапы (backup.zip, .sql, .bak) в веб-доступе — это первая цель для сканеровshieldome+1 Обновляйте CMS и плагины — WordPress 4.7 имеет 24 известные уязвимостиwordsec .env и другие конфиги должны быть под .htaccess / deny allboringsec+1 SSH-ключи защищайте паролем Регулярный аудит безопасности — обязательно Эта история не про взлом как преступление, а про то, как одна забытая деталь становится дырой в безопасности. Важно видеть такие уязвимости до злоумышленников. 👍 — если полезно, хочу ещё кейсов 🔥 — админ, удаляй тг, инфа не актуальна 😈 CodeGuard: PySec Edition | Чат

🛡 Интеграция аудит-логов с SIEM: от теории до Wazuh и RuSIEM Как превратить сырые логи в инструмент расследования инцидентов? В статье на Хабре от Selectel подробно разбирают процесс интеграции аудит-логов с SIEM-системами. Рассказываем о главном. 🎯 Зачем вообще нужны аудит-логи? У них две ключевые задачи: ⚙️ Как SIEM работает с логами: 4 шага 🤔 Wazuh или RuSIEM: что выбрать? Выбор зависит от задач, бюджета и необходимости работать с российскими требованиями. 💎 Итог: Аудит-логи становятся реальным инструментом безопасности только после правильной интеграции с SIEM. 😈 CodeGuard: PySec Edition | Чат