Сисадмин отвечает на вопросы

Твои первые действия при атаке шифровальщиков?

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

При настройке инфры изначально нужно ставить SIEM и настраивать широкий мониторинг по событиям, попытки брута, эксплуатации известных cve, аномальные запросы внутри сети и т.д. Хранить логи отдельно от продовых машин с проверкой на целостность, расширять . Все это после обнаружения инцедента поможет определить как именно атакующий получил доступ и закрыть уязвимости. Но это не гарантия, иногда отследить логику атаки довольно сложно особенно если использовались валидные доступы, от этого существенно поможет введение MFA и ACL списков на критичные сервисы. Совет по вебу максимально обогащайте логи прокси серверов, в том же nginx по дефолту не логгируются body post запросов что очень осложняет поиск вектора атаки.

на одном из таргетов попал в DMZ, инет только NAT от VM с которой работаю в сетке через VPN, до второго роутера не достучаться, в сети есть IP телефония. вопрос как выйти из DMZ? мне на ум приходит что-то вроде проброс портов/пивотинг или DNS forwarding.

Совет по бекапам, сделайте отдельное хранилище (физически дрйгой хост не связанный напрямую по сети) которое будет забирать бекапы из продовой инфры, именно pull в PBS (proxmox backup server) есть пример такого функционала. Это спасет при компроментации бекап серверов внутри инфры, если у вас настроена синхронизация и крады хранятся внутри скомпроментированной инфры то риск потерять бекапы довольно велик. Ну и классически храните бекапы отдельно от прода

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

Думаю самый простой вариант это попасть на роутер если есть с ним возможность взаимодействовать, проброс портов можно делать если есть через что пробрасывать, если доступ есть только к вм в изолированной сети то через нее нет смысла что-то пробрасывать. Если админ настроил все корректно то телефония с большой вероятностью тоже будет в этой же сетке без доступа к основной

Да я именно поэтому и пишу что бекапы должен именно забирать сторонний сервер из инфры у него должен быть ограниченный доступ на выгрузку и не более. С облаками можно сделать аналогично, просто добавить сервак который будет от себя забирать бекап и грузить его в облако

я как раз на роутере и сижу. ну по поводу корректно конечно все относительно, потому что оставлены дефолт УЗ на телефонию и единственное что можно рассматривать в качестве выхода это наверное шлюз.

так я и не спорил. что бы такой сервак что-то забирал нужно прописать правила или писать скрипт.

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

ну вот с машины которая подключена к VPN сети шлюз не пингуется, но если зайти по ssh на менеджер шлюза, то от туда пинг идет до него, и если я правильно понимаю механику, то можно подать инет на тот ip который выдан vpn или я ошибаюсь?

а вот по поводу сети, то же инетерсно, она вроде бы есть, но я ее не вижу.

Если правильно тебя понял то с впна ты можешь зайти на роутер, с роутера пингуеться вм которая также есть в сети, с вм роутер не пингуеться. Сети у впн и вм разные рулит обоими роутер на который есть доступ, если все так то да ты можешь настроить на впне роутами доступ с впна в другие сети с которыми связан роутер. Или по простому пробросом через ssh

Опиши подробнее, не особо понятно что значит есть, но не вижу) Можно в лс

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

да это уже все сделано, я про arp таблицу, там все на глухо, так что сказали уже забить. сейчас нашел в другой сети ms17_010 только проблема теперь другая, нет сплойтов под x86.:ROFLMAO:

Раз уж ты знаком с LEMP. Как защититься от ddos? Поделись неочевидными вещами

Хороший способ защиты если нет возможности использовать Cloudflare и подобные сервисы(они часто убивают траф на сайт при введении жесткой политики блокировок) писать свои списки в nginx по которым будешь фильтровать атаки, речь сейчас только про л7, л4 оставляем на ответственность хостеру. На практике встречал несколько основных векторов атак:
1) Плохо написанный сервис который грузит сам себя(тяжелые запросы в бд, неоптимизированное кеширование и т.п.) - это вопрос именно с точки зрения инфры, добавлять кеширование страниц чтобы снизить нагрузку на бекенд, по максимому сжимать отдачу статики, выносить ее на отдельные сервера и CDN.
2) Прямая атака в лоб когда просто с различных адресов запрашивают главную страницу, тут единственное что реально может помочь это ограничение по гео на отдачу сайта если это возможно на проекте(закрытие китая например что уже снизит существенно возможности под использвоанию ботнетов) и бан публичных хостингов\впнов\тор нод механизмами самого nginx. Реализуеться просто, ставишь модуль от maxmind и маркируешь нежелательных провайдеров флагом, по этому флагу отдаешь 403 через if в конфиге сайта. Аналогично работат с гео и конкретными подсетями.
3) Более сложный вариант когда бот маскируеться под реальное использование сайта, в основном это парсеры которые собирают контент с сайтов, тоже при активном парсинге могут сильно нагружать бек, их проще всего лимитировать на количество запросов через rate limit поставив корректные правила очереди для того чтобы не повлиять на пользователей, если есть какие-то уникальные метки например user-agent или referrer можно банить по ним также присваивая флаг.

Основной совет который могу дать это максимальная оптимизация сайта, вынос статики на отдельные сервера, добавление кастомных правил под конкретную ситуацию, если бот получает 403 на прокси его запрос не дойдет до бека и не будет влиять на сайт. Можно рассматривать более сложные механизмы наподобии crowdsec, у него есть возможность гибко фильтровать запросы, добавлять капчу на прокси сервера, синхронизироваться с публичной базой адресов находящихся в блеклистах. Если рассматривать вариант с Cloudflare то на ней аналогично через WAF можно настраивать политики по блокировке, но есть существенные плюсы в том что статика может кешироваться у них не загружая канал сервера и они сами предоставляют капчу + следят за фильтрацией запросов от адресов в блеках(ботнетов)

Все л7 ддосы нужно рассматривать на конкретных примерах, общие советы постарался описать, главная цель таких блокировок отдавать 403 ответ на все возможные подсети которые будут атаковать если это ботнет и сделать атаку максимально дорогой для ддосера, если он будет вынужен использовать только чистые ip адерса только из пула стран где реально работает сайт это очень сильно ограничит его возможности.