Фильтрация входящего трафика

Фильтрация входящего трафика

Входящий трафик — одна из самых чувствительных частей инфраструктуры. Если сервис доступен из интернета, к нему могут обращаться не только нужные пользователи, но и случайные боты, сканеры, автоматические проверки и нежелательные запросы.

Главная идея простая: внешний запрос не должен сразу попадать внутрь инфраструктуры. Между интернетом и внутренним сервисом должен быть понятный защитный слой.

Для обычного пользователя это можно представить как вход в здание. Посетитель сначала попадает на ресепшн, а не сразу в любую комнату. Для специалиста это слой edge, reverse proxy, HTTPS, host-based routing, фильтрации, журналов и мониторинга.

Зачем нужен защитный периметр

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

Во-первых, приложение оказывается слишком близко к внешнему миру. Если в нём есть ошибка, слабая авторизация или неправильная настройка, риск становится выше.

Во-вторых, сложно централизованно управлять HTTPS, доменами, журналами и правилами доступа. Каждый сервис начинает жить по своим правилам.

В-третьих, диагностика становится сложнее. Когда что-то не работает, непонятно, проблема в домене, сертификате, proxy, маршруте, backend-сервисе или самом приложении.

Защитный периметр решает эти задачи. Он становится контролируемой входной точкой, через которую проходят внешние запросы.

Основные элементы

В архитектуре FASTRAID LAB можно выделить несколько логических элементов.

Элемент	Простое назначение	Что делает технически
EdgeGate	внешний вход	принимает трафик из интернета и передаёт его в контролируемый периметр
ShieldBox	защитный слой	проверяет запросы, отбрасывает неизвестные направления, ведёт журналы
GateProxy	reverse proxy	принимает HTTPS и направляет запрос к нужному внутреннему сервису
Service	внутреннее приложение	выполняет полезную задачу: сайт, панель, API или другой сервис
WatchTower	наблюдение	проверяет доступность, фиксирует ошибки и отправляет уведомления

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

Как проходит входящий запрос

Типовой путь входящего запроса выглядит так:

Internet → EdgeGate → ShieldBox → GateProxy → Service

На практике это означает:

1. пользователь обращается к домену;
2. запрос приходит на внешний сетевой вход;
3. защитный слой проверяет, известен ли домен;
4. HTTP перенаправляется на HTTPS;
5. reverse proxy принимает безопасное соединение;
6. proxy определяет нужный внутренний сервис;
7. backend получает только разрешённый трафик;
8. событие фиксируется в журналах и мониторинге.

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

Reverse proxy простыми словами

Reverse proxy — это промежуточный сервер между внешним пользователем и внутренним сервисом.

Пользователь видит домен и HTTPS. Внутри инфраструктуры запрос направляется на конкретный сервис, порт или контейнер. Пользователю не нужно знать, где именно находится backend.

Reverse proxy помогает:

• публиковать несколько сервисов через один внешний вход;
• использовать HTTPS;
• скрывать внутренние адреса и порты;
• управлять маршрутами по доменам;
• централизованно вести журналы доступа;
• отделять внешний слой от приложений;
• быстро менять backend без изменения внешнего адреса.

Для обычного пользователя это единая входная дверь. Для специалиста — маршрутизация web-запросов по host-заголовкам, TLS, upstream-сервисам и правилам доступа.

Базовая политика доступа

Хорошая политика строится на простом принципе: разрешено только то, что явно описано.

Ситуация	Действие
HTTPS-запрос к известному домену	разрешить и направить к нужному сервису
HTTP-запрос	перенаправить на HTTPS
неизвестный домен	отклонить или не обслуживать
запрос к служебному пути	отклонить
попытка прямого доступа к backend	запретить
слишком частые повторяющиеся запросы	ограничить или зафиксировать
административная панель	не публиковать наружу без отдельной защиты

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

HTTPS и сертификаты

HTTPS нужен не только для красивого замка в браузере. Он защищает соединение между пользователем и входным слоем инфраструктуры.

Через HTTPS могут передаваться логины, cookie, токены, формы, административные действия и технические запросы к API. Если сервис опубликован наружу, HTTPS должен быть обязательным.

Удобнее, когда сертификаты обслуживаются на уровне reverse proxy или входного периметра. Тогда не нужно настраивать HTTPS отдельно в каждом внутреннем сервисе, а внешний вход остаётся стабильным.

Неизвестные домены и host-заголовки

Когда запрос приходит на сервер, он содержит имя домена, к которому обратился пользователь. Reverse proxy смотрит на это имя и понимает, куда направить запрос.

Но сервер не должен обслуживать любые случайные имена. Если приходит запрос к неизвестному домену, его лучше отклонить.

Это помогает:

• не отдавать лишнюю информацию;
• не смешивать маршруты;
• не направлять неизвестные запросы внутрь;
• проще анализировать журналы;
• уменьшить вероятность неправильной маршрутизации.

Подозрительные запросы

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

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

Подозрительными могут быть:

• частые обращения к несуществующим путям;
• запросы к служебным каталогам;
• попытки найти административные панели;
• повторяющиеся ошибки с одного источника;
• необычные host-заголовки;
• попытки доступа к backend напрямую;
• слишком высокая частота запросов.

Задача фильтрации — не паниковать, а отделять нормальные обращения от лишнего шума.

Журналы входящего трафика

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

Журналы помогают увидеть:

• какой домен запрашивали;
• какой путь открывали;
• какой код ответа был возвращён;
• сколько времени занял запрос;
• был ли запрос передан backend-сервису;
• какие ошибки возникли на proxy;
• повторялись ли похожие запросы.

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

Мониторинг периметра

Фильтрация входящего трафика должна быть связана с мониторингом. Недостаточно настроить proxy и забыть.

Минимальные проверки:

• доступен ли HTTPS;
• отвечает ли домен;
• корректно ли обновляются сертификаты;
• отвечает ли reverse proxy;
• доступен ли backend-сервис;
• нет ли повторяющихся ошибок;
• не выросло ли количество отказов;
• не сломалась ли маршрутизация.

Хороший мониторинг не сообщает о каждой мелочи. Он выделяет события, которые действительно требуют внимания.

Что не стоит публиковать наружу

Не каждый сервис должен быть доступен из интернета. Некоторые панели и инструменты лучше оставлять только во внутренней сети или открывать через отдельный защищённый доступ.

Обычно не стоит напрямую публиковать:

• административные панели;
• панели управления инфраструктурой;
• интерфейсы баз данных;
• dashboards без защиты;
• тестовые приложения;
• временные контейнеры;
• служебные API;
• интерфейсы резервного копирования.

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

Частые ошибки

При публикации сервисов часто повторяются одни и те же ошибки.

Первая ошибка — открывать backend-сервис напрямую в интернет.

Вторая ошибка — публиковать административные панели без отдельной защиты.

Третья ошибка — разрешать любые host-заголовки.

Четвёртая ошибка — не вести журналы доступа.

Пятая ошибка — не проверять сертификаты и HTTPS.

Шестая ошибка — смешивать тестовые и рабочие сервисы.

Седьмая ошибка — не иметь быстрого способа отключить проблемный маршрут.

FASTRAID LAB строится вокруг другого подхода: публикация сервиса должна быть управляемой, наблюдаемой и обратимой.

Простая модель для небольшой инфраструктуры

Для небольшой домашней или лабораторной инфраструктуры достаточно понятной модели:

1. наружу открыты только нужные web-порты;
2. все web-сервисы проходят через reverse proxy;
3. backend-сервисы не публикуются напрямую;
4. неизвестные домены не обслуживаются;
5. HTTP перенаправляется на HTTPS;
6. административные панели не открываются без отдельной защиты;
7. журналы входящих запросов сохраняются;
8. мониторинг проверяет внешний вход и backend;
9. изменения в правилах применяются по одному;
10. после каждого изменения выполняется проверка.

Эта модель не делает систему абсолютно неуязвимой, но резко повышает порядок и управляемость.

Итог

Фильтрация входящего трафика — это не отдельная “защитная кнопка”, а часть архитектуры.

Внешний запрос должен проходить понятный маршрут. Неизвестные направления не должны обслуживаться. Опубликованные сервисы должны идти через reverse proxy. HTTPS должен быть обязательным. Журналы должны помогать диагностике. Мониторинг должен показывать состояние входного слоя.

Главная цель — сделать внешний доступ контролируемым.

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