МЭ на интерфейсном уровне

Задачи МЭ на интерфейсном уровне:

• Работа непосредственно с фреймами (фильтрация, перенаправление и отслеживание MAC-адресов и их полей)
• Обработка (по возможности) TCP/IP-трафика в сетевых мостах (bridge)
• Ограничение трафика и имитация свойств «настоящей» сети
• Работа на стыке интерфейсного и сетевого уровней (например, ARP)

Сетевой мост (bridge)

FreeBSD (возможна также настройка в /etc/rc.conf):

# ifconfig bridge0 create
# ifconfig bridge0 addm fxp0 stp fxp0 addm fxp1 stp fxp1
# ifconfig fxp0 bridge0 192.0.2.10 netmask 255.255.255.0

Linux

root@mbb-1:~ # brctl addbr mybridge
root@mbb-1:~ # brctl addif mybridge eth0
root@mbb-1:~ # brctl addif mybridge eth1
root@mbb-1:~ # ip addr add dev mybridge 192.168.100.5/24

Spanning Tree Protocol (STP)

Spanning Tree Protocol — пример того, что должно быть реализовано помимо простого перебрасывания фреймов из интерфейса в интерфейс. Задача: если топология сетевых устройств имеет циклы, избавиться от них.

1. Все главные (рассылка оповещений-фреймов с ID)
2. Если принятое оповещение главнее, пересылка его вместо своего (с добавлением также и собственного ID и стоимости пересылки)
3. Остаётся один главный
4. Если оповещение принято из нескольких интерфейсов, все более дорогие интерфейсы деактивируются

Алгоритм неидеальный, имеется множество неидеальных же модификаций (см.).

Имитация сети

образы виртуальных машин с Linux и FreeBSD в каталогах ALC703EFW и FWE-BSD соответственно. У каждой машины 3 сетевых интерфейса:

• типа «NAT» — для доступа по ssh из хост-системы (посмотрите, какой порт пробрасывается)
• 2 «внутренних» (сеть «intnet» и «intnet2»), собранных в мост

FreeBSD dummynet

• на сайте автора, Луиджи Риццо

• в документации по ipfw (раздел «TRAFFIC SHAPER (DUMMYNET) CONFIGURATION»)

Dummynet поддерживает абстрактные очереди и планировщики, но нас интересует «pipe» — имитация подключения к среде передачи данных заданной паршивости. Часть ipfw.

Пример: Файл /etc/rc.conf:

[root@fwe-bsd ~]# cat /etc/rc.conf
hostname="fwe-bsd.fw.cs.msu.su"
ifconfig_em0="dhcp"
dumpdev="NO"

sshd_enable="YES"
cloned_interfaces="bridge0"
ifconfig_bridge0="addm le0 addm le1 up"
ifconfig_le0="up"
ifconfig_le1="up"

firewall_enable="YES"
firewall_type="/etc/rc.ebridge"
dummynet_enable="YES"

Файл /etc/rc.ebridge:

pipe 1 config bw 10Mbit/s
add pipe 1 ip from any to any via le* layer2
add allow ip from any to any via em0 layer2
add allow ip from any to any via lo0
add allow ip from any to any

Linux TC netem

Базовая статья: NETEM By Linux Foundation и tc-netem manual page

Network Emulator — модуль tc qdisc, привязывается непосредственно к интерфейсу (на выходе пакета).

Пример (если root-очередь в tc не указана, по умолчанию — pfifo_fast):

root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 1156 bytes 14 pkt (dropped 0, overlimits 0 requeues 1)
 backlog 0b 0p requeues 1
root@host-15 ~ # tc qdisc add dev enp0s8 root netem rate 256kbit delay 100ms
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc netem 8001: root refcnt 2 limit 1000 delay 100.0ms rate 256000bit
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

Пример использования нескольких настроек в Etcnet. Конфигурационные файлы:

root@host-15 ~ # grep -r . /etc/net/ifaces/[be]*
/etc/net/ifaces/bridge/options:TYPE=bri
/etc/net/ifaces/bridge/options:HOST='enp0s8 enp0s9'
/etc/net/ifaces/enp0s3/options:BOOTPROTO=dhcp
/etc/net/ifaces/enp0s3/options:TYPE=eth
/etc/net/ifaces/enp0s3/options:CONFIG_WIRELESS=no
/etc/net/ifaces/enp0s3/options:CONFIG_IPV4=yes
/etc/net/ifaces/enp0s8/options:TYPE=eth
/etc/net/ifaces/enp0s8/qos/1/qdisc#delay:netem delay 0.5ms loss 0.05% 25% corrupt 0.05%
/etc/net/ifaces/enp0s8/qos/1/qdisc#loss:netem loss 0.33% 25% corrupt 0.33%
/etc/net/ifaces/enp0s8/qos/1/qdisc#rate:netem loss 0.05% 25% corrupt 0.05% rate 10mbit
/etc/net/ifaces/enp0s8/qos/1/qdisc#LOSS:netem loss 5% 10% corrupt 5%
/etc/net/ifaces/enp0s8/qos/1/qdisc:pfifo_fast
/etc/net/ifaces/enp0s9/options:TYPE=eth
/etc/net/ifaces/enp0s9/qos/1/qdisc:pfifo_fast
/etc/net/ifaces/enp0s9/qos/1/qdisc#delay:netem delay 0.5ms loss 0.05% 25% corrupt 0.05%
/etc/net/ifaces/enp0s9/qos/1/qdisc#loss:netem loss 0.33% 25% corrupt 0.33%
/etc/net/ifaces/enp0s9/qos/1/qdisc#LOSS:netem loss 5% 10% corrupt 5%
/etc/net/ifaces/enp0s9/qos/1/qdisc#rate:netem loss 0.05% 25% corrupt 0.05% rate 10mbit

Пояснение. Общая задача стенда — имитировать «плохую» сеть между enp0s9 и enp0s8 различной степени паршивости. Для этого на их выход вешается netem.

alt:Etcnet включает в себя понятие «профиль»: при перезапуске сети вида service network restartwith профиль будут использованы настроечные файлы с именами вида файл#профиль, и только если соответствующего файла нет — файл:

root@host-15 ~ # service network restart
 . . .
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 . . .
root@host-15 ~ # service network restartwith loss
 . . .
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc netem 1: root refcnt 2 limit 1000 loss 0.33% 25% corrupt 0.33%
 . . .
root@host-15 ~ # service network restartwith rate
 . . .
root@host-15 ~ # tc -s qdisc show dev enp0s8
 qdisc netem 1: root refcnt 2 limit 1000 loss 0.05% 25% corrupt 0.05% rate 10000Kbit

Основные возможности dummynet и netem

Сетевой мост и МЭ уровня TCP/IP (ipfw)

Базовая статья: Filtering Bridges Включение (обратите внимание на «прозрачную» коммутацию в ядре вместо создания виртуального сетевого интерфейса типа if_bridge):

# sysctl net.link.ether.bridge.config=fxp0:0,xl0:0
# sysctl net.link.ether.bridge.ipfw=1
# sysctl net.link.ether.bridge.enable=1

Фрагмент правил МЭ ipfw (xl0 смотрит «внутрь», fxp0 — наружу, но всё равно обслуживается единый сегмент локальной сети):

# Outbound
add pass tcp from any to any in via xl0 setup keep-state
add pass udp from any to any in via xl0 keep-state
add pass ip from any to any in via xl0
# Local traffic (my IP is 1.2.3.4)
add pass tcp from 1.2.3.4 to any setup keep-state
add pass udp from 1.2.3.4 to any keep-state
add pass ip from 1.2.3.4 to any
# Inbound ssh
add pass tcp from any to any 22 in via fxp0 setup keep-state
# Inbound SMTP
add pass tcp from any to relay 25 in via fxp0 setup keep-state
# Inbound DNS
add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
add pass udp from any to ns 53 in via fxp0 keep-state
# Inbound icmp
add pass icmp from any to any
# Inbound Ephemeral port (IANA standard only)
add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state
add pass udp from any to any 49152-65535 in via fxp0 keep-state

Пояснения:

• Пакеты, отправляемые с самой машины, надо разрешать отдельно (т. к. они не «получены» ни откуда)

• Волшебные слова relay и ns заработают только если уже работает DNS (это поля MX и NS нашего домена)

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

МЭ интерфейсного уровня в Linux: ebtables

Базовая статья: ebtables/iptables interaction on a Linux-based bridge

• Пакет попадает в ebtables, если он пришёл или уходит через коммутируемый интерфейс

• Пакет покидает ebtables, если его нужно обработать уровнем выше

• Маршрутизация (routing) vs. коммутация (bridging) ⇒ цепочка BROUTE

  • DROP в BROUTE означает только выкидывание из ebtables и передачу на уровень IP

Обратите внимание, что уровнем выше может быть IPTables (а не просто «application», как на схеме)

• Подобно netfilter, ebtables состоит из цепочек и таблиц (путаница та же самая )

Возможности ebtables:

• Фильтр по полям фрейма:
  • mac-адреса интерфейсов (отправителя, входящий и выходящий на мосту, получателя), в т. ч. т. н. Bridge Group Addres
  • по полю «протокол» (фрейма!)
  • …
• Фильтры-модули:

  • поля arp

  • поля ip (включая порты транспортного уровня!)

  • ограничитель limit

  • классификатор mark

  • поля stp

  • vlan

  • …

• Действия-модули (параметры для "-J")

  • arpreply — порождение произвольного ARP-ответа

  • snat/dnat — подмена MAC-адресов

  • mark — маркировка пакета

  • redirect — «тупая» подмена MAC-адреса

Linux arptables

Базовая статья: ARPTABLES manual page

Структура:

• три цепочки: INPUT, OUTPUT, FORWARD
• одна таблица: filter
• фильтры по полям arp (К. О. гарантирует это)

• дополниетльный модуль mangle для подмены адресов

Туннелирование и IPSec

«Определение»: инкапсуляция трафика внутрь специального сетевого протокола

Задачи:

• Организация общего адресного пространства
• Аутентификация и шифрование трафика целиком

Простейшее решение: использовать прикладной уровень:

1. Подключение и авторизация

   • Клиент                                           Сервер
     VPN-клиент ---> eth0: 5.6.7.8 ---> (Интернет) ---> eth0: 1.2.3.4 ---> VPN-сервер

2. Создание виртуальных сетевых tun или tap интерфейсов и настройка их как обычных сетевых карт:

   • Клиент                                           Сервер
     VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер
      |                                                                     |
     tun0: 192.168.10.2                                                    tun0: 192.168.10.1

3. Обмен данными через туннель:

   • VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер
      |                                                                     |
     tun0: 192.168.10.2 <-- (Пакет для 102.168.10.1)                 … <-- tun0: 192.168.10.1

     На всем протяжении пути от 5.6.7.8 до 1.2.3.4 пакет не меняется.
   • TCP over TCP ⇒ использование UDP
   • Паразитная нагрузка (поля транспортного и прикладного уровней)

   • Примеры: vtun, OpenVPN, …

Использовать сетевой уровень ( «IP over IP») :

• Параметры виртуального сетевого интерфейса: собственный IP-адрес и IP-адреса концов туннеля

  • Всякий попавший в tun0 пакет инкапсулируется в IP-пакет (например, протокола GRE) с адресами конца туннеля, а этот пакет маршрутизируется

• Проблемы с NAT вида «много в один»
• Шифрование и аутентификация отсутствуют

Пример: настройка GRE-тоннеля

• На одной стороне:

  # ip a show dev enp0s8
  2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
      link/ether 08:00:27:4c:12:2a brd ff:ff:ff:ff:ff:ff
      inet 10.30.50.3/24 brd 10.30.50.255 scope global enp0s8
      inet6 fe80::a00:27ff:fe4c:122a/64 scope link 
         valid_lft forever preferred_lft forever
  # ip tunnel add tun mode gre remote 10.50.70.3 local 10.30.50.3
  # ip a a 192.168.0.30/24 dev tun
  # ip l set up dev tun 
  [root@uneexclient ~]# ip a show dev tun
  5: tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN 
      link/gre 10.30.50.3 peer 10.50.70.3
      inet 192.168.0.30/24 scope global tun
      inet6 fe80::5efe:a1e:3203/64 scope link 
         valid_lft forever preferred_lft forever

  На другой строне:

  # ip a show dev enp0s8
  2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
      link/ether 08:00:27:d8:46:fd brd ff:ff:ff:ff:ff:ff
      inet 10.50.70.3/24 brd 10.50.70.255 scope global enp0s8
      inet6 fe80::a00:27ff:fed8:46fd/64 scope link 
         valid_lft forever preferred_lft forever
  # ip tunnel add tun mode gre remote 10.30.50.3 local 10.50.70.3
  # ip a a 192.168.0.50/24 dev tun
  # ip a show dev tun
  5: tun: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN 
      link/gre 10.50.70.3 peer 10.30.50.3
      inet 192.168.0.50/24 scope global tun
      inet6 fe80::5efe:a32:4603/64 scope link 
         valid_lft forever preferred_lft forever
  # ping 192.168.0.30
  PING 192.168.0.30 (192.168.0.30) 56(84) bytes of data.
  64 bytes from 192.168.0.30: icmp_req=1 ttl=64 time=1.54 ms
  …
  # traceroute -n 192.168.0.30
  traceroute to 192.168.0.30 (192.168.0.30), 30 hops max, 60 byte packets
   1  192.168.0.30  1.145 ms  1.145 ms  1.195 ms

Виртуальные машины с GRE-туннелем: одна, другая, маршрутизатор (замена интернету) .

IPSec

Базовая статья: An Illustrated Guide to IPsec, смотреть на картинки обязательно.

• Происхождение: IPv6.
• Назначение: «прозрачный» IP с аутентификацией и шифрованием
  • ⇒ универсальность
  • ⇒ задача: аутентификация
  • ⇒ задача: шифрование
  • ⇒ свойство: сохранение (по возможности) исходных IP-полей
• Использование различных алгоритмов шифрования (как стороны договорятся)
• Протокол обмена ключами с множеством вариантов использования

Четыре вида (2×2):

1. Сокрытие трафика:

   • (нет): Authentication Header (AH)

   • (да): Encapsulating Security Payload (ESP)

2. Какой уровень протоколов защищаем:

   • (транспортный): Transport Mode

   • (сетевой): Tunnel Mode

Authentication Header (AH)

Только аутентификация (контрольные суммы), все IP-поля, по возможности, сохраняются

AH + Transport

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета остаются неизменными, кроме:

   • proto=TCP → proto=AH (51)

   • pkt_len=size → pkt_len=size+AH_size

2. Между заголовком и контентом IP-пакета добавляется сам AH (с полем next=TCP)

3. В целях аутентификации вычисляется контрольная сумма всех полей, кроме тех, что меняются по дороге, а также контента (TCP-пакета)

   • ⇒ вычисляется контрольная сумма полей src_IP и dst_IP

AH + Tunnel

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета остаются неизменными, кроме:

   • proto=TCP → proto=AH (51)

   • pkt_len=size → pkt_len=size+AH_size+IP_header_size`

2. Между заголовком и исходным IP-пакетом в неизменном виде вставляется сам AH (с полем next=IP)

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

   • ⇒ вычисляется контрольная сумма полей src_IP и dst_IP как IPSec-пакета, так и туннелируемого IP-пакета

Encapsulating Security Payload (ESP)

Шифрование и (по необходимости) аутентификация.

ESP + Transport

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета остаются неизменными, кроме:

   • proto=TCP → proto=ESP (50)

   • pkt_len=size → pkt_len=new_size

2. Далее следует ESP-секция, содержащая заголовок ESP, исходный TCP-пакет и метаданные TCP-пакета, в которой шифруется всё, кроме заголовка

   • ⇒ шифруются также метаданные, например поле next=TCP

3. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.

ESP + Tunnel

Структура IPSec-пакета (на примере TCP-контента):

1. Поля IP-пакета никого не интересуют, потому что они есть внутри туннелируемого контента; поле proto=ESP (50)

2. Далее следует ESP-секция, содержащая заголовок ESP, исходный IP-пакет и метаданные IP-пакета, в которой шифруется всё, кроме заголовка

   • ⇒ шифруются также метаданные, например поле next=IP

3. Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.

«And the winner is… oops… er… never mind»

Вывод: в жизни можно использовать только ESP и лучше в туннельном виде:

• AH не совместим с NAT вида «много→один»
• ESP+Transport требует настройки IPSec на всех абонентах сети

Ну, и чем это лучше других туннелей?

Виды VPN (первый заход)

• «Old Windows style»: PPP+GRE
• «New Windows style»: ipsec+l2tp
• OpenVPN
• …

МЭ на прикладном уровне, а также что не попало в лекции

Туннеллирование (продолжение)

Протоколы туннелирования: тысячи их

L2TP

Основной RFC — 2661. Базовая статья — Layer_2_Tunneling_Protocol

• Развитие PPTP:
  • Предназначен для туннелирования PPP через «любую» среду передачи данных (UDP, IP, ATM, Frame Relay, …)

    • ⇒ Очень большой

• Разделяются понятия «туннель» и «сеанс внутри туннеля»
• Управляющий протокол создания туннеля и установления сеанса надёжен, а надёжность данных не гарантируется
• Поддерживаются «входящие звонки», «исходящие звонки», простой туннель и даже какой-то «multihop»
• Не имеет механизма аутентификации ⇒ используется пара L2TP + IPSec ESP Transport

Пример простого L2TP-туннеля с помощью iproute2: ip l2tp (без задействования управляющего протокола) Управляющий протокол реализуется специальным демоном (вариантов много)

IPSec

См. предыдущую лекцию.

Ключи и обмен ими

• Аутентификация в IPSec использует HMAC (симметричное шифрование) ⇒ нужен т. н. shared secret.

• IPSec «поддерживает любые механизмы аутентификации» ⇒ сложный протокол IKE для устаноления т. н. security association (SA) (используемого набора механизмов шифрования и аутентификации).

  • Привет и спасибо Диффи и Хеллману

  • pre-shared secrets

  • IPSECKEY DNS

  • KINK

  • …
• Потому (и в процессе) этими ключами надо управлять

OpenVPN

Базовая статья OpenVPN

• Простая клиент-сервернеая структура
• Авторизация по PSK или паролю
• Протокол прост в реализации (см. поддерживаемые архитектуры)
• Наких RFC не написано

• Примеры настройки: простейший, ещё

МЭ на прикладном уровне

Проблема: многообразие протоколов.

Общие задачи:

• Контентная фильтрация/ограничение
  • Антиспам/Антивирус

  • l7filter (дохленький?)

  • …
• Ретрансляция (возможно, с изменением полей прикладного протокола)
  • «Классический» прокси (например, squid)

  • FTP (например, ftp-proxy)

  • TLS и разное жульничество с ним
  • …

Не вошло

• Эффективные сетевые подсистемы (netgraph, netmap про netmap на Хабре, …)

• Взаимодействие с packer processors (для большой загрузки)

• Высокоуровневые МЭ: shorewall

• Проксирование и иная ретрансляция
• Антиспам/антивирус/скоринг контента
• Подсчёт статистики
• …