08. Политики firewall
В прошлый раз мы поделили нашу сеть на зоны, тем самым перекрыв все доступы. Сегодня же мы разберёмся, как точечно выдавать эти доступы. В реальной инфраструктуре этим обычно занимается отдел информационной безопасности, но мы тоже неспроста это разбираем. Обычно, когда администратор настраивает и связывает какие-то сервера в разных зонах, он должен обратиться к отделу безопасности и сообщить, что ему нужно. Мол, у меня есть джампхост во втором влане с IP 10.0.2.101 и нужно, чтобы он мог подключаться к серверу1 по адресу 10.0.5.101 и по порту 22. Т.е. выпрашивать доступы на файрволе - это стандартная процедура для администратора. И чтобы закрепить это у себя в голове и понимать, когда это нужно, а когда нет - мы сами будем по необходимости прописывать эти правила. Да, в реальной инфраструктуре никто это не делает через firewalld, но нам главное понять саму идею, зачем и как это делать. А этот инструмент или другой - абсолютно неважно.
Сегодня мы будем работать с роутером 1 и 3. В прошлый раз мы запретили с jumphost-а подключаться к роутеру1:
1
firewall-cmd --list-all --zone=dmz
Copied!
И чтобы не настраивать всё через консоль, временно разрешим ssh:
1
firewall-cmd --add-service=ssh --zone=dmz
Copied!
Стартанём ssh-агент:
1
eval $(ssh-agent)
Copied!
добавим ключи:
1
ssh-add .ssh/jumphost .ssh/servers
Copied!
И подрубимся к роутеру:
1
ssh router1
Copied!
В прошлый раз на роутере 3 мы создали зону routers, а на роутере 1 всё осталось в public зоне:
1
sudo firewall-cmd --list-all
Copied!
Давайте это исправим. Для начала создадим зону routers:
1
sudo firewall-cmd --new-zone=routers --permanent
Copied!
Переместим в неё интерфейс, который в одной сети с роутером 3:
1
sudo firewall-cmd --change-interface=team0 --zone=routers --permanent
Copied!
Добавим в эту зону ssh, чтобы мы могли с роутера 3 подключаться к роутеру 1:
1
sudo firewall-cmd --add-service=ssh --zone=routers --permanent
Copied!
Потому что с джампхоста нельзя, а иначе только через консоль. Перезапустим файрвол и проверим новую зону:
1
sudo firewall-cmd --reload
2
sudo firewall-cmd --list-all --zone=routers
Copied!
Всё как и должно быть.
Пока не забыл. Недавно мы на роутере1 прописали 3 маршрута:
1
ip ro sh
Copied!
3, 4 и 5 сети. Но если у нас количество сетей будет постоянно расти, чтобы не забывать их добавлять, давайте поменяем подход. Уберём эти 3 сети:
1
sudo nmcli connection modify team -ipv4.routes "10.0.3.0/24 10.0.1.254"
2
sudo nmcli connection modify team -ipv4.routes "10.0.4.0/24 10.0.1.254"
3
sudo nmcli connection modify team -ipv4.routes "10.0.5.0/24 10.0.1.254"
Copied!
и вместо них пропишем всю подсеть 10.0.0.0/8 - сюда входит всё от 10.0.0.0 до 10.255.255.255.
1
sudo nmcli connection modify team +ipv4.routes "10.0.0.0/8 10.0.1.254"
Copied!
Затем поднимем профиль и проверим таблицу маршрутизации:
1
sudo nmcli connection up team
2
ip ro sh
Copied!
Теперь всё, что касается локальной сети, будет пересылаться на третий роутер.
Давайте представим себе схему подключения jumphost-а к server1. Изначально пакет идёт от jumphost-а к router1. Для router1 jumphost находится в зоне DMZ. Дальше router1 передаёт пакет на router3. Для router1 router3 находится в зоне routers. Тоже самое для router3 - router1 находится в зоне routers.
Что касается router3, в нашей схеме сейчас трафик из DMZ зоны, чтобы попасть во внутреннюю сеть, должен будет проходить сначала через router1, и только потом через роутер3. А это значит, что мы будем перегонять лишний трафик через роутер1. Поэтому давайте лучше добавим к роутеру3 второй влан, чтобы устройства из DMZ напрямую проходили через роутер3. Я пропущу добавление второго влана на роутере 3 и настройку транк портов на свитчах, мы это уже разбирали.
На роутере 3 я создал новый влан интерфейс с адресом 10.0.2.254 и добавил его в зону DMZ.
На самом jumphost-е, чтобы он направлял все пакеты во внутреннюю сеть через адрес третьего роутера, пропишем новый маршрут:
1
sudo nmcli connection modify team +ipv4.routes "10.0.0.0/8 10.0.2.254"
Copied!
Затем поднимем интерфейс и проверим таблицу маршрутизации:
1
sudo nmcli connection up team
2
ip ro sh
Copied!
Тут мы видим, что все пакеты, идущие в сеть 10.0.0.0/8 будут проходить через роутер3. А все другие адреса - через роутер 1.
Теперь подключение от jumphost-а на сервер выглядит попроще - посреди только роутер3. Jumphost для роутера3 находится в зоне DMZ, а сервер1 в зоне management. Точнее в двух зонах - servers и management, но нас сейчас интересует только вторая зона.
Подключимся к серверу1. К нему по ssh можно подрубиться только с 5 влана:
1
ip a
Copied!
А он у нас на интерфейсе ens5. Давайте посмотрим tcpdump на этом интерфейсе:
1
tcpdump -i ens5
Copied!
Теперь идём на jumphost и пытаемся пингануть:
1
ping 10.0.5.101
Copied!
Пинга нет. Но дело не в файрволе, он у нас все пинги по-умолчанию разрешает. Также не получается подключиться по ssh:
1
ssh 10.0.5.101
Copied!
Но это ещё понятно, тут дело в файрволе. К нему мы ещё придём, а пока попытаемся разобраться, почему server1 не пингуется.
Идём и смотрим tcpdump. Как видите, пакетов по ssh не было, но вот пинги приходили. Но на них не было ответа. Почему?
Есть одна особенность, когда у вас в системе несколько IP адресов, как на нашем сервере1. У него два адреса - 10.0.4.101 и 10.0.5.101. А вот default gateway всего 1 - 10.0.4.1. И вот представьте - джампхост посылает пинг на адрес 10.0.5.101. Сервер1 должен ответить на адрес 10.0.2.101. Но у него в таблице маршрутизации сказано, что этот адрес доступен за адресом 10.0.4.1 - а значит ответ надо посылать с другого интерфейса, на котором IP - 10.0.4.101. Т.е. пакет приходит с одного интерфейса, а ответить надо с другого. С одной стороны, мы могли бы для адреса 10.0.2.101 прописать маршрут через 10.0.5.1. Но тогда бы возникла обратная проблема - если запрос будет приходить на 4.101, то ответ будет посылаться с 5.101 - что приведёт к такой же проблеме.
Обычно так не должно быть. Поэтому ядро по-умолчанию блокирует такие ответы. Т.е. если пакет приходит с одного интерфейса, а ответ нужно послать с другого - то ядро не разрешает. В целом, конечно, можно разрешить, но с точки зрения маршрутизации это не совсем верно. Есть более правильный способ. Нам надо для интерфейса, где адрес 5.101 прописать свою таблицу маршрутизации.
Для начала разберёмся с таблицами и правилами маршрутизации. Вкратце, есть таблица маршрутизации:
1
ip route sh
Copied!
Ничего такого. Есть ещё правила маршрутизации:
1
ip rule show
Copied!
Числа слева - приоритет. Чем ближе к 0 - тем он выше. Дальше "от кого" - from all. Тут мы указываем исходящую сеть. И потом lookup и 3 значения - local, main и default. Это и есть таблицы маршрутизации. Та таблица маршрутизации, которую мы видим при вводе ip ro sh - одна из них - main. Можем убедиться в этом введя команду:
1
ip route show table main
Copied!
Есть ещё local:
1
ip route show table local
Copied!
Здесь, в основном, про локальные сети.
Т.е. мы можем создать несколько таблиц маршрутизации и можем написать, что для запросов с таких-то сетей нужно использовать такую-то таблицу маршрутизации, при этом учитывая ещё и приоритет. Чтобы было понятнее, сделаем это на сервере1.
Добавим для интерфейса ens5 в профиле NetworkManager-а новый маршрут, при этом указав таблицу с каким-то числом, допустим, 2:
1
nmcli con mod management ipv4.routes "10.0.0.0/8 10.0.5.1 table=2" ipv4.routing-rules "priority 5 from 10.0.5.101 table 2"
Copied!
И так, мы в профиле интерфейса ens5 сказали, что для сети 10.0.0.0/8 нужно использовать в качестве гейтвея 10.0.5.1, при этом это относится к таблицу маршрутизации 2. И сразу же добавили правило с приоритетом 5, исходящим IP 10.0.5.101 и этой таблицей 2.
Поднимем интерфейс и посмотрим правила и таблицу маршрутизации:
1
nmcli con up management
2
ip rule list
3
ip route show table 2
Copied!
Как видите, теперь у нас есть правило с приоритетом 5, которое указывает на таблицу 2, где и указан маршрут для локальной сети. Теоретически, вместо 10.0.0.0/8 можно было бы указать 0.0.0.0/0, чтобы у каждого интерфейса был свой default gateway, но так как речь касается management интерфейса, я не хочу, чтобы у него был маршрут в интернет.
Теперь с самого jumphost-а можно пинговать server1 как по адресу 4.101, так и по 5.101:
1
ping 10.0.4.101
2
ping 10.0.5.101
Copied!
В итоге получается такая картина: когда запрос приходит на интерфейс с адресом 4.101, то для ответа используется таблица маршрутизации main, в которой default gateway-ем является адрес роутера 4.1. А вот если запрос придёт на адрес 5.101, то будет использоваться таблица маршрутизации 2, в которой есть обратный маршрут через адрес роутера 5.1.
Теперь, когда мы привели в порядок маршрутизацию, вернёмся к файрволу. И так, мы на внутреннем роутере должны разрешить джампхосту подключаться по ssh к серверу1. Для этого нужны политики файрвола.
Для начала на роутере3 создадим новую политику:
1
sudo firewall-cmd --new-policy=jh_srv1_ssh --permanent
2
sudo firewall-cmd --reload
Copied!
Она должна разрешать подключение от jumphost-а к серверу1 по ssh. Такое название и дадим, чтобы было понятнее.
После создания политика почти пустая:
1
sudo firewall-cmd --info-policy=jh_srv1_ssh
Copied!
Политика сильно напоминает зону. Но если в зоне мы указываем порты и сервисы, по которым могут подключаться к нам, то в политике мы указываем порты и сервисы, которые мы разрешаем в проходящих пакетах от одной зоны к другой. Поэтому здесь есть два дополнительных поля - ingress-zone и egress-zone - входящая зона и исходящая.
Как вы поняли - теперь мы должны добавить ingress и egress зоны в эту политику:
1
sudo firewall-cmd --policy=jh_srv1_ssh --add_ingress_zone=dmz --permanent
2
sudo firewall-cmd --policy=jh_srv1_ssh --add-egress-zone=management --permanent
3
sudo firewall-cmd --reload
Copied!
Соответственно, подключение будет из зоны dmz, значит ingress zone это dmz, а направляться пакеты будут в зону management - значит это egress зона. Проверим политику:
1
sudo firewall-cmd --info-policy=jh_srv1_ssh
Copied!
Как видите, зоны прописались.
Но так как тут нет возможности добавить source и destination адреса, нам остаётся два варианта. Либо придётся просто прописать сервис, что приведёт к тому, что с любого адреса из зоны dmz можно будет по ssh подрубиться к management зоне. А мы этого не хотим.
Либо придётся писать rich rule, что мы и сделаем.
1
sudo firewall-cmd --policy=jh_srv1_ssh --permanent --add-rich-rule='rule family=ipv4 source address=10.0.2.101/32 destination address=10.0.5.101/32 port port=22 protocol=tcp accept'
Copied!
И так, здесь мы говорим, что разрешаем подключение от адреса 10.0.2.101 к адресу 10.0.5.101 по порту 22 и протоколу tcp. И это всё применяется на политику с зоны dmz на management.
Перезагрузим файрвол и проверим политику:
1
sudo firewall-cmd --reload
2
sudo firewall-cmd --info-policy=jh_srv1_ssh
Copied!
Да, появилось правило.
На мой взгляд, здесь политики сделаны немного нелогично. Как минимум нужна возможность добавить source и destination адреса, а не возиться с rich rule-ами. Но это относительно новый функционал у firewalld и не то чтобы кто-то кроме нас использует firewalld как сетевой файрвол. Поэтому на это можно закрыть глаза. У политик есть приоритеты, от которых зависит порядок их проверки, но мы не будем сильно с этим заморачиваться, курс всё таки не об этом.
Давайте попробуем с jumphost-а подключиться к серверу1:
1
ssh 10.0.5.101
Copied!
И всё работает.
Теперь у нас есть возможность попасть во внутреннюю сеть, подключаясь от jumphost-а к серверу1. По сути, теперь server1 будет выступать нашим вторым jumphost-ом. Через него есть выход в 5 влан, откуда мы можем подрубаться к менеджмент интерфейсам. Например, роутера3.
Теперь смотрите какую цепочку мы можем создать в ssh подключении. И так, из интернета у нас доступен только jumphost. Но сам jumphost не может подключаться куда угодно, единственный доступный ему сервер - сервер1. Сам сервер1 может видеть роутер3, так как они находятся в одном management vlan-е. А из роутера3 я могу подключиться к роутеру1. Последнее, на самом деле, не обязательно. Для роутера 1 вы также можете использовать сервер1 в качестве джамп хоста, но тогда надо будет прописать политику файрвола на роутере3, чтобы он разрешал подключение от сервера1 к роутеру1.
Попробуем подключиться. При первом подключении надо будет сохранить ключи от всех промежуточных хостов и ввести все пароли от систем, куда мы не закинули ключи.
Больше мы этих сообщений не увидим:
1
ssh router1
Copied!
А на хосты, которые просят пароли, можем закинуть ключи:
1
ssh-copy-id -i .ssh/servers.pub server1
2
ssh-copy-id -i .ssh/servers.pub router3
Copied!
И теперь простой командой:
1
ssh router1
Copied!
мы через 3 джампхоста попадаем на роутер1. Да и в целом можем на любой хост в сети.
Вообще, если использовать роутер3 в качестве джампхоста, можно попасть на любой хост. Но так как настоящие роутеры не очень годятся в качестве джампхостов, вместо этого мы будем писать правила для файрвола и использовать маршрутизацию. Поэтому это будет небольшим заданием для вас - прописать на нём политики, чтобы можно было с сервера1 подключаться к юзеру1 и роутеру1.
Давайте подведём итоги. Сегодня мы с вами разобрали таблицы и правила маршрутизации, а также политики для файрволов. Хотя пока мы написали всего одну политику, но это в основном было сделано для будущих задач. Когда мы будем поднимать различные сервисы в разных зонах, нам нужно будет постоянно лезть в файрвол и писать политики. А сеть у нас почти готова - дальше можно сконцентрироваться на самих сервисах.
Last modified 6mo ago
Export as PDF
Copy link