UNИX, весна 2009, 09 лекция (от 22 апреля)

Материал из eSyr's wiki.

Версия 17:02, 26 апреля 2009

• Диктофонная запись: http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_04_22.ogg

Фактически, третью лекцию лектор пересказывает pf howto. В книге всё понятно, и её рекоимендуется читать всем, даже если не собир. пользоваться pf.

Поверхностность обманчива: pf устроен так, чтобы облегчить работу пользователю, и если загл. внутрь простого правила в pf, то на самом деле оно раск. в довольно сложный набор, и тенденция в том. Недавно на опеннете была информационка, что отменили scrub (пересборка пакетов). Основная задача scrub — заменить кривые пакеты на опенбсдишные. Отменили потому, что он теперь включен по умолчанию.

Это всё дует в одну и то же дудку: инстр. должен ориент. на польз. задачи, а не плясать вокруг структуры ip-трафика.

Якоря.

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

Отн. того, что это такое, зачем это нужно. Какие они бывают: в прошлый раз лектор говорил, что в якорь можно складывать фильтр. правила и nat/binat/redirect, что в основном чаще всего исп. правила типа filter. Тут мы приходим к ещё одному забавному св-ву: поск. якорю — штука, которую можно менчять по ходу, то если где-то в тексте написано anchor goodguys, то в этом месте происх. нечто среднее между подст. и переходом. Это не макросы, подст. оно в момент выполнения. Соотв., как только модиф. якорь, поведение pf меняется. Как это менять из us:

pfctl -a goodguys -f <filename>

Можно в тексте конфига написать что-то типа

block on $ext_if all
anchor goodguys {
  pass in proto tcp from 10.20.30.40 port 80
}

Якоря могут быть вложенные. Зачем это делать: чтобы не модиф. содерж. одного подъякоря для модиф. другого. Можно например всязть и включить все подъякори якоря бех рек. обхода:

anchor "spam/*"

Когда пишется переход на анкор, то к нему можно приделать фильтр, например:

anchor "spam/*" on $ext_if proto tcp from any to any port 25

И если в этот момент не ижёт трафик, соотв. данному фильтру, то не будет никакой потери произв.

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

Очереди.

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

Все пакеты, которые ходят через tcp/ip стек, нах. в очережи. Прочто очередь имеет самый простой алгоритм, фифо.

Делать планирование звходящих пакетов глупо, поэтому в pf такой возм. нет.

Немного теории. Какие бывают планировщики:

• Самый нерекомендуемый. В pf их два, они дпросто соответст. двум диссертациям, соотв. на эту темы, одна из них — priority queueing, вторая — class-based queueing. В pf class-based тоже имеет свои приоритеты, поэтому первым полз. необяхз. С другой стороны, первый быстрее и более правилно работающий. Приоритезация: о чём вообще речь. Есть пресловутый интерфейс, из которог вылазят пакеты. Вы орг. неск. очередей fifo, в зависимости от того, как учтроен фильтр, пакет попадает в соотв. очередь и по разным правилам отп. Приоритетная орг. очредей постр. очень просто: Вы указ. пропуск. способ. очереди целиком. ... Как это делается в настройках: Идея следу.: вы должны объявить о том

фдей щт ачз0 им 2Ьи йгугу Хыев_щгеб вты_щгеЪ
queue std_out priq(default)
#все пакеты, будущие выходить и з интерф., будут попадать по умолч. в std_out
queue dns_out priority 5 priq

Что озн. более высокий проиритет? Если идёт dns-запрос, то он вылехзет первым, и если другие пакет ждут своей очереди, то они ещё подождут.

Этого мало. Теперь нужно где-то написать:

...
pass out on fvp0 inet prot { udp tcp } from fxp0 to any port domain keep-state queue dns_out

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

Почему лектор про это расск., но не рек. польз. приоритетными очередями? Если вы впихнули в очередь с высоким проир. пост. трафик, то можете сделать всем хуже.

Как этого избежать? Дост. просто, если не будете польз. приор. очередями, а таким способом орг. очередей, когда приоритет наводится не в рамках всего трафика, а в рамках конкур. потоков. То есть если бы была возм. делать дерево, то там вполне можно устр. приоритеты.

Шаманство с приор. это довльно тяжело, поэтому есть CBQ. Там изн. предпю, что траф. разд. на очереди, очереди на подочереди и так далее. Осн. способ манип: манип. проп. способностями, а не приоритетами. Пример:

фдей щт ачз0 сий зц 2Ьи йгугу Хыевб ssh, ftpЪ
queue std bw 50% cbq(default)
queue ssh bw 25% { ssh_loging, ssh_bulk }
queue ssh_login bw 25% priority 4 cbq(ecn)
queue ssh_bulk bw 75% cbq(ecn)
queue ftp bf 500Kb priority 3 cbr(borrow qred) #red делается, если ecn не поддерживается

borrow — то самое, о чём гворили в начале: ftp дали гарант. скорость передачи, и если никто больше не занимет канал, то исп. свободную пропуск. способность.

Таким обр., мы оплучаем дост. неплохое описание очереди, ост. только напистаь что-нибудь типа

pass out on fxp0 from any to any port 22 queue ssh

Что лектору не нравится: непонятно, в какую из подочередей упадёт поток. У pf есть замечательное свойство: можно указ. неск. очередей:

pass out on fxp0 from any to any port 22 queue (ssh_bulk, ssh_login)

Если так пишете, то будет приниматься во внимание ToS и содержимое спец. флагов TCP типа SYN, ACK. ACK и ToS "low delay" будет попадать во вторую очередь, все ост. — в первую.

Всё остальное примерно понятно. Лектор обр. внимание, что это действ. для исх. трафика.

Redirect — в зависимости от того, на какой порт пришли, перенапр. трафик.

Какие есть упражнения:

Пусть есть нат 1 в 1. Как сделать так, чтобы 10.20.30.50 была включена в 123.45.67.__, и блоы бы неплохо, смотря на трафик понимать, что за машина. В простейшем случае, хорошо бы, чтобы последние октеты совпадали. Первое решгкение — сгенерировать 254 правила. Второй сопособ — подменять адрес сети, не трогая адрес компьютера. Когда идёт распр. даресов, можно подст. волшебное слово binat on $ext_if ... from $int_nat to any bitmask

loadbalancing: чтобы это работало, нужно исп. клаузу random. Djj,ot? jyf yt jxtyь хороша, и обычно вместо неё исп. round_robin. Обр. внимание, что эта штука опис., каким обр. происх. подмена адресов.

Есть ещё один крайцне оплезный штук, пусть у вас есть внеш и внутр диапазон адресов, которые разные: 10.0.0.0/8 плохо забитый и два раза по .../24. Как сделать так, чтобы при подмене каждый раз генерился один и тот же ip, чтобы можно было понять какой, посмотрев в таблицу? Какой бонус: если внутри появлися зулиган, то по тому, какой внкш. ip, то область поиска сильно сужается. Что делал лектор: написал хэш-функцию на питоне — по маку генерировал внутр. адрес и однозн. соотв.. Обычно эта задачарешается именно так: не исп. дин. расп. адресов, а выдаёте один в один. В pf есть клауза source-hash, которая так устр., что внеш. адр. выч. из внутр. Если у вас такая ситуация, как на факе: подсеть большая, но компьютеров много, то вер. пересеч. низкая.

Немного про раск. пакетов.

Метка у пакета может быть только одна. Метки в pf текстовые, длина текста — 63 большие лат. буквы и подч. Политика разд. дост. простая — при входе можно пометить пакет, и при выходе можно это обнаружить. Ничего более мутного в pf нет. Метки нестираемые. Они исчезают после покидания кернелспейса.

С другой стороны, помея. пакетов — техн. инстр., и, возм. польз. заджача решается другим способом.

Журнализация.

Есть спец. инт. pflog, в который идёт всё, про что скзаали log, или, если сказали logall, будут идти все пакеты. На этом инт. висит logd, который форм. лог tcpdump, который можно ей посмотреть tcpdump -r.

FTP

Классич. двунапр. соед.. Через fw такие штуки не пролезают по-человечески, хотя в pf есть возм. это сделать.

Если ftp-сервер за fw, то к нему плохо попасть passive.

Есть ещё такая проблема, что внутри пиркл. протокола есть передача ip. Поэтому у ftp-клиентов обычно есть галочка, исп. или не исп. этот адрес. Для противоборства можно сделать split horizon.

Ещё один вариант — использовать специального демона.

Ешё две вещи. Абсолютно прекрасная программа authpf. Что это такое: это такой shell, тоесть польз. логинится, и ему запускается вмест шелла authpf. Он выясняет, с какого ip польз. залогинился, его uid, и в зависимости от этого подкл. анкоры и таблицы небоходимые. Делается это путём доб./уд. в таблице authpfusers, а анкор наз. authpf. Можно взять и вручную задачть анкор authpf.rules, тогда при логине этот анкор будет обн. и добавляться для данного ip в обработку. Что из этого можно сделать: много чего . Например: вы не хотите, чтбы всем и каждому давался доступ к https. Что делать: берёте authpf и пишете простую штуку в authpf-якорь: для всех ip из authpfuser разрешить 443 порт.

Как лектор этим польз.: у лектора в фф стоит такая штука, как antisocial bookmarks. Есть social bookmarks, которые позв. всасывать букмарки. Они всем хороши, кроме одного: лежат они на левом сервере, а хорошо, чтобы на своём. Такое расширение есть, как вариант, можно выкачивать по ftp, но там пароли ходят клиртекстом. Поэтому ....

Есть такая вещь, как CARP, это протокол, расш. она как common address redundancy protocol. Что это такое? Это некая технология, позв. держать неск. идентичных серверов, которые предост. одеу услугу с одинаковвыми адресами на соотв. интерфейсах. Если одна машина сдохла, то начинает работать другая, при этом сохр. все состояния. Орг. это след. обпразом: некотроые спец. штуки внутри ядра и pfsync, а появл. этого протокола возн. в связи с чем: товарищи из cisco вышли на рынок с vrrp (virtual routing redundancy protocol), предост. то же самое, только для роутеров. Проблема в том, что протокол был запатентован. После чего openbsd сказали, что ни всё время сделали, продвинули свой протокол в ietf.

Каждый выпуск openbsd сопровождается музыкой и комиксами. Обычно они довольно злобные. В этот раз у них была описана история bsd.