Глава 8. Межсетевой экран Proxmox

Межсетевой экран Proxmox VE усиливает действие iptables по защищённости каждого узла Proxmox. Iptables являются приложением, которое позволяет вам управлять таблицами правил для межсетевого экрана ядра Linux. Все правила и настройки межсетевого экрана сохраняются в файловой системе вашего кластера Proxmox, тем самым делая доступной распределённый межсетевой экран в кластере вашем Proxmox. Предоставляемая Proxmox на каждом узле предваряющая межсетевой экран служба считывает все правила и настройки из файловой системы кластера и автоматически приводит в соответствие ваши локальные iptables. Правила могут быть полностью созданы и поддержаны GUI или CLI Proxmxox. Межсетевой экран Proxmox может быть использован на месте виртуального межсетевого экрана всего кластера.

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

 

Зоны

Области защиты межсетевым экраном Proxmox делятся на следующие три логические зоны:

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

 

Группы безопасности

Это средство группировки некоторых правил межсетевого экрана в одно правило. Оно очень полезно когда то же самое множество правил применяется к различным ВМ. Например, мы можем создать группу безопасности с названием webserver и добавить множество правил для открытия портов, таких как 21, 22,80, 443 и тому подобных. Затем мы можем применять эти Security Groups для любых ВМ, используемых в качестве веб сервера. Аналогично, мы можем создать группу безопасности для открытия портов только для электронной почты. Следующий снимок экрана отображает пример группы безопасности вебсервера с правилами открытия портов для FTP, SSH, HTTP и HTTPS:

Создаваемая в зоне центра данных Security Groups может быть применена в любых зонах. Группы безопасности делают более простым создание правил для множества узлов или виртуальных машин. Подробности о создании групп безопасности и управлении ими будут объяснены в этой главе позже.

 

IPSet

Иногда бывает необходимо создать правила межсетевого экрана для ограничения или разрешения обмена исключительно на основании IP адресов. IPSet позволяет нам создавать правила, котороые могут применяться ко множеству IP адресов или подсетей IP. Например, мы можем создать IPSet чтобы разрешить доступ к GUI Proxmox только с ограниченных IP адресов. Следующий снимок отображает пример IPSet для разрешения доступа к вашему proxmoxgui только с трёх адресов:

Мы можем создавать правила основываясь на индивидуальных IP или на целых подсетях с пименением формата CIDR в своих правилах.

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

 

Правила

Правила являются сердцевиной настройки межсетевого экрана. Правила определяют поток и тип обмена, который будет разрешён или запрещён в данной зоне. Существуют два направления в которых может идти сетевой обмен:

Существует три вида действий, которые могут быть применены правилом межсетевого экрана:

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

 

Протоколы

В межсетевом экране Proxmox мы можем создавать правила основываясь на различных сетевых протоколах, таких как TCP, UDP, ICMP и тому подобные. В зависимости от требований приложений, могут быть необходимы различные выборы протоколов. Например, если мы хотим разрешить для зоны ping, нам необходимо создать правило с таким протоколом ICMP. Предварительно определённые протоколы доступны для выбора в блоки диалога, что отображает следующий снимок экрана:

 

Макросы

Макросы являются предварительно созданными настройками порта для большинства известных служб, например, HTTP, SSH, FTP, Telnet, MySQL, NTP, OpenVPN и тому подобных. Каждый макрос имеет предопределённый протокол и номер порта. Поэтому, при выборе макроса на не нужно определять протокол или номер порта. Фактически, когда мы выбираем Macro при помощи ниспадающего меню, блок диалога Proxmox автоматически запрещает все текстовые блоки протокола и порта, как это отображается на следующем снимке экрана:

Следующий снимок экрана показывает ниспадающее меню Macro в блоке диалога Rule:

К функциям межсетевого экрана можно осуществить доступ через закладку firewall о всех трёх зонах, таких как Datacenter, Host, или Nodes, а также на виртуальных машинах, причём как KVM, так и LXC.

 

Службы pve-firewall и pvefw-logger

Существуют две службы, которые делают доступным межсетевой экран Proxmox:

Служба pve-firewall запускается автоматически после перезагрузки узла. Мы также можем осуществлять запуск, останов и перезапуск данной службы вручную с использованием следующих команд:

# pve-firewall start
# pve-firewall stop
# pve-firewall restart
 	   

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

# pve-firewall status
 	   

В случае, если в работе межсетевого экрана отсутствуют какие- либо проблемы, её вывод будет таким:

Status: enabled/running
 	   

Хотя межсетевой экраном Proxmox можно полностью управлять через GUI Proxmox, временами может потребоваться намеренный доступ к правилам через CLI в случае, когда некий кластер заблокирован из- за неправильной настройки правил межсетевого экрана. Все настройки и правила межсетевого экрана следуют одному и тому же формату именования с расширением .fw. Настройки межсетевого экрана и файлы правил хранятся в двух различных каталогах для всех ваших трёх зон:

/etc/pve/firewall/cluster.fw
 	   

Это файл настроек правил зоны и настроек центра данных (Datacenter). Вся прочая информация межсетевого экрана повсеместная в центре данных, такая как Security Groups и IPSets также хранятся в этом отдельном файле. Мы можем разрешать или запрещать межсетевой экран центра данных изменяя такой файл настроек.

Вот файлы настроек и правил для узла или хоста Proxmox:

/etc/pve/nodes/<node_name>/host.fw
 	   

Каждая виртуальная машина, будь то KVM или LXC, имеет отдельный файл настроек межсетевого экрана со своим идентификатором ВМ, хранящийся в том же каталоге, в котором хранится и файл настроек межсетевого экрана центра данных:

/etc/pve/firewall/<vm_id>.fw
 	   

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

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

Следующий снимок экрана отображает параметры межсетевого экрана для зоны центра данных в закладке Options перейдя в Datacenter | Firewall | Options:

Как мы можем увидеть из предыдущего снимка экрана, межсетевой экран для зоны центра данных по умолчанию выключен, при помощи Input Policy установите Drop, а Output Policy установите на Accept. Если мы на самом деле разрешим этот параметр межсетевого экрана прямо сейчас, тогда весь входящий доступ будет запрещён. Вам придётся перейти в консоль для доступа к данному узлу. Перед тем как разрешать этот параметр, мы должны с создать два правила для разрешения доступа вашего GUI по порту 8006 и вашего консольного доступа SSH через порт 22.

 

Создание правил межсетевого экрана центра данных

Чтобы открыть блок диалога создания Rule, нам нужно кликнуть на Add, переместившись в меню с закладками Datacenter | Firewall | Rules. В качестве нашего первого правила мы собираемся разрешить GUI Proxmox по порту 8006, как это отображено на следующем снимке экрана:

Блок диалога правил {почти} идентичен для всех трёх зон, поэтому важно знать подробности опционных элементов в этом блоке диалога. Следующая таблица суммирует все цели текстов и ниспадающих списков, доступных в данном блок диалога Правил:

Элемент	Функция
Direction	Этот ниспадающий перечень используется для выбора направления вашего обмена для данного правила, при этом это обязательное поле.
Action	Этот ниспадающий перечень используется для выбора необходимого для применения действия, такого как Accept, Drop или Reject. Это обязательное поле.
Interface	Это текстовое поле используется для определения вашего интерфейса, применяемого для данного правила. Оно не применяется в зоне центра данных. Полезно определять его для ВМ со множеством интерфейсов.
Source	Этот ниспадающий список используется для выбора предварительно настроенного IPSet или текстовое поле для ввода необходимого IP адреса, откуда происходит данный обмен. Мы можем определять подсеть в формате CIDR. Когда поле оставляется незаполненным, это позволяет принимать обмен со всех IP адресов источников.
Destination	Этот ниспадающий список используется для выбора предварительно настроенного IPSet или текстовое поле для ввода необходимого IP адреса устройства назначения в кластере. Когда поле оставляется незаполненным, это позволяет осуществлять обмен со всеми IP адресами получателей.
Enable	Это окошко метки используется для включения или выключения данного правила.
Macro	Этот ниспадающий перечень используется для выбора предварительно настроенных макросов. Мы также можем набрать свой текст имени макроса, который будет осуществлять фильтрацию нашего списка макросов.
Protocol	Этот ниспадающий список используется для выбора протокола. Мы также можем набрать своё имя протокола, которое будет осуществлять фильтрацию нашего списка протоколов.
Source port	Это текстовое поле используется для определения номера порта, порождающего данный входящий обмен. Если оно оставлено пустым, будет приниматься обмен со всех портов. Мы также можем определить в данном поле свой диапазон портов разделённый :. Данное поле порта источника также используется для исходящего обмена в случае, когда такой обмен имеет внутреннее происхождение с ВМ, узла или кластера.
Dest. Port	Это текстовое поле используется для определения номера порта получателя данного входящего обмена. Если оно оставлено пустым, будет приниматься обмен со всех портов. Мы также можем определить в данном поле свой диапазон портов разделённый :.
Comment	Это текстовое поле используется для записи определения или любых заметок относящихся к данному правилу.

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

 

Создание IPSet центра данных

Приводимый ниже снимок экрана показывает IPSet с именем proxmox_node_ips с IP адресами для двух узлов в нашем примере кластера:

На странице управления IPSet нам вначале необходимо создать собственно IPSet, а затем добавить IP с расположенных по правую руку опций IP/CIDR. Адреса IP могут добавляться по отдельности или определяться целым блоком с применением соответствующих значений CIDR. Имя IPSet может содержать только алфавитно- цифровые символы с двумя специальными: - и _. Однако, когда Proxmox отображает в ниспадающем списке IPSet, он добавляет в качестве префикса +. Этот символ не является частью имени. Если строка введена с заглавными буквами, они автоматически будут заменены на строчные. Следующий экранный снимок отображает диалоговый блок Rules в котором мы выбираем IPSet для узлов Proxmox в поле Destination для разрешения SSH только для узлов Proxmox:

Видоизменённое правило будет обеспечивать то, что SSH будет допустим только для узлов Proxmox, а не для ВМ. Как мы можем увидеть в предыдущем примере, при создании правил в зоне Центра данных, очень важно помнить о каскадном эффекте правил Центра данных и том, как он может влиять на узлы и ВМ. Будет лучше применять правила зоны Центра данных для относящегося к кластеру обмена, а не для ВМ на всех узлах.

После того, как мы создали правила, допускающие SSH и GUI Proxmox, мы готовы разрешить межсетевой экран всего Центра данных через меню Options. Следующий снимок экрана показывает меню с теперь включённым межсетевым экраном:

Предыдущий снимок отображает политику, которая будет отклонять весь входящий обмен. а исходящий обмен будет разрешён. Для наличия полностью заблокированного безопасного кластера, обе данные политики должны быть установлены в значение DROP. Обычно исходящий обмен рассматривается безопасным. В противном случае, в среде со множеством арендаторов (multitenant), исходящий обмен также должен экранироваться. Таким образом, мы можем управлять видом обмена, который может покидать ВМ. Примером обмена, который следует запрещать может быть обмен ICMP или Ping, которые позволяют какой- либо ВМ обнаруживать сетевые устройства.

 

Создание псевдонимов

Псевдонимы (aliases) делают более наглядным просмотр того, какие устройства или группы устройств подвергаются воздействию правила. Мы можем создавать псевдонимы для идентификации адреса IP или сетевой среды. Это также аналогично относится к IPSet, однако только один псевдоним указывает на адрес IP или сеть, в то время как IPSet содержит {может содержать} множество адресов IP или сетевых сред. Например, в сценарии, в котором у нас имеется один Proxmox в качестве 10.0.0.0/24 и адрес IP 172.16.0.3, мы можем создать два псевдонима применяя блок диалога Alias кликнув на Add в меню Alias, как это отображено на следующем снимке экрана:

На предыдущем снимке мы создали псевдоним с именем ProxmoxNet для обозначения сети 10.0.0.0/24. Применяя тот же самый блок диалога мы создадим другой псевдоним с названием Management для IP 172.16.0.3. Отображённый ниже снимок экрана вашего окна Alias показывает оба созданных псевдонима:

Преимущество наличия Alias состоит в том, что всякий раз, когда мы создаём правила, мы можем использовать этот псевдоним вместо набора IP адреса целиком. Это в особенности полезно при использовании IPv6. Поскольку адреса IPv6 достаточно длинные, мы можем создавать псевдоним для вызова IP адреса в правиле всякий раз, когда он нам понадобится.

Это также другой способ описания численного IP адреса текстом. Псевдонимы доступны в ниспадающих списках как в Source, так и в Destination в вашем блоке диалога Rules. Приводимый ниже снимок отображает блок диалога создания правила с вашими псевдонимами в ниспадающем перечне для Source:

Создаваемые в зоне Центра данных псевдонимы доступны во всём кластере как в его зонах хостов, так и в зонах ВМ.

[OPTIONS] 

polioy_in: ACCEPT 
enable: 1 
policy_out: ACCEPT 

[ALIASES] 

ProxmoxNet 10.0.0.0/24 # Proxmox Cluster Network 
Management 172.16.0.3 # Proxmox Management Interface 

[IPSET proxmox_node_ips] 

172.16.0.171 
172.16.0.172 

[IPSET proxmoxgui] 

10.0.0.9 # Office 
172.16.0.3 # Home 
192.168.1.10 # Lab 

[RULES] 

|IN Ping(ACCEPT) 
IN SSH(ACCEPT) -dest +proxmoxnodeips # Allow SSH only for Proxmox nodes 

[group webserver] 

IN ACCEPT -source 10.0.0.2 -p tcp -dport 565 
IN HTTPS (ACCEPT) 
IN HTTP(ACCEPT) 
IN SSH(ACCEPT) 
IN FTP(ACCEPT) 
 	   

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

[OPTIONS]
. . . . . . . .
[ALIASES]
. . . . . . . .
[IPSET <name>]
. . . . . . . .
[RULES]
. . . . . . . .
[group <name>]
. . . . . . . .
 	   

 

[OPTIONS]

Эта область применяется для разрешения или запрета межсетевого экрана всего Центра данных (Datacenter). В настоящий момент наш пример кластера имеет политику Bold установленную по умолчанию, которая назначена на сброс всего входящего обмена, в то же время разрешая весь исходящий обмен. Если мы собираемся изменить свою политику входа на приём всего входящего обмена, тогда эти параметры должны выглядеть следующим образом:

[OPTIONS]
policy_in: ACCEPT
enable: 1
 	   

Если, из- за неверной настройки межсетевого экрана, мы заблокировали себя, мы можем запретить межсетевой экран всего Центра данных воспользовавшись с консоли следующим параметром:

enable: 0
 	   

 

[ALIASES]

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

 

[IPSET <name>]

Этот сегмент накапливает все IPSet, создаваемые в зоне Центра данных. Он отображает назначенное имя этого IPSet, а также добавленные в этот набор IP адреса. Для нашего примера у нас в наличии два IPSet с именами proxmox_node_ips и proxmoxgui.

 

[RULES]

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

 

[group <name>]

Этот раздел собирает все ваши Security Groups, создаваемые в зоне Центра данных. Он отображает имена групп безопасности и соответствующее правило, добавленное в эту группу. На предыдущем снимке мы могли видеть, что мы создали группу безопасности с названием webserver и добавили правила макросов чтобы сделать доступным обмен HTTPS, HTTP, SSH и FTP. Мы также можем вручную добавлять правила в данный сегмент определяя протокол и порт. Например, если мы хотим разрешить обмен TCP по порту 565 только для IP адреса 10.0.0.2, мы добавим следующую строку кода в свою группу безопасности webserver:

IN ACCEPT –source 10.0.0.2 –p tcp –dport 565
 	   

Все правила, создаваемые в вашей зоне хоста применяются только в тому непосредственному узлу, на котором это правило создано и к тем ВМ, которые находятся на данном узле хоста. Правила для одного узла не подвергаются репликации на все прочие узлы, хотя эти файлы правил сохраняются в файловой системе вашего кластера Proxmox. Не существует опций для создания IPSet или Security Groups в зоне вашего хоста. Следующий снимок экрана показывает функции вашего межсетевого экрана для узла хоста pm4-1 в нашем примере кластера:

Процесс создания новых правил для зоны Хоста идентичен процессу созданию правила, который мы уже обсуждали в разделе Настройка межсетевого экрана специфичного для центра данных ранее в данной главе. Помимо создания правил в рабочей области, мы также можем назначать предварительно созданные правила в своей форме Security Group на какой- либо узел. Мы не можем создавать новую Security Group в меню межсетевого экрана вашего хоста, однако мы можем назначать ей некоторые предварительно определённые правила. Например, ранее в этой главе мы создали Security Group с именем webserver. Если узел Proxmox предназначается только для размещения ВМ, используемых в свою очередь только для веб- серверов, тогда мы можем назначить такому узлу Security Group webserver, и все её правила будут каскадироваться во все ВМ данного хоста. Таким образом, мы могли бы сохранить уйму времени, которое мы бы потратили на создание отдельных правил для каждой ВМ.

Чтобы открыть блок диалога для назначения группы безопасности, кликните по Insert: Security Group. Ниже приводится снимок экрана, отображающий блок диалога с webserver, выбранным из ниспадающего перечня Security Group:

Мы должны гарантировать включение своего правила, кликнув по кнопке- флажку, а затем нам необходимо кликнуть по Add для назначения группы безопасности. Последующий снимок отображает Rule, добавленные к нашему узлу pm4-1:

 

Параметры зон межсетевого экрана хоста

Межсетевой экран узла Proxmox имеет некоторые элементы в своей закладке Options. Большинство этих элементов может быть оставлено с установленными по умолчанию значениями, как это показано на экранном снимке ниже. Однако понимание этих элементов придаст дополнительную вооружённость вашей безопасности в кластере. Ниже приводится снимок ваших элементов Options со значениями по умолчанию для не изменённого узла pm4-1:

Для изменения настроек любого элемента параметров нам нужно выбрать строку с этим элементом и после этого кликнуть по кнопке Edit.

 

Включение межсетевого экрана

По умолчанию узлы Proxmox имеют параметры межсетевого экрана во включённом состоянии. Для выключения межсетевого экрана данного узла целиком выберите No для данного параметра.

 

Фильтр SMURFS

По умолчанию, фильтр SMURFS является включённым. По своей природе, SMURFS является атакой DDoS (distributed denial-of-service). При данной атаке нападающий отсылает очень большое число пакетов данных ICMP с IP адресом вводимой в заблуждение жертвы в качестве источника, а он широковещательно распространяется на всю сеть с применением широковещательного адреса. Обычно все сетевые устройства отвечают на ping ICMP. В процессе атаки SMURF устройство- жертва переполняется ответами ICMP. Если в сетевой среде присутствует большое число устройств, в этом случае переполнение становится чрезвычайным, переводя ставшие жертвами устройства в безответное состояние. Это та причина, по которой данный фильтр должен оставаться включённым постоянно.

 

Фильтр флагов TCP

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

Флаг TCP	Функция
URG - 1бит	Он отображает, что данный пакет TCP является неотложным (urgent).
ACK - 1бит	Отображает поле Acknowledgement. После инициирующего SYN для всех пакетов, они обычно сопровождаются данным флагом.
PSD - 1бит	Данный флаг запрашивает проталкивание буферизации данных настолько быстро, насколько это возможно на принимающую сторону вашего клиентского приложения.
RST - 1бит	Этот флаг отображает сброс вашего соединения TCP.
SYN - 1бит	Данный флаг индицирует синхронизирующую последовательность чисел перед инициацией соединения TCP. Обычно этот флаг имеет только самый первый пакет, отправляемый из источника.
FIN - 1бит	Этот флаг отображает завершение пакетов TCP.

Флаги TCP полезны для определения и локализации пакетов TCP со странным поведением и определение возможного вторжения. Аргументы для добавления фильтрации флагов TCP добавляются в правила межсетевого экрана сразу после синтаксиса -p, как это отображено в следующем коде:

[RULES]
IN DROP –p tcp –tcp-flags SYN,ACK SYN –dport
 	   

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

 

nf_conntrack_max

Это значение определяет максимальный размер таблицы отслеживания соединения сетевой фильтрации. Эта таблица хранит записи обо всех рабочих соединениях и удаляет их при закрытии соединения. По умолчанию размер этой таблицы равен 65536 байтам. В то время как для большинства этих узлов этого вполне достаточно, для серверов с большим объёмом соединений, таких как DNS или веб- сервер, данная таблица может быстро заполняться. Для узла Proxmox, который содержит большое число ВМ с высоким уровнем обмена, данное значение должно быть увеличено. Мы можете проверить текущее значение nf_conntrack_max воспользовавшись следующей командой:

# sysctl –a | grep nf_conntrack_max
 	   

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

# sysctl –a | grep nf_conntrack_count
 	   

Следующий снимок показывает количество соединений для нашего примера узла pm4-1:

root@pm4-1:/# sysctl -a | grep nf_conntrack_count 
sysctl: reading key "net.ipv6.conf.all.stable_secret" 
sysctl: reading key "net.ipv6.conf.default.stable_secret" 
sysctl: reading key "net.ipv6.conf.eth0.stable_secret" 
sysctl: reading key "net.ipv6.conf.eth0/10.stable_secret" 
sysctl: reading key "net.ipv6.conf.eth1.stable_secret" 
sysctl: reading key "net.ipv6.conf.eth2.stable_secret" 
sysctl: reading key "net.ipv6.conf.fwbrl00i0.stable_secret" 
sysctl: reading key "net.ipv6.conf.fwbr112i0.stable_secret" 
sysctl: reading key "net.ipv6.conf.fwln100i0.stable_secret" 
sysctl: reading key "net.ipv6.conf.fwln112i0.stable_secret" 
sysctl: reading key "net.ipv6.conf.fwpr100p0.stable_secret" 
sysctl: reading key "net.ipv6.conf.fwpr112p0.stable_secret" 
sysctl: reading key "net.ipv6.conf.lo.stable_secret" 
sysctl: reading key "net.ipv6.conf.tap112i0.stable_secret" 
sysctl: reading key "net.ipv6.conf.vethl00i0.stable_secret" 
sysctl: reading key "net.ipv6.conf.vmbr0.stable_secret" 
sysctl: reading key "net.ipv6.conf.vmbr0v10.stable_secret" 
sysctl: reading key "net.ipv6.conf.vmbr1.stable_secret" 
net.netfilter.nf_conntrack_count = 74 
 	   

 

nf_conntrack_tcp_timeout_established

Данный узел может сохранять отслеживание своих фильтруемых сетевых соединений только если они в работе. Безжизненные соединения автоматически удаляются из вашей таблицы. Такое удаление осуществляется на основании установленного промежутка таймаута. Чем длиннее промежуток таймаута, тем более длинный список записей ваших соединений будет оставаться в отслеживающей его таблице. Значение данного параметра задаётся в секундах. По умолчанию это значение установлено на 43200 секунд, или 12 часов. Мы можем проверить текущее значение, воспользовавшись следующей командой:

# sysctl –a | grep nf_conntrack_tcp_timeout_established
 	   

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

 

log_level_in/out

Межсетевой экран хорош только благодаря возможностям своего журнала регистраций. Только пройдясь по своему журналу мы можем увидеть что блокируется, а что нет. Proxmox поставляется с индивидуальной службой, именуемой как pvefw-logger, которая основывается на своём демоне регистрации сетевой фильтрации. Единственная цель такой службы состоит в регистрации активности соединения на основе вашего набора правил межсетевого экрана. При помощи закладки межсетевого экрана Option мы можем устанавливать различные уровни детализации регистрации. Существует восемь доступных уровней регистрации для межсетевого экрана на базе iptable. Следующая таблица отображает уровни регистрации iptable и их доступность в межсетевом экране Proxmox:

Уровень журнала	Тип
Level 0	Emergency	Доступен в Proxmox
Level 1	Alert	Доступен в Proxmox
Level 2	Critical	Доступен в Proxmox
Level 3	Error	Доступен в Proxmox
Level 4	Warning	Доступен в Proxmox
Level 5	Notice	Доступен в Proxmox
Level 6	Info	Не доступен в Proxmox
Level 7	Debug	Доступен в Proxmox

В добавление к этим уровням, Proxmox также имеет опцию nolog. Она запрещает все регистрационные ресурсы. Информация о вашем уровне регистрации в основном используется по той причине, что она записывает все хорошие и плохие соединения. Таким образом, мы можем можем в точности видеть что блокируется, а что разрешено. Однако, уровень регистрации Info к тому же создаёт много записей регистраций в очень короткий промежуток времени. Хорошей практикой будет всегда выбирать некоторую форму протоколирования при вкючённом межсетевом экране.

 

tcp_flags_log_level

Аналогично вашему стандартному уровню регистрации, мы также можем включать различные уровни протоколов для своих флагов tcp. Если фильтр флагов TCP не включён, тогда не будут производиться никакие записи. Когда он включён, мы видим журнал регистрации своего фильтра флагов tcp в нашем окне протоколов.

 

smurf_log_level

Как и протокол флагов tcp, этот параметр также отображает элементы регистрации для атак smurf. Он также следует различным уровням ведения регистрации.

Мы также можем осуществлять настройку и управление своей зоной хоста с применением CLI. Файл настроек для нашего хоста находится в /etc/pve/local/host.fw. Следующий снимок отображает содержимое файла host.fw:

[OPTIONS]

nf_conntrack_max: 100000
tcp_flags_log_level: err
log_level_out: err
tcpflags: 1
log_level_in: err

[RULES]

IN ACCEPT -p tcp -dport 65
GROUP webserver
 	   

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

[OPTIONS]
. . . . . . . .
[RULES]
. . . . . . . .
 	   

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

Правила, создаваемые только для ВМ применяются только к этой определённой виртуальной машине. Даже когда эта виртуальная машина перемещается на другой узел, такой межсетевой экран следует за данной ВМ в нашем кластере. Не существует никаких правил каскадирования для этой зоны. В функциях своего межсетевого экрана ВМ мы можем создавать Rules, Aliases и IPSets, однако мы не можем создавать никакие группы безопасности. Управление нашим межсетевым экраном одно и то же как для виртуальных машин KVM, так и для контейнеров LXC. Мы можем перейти к функциям межсетевого экрана ВМ переместившись в свою закладку меню VM | Firewall. Следующий снимок отображает все функции нашего примера ВМ #112:

Процесс создания новых правил для ВМ идентичен процессу создания правил, который мы уже видели в нашем разделе Настройка межсетевого экрана центра данных через GUI, ранее в этой главе. Помимо создания правил в рабочей зоне, мы также можем назначать предварительно определённые правила в своей форме Security Group для ВМ. Предыдущий снимок экрана отображал тот факт, что наш экземпляр ВМ имеет правило межсетевого экрана для разрешения обмена через SSH.

Alias для зоны ВМ преследуют ту же самую цель, что и Псевдонимы для зоны Центра данных. Процесс создания Псевдонимов также идентичен описанному в нашем разделе Настройка межсетевого экрана центра данных через GUI.

Как и Псевдонимы для ВМ, создаваемые под ВМ IPSet также остаются с этой определённой ВМ. Процесс создания IPSet идентичен уже описанному ранее в этой главе в разделе Настройка межсетевого экрана центра данных через GUI процессу создания IPSet для зоны Центра данных.

Все параметры элементов в меню Option являются теми же самыми, что и уже описанные элементы для ваших зон Центра данных и хоста, за исключением фильтров DHCP и MAC. Следующий снимок экрана показывает элементы Option для нашего примера ВМ #112:

 

Снятие запрета DHCP

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

 

Фильтр MAC

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

Как и с прочими зонами межсетевых экранов в Proxmox, мы можем осуществлять настройку и управление межсетевыми экранами, предназначенными для виртуальных машин также и через свой CLI. Файл настройки для каждой ВМ находится в /etc/pve/firewall/<vm_id>.fw. Все сегменты в этом файле настроек являются теми же самыми, что и в настройках зон Центра данных и хоста. Следующий снимок показывает содержимое файла настроек межсетевого экрана для ВМ #112:

[OPTIONS]

enable: 1
dhcp: 0

[ALIASES]

kvm-112Ubuntu 192.168.1.10

IN SSH(ACCEPT)
 	   

Защита безопасности вашего межсетевого экрана Proxmox VE может быть ещё усилена настройкой системы определения и предотвращения внедрений подобной Suricata. Это высокопроизводительный механизм IDS/IPS, который способен защищать виртуальную машину, отклоняя обмен, который вероятно является внедрением. В настоящее время Snort и Suricata являются двумя основными направлениями доступного IDS/IPS с открытым по сравнению с остальными. Одним из основных преимуществ Suricata является её многопоточность, в то время как Snort имеет только один поток. Suricata находится в ускоренном развитии и быстро получает популярность в связанном с безопасностью сообществе.

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

Если вы новичок для Suricata, посетите официальный сайт Suricata, который поможет вам получить некоторые знания о Suricata в качестве IDS/IPS по ссылке: http://suricata-ids.org/.

Мы можем установить Suricata на узле Proxmox применив следующую команду:

# apt-get install suricata
 	   

После того, как Suricata установлена, мы должны загрузить очередь netfilter модуля подсистемы nfnetlink_queue, воспользовавшись командой:

# modprobe nfnetlink
 	   

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

Установщик выполнит установку всех необходимых для Suricata файлов, включая правила Oinkmaster. Все механизмы IDS/IPS сильно зависят от правил. Эти правила предварительно скомпилированы и упакованы в файлы правил. Oinkmaster является сценарием, который позволяет нам простым образом обновлять и управлять правилами. Он в основном применяется в Snort, но также поддерживается и Suricata. Без этих правил Suricata неп будет ничего делать. Для получения информации о правилах посетите официальный сайт Snort по ссылке: https://www.snort.org/.

Не существует опций для разрешения Suricata для ВМ через GUI. Поэтому мы должны вручную включить её через CLI изменив файл настроек межсетевого экрана выбранной ВМ в /etc/pve/firewall/<vm_id>.fw. Мы должны добавить следующие строки в сегмент [OPTIONS] данного файла настроек:

ips: 1
ips_queues: 0
 	   

Ips_queues привязывается к определённой очереди ЦПУ выбранной виртуальной машины в силу своей многопоточной природы. Доступные очереди, которые Suricata должна прослущивать определены в /etc/default/suricata следующим образом:

NFQUEUE=0
 	   

Эти значения обычно устанавливаются на основании общего числа ЦПУ. Например, чтобы использовать четыре ядра для Suricata, мы можем применить значение 3 для NFQUEUE. Значение по умолчанию 0 отображает то, что мы используем только первый ЦПУ, которым является ЦПУ 0.

Suricata будет работать только при прослушивании nfqueue. Это настроено по умолчанию при установке Suricata на узел Proxmox. Весь обмен который только принимается межсетевым экраном вашего Proxmxox пропускается в Suricata для инспекции. Файлы настроек Suricata находятся в /etc/suricata/suricata-debian.yaml. Настройка по умолчанию должна работать в большинстве случаев.

Относительно проще написать свои собственные индивидуальные правила для Suricata, чем это делается для Snort. Вы можете воспользоваться следующей замечательной документацией по тому, как писать свои собственные правила для Suricata по адресу https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricata_Rules.

Мы можем запустить службу Suricata, выполнив такую команду:

# service suricata start
 	   

Следующий снимок экрана показывает команду проверки состояния службы Suricata и отображаемую информацию об этом состоянии:

root@pm4-1:/vari1og/suricata# service suricata status 
• suricata.service - LSB: Next Generation IDS/IPS 
   Loaded: loaded (/etc/init.d/suricata) 
   Active: active (running) since Thu 2016-02-18 22:00:10 MST; 3s ago 
  Process: 3346 ExecStop=/etc/init.d/suricata stop (code=exited, status=0/SUCCESS) 
  Process: 3352 ExecStart=/etc/init.d/suricata start (code=exited, status=0/SUCCESS) 
   CGroup: /system.slice/suricata.service 
           └─3358 /usr/bin/suricata -c /etc/suricata/suricata-debian.yaml --pidfile /var/run/suricata.pid q 0 -D 

Feb 18 22:00:10 pm4-1 suricata[3352]: Starting suricata in IPS (nfqueue) mode... done. 
 	   

Как уже упоминалось ранее, в Proxmox не существует опций GUI для Suricata. Все настройки выполняются при помощи CLI. Без надлежащего знания правил IDS/IPS очень трудно создавать правила на основе своего собственного окружения. Suricata не может применяться для защиты каких- либо узлов Proxmox, и может применяться только к виртуальным машинам. Это ограничение может происходить из того, что IDS/IPS часто может потреблять большие объёмы ресурсов ЦПУ. В то время как для выделенного приложения межсетевого экрана это не может быть проблемой, в случае гипервизора, при использовании которого ЦПУ совместно применяется как самим гипервизором, так и располагающимися на нём виртуальными машинами, это может приводить к фатальным последствиям из- за чрезмерного потребления ЦПУ.

Для Suricata отсутствуют выделенные просмотры протоколов, как это происходит в случае вашего межсетевого экрана с GUI. Однако мы можем пропускать регистрации IPS Suricata сквозь syslog изменив свой файл настроек в /etc/pve/suricata/suricata-debian.yaml. Мы должны внести следующие изменения для пропуска протоколирования Suricata в syslog:

# a line based alerts log similar to fast.log into syslog
syslog:
enabled: yes
identity: "Suricata"
level: Info
 	   

В том же самом файле настроек существует ряд дополнительных опций, доступных для регистрации вашего вывода. Некоторые пользователи Proxmox пытаются пропускать записи регистрации Suricata в решения сторонних производителей, используя Logstash и Kibana из Elastic (www.elastic.co). Suricata или любое другое IPS являются сложной задачей для управления на ежедневной основе. Suricata всё ещё находится в детском возрасте в Proxmox. Со временем она может быть интегрирована в GUI для более лёгкого использования, однако в настоящее время, применение выделенных приложений межсетевого экранирования, например pfSense может быть более подходящим вариантом для интеграции Suricata в сетевую среду. Suricata полностью поддерживается в pfSense с большим количеством управляемых свойств, причём все они доступны в инструментальной панели GUI pfSense. Реализация системы IDS/IPS в сетевой среде является не обязательной, однако её следует обязательно делать для защиты от любых видов проникновения. {Прим. пер.: более подробную информацию мы надеемся в скором времени предоставить в своём переводе новой (август 2016) книги David Zientara "Mastering pfSense" Suricta.}

В данной главе мы изучили одно из наиболее мощных средств Proxmox, встроенный межсетевой экран. Мы ознакомились с тем что это такое, и как его реализовывать для защиты всего кластера Proxmox, узлов хостов Proxmox и виртуальных машин. Мы изучили как управлять правилами межсетевого экрана и его настройкой при помощи как GUI, так и CLI. Proxmox добавляет безопасность там, где она нужна в большей степени. Усилившись гибкой и гранулированной защитой межсетевого экрана на уровне гипервизора, мы теперь имеем возможность получать лучший, безопасный кластер.

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