В данной импровизированной лаборатории я хотел бы осветить работу с сетями в GNU\Linux
и рассмотреть следующие темы:
- Изучаем vlan. Строим сеть между vm1, vm2 в одном vlan. Пингуем, ловим пакеты, изучаем заголовки.
- Разбиваем vm1 vm2 на разные vlan. Настраиваем intervlan routing с помощью R1.
- Iptables. Настраиваем маскарад. Имитируем выход во внешние сети.
- Iptables. Настраиваем port forwarding для сервисов на vm1 и v2, которые находятся за NAT.
- Iptables. Настраиваем security zones. Изучаем tcp сессии.
З.Ы. все люди ошибаются, я открыт для ваших комментариев, если я написал какую-то глупость, готов ее исправить!
Дано: локальная сеть, состоящая из VM1,VM2. Роутер R1 (тоже виртуальная машина), веб сервер S1.
Скачать готовую виртуалку для этой лабораторки можно с яндекс диска
Т.к. я попытался подать данную статью как урок, то по большей части я не пишу команды текстом, а делаю скриншот, чтобы их вбивали своими руками. Это помогает лучше разобраться и быстрее запомнить. Я вполне понимаю что это неудобно, но я решил выбрать такой подход.
Настройка для VM1 — подключаем как bridge к интерфейсу. Интерфейс можно выбрать любой и забриджевать все на него. Для полноты соответствия схеме я сделал в системе 2 bridge адаптера (br0,br1) и подключил vm1,vm2,r1(адаптером 1) к br0, а s1,r1(адаптером 2) к br2.
Для остальных 3-х настройки аналогичны.
I. Изучаем vlan. Строим сеть между vm1, vm2 в одном vlan. Пингуем, ловим пакеты, изучаем заголовки.
Запускаем vm1 и vm2 и смотрим интерфейсы в нашей системе командой
ip addr
(сокращенно ip a)Добавляем новое устройство, которое будет называться eth0.100 и представлять собой тегированный интерфейс с id=100.
ip link add - добавить устройство
link eth0 - соединить с ФИЗИЧЕСКИМ адаптером eth0
name eth0.100 - имя устройства в списке. Это имя можно выбрать любым, но для собственного удобства мы выбрали имя физического интерфейса и номер vlan. так то точно не запутаемся
type vlan - тип создаваемого интерфейса. Оно работает с 8021q - тип vlan
id 100 - собственно сам id vlan
Теперь присвоим этому интерфейсу ip адрес:
ip addr add 10.10.10.10/24 dev eth0.100
короткий вид записи:
ip a a 10.10.10.10/24 dev eth0.100
Обращаем внимание на следующие вещи: no-carrier и DOWN
это значит что у нас к интерфейсу не подключен сетевой кабель, а сам интерфейс находится в DOWN.
Подключаем кабель и получаем такую картину:
И выполним включение интерфейса командой:
ip link set dev eth0.100 up
Таким образом мы создали интерфейс, который будет получать тегированные пакеты с vlan id = 100 и соответственно вешать на пакеты тег 100 при выпуске пакета в сеть через этот интерфейс. и назначили ему ip адрес 10.10.10.10/24
делаем то же самое на VM2, назначаем адрес 10.10.10.20/24
Проверяем связность между VM1 и VM2: выполним ping 10.10.10.10 с VM2
Проверяем, что все это не ложь и провокация! Запустим на VM1 слушателя и постучимся на него с VM2 и проснифаем траффик.
1. на VM1 запустим
nohup nc -lvp 3000 &
tcpdump -n host 10.10.10.20 -i eth0 -e
2. на VM2 запустим
nc 10.10.10.10 3000
Видим в заголовках канального уровня vlan 100. Значит пакеты по сети реально ходят с тегами и это не выдумки матушки гусыни.
II. Разбиваем vm1 vm2 на разные vlan. Настраиваем intervlan routing с помощью R1.
Теперь переходим к пункту №2 — разобьем эти 2 виртуалки на разные vlan и настроим роутер.
На VM1:
добавить интерфейс eth0.200 c тегом 200 и присвоить ему адрес 192.168.0.2
на VM2:
добавить интерфейс eth0.300 c тегом 300 и присвоить ему адрес 172.16.0.2
(Самостоятельно)
Включим и настроим роутер R1. На роутере в отличие от VM1, VM2 нужно создать интерфейс и во vlan 200 и во vlan 300 — этот интерфейс будет шлюзом в данных сетях. Присвоим им адреса 192.168.0.1, 172.16.0.1.
Проверяем связность. Пингуем с роутера 192.168.0.2 и 172.16.0.2. (Кстати говоря вот тут была небольшая проблема, т.к. я ошибся в настройке eth0.300 на VM2.
Итак, мы получили связность между VM1,R1 и VM2,R1. Попробуем связать VM1,VM2 через R1.
Для того чтобы наш Router получил возможность форвардить пакеты между интерфейсам нужно разрешить ему это. Необходимо раскомментировать директиву net.ipv4.ip_forward = 1 в файле /etc/sysctl.conf и применить изменения командой sysctl -p.
# nano /etc/sysctl.conf
# sysctl -p
net.ipv4.ip_forward = 1
А теперь самое главное. Нужно настроить маршрутизацию. Есть 3 распространенных способа это сделать:
1. указать маршрут по умолчанию. т.е. мы не знаем где у нас находится destination ip, поэтому все пакеты не принадлежащие локальной сети шлем на роутер.
2. указать шлюз для конкретной подсети. Это нужно делать если сети доступны за разными маршрутизаторами.
3. указать интерфейс, за которым находится тот кто примет пакет. Такая ситуация у меня возникала, например при необходимости в ЦОДе смаршрутизировать подсеть. Т.е. Была виртуалка-роутер на внешний адрес которой датацентр статически маршрутизировал выделенную мне подсеть. Тогда я просто указал что ip адеса этой подсети находятся на одним из торчащих внутрь интерфейсов роутера. Пакеты слались в этот интерфейс и принимались на той стороне виртуалками, которым и были назначены эти белые адреса. т.е. в данной ситуации указывать шлюз было совершенно необязательно.
посмотрим список маршрутов на VM1:
ip ro
Наша виртуалка знает всего о 2 подсетях: 10.10.10.0/24 & 192.168.0.0/24. Про хост 172.16.0.2 ничего не сказано! потому если попробовать пропинговать ничего не выйдет:
добавим маршрут к подсети 172.16.0.0/24:
ip ro add 172.16.0.0/24 via 192.168.0.1
via — значит через кого. т.е. отправляем пакеты хосту 192.168.0.1, он разберется.
Просматривая таблицу маршрутизации принимается следующее решение:
1. Кому предназначен данный пакет? хосту 172.16.0.2
2. Кому отправить пакет 172.16.0.2? хосту 192.168.0.1
3. Что мы знаем о хосте 192.168.0.1? он directly connected. Эта подсеть наша. формируем на канальном уровне mac адрес источника, mac адрес хоста 192.168.0.1, ip источника — 192.168.0.2, ip адрес назначение 172.16.0.2, и отправляем через интерфейс eth0.200. Как говорил автор подкаста «сетей для самых маленьких», дальшейшая судьба пакета нас не волнует.
Попробуем пропинговать шлюз соседнего vlan:
ping 172.16.0.1
Работает! Но что будет если пинговать 172.16.0.2? Работать не будет, потому что нет обратного маршрута. Пакет дойдет до хоста VM2, а вот обратно VM2 отправить его уже не сможет, т.к. не знает куда. Попробуем добавить маршрут обратно на VM2.
Добавим маршрут по-умолчанию для VM2. Сделать это можно указав подсеть и маску (0.0.0.0/0 — т.е. под нее попадают абсолютно все адреса) или используя ключевое слово default
Получим один и тот же результат. И в итоге теперь VM1 свободно пингует VM2. Ура!
Подведем итог: Мы научились выполнять маршрутизацию между 2 vlan с помощью linux-роутера.
III. Iptables. Настраиваем маскарад. Имитируем выход во внешние сети.
Добавляем некий публичный сервер S1. на нем я поставлю apache2 (apt install apache2) и буду имитрировать веб-сервер в интернете. Тогда как наши VM1,VM2 — приватные машинки, которые находятся за роутером. Роутер вторым интерфейсом смотрит в импровизированный интернет.
Добавим 2-й интерфейс для R1 — eth1 и уже без VLAN настроим ему ip адрес 8.8.8.100, а на S1 — 8.8.8.8
Важно помнить, что все команды, которые мы вводили в консоли работают только до перезагрузки. Когда я добавлял 2 интерфейс и выключил виртуалку, то после перезагрузки получил не настроенную машину, вследствие чего все команды пришлось применить заново.
Если вы повторяете за мной в том числе и настройку VBOX, не забудьте добавить в br1 обе сетевые карты и на S1 и на R1. Bridge интерфейс в системе можно создать командой
ip link add br1 type bridge
.Но вообще сделать всю лабу можно сделать и на одном любом интерфейсе ничего не создавая.
Я акцентирую разделение для того чтобы имитировать bridge = как бы коммутатор.
После настройки S1, R1 проверяем связность — выполним ping 8.8.8.8 — с R1 он должен работать. При этом если мы будем пинговать с VM2, то пинга не будет.
ip ro add default via 8.8.8.100
Кроме того, если мы будем пинговать сервак с VM1 то он вообще скажет что сеть недоступна.
Исправим это прописав gateway:
Теперь все 4 машинки прекрасно пингуют друг друга. Но так быть не должно. Серые адреса не должны выходить в интернет! И та сеть, куда смотрит вторым интерфейсом R1, не должна знать где находятся адреса 172.16.*.*, 192.168.*.*.
Удалим deafult gw с S1:
ip ro del default
Подведем итог: мы научились прописывать маршруты до необходимых нам сетей, а также узнали как «прятать» серые адреса за маршрутизатором, выпуская «наружу» весь трафик только через один белый адрес.
Настало время поговорить о NAT. NAT (от англ. Network Address Translation — «преобразование сетевых адресов») — это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов. Также имеет названия IP Masquerading, Network Masquerading и Native Address Translation. Мы рассмотрим маскарадинг. это SourceNAT (SNAT) && DestinationNAT (DNAT).
Что нам от NAT вообще нужно? А нужно нам, чтобы исходящий в сторону S1 пакет получал в качестве source ip адрес маршрутизатора, а когда возвращался обратно — получал адресом назначения вновь адрес виртуалки.
Настроим маскарад для подсети 17.16.0.0/24 — выполним на роутере команду:
iptables -t nat -A POSTROUTING -p tcp -m tcp -s 172.16.0.0/24 ! -d 172.16.0.0/24 -j MASQUERADE
Я не буду расписывать подробно как работают iptables, т.к. это много и много буков и эта статья явно не для этого. Вот очень неплохая статья на изучение.
Обращу только внимание на
! -d 172.16.0.0/24: зачем это нужно. Это нужно для того чтобы хосты из подсети 172.16.0.0/24, которые потенциально могли бы находиться за маршрутизатором (например удаленные vpn клиенты) не попадали бы под действие этого правила.Посмотреть полученный результат можно командой
iptables-save
Итак, чего мы достигли? Мы настроили маскарад для VM2. Это значит что когда она будет стучаться к S1, то S1 увидит адрес не VM2, а адрес роутера! Парочка пруфов:
а что же в этот момент видит S1?
8.8.8.8 прекрасно общается с 8.8.8.100, никаким 172.16.0.2 и не пахло!
А что же происходит в этот момент на роутере? Как работает эта кухня? Подслушаем «серый» интерфейс eth0.300
А вот как это выглядит на выходе во «внешнюю» сеть:
Ядро в зависимости от направления пакета обрабатывает его и подставляет правильные ip адреса. А вот если мы сделаем то же самое с VM1, то S1 увидит серые адреса. и просто не ответит на данный запрос. Посмотрите на это самостоятельно. Напомню, что GW на S1 необходимо удалить.
Подведм итог: Мы скрыли наши серые сети и выпустили хосты за роутер, подменив ip адеса источников на адрес роутера. И в другую сторону — мы научились пробрасывать определенный порт определнной виртуалки «наружу» и смогли подключиться к серому адресу виртуалки VM1 из «публичной» сети с сервера S1.
IV. Iptables. Настраиваем port forwarding для сервисов на vm1 и v2, которые находятся за NAT
Сымитируем, что S1 — некий клиент из интернета и он хочет подключиться к VM1 (тот клиент, до которого нет ни маршрута, ни настроен маскарад). Пусть это будет попытка подлючиться по ssh. SSH по дефолту висит на 22 порту, но если у нас таких серваков будет больше 1, то как быть? Вообще по-хорошему чтобы избавиться от самых простых сканеров сети, ssh нужно всегда убирать с 22 порта. Воспользуемся портом 30022, например, чтобы обратиться по ssh к VM1.
Как это работает?
S1 отправляет пакет (s.ip=S1.ip, d.ip=R1.ip; s.port=N, d.port=30022) который прилетает на R1.
R1 Просматривает iptables и применяет правило DNAT, и формирует пакет (по нашему правилу): (s.ip=S1.ip, d.ip=VM1.ip; s.port=N, d.port=22)
Просматривает таблицу маршрутизации и отправляет пакет vm1 через интерфейс eth0.200.
VM1 в свою очередь принимает пакет, получает data, и формирует ответ: (s.ip=VM1.ip, d.ip=S1.ip; s.port=22, d.port=N).
R1 принимает пакет и восстанавливает исходный s.ip к которому изначально обратился s1:
(s.ip=R1.ip, d.ip=S1.ip; s.port=22, d.port=N)
Достичь этого можно следующим образом:
пробуем подключиться:
Подведм итог: мы научились предоставлять доступ к сервисам, расположенным на виртуальных машинах за неким роутером (иначе можно сказать — к виртуалкам за NAT'ом — что как раз чаще всего и нужно)
V. Iptables. Настраиваем security zones. Изучаем tcp сессии.
И последнее, что я хотел бы рассмотреть в данном занятии — tcp сессии и направление установки этих сессий. Так, например, рассмотрим 2 сегмента: серверный и клиентский. Клиент, например, должен иметь возможность «сходить» в серверный сегмент к контроллеру домена. А вот контроллеру домена делать на клиентской машине нечего. Таких примеров можно придумать множество и ситуации почему из одного сегмента сети в другой ходить можно а наоборот нет — тоже. Зачем же может это понадобиться? Например у нас есть веб сервер, который «смотрит» в интернет и им «завладел» злоумышленник. С этого сервера он вполне может попробовать постучаться в корпоративную сеть. Однако, если запретить устанавливать сессии из этого сегмента — этого не произойдет. Т.е. мы по крайней мере усложняем злоумышленнику жизнь. Давайте добавим правило, которое запретит ходить VM2 к VM1, а VM1 к VM2 — можно.
Пробуем ходить с VM1 на VM2:
и в обратную сторону:
Почему так происходит? В момент установления TCP сессии прилетает пакет TCP SYN (на него отвечается SYN ACK, а потом ACK и сессия считается установленной). первое правило которое мы записали (c NEW) разрешает форвардить пакеты TCP SYN из сети 192.168.0.0 в 172.16.0.0.
Когда второй участник отвечает на этот и любой последубщий пакет, то попадает под действие 2 правила об установленных сессиях и такие пакеты из сети 172.16.0.0 проходят. А вот если он сам попробует установить сессию (или просто пингануть) то не попадет по 1,2 правило, а попадет под 3-е, которое дропнет этот пакет. Voila!
Подведем итог: Мы научились управлять направлениями установки tcp сессий для контроля направления трафика между зонами безопасности.
Спасибо за внимание!
Свои черновики лекции я выкладываю в канале telegram: http://ift.tt/2j8wMRV
Комментарии (0)