169
Комментарий:
|
153
|
Удаления помечены так. | Добавления помечены так. |
Строка 2: | Строка 2: |
<<Include(^LecturesCMC/UnixFirewalls2014/[0-9][1-9]|1[0-9],,to="^=* Д/З|$")>> | <<Include(^LecturesCMC/UnixFirewalls2014/[0-9][1-9]|1[0-9],,)>> |
Сводный план лекций «Межсетевые экраны в UNIX»
Общая задача межсетевого экранирования
Цель: избавиться от нежелательного сетевого трафика (в случае МЭ для Unix речь идёт о программной защите)
Задачи: работа с сетевым трафиком:
- Фильтрация
- Ограничение
- Перенаправление
- Преобразование
- Отслеживание
Причины:
- Административные требования
- Расширение логики TCP/IP
Примеры использования МЭ в TCP/IP
(Это далеко не все примеры )
Аппаратный уровень — ?
Интерфейсный уровень — фильтрация MAC и отслеживание подмены/дублей
Сетевой
- Фильтрация по IP, антиспуф
- Ограничение пропускной способности по IP (недостатки), приоритизация
- Policy routing
- NAT «1 — 1»
- Грубый подсчёт сетевой активности
Транспортный
- Фильтрация по порту
- Ограничение пропускной способности TCP и количества TCP-соединений
- «Проброс портов» без модификации пакета, используется редко (почему?)
- NAT «много — 1», «проброс портов»
- Отслеживание активности по портам (например, запредельное количество TCP-соединений)
Прикладной. В основном все задачи должно делать само приложение. Исключения: контент-фильтрация (например, почтовый антивирус, антиспам) и поиск информации для определения «состояния потока данных» (например, для работы DNS по UDP).
Организация «МЭ уровня ядра»
- Поддержка изменяемой логики работы TCP/IP в ядре
- Язык задания этой логики
- Утилиты пространства пользователя для оперативной работы с ядерной составляющей
- Сложность понятия «пакет» в стеке TCP/IP ядра («пакет» какого уровня?)
- Сложность фиксации точки принятия решения (различные пути обработки пакетов)
Три-четыре примера языка описания МЭ
Общий принцип: свод правил МЭ состоит из одиночных записей вида
тест пакета → действие
Заметно влияние Нормальных Алгоритмов Маркова
- «Линейный» (ipfw) воспроизводит работу НАМ: правила в столбик, first wins
- Достоинства: простота, гибкость
- Недостатки: неструктурированность, трудно отследить точку принятия решения, goto
- «Граф» (iptables) представляет собой несколько НАМ-машин («цепочек»), передающих друг другу пакеты, first wins
- Достоинства: большинство типичных задач требуют только дополнения имеющихся цепочек ⇒ очевидный граф
- Недостатки: сложные задачи требуют конструирования новых цепочек и логико «прыжков» из одной в другую ⇒ неочевидный граф
- «Таблица» (pf): правила просматриваются по принципу last wins (т. е применяются все, а потом принимается решение, что делать с пакетом)
- Достоинства: возможность использования сложных атомарных правил и именованных групп правил («якорей»), хеш-таблиц, гарантированное время прохождения пакета
- Недостатки: долгое прохождение пакета через длинные списки правил,
Альтернативный подход (shorewall): компилировать высокоуровневое описание (скажем, структуры сети и абонентских служб) в нечитаемой множество правил.
Работа в FreeBSD и ipfw
Настройки VirtualBox
Внешний интерфейс: «VirtualBox NAT» ⇒ 10.0.2.15/24
- Внутренний интерфейс 10.30.50.1/24
- Доступ по ssh localhost:2212
FreeBSD
Особенности FreeBSD
Базовая дистрибуция + пакеты (пакетный диспетчер pkg)
Установка пакетов в /usr/local (в т. ч. /usr/local/etc, /usr/local/man и т. п.)
Пользователь toor (tcsh в качестве оболочки для root)
- Оболочка: sh или установить bash/zsh
Просмотр сокетов (в т. ч. TCP): sockstat
Достаточно полная и связная система man-страниц; /usr/share/doc и /usr/share/examples
Подсистема запуска служб RC
История развития rc:
/etc/rc → … + /etc/rc.conf→ … + /etc/defaults/rc.conf
… + /etc/rc.d/; service (start, stop, restart, rcvar, onestart и т.п.)
- Зависимости служб,
Включение cлужбы в /etc/rc.conf: служба_enabled="YES"
IPFW
Основная статья: IPFW в FreeBSD handbook (несколько устаревший русский перевод
Архитектура
Список правил вида: действие ← фильтр
полный вид:RULE_NUMBER set SET_NUMBER ACTION log LOG_AMOUNT PROTO from SRC SRC_PORT to DST DST_PORT OPTIONS
например, 420 allow tcp from any to me 80 in via em0 setup
Финальные действия (вида «побеждает первый»): allow, deny и т. п.
Проходные действия: log, count, skipto и т. п.
Последнее правило: 65535 deny ip from any to any (net.inet.ip.fw.default_to_accept="1" ⇒ 65535 allow …)
Утилита ipfw: работа со списком правил
add, delete, swap и т. п.
flush и что будет, если выполнить только ipfw flush
- автоматическая нумерация (шаг 100)
list, show и zero
Запуск: service ipfw и /etc/rc.firewall
- Виды профилей МЭ по умолчанию (open, simple, silent и т. п.)
- Кастомный профиль: имя shell-сценария
Задача удалённого редактирования правил:
- Отредактировать сценарий или настройки
- Перезагрузить ipfw
- В течение тайм-аута ждать подтверждение
- Если подтверждения нет, вернуться к исходному набору правил
Проблемы: невозможность ввода и SIGHUP
Примерная реализация:
- /usr/share/examples/ipfw/change_rules.sh
Д/З
Скачать и заставить работать стендовую виртуальную машину (два файла с именем FW_что-то там).
Поменять на simple значение firewall_type в /etc/rc.conf (МЭ перезапускается с помощью service ipfw restart) . Почему при этом нельзя подключиться к машине по SSH? Как исправить?
Использование IPFW
Базовые статьи FreeBSD Handbook, ipfw, divert, dummynet
Общий вид правила:
[rule_number] [set set_number] [prob match_probability] action [log [logamount number]] [altq queue] [{tag | untag} number] body
action:
- allow, deny, unreach ICMPTYPE, reset; count
- check-state (+первое правило с keep-state/limit)
- skipto#, call# / return
- divert DIVPORT, tee DIVPORT
- fwd IP [PORT]
- pipe#, qeue#
- reass
- setfib#
Прочее: nat#, netgraph COOKIE, ngtee COOKIE (см. netgraph)
body: [proto from src to dst] [options]
proto (/etc/protocols), all
src,dst: any | me | table# | addr(+/mask) addrlist [ports]
ports: port,port-port[ports]
OPTIONS
- bridged layer2
- mac(dst-mac,any src-mac,any) mac-typeTYPE
- icmptypesTYPES
- protoPROTO
- in out
- {recv|xmit|via}IFACE
- ipidLIST iplenLIST ipoptionsSPEC ipprecedencePREC ipsec iptosSPEC ipttlLIST ipversionVER
- frag
- dscpSPECS
- diverted diverted-loopback diverted-output
- dst-ipIP dst-portPORTS src-ipADDRS src-portPORTS
- keep-state limit{src-addr|src-port|dst-addr|dst-port}#
- tcpackACK tcpdatalenLIST tcpflagsSPEC tcpseqSEQ tcpwinLIST tcpoptionsSPEC established (RST|ACK), setup (tcpflags syn,!ack)
- taggedLIST
- gidGID, uidUID
- fib#
- jail#
- lookup {dst-ip|dst-port|src-ip|src-port|uid|jail}#
- verrevpath versrcreach antispoof
LOOKUP TABLES — аналог таблиц маршрутизации (+/MASK), но +порт,jail#,IP и ifacename
SETS OF RULES — 0-31 (неубиваемый), нумерация правил общая, enable/disable/flush, move, swap
STATEFUL FIREWALL
ipfw add check-state ipfw add allow tcp from my-subnet to any setup keep-state ipfw add deny tcp from any to any
Dynamic rules are created when a packet matches a keep-state or limit rule
ipfw -d -e show
DIVERT SOCKET:
DUMMYNET
- pipe, queue, sched
- pipe # config …:
- bw bandwidth|iface
- delay ms-delay
- burst size (если труба была пустая, пускать больше)
- profile filename (сложный профиль)
- buckets hash-table-size
- mask mask-specifier
- noerror
- plr packet-loss-rate
- queue {slots | sizeKbytes}
- red | gred параметры
LOG:
syslog (net.inet.ip.fw.verbose=1)
fconfig ipfw0 create ⇒ …
Д/З
Разбор группы правил из FreeBSD handbook.
Практиковаться можно на виртуальной машине FW
Введение в FreeBSD PF
Daniel Hartmeier (CX, 2001) (ip/ipnat gone)
http://ru.wikipedia.org/wiki/Packet_Filter
ядро + pfctl
Принципы:
- Last wins:
- оптимизация правил и быстрый просмотр (⇒ большие объёмы правил, напр., генераты)
- предсказуемое время
- ⇒ быстрый поиск (таблицы адресов)
- «якоря» (множества правил)
- …
- Команда = задача:
- ⇒ списки и макросы (развёртываются в несколько правил) + таблицы
- комплексные понятия (напр., state: +icmp, обслуживающий соединения; +UDP, NAT, …)
- умолчания (напр., keep state по умолчанию, разные тайминги и т. п.)
- различные формы (напр, адрес-ip ≠ адрес-FQDN, можно и то и то)
- Атомарные задачи: scrub, reassemble, antispoof, OS fp, …
- очереди и шейпинг
Уровень IP и выше.
Порядок правил:
- options
- normalization
- queueing
- translation
- filtering
pfctl
Command Purpose
pfctl -e Enable PF.
pfctl -d Disable PF.
pfctl -F all -f /etc/pf.conf Flush all NAT, filter, state, and table rules and reload /etc/pf.conf.
pfctl -s [ rules | nat state ] Report on the filter rules, NAT rules, or state table.
pfctl -vnf /etc/pf.conf Check /etc/pf.conf for errors, but do not load ruleset. -a anchor
pflog
dev pflog0 + pflogd (=tcpdump)
Пример
# # Firewall for Home or Small Office # http://www.openbsd.org/faq/pf/example1.html # # macros ext_if="em0" int_if="le0" tcp_services="{ 22, 13 }" icmp_types="echoreq" comp3="10.30.50.3" # options set block-policy return set loginterface $ext_if set skip on lo # scrub scrub in # nat/rdr nat on $ext_if inet from !($ext_if) -> ($ext_if:0) rdr on $ext_if proto tcp from any to any port 80 -> $comp3 # filter rules block in pass out antispoof quick for { lo $int_if } pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services pass in on $ext_if inet proto tcp from any to $comp3 port 80 synproxy state pass in inet proto icmp all icmp-type $icmp_types pass quick on $int_if no state
pfsync/CARP
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.html
http://www.freebsd.org/cgi/man.cgi?query=pfctl
Особенности FreeBSD/OpenBSD PF
OpenBSD: отказ от разделения преобразующих (nat, rdr) и фильтрующих (bass, block) команд.
pass out on ext_interface from src_addr to dst_addr nat-to ext_addr или match out on ext_interface from src_addr to dst_addr nat-to ext_addr … pass out on ext_interface from src_addr to dst_addr и pass in on ext_interface other_filters port ext_port rdr-to int_server [int_port]
Синтетическое понятие «состояние» PF
Состояние — это набор информации, необходимый для преобразования/перенаправления/допуска потока данных. См., например, два состояния, сохранённых для ping из внутренней сети.
fw-bsd# pfctl -ss No ALTQ support in kernel ALTQ related functions disabled all tcp 10.0.2.15:22 <- 10.0.2.2:38548 ESTABLISHED:ESTABLISHED all tcp 10.0.2.15:22 <- 10.0.2.2:38559 ESTABLISHED:ESTABLISHED all tcp 10.30.50.1:18550 -> 10.30.50.3:22 ESTABLISHED:ESTABLISHED all tcp 10.30.50.3:80 (10.0.2.15:80) <- 10.0.2.2:35520 FIN_WAIT_2:FIN_WAIT_2 all tcp 10.0.2.2:35520 -> 10.30.50.3:80 FIN_WAIT_2:FIN_WAIT_2 all udp 10.30.50.1:53 <- 10.30.50.3:59363 SINGLE:MULTIPLE all udp 10.0.2.15:55546 -> 192.168.11.1:53 MULTIPLE:SINGLE all icmp 144.76.222.201:3782 <- 10.30.50.3:3782 0:0 all icmp 10.0.2.15:25608 (10.30.50.3:3782) -> 144.76.222.201:25608 0:0
Понятия "modulate sate" и "synproxy state". Назначение SYN proxy.
Списки, макросы и таблицы
Списки: одно правило в pf.conf → N правил
- Макросы: переменные
- Таблицы: логарифмический поиск, модификация из userspace без модификаций правил
Пример поиска по таблице. Обратите внимание на особенность интерпретации записи вида «!адрес»
Заполнение таблицы по параметру overload.
Разбор примера
# Firewall for Home or Small Office # http://www.openbsd.org/faq/pf/example1.html # macros ext_if="em0" int_if="le0" tcp_services="{ 22, 13 }" icmp_types="echoreq" comp3="10.30.50.3" # options set block-policy return set loginterface $ext_if set skip on lo # scrub scrub in # nat/rdr nat on $ext_if inet from !($ext_if) -> ($ext_if:0) rdr on $ext_if proto tcp from any to any port 80 -> $comp3 # filter rules block in pass out antispoof quick for { lo $int_if } pass in on $ext_if inet proto tcp from any to ($ext_if) port $tcp_services pass in on $ext_if inet proto tcp from any to $comp3 port 80 synproxy state pass in inet proto icmp all icmp-type $icmp_types pass quick on $int_if no state
Замечание (на лекции было замято): параметр loginterface определяет, из какого интерфейса пакеты будут перекладываться в pflog0, чтобы их можно было проанализировать pflogd.
Д/З
Поработать со стендом: Образы клиента и сервера:
FW-PFBSD: сервер, доступ по ssh localhost -p2212, доступ на 80-порт http://localhost:8012
FW-client: клиент с единственной сетью (intnet), адрес 10.30.50.3 (можно попасть из консоли virtualbox или ssh с сервера)
Что можно сделать:
Посмотреть правила в /etc/pf.conf
Посмотреть, во что они превращаются: pfctl -sa
- Обратить внимание на якорь (подробнее о якорях — на одной из следующих лекций)
Подключиться к http://localhost:8012 (проброс на сервер → проброс средствами PF на клиент)
Посмотреть таблицу состояний pfctl -ss
Подключиться с клиента куда-нибудь по какому-нибудь протоколу
Посмотреть таблицу состояний pfctl -ss
Linux IPTables
Виды МЭ (условно):
- линейный (ipfw)
- табличный (pf)
- графовый (iptables)
IPTables
Ключевая ссылка IPTables HowTo
Общее устройство https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html (довольно старый перевод):
ядерная часть + утилита управления iptables
- «Пакеты» транспортного и сетевого уровня
Правила обработки пакетов: условие → действие по принципу «кто первый попал»
- Правила объединены в цепочки (действие выглядит как переход в другую цепочку)
- Цепочки бывают разного типа (это называется «цепочка из таблицы»)
- Переход между цепочками по умолчанию:
Естественный граф обработки проходящих пакетов:
- Возврат из пользовательских цепочек
Команды (над цепочками):
- -A, -D, -R №, -I №
- -F, -Z
- -N, -X
Параметры:
- -t Table (по умолчанию — filter)
Действия:
- ACCEPT, DROP, REJECT, RETURN
- SNAT, DNAT, MASQUERADE, NETMAP
- LOG, ULOG
- MARK, CONNMARK
- QUEUE
- …
Условия:
- -s, -d (IP); -i, -o (iface)
- -p протокол, --sport, --dport
- --icmp-type №
-m подмодуль
- mark, connmark
- conntrack, state (TCP)
- helper (прикладной уровень)
- owner (как имя процесса, так и IDs)
- recent
Особенности IPTables
Различие «BSD» и «Linux» подхода к разработке
- «Linux»: upstream → пакет → хранилище → дистрибутив. Все пакеты примерно равноправны и подчиняются дисциплине разработки. Приоритет пакетов выбирается при формировании дистрибутива
- «BSD»: базовый дистрибутив + upstream → пакеты. Больше ответственности за базовый дистрибутив, меньше — за пакеты.
IPTables extensios
Базовая статья: iptables-extensions
Модуль |
Тип |
ah |
ipsec |
esp |
ipsec |
policy |
ipsec |
conntrack |
базовые функции, классификация |
cpu |
балансировка нагрузки |
statistic |
балансировка нагрузки |
addrtype |
классификация |
connmark |
классификация |
devgroup |
классификация |
length |
классификация |
mac |
классификация |
mark |
классификация |
owner |
классификация |
physdev |
классификация |
pkttype |
классификация |
realm |
классификация |
recent |
классификация |
rpfilter |
классификация |
socket |
классификация |
state |
классификация |
string |
классификация |
tcpmss |
классификация |
time |
классификация |
tos |
классификация |
ttl |
классификация |
u32 |
классификация |
unclean |
классификация |
iprange |
классификация, таблицы |
multiport |
классификация, таблицы |
set |
классификация, таблицы, userspace |
connlimit |
ограничение |
hashlimit |
ограничение |
limit |
ограничение |
quota |
ограничение |
dccp |
протоколы |
dscp |
протоколы |
ecn |
протоколы |
icmp |
протоколы |
ipvs |
протоколы |
sctp |
протоколы |
tcp |
протоколы |
udp |
протоколы |
connbytes |
статистика |
rateest |
статистика |
nfacct |
статистика, userspace |
osf |
статистика, userspace |
cluster |
топология сети, балансировка нагрузки |
comment |
удобство |
-j Цель |
Тип |
AUDIT |
userspace |
IDLETIMER |
userspace |
LED |
userspace |
LOG |
userspace |
NFQUEUE |
userspace |
DNAT |
базовые функции |
MASQUERADE |
базовые функции |
NETMAP |
базовые функции |
REDIRECT |
базовые функции |
REJECT |
базовые функции |
SNAT |
базовые функции |
CONNMARK |
классификация |
CONNSECMARK |
классификация |
HMARK |
классификация |
MARK |
классификация |
CT |
настройки |
CLASSIFY |
ограничение, очереди |
CHECKSUM |
протоколы |
DSCP |
протоколы |
ECN |
протоколы |
TCPMSS |
протоколы |
TOS |
протоколы |
TTL |
протоколы |
RATEEST |
статистика |
TRACE |
статистика |
NFLOG |
статистика, userspace |
ULOG |
статистика, userspace |
SET |
таблицы, userspace |
CLUSTERIP |
топология сети |
TEE |
топология сети |
MIRROR |
экспериментальные возможности |
TCPOPTSTRIP |
экспериментальные возможности |
Разбор примера
ALT Linux Centaurus Server 7.0.3 по умолчанию+проброс порта):
[root@srv ~]# iptables-save # Generated by iptables-save v1.4.18 on Fri Apr 4 14:38:01 2014 *mangle :PREROUTING ACCEPT [27:2118] :INPUT ACCEPT [27:2118] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [20:2782] :POSTROUTING ACCEPT [20:2782] COMMIT # Completed on Fri Apr 4 14:38:01 2014 # Generated by iptables-save v1.4.18 on Fri Apr 4 14:38:01 2014 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A PREROUTING -d 10.0.2.15/32 -p tcp -m tcp --dport 2222 -j DNAT --to-destination 192.168.62.2:22 -A OUTPUT -d 10.0.2.15/32 -p tcp -m tcp --dport 2222 -j DNAT --to-destination 192.168.62.2:22 -A POSTROUTING -o enp0s3 -j MASQUERADE COMMIT # Completed on Fri Apr 4 14:38:01 2014 # Generated by iptables-save v1.4.18 on Fri Apr 4 14:38:01 2014 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -f -j DROP -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -j ULOG --ulog-prefix icount --ulog-cprange 48 --ulog-qthreshold 50 -A INPUT -i enp0s3 -p tcp -m tcp --dport 8080 -j ACCEPT -A INPUT -i enp0s3 -p udp -m udp --dport 1194 -j ACCEPT -A INPUT -i enp0s3 -p tcp -m tcp --dport 1194 -j ACCEPT -A INPUT -i enp0s3 -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -i enp0s3 -p udp -m udp --dport 22 -j ACCEPT -A INPUT -i enp0s3 -p icmp -j ACCEPT -A INPUT -i enp0s3 -j DROP -A FORWARD -f -j DROP -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -j ULOG --ulog-prefix fcount --ulog-cprange 48 --ulog-qthreshold 50 -A FORWARD -d 192.168.62.2/32 -p tcp -m tcp --dport 22 -j ACCEPT -A FORWARD -d 10.0.2.0/24 -i enp0s3 -j ACCEPT -A FORWARD -m physdev --physdev-is-bridged -j ACCEPT -A FORWARD -i enp0s3 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i enp0s3 -j DROP -A OUTPUT -f -j DROP -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A OUTPUT -j ULOG --ulog-prefix ocount --ulog-cprange 48 --ulog-qthreshold 50 COMMIT # Completed on Fri Apr 4 14:38:01 2014
Д/З
Пронаблюдать свод правил на Linux-стенде (машина FW-Centaurus). Можно установить самостоятельно (например, отсюда); в настройках машины надо задать два сетевых интерфейса, а при установке выбрать «установку сервера».
- 22 порт → 2204
8080 порт (веб-конфигуратор) → 8084 (точнее, https://localhost:8084 )
- Зайти в веб-конфигуратор, раздел «Внешние сети» и пр. Поменять настройки, посмотреть, что изменилось
Ограничение трафика
Цели:
- Приоритизация потоков
- Честное распределение пропускной способности
- Резервирование канала
- Имитация reallife сети
- …
Задачи:
- Классификация потоков
- Bandwidth: очереди и работа с ними
- Учёт специфики протоколов
Строго говоря, это отдельные задачи.
Замечание: незачем ограничивать уже полученный трафик ⇒ на отправку.
PF
Базовая статья: PF: Packet Queueing and Prioritization
PriQ
- Линейная структура: общая труба → очереди с приоритетами
- Строгая приоритизация (+RR в рамках одного приоритета)
Пример:
Root Queue (2Mbps) Queue A (priority 1) Queue B (priority 2) Queue C (priority 3) Queue D (priority 3)
Области применения: emergency-трафик, обслуживающий трафик на загруженных каналах (например, пустые TCP ACK при скачивании; см. пояснения в конце раздела «Assigning Traffic to a Queue»
CBQ
Иерархические очереди. Аналогия: река с притоками («водная система»)
- BW очереди = ∑ BW подочередей
- borrow
- приоритет (только на случай нехватки родительского BW)
RED и ECN
TCP: саморегуляция путём выбрасывания пакета.
Проблема: переполнение очереди ⇒ рестарт почти всех TCP-соединений
Решение: выбрасывать пакеты заранее: чем полнее очередь, тем больше вероятность потери пакета
Проблема: ограничение трафика путём увеличения трафика?
Протокол ECN
Задание в /etc/pf.conf
Описание очередей:
altq on fxp0 cbq bandwidth 2Mb queue { std, ssh, ftp } queue std bandwidth 50% cbq(default) queue ssh bandwidth 25% { ssh_login, ssh_bulk } queue ssh_login bandwidth 25% priority 4 cbq(ecn) queue ssh_bulk bandwidth 75% cbq(ecn) queue ftp bandwidth 500Kb cbq(borrow red) … pass out on $oif from any to any tcp queue std pass out on $oif from any to any port 22 queue(ssh_bulk, ssh_login) pass out on $oif from any to any port 20 queue ftp
HFSC
Базовая статья: Hierarchical Fair Service Curve (HFSC). Quality of Service for FreeBSD and OpenBSD Иерархические очереди плюс:
- разделение обещанного (realtime) и допустимого (upperlimit) трафика
- задание кривой пропускания (скажем, чем дольше передача, тем ниже BPS)
- без приоритизации вообще
Linux TC (первая попытка)
Базовая статья Linux Advanced Routing & Traffic Control HOWTO
- Разделение МЭ и управления очередями.
- Модульный принцип:
Множество модулей: например, NetEm — аналог DummyNet для BSD; используется на интерфейсном уровне
Дублирование функций (см. tc-htb(8): «HTB is meant as a more understandable and intuitive replacement for the CBQ qdisc in Linux»
Ещё модули (далеко не все!): http://lartc.org/manpages
Ограничение трафика: Linux TC и интерфейсный уровень
ToS
Поле IP-пакета. 4 бита (+3+1резервный) таблица отсюда:
TOS |
Bits |
Means |
Linux Priority |
Band |
0x0 |
0 |
Normal Service |
0 Best Effort |
1 |
0x2 |
1 |
Minimize Monetary Cost |
1 Filler |
2 |
0x4 |
2 |
Maximize Reliability |
0 Best Effort |
1 |
0x6 |
3 |
mmc+mr |
0 Best Effort |
1 |
0x8 |
4 |
Maximize Throughput |
2 Bulk |
2 |
0xa |
5 |
mmc+mt |
2 Bulk |
2 |
0xc |
6 |
mr+mt |
2 Bulk |
2 |
0xe |
7 |
mmc+mr+mt |
2 Bulk |
2 |
0x10 |
8 |
Minimize Delay |
6 Interactive |
0 |
0x12 |
9 |
mmc+md |
6 Interactive |
0 |
0x14 |
10 |
mr+md |
6 Interactive |
0 |
0x16 |
11 |
mmc+mr+md |
6 Interactive |
0 |
0x18 |
12 |
mt+md |
4 Int. Bulk |
1 |
0x1a |
13 |
mmc+mt+md |
4 Int. Bulk |
1 |
0x1c |
14 |
mr+mt+md |
4 Int. Bulk |
1 |
0x1e |
15 |
mmc+mr+mt+md |
4 Int. Bulk |
1 |
|
TC
Базовые статьи:
Userspace + поддержка в ядре + модули.
Отдельная подсистема (≠netfilter).
Работа с очередями пакетов («дисциплина обработки»):
- приоритизация (жесткое упорядочивание)
- переупорядочивание
- ограничение пропускной способности
Термины:
дисциплина — очередь (или иная динамическая структура) пакетов и правила её обработки
класс — поток пакетов; на конце этого потока либо очередь (по умолчанию fifo), либо родительский класс (тогда классы иерархические)
фильтр — сканирование пакетов на предмет записывания их в классы
Бесклассовые очереди
Prioritized FIFO (pfifo_fast)
Чистая приоритизация. Три приоритетных очереди в зависимости от ToS.
Token Bucket Filter (TBF)
Чистое ограничение трафика: очередь пакетов иррегулярная (то густо, то пусто), очередь жетонов равномерно прибывающая; выйти из системы пакет может только получив жетон.
- ⇒ средняя скорость отсылки пакетов не превышает скорость прибытия жетонов
- ⇒ т. н. burst: если очередь пакетов пуста, а очередь из N жетонов полна, и внезапно™ прибывает много пакетов, первые N пакетов отошлются быстрее
Пример:
# tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540
Идея в том, чтобы очередь обрабатывалась со стороны Linux, а не на ADSL-модеме (где очередь может быть очень длинная и в ней потеряются интерактивные пакеты). В идеале неплохо бы использовать приоритетную очередь, но даже так лучше.
Stochastic Fairness Queueing (SFQ)
Чистое переупорядочивание.
Трафик классифицируется по «потокам» (грубо говоря, TCP-соединениям), каждый поток направляется в отдельную FIFO-очередь, а отсылка пакетов происходит по одному из каждой очереди.
Классовые очереди
Классы — потоки пакетов с определёнными свойствами (например, скорость отсылки или пропускная способность). Иерархические подклассы должны соответствовать этим свойствам (например, скорость отсылки или пропускная способность не выше, чем у родительского класса).
Классы и дисциплины (=очереди) в дереве обработки пакетов:
10:1 10:2 12:1 12:2 концевые классы \ / \ / 10: 12: дисциплины | | | 11: | концевой класс | | | 1:10 1:11 1:12 классы \ | / \ | / \ | / \ | / 1:1 класс | 1: корневая дисциплина
Идентификатор очереди всегда заканчивается на «:0» (или, что то же самое, на «:»).
Процесс:
- Постановка пакета в классовую очередь:
- Постановка пакета в корневую очередь
- Классификация пакета
Постановка пакета в очередь уровня k>0
- Классификация пакета
Постановка пакета в очередь уровня l>k
- …
- Отсылка пакета из классовой очереди:
- Прохождение очереди уровня N и передача в очередь уровня N-1
- …
- Прохождение корневой очереди и отсылка пакета
Пример:
1: → 1:1 → 1:12 → 12: → 12:2
12: → 1:
CBQ
Классы на основании времени ожидания отсылки пакета.
Считается малопонятной и устаревшей.
PRIO
Приоритетная классификация по ToS (как в pfifo), но пакеты помещаются в класс, который можно обработать дальше в графе. Класс :1 наиболее приоритетный.
Пример:
полоса 0 1 2 sfq tbf sfq 10: 20: 30: дисциплины | | | 1:1 1:2 1:3 классы \ | / \ | / \|/ 1: корневая дисциплина
Задание с помощью tc:
# tc qdisc add dev eth0 parent 1:1 handle 10: sfq # tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 # tc qdisc add dev eth0 parent 1:3 handle 30: sfq
Hierarchical Token Bucket (HTB)
Классы на основании пропускной способности (по алгоритму TBF).
Пример:
10: 20: 30: sfq-очереди | | | 1:10 1:20 1:30 подклассы 5Mbit 3Mbit 1Kbit \ | / \ | / \ | / 1:1 класс | 1: корневая дисциплина (htb)
Описание классов:
# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k
Задание очередей:
# tc qdisc add dev eth0 root handle 1: htb default 30 # tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 # tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 # tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
Классификация с помощью фильтра u32 (класс 30: по умолчанию) — разброс по 25 и 80 порту.
# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32" # $U32 match ip dport 80 0xffff flowid 1:10 # $U32 match ip sport 25 0xffff flowid 1:20
Примеры экзотических дисциплин
CoDel — пакеты выбрасываются, если и так слишком долго задерживаются в очереди
choke — вариант RED: если очередной пакет заходит за LO-mark и принадлежит тому же потоку данных, что и случайно выбранный из очереди пакет, выбрасыватся оба (⇒ чем толще поток, тем выше вероятность)
drr — (deficit round robin), вариант SFQ с ручным разбиением на потоки (классы)
- …
Фильтры
(Again: работает не на уровне iptables)
Базовая статья: Advanced filters for (re-)classifying packets
- u32 — поля IP (и TCP/UDP)
В примере выше 0xffff — это битовая маска
- fw — пакеты, помеченные iptables
- route — куда направлен пакет
- hfsc — реализация HFSC для linux
- stab — подстановка других размеров пакетов при обработке их очередями
- …
Туннелирование и IPSec
«Определение»: инкапсуляция трафика внутрь специального сетевого протокола
Задачи:
- Организация общего адресного пространства
- Аутентификация и шифрование трафика целиком
Простейшее решение: использовать прикладной уровень:
- Подключение и авторизация
Клиент Сервер VPN-клиент ---> eth0: 5.6.7.8 ---> (Интернет) ---> eth0: 1.2.3.4 ---> VPN-сервер
- Создание виртуальных сетевых tun или tap интерфейсов и настройка их как обычных сетевых карт:
Клиент Сервер VPN-клиент <--> eth0: 5.6.7.8 <--> (Интернет) <--> eth0: 1.2.3.4 <--> VPN-сервер | | tun0: 192.168.10.2 tun0: 192.168.10.1
- Обмен данными через туннель:
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
- Паразитная нагрузка (поля транспортного и прикладного уровней)
Использовать сетевой уровень ( «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):
- Сокрытие трафика:
(нет): Authentication Header (AH)
(да): Encapsulating Security Payload (ESP)
- Какой уровень протоколов защищаем:
(транспортный): Transport Mode
(сетевой): Tunnel Mode
Authentication Header (AH)
Только аутентификация (контрольные суммы), все IP-поля, по возможности, сохраняются
AH + Transport
Структура IPSec-пакета (на примере TCP-контента):
- Поля IP-пакета остаются неизменными, кроме:
proto=TCP → proto=AH (51)
pkt_len=size → pkt_len=size+AH_size
Между заголовком и контентом IP-пакета добавляется сам AH (с полем next=TCP)
В целях аутентификации вычисляется контрольная сумма всех полей, кроме тех, что меняются по дороге, а также контента (TCP-пакета)
⇒ вычисляется контрольная сумма полей src_IP и dst_IP
AH + Tunnel
Структура IPSec-пакета (на примере TCP-контента):
- Поля IP-пакета остаются неизменными, кроме:
proto=TCP → proto=AH (51)
pkt_len=size → pkt_len=size+AH_size+IP_header_size`
Между заголовком и исходным IP-пакетом в неизменном виде вставляется сам AH (с полем next=IP)
В целях аутентификации вычисляется контрольная сумма всех полей, кроме тех, что меняются по дороге, а также контента (IP-пакета)
⇒ вычисляется контрольная сумма полей src_IP и dst_IP как IPSec-пакета, так и туннелируемого IP-пакета
Encapsulating Security Payload (ESP)
Шифрование и (по необходимости) аутентификация.
ESP + Transport
Структура IPSec-пакета (на примере TCP-контента):
- Поля IP-пакета остаются неизменными, кроме:
proto=TCP → proto=ESP (50)
pkt_len=size → pkt_len=new_size
- Далее следует ESP-секция, содержащая заголовок ESP, исходный TCP-пакет и метаданные TCP-пакета, в которой шифруется всё, кроме заголовка
⇒ шифруются также метаданные, например поле next=TCP
Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей ESP-секции.
ESP + Tunnel
Структура IPSec-пакета (на примере TCP-контента):
Поля IP-пакета никого не интересуют, потому что они есть внутри туннелируемого контента; поле proto=ESP (50)
- Далее следует ESP-секция, содержащая заголовок ESP, исходный IP-пакет и метаданные IP-пакета, в которой шифруется всё, кроме заголовка
⇒ шифруются также метаданные, например поле next=IP
Далее может (должна) следовать дополнительная аутентификационная секция, в которой считается контрольная сумма всей 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
- …
- Потому (и в процессе) этими ключами надо управлять
OpenVPN
Базовая статья OpenVPN
- Простая клиент-сервернеая структура
- Авторизация по PSK или паролю
- Протокол прост в реализации (см. поддерживаемые архитектуры)
- Наких RFC не написано
Примеры настройки: простейший, ещё
МЭ на прикладном уровне
Проблема: многообразие протоколов.
Общие задачи:
- Контентная фильтрация/ограничение
- Антиспам/Антивирус
l7filter (дохленький?)
- …
- Ретрансляция (возможно, с изменением полей прикладного протокола)
- «Классический» прокси (например, squid)
FTP (например, ftp-proxy)
- TLS и разное жульничество с ним
- …
Не вошло
Эффективные сетевые подсистемы (netgraph, netmap про netmap на Хабре, …)
- Взаимодействие с packer processors (для большой загрузки)
Высокоуровневые МЭ: shorewall
- Проксирование и иная ретрансляция
- Антиспам/антивирус/скоринг контента
- Подсчёт статистики
- …