ZeroDay | Кибербезопасность

Антивирусы, EDR, фаерволы и SIEM генерируют тысячи событий каждый день. Ценность создаёт не сам факт их наличия, а специалист, который умеет отличить шум от атаки, связать события в цепочку и принять решение до того, как инцидент станет ущербом. Профессия «Аналитик SOC» от Codeby Academy — 7,5 месяцев практического курса в Blue Team: от первого алерта до расследования уровня L2. На курсе: ⏺️триаж и приоритизация — логи, события, потоки ⏺️корреляция и разбор инцидентов ⏺️MITRE ATT&CK — как атакующий действует на самом деле ⏺️Threat Intelligence и Threat Hunting ⏺️Vulnerability Management ⏺️SIEM на Wazuh — руками, не в теории ⏺️мышление SOC-аналитика: алерт ➡️расследование ➡️ отчёт Формат: живые занятия, практические задания, разбор реальных кейсов. Это профессиональный трек по мониторингу и реагированию. За 7,5 месяцев вы выстраиваете навыки, которые ежедневно нужны в SOC-командах банков, телекома, ритейла и IT-компаний. Старт курса 19 октября ➡️️Посмотреть программу и записаться 🪧По вопросам — @CodebyAcademyBot

Как настроить новый VPS и не оставить его открытым для всех 👋 Приветствую в мире цифровой безопасности! Получить IP и пароль от VPS - это мало. Свежий сервер уже через несколько минут начинают находить автоматические сканеры, поэтому перед деплоем сайта или бота лучше сначала закрыть базовые точки входа. ⏺Первое, что стоит сделать после входа, обновить систему: sudo apt update && sudo apt upgrade -y После этого создаём отдельного пользователя с sudo. Постоянно работать под root точно не стоит: sudo adduser admin sudo usermod -aG sudo admin ⏺Следующий шаг, SSH-ключи. На своём компьютере создаём пару: ssh-keygen -t ed25519 ssh-copy-id admin@SERVER_IP Проверяем, что новый пользователь действительно входит по ключу, и только после этого запрещаем удалённый вход для root: PermitRootLogin no PasswordAuthentication no Затем проверяем конфигурацию и перечитываем SSH: sudo sshd -t sudo systemctl reload ssh Старую SSH-сессию лучше пока не закрывать. Ошибка в конфиге или ключах иначе легко оставит вас с сервером, в который больше нельзя войти. ⏺Теперь файрвол. Если серверу нужны только SSH и обычный веб-трафик: sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status verbose Порты приложения вроде 3000, 8000 или 8080 наружу открывать обычно не нужно. Их можно слушать только на 127.0.0.1, а внешний трафик принимать через Nginx. ⏺Для SSH можно добавить Fail2ban: sudo apt install fail2ban sudo systemctl enable --now fail2ban sudo fail2ban-client status Он следит за логами и блокирует адреса после серии неудачных попыток входа. Это не замена ключам и файрволу, а дополнительный слой защиты. ⏺Само приложение тоже лучше не запускать от root. Для systemd можно создать отдельного системного пользователя и добавить ограничения: [Service] User=myapp NoNewPrivileges=true PrivateTmp=true ProtectSystem=full ProtectHome=true Даже если в приложении найдётся уязвимость, процесс будет работать с гораздо меньшими правами. ⏺И наконец, проверяем, что вообще торчит наружу: ss -tulpn sudo ufw status systemctl --failed У нового VPS с сайтом снаружи обычно должны быть доступны только действительно необходимые сервисы. База данных, Redis, внутренний API и служебные панели без причины выставлять в интернет не стоит. ZeroDay | Белый Хакер | #VPS

🗂 Пакет Безопасности — папка, которую админ собирал более 10 лет ⚡️ Слитые курсы по IT и ИБ ⚡️ Сервисы и тулзы для приватности ⚡️ Инструкции и шпаргалки ⚡️ Редкие книги и утилиты ⚡️ Гайды написанные автором Большинство собирает такую базу годами. Здесь все отсортировали и разбили в одном канале ссылка действует 48 часов 📌 Подписывайся: @package_security

Strix: AI-пентестер, который сам ищет уязвимости 👋 Приветствую в мире цифровой безопасности! Обычный сканер находит потенциальную проблему и оставляет её разбирать человеку. Strix пытается пройти дальше: запускает код, исследует приложение и проверяет найденные уязвимости рабочими PoC. ⏺Strix - open-source инструмент для автоматизированного пентеста. Внутри есть reconnaissance, OSINT, HTTP-прокси, браузер для тестирования веб-приложений, shell, Python runtime и анализ исходного кода. ⏺Для первого запуска достаточно Docker и API-ключа LLM: curl -sSL https://strix.ai/install | bash export STRIX_LLM="openrouter/z-ai/glm-5.3" export LLM_API_KEY="your-api-key" strix --target ./app-directory ⏺Можно проверять не только локальный код. Например, указать GitHub-репозиторий: strix --target https://github.com/org/repo Или запустить black-box проверку собственного веб-приложения: strix --target https://your-app.com ⏺Strix умеет работать и с API. Можно передать OpenAPI/Swagger или Postman collection вместе с адресом работающего API: strix --target ./openapi.yaml \ --target https://api.your-app.com ⏺Интересная часть - multi-agent подход. Отдельные агенты могут заниматься разведкой, поиском и проверкой уязвимостей, а затем передавать находки друг другу. В результатах Strix старается показать не просто «возможна SQLi», а подтверждение проблемы и шаги для воспроизведения. ⏺Есть и режим для CI/CD: strix -n -t ./ --scan-mode quick В CI можно запускать проверку на pull request и останавливать сборку, если найдены уязвимости. Для автоматизации это уже ближе не к разовому пентесту, а к постоянной проверке приложения. ⏺Результаты сохраняются локально, а посмотреть последний запуск можно через: strix view Там отображаются найденные проблемы, карта работы агентов и предыдущие запуски. Главное отличие Strix от обычного SAST-сканера в подходе: он пытается не просто найти подозрительный участок кода, а проверить, можно ли превратить его в реальную уязвимость. Использовать такой инструмент, конечно, стоит только на своих системах или с разрешения владельца. ZeroDay | Белый Хакер | #Инструмент

😎ИИ ускоряет атаки. А что насчет защиты? Злоумышленникам уже не обязательно пропорционально увеличивать команду, чтобы масштабировать атаки: часть работы берет на себя ИИ. Значит, и защита должна становиться быстрее, автономнее и эффективнее. 👀15–16 октября на Positive Security Day 2026 поговорим о том, как меняется кибербезопасность в новой модели угроз — и какие технологии помогают защитникам не отставать от атакующих. В фокусе: 👨‍💻 движение к автономному SOC; 👨‍💻 защита устройств от неизвестных угроз; 👨‍💻 работа с большими объемами данных; 👨‍💻 технологии, которые помогают быстрее обнаруживать и расследовать атаки. Но одной теорией не ограничимся. 🐯 В hands-on-зонах и соревнованиях можно будет атаковать ИИ-технологии, расследовать инциденты, тестировать продукты и вместе с инженерами Positive Technologies разбирать, что происходит под капотом. 📍 Москва + онлайн

ИИ нашёл баг, исправил его и заодно оставил хакеру лазейку… Автор устроил ИИ-ревьюерам ловушку: в PR лежит настоящий баг, который нужно исправить, а рядом незаметно протащена правка, ослабляющая авторизацию. Никаких «игнорируй правила» и других примитивных prompt injection. Вредное требование выглядит как обычная часть логики проекта. ⏺Claude, GPT, DeepSeek и локальные модели прогнали через разные варианты таких ревью. Самый неожиданный результат в том, что модель может распознать атаку и написать в рассуждении, что правка опасна, но всё равно внести её в итоговый код 🤯А роль проверяющего и роль исполнителя для одной и той же модели дают совершенно разный результат. ZeroDay | Белый Хакер | #статья

NAT, PAT и Proxy: в чём разница? 👋 Приветствую в мире цифровой безопасности! Все три механизма могут скрывать внутренний адрес клиента, но делают это по-разному. ⏺NAT меняет IP-адрес в заголовке пакета. Например, внутренний хост 192.168.1.10 выходит в Интернет через публичный 203.0.113.5: 192.168.1.10 → NAT → 203.0.113.5 → Internet NAT меняет адреса и отслеживает соответствие соединений. Сам трафик при этом продолжает идти между клиентом и сервером. ⏺PAT использует ещё и номера портов. Поэтому несколько внутренних машин могут одновременно выходить через один публичный IP: 192.168.1.10:49152 → 203.0.113.5:40001 192.168.1.11:49153 → 203.0.113.5:40002 По номеру порта роутер понимает, какому внутреннему соединению вернуть ответ. ⏺Proxy работает иначе. Он принимает соединение от клиента и сам устанавливает отдельное соединение с сервером: Client → Proxy → Server Поэтому proxy может разбирать HTTP-запросы, применять фильтры, вести логи или терминировать TLS при включённом TLS inspection. ⏺В Wireshark это особенно заметно при сравнении TCP-сессий. При NAT клиент и сервер всё ещё находятся в одном TCP-соединении, только адрес источника изменён. У proxy появляются две отдельные сессии: Client ↔ Proxy Proxy ↔ Server У них могут отличаться TCP-параметры, временные характеристики и даже версии протоколов. ⏺Поэтому NAT сам по себе не является firewall, PAT не делает трафик анонимным, а proxy может стать полноценной точкой контроля трафика. Запомнить можно так: NAT меняет адрес, PAT меняет адрес и порт, Proxy принимает одно соединение и создаёт другое. ZeroDay | Белый Хакер | #NAT #PAT

Zeroization: как правильно уничтожать секреты в памяти 👋 Приветствую в мире цифровой безопасности! ⏺Zeroization - это практика безопасного удаления чувствительных данных из памяти после использования. Ключи, пароли, токены и другие секреты не должны оставаться в RAM дольше необходимого. ⏺Проблема в том, что обычного освобождения памяти недостаточно. Например: char secret[32] = "super-secret-key"; use_secret(secret); memset(secret, 0, sizeof(secret)); На -O2 компилятор может увидеть, что результат memset() больше нигде не используется, и удалить операцию очистки. Проверить можно так: gcc -O2 test.c -o test objdump -d ./test | less ⏺Для секретов используют функции, специально предназначенные для очистки памяти: explicit_bzero(secret, sizeof(secret)); На Windows аналогичный вариант: SecureZeroMemory(secret, sizeof(secret)); ⏺Но есть ещё одна проблема: секрет может существовать сразу в нескольких местах. Например, посмотреть память процесса можно через /proc: grep -a "super-secret-key" /proc/$PID/mem На практике доступ к /proc/$PID/mem ограничен правами и настройками ядра, поэтому для анализа собственного процесса чаще используют отладчик или дамп. Например: gdb -p $PID А затем можно посмотреть отображённые области памяти: info proc mappings ⏺Ещё один источник утечек - core dump. Проверить его настройку: ulimit -c cat /proc/sys/kernel/core_pattern Если процесс упадёт, содержимое его памяти потенциально может оказаться в дампе. Поэтому для сервисов, работающих с ключами и токенами, важно отдельно контролировать создание и хранение core dump. ⏺И не стоит забывать про swap. Проверить, используется ли он: swapon --show Сам факт наличия swap не означает, что конкретный секрет туда попал, но чувствительные приложения учитывают этот риск и используют механизмы вроде mlock() для страниц с ключами. ⏺Главный нюанс zeroization в том, что недостаточно стереть один буфер. Секрет мог скопироваться при передаче между функциями, попасть в другой объект или остаться в памяти после временного преобразования. ⏺Поэтому хороший подход выглядит так: минимальное время жизни секрета → минимум копий → контролируемое хранение → явная очистка → контроль дампов и swap. Zeroization - это не просто memset(secret, 0, ...). Это управление всем жизненным циклом секрета в памяти. ZeroDay | Белый Хакер | #zeroday

Анализ скрытых MITM в Wireshark: часть 2 👋 Приветствую в мире цифровой безопасности! В прошлой части смотрели на сертификаты и сетевые параметры. Теперь копнём глубже: разберём признаки, которые по отдельности ещё ничего не доказывают, но вместе могут вывести на след прокси или перехватывающего узла. ⏺Начнём с TLS Alert. Если посредник не может нормально обработать соединение, он может оборвать сессию прямо во время handshake: tls.alert_message Смотрим, какие соединения заканчиваются Alert, и сравниваем их с успешными сессиями того же клиента. Один случай - ещё не сенсация. Повторяющийся сценарий - уже повод насторожиться. ⏺Следующий фильтр ловит неожиданные сбросы TCP: tcp.flags.reset == 1 Особенно интересно, если RST прилетает сразу после Client Hello или Server Hello. Сам по себе сброс не означает MITM, но если он регулярно появляется в одном и том же месте handshake, картина становится подозрительной. ⏺Теперь проверим, куда клиент вообще пытается установить TLS-соединение: tls.handshake.extensions_server_name Сверяем SNI, DNS-ответ и фактический IP назначения. Например, клиент запрашивает api.example.com, DNS отдаёт один адрес, а соединение снова и снова уходит на другой. Это может быть CDN, балансировщик или корпоративная инфраструктура, но такое расхождение точно стоит проверить. ⏺Отдельно смотрим ALPN: tls.handshake.extensions_alpn_str Сравниваем несколько соединений одного клиента. Если обычно используется h2, а часть сессий внезапно переключается на http/1.1, возможны промежуточный прокси, TLS inspection или другая прослойка между клиентом и сервером. ⏺Ищем повторные handshake через Client Hello: tls.handshake.type == 1 Добавляем к просмотру: tcp.stream Теперь сравниваем потоки. Сценарий Client Hello → несколько пакетов → FIN/RST → новый Client Hello, который повторяется снова и снова, выглядит гораздо интереснее, чем единичный разрыв соединения. ⏺Ещё один полезный фильтр: tcp.analysis.retransmission || tcp.analysis.out_of_order Здесь важно не просто посчитать retransmission, а найти закономерность. Например, повторные передачи начинаются только после TLS handshake или возникают исключительно при обращении к конкретному IP. ⏺Чтобы быстро собрать всё в одну картину, открываем: Statistics → Conversations → TCP Сортируем соединения по количеству пакетов и смотрим пары IP:port. Затем открываем подозрительный поток через Follow → TCP Stream и проверяем всю цепочку: TCP handshake, TLS handshake, Alert, retransmission и завершение соединения. MITM редко оставляет один очевидный след. Гораздо интереснее, когда DNS, SNI, TLS, TCP и поведение нескольких сессий начинают противоречить друг другу. Вот тогда уже есть за что зацепиться. ZeroDay | Белый Хакер | #MITM

Как дать контейнеру SSH и при этом не дать ему украсть ключ? Контейнеру нужно забрать код из приватного Git или сходить на сервер. Самый очевидный путь - сунуть внутрь ~/.ssh. Только вместе с SSH-доступом приложение получает и приватный ключ: если процесс взломают, ключ можно прочитать и унести. ⏺Автор статьи решил сделать наоборот - оставить контейнеру полноценный SSH, но сам секрет от него спрятать. Вместо ключа внутрь пробрасывают только сокет ssh-agent, но тут rootless Docker подкидывает неприятный сюрприз: UID внутри контейнера не совпадает с UID на хосте, и простой SSH_AUTH_SOCK перестаёт работать. В статье разбирают этот затык, собирают схему с non-root, read-only filesystem и без capabilities. ZeroDay | Белый Хакер | #Статья