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

Ниже — не попытка рассказать опытным администраторам или DevOps, как им делать свою работу. В зрелых с точки зрения ИБ компаниях такие ситуации обычно уже разобраны в процедурах реагирования, а у команд есть понимание, кто и что делает в первые минуты и часы инцидента.

Но довольно часто с серьёзным инцидентом компания сталкивается впервые. И вот там начинается самое сложное: всё лежит, бизнес нервничает, информации мало, а делать что‑то надо прямо сейчас.

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

Поэтому ниже — семь базовых правил о том, что стоит сделать и чего, наоборот, лучше не делать в момент инцидента, пока ситуация ещё не локализована, не определён дальнейший план действий и не понятно, кто именно будет заниматься разбором последствий и восстановлением.

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

В последние годы для команд, которые работают с зарубежной инфраструктурой из России, обычный корпоративный VPN перестал быть чем-то, что можно один раз настроить и забыть. OpenVPN, WireGuard, IPsec, различные TLS- и QUIC-обёртки могут работать стабильно месяцами, а потом внезапно начать деградировать: где-то соединение не устанавливается, где-то режется UDP, где-то DPI начинает узнавать сигнатуры, где-то провайдер меняет правила фильтрации.

Для компании это превращается не в техническую мелочь, а в операционный риск. Инженеры не могут попасть на серверы. DevOps не может проверить прод. Администратор не может забрать бэкап. Пентестер не может подключиться к стенду заказчика. При этом инфраструктура может находиться в Европе, США, Азии или у любого другого зарубежного провайдера, а сотрудники — физически находиться в РФ.

В какой-то момент мы пришли к простой мысли: если из корпоративной сети ещё можно установить исходящее SSH-соединение, то можно попробовать использовать сам OpenSSH не только как инструмент администрирования, но и как транспорт для L3-туннеля. В OpenSSH для этого давно существует режим ssh -w, который поднимает туннель через tun-устройство.

Идея статьи не в том, чтобы объявить ssh -w «лучшим VPN на все времена». Это не замена WireGuard для нормальной постоянной инфраструктуры и не серебряная пуля против любых сетевых ограничений. Но это очень полезный аварийный и корпоративный вариант: работает поверх обычного SSH, не требует отдельного VPN-демона на сервере, может быть поднят на дешёвом VPS, использует привычную модель ключей OpenSSH и позволяет строить полноценную маршрутизацию на L3.

Я живу вне РФ, но у меня там остаются близкие, с которыми важно продолжать общение.

И в какой-то момент я столкнулся с простой, но неприятной реальностью:
поддерживать стабильную связь становится всё сложнее.

В условиях массовых блокировок и внедрения «белых списков» интернет постепенно перестаёт быть глобальным - вместо этого остаётся ограниченный набор разрешённых сервисов.

На практике:

При проведении теста на проникновение внутренней сети предприятия, одним из первых рассматриваемых векторов атак на сети Windows является поиск и компрометация неподдерживаемых операционных систем с известными и публичными эксплойтами. Чаще других при этом эксплуатируется служба SMB. Другой проблемой системных администраторов является отсутствие документации сети. Пентестер и/или аналитик информационной безопасности сети может столкнуться с разведкой сети по принципу черного ящика в ситуации большой загруженности или при откровенной халатности сотрудников, ответственных за эксплуатацию. В частности, администраторов (тезис подтверждается исследованием коллег из Positive Technologies).

Сформулируем и немного расширим кейс

Необходимо за адекватное время найти все неподдерживаемые операционные системы семейства Windows в локальной сети предприятия с числом хостов более 10 тыс., предположительно имеющих публичные эксплойты SMB.
Ограничением метода может стать сегментация сети, когда некоторые подсети закрыты от хоста исследователя.

Кому интересно, добро пожаловать под кат...

Данное исследование является исключительно научно-техническим экспериментом.