актуальные новости и полезные материалы в telegram канале
 
30 января 2022

Hardering Linux security

Статья 1

Содержание статьи

Введение

Очень часто IT инженеры, поддерживающие инфраструктурные системы предприятия, при внедрении комплексной ИБ сталкиваются с огромным перечнем задач, требующих от них проведения большого объема работ по настройке разного оборудования. Им приходится настраивать десятки, а иногда даже сотни и тысячи устройств при закрытии как внутренних требований ИБ, так и внешних (требования регуляторов и сертификаций).

Обычно это обусловлено тем, что при внедрении некоторых ИБ систем на активах сети приходится производить изменения конфигурации для подключения актива к системе, например:

  • при настройке SIEM систем требуется настроить массовое логирование активов, пересылку логов на десятках syslog серверов или изменить существующий уровень и детализацию логов на активах
  • при настройке систем контроля защищенности требуется настроить на активах специальные УЗ или разрешить соединение с тех или иных IP адресов системы

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

В цикле данных статей я хочу рассказать как о типовых мероприятиях ИБ, с которыми сталкиваются специалисты IT и ИБ в своей работе, так и о возможности их автоматизации на примере Linux систем и оркестратора Ansible.

Попутно я подробно рассмотрю базовый процесс настройки Linux активов для работы с SIEM системой и системой контроля защищенности.

А начнем мы с кусочка теории.

Теория

Немного теории ИБ.

Как известно защитные мероприятия ИБ делятся на 3 основных этапа:
  • превентивные мероприятия;
  • детективные мероприятия;
  • коррективные мероприятия.
1. Превентивные мероприятия

Предиктивные мероприятия идут первыми и в свою очередь состоят также из 3-х этапов.

1. 1 Управление активами:

Аудит систем и активов* — в итоге мы понимаем, что мы собственно говоря защищаем, результатом является:
  • Таблица систем и узлов, их населяющих. Также желательно собрать таблицу сервисов с портами, которые могут быть запущены на узлах.
  • Сбор технических характеристик активов — аппаратная платформа, тип операционных систем.
  • Сбор организационной информации — кто ответственен за актив, кто с ним работает и кому нужно какой предоставить доступ к активу по служебным обязанностям.

Аудит сетевого взаимодействия активов и систем — в итоге мы понимаем как и с кем должны взаимодействовать защищаемые активы на сетевом и транспортных уровнях результатом является матрица доступа, которую мы используем для формирования списков доступа для:
  • МСЭ самого актива (netfilter, брандмауэр);
  • сетевых МСЭ, маршрутизаторов с функцией МСЭ или маршрутизаторов уровня распределения;
  • коммутаторов доступа (при авторизации 802.1x на порту с передачей коммутатору Filter-Id Radius атрибута от системы авторизации, либо для обычных Port-Based ACL);
  • все вышеперечисленное дает нам базовую защиту от НСД и она в принципе может быть многослойной — то есть применяться на разных перекрывающих друг друга уровнях:
Уровень доступа сети (на входе трафика в сеть) - фильтрация на портах коммутатора доступа, куда подключаются пользовательские АРМ и другое оборудование доступа.
Уровень распределения сети — тут находятся маршрутизаторы, которые являются шлюзами для пользовательских АРМ и агрегаторами служебных сетей.
Уровень ЦОД — сетевые МСЭ или маршрутизаторы распределения в ЦОД, которые могут дополнительно защищать служебные сервера.
Уровень МСЭ систем виртуализации — да-да, системы виртуализации могут поддерживать фильтрацию трафика между ВМ и миром и ВМ-ВМ.
Уровень МСЭ самих узлов — файерволы в ОС на серверах и рабочих станциях.
Уровень приложения — функционал ИБ, который предоставляет сам сервис, работающий на сервере.
  • управление учетными данными;
  • настройка активов в соответствии с результатами аудита и принятыми стандартами ИБ (внутренними или внешними).

1.2 Управление уязвимостями:
  • сбор данных об уязвимостях узлов, их сервисов и ПО — здесь речь идет по сути об инвентаризации активов и установленного на них ПО;
  • устранение найденных уязвимостей.

1.3 Соответствие стандартам ИБ:
Здесь ведется постоянный контроль и мониторинг параметров и настроек активов на соответствие:
  • внутренним корпоративным стандартам;
  • международным стандартам или требованиям регуляторов.

*под активами понимаются любые узлы - сетевое оборудование, арм, сервера, СРЗИ, voip терминалы, СКУД контроллеры, видеорегистраторы и т.д.

2. Детективные мероприятия

Детективные мероприятия по своей сути крутятся вокруг SIEM систем и:
  • сбора событий ИБ и системных событий непосредственно с самих активов;
  • автоматического поиска в них подозрительных событий или цепочек событий с помощью правил корреляции, которые по сути и составляют "функционал охоты на злоумышленника";
  • оповещения о событии/инциденте отдела ИБ/IT и/или системы SOAR (Security Orchestration, Automation and Response).

3. Коррективные мероприятия

Коррективные мероприятия в свою очередь замыкают круг ИБ мероприятий. К ним относится:
  • расследование/forensic — это все, что касается расследования события/инцидента и ИБ (кто, где, когда, чем и как нарушил и что теперь с этим делать);
  • корректировка/изменение — сюда попадают мероприятия, которые принимаются по результату расследования события/инцидента.

Могут начинаться:
  • тюнингом настроек SIEM систем — обычно это изменение правил корреляции в следствии false-positive срабатываний.

Продолжаться:
  • изменением настроек ИБ на активах и средствах защиты (например добавления запрещающих правил или ограничение полномочий УЗ).

И могут заканчиваться:
  • как правкой/доработкой разделов политики ИБ — тут как правило идут глобальные решения, такие как отключение сервисов, внедрение доп. систем защиты, изменение организационного расписания для сотрудников;
  • так и различными штрафными санкциями в отношении внутренних и внешних нарушителей.

    Практика

    Теперь перейдем к практике.

    Хочу заметить, что в ходе практики я буду рассматривать следующие разделы теории:

    1. Предиктивные мероприятия:

    Управления активами:
    • аудит активов и систем, их взаимодействие;
    • настройка активов (сервера Linux) в соответствии с результатами аудита и своим внутренним стандартом ИБ, который я определю для себя далее.

    Управление уязвимостями:
    • здесь я постараюсь показать примеры работы с поисками уязвимостей и типовыми шагами по их устранению.

    2. Детективные мероприятия: здесь я покажу на примере работу SIEM системы (а также мы устроим "охоту на ведьм").

    3. Коррективные мероприятия: здесь я рассмотрю типовые примеры, которые мы примем в результате расследования инцидентов ИБ.
    Схема сети
    Для демонстрации практических действий по усилению ИБ я создал в своей виртуальной лаборатории несколько систем, эмулирующих кусочек инфраструктуры предприятия (чрезвычайно маленький кусочек).
    На самом деле на картинке у меня приведена некая целевая схема, к которой я буду стремиться. Обычно в начале пути предприятия не имеют таких систем ИБ как:
    • SIEM
    • VMControl и VMControl1
    • Honeypot/Weak

    Поэтому на первых этапах их не будет и у меня, но по ходу выхода статей я буду добавлять их.

    Этап 1 — превентивные мероприятия:

    И начну я демонстрацию с самого первого и зачастую самого трудоемкого и нелюбимого шага для ИБ специалиста — предиктивных мероприятий и документирования.

    Первоначальный аудит систем и активов

    Для того, чтобы двигаться дальше к аудиту систем и активов и анализу их сетевого взаимодействия мне необходимо сделать небольшое отступление.
      Процесс организации и распределения IP адресов при проектировании и построении сети называется IPAM (IP Address Management).
      На самом деле это чрезвычайно важный процесс как для сетевых IT инженеров, так и для инженеров ИБ.

      С точки зрения IT — правильная организация IP адресных пространств помогает уменьшать таблицы динамической маршрутизации путем агрегирования IP сетей отдельных филиалов и анонсирования summary маршрута соседям. На практике я встречал в опорной OSPF backbone сети L3 коммутаторы, у которых маршруты не помещались в TCAM (память устройства, которая содержит MAC/QOS ACL, IP/TCP ACL на основании которых возможно производить фильтрацию и приоритезацию трафика, а также таблицы маршрутизации). Из-за этого устройства начинали использовать системные ресурсы CPU и RAM коммутаторов для обработки маршрутов, что в свою очередь увеличивало загрузку устройств вплоть до 90 -100% и иногда приводило к потерям трафика.

      С точки зрения ИБ       — правильная организация IP адресных пространств помогает в организации и контроле политики НСД путем составления и мониторинга списков правил доступа ACL. Довольно часто встречается такая ситуация:

      Следующие системы могли сидеть в одном VLAN и одной IP сети:
      • видеонаблюдение
      • СКУД
      • пользовательские АРМ
      • пожарная безопасность
      • ИБП
      • сервера, которые обслуживают эти подсистемы
      • управление коммутаторами и роутерами

      Такая организация сети практически не поддавалась контролю трафика (на самом деле нет ничего не возможного и в принципе контролировать трафик в такой сети можно, но трудоемкость работ при этом столь высока, что зачастую проще переделать сеть и организовать ее правильную структуру, чем работать в существующей).

      А теперь представьте, что без контроля и ограничения трафика в такую сеть попадает шифровальщик или злоумышленник — это для него идеальные условия:
      • все IP и все tcp/udp порты находятся в прямой доступности;
      • фильтрация трафика на портах коммутаторах доступа в таких сетях зачастую не реализуется;
      • встроенные Host-Base Firewall (внутренние МСЭ оборудования) также зачастую не настраиваются, либо настраивать их очень тяжело ввиду того, что разделение происходит не по подсетям, а по IP адресам. Это приводит к громадному количеству правил доступа и их постоянному обновлению на всех узлах, входящих в одну подсеть. Как я писал выше все это практически не подлежит нормальному обслуживанию.

        Важность процесса IPAM на стадии проектирования и построения сети ни в коем случае нельзя недооценивать.

        Как правило IPAM предприятия можно организовать одним из следующих способов:
        • горизонтально;
        • вертикально;
        • смешанно;
        • бессистемно.

        Кратко расскажу про каждый из них на примере типовой задачи. Есть 4 разнесенных географически региональных офиса (штаб-квартиры), к каждому из офисов подключены несколько десятков филиалов региона. Необходимо распределить между всей структурой пространства серых сетей 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16.
        Дальше адресные пространства делятся между самим офисом и подключенными к нему филиалами. При этом разным системам нарезаются произвольные сети любой длины из любого выданного диапазона.
        Дальше офисам и филиалам выдают подсети под каждую систему из этих адресных пространств. При этом разным офисам и филиалам нарезаются произвольные сети любой длины из любого выданного диапазона.
        Дальше сети разделяются пропорционально по филиалам с сохранением структуры адресного пространства систем. Существует и обратный вертикально-горизонтальный подход к организации IPAM, но смысл остается тем-же — эффективное контролирование адресного пространства, которое в дальнейшем упростит внедрение ИБ.
        Отсутствие организации IPAM характерно для хаотично-строящихся сетей (без какого-либо проекта или оценки). К сожалению, бессистемная организация IPAM в организациях встречается гораздо чаще, чем остальные виды (особенно в государственных бюджетных организациях).

        Ввиду того, что бессистемная организация IPAM встречается очень часто, именно ее я буду использовать у себя в качестве примера (да и возможности моей существующей виртуальной лаборатории ограничены), поэтому сети 10.30.0.0/24 и 192.168.168.0/24 будут сразу c несколькими служебными системами в каждой.

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

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

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

        На этом закончим рассмотрение IPAM и перейдем к аудиту и созданию матрицы доступа активов и систем.
        Systems and population
        Как мы помним в ходе аудита необходимо собирать информацию об инфраструктуре предприятия, которую нужно защищать. Делать это можно двумя основными методами:

        • ручной — собирать информацию об активах и системах путем обсуждения структуры сети, ее активов, сервисов, их настроек и сетевого взаимодействия с IT инженерами
        • автоматический — с помощью различных систем мониторинга узлов и трафика, систем аутентификации/авторизации, а также аудита узлов специализированным ПО

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

        • ручной — очень трудоемкий и затратный процесс в ходе которого запросто могут быть упущены важные технические детали, например наличие отдельных уязвимых сервисов на серверах о которых никто не знает или все забыли (серверы ntp, web, dns, dhcp, db и т.д.). Но неоспоримым плюсом данного подхода является то, что в ходе аудита вы сможете понять важность и критичность той или иной системы и активов, что невозможно при автоматическом сборе информации.
        • автоматический — тут ситуация в точности наоборот. Автоматический метод уменьшает трудоемкость сбора технической информации с активов и сети так как выполняется скриптами пентест-сканирования и/или системных проверок, либо выгрузкой информации с различных систем управления и мониторинга. Но его главным минусом является неспособность определить критичность систем и узлов их населяющих. Например, с точки зрения данного метода web-сервис запущенный на платах управления ИБП ничем не отличается от WEB-сервисов, которые запущены на кластере серверов в DMZ зоне, работающих с ПДН и обслуживающих коммерческие услуги, предоставляемые компанией.

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

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

        Итак, после нескольких часов/дней/недель упорного труда в части исследования инфраструктуры я получаю следующую примерную картину систем* и их популяции:
        * здесь указаны не все системы, присутствующие на схеме сети, так как остальные системы будут появляться дальше по мере выхода статей

        Как вы наверное заметили, формат такой записи активов (узлов и сетей) не случаен — я буду использовать его в дальнейшем.

        В общем виде у меня записывается он так: Host/Network Number : OS type : Interface name : IP address/network

        Host/Network number — поля для обозначения типа актива (узел или подсеть) и порядковый номер
        • H1 — первый узел в системе, H2 — второй и т.д., примечательно здесь то, что у одного узла может быть несколько интерфейсов с разными IP адресами и разным набором сервисов на них (система Internet-Access)
        • N1 — первая подсеть в системе, N2 — вторая и т.д. Как я уже говорил в разделе IPAM правильное распределение IP пространств облегчает работу ИБ в части построения матрицы доступа

        OS type — поле описывающее тип ОС узла. Поле пригодится при работе с ansible:
        • Lin — операционная система типа Linux, то есть система, которая может управляться по протоколу ssh. Ansible может управлять устройствами с этой ОС.
        • Win — операционная система типа Windows.

        Interface name — поле описывающее интерфейсы узла. Это поле предназначено для тех узлов, у которых есть несколько интерфейсов с разными IP адресами. Если поля нет в записи, то у узла только 1 основной IP адрес

        IP address/network — IP адрес узла или подсеть:
        • узел должен иметь только IP адрес (без /префикса сети)
        • сеть должна иметь префикс != /32

        Ознакомившись с системами я начинаю разбираться с их владельцами и ответственными за работу системы. Тут надо заметить, что в общем случае не всегда ответственный = владелец системы, например: есть бизнес-система, которую заказал себе в рабочих целях коммерческий отдел, например, для учета продаж. По сути с системой будут работать в основном сотрудники самого коммерческого отдела - то есть владельцем системы будет сам отдел (его руководители).

        Ответственными же за систему будут в данном случае:
        • коммерческий отдел — так как он организует работу в системе, внесение информации и ее изменение, а также определяет круг сотрудников и их права доступа к этой информации
        • IT отдел — так как он организует поддержку работоспособности системы, ее серверов, сетевой части и приложений
        • отдел программирования — так как он по требованию коммерческого отдела вносит изменения в работу приложений системы

        В моем случае:
        • сотрудники коммерческого отдела располагаются в сетях принадлежащих системе LAN-Users
        • IT отдел/администраторы являются также и программистами (работают в отделе программирования на пол ставки) и располагаются все с сетях принадлежащих системе LAN-Admins

        И в итоге у меня получается такая организационная таблица для систем:
        Здесь бизнес критичность это по сути некое внутреннее категорирование для понимания важности системы и ее узлов. Предполагается, что под регуляторные требования КИИ компания не попала.

        В основном понимание критичности мне нужно для понимания того, что мне нужно защищать в первую очередь и с какой тщательностью (сколько человеческих ресурсов и денег для СРЗИ на это потратить), но здесь обязательно помнить, что защита информации это триада "С-I-A", поэтому каждую систему и хранимую ей информацию вы должны анализировать по:
        • конфиденциальности — как защищена система (и ее информация) от кражи/утечки? что произойдет, если данные украдут/обнародуют/продадут мошенникам? контролируется несанкционированный доступ к ней? а ACL внедрены? а учетки как контролируются? а логи ведутся — кто где аутентифицируется и что выполняет? а кто что скачивает и кому какие пересылает файлы по почте/мессенджерам?
        • целостности — как защищена система от нарушения целостности? а кто может вносить в нее изменения? а бэкапы делаются?
        • доступности — как обеспечивается доступность? а она вообще отказоустойчива? а кластеризация и резервирование есть? А что будет если умрет вот, например, ну вот этот вот узел с IP = 10.10.30.2 из Network системы? много денег потеряется и инфарктов случится?

        На этом аудит систем пока закончен. Перейдем к матрице доступа.

        Аудит сетевого взаимодействия

        Access matrix
        В целях облегчения восприятия матрицы доступа я разнесу системы по группам и для этого в своей сети я определил следующие группы систем:
        • local — локальные сети пользователей;
        • internal — внутренние служебные системы — сеть, сервера ЦОД с сервисами;
        • external — внешние служебные системы — сюда как правило попадает граничное оборудование (Edge) сети, сервера ЦОД и расположенные в DMZ сети к сервисам которых есть прямой доступ из интернета;
        • public — внешние ресурсы (глобальная сеть интернет и ресурсы располагающиеся в ней).

        Потратив еще N-е количество времени на анализ документации сети и систем, сетевых потоков (flow), файлов конфигурации, систем мониторинга, а также проведя пару совместных вечеров с IT инженерами в попытках разобраться что да как работает, я составляю матрицу доступа для систем в зависимости от их расположения в сети.

        Ниже я привожу матрицу доступа между системами и их активами также в некоем формате, так как эти записи понадобятся мне позднее. Пояснения по поводу формата записей также будут даны далее.
        Local systems
        Данную таблицу следует читать так:

        NOC — доступ с узлов системы контроля управления сетью в локальные сети с АРМ запрещен.

        Network — доступ с узлов сетевой системы в локальные сети с АРМ запрещен.

        knowledge-base — доступ с узлов из внутренней базы знаний в локальные сети запрещен.

        Application1 — доступ с узлов данной web-системы в локальные сети запрещен.

        Internet-Access — доступ с узлов системы доступа в интернет в локальные сети запрещен.

        LAN-Users:
        1. Доступ с узлов системы к узлам этой же системы я не рассматриваю, так как по большей части рабочие АРМ состоят из узлов с Windows, которую не администрируют с помощью Ansible, для этого есть структура AD и групповые политики.

        Но на самом деле это не совсем корректно — помните, что вы можете запрещать локальный трафик между узлами как на самих АРМ, так и на портах коммутаторов доступа (или хотя бы маршрутизаторах распределения). более безопасной практикой является запрет локального трафика между узлами как внутри одной LAN, так и между LAN. Организация обмена служебными файлами в таком случае внутри подразделения и отдела (АРМ в одной L2/L3 сети) и между подразделениями (АРМ в разных L2/L3 сетях) может происходить через центральные или локальные файлобменные сервера, к которым у АРМ есть доступ например по HTTPS | FTPS, либо через служебную почту.

        Данный способ позволит:
        • Во-первых: контролировать и разграничивать доступ к передаваемой и хранимой информации (а не так, что файлы лежат в открытом доступе на локальной шаре АРМ и все могут их прочитать, а еще и закинуть что-нибудь в общую папку)
        • Во-вторых: усложняет распространение зловредного ПО и перемещение нарушителя при компрометации АРМ так как трафик между локальными АРМ и в другие локальные сети запрещен, разрешен только к рабочим служебным серверам в локальном ЦОД или основном ЦОД организации. Как правило служебные сервера обычно защищены лучше АРМ и стоят под непрерывным наблюдением и мониторингом.
        • В-третьих: упрощает централизованное сканирование рабочих файлов на предмет зловреда (песочница/ локальные антивирусы на файловых серверах).

        2. Доступ между локальными пользовательскими АРМ и АРМ администратора к примеру я пометил как запрещенный и при необходимости на маршрутизаторе распределения или коммутаторах доступа можно реализовать такую блокировку с помощью ACL.

        LAN-Admins — аналогично с пользовательскими АРМ.

        Internet — здесь прямой доступ из интернета в локальные сети абсолютно запрещен (как и наоборот), что в целом логично.
        Internal systems
        Данную таблицу следует читать так:

        NOC — доступ с узлов системы на:
        • узлы NOC стоит прочерк так как у меня в этой системе только один узел, если было бы больше, то я бы разрешал доступ между узлами системы отдельно.
        • узлы Network — разрешен только по ssh порту tcp/22 и разрешен любой трафик icmp
        • узлы knowledge-base — разрешен только по ssh порту tcp/22 и разрешен любой трафик icmp
        • узлы Internet-Access — разрешен: по ssh порту tcp/22, по порту tcp/3128 — это прокси порт SQUID, разрешен любой трафик icmp
        • узлы внутреннего DNS сервера только на порт udp/53 и icmp

        Network — разрешен доступ к серверам системы NOC по портам FTP | SSH это в основном нужно для скачивания прошивок обновления и других файлов (и да -лучше отказаться от tftp).

        knowledge-base — доступ с узлов системы на:
        • узлы NOC — запрещен
        • узлы knowledge-base — разрешен между: серверами по ssh порту tcp/22 — так как через него происходит резервное копирование и восстановление основной директории сервиса confluence, серверами по порту tcp/5432 — это порт данных базы PostgreSQL, которое confluence использует как хранилище данных
        • узлы Internet-Access — по порту tcp/3128 — это прокси порт SQUID
        • узлы внутреннего DNS сервера только на порт udp/53

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

        LAN-Users — web доступ к серверам базы знаний, SQUID и DNS.

        LAN-Admins — все то же, что и для пользователей, а также доступ к серверу NOC для управления сетью.

        Internet — прямой доступ во внутренние служебные сети запрещен.
        External systems
        Данную таблицу следует читать так:

        NOC — доступ с узлов системы на узлы Application1 — разрешен только по ssh порту tcp/22 и разрешен любой трафик icmp.

        Network — доступ запрещен.

        knowledge-base — доступ запрещен.

        Application1 — внутри системы доступ разрешен:
        • для web нод к db нодам с mysql, работающим в кластере active/passive
        • между самими db нодами mysql.

        Internet-Access         — доступ запрещен.

        LAN-Users — доступ разрешен только к web нодам системы.

        LAN-Admins — доступ разрешен только к web нодам системы.

        Internet — доступ разрешен только к web нодам системы.
        Public systems
        Здесь всем системам прямой выход в интернет запрещен, только через прокси.

        Разрешен доступ только для самой системы Internet-Access (SQUID proxy).

        Здесь нужно понимать, что мы говорим про МСЭ типа ZBF со statefull инспекцией:
        • если был пропущен по какому-либо правилу пакет tcp SYN к серверу ( статус соединения NEW)
        • то назад автоматически пропускаются ответные пакеты SYN/ACK от сервера (статус соединения ESATBLISHED и при необходимости RELATED)
        Записи по сути означают правила фильтрации трафика для встроенного МСЭ Linux — netfilter, который мы будем настраивать с помощью пользовательской утилиты iptables.

        Также ими можно руководствоваться для фильтрации трафика управления сетевого оборудовании — для составления ACL доступа или trusted хостов.

        Правила фильтрации для подсетей можно применять для фильтрации на сетевых устройствах — коммутаторах, маршрутизаторах и МСЭ.

        Формат записей в матрицах доступности, который я использовал выше, следующий:

        Полная запись — ip_src : src_port→ip_dst : protocol1/protocol2 : dst_port
        • ip_src — IP адрес узла источника трафика
        • src_port — порт узла источника трафика
        • ip_dst — IP адрес узла назначения
        • protocol1/protocol2 — тут перечисляются протоколы (в основном это tcp/udp)
        • dst_port — порт узла назначения

        Сокращенная запись:
        • any→any — означает, что разрешен любой трафик с любых узлов-источников системы1 без указания исходного порта на любые узлы-назначения системы2 без указания порта назначения по любому протоколу (только на основе IP заголовка пакета)
        • any→any:protocol:dst_port — означает, что разрешен трафик с любых узлов-источников системы1 на любые узлы-назначения системы2 только по определенному протоколу и порту назначения

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

        Мы получили системы с узлами и матрицы доступа для систем, а что же дальше?

        Настройка Linux firewall

        А дальше первым шагом мы попробуем настроить наши средства защиты на Linux узлах в соответствии с нашей матрицей доступа и контролировать их актуальность.

        В общем случае под средствами защиты подразумеваться может любое устройства или ПО несущее функционал безопасности, например, это могут быть:
        • коммутаторы доступа, которые обеспечивают фильтрацию трафика на портах доступа, обнаруживают смену мак адресов на пользовательских портах и могут делать много всего остального;
        • маршрутизаторы распределения, которые контролируют трафик с помощью ACL, поддерживают, например, протокол uRPF, а также является источником netflow трафика в системе анализа сетевого взаимодействия;
        • внутренние МСЭ серверов и АРМ;
        • антивирусное ПО на серверах и АРМ;
        • и многое другое.

        Так как мы рассматриваем Linux системы, то будем работать с их внутренним МСЭ — netfilter и утилитой для его настройки iptables.

        И вот тут на сцену поднимается средство оркестрации — Ansible, с помощью которого мы и будем настраивать и актуализировать правила для netfilter.

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

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

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

        Используя данную таблицу мы сможем сгенерировать inventory файл для Ansible и файл переменных ansible с перечнем правил iptables для узлов.

        Заключение

        Таким образом в ходе данной статьи мы:

        1. Рассмотрели типовые мероприятия ИБ.
        2. Реализовали часть превентивных мероприятий на практике:
        • провели аудит систем и населяющих их узлов;
        • провели аудит сетевого взаимодействия между узлами различных систем;
        • подготовили исходные следующие исходные файлы, с которыми будет в дальнейшем работать ansible: файл инвентаризации — system и файл переменных для роли firewall - iptables.yml.

        На этом я закончу первую статью цикла.

        Во второй перейдем к тестовой настройке МСЭ на наших Linux узлах с помощью сгенерированных файлов и ansible.

        Всем спасибо.

        Автор: Иван Богучарский, инженер TS Solution