Что такое правила межсетевого экрана

Вопрос: Возможно ли с помощью правил Межсетевого экрана заблокировать трафик только между двумя хостами локальной сети?

Ответ: С помощью правил Межсетевого экрана заблокировать трафик между двумя хостами одной локальной сети нельзя, так как хосты находятся в одном сегменте и обмен между ними проходит на втором уровне модели OSI. Межсетевой экран работает на третьем уровне модели OSI.
Заблокировать трафик возможно только между всеми хостами, которые находятся в разных сегментах сети, включением функции isolate-private (блокирует связь полностью между сегментами), или с помощью отдельных правил Межсетевого экрана, блокируя доступ только для некоторых хостов.

Гайд по межсетевому экранированию (nftables)

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

В качестве межсетевого экрана будем использовать nftables, функционирующий под управлением ОС Debian GNU Linux.

Требования к предварительным знаниям

Технические требования

Создание шаблона виртуальной машины

1. Скачать Debian 11.4 в формате netinstall .
2. Установить ОС в минимальной конфигурации. Для этого во время инсталляции выбираем все параметры по умолчанию (Next, Next, Next, . ), а на шаге с выбора пакетов «Software selection» отказываемся от всего предлагаемого (Рисунок 1).

Рисунок 1

• OpenSSH сервер (пакет ssh).
• Файловый менеджер Midnight Commander (пакет mc).
• Утилиту conntrack, демонстрирующую внутреннее состояние брандмауэра и помогающую в отладке правил фильтрации (пакет conntrack).

Типовой сценарий: защита сервера / рабочей станции с помощью локального брандмауэра

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

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

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

1. Формулирование модели угроз.
2. Анализ угроз и выработка мер по их нейтрализации. На данном этапе необходимо сформулировать схему разграничения трафика: то есть какой трафик пропускаем, а какой блокируем.
3. На основании схемы разграничения трафика производится настройка межсетевого экрана: формируются правила фильтрации, настраиваются сервисы, пишутся скрипты и так далее.

Модель угроз

Теперь проанализируем угрозы и сформулируем идеи по их нейтрализации.

Для парирования угрозы У1 и У5 необходимо лишить злоумышленников возможности осуществлять подключения к сетевым сервисам узла. Это достигается путем ограничения входящего трафика по портам и адресам источника (белые или черные списки).

Нейтрализация У2.1 базируется на ограничении скорости получения сервисом сетевых пакетов, а как более сложный вариант — обнаружение атакующих узлов и блокировка их по IP. Следует отметить, что ограничение максимальной частоты подключений не всегда допустимо, особенно для публичных сервисов.

Угроза У2.2. нейтрализуется путем отбрасывания всех сетевых пакетов, имеющих адрес источника из подсети 127.0.0.0/8 и пришедших не с петлевого (loopback) интерфейса.

Для нейтрализации угрозы У3 в общем случае требуется применение дополнительных программ, которые бы определяли факты неудачных попыток авторизации, определяли бы IP адреса атакующих, а затем с помощью брандмауэра блокировали бы их по IP. Реализации защиты от угрозы У2.1. частично усложнит злоумышленникам возможность реализации угрозы У3.

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

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

Схемы разграничения трафика

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

Ограничение исходящего трафика по адресам назначения на рабочих станциях, где активно пользуются Интернетом, крайне трудоемко, а ограничивать трафик по приложениям брандмауэр nftables не умеет. Соответственно, весь исходящий сетевой трафик разрешается без ограничений. Угроза У3 полностью игнорируется. Как слабенький вариант борьбы с У3 можно рекомендовать применение встроенной системы мандатного разграничения доступа (MAC) AppArmor, которая позволяет выбранным приложениям отключить сетевые возможности. Проблема в том, что AppArmor работает только по черным спискам, белый список – замкнутую программную среду — с его помощью сделать не получится.

Рассмотренная схема разграничения трафика позволяет полностью нейтрализовать угрозы У1, У2, У3, У5, угроза У4 игнорируется.

По умолчанию встроенный брандмауэр ОС Windows работает по этой схеме.

• разрешается входящий трафик по выбранным сетевым портам, требуемым для работы сетевым сервисам;
• блокируется входящий трафик для IP-пакетов, адрес источника которых относится к сети 127.0.0.0/8, и которые пришли не с петлевого (loopback) интерфейса.

Реализация данной схемы частично защищает от У1 и полностью от У2.2 и У5, остальные же угрозы игнорируются.

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

• для каждого открываемого сетевого сервиса (при наличии возможности) настраивается:
  • ограничение по максимальной частоте (rate) попыток подключения;
  • ограничение по перечиню узлов, имеющих право на подключение (белый список);
  • использование дополнительных средств обнаружения большого количества неудачных попыток авторизации, после чего нарушителя с помощью брандмауэра блокируют по IP;

  Практическая работа: реализация межсетевого экранирования сервера по схеме усиленной защищенности

  Описание стенда

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

  Здесь все просто. Есть одна виртуальная машина «Сервер». Она подключена своим единственным сетевым адаптером к виртуальной сети «NAT». В данной сети присутствует виртуальный маршрутизатор, реализующий NAT и выполняющий роль DNS-сервера. Сетевой адаптер гипервизора также подключен к сети «NAT». В качестве защищаемого сервиса на виртуальной машине «Сервер» будет выступать SSH. Для его тестирования на гипервизоре устанавливается SSH-клиент.

  Задача

  Подготовка стенда

  1. На виртуальную машину «Сервер» установим OpenSSH сервер и службу автоматической синхронизации системных часов systemd-timesyncd:
  2. В файле настроек службы синхронизации времени /etc/systemd/timesyncd.conf раскомментируем строки NTP и FallbackNTP. Строку NTP запишем в следующем виде:
  3. Активируем автоматическую синхронизацию времени, выполнив заклинание:

  Ход выполнения работы

  1. Логика организации дистрибутива Debian такова, что межсетевой экран nftables установлен в нем по умолчанию. В этом можно убедиться, выполнив заклинание:
  2. Для автоматической загрузки правил межсетевого экранирования после старта системы создана служба nftables (по сути являющаяся systemd юнитом), но по умолчанию она деактивирована. В этом можно убедиться, выполнив заклинание: Служба организована таким образом, что при запуске она считывает правила, записанные в файле /etc/nftables.conf. Соответственно, цель нашей работы — внести в данный файл необходимые правила и активировать службу.
  3. Уточним схему разграничения сетевого трафика. Как часто бывает, те схемы, которые мы описывали ранее, не могут учитывать особенности эксплуатации конкретных серверов, поэтому и требуют уточнения. В частности, сделаем следующее:
     • Разрешим «пинговать» (использовать команду проверки сетевой связности ping) защищаемый сервер и разрешим серверу «пинговать» другие узлы. Несмотря на то, что каждый открытый поток сетевого трафика снижает защищенность, открытие «пингов» существенно улучшает эксплуатационные свойства сервера.
       Для этого разрешим входящие и исходящие ICMP echo-request.
     • Разрешим отправлять запросы и получать ответы по протоколу DNS.
       Для этого разрешим исходящие соединения по портам: TCP 53 и UDP 53 в адрес явно указанного DNS сервера: 172.30.0.2.
     • Разрешим автоматически обновлять системные часы по протоколу NTP.
       Для этого разрешим исходящие соединения по портам: TCP 123 и UDP 123 в адрес серверов, указанных в файле /etc/systemd/timesyncd.conf.
     • Разрешим скачивать обновления с репозиториев, указанных в файлах настройки менеджеров пакетов.
       Для этого разрешим исходящие http соединения (TCP 80) в адрес репозиториев, указанных в файле /etc/apt/sources.list.
     • Будем явно отбрасывать входящий трафик, превышающий скоростные ограничение в:
       • 5 пакетов в секунду для ICMP;
       • 10 попыток установки соединений в минуту для SSH.
     • Узлы, занимающиеся подборкой паролей к SSH, будем определять с помощью утилиты fail2ban. Утилита сама будет конфигурировать nftables для блокирования и разблокирования атакующих узлов.
  4. В файл /etc/nftables.conf запишем следующее содержимое:

  • репозиториев, указанных в файле /etc/apt/sources.list;
  • NTP-серверов, указанных в файле /etc/systemd/timesyncd.conf.

  На самом деле fail2ban по умолчанию защищает SSH-сервер сразу после установки. Единственное, что необходимо сделать, так это поменять действия, выполняемые при блокировке. По умолчанию они рассчитаны на iptables (предшественника nftables), нам же требуется их поменять для nftables.

  Сделать это очень просто. В конфигурационном файле /etc/fail2ban/jail.conf в секции [DEFAULT] значение параметров banaction и banaction_allports необходимо поменять на nftables-multiport и nftables-allports соответственно. Затем перезапустить службу заклинанием
  Для блокировки нарушителей fail2ban добавляет к правилам фильтрации nftables новую таблицу f2b-table. Эта таблица содержит единственную цепочку f2b-chain, имеющую более низкий приоритет и соответственно срабатывающую раньше, чем тем цепочки, что мы создавали в файле /etc/nftables.com. Единственным правило цепочки f2b-chain является блокировка доступа к порту ssh (tcp 22) для IP-адресов, включенных в список addr-set-sshd. Пример рассмотренных списков и правил фильтрации, при добавлении туда нарушителя, выглядит следующим образом (Рисунок 3):

  
  Рисунок 3

  Типовая задача: проверка работы брандмауэра

  Очень часто на практике возникает задача проверить, работает ли межсетевой экран. Сделать это можно тривиальным образом: попробовать «пингануть» защищаемый узел или попробовать обратится к какому-либо защищаемому сетевому сервису.

  Иногда специалисты по информационной безопасности могут потребовать от системных администраторов провести полную гарантированную проверку (аттестацию) всех правил фильтрации. Например, проверить на возможность открытия UDP и TCP порты из всего возможного диапазона (1-65535).

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

  Не самым удобным, но очень доступным вариантом решения этой задачи будет следующий: с помощью утилиты netcat на проверяемом сервере при включенном брандмауэре открываются UDP или TCP порты, а затем сервер с помощью утилиты nmap сканируется с другой машины. Если обнаруживаются порты, которые не должны быть открытыми, то с межсетевым экраном есть проблемы.

  Практическая работа: проверка работы брандмауэра

  Описание стенда

  Задача

  Подготовка стенда

  1. На виртуальную машину «Сервер» поставим две дополнительные утилиты: «netcat» и «netstat». Для этого выполним заклинание:
  2. На гипервизор, а именно с него мы и будем сканировать, установим nmap.

  Ход выполнения работы

  1. Перечень открытых портов на сервере можно узнать с помощью утилиты netstat. Для UDP портов заклинание будет таким: а для TCP портов таким:
  2. Удаленную проверку доступности открытых портов будем проводить с помощью nmap. Например, для проверки порта UDP 100:
     или для проверки порта TCP 100:
  3. Для того чтобы проверить порты, которые никто не слушает, воспользуемся утилитой netcat и откроем их. В частности, для открытия порта UDP 100 выполним следующее заклинание:

  Типовой сценарий: сегментирование локальной сети маршрутизатором с функцией брандмауэра

  Хорошей практикой защиты локальных сетей является их сегментация – разделение плоской сети на подсети с последующим разграничением и контролем трафика между ними.
  В корпоративных сетях, как правило, выделяют следующие сегменты: сегмент пользовательских рабочих станций, сегмент серверов, сегмент технологического оборудования (например, системы видеонаблюдения), сегмент серверов, имеющих доступ из Интернет (DMZ) и другие сегменты. Каждый сегмент может в свою очередь быть разделен на полсегмента и так далее.

  Существует несколько способов сегментации, но наиболее распространенной является сегментация на сетевом уровне (L3), когда каждому сегменту присваивается своя IP-подсеть, а разграничение доступа осуществляется маршрутизаторами с функцией брандмауэра.

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

  Важно отметить, что в корпоративных сетях доступы пользователей, как правило, бывают типовыми. Например, все сотрудники отдела продаж должны иметь доступ к Web-интерфейсу системы учета клиентов (customer relation management, CRM). С точки зрения учета и управления доступами можно сказать, что таким пользователям назначается роль «Доступ к Web-интерфейсу CRM». Поэтому очень важно сделать правила фильтрации таким образом, чтобы можно было просто и единообразно добавлять доступы пользователям. Требование единообразия важно еще и потому, что любую систему разграничения доступа нужно периодически проверять, а зоопарк вариантов предоставления доступов серьезно осложнит эту задачу.

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

    Примечание 2. Большинство серверов enterprise уровня имеют несколько сетевых адаптеров. Например, один рабочий, с помощью которого он обслуживает целевые запросы клиентов, а второй служебный, используемый, например, для систем удаленного управления типа iLO, IPMI, iDrac и др. Поэтому корректнее говорить не «помещение сервера в отдельный сегмент», а «помещение сетевого интерфейса сервера в отдельный сегмент». Нормальной является ситуация, когда все сетевые адаптеры сервера находятся в различных сетевых сегментах.

    Практическая работа: разграничение трафика между пользовательским и серверным сегментами

    Описание стенда

    Дан макет корпоративной сети (Рисунок 4), в которой присутствуют две подсети: 192.168.0.0/24 – для пользовательского сегмента и 172.30.0.0/24 — для серверного сегмента. В макете эти две сети представлены виртуальными сетями: «Custom11» и «NAT» соответственно. Виртуальная машина FW снабжена двумя сетевыми интерфейсами, каждый из которых «смотрит» в свою виртуальную сеть. Данная машина выполняет функции маршрутизатора и брандмауэра.

    
    Рисунок 4

    Задача

    Server1	Server2	Виртуальный маршрутизатор
    User1	TCP:80	TCP:80	UDP:53
    User2	TCP:22	TCP:22	UDP:53

    Подготовка стенда

    1. Средствами системы виртуализации создадим отдельную виртуальную сеть (VMnet), которую назовем «Custom11».
    2. Ранее созданный шаблон виртуальной машины растиражируем в 5 отдельных экземпляров: FW, User1, User2, Server1, Server2.
    3. К виртуальной машине FW добавим второй виртуальный сетевой адаптер, который соединим с сетью «Custom11». Ее первый сетевой адаптер должен быть подключен к виртуальной сети «NAT».
    4. Сетевые адаптеры машин User1 и User2 подключим к «Custom11», а сетевые адаптеры Server1, Server2 подключим к «NAT».
    5. Редактируя файлы /etc/network/interfaces, назначим всем виртуальным машинам статические IP-адреса, а также шлюзы (GW) и DNS-сервера в соответствии со схемой лабораторного стенда. В качестве шлюзов по умолчанию для Host1 и Host2 будет 192.168.0.40, для Server1 и Server2 172.30.0.40, а для FW 172.30.0.2
    6. На виртуальной машине FW активируем функции маршрутизации IPv4 трафика. Для этого в файле /etc/sysctl.conf раскомментируем строку net.ipv4.ip_forward=1. Сделать это можно с помощью заклинания:
    7. Проверим стенд. Host1 и Host2 должны иметь возможность «пингануть» Server1, Server2 и FW и наоборот. FW должен иметь возможность «пингануть» любой из узлов сети.

    Ход выполнения работы

    1. Полную настройку брандмауэра мы уже рассматривали в предыдущей задаче. Поэтому здесь мы направим внимание на конфигурационный файл /etc/nftables.conf. Причем мы также опустим вопросы защиты самого FW, поскольку они будут точно такими же, как и в предыдущей задаче, и сосредоточимся лишь на фильтрации транзитного трафика.
    2. Анализируя матрицу доступа можно предположить, что User1 является рядовым работником, и ему требуется доступ по http ко всем серверам. Назовем такой доступ ролью «all_web». Для User2 требуется предоставить доступ ко всем серверам по SSH, вероятно он системный администратор. Обозначим такой доступ ролью «all_ssh». Обоим пользователям требуется доступ к DNS-серверу — это будет роль «DNS».
    3. Наиболее простым способом создать в nftables ролевую систему разграничения доступа будет применение правил, где в качестве аргументов используются списки (sets), содержащие конкретные параметры предоставления доступа. В нашем случае для каждой роли нужно создать два списка: наименование роли_users и наименование роли_servers. В первый список будут добавляться IP-адреса пользователей, во второй — IP-адреса серверов, а также протоколы и доступные порты.
    4. После создания списков для каждой роли создадим правило, разрешающее установку соединений ip saddr @название роли_users ip daddr. meta l4proto. th dport @название роли_servers accept. Трафик по инициированным соединения, как обычно, будет проходить с помощью правила ct state established,related accept.
    5. Итоговый конфигурационный файл (/etc/nftables.conf), решающий поставленную задачу будет выглядеть следующим образом:

    Примечание. После настройки всех правил вы столкнетесь с одной проблемой: DNS на User1 и User2 работать не будет. Это не баг, это методическая фича. Проблема в том, что DNS-сервер работает на виртуальном маршрутизаторе, который ничего не знает о пользовательской сети 192.168.0.0/24, из-за этого ответы на запросы не доходят до адресатов. Этой проблемой хотелось показать реальные сложности, возникающие при сегментации уже работающих сетей с помощью разделения их на IP-подсети. На предприятиях со сложившейся инфраструктурой, но низким уровнем зрелости IT внедрить подобные меры защиты крайне сложно, а учитывая user resistance, практически невозможно. Но проблема все же имеет решение, и мы поговорим о нем прямо сейчас.

    Типовой сценарий: сегментирование локальной сети коммутатором с функцией брандмауэра

    Данный подход к межсетевому экранированию имеет множество названий: коммутатор с функцией брандмауэра, «stealth firewall», «transparent firewall» и др. Суть, однако, заключается в том, что сегментируемая сеть сохраняет свою IP-адресацию, а разделение происходит путем установки коммутатора в разрыв между будущими сегментами. Причем коммутатор фильтрует трафик как обычный межсетевой экран — на основании данных со всех инкапсулированных протоколов (L2, L3, L4, L7), а не только данных с протоколов канального уровня (L2), как в случае с обычным коммутатором.

    Сетевые интерфейсы коммутатора не имеют IP-адресов (за исключением тех, что используются для управления). Соответственно, данное устройство не видимо для других сетевых узлов (за исключением случаев, когда используются специфические протоколы, например OSPF). Поэтому коммутатор с функцией брандмауэра часто называют прозрачный межсетевой экран — stealth firewall.

    1. Внедрение устройства не требует выделения IP-подсетей и, как следствие, перенастройки таблиц маршрутизации роутеров и сетевых стеков узлов.
    2. Устройство очень просто внедрить и очень просто изъять из сети в случае его поломки.

    Практическая работа: провести сегментирование сети без разделения ее на IP-подсети

    Описание стенда

    Используемый лабораторный стенд (Рисунок 5) очень похож на предыдущий, за исключением того, что все машины здесь находятся в одной IP-подсети. Для того, чтобы машины UserX и ServerX не могли связаться между собой напрямую, а использовали для связи FW, их разделили по виртуальным сетям «Custom11» и «NAT».

    
    Рисунок 5

    Задача

    Подготовка стенда

    1. Внося изменения в файлы /etc/network/interfaces, назначим статические адреса всем узлам сети.
    2. Для организации работы FW в режиме коммутатора установим на него пакет bridge-utils:
    3. Затем на узле FW сконфигурируем коммутатор, объединив в мост (bridge) все сетевые порты. Для этого файл /etc/network/interfaces заполним следующим образом:
    4. Проверим стенд. Все узлы, кроме FW, должны «пинговаться» между собой. DNS, кстати, тоже должен работать.

    Ход выполнения работы

    Как и в предыдущей задаче рассмотрим только файл с правилами межсетевого экранирования /etc/nftables.conf. Скорее всего при беглом осмотре вы даже не заметите в нем различий по сравнению с таким же файлом из предыдущей задачи.

    Проект OneButtonFirewall

    Можно ли сделать межсетевой экран, не требующий конфигурирования? Если можно, то что он будет уметь? Давайте разбираться.

    Мы с вами рассмотрели несколько схем разграничения трафика. Есть ли среди них та, что не требует конфигурирования, то есть указания IP-адресов или портов, на основании которых производится фильтрация трафика? Конечно, есть, и эта схема первая в списке.

    • Запрещен транзит трафика из внешнего сегмента во внутренний, кроме того, что относится к уже установленным соединениям.
    • Разрешен транзит любого трафика из внутреннего сегмента во внешний сегмент.

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

    Осталась одна проблема – широковещательный трафик. Раньше, когда мы рассматривали фильтрацию с помощью коммутатора, мы не обращали на него внимание, и по факту он был запрещен, кроме разве что ARP. Это, конечно, безопасно, но для универсального межсетевого экрана не подходит, поскольку ломает работу множества протоколов, базирующихся на широковещательных посылках, и первыми такими протоколами будут протоколы ОС Windows, отвечающие за отрисовку сетевого окружения. В результате тетенька бухгалтерша, сидящая за подобным брандмауэром, издаст злобный писк, что пропали все ее сетевые папки, и что вы вообще бесполезный вредитель. Нам такого не надо, поэтому, скрипя сердцем, разрешим транзит всего широковещательного трафика.

    Ну, вроде бы все учли… ан нет. В ходе эксплуатации OneButtonFirewall всплыла проблема, откуда не ждали – получение IP-адреса от DHCP-сервера, находящегося во внешнем сегменте. ОС Windows получает IP-адреса по DHCP сугубо на широковещательных рассылках, и текущих правил фильтрации ей полностью хватает. Linux же идет своим путем. При получении адреса на конечном этапе DHCP-сервер посылает клиенту адресный (unicast) пакет по UDP 68, и, чтобы тот достиг адресата, в правилах фильтрации нужно сделать соответствующее исключение.

    Практическая работа: защитить сегмент сети с помощью межсетевого экрана, построенного по технологии OneButtonFirewall

    Описание стенда

    Давайте теперь соберем лабораторный стенд (Рисунок 6) и отработаем на нем наши идеи. Тут мы даже немного усложним задачу. У FW будет не два интерфейса: один внутренний и один внешний, а четыре: один внешний и три внутренних. Все узлы, подключенные к внутренним интерфейсам, будем считать внутренним сегментом и фильтровать трафик между этими узлами не будем. Как вы увидите дальше, количество внутренних интерфейсов не имеет значения, но внешний может быть только один.

    
    Рисунок 6

    В этом примере для наглядности мы моделируем классическую корпоративную сеть на базе ОС Windows. Host1 – это Windows 10, подключенный к домену Active Directory, контроллер которого (ADDC) расположен во внешней сети. Host2 – Windows 10, не подключенная к домену, а Host3 – наша шаблонная машина на базе Debian. Все HostX получают IP-адреса по DHCP от виртуального маршрутизатора.

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

    Задача

    Подготовка стенда

    На узле FW установим 4 сетевых интерфейса. Для наглядности с помощью средств виртуализации изменим на них MAC-адреса (Рисунок 7):

    
    Рисунок 7

    Ход выполнения работы

    1. Для решения поставленной задачи заполним файл /etc/nftables.conf следующим образом:

    Реализация OneButtonFirewall в виде аппаратного устройства

    Идея OneButtonFirewall наиболее полным образом раскрывает себя в виде аппаратного устройства. Реализовать ее в виде виртуальных машин или контейнеров, конечно, тоже можно, но особого профита это не даст. Аппаратное же устройство дает эффект своеобразного кирпичика, который можно подключить к сети, и он ее защищает. Отсюда, кстати, и название пошло OneButtonFirewall, так как подобному устройству нужна только одна кнопка: включение питания. Несомненным плюсом устройства является его неконфигурируемость. Оно реализует жесткий алгоритм, не требующий дополнительных настроек. Как следствие, не нужно заботиться о целостности конфигурации или продумывать интерфейсы администрирования и обеспечивать их защиту.

    Построить OneButtonFirewall очень просто. Достаточно найти подходящую аппаратную платформу установить туда дистрибутив Linux, в котором есть поддержка nftables, и провести настройку из примера выше. Например, OneButtonFirewall, построенный на базе аппаратной платформы MikroTik, выглядит следующим образом (Рисунок 8):

    
    Рисунок 8

    Преимущества и недостатки OneButtonFirewall

    1. Простота и скорость развертывания и изъятия системы защиты.
    2. Защищенность конфигурации от изменения.
    3. Минимальные требования к квалификации персонала.
    1. Устройство реализует жесткий алгоритм фильтрации, который решает далеко не все задачи межсетевого экранирования.
    2. Устройство не фильтрует широковещательный трафик и трафик по порту UDP 68 из внешней сети во внутреннюю.

    Сценарии применения

    Рассмотренные преимущества и недостатки определяют основную нишу применения OneButtoFirewall сценариями, в которых нужно просто и быстро реализовать межсетевое экранирование, а применение классических межсетевых экранов натыкается на недостаточную квалификацию / саботаж / лень / перегруженность работников IT.

    1. Защита сети отдела компании, например, бухгалтерии или службы безопасности. Узлы защищаемого отдела подключаются к внутренним портам межсетевого экрана, а остальная сеть к внешним. Внутренние узлы работают «как обычно», а из внешней сети подключиться к ним нельзя.
    2. Защита сети компании от компьютеров подрядчиков (например, аудиторов).
       Тут обратная схема. Узлы компьютеров подрядчиков через коммутатор подключаются к внешнему порту межсетевого экрана, корпоративная сеть подключается к внутреннему порту. Из корпоративной сети можно подключится к компьютерам подрядчиков, а вот в обратную сторону нет.
    3. Элемент дежурной аптечки системных администраторов.
       OneButtonFirewall наряду с антивирусным LiveUSB может существенно помочь в случае массового заражения сети компьютерными вирусами. С его помощью можно безопасно переустановить и обновить операционную систему компьютеров, в случаях когда заражение происходит еще до того, как стартует штатный межсетевой экран операционной системы.

    Заключение

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

    Firewall: настройка межсетевого экрана сервера

    Инструкция по настройке правил Firewall для виртуальных серверов в панели управления Serverspace.

    Что это такое?

    С помощью межсетевого экрана прямо из панели управления можно управлять доступом к серверу, сетевыми пакетами данных. Данная опция отдельно не тарифицируется и входит в стоимость сервера.

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

    Сетевая архитектура

    Для избежания конфликта правил межсетевого экрана и его правильной настройки необходимо понимать порядок действия существующих брандмауэров. Во-первых, вы можете настроить брандмауэр для частной сети. Во-вторых, для сервера через панель управления. В-третьих, вы можете настроить внутренний брандмауэр, например, для Linux через iptables, для Windows — встроенный.

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

    Мы не рекомендуем одновременно использовать межсетевой экран на уровне сервера и внутренний программный:

    

    Создание правила

    Конфигурация брандмауэра доступна для всех VPS и находится в настройках сервера в разделе Firewall.

    Важно:
    — порядок правил имеет значение, чем меньше порядковый номер правила (чем выше он в списке), тем выше его приоритет. Изменять последовательность правил можно с помощью Drag and Drop, перетащив правило левой кнопкой мыши на нужную позицию;
    — по умолчанию — все пакеты данных, как входящие, так и исходящие разрешены.

    Для создания правила нажмите кнопку Добавить:

    

    Перед вами откроется окно добавления правила. Необходимо заполнить следующие поля:

    • Name — понятное для пользователя название (не более 50 символов), как правило кратко описывает назначение правила;
    • Direction — направление пакетов, для которых необходимо применить правило, принимает одно из двух значений: Incoming или Outgoing. Incoming — правило распространяется на входящие пакеты данных, Outgoing — на исходящие;
    • Source/Destination — в зависимости от направления содержит IP-адрес сервера или одно из значений: IP-адрес, CIDR, диапазон IP-адресов и any;
    • SourcePort/DestinationPort — при выборе протокола TCP, UDP или TCP and UDP возможно указать порт, диапазон портов, либо Any;
    • Action — действие, которое необходимо применить, принимает одно из двух значений: Allow или Deny. Allow — разрешение пересылки пакетов данных, Deny — запрет пересылки;
    • Protocol — тип протокола, доступно ANY, TCP, UDP, TCP and UDP и ICMP.

    Для создания правила нажмите Сохранить.

    В нашем примере правило блокирует все входящие на сервер пакеты:

    

    Чтобы созданное правило вступило в силу необходимо сохранить изменения с помощью кнопки Сохранить. Вы можете создать несколько правил и затем сохранить все разом:

    

    После этого страница будет выглядеть следующим образом:

    

    Приоритет правил

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

    

    Для изменения приоритета правил перетащите с помощью левой кнопки мыши разрешающее правило на первое место и сохраните изменения:

    

    После сохранение порядковые номера правил изменятся, а также изменится их приоритет:

    

    Теперь конфигурация брандмауэра позволяет получать пакеты по протоколу Tcp по 80 порту, остальные пакеты проходить не будут.

    Что такое правила межсетевого экрана

    Межсетевые экраны

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

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

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

    Определение типов межсетевых экранов

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

    Межсетевые экраны прикладного уровня

    Межсетевые экраны прикладного уровня, или прокси-экраны, представляют собой программные пакеты, базирующиеся на операционных системах общего назначения (таких как Windows NT и Unix) или на аппаратной платформе межсетевых экранов. Межсетевой экран обладает несколькими интерфейсами, по одному на каждую из сетей, к которым он подключен. Набор правил политики определяет, каким образом трафик передается из одной сети в другую. Если в правиле отсутствует явное разрешение на пропуск трафика, межсетевой экран отклоняет или аннулирует пакеты.

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

    При использовании межсетевого экрана прикладного уровня все соединения проходят через него (см. рис. 10.1). Как показано на рисунке, соединение начинается на системе-клиенте и поступает на внутренний интерфейс межсетевого экрана. Межсетевой экран принимает соединение, анализирует содержимое пакета и используемый протокол и определяет, соответствует ли данный трафик правилам политики безопасности. Если это так, то межсетевой экран инициирует новое соединение между своим внешним интерфейсом и системой-сервером.

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

    Примечание

    Здесь подразумевается, что модуль доступа на межсетевом экране сам по себе неуязвим для атаки. Если же программное обеспечение разработано недостаточно тщательно, это может быть и ложным утверждением.

    Дополнительным преимуществом архитектуры данного типа является то, что при ее использовании очень сложно, если не невозможно, «скрыть» трафик внутри других служб. Например, некоторые программы контроля над системой, такие как NetBus и Back Orifice, могут быть настроены на использование любого предпочитаемого пользователем порта. Следовательно, их можно настроить на использование порта 80 (HTTP). При использовании правильно настроенного межсетевого экрана прикладного уровня модуль доступа не сможет распознавать команды, поступающие через соединение, и соединение, скорее всего, не будет установлено.

    Межсетевые экраны прикладного уровня содержат модули доступа для наиболее часто используемых протоколов, таких как HTTP, SMTP, FTP и telnet. Некоторые модули доступа могут отсутствовать. Если модуль доступа отсутствует, то конкретный протокол не может использоваться для соединения через межсетевой экран.

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

    Примечание

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

    Межсетевые экраны с пакетной фильтрацией

    Межсетевые экраны с пакетной фильтрацией могут также быть программными пакетами, базирующимися на операционных системах общего назначения (таких как Windows NT и Unix) либо на аппаратных платформах межсетевых экранов. Межсетевой экран имеет несколько интерфейсов, по одному на каждую из сетей, к которым подключен экран. Аналогично межсетевым экранам прикладного уровня, доставка трафика из одной сети в другую определяется набором правил политики. Если правило не разрешает явным образом определенный трафик, то соответствующие пакеты будут отклонены или аннулированы межсетевым экраном.

    Правила политики усиливаются посредством использования фильтров пакетов. Фильтры изучают пакеты и определяют, является ли трафик разрешенным, согласно правилам политики и состоянию протокола (проверка с учетом состояния). Если протокол приложения функционирует через TCP, определить состояние относительно просто, так как TCP сам по себе поддерживает состояния. Это означает, что когда протокол находится в определенном состоянии, разрешена передача только определенных пакетов. Рассмотрим в качестве примера последовательность установки соединения. Первый ожидаемый пакет — пакет SYN. Межсетевой экран обнаруживает этот пакет и переводит соединение в состояние SYN. В данном состоянии ожидается один из двух пакетов — либо SYN ACK (опознавание пакета и разрешение соединения) или пакет RST (сброс соединения по причине отказа в соединении получателем). Если в данном соединении появятся другие пакеты, межсетевой экран аннулирует или отклонит их, так как они не подходят для данного состояния соединения, даже если соединение разрешено набором правил.

    Если протоколом соединения является UDP, межсетевой экран с пакетной фильтрацией не может использовать присущее протоколу состояние, вместо чего отслеживает состояние трафика UDP. Как правило, межсетевой экран принимает внешний пакет UDP и ожидает входящий пакет от получателя, соответствующий исходному пакету по адресу и порту, в течение определенного времени. Если пакет принимается в течение этого отрезка времени, его передача разрешается. В противном случае межсетевой экран определяет, что трафик UDP не является ответом на запрос, и аннулирует его.

    При использовании межсетевого экрана с пакетной фильтрацией соединения не прерываются на межсетевом экране (см. рис. 10.2), а направляются непосредственно к конечной системе. При поступлении пакетов межсетевой экран выясняет, разрешен ли данный пакет и состояние соединения правилами политики. Если это так, пакет передается по своему маршруту. В противном случае пакет отклоняется или аннулируется.

    

    Межсетевые экраны с фильтрацией пакетов не используют модули доступа для каждого протокола и поэтому могут использоваться с любым протоколом, работающим через IP. Некоторые протоколы требуют распознавания межсетевым экраном выполняемых ими действий. Например, FTP будет использовать одно соединение для начального входа и команд, а другое — для передачи файлов. Соединения, используемые для передачи файлов, устанавливаются как часть соединения FTP, и поэтому межсетевой экран должен уметь считывать трафик и определять порты, которые будут использоваться новым соединением. Если межсетевой экран не поддерживает эту функцию, передача файлов невозможна.

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

    Примечание

    Последний абзац начинается с фразы «как правило». Различные производители межсетевых экранов сопоставляют их производительность различными способами. Исторически сложилось так, что межсетевые экраны с пакетной фильтрацией имеют возможность обработки большего объема трафика, нежели межсетевые экраны прикладного уровня, на платформе одного и того же типа. Это сравнение показывает различные результаты в зависимости от типа трафика и числа соединений, имеющих место в процессе тестирования.

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

    Примечание

    Большая часть межсетевых экранов с фильтрацией пакетов поддерживает трансляцию межсетевых адресов.

    Гибридные межсетевые экраны

    Как и многие другие устройства, межсетевые экраны изменяются и совершенствуются с течением времени, т. е. эволюционируют. Производители межсетевых экранов прикладного уровня в определенный момент пришли к выводу, что необходимо разработать метод поддержки протоколов, для которых не существует определенных модулей доступа. Вследствие этого увидела свет технология модуля доступа Generic Services Proxy (GSP). GSP разработана для поддержки модулями доступа прикладного уровня других протоколов, необходимых системе безопасности и при работе сетевых администраторов. В действительности GSP обеспечивает работу межсетевых экранов прикладного уровня в качестве экранов с пакетной фильтрацией.

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

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

    Разработка конфигурации межсетевого экрана

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

    • веб-сервер, работающий только через порт 80;
    • почтовый сервер, работающий только через порт 25. Он принимает всю входящую и отправляет всю исходящую почту. Внутренний почтовый сервер периодически связывается с данной системой для получения входящей почты и отправки исходящих сообщений.

    Существует внутренняя система DNS, которая запрашивает системы интернета для преобразования имен в адреса, однако в организации отсутствует своя собственная главная внешняя DNS.

    Интернет-политика организации позволяет внутренним пользователям использовать следующие службы:

    • HTTP;
    • HTTPS;
    • FTP;
    • Telnet;
    • SSH.

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

    Архитектура 1: системы за пределами межсетевого экрана, доступные из интернета

    На рис. 10.3 показано размещение доступных из интернета систем между сетевым экраном и внешним маршрутизатором. В таблице 10.1 приведены правила межсетевого экрана.

    

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

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

    Номер	Исходный IP	Конечный IP	Служба	Действие
    1	Внутренний почтовый сервер	Почтовый сервер	SMTP	Принятие
    2	Внутренняя сеть	Почтовый сервер	Любой HTTP, HTTPS, FTP, telnet, SSH	Принятие
    3	Внутренняя DNS	Любой	DNS	Принятие
    4	Любой	Любой	Любая	Сброс

    Архитектура 2: один межсетевой экран

    Вторая стандартная архитектура показана на рис. 10.4. В данной архитектуре используется один межсетевой экран для защиты как внутренней сети, так и любых других систем, доступных из интернета. Эти системы располагаются в отдельной сети . В таблице 10.2 приведены правила межсетевого экрана

    

    Таблица 10.2. Правила межсетевого экрана для архитектуры с одним межсетевым экраном

    Номер	Исходный IP	Конечный IP	Служба	Действие
    1	Любой	Веб-сервер	HTTP	Принятие
    2	Любой	Почтовый сервер	SMTP	Принятие
    3	Почтовый сервер	Любой	SMTP	Принятие
    4	Внутренняя сеть	Любой	HTTP, HTTPS, FTP, telnet, SSH	Принятие
    5	Внутренняя DNS	Любой	DNS	Принятие
    6	Любой	Любой	Любая	Сброс

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

    Архитектура 3: двойные межсетевые экраны

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

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

    Хорошим примером секретных сетей являются банковские сети. Каждый вечер банки связываются с системой федерального резерва для передачи денежных средств. Ошибки в этих сетях могут стоить банкам больших денег. Системы, управляющие такими соединениями, являются крайне секретными и жизненно важными для банковских структур. Для ограничения доступа к этим системам из других подразделений банка можно установить межсетевой экран.

    Как видно из таблицы 10-3, правила в данном случае аналогичны правилам межсетевого экрана в архитектуре 2. Но еще имеется и второй межсетевой экран. Правила для межсетевого экрана 2 приведены в табл. 10-4.

    Таблица 10.3. Правила межсетевого экрана 1 в архитектуре с двумя межсетевыми экранами

    Номер	Исходный IP	Конечный IP	Служба	Действие
    1	Любой	Веб-сервер	HTTP	Принятие
    2	Любой	Почтовый сервер	SMTP	Принятие
    3	Почтовый сервер	Любой	SMTP	Принятие
    4	Внутренняя сеть	Любой	HTTP, HTTPS, FTP, telnet, SSH	Принятие
    5	Внутренняя DNS	Любой	DNS	Принятие
    6	Любой	Любой	Любая	Сброс

    Таблица 10.4. Правила межсетевого экрана 2 в архитектуре с двойным межсетевым экраном

    Номер	Исходный IP	Конечный IP	Служба	Действие
    1	Внутренний почтовый сервер	Почтовый сервер	SMTP	Принятие
    2	Внутренняя сеть	Любой	HTTP, HTTPS, FTP, telnet, SSH	Принятие
    3	Внутренняя DNS	Любой	DNS	Принятие
    4	Любой	Любой	Любая	Сброс

    Примечание

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

    Построение набора правил межсетевого экрана

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

    Примечание

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

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

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

    Выявление различий между межсетевыми экранами различных типов

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

    Шаг за шагом

    1. Сконфигурируйте сеть согласно архитектуре 2. Не подключайте эту сеть к интернету!
    2. Создайте почтовый сервер и веб-сервер с настройками по умолчанию и оставьте в каждой системе уязвимости.
    3. Разместите межсетевой экран прикладного уровня в сети и настройте его согласно набору правил из табл. 10.2.
    4. Сконфигурируйте другую систему в качестве внешней системы (как если бы она располагалась вне межсетевого экрана в интернете) и запустите сканер уязвимостей.
    5. С помощью сканера уязвимостей просканируйте почтовый сервер и веб-сервер, а также межсетевой экран.
    6. Теперь замените межсетевой экран прикладного уровня межсетевым экраном с фильтрацией пакетов.
    7. Снова просканируйте серверы.
    8. Сравните полученные результаты. Различна ли информация, полученная при первом и втором сканировании? Одинаковы ли уязвимости, отображенные при подключении обоих межсетевых экранов? Если нет, то почему?

    Выводы

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

    Похожие публикации:

    1. Как поставить флажок в excel
    2. Windows to go rufus что это
    3. Где взять стикеры для whatsapp 18
    4. Как включить внутриигровой оверлей в geforce experience