Буквально только что выстрелил себе в ногу. Настраивал iptables на одном из серверов. Надо было просто базовый набор правил сделать с заделом на будущее, если вдруг что-то понадобится ограничить. Я обычно за основу беру свой же список правил из статьи https://serveradmin.ru/centos-nastroyka-servera/#Nastraivaem_firewall

Просто копирую набор правил в bash скрипт и запускаю. Пользуюсь статьей уже несколько лет, поэтому точно знаю, что проблем с правилами быть не должно. Достаточно только заменить ip адрес и имя интерфейса. Но в этот раз что-то пошло не так. Применил правила, получил кучу ошибок синтаксиса iptables и меня отрубило от сервера.

Я то знаю заветное правило - настройка firewall без доступа к консоли - к дальней дороге. Я подключился по vnc к серверу и посмотрел, в чем проблема. Оказывается, после какого-то обновления движка сайта, он двойные тире -- стал заменять на одинарные и пробел. Соответственно, обычный копипаст правил с сайта приводит к тому, что правила не работают так, как задумывалось. Успевают примениться начальные правила блокировки, а до разрешений дело не доходит.

К чему я все это написал? Чтобы лишний раз напомнить, не надо лезть в настройки фаервола если нет доступа напрямую к консоли сервера, чтобы откатить настройки в случае проблем. У меня для минимизации вероятности опечаток и ошибок есть рецепт ansible для настройки iptables, но в данном случае стало лень его запускать, так как нужна была типовая пустая настройка, которую копипастом было сделать банально быстрее. В итоге получилось дольше :)

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

#статья #centos #iptables

​​Вы какой firewall в Linux используете? Iptables или уже перешли на nftables? Я по прежнему первый. Уже давно запланировал изучить nftables и перейти на него, но всё никак. Причина тут проста - я хорошо знаю iptables и он меня полностью устраивает. Ничего нового, перейдя на nftables, для себя не получу. Только все конфиги и правила переписывать придётся.

Для iptables есть интересный проект по графическому отображению правил - iptables-vis - https://github.com/Nudin/iptable_vis. Я его потестировал. Работает неплохо. Можно где-то использовать, например в документации для людей, не знакомых с синтаксисом iptables. Картинки вполне наглядные получаются.

Для рисования схем используется blockdiag, который написан на python. Проще всего поставить через pip:
# dnf install python3-pip
# apt install python3-pip
# pip install blockdiag

Потом клонируем себе репозиторий и рисуем схему:
# git clone https://github.com/Nudin/iptable_vis
# cd iptable_vis
# iptables -v -L > iptables.txt
# awk -f iptables-vis.awk < iptables.txt > iptables.dia
# blockdiag iptables.dia -T svg -o iptables.svg

Забирайте файл iptables.svg и смотрите любым просмотрщиком этого формата. Я в обычном браузере открыл.

#iptables

​​Ещё не успел перейти на nftables, а оказывается, что может и не придётся, так как на смену спешит eBPF, который уже много где используется. Например, в cilium.io (одна из реализаций сети для контейнеров в kubernetes). У них подробный материал есть на эту тему - Why is the kernel community replacing iptables with BPF.

Я уже почти созрел и давно запланировал переход на nftables. Уже и примеры конфигураций смотрел, и понял, зачем мне это надо. Nftables действительно удобнее iptables. Рекомендую погуглить различия, если ещё не делали этого. Из того, что сходу помню и на что обратил внимание: единый конфиг для ipv4 и ipv6, более короткий и наглядный синтаксис, больше не нужен ipset, так как nftables умеет быстро работать с огромными списками, экспорт правил в json и т.д.

И вот на сцене появляется ещё один пакетный фильтр bpfilter. Он не новый, но как я понял из некоторых новостей, которые погуглил, его активно развивают и уже много куда внедряют. Его используют в том числе Facebook и Netflix. Понятно, что они много чего используют и это не показатель реальной популярности и скорого роста использования того или иного продукта.

Написал эту заметку не только, чтобы поделиться информацией, но и спросить тех, кто разбирался уже в этом вопросе. Мне сейчас реально не понятно, eBPF это реально наше будущее в Linux и переходить на nftables не имеет большого смысла. Или не всё так однозначно? Если посмотреть презентацию с недавней конфы линуксоидов, то там прям на пальцах объяснили, что bpfilter это будущее. И там же указано, что будет переход From nft to bpfilter. Во разогнались как 😄 Я ещё на nft не перешёл, а они уже на bpfilter переезжают.

#iptables #nftables #bpfilter #firewall

Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow

​​С помощью Iptables можно очень хорошо защитить сервис, смотрящий напрямую в интернет. В частности, будет актуально в том числе для защиты asterisk, про которую я недавно рассказывал.

Я покажу несколько примеров с набором правил iptables. Начнём с защиты от сканирования портов. Будем банить на 10 минут всех, кто обратится не на открытые порты, например, 5060 и 22.

iptables -A INPUT -m recent --rcheck --seconds 600 --name BANLIST -j DROP
iptables -A INPUT -p tcp -m multiport ! --dports 22,5060 -m recent --set --name BANLIST -j DROP
iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --syn --dport 5060 -j ACCEPT

Попробуйте с помощью telnet тыкнуться в любой другой порт, отличный от 22 и 5060. Тут же получите бан.

Защита от bruteforce средствами iptables на примере ssh порта:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name BANLIST --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name BANLIST --update --seconds 60 --rttl --hitcount 3 -j DROP
iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT

Разрешаем только 3 запроса в минуту, третий должен быть удачным, чтобы подключиться, иначе ip адрес уходит в бан на 60 секунд.

Можно то же самое сделать с помощью модуля hashlimit. С одного ip разрешаем 2 запроса на соединение (NEW) в минуту (2/m) все остальные пакеты (NEW) c этого ip блокируется:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m hashlimit
--hashlimit-name BANLIST --hashlimit-mode srcip --hashlimit-above 2/m --hashlimit-burst 2 -j DROP
iptables -A INPUT -p tcp --syn --dport 22 -j ACCEPT

Посмотреть содержимое создаваемого списка BANLIST можно так:
cat /proc/net/xt_recent/BANLIST
src=192.168.13.15 ttl: 128 last_seen: 4295998682 oldest_pkt: 1 4295998682
src=10.8.0.2 ttl: 127 last_seen: 4296007032 oldest_pkt: 4 4295389944, 4295734397, 4295895199, 4296007032

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

Полный рабочий набор правил iptables с примерами выше:
https://log.serveradmin.ru/OpfLstlV

Заметку рекомендую сохранить.

#iptables #security

​​Есть удобный инструмент для отладки работы iptables - iptables-tracer. С его помощью можно отследить путь прохождения пакета по цепочкам iptables. Утилита написана на Go, так что ставится относительно просто. Надо собрать бинарник, причём сделать это можно где угодно, а потом просто передать на целевой сервер.

# apt install golang git
# git clone https://github.com/x-way/iptables-tracer
# cd ./iptables-tracer/
# go build
Почему то команда, которую я считал аналогичной трём выше:
# go get github.com/x-way/iptables-tracer
не собрала бинарник. Не стал разбираться с ошибкой. Мне всегда казалось, что это одно и то же. В итоге у вас соберётся бинарник iptables-tracer, который можно запускать с нужными параметрами.

Посмотрим список правил iptables:
# iptables -L -v -n
# iptables -L -v -n -t nat

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

# ./iptables-tracer -f "-d 10.20.1.56 -p icmp" -t 30s
nat PREROUTING NEW IP 10.20.1.1 > 10.20.1.56: ICMP echo request, [In:ens18 Out:]
filter INPUT NEW IP 10.20.1.1 > 10.20.1.56: ICMP echo request, [In:ens18 Out:]
nat  INPUT NEW IP 10.20.1.1 > 10.20.1.56: ICMP echo request, [In:ens18 Out:]

Запросы шли извне, так что сначала попали в таблицу NAT, цепочку PREROUTING, потом в таблицу FILTER, цепочку INPUT. Всё достаточно наглядно и понятно, как на картинках со схемой прохождения пакетов в iptables. Синтаксис фильтров для iptables-tracer аналогичен правилам iptables, так что проблем с написанием возникнуть не должно.

Когда что-то не получается с iptables, я первым делом включаю лог всех заблокированных запросов. Это самое простое. Там обычно сразу видно, в чём проблема и какое конкретно направление блокируется. Если не помогает, то подключаю iptables-tracer.

#iptables

Простой и эффективный способ запретить скан портов на своём сервере с помощью iptables. Просто баним всех, кто стучится не на открытый целевой порт. Допустим, у вас запущен OpenVPN на TCP и UDP портах 34881. Забаним на 10 минут всех, кто обращается не к ним.

# Блокируем тех, кто обращается на неоткрытые порты tcp
iptables -A INPUT -m recent --rcheck --seconds 600 --name BANPORT -j DROP
iptables -A INPUT -p tcp -m multiport ! --dports 34881 -m recent --set --name BANPORT -j DROP
iptables -A INPUT -p tcp --syn -m multiport --dports 34881 -j ACCEPT

# Блокируем тех, кто обращается на неоткрытые порты udp
iptables -A INPUT -m recent --rcheck --seconds 600 --name BANPORT -j DROP
iptables -A INPUT -p udp -m multiport ! --dports 34881 -m recent --set --name BANPORT -j DROP
iptables -A INPUT -p udp -m multiport --dports 34881 -j ACCEPT

Я использую multiport с заделом на список из нескольких портов, которые в случае необходимости можно перечислить через запятую. Посмотреть список забаненых:
# cat /proc/net/xt_recent/BANPORT
Удалить оттуда:
# echo -1.1.1.1 > /proc/net/xt_recent/BANPORT
Очистить список:
# echo / > /proc/net/xt_recent/BANPORT

Такой вот простой способ скрыть от посторонних глаз сервис, который не получается ограничить какими-то списками. Понятное дело, это не 100% защита, так как найти открытый порт всё равно возможно, но для этого нужно приложить довольно много усилий. Если бан сделать вечным, то нужно очень много IP адресов, чтобы найти открытый порт.

Подобным способом можно скрыть проброс RDP или какого-то ещё порта от посторонних глаз. Когда будете настраивать, не забудьте разместить эти правила в общем списке правил фаервола так, чтобы они реально работали, и пакеты не попадали раньше в какие-то разрешающие правила.

#iptables #security

​​Если вам нужно заблокировать какую-то страну, чтобы ограничить доступ к вашим сервисам, например, с помощью iptables или nginx, потребуется список IP адресов по странам.

Я сам всегда использую вот эти списки:
⇨ https://www.ipdeny.com/ipblocks
Конкретно в скриптах забираю их по урлам. Например, для России:
⇨ https://www.ipdeny.com/ipblocks/data/countries/ru.zone
Это удобно, потому что списки уже готовы к использованию — одна строка, одно значение. Можно удобно интегрировать в скрипты. Например, вот так:

#!/bin/bash

# Удаляем список, если он уже есть
ipset -X whitelist
# Создаем новый список
ipset -N whitelist nethash

# Скачиваем файлы тех стран, что нас интересуют и сразу объединяем в единый список
wget -O netwhite http://www.ipdeny.com/ipblocks/data/countries/{ru,ua,kz,by,uz,md,kg,de,am,az,ge,ee,tj,lv}.zone

echo -n "Загружаем белый список в IPSET..."
# Читаем список сетей и построчно добавляем в ipset
list=$(cat netwhite)
for ipnet in $list
 do
 ipset -A whitelist $ipnet
 done
echo "Завершено"
# Выгружаем созданный список в файл для проверки состава
ipset -L whitelist > w-export

Тут я создаю список IP адресов для ipset, а потом использую его в iptables:

iptables -A INPUT -i $WAN -m set --match-set whitenet src -p tcp --dport 80 -j ACCEPT

Если в списке адресов более 1-2 тысяч значений, использовать ipset обязательно. Iptables начнёт отжирать очень много памяти, если загружать огромные списки в него напрямую.

Есть ещё вот такой сервис:
⇨ https://www.ip2location.com/free/visitor-blocker
Там можно сразу конфиг получить для конкретного сервиса: Apache, Nginx, правил Iptables и других. Даже правила в формате Mikrotik есть.

☝ Ссылки рекомендую в закладки забрать.

#iptables #nginx #security #script

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

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

Вот пример простейшего набора правил для веб сервера, где запрещено всё, что не разрешено явно (22,80,443 порты). Показываю для понимания принципа.

# default rules
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# allow localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# allow established
iptables -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

# allow ping
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# allow server connections
iptables -A OUTPUT -o ens3 -j ACCEPT

# allow ssh, www
iptables -A INPUT -i ens3 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i ens3 -p tcp --dport 443 -j ACCEPT

# logging
iptables -N block_in
iptables -N block_out
iptables -N block_fw
iptables -A INPUT -j block_in
iptables -A OUTPUT -j block_out
iptables -A FORWARD -j block_fw
iptables -A block_in -j LOG --log-level info --log-prefix "-IN-BLOCK-"
iptables -A block_in -j DROP
iptables -A block_out -j LOG --log-level info --log-prefix "-OUT-BLOCK-"
iptables -A block_out -j DROP
iptables -A block_fw -j LOG --log-level info --log-prefix "-FW-BLOCK-"
iptables -A block_fw -j DROP

С такими правилами в лог будут попадать все заблокированные соединения во всех трех цепочках. В обычной работе это не нужно. Но если набор правил большой, бывает, что добавляете куда-то новое правило, а пакеты по какой-то причине не ходят. Такое бывает нередко, особенно когда между различных VPN туннелей приходится трафиком управлять. Добавляете правила для логирования из этого примера и смотрите, нет ли ваших пакетов в списке заблокированных. Префиксы для разных цепочек помогают быстро грепать разные цепочки. Если находите заблокированные пакеты, разбираетесь, почему они там оказались. Вносите исправление в правила. Когда всё закончите, правила с логированием удаляете, чтобы не собирать ненужные логи.

📌 Полезные материалы по теме:

▪ Графическое отображение правил iptables
▪ Защита от брута и скана портов
▪ Отладка работы с помощью iptables-tracer
▪ Бан всех, кто стучит в закрытый порт
▪ Блокировка стран по IP

#iptables

​​Iptables по прежнему остаётся наиболее распространённым файрволом на Linux. Несмотря на то, что nftables уже давно анонсированы и по умолчанию установлены во многих дистрибутивах, тот же Docker по прежнему по умолчанию использует iptables.

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

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

Пакеты проходят по списку правил по порядку, сверху вниз. Если пакет соответствует какому-то правилу, то он прекращает движение по цепочке. Из этого следует важный вывод — первыми в цепочке должны быть правила, которые охватывают максимальный объем трафика, чтобы он дальше не обрабатывался устройством. Примером такого правила является разрешение пакетов уже установленных (established) или связанных (related) соединений, которые ранее были разрешены каким-то правилом. Повторно проверять по всем правилам их не имеет смысла. То же самое относится к проблемным пакетам (например, invalid), которые нам не нужны и мы можем их сразу отбросить.

Правила читаются по порядку в каждой отдельной цепочке: Input, Forward, Output. Если вы в списке своих правил как-то их перемешаете, то это не повлияет на порядок их обработки. Каждое правило попадёт в ту цепочку, к которой оно относится и будет выполняться в соответствии со списком правил в этой цепочке.

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

1️⃣ Разрешающие правила, охватывающие максимальный объём трафика.
2️⃣ Остальные разрешающие правила.
3️⃣ Правило, запрещающее весь трафик данной цепочки.

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

Вот пример минимального набора правил для шлюза на базе Linux и iptables. Он подойдёт как для обычного офиса, так и для шлюза виртуальных машин гипервизора. Его же можно использовать прямо на гипервизоре Proxmox, если он сам выступает шлюзом для виртуальных машин.
⇨ https://pastebin.com/0sw4Cr5w

#iptables

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

Порядок настройки следующий:

1️⃣ Сохраняю список правил в файл /etc/iptables.sh. Адаптирую под текущие условия гипервизора: меняю имена сетевых интерфейсов, IP адреса. Делаю его исполняемым. Обычно сразу же проверяю, просто запустив его.

# mcedit /etc/iptables.sh
# chmod +x /etc/iptables.sh
# bash /etc/iptables.sh
# iptables -L -v -n

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

2️⃣ Убеждаюсь, что после выполнения скрипта появился файл-экспорт с набором правил /etc/iptables.rules. Добавляю применение правил в файл /etc/network/interfaces:

iface enp5s0 inet manual
post-up iptables-restore < /etc/iptables.rules

Вешаю загрузку правил iptables на поднятие wan интерфейса.

3️⃣ Перезагружаю сервер и убеждаюсь, что всё нормально поднимается, правила применяются, доступ к серверу у меня есть.

4️⃣ Если нужно добавить или изменить какое-то правило, то правлю файл iptables.sh, а когда закончу, запускаю его. Он обновляет набор правил в iptables.rules, так что после перезагрузки хоста изменённые правила сохранятся.

Если у вас хост Proxmox выполняет роль шлюза, то не забудьте проверить, что параметр net.ipv4.ip_forward=1 активен в /etc/sysctl.conf. Без него NAT для виртуалок не заработает. Точнее не сам нат, а передача пакетов между локальным и wan интерфейсом. Если в качестве шлюза для VM выступает отдельная VM, то как минимум из набора правил исчезает NAT и всё, что касается локалки и проброса портов. А на шлюз уезжает этот же шаблон с правилами и там правится по месту.

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

Формирую набор правил именно в таком виде, потому что он мне кажется удобным и наглядным. Можно быстро оценить все правила, оставить комментарии, что-то добавить.

#proxmox #iptables