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

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

Лектор читал первоапредьские новости, они все какие=то мрачные:

• Гвидо уходит в отставку по причине того, что счёл себя морально устаревшим, по поводу чего написал соответствующий PEP
• FreeBSD исключает из портов gcc

Попробуем восст. структуру прошлой лекции. Попробуем разделить предыдущую лекцию на 3—4 части:

• Как оно выглядит
• Как оно работает
• Как этим пользоваться

Как выглядит: речь о чём: есть ядерная составляющая, есть набор утилит, есть набор ручек (/proc/net)

Как оно работает: какие задачи iptables решает, какие есть примитивы (правила, цепочки, таблицы), как проходит пакет

Как используется: какие есть match, targets, как пользоваться iptables.

Обратите внимание вот на какие две важные вещи:

• С одной стороны, iptables это такой же ленточный firewall, как ipfw, в том смысле, что там идут правила подряд, даже перескакивания сводятся к некоему пути
• Те сложности, котрые лектор открывал, когда говорил про погонную структуру в ipfw, они преодоляются тем, что сложный набор правил в iptables это граф.
• Обратно с первой стороны, этот граф не обл. настолько гибкой ст руктурой, как ng
• C другой стороны, это позволяет не запутаться

Тем не менее, возможность делать подцепочку, чтобы вып. в ней опр. виды команд, преврщает iptables мощный инструмент.

В прошлый раз говорилось про разного рода дополнительные модули. Таких расширений довольно много.

Если в случае ipfw видим инструмент, который полностью зачёсан и нижнеуровневый (как именно мы хотим обр. пакеты), то в случае iptables есть возможность, правда такая ("всё можно запрограммировать на С"), запр. модуль, решающий опр. высокоуровневую задачу. Типичный пример такого подхода: ipp2p — это штука, которая позв. на уровне p2p опр., что за трафик оно гоняет, и на основании этого что-то сделать с пакетом. Это типичный пример лобового подхода.

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

То етсь, iptables с точки зрения инструментария как низкоур., так и более высокоур. инструментов.

Теперь лектор немножко продолжит: как лектор понял из того, что было, необх. расск. немного про nat. На самом деле, с точки зрения iptables рассказывть почти нечего.

NAT расш. как Network Address Translation. Идея в следующем: у нас есть пакет, у которого есть src/dst адреса, и по какой-то причине мы не хотим засвечивать один из них. С точки зрения польз. это выглядит банально: у тебя есть ip, при прохожд. пакета адрес твой подменяется, и при прохождении обратно он меняется обратно. Возникает вопрос: по каким параметрам мы понимаем, кому отдать пакет, если у нас много внутренних ip? Ответ очень простой, но слегка теоретический: в пакете, помимо адресов, должны содерж. дополн. данные, которые говорят о том, какому потоку принадл. пакет, мы удем их выковыривать, и на основании этого делать обр. преобразование. Типичный пример: преобр. TCP-трафика. В случае TCP таким идент. явл. адрес транспортного уровня. В случае преобр. внутри TCP-соединения мы можем это сделать. Действительно, эта четвёрка не может совпадать. Что ещё может служить идентификатором? На самом еле, всё, что угодно, лишь бы можно было бы вычленить, к какому потоку данных принадл. пакет. Другой типичный пример — ICMP. У ICMP есть серийный номер, и по нему можно идентифицировать. Например, на запромы traceroute часто не отвечают некоторые хосты. Раз это так, то мы можем, ... . Другой типичный пример: DNS-запросы. Ращумеется, сущ. такие категорие трафиков, которые нельзя пропустить через NAT достаточно простым способом. Например, всякое шифрование, которое учитывает поля пакетов. Например, так делает ipsec в одном из режимов. Произвольный UDP-трафик тоже сложно пропускать.

Другой пример, FTP, тоже сложно проходит, по причине того, что когда уст. управл. соед., а соед. лдя данных уст. от сервера клиенту (клиент передаёт свой ip), и NAT должен проявлять чудеса интеллекта, догадываясь, что пришедший пакет ломится ко внутренней машине.

Проблема в том, что в понятие адреса прикл. уровня у FTP входит IP-адрес. Решение

• Захакать весь пакет, и подменять адрес в пейлоаде прикл. уровня
• Запустить два ftp-сервера, которые будут отвечать в зависимости от того, какой source

Чтобы закончить эту часть: есть ещё одна проблема, проблема конфликта портов: если много абонентов в сети, то вероятность того, что при подмене ip получится два совершенно одинаковых пакета. Поскольку такая проблема есть, то исп. подмена не только адреса, а транспротного адреса: подменяются и ip отправителя и порт отправителя. Но есть такие долбаные (неправильные) сервисы, которые хотят, чтобы подкл. шло с опр. портов, и в противном случае не работают. Особенно самодельные.

Пример: что нужно, чтобы по-быстрому сделать из машины маршрутизатор с натом:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source <внеш. адр.>

Что здесь происх: у нас есть ..., и происх. подмена исх. адреса с попыткой выковырять идент. информацию. Что тут не нравится: мы можем не знать внеш. адрес. Например, если есть dhcp. Поэтому есть действие MASQUERADE:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Тогда каждый раз при необх. будет смотреться ip-адрес интерфейса.

GQ: в чём проблема маскарада: при перезапуске интерфейса сбрасывается таблица conntrack.

DNAT. Как вы думаете, насколько вообще часто встречается ситуация? Она случается, если сервер в локальной сети, а другие машины подкл. к нему по внеш. адресу.

iptables -t nat -A PREROUTING -d <внеш. ip> --dport 21 -i eth1 -j DNAT --to-destination <внт. ip>:21

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

Для ssh:

iptables -t nat -A PREROUTING -d <внеш. ip> --dport 1122 -i eth1 -j DNAT --to-destination <внт. ip>:22

Полезно, если ходят на разные машины внутри сети.

Мы плавно перезжаем от ната к другие св-ва фаерволла. Например, tarpit — позв. сделать очень медленное tcp-соединение. Часто исп. для борьбы со спаммерами. Но это становится замечательной целью для ddos. В этом смысле mirror лучше.

Соверш. отдельная тема, связанная с conntrack: есть netfilter.org. Там лектор нашёл ссылку на один замечательный пакет утилит, conntrack tools/ в чём смысл: если у вас stateful firewall, можно поднять рядом горячую замену ему в случае, если, например, первый отвалился, или для балансировки нагрузки. В чём такая реальная проблема резерва: на резервной машине ничего неизвестно про текущие соединения, только если не синхр. сост. фаерволла и его таблицы. Такая штука есть для bsd, и такая штука есть для linux. Там довольно простая функц. (в BSD круче), но для данных целей (возобновление работоспособности без потери соед.) подходит.

Последняя тема: в ipfw раньше пользовались юзерспейсным natd и divert socket. Лектор ещё сказал, что он пошарил по bsd-софту, и обнаружил, что в divert больше никто и нелазит. Зато туда лазят разные большие утилиты по учёту. Например, так некоторые крутые системы биллинга перенапр. на стр. "заплатите за интернет"

В чём состоит идея nfqueue: вы отпр. пакет в юзерспейс, а дальше он оттуда либо не приезжает, либо приезжает, но модифицированный, и считается, что его обр. закончилась в этой цепочке. Один из вариантов модиф. --- поставить марк. Как выяснилось, один из популярных проектов, l7filter, польз. именно этим. l7f позв. осущ. фильтрацию на прикл. уровне, он умеет распозн. разл. прикл. протоколы. Для чего это делается: для ослов, или торрентов, или ещё чего-нибудь. Ещё можно, в зависимости от того, какой прикл. трафик гоняется, назн. разные приоритеты, разные уровни. Проблема с ослами актуальна, поск. они освоили подмену портов и мимикрирование.

Что он делает: он довольно долго или довольно быстро расп. что за трафик, который идёт, на сайте l7f можно увидеть табличку, какие протоколы с какой вероятностью и скоростью распознаётся, после чего l7f ставит MARK на этот пакет.

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

Как он работает: вы пишите regex, если кусок трафика ему соотв., то считается, что протокол угадан. Когда рафик проходит через этот модуль, он regex применяет, и когда произошёл матчинг, то начинает срабатывать. Это выглядило так:

-m layer7 -ljproto ... -j ...

Ребята пишут, что в 2006 году ни поняли, что, вообще говоря, это опасное дело: может съесться память, может съесться время, поск. некоторые re разб. долго. Довольно быстро люди пришли к выводу, что расп. протоколов прикл. уровня не должно блокировать трафик. в-третьих, для того, чтобы это сделать, нужно делать опасные патчи на iptables, которые очень плохо работают в smp-режиме, поск. они не thread-safe.

На сегодняшний день принято решение отсылать жто в userspace, поск. от него не требуется немедленная реакция.

Помимо того, что это очевидный пример фильтрации на уровне прилож., это пример, зачем действ. нужны us-обработчики, поск. у нас не стоит задача немедленного реагирования, а стоит задача обезопасить kernelspace от перегрузок.

Там есть ссылки на азные проекты, которые это делао используют.

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