Network hardening

Default-deny — единственная масштабируемая позиция фаервола

Набор правил фаервола — это политика о том, что может происходить на проводе. Написать её можно ровно двумя способами. Default-allow разрешает всё и перечисляет, что блокировать, — ты выписываешь атаки, о которых подумал, и каждая, о которой не подумал, проходит. Default-deny дропает всё и перечисляет, что разрешить, — ты выписываешь потоки, которые приложению реально нужны, а всё остальное, известное и неизвестное, запрещено отсутствием правила.

Вся суть в этой асимметрии. Список default-allow — это блок-лист, а блок-лист полон ровно настолько, насколько богато было твоё воображение в день написания. Список default-deny — это allow-лист, и он отказывает в закрытую: новый сервис, новый порт, забытый отладочный эндпоинт, свежий CVE, открывший неожиданный слушатель, — ничто из этого не заработает, пока кто-то осознанно не напишет правило. Это тот же рефлекс deny-by-default, что управляет авторизацией в приложении, применённый слоем ниже — на сети. CIS Benchmarks и NIST SP 800-123 делают финальное правило неявного запрета базовой нормой именно поэтому: оно превращает «а мы не забыли это заблокировать?» в «а мы не забыли это разрешить?», и на второй вопрос рецензент действительно может ответить, просто прочитав набор правил.

Причина, по которой команды всё ещё отгружают default-allow, операционная, а не архитектурная: deny-by-default громко ломает всё, пока каждый легитимный поток не перечислен, а это перечисление — настоящая работа. Но эта боль и есть фича — она заставляет тебя знать собственный трафик.

Egress — половина фаервола, о которой все забывают

Зайди в большинство сетей: входные правила жёсткие, а egress-правила — одна строка: allow all outbound. Эта одна строка и сделала сценарий из Hook возможным. Почти каждая современная цепочка атаки зависит от исходящих соединений, которые разрешил защитник: подтянуть вторую стадию пейлоада, маячить на command-and-control сервер и выгрузить украденные данные обратно наружу. Фаервол только-на-входе — это дверь с засовом снаружи и снятой внутренней ручкой: он не пускает войти и ничего не делает с тем, кто уже внутри и выходит с серебром.

Egress-фильтрация применяет default-deny к исходящему направлению: воркер может инициировать соединения только к тем конкретным адресам, которые нужны для его работы. Платёжному воркеру, который общается с одним банковским API и твоей базой, незачем открывать TLS-соединение к произвольному IP в интернете — поэтому он не может, и в момент попытки она запрещается и логируется, что часто и есть твой самый ранний сигнал компрометации. Самое ценное egress-правило на облачном хосте — заблокировать исходящий доступ к metadata-эндпоинту инстанса (169.254.169.254) для всего, чему он не нужен: именно этот link-local адрес превращает SSRF или захваченный контейнер в украденные облачные учётки.

Сегментация решает радиус поражения

Плоская сеть — один большой 10.0.0.0/8, где каждый хост достаёт любой другой по любому порту, — означает, что радиус поражения любой компрометации — всё хозяйство целиком. Сегментация разбивает сеть на зоны (подсети, VLAN, security groups, Kubernetes NetworkPolicies, авторизация service-mesh) и навязывает default-deny между ними. East-west трафик — сервер-к-серверу, направление, по которому идёт латеральное движение, — теперь обязан пересечь границу, которая по умолчанию говорит «нет».

Выигрыш конкретен: помести слой базы в собственный сегмент, до которого добирается только слой приложения по порту 5432, — и захваченная фронтовая веб-машина не сможет тронуть базу напрямую, хотя обе живут «в сети». Помести каждый микросервис под свою политику — и захваченный ресайзер картинок не сможет сканировать соседей. Классический худший случай — одна машина скомпрометирована, а затем неаутентифицированные внутренние сервисы (Redis, Elasticsearch, админ-панель) достижимы плоско по всей подсети — это ровно то, что убирает сегментация. Ты здесь не предотвращаешь первый взлом; ты делаешь так, чтобы первый взлом был и последней машиной.

Убийство протоколов открытым текстом

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

«Внутренний HTTP — нормально, он никогда не покидает нашу сеть» — это опасная полуправда: как только ты признаёшь, что атакующий уже может быть внутри сети (вся посылка сегментации), внутренний открытый текст ровно так же открыт, как внешний. Шифруй и east-west трафик тоже — взаимный TLS между сервисами и есть ответ service-mesh, — чтобы плацдарм на одной машине не вручал атакующему отвод на трафик всех остальных.