Почему мы его создали? Долгое время мы в Rambler Group использовали трехуровневую архитектуру сети дата-центра, в которой каждый проект или компонент инфраструктуры находился в выделенном vlan. Весь трафик — как между вланами, так и между дата-центрами — проходил через оборудование периферийного уровня.
Edge-оборудование — это дорогой маршрутизатор, который может выполнять множество различных функций, поэтому порты на нем тоже дорогие.
Со временем горизонтальный трафик рос (межмашинный — например, репликация баз данных, запросы к различным сервисам и т. д.), и в какой-то момент встал вопрос о перезапуске портов на Edge-маршрутизаторах.
Одной из основных функций таких устройств является фильтрация трафика.
В связи с этим управление ACL также усложнилось: все приходилось делать вручную, плюс выполнение задачи смежным отделом тоже требовало времени.
Дополнительное время также было потрачено на настройку портов на уровне доступа.
Необходимо было выполнять не только ручные действия тех же NOC, но и выявлять потенциальные проблемы безопасности, ведь хосты меняют свое местоположение и, соответственно, могут получить нелегитимный доступ к чужим вланам.
Пришло время что-то менять, и на помощь пришли сети Kloz или, как их еще называют, IP-фабрики.
Несмотря на внешнее сходство, принципиальное отличие этой архитектуры от предыдущей заключается в том, что каждое устройство, включая листовой уровень, выступает в роли маршрутизатора, а шлюзом по умолчанию для сервера является Top-of-Rack. Таким образом, горизонтальный трафик между любыми хостами разных проектов теперь может проходить через уровень позвоночника, а не через ребро.
Кроме того, на одном уровне позвоночника мы можем соединять дата-центры друг с другом, а на пути между любыми двумя серверами теперь находится не более четырех сетевых устройств.
Периферийное оборудование в этой архитектуре нужно только для подключения операторов связи и пропускает только вертикальный трафик (в Интернет и из Интернета).
Основная особенность сети Clos — в ней нет места, где можно фильтровать трафик между хостами.
Поэтому эту функцию необходимо выполнять непосредственно на сервере.
Централизованный брандмауэр — это программа, которая фильтрует трафик на самом хосте, который получает трафик.
Требования
Необходимость внедрения централизованного межсетевого экрана была продиктована несколькими факторами:- конечные потребители и
- существующая инфраструктура.
- Брандмауэр должен уметь работать и создавать правила на хосте и виртуальных машинах.
При этом список правил не должен отличаться от среды, в которой работает межсетевой экран.
То есть правила идентичны.
- Агент брандмауэра не должен блокировать весь трафик после установки.
То есть должен быть набор правил по умолчанию, которые предоставляются сразу вместе с агентом — ssh, порты экспортера (мы используем Prometheus), доступ для различных сканеров безопасности и так далее.
- Агент может работать без сервера, используя только файлы правил.
- Агент не принимает никаких решений; его задача — применить список правил из указанных источников.
- Вся логика выполняется на сервере.
- Политика запрета по умолчанию гласит: «Что не разрешено, то запрещено».
Поэтому мы не используем двухточечный доступ; в нашей инфраструктуре существует понятие «группа хостов».
Группа хостов — это разметка для группы серверов, которая однозначно описывает их роль.
Например, news-prod-coolstream-blue. Это приводит к еще одному требованию: пользователи должны работать с сущностями высокого уровня — группами хостов, проектами и так далее.
Идея и реализация
Таллинг Централизованный межсетевой экран — это большая и сложная вещь, требующая настройки агента.Поиск проблем может занять более пяти минут, поэтому вместе с агентом и сервером появился инструмент, который сообщает пользователю, правильно ли настроен агент и что необходимо исправить.
Например, важным требованием к хосту является наличие группы хостов или записи PTR в DNS. Обо всем этом и многом другом инструмент расскажет вам ( его функции описаны ниже ).
Единый межсетевой экран Мы стараемся придерживаться следующего принципа: приложение, настраивающее фаервол на хосте, должно быть единственным, чтобы не получать «мигающие правила».
То есть, если на сервере уже есть свой инструмент настройки (например, если правила настраивает другой агент), то нашему приложению там не место.
Ну и обратное условие тоже действует: если есть наш агент межсетевого экрана, то правила настраивает только он — здесь действует принцип тотального контроля.
Брандмауэр не iptables Как вы знаете, iptables — это всего лишь утилита командной строки для работы с netfilter. Для переноса межсетевого экрана на разные платформы (Windows, BSD-системы) агент и сервер работают по своей модели.
Подробнее об этом ниже, в разделе "Архитектура" .
Агент не пытается устранить логические ошибки.
Как указано выше, агент не принимает никаких решений.
Если вы хотите закрыть порт 443, на котором уже работает ваш HTTP-сервер, не проблема, закройте его!
Архитектура
В архитектуре такого приложения сложно придумать что-то новое.
- У нас есть агент, он настраивает правила на хосте.
- У нас есть сервер, он отправляет пользовательские правила.
- У нас есть библиотека и инструменты.
- У нас есть резолвер высокого уровня — он меняет IP-адреса на группы хостов/проекты и наоборот. Подробнее обо всем этом ниже .
- ВЛАН
- Сеть
- Проект
- Группа хостов.
Например, news-prod-backend-api, где: news – проект; prod – его окружение, в данном случае это продакшн; бэкэнд – роль; api – произвольный пользовательский тег.
резольвер Межсетевой экран работает на сетевом и/или транспортном уровне, а группы хостов и проекты являются объектами высокого уровня.
Поэтому, чтобы «подружиться» с ними и понять, кому принадлежит хост (или виртуальная машина), необходимо получить список адресов — мы назвали этот компонент «High Level Resolver».
Он изменяет имена высокого уровня на набор адресов (в терминах преобразователя это «содержится») и, наоборот, адрес на имя объекта («содержит»).
Библиотека – Ядро Для унификации и объединения некоторых компонентов появилась библиотека, известная также как Core. Это модель данных со своими контроллерами и представлениями, позволяющими ее заполнять и читать.
Такой подход значительно упрощает код серверной части и агента, а также помогает сравнивать текущие правила на хосте с правилами, полученными с сервера.
У нас есть несколько источников для наполнения модели:
- файлы правил (два разных типа: упрощенный и полностью описывающий правило)
- правила полученные с сервера
- правила, полученные от самого хоста.
Роль агента минимальна: читать файлы правил (в том числе по умолчанию), получать данные от сервера (если он настроен на удаленную работу), объединять правила в один набор, проверять, отличаются ли они от предыдущего состояния и если они различаются, примените их.
Еще одна важная роль агента — не превратить хост в тыкву при первоначальной установке или при получении некорректного ответа от сервера.
Чтобы этого избежать, по умолчанию мы поставляем в пакет набор правил, например, таких как ssh, мониторинг доступа и так далее.
Если агент брандмауэра получит код ответа, отличный от 200, агент не будет пытаться выполнять какие-либо действия и выйдет из предыдущего состояния.
Но это не защищает от логических ошибок; если вы запретите доступ к портам 80, 443, агент все равно будет выполнять свою работу, даже если на хосте запущен веб-сервис.
Тулза Инструмент предназначен для системных администраторов и разработчиков, поддерживающих проект. Цель невероятно проста: в один клик получить все данные о работе агента.
Утилита может рассказать вам о:
- демон агента запущен?
- существует ли запись PTR для хоста?
- к каким группам хостов принадлежит хост?
- были ли конфиги изменены пользователем.
Сервер Сервер — это приложение + база данных.
Именно он выполняет всю логику работы.
Важной особенностью сервера является то, что он не хранит IP-адреса.
Сервер работает только с объектами верхнего уровня — именами хост-группы, проекта и т.д. Правила в базе данных следующие: Действие: Принять Src: project-B, project-C Dst: Project-B Proto: tcp Порты: 80, 443. Как сервер понимает, какие правила давать и кому? Из требований следует, что правила должны быть одинаковыми вне зависимости от того, где запущен агент, будь то хост или виртуальная машина.
Запрос от агента всегда приходит на сервер с одним значением — IP-адресом.
Важно помнить, что каждый агент запрашивает правила для себя, то есть он является пунктом назначения.
Чтобы было проще понять, как работает сервер, рассмотрим процесс получения правил хоста, принадлежащих проекту.
Резолвер начинает работать первым.
Его задача — изменить IP-адрес на имя хоста, а затем выяснить, какая сущность содержит этот хост. HL-Resolver отвечает серверу, что хост содержится в проекте A. HL-Resolver обращается к источнику данных (о котором мы не упоминали ранее).
Источник данных — это своего рода база знаний компании о серверах, проектах, группах хостов и т. д. Затем сервер ищет все правила для проекта с именем назначения = проекту.
Поскольку наша база данных не содержит адресов, нам необходимо разыменовать имена проектов в имена хостов, а затем в адреса, чтобы запрос снова отправлялся в источник данных через преобразователь.
HL-Resoler возвращает список адресов, после чего агент получает готовый список правил.
Если наш пункт назначения — хост с виртуальными машинами, то тот же сценарий выполняется не только для хоста, но и для каждой виртуальной машины на нем.
Ниже представлена диаграмма, показывающая простой случай: хост (аппаратный или виртуальный) получает правила для хоста в Project-A. 
Релизы
Нетрудно догадаться, что если у вас есть централизованное управление фаерволом, то и ломать все можно централизованно.Поэтому релизы для агента и сервера выполняются поэтапно.
Для сервера – Сине-Зеленый + A/B тестирование.
Blue-Green — это стратегия развертывания, в которой участвуют две группы хостов.
Причем переключение происходит порциями 1,3,5,10.100%.
поэтому, если возникнут проблемы с новой версией, это затронет лишь небольшую часть сервисов.
Для агента – Канарейка Canary (или канареечное развертывание) чем-то похож на A/B-тестирование.
Обновляем только часть агентов и смотрим метрики.
Если все хорошо, берем еще кусок побольше и так до 100%.
Заключение
В результате мы создали самообслуживание для системных инженеров, которое позволяет управлять доступом к сети из одной точки.Таким образом, мы:
- освободили системных инженеров от рутинных задач
- получили возможность аудита доступа с помощью понятного HTTP API
- исключена возможность получения нелегитимного доступа
- и конечно мы получили большой опыт разработки такого приложения.
-
Как Я Перешел На Ubuntu
19 Oct, 24 -
Новинки Xiaomi На Выставке Ces 2017
19 Oct, 24
