UNИX, весна 2009, 06 лекция (от 01 апреля)
Материал из eSyr's wiki.
- Диктофонная запись: http://esyr.org/lections/audio/uneex_2009_summer/uneex_09_04_01.ogg
Лектор читал первоапредьские новости, они все какие=то мрачные:
- Гвидо уходит в отставку по причине того, что счёл себя морально устаревшим, по поводу чего написал соответствующий 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 для линукса, но это не так, хотя там действительно ориентировано на задачу.
Содержание |
[править] Конспект Kda
[править] Вступление
Нужно обратить внимание на две важные вещи. Во-первых, iptables — это такой же ленточный файрвол, в том смысле, что правила идут подряд. Даже если перескакивает с цепочки на цепочку, все подряд. Не обладает такой структурой, как нетграф. Но это позволяет не запутаться и не превратить все в кашу. Эта возможность делать цепочку, чтобы в ней выполнять работы. Второе, о чем хотелось бы заметить. Было немного про дополнительные модули к iptables. Расширений довольно много. Если кому-то приходит в голову ставить фильтрацию, он либо начинает писать расширение, либо модифицирует кусок QoS. Мы описали, что мы хотим делать с пакетами.
В случае iptables есть возможность запрограммировать на си кусок кода, который будет решать задачу.
[править] Фильтрация на прикладном уровне
Сегодня будет про фильтрацию на прикладном уровне. Типичный пример лобового подхода вставки своего модуля решения задачи — ipp2p. Эта штука позволяет на уровне p2p определить, что за трафик внутри этого соединения идет и сделать что-то с пакетами. Таких модулей может быть бесконечно много. Модули зарождаются и умирают по причине потери интереса создателей.
iptables — как низкоуровневый, так и высокоуровневый инструмент.
[править] NAT
Про nat рассказывать особо нечего. Что такое nat? Мы не хотим засвечивать адрес отправителя — типичный пример. Машина служит маршрутизатором во внешний мир и она преобразует адрес во внешний. С точки зрения пользователя это довольно банально. При прохождении через nat адрес превращается в другой. Потом приходит ответ, адрес превращается обратно.
[править] Способ преобразований
Возникает резонный вопрос, каким образом мы делаем преобразования. Есть таблица взаимно однозначного соответствия. Типичный пример преобразования — tcp пакет. Адрес транспортного уровня — ip адреса и порты. В случае преобразования адресов есть такая штука, за которой мы можем признать права. Действительно, четверка не может совпадать, мы не можем организовать два потока с совпадающими четверками. Даже если генерируем http-запросы, порты отправителя будут различаться.
Какому потоку данных принадлежит тот или иной пакет. Есть серийный номер у пакета ICMP. Точно знаем, на каком ICMP запрос пришел ответ, на какой нет.
Еще один пример анализа трафика — DNS-запрос UDP. В запросе есть серийный номер. В запросе есть достаточно информации для распознавания ответа в случае его прихода. Службы UDP отвечают на порт отправителя. В случае DNS порт отправителя всегда 53. Разумеется, существуют такие категории трафика, которые нельзя пропустить через nat. Это секьюрити, шифрование, которое учитывает поля прикладного и транспортного уровня. IPSec в одном из режимов вообще невозможно пропустить через nat. Какой-то унылый UDP-трафик тоже невозможно пропустить.
[править] FTP за NAT
Файрвол должен быть очень умным, чтобы понять, что если снаружи ломятся на один порт, то этот порт был анонсирован FTP-клиентом из внутренней сети. Есть FTP-сервер за NAT. Это небольшая проблема. Сейчас позволяют нормально транслировать. ... Решение 1 — захакать подмену внутрь файрвола и сделать подмену. Проблема в том, что когда пакет будет идти обратно, нужно сделать вторую подмену. Решение 2 — запуск 2 серверов, которые будут отвечать в зависимости от источника — локальная сеть или Интернет.
[править] Неправильные сервисы
Есть такие неправильные сервисы, которые хотят, чтобы у них шло подключение с определенных портов, иначе они не работают. Особенно самодельные, временные и т п. Относительно примеров.
[править] Команды
Что нужно, чтобы сделать из машины маршрутизатор с NAT?
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-route ВН.IP
Что не нравится? Одна вещь — внешний адрес мы можем не знать. У нас, допустим, DHCP-клиент и адрес меняется при каждом старте. Вместо SNAT пишется MASQUERADE. Насколько медленнее — зависит от многих обстоятельств. Файрвол обращается к устройству и смотрит, какой у него IP. Довольно долгая процедура и каждый пакет таким способом.
[править] Destination NAT
Теперь Destination. Насколько часто встречается подмена адреса получателя? Типичный пример — сервер внутри сети с локальным адресом. Первый вариант — проброс портов. Есть http-сервер, и когда происходит подключение, мы его меняем. Сервер лежит внутри сети. По всему Интернету гуляет пакет с получателем-маршрутизатором, а маршрутизатор принимает решение о том, кому он предназначен.
-A PREROUTING -j <EXT IP> -i eth0 --dport 20 -j DNAT --to-destination <INT IP>:20 -- -- --dport 21
При таких сложных штуках, как пробрасывание FTP есть мост в межсетевом экране.
[править] SSH
В SSH есть хорошая поддержка всего безобразия.
[править] Свойства
Переезжаем с NAT на разные свойства. Пришел спамбот, и для ip этого бота ставим проброс в тарпик. Но это может дать уязвимость для DDOS.
[править] Contrack-tools
Есть netfilter.org (?), посвященный текущему состоянию дел в линукс. Там есть ссылка на забавный комплект утилит contrack-tools. В чем смысл? Если у нас файрвол, то мы можем поднять горячую замену файрволу, которая будет включаться в случае, если первый отвалился или балансировать нагрузку. В чем реальная проблема резерва? Одна машина включена, другая выключена. Одна сгорела. Все соединения порвались. Если даже вторая машина включена, все соединения порвутся. Такая штука есть в openbsd.
Машина с горячей заменой в течение секунды без прерывания соединений — это позволяет contrack-tools.
[править] Divert socket
В ipfw не было nat вообще и пользовались userspace-программой и механизмом divert socket.
Лектор пошарил по популярному софту. В divert socket лазают большие системы по учету. Если нужно вернуть пакет, они его возвращают. Внезапно можно перенаправить пользователя на страничку «А ну-ка, заплатите за Интернет».
[править] l7filter
Довольно известный комплект l7filter. Он позволяет осуществлять фильтрацию на прикладном уровне. Есть несколько десятков прикладных протоколов. Что касается фильтрации ослов, это задача актуальная. Приходит пользователь, ставит eDonkey, выкручивает все на максимум.
Ситуация такая, что людей много и они активно действуют, то очень многие люди фильтруют порты и эти пиринговые протоколы освоили технологию port forwarding. Уже непонятно, как фильтровать. Остается только распознавать трафик на прикладном уровне. Можно распознавать типы файлов, например, картинки. Долго для некоторых протоколов распознает, что за трафик там идет. После распознания l7filter ставит метку на пакет. Изначально это был kernel-space модуль. После накатки изменений появлялся интерфейс.
[править] Работа в userspace
Довольно быстро люди пришли к выводу, что распознание протокола прикладного уровня не должно быть связано с блокировкой. Для того, чтобы это сделать, нужны опасные патчи iptables, которые плохо работают в smp-режиме. Ядро линукс очень динамичное и его нужно поддерживать.
Более правильное решение — отсылать в userspace. Не требуется немедленная реакция. Пусть 3 секунды будет ожидание распознания, это не сильно повредит. Довольно эффективный способ.
[править] Nftables
Что еще можно сказать? Две недели назад прошла информация о том, что вышла рабочая версия пакета nftables, который намного круче, чем iptables. У него намного более разумно и структурировано организованы настройки. Это не pf для линукса, поскольку идеология таблиц и цепочек наследуется. Система идет не низкоуровневая, а от задач. Это облегчает работу пользователя.
[править] Хитрые решения
Много хитрых решений. Например: контачимся на один порт, другой, третий, и открывается ssh. Или несколько пингов разной длины. Это уже мелкие извращения.
