Differences between revisions 4 and 5
Revision 4 as of 2008-07-07 22:34:51
Size: 26337
Editor: PavelSutyrin
Comment: m
Revision 5 as of 2008-07-07 22:37:39
Size: 25828
Editor: PavelSutyrin
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
##{02:31:00}
Это тематика позапрошлого дня, когда мы гворили про сеть. Мы потрогали стек протоколов, в том числе, гворили о маршрутизации, и ещё лектор говорил о том, что
Line 3: Line 5:
##{02:31:00}

Это тематика позапрошлого дня, когда мы гворили про сеть. Мы
потрогали стек протоколов, в том числе, гворили о маршрутизации,
и ещё лектор говорил о том, что

Для того, чтобы компьютер был маршрутизатором, нужно выставить
системную переменную, параметр ядра (ip forwarding), чтобы он занимался
перекладыванием пакетов из одной СПД в другую. Надо сказать, что
перекладывание из одного интерфейса в лругой (маршрутизация)
каких-то пакетов --- задача частная, которая в общем случае
выглядит следующим образом: есть задача по перераспределению,
преобразованию и ограничению трафика. То есть, манипулировать
какими-то данными, которые проходят через маршрутизатор
(возможно, они зарождаются в нём, возможно, они ему направлены),
модифицировать этот трафик сообразно нашим нуждам, и, третье,
накладывать ограничения на трафик, начиная просто фильтрацией,
когда мы просто не допускаем какой-то вид сетевой активности,
и заканчивая более тонкими ограничениями, например, на объём
передаваемого траффика (шейпинг), и т.д. Под трафиком имеется в
виду некий обобщенный массив передаваемых по сети данных.
Для того, чтобы компьютер был маршрутизатором, нужно выставить системную переменную, параметр ядра (ip forwarding), чтобы он занимался перекладыванием пакетов из одной СПД в другую. Надо сказать, что перекладывание из одного интерфейса в лругой (маршрутизация) каких-то пакетов задача частная, которая в общем случае выглядит следующим образом: есть задача по перераспределению, преобразованию и ограничению трафика. То есть, манипулировать какими-то данными, которые проходят через маршрутизатор (возможно, они зарождаются в нём, возможно, они ему направлены), модифицировать этот трафик сообразно нашим нуждам, и, третье, накладывать ограничения на трафик, начиная просто фильтрацией, когда мы просто не допускаем какой-то вид сетевой активности, и заканчивая более тонкими ограничениями, например, на объём передаваемого траффика (шейпинг), и т.д. Под трафиком имеется в виду некий обобщенный массив передаваемых по сети данных.
Line 26: Line 8:
Line 30: Line 13:
Обратите внимание, что кое-какие вещи, например, простейшая
маршрутизация, делаются более или менее автоматически. Если
соответствующиq параметр ядра включён и если таблицы
маршрутизации правлиьные, то оно будет работать автоматически,
но нужно понимать, что номенклатурно эта уже функция некоторого
сетевого устройства, которое занимается некоторыми задачами из
приведенного выше списка. То же относительно ограничения. Если
без дополнительных настроек пытаться передать данные
по адресам, которые недоступны в локальной сети, они не
передадутся и фактически будет реализовано некоторое
ограничение трафика. Хотя мы явно его не вводили.
Обратите внимание, что кое-какие вещи, например, простейшая маршрутизация, делаются более или менее автоматически. Если соответствующиq параметр ядра включён и если таблицы маршрутизации правлиьные, то оно будет работать автоматически, но нужно понимать, что номенклатурно эта уже функция некоторого сетевого устройства, которое занимается некоторыми задачами из приведенного выше списка. То же относительно ограничения. Если без дополнительных настроек пытаться передать данные по адресам, которые недоступны в локальной сети, они не передадутся и фактически будет реализовано некоторое ограничение трафика. Хотя мы явно его не вводили.
Line 42: Line 15:
В принципе, межсетевой экран как инструмент --- штука
совокупна
я. Особенно, когда вспоминаем, что в стеке протоколов 4
уровня. По всей видимости, можно вообразить решение всех
этих задач на каждом из этих уровней. Даже на нижнем уровне
пятувровневой схемы (носитель) есть замечательный инструмент
ограничения трафика -- секатор. Представим себе комплекс
задач. Межсетевой экран как таковой это подход от подзадачи.
У нас есть задача обеспечить безопасеность работы в сети, эта
задача решается разными способами, в частности ограничением
или перераспределением или преобразованием траффика,
который в эту сеть поступает, и эти способы могут быть
реализованы различными инструментами. Такой трёхуровневый
подход: задача-решение-инструмент. Обратите внимание, что
межсетевой экран --- это решение, это не задача. Не уточняется,
зачем нужно ограничивать возможности сети передачи данных,
поэтому это не задача. С другой стороны, когда мы гворим, что для
задачи ограничения доступа в сеть. используется межсетевой
экран, мы не гвоорим, каким образом реализуется этот экран.
Конкретный инструмент может быть iptables, iproute2, секатор. То есть,
решение реализуется не одним инструментом. В этом цикле может
быть много задач, много решений и много инструментов. И когда
мы гворим про сетевой экран, мы говорим про решение, которое
восходит от инструмента.
В принципе, межсетевой экран как инструмент — штука совокупная. Особенно, когда вспоминаем, что в стеке протоколов 4 уровня. По всей видимости, можно вообразить решение всех этих задач на каждом из этих уровней. Даже на нижнем уровне пятувровневой схемы (носитель) есть замечательный инструмент ограничения трафика -- секатор. Представим себе комплекс задач. Межсетевой экран как таковой это подход от подзадачи. У нас есть задача обеспечить безопасеность работы в сети, эта задача решается разными способами, в частности ограничением или перераспределением или преобразованием траффика, который в эту сеть поступает, и эти способы могут быть реализованы различными инструментами. Такой трёхуровневый подход: задача-решение-инструмент. Обратите внимание, что межсетевой это решение, это не задача. Не уточняется, зачем нужно ограничивать возможности сети передачи данных, поэтому это не задача. С другой стороны, когда мы гворим, что для задачи ограничения доступа в сеть. используется межсетевой экран, мы не гвоорим, каким образом реализуется этот экран. Конкретный инструмент может быть iptables, iproute2, секатор. То есть, решение реализуется не одним инструментом. В этом цикле может быть много задач, много решений и много инструментов. И когда мы гворим про сетевой экран, мы говорим про решение, которое восходит от инструмента.
Line 66: Line 17:
Это к чему. Нельзя говорить, что, например межстеетвой экран это
iptables. Это неправильно. С другой стороны. нельзя говорить о том,
что сетевой экран --- гарантия безопасности сети. И то и другое --
это никакое ни наблюдение или практический результат работы,
допустим, с iptables. Это результат того, что решение не является
задачей и не является инструментом. Для задачи обеспечения
безопасности далеко не всегда удовлетвояет решение "межсетевой
экран", а сам по себе межсетевой экран совершенно не всегда
явлеятся конкретным инструментом, например iptables. Но мы будем
главным образом разговаривать про iptables. Поясню, почему.
Это к чему. Нельзя говорить, что, например межсетевой экран это iptables. Это неправильно. С другой стороны. нельзя говорить о том, что сетевой экран гарантия безопасности сети. И то и другое это никакое ни наблюдение или практический результат работы, допустим, с iptables. Это результат того, что решение не является задачей и не является инструментом. Для задачи обеспечения безопасности далеко не всегда удовлетвояет решение "межсетевой экран", а сам по себе межсетевой экран совершенно не всегда явлеятся конкретным инструментом, например iptables. Но мы будем главным образом разговаривать про iptables. Поясню, почему.
Line 77: Line 19:
Итак, каждая из трех задач может решаться на каждом из 4 уровней
организации сети. Попробуем представить, на каком из этих
уровней
Итак, каждая из трех задач может решаться на каждом из 4 уровней организации сети. Попробуем представить, на каком из этих уровней
|| || Интерфейсный уровень || Сетевой || Транспортный || Прикладной ||
|| Ограничение || iptables || iptables || iptables, iproute2 || l7-filter, iptables, squid, спам-фильтры, ... ||
|| Перераспределение || iptables || iptables, iproute2 || iptables, iproute2 || ... ||
|| Преобразование || ? || iptables || iptables || iptables, ... ||
Line 81: Line 25:
|| || Интерфейсный уровень || Сетевой || Транспортный || Прикладной ||
|| Ограничение || iptables || iptables || iptables, iproute2 || l7-filter, iptables, squid, спам-фильтры, ... ||
|| Перераспределение || iptables || iptables, iproute2 || iptables, iproute2 || ... ||
|| Преобразование || ? || iptables || iptables || iptables, ... ||

Line 87: Line 29:
Line 89: Line 30:

Ограничение на интерфейсном уровне. Сужение, наверное,
трудно реализовать в разделяемой среде передачи данных, а
ограничение делается сплошь и рядом, например фильтрация по
уникальным идентификаторам сетевых устройств (MAC-адресам в
случае Ethernet-устройств). Это умеет iptables.
Ограничение на интерфейсном уровне. Сужение, наверное, трудно реализовать в разделяемой среде передачи данных, а ограничение делается сплошь и рядом, например фильтрация по уникальным идентификаторам сетевых устройств (MAC-адресам в случае Ethernet-устройств). Это умеет iptables.
Line 97: Line 33:

Распределение тоже можно сделать в iptables. У вас регистрируются
виртуальные сетевые интерфейсы, соответсвующий каждый
соответствующему vlan'у, после чего они, скорее всего, ядерным
модулем... (см. vlanutils) Таким образом, задача распределения на
интерфейсном уровне сводится к той же задаче на сетевом уровне.
Распределение тоже можно сделать в iptables. У вас регистрируются виртуальные сетевые интерфейсы, соответсвующий каждый соответствующему vlan'у, после чего они, скорее всего, ядерным модулем... (см. vlanutils) Таким образом, задача распределения на интерфейсном уровне сводится к той же задаче на сетевом уровне.
Line 105: Line 36:
Преобразование на интерфейсном уровне?.. Нужен некоторый ядерный модуль, который организует соотв. vlan-интерфейс... (неясно, зачем).
Line 106: Line 38:
Преобразование на интерфейсном уровне?.. Нужен некоторый ядерный
модуль, который организует соотв. vlan-интерфейс... (неясно, зачем).

Вопрос общего плана: насколько это вобще востребовано?
Кроме
vlan'ов, которые реально востребовны, но как правило решаются
аппаратно и в линукс-машину их втыкать особенно не надо. Обычно
покупается свитч с поддержкой vlan'а, если он смотрит на другой
свич с поддержкой vlan'а то между ними ходят "крашеные пакеты",
а в другую стороны -- обычные ethernet-фреймы.
Вопрос общего плана: насколько это вобще востребовано? Кроме vlan'ов, которые реально востребовны, но как правило решаются аппаратно и в линукс-машину их втыкать особенно не надо. Обычно покупается свитч с поддержкой vlan'а, если он смотрит на другой свич с поддержкой vlan'а то между ними ходят "крашеные пакеты", а в другую стороны ethernet-фреймы.
Line 119: Line 43:
Line 121: Line 44:
Line 123: Line 45:

По IP-адресам. Нужно часто, используется iptables. Первое, о чём
думают при слове межсетевые экраны. У пакета есть отправитель,
есть получатель, на основе их адресов принимается решение, что
делать с пакетом, в соответствии с некоторой дисциплиной. Мы
видели в альтераторе ICMP, который можно было разрешить (скриншот?)
По IP-адресам. Нужно часто, используется iptables. Первое, о чём думают при слове межсетевые экраны. У пакета есть отправитель, есть получатель, на основе их адресов принимается решение, что делать с пакетом, в соответствии с некоторой дисциплиной. Мы видели в альтераторе ICMP, который можно было разрешить (скриншот?)
Line 131: Line 48:

Распределение на уровне ip нам всегда нужно, это основная задача
на этом уровне. Для этого iptables, iproute2. Нужно создавать некоторое
множество правил, согласно которым управлять пакетами. Если
мы решаем эту задачу нест. образом, то созд. множество правил,
по которым это распр. осуществляется. Для этог есть ipt и ipr2.
Распределение на уровне ip нам всегда нужно, это основная задача на этом уровне. Для этого iptables, iproute2. Нужно создавать некоторое множество правил, согласно которым управлять пакетами. Если мы решаем эту задачу нест. образом, то созд. множество правил, по которым это распр. осуществляется. Для этог есть ipt и ipr2.
Line 139: Line 51:
Начем нужно преобразование IP-адресов. Это все еще непонятная ситуация: как быть, когда адреса в локальной сети имеют диапазон интранетовский, т.е. внутренний, и хотят подключиться к внешнему серверу. Один способ мы уже рассмотрели, это воспользоваться proxy, но это значит в корне изменить ситуацию. Было бы неплохо, чтобы сам пользователь решил, кому и какие пакеты он собирается слать, а не передоверял это дело proxy, к тому же в них cookie плохо работают, в частности в анонимизирующем они не работают.
Line 140: Line 53:
Начем нужно преобразование IP-адресов. Это все еще непонятная
ситуация: как быть, когда адреса в локальной сети имеют диапазон
интранетовский, т.е. внутренний, и хотят подключиться к внешнему
серверу. Один способ мы уже рассмотрели, это воспользоваться
proxy, но это значит в корне изменить ситуацию. Было бы неплохо,
чтобы сам пользователь решил, кому и какие пакеты он собирается
слать, а не передоверял это дело proxy, к тому же в них cookie плохо
работают, в частности в анонимизирующем они не работают.
Прозрачный прокси: когда пользователь заходит на 80 порт на своей машине, а на самом деле он заходит на удалённый сервер, но этого не замечает. Браузер можно не настраивать специально. Есть несколько проблем, если это не требует настроек в браузере, значит и управлять этим прокси по-человечески нельзя, и другие проблемы. С SSL есть серьёзные проблемы, он не работает в принципе.
Line 149: Line 55:
Прозрачный прокси: когда пользователь заходит на 80 порт на своей
машине, а на самом деле он заходит на удалённый сервер, н
о этого
не замечает. Браузер можно не настраивать специально. Есть
несколько про
блем, если это не требует настроек в браузере,
значит и управлять этим прокси по-человечески нельзя, и другие
проблемы. С SSL есть серьёзные проблемы, он не работает в принципе.

Это такой метод, когда машина из внутренней сети отсылает пакет
наружу, каким-то образом запоминается, что это был за пакет,
у этого пакета подменяется ip-адрес и уже с ip-адресом внешним
этот пакет уходит по назначению, и когда на него происходит
ответ, этот ответ, доходя до машины, чей ip-адрес был подставлен
преобразуется обратно по каким-то признакам выявляется, какой
же на самом деле хост из внутренней сети отправил первый пакет,
и ответный пакет возвращается ему. Делается это опять-таки с
помощью iptables,
Это такой метод, когда машина из внутренней сети отсылает пакет наружу, каким-то образом запоминается, что это был за пакет, у этого пакета подменяется ip-адрес и уже с ip-адресом внешним этот пакет уходит по назначению, и когда на него происходит ответ, этот ответ, доходя до машины, чей ip-адрес был подставлен преобразуется обратно по каким-то признакам выявляется, какой же на самом деле хост из внутренней сети отправил первый пакет, и ответный пакет возвращается ему. Делается это опять-таки с помощью iptables,
Line 167: Line 58:
Line 169: Line 59:

По портам, типично. iptables. Ограничение по объёму,
traffic control (tc) входит в iproute2.
По портам, типично. iptables. Ограничение по объёму, traffic control (tc) входит в iproute2.
Line 174: Line 62:
Line 178: Line 65:

NAT, он работает и на транспортном уровне, т.к. задействует такое понятие, как
sequential number, и пр. Этим занимается iptables.
NAT, он работает и на транспортном уровне, т.к. задействует такое понятие, как sequential number, и пр. Этим занимается iptables.
Line 183: Line 68:
==== Ограничение ====
Фильтрация. Мы только что это делали (squid), LOR фильтровали, мы фильтровали исключительно адрес прикладного уровня —. Запретить аську, осла, и т.п. — l7filter для netfilter. Он может, будучи на уровне TCP, выяснить, что за пртокол прикладного уровня по этому TCP-соединеню идёт. Кроме того, эти инструменты аккуратно промеряют тайминги, т.к. за какой срок это происходит. Простейшее взаимодействие с прикладным уровнем есть также и в iptables.
Line 184: Line 71:
==== Ограничение ====

Фильтрация. Мы только что это делали (squid), LOR фильтровали,
мы фильтровали исключительно адрес прикладного уровня --
URL. Запретить аську, осла, и т.п. -- это l7filter для netfilter.
Он может, будучи на уровне TCP, выяснить, что за пртокол прикладного уровня по
этому TCP-соединеню идёт. Кроме того, эти инструменты аккуратно промеряют
тайминги, т.к. за какой срок это происходит. Простейшее
взаимодействие с прикладным уровнем есть также и в iptables.

Антиспам. Анализируется адрес протокола прикладного уровня
SMTP, то есть e-mail, анализируется содержимое прикладного уровня, содержимое письма.
Фактически, фильтрация на этом уровне --- это чаще всего
дело отдельного специального приложения, по крайней мере с
точки зрения linux, да и не linux тоже.
Антиспам. Анализируется адрес протокола прикладного уровня SMTP, то есть e-mail, анализируется содержимое прикладного уровня, содержимое письма. Фактически, фильтрация на этом уровне — это чаще всего дело отдельного специального приложения, по крайней мере с точки зрения linux, да и не linux тоже.
Line 201: Line 74:

Если речь идет о распределении на уровне прикладного протокола, значит,
оно должно быть реализовано в этом самом протоколе. Допустим,
пересылка почты, она реализуется на уровне e-mail адресов, доменов,
и т.д.
Если речь идет о распределении на уровне прикладного протокола, значит, оно должно быть реализовано в этом самом протоколе. Допустим, пересылка почты, она реализуется на уровне e-mail адресов, доменов, и т.д.
Line 208: Line 77:
То же самое --- реализуется отдельным приложением. Хотя, преобразование на прикладном уровне делает также iptables. Connection tracker в нём есть. Когда в прикладном протоколе используется адрес машины-получателя, то нельзя, чтобы туда просочился интранетовский адрес (10.0.0.сколько-то), работать не будет вообще, что FTP, что IRC.
Line 209: Line 79:
То же самое --- реализуется отдельным приложением. Хотя, преобразование на
прикладном уровне делает также iptables. Connection tracker в нём есть. Когда в
прикладном протоколе используется адрес машины-получателя,
то нельзя, чтобы туда просочился интранетовский адрес
(10.0.0.сколько-то), работать не будет вообще, что FTP, что IRC.
И теперь ответьте на вопрос, про какой инструмент стоит теперь поговорить? iptables. На прикладном уровне у нас существенный пробел, именно поэтому есть отдельный скрипт для настройки, отдельно почтовый сервер с возможностью фильтрации. В остальных случаях — iptables.
Line 215: Line 81:
И теперь ответьте на вопрос, про какой инструмент стоит теперь
поговорить? iptables. На прикладном уровне у нас существенный пробел,
именно поэтому есть отдельный скрипт для настройки, отдельно
почтовый сервер с возможностью фильтрации. В остальных случаях
-- iptables.

Да, есть задачи, с которыми гораздо легче справляется или только
это и делает iproute2. Но лектор не готов сейчас рассказывать
про iproute2, это такая мощная внутренностная программа такая
линуксовая, а о возможностях iptables можно рассказать.
Да, есть задачи, с которыми гораздо легче справляется или только это и делает iproute2. Но лектор не готов сейчас рассказывать про iproute2, это такая мощная внутренностная программа такая линуксовая, а о возможностях iptables можно рассказать.
Line 228: Line 85:
Достаточно неплохо введение в эту тему излождено в
Курячем-Маслинском, в соответствующей главе. Идея состоит в
следующем. Тут надо на самом деле... лектор не любит линуксовый
фаерволл, бсдшный намного прямее... Идея в том, что у нас приходят
пакеты и мы их обрабатываем в нескольких цепочках. Сначала мы
обрабатываем пакеты в цепочке правил mangle, для преобразования, потом
в цепочке специального преобразования, nat, подмены
адресов, потом в цепочке, предназначенной для фильтрации, filter.
Достаточно неплохо введение в эту тему излождено в Курячем-Маслинском, в соответствующей главе. Идея состоит в следующем. Тут надо на самом деле... лектор не любит линуксовый фаерволл, бсдшный намного прямее... Идея в том, что у нас приходят пакеты и мы их обрабатываем в нескольких цепочках. Сначала мы обрабатываем пакеты в цепочке правил mangle, для преобразования, потом в цепочке специального преобразования, nat, подмены адресов, потом в цепочке, предназначенной для фильтрации, filter.
Line 237: Line 87:
Когда разрабатывали всю эту систему,
выяснилось, что на самом деле не все пакеты одинаковые в
нашей системе. В зависимочсти от того, кто адресат и получатель
пакета, очень разные решения нужно принимать. Для этого завели
таблицы, состоящие из цепочек. Вы видите (ссылка на учебник?) архитектуру
таблиц по умолчанию, а можно завести сколько угодно и таблиц,
и цепочек, по-моему.
Когда разрабатывали всю эту систему, выяснилось, что на самом деле не все пакеты одинаковые в нашей системе. В зависимочсти от того, кто адресат и получатель пакета, очень разные решения нужно принимать. Для этого завели таблицы, состоящие из цепочек. Вы видите (ссылка на учебник?) архитектуру таблиц по умолчанию, а можно завести сколько угодно и таблиц, и цепочек, по-моему.
Line 245: Line 89:
Идея в следующем: даже по умолчанию есть три типа пакетов: пакеты, которые
предназначены нам, пакеты, который от нас уходят, и пакеты,
которые мы сквозь себя маршрутизируем. Для этого удобно использовать
несколько разных групп правил. Цепочка называется цепочкой, т.к.
это упорядоченный список правил, каждое из который состоит из двух частей.
Левая половинка правила описывает вид пакета, т.е. условие на пакет, а вторая
половинка правила описывает, что с таким пакетом делать.
Идея в следующем: даже по умолчанию есть три типа пакетов: пакеты, которые предназначены нам, пакеты, который от нас уходят, и пакеты, которые мы сквозь себя маршрутизируем. Для этого удобно использовать несколько разных групп правил. Цепочка называется цепочкой, т.к. это упорядоченный список правил, каждое из который состоит из двух частей. Левая половинка правила описывает вид пакета, т.е. условие на пакет, а вторая половинка правила описывает, что с таким пакетом делать.
Line 253: Line 91:
И способ обработки следующий: если левая половинка, т.е. условие,
выполняется, то делается то, что в написано в правой и обработка
текущей цепочки закачивается.
И способ обработки следующий: если левая половинка, т.е. условие, выполняется, то делается то, что в написано в правой и обработка текущей цепочки закачивается.
Line 257: Line 93:
Это называется политика thurst wings /?/
(''Не очень разборчивый и незнакомый термин. Увы %) --PavelSutyrin'')
Это называется политика thurst wings /?/ (''Не очень разборчивый и незнакомый термин. Увы %) --PavelSutyrin'')
Line 260: Line 95:
Таким образом, приходит пакет, мы что-то с ним делаем, пока
в цепочке не найдётся правило, которое подходит ему по типу. И
есть в цепочке правило по умолчанию, что делать с теми пакетами,
к которым не подошло ни одно правило. Например, выбрасывать,
или передавать дальше. Кстати, дальше -- куда?.. На следующую
таблицу, или цепочку. Все строго. Раньше были только цепочки
(ipchains), а теперь таблицы (iptables). Когда пакет проходит через одну
цепочку, тем или иным способом, он проходит в следующую (порядок цепочек задан), и так
далее. Если только он не попал в такое правило, где в качестве
действия указано "выбросить" или "передать в конкретную другую
цепочку".
Таким образом, приходит пакет, мы что-то с ним делаем, пока в цепочке не найдётся правило, которое подходит ему по типу. И есть в цепочке правило по умолчанию, что делать с теми пакетами, к которым не подошло ни одно правило. Например, выбрасывать, или передавать дальше. Кстати, дальше -- куда?.. На следующую таблицу, или цепочку. Все строго. Раньше были только цепочки (ipchains), а теперь таблицы (iptables). Когда пакет проходит через одну цепочку, тем или иным способом, он проходит в следующую (порядок цепочек задан), и так далее. Если только он не попал в такое правило, где в качестве действия указано "выбросить" или "передать в конкретную другую цепочку".
Line 272: Line 97:
Все-таки по таблицам, если ему сказали DNAT, то он попадет
в цепочку NAT, так просто в цепочку NAT он не попадет. Лектор мало
ел. Давайте разберемся. Кто из них кто. Лектор никогда не любил
эту штуку. Цепочки объединены в таблицу.
Все-таки по таблицам, если ему сказали DNAT, то он попадет в цепочку NAT, так просто в цепочку NAT он не попадет. Лектор мало ел. Давайте разберемся. Кто из них кто. Лектор никогда не любил эту штуку. Цепочки объединены в таблицу.
Line 279: Line 101:
ГК: Нет, на линуксе ничего кроме этого безобразия нет. Нельзя, нельзя
читать manual к iptables. Дим, попробуйте объяснить эту картинку.
ГК: Нет, на линуксе ничего кроме этого безобразия нет. Нельзя, нельзя читать manual к iptables. Дим, попробуйте объяснить эту картинку.
Line 282: Line 103:
Дима: Прямоугольнички, которые обозначены большими буквами на
картинке, то есть pre-routing, input, forward, output, post-routing -- это названия
цепочек. А в правом верхнем углу каждого прямоугольничка
указано, в каких таблицах существует такая цепочка. То есть,
когда пакет приходит, он сначала идет в цепочку pre-routing mangle,
потом pre-routing nat, потом смотрится, какое решение о маршрутизации
принимать...
Дима: Прямоугольнички, которые обозначены большими буквами на картинке, то есть pre-routing, input, forward, output, post-routing это названия цепочек. А в правом верхнем углу каждого прямоугольничка указано, в каких таблицах существует такая цепочка. То есть, когда пакет приходит, он сначала идет в цепочку pre-routing mangle, потом pre-routing nat, потом смотрится, какое решение о маршрутизации принимать...
Line 296: Line 111:
Дима: Нет, смотрите. Есть input, есть цепочка input в таблице mangle,
есть цепочка input в таблице filter. Это разные цепочки. Выполняется
сначала одна, потом другая.
Дима: Нет, смотрите. Есть input, есть цепочка input в таблице mangle, есть цепочка input в таблице filter. Это разные цепочки. Выполняется сначала одна, потом другая.
Line 302: Line 115:
?: Прямоугольник --- это не одна цепочка. ?: Прямоугольник это не одна цепочка.
Line 306: Line 119:
Дима: Вот пакет пришел из сети. Он пойдёт вначале в цепочку
pre-routing таблицы mangle, потом он пойдёт в цепочку pre-routing таблицы nat,
потом принимается промежуточное решение о маршрутизации...
Дима: Вот пакет пришел из сети. Он пойдёт вначале в цепочку pre-routing таблицы mangle, потом он пойдёт в цепочку pre-routing таблицы nat, потом принимается промежуточное решение о маршрутизации...
Line 312: Line 123:
Дима: .... это, если я правильно помню, обоснование приблизительно
такое было. Разные типы ... пакетами разрешены в разных
таблицах. Например, сказать слово SNAT, т.е. выполнять...
Дима: .... это, если я правильно помню, обоснование приблизительно такое было. Разные типы ... пакетами разрешены в разных таблицах. Например, сказать слово SNAT, т.е. выполнять...
Line 316: Line 125:
ГК: Все, я понял. Самое смешное, Дим, что они разрешены везде.
У меня получалось это объяснить, когда-то давно...
Давайте сделаем так. На сегодня мы бардак прекратим.
ГК: Все, я понял. Самое смешное, Дим, что они разрешены везде. У меня получалось это объяснить, когда-то давно... Давайте сделаем так. На сегодня мы бардак прекратим.
Line 321: Line 128:
Line 327: Line 133:
|| Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer                       || Start date || End date ||
|| 20              || 1 || 1 || 1 || || 1 || PavelSutyrin, VladimirLysikov    || || ||
|| Готовность (%) || Продолжительность (ак. ч.) || Подготовка (календ. ч.) || Полный текст (раб. д.) || Предварительные знания || Level || Maintainer || Start date || End date ||
|| 20 || 1 || 1 || 1 || || 1 || PavelSutyrin, VladimirLysikov || || ||

Line 330: Line 138:
CategoryLectures CategoryPspo CategoryMpgu CategoryUneex  CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

Межсетевые экраны: теория

Это тематика позапрошлого дня, когда мы гворили про сеть. Мы потрогали стек протоколов, в том числе, гворили о маршрутизации, и ещё лектор говорил о том, что

Для того, чтобы компьютер был маршрутизатором, нужно выставить системную переменную, параметр ядра (ip forwarding), чтобы он занимался перекладыванием пакетов из одной СПД в другую. Надо сказать, что перекладывание из одного интерфейса в лругой (маршрутизация) каких-то пакетов — задача частная, которая в общем случае выглядит следующим образом: есть задача по перераспределению, преобразованию и ограничению трафика. То есть, манипулировать какими-то данными, которые проходят через маршрутизатор (возможно, они зарождаются в нём, возможно, они ему направлены), модифицировать этот трафик сообразно нашим нуждам, и, третье, накладывать ограничения на трафик, начиная просто фильтрацией, когда мы просто не допускаем какой-то вид сетевой активности, и заканчивая более тонкими ограничениями, например, на объём передаваемого траффика (шейпинг), и т.д. Под трафиком имеется в виду некий обобщенный массив передаваемых по сети данных.

Итак:

  • Ограничение (фильтрация и шейпинг)
  • Перераспределение (маршрутизация, перенаправление, балансировка)
  • Преобразование

Обратите внимание, что кое-какие вещи, например, простейшая маршрутизация, делаются более или менее автоматически. Если соответствующиq параметр ядра включён и если таблицы маршрутизации правлиьные, то оно будет работать автоматически, но нужно понимать, что номенклатурно эта уже функция некоторого сетевого устройства, которое занимается некоторыми задачами из приведенного выше списка. То же относительно ограничения. Если без дополнительных настроек пытаться передать данные по адресам, которые недоступны в локальной сети, они не передадутся и фактически будет реализовано некоторое ограничение трафика. Хотя мы явно его не вводили.

В принципе, межсетевой экран как инструмент — штука совокупная. Особенно, когда вспоминаем, что в стеке протоколов 4 уровня. По всей видимости, можно вообразить решение всех этих задач на каждом из этих уровней. Даже на нижнем уровне пятувровневой схемы (носитель) есть замечательный инструмент ограничения трафика -- секатор. Представим себе комплекс задач. Межсетевой экран как таковой это подход от подзадачи. У нас есть задача обеспечить безопасеность работы в сети, эта задача решается разными способами, в частности ограничением или перераспределением или преобразованием траффика, который в эту сеть поступает, и эти способы могут быть реализованы различными инструментами. Такой трёхуровневый подход: задача-решение-инструмент. Обратите внимание, что межсетевой — это решение, это не задача. Не уточняется, зачем нужно ограничивать возможности сети передачи данных, поэтому это не задача. С другой стороны, когда мы гворим, что для задачи ограничения доступа в сеть. используется межсетевой экран, мы не гвоорим, каким образом реализуется этот экран. Конкретный инструмент может быть iptables, iproute2, секатор. То есть, решение реализуется не одним инструментом. В этом цикле может быть много задач, много решений и много инструментов. И когда мы гворим про сетевой экран, мы говорим про решение, которое восходит от инструмента.

Это к чему. Нельзя говорить, что, например межсетевой экран это iptables. Это неправильно. С другой стороны. нельзя говорить о том, что сетевой экран — гарантия безопасности сети. И то и другое — это никакое ни наблюдение или практический результат работы, допустим, с iptables. Это результат того, что решение не является задачей и не является инструментом. Для задачи обеспечения безопасности далеко не всегда удовлетвояет решение "межсетевой экран", а сам по себе межсетевой экран совершенно не всегда явлеятся конкретным инструментом, например iptables. Но мы будем главным образом разговаривать про iptables. Поясню, почему.

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

Интерфейсный уровень

Сетевой

Транспортный

Прикладной

Ограничение

iptables

iptables

iptables, iproute2

l7-filter, iptables, squid, спам-фильтры, ...

Перераспределение

iptables

iptables, iproute2

iptables, iproute2

...

Преобразование

?

iptables

iptables

iptables, ...

Интерфейсный уровень

Ограничение

Ограничение на интерфейсном уровне. Сужение, наверное, трудно реализовать в разделяемой среде передачи данных, а ограничение делается сплошь и рядом, например фильтрация по уникальным идентификаторам сетевых устройств (MAC-адресам в случае Ethernet-устройств). Это умеет iptables.

Перераспределение

Распределение тоже можно сделать в iptables. У вас регистрируются виртуальные сетевые интерфейсы, соответсвующий каждый соответствующему vlan'у, после чего они, скорее всего, ядерным модулем... (см. vlanutils) Таким образом, задача распределения на интерфейсном уровне сводится к той же задаче на сетевом уровне.

Преобразование

Преобразование на интерфейсном уровне?.. Нужен некоторый ядерный модуль, который организует соотв. vlan-интерфейс... (неясно, зачем).

Вопрос общего плана: насколько это вобще востребовано? Кроме vlan'ов, которые реально востребовны, но как правило решаются аппаратно и в линукс-машину их втыкать особенно не надо. Обычно покупается свитч с поддержкой vlan'а, если он смотрит на другой свич с поддержкой vlan'а то между ними ходят "крашеные пакеты", а в другую стороны — ethernet-фреймы.

Есть подозрение, что это не очень востребовано.

Сетевой уровень

Ограничение

По IP-адресам. Нужно часто, используется iptables. Первое, о чём думают при слове межсетевые экраны. У пакета есть отправитель, есть получатель, на основе их адресов принимается решение, что делать с пакетом, в соответствии с некоторой дисциплиной. Мы видели в альтераторе ICMP, который можно было разрешить (скриншот?)

Перераспределение

Распределение на уровне ip нам всегда нужно, это основная задача на этом уровне. Для этого iptables, iproute2. Нужно создавать некоторое множество правил, согласно которым управлять пакетами. Если мы решаем эту задачу нест. образом, то созд. множество правил, по которым это распр. осуществляется. Для этог есть ipt и ipr2.

Преобразование

Начем нужно преобразование IP-адресов. Это все еще непонятная ситуация: как быть, когда адреса в локальной сети имеют диапазон интранетовский, т.е. внутренний, и хотят подключиться к внешнему серверу. Один способ мы уже рассмотрели, это воспользоваться proxy, но это значит в корне изменить ситуацию. Было бы неплохо, чтобы сам пользователь решил, кому и какие пакеты он собирается слать, а не передоверял это дело proxy, к тому же в них cookie плохо работают, в частности в анонимизирующем они не работают.

Прозрачный прокси: когда пользователь заходит на 80 порт на своей машине, а на самом деле он заходит на удалённый сервер, но этого не замечает. Браузер можно не настраивать специально. Есть несколько проблем, если это не требует настроек в браузере, значит и управлять этим прокси по-человечески нельзя, и другие проблемы. С SSL есть серьёзные проблемы, он не работает в принципе.

Это такой метод, когда машина из внутренней сети отсылает пакет наружу, каким-то образом запоминается, что это был за пакет, у этого пакета подменяется ip-адрес и уже с ip-адресом внешним этот пакет уходит по назначению, и когда на него происходит ответ, этот ответ, доходя до машины, чей ip-адрес был подставлен преобразуется обратно по каким-то признакам выявляется, какой же на самом деле хост из внутренней сети отправил первый пакет, и ответный пакет возвращается ему. Делается это опять-таки с помощью iptables,

Траспортный

Ограничение

По портам, типично. iptables. Ограничение по объёму, traffic control (tc) входит в iproute2.

Распределение

Проброс портов (port forwarding), анализирует номер TCP-порта.

Преобразование

NAT, он работает и на транспортном уровне, т.к. задействует такое понятие, как sequential number, и пр. Этим занимается iptables.

Прикладной

Ограничение

Фильтрация. Мы только что это делали (squid), LOR фильтровали, мы фильтровали исключительно адрес прикладного уровня —. Запретить аську, осла, и т.п. — l7filter для netfilter. Он может, будучи на уровне TCP, выяснить, что за пртокол прикладного уровня по этому TCP-соединеню идёт. Кроме того, эти инструменты аккуратно промеряют тайминги, т.к. за какой срок это происходит. Простейшее взаимодействие с прикладным уровнем есть также и в iptables.

Антиспам. Анализируется адрес протокола прикладного уровня SMTP, то есть e-mail, анализируется содержимое прикладного уровня, содержимое письма. Фактически, фильтрация на этом уровне — это чаще всего дело отдельного специального приложения, по крайней мере с точки зрения linux, да и не linux тоже.

Распределение

Если речь идет о распределении на уровне прикладного протокола, значит, оно должно быть реализовано в этом самом протоколе. Допустим, пересылка почты, она реализуется на уровне e-mail адресов, доменов, и т.д.

Преобразование

То же самое --- реализуется отдельным приложением. Хотя, преобразование на прикладном уровне делает также iptables. Connection tracker в нём есть. Когда в прикладном протоколе используется адрес машины-получателя, то нельзя, чтобы туда просочился интранетовский адрес (10.0.0.сколько-то), работать не будет вообще, что FTP, что IRC.

И теперь ответьте на вопрос, про какой инструмент стоит теперь поговорить? iptables. На прикладном уровне у нас существенный пробел, именно поэтому есть отдельный скрипт для настройки, отдельно почтовый сервер с возможностью фильтрации. В остальных случаях — iptables.

Да, есть задачи, с которыми гораздо легче справляется или только это и делает iproute2. Но лектор не готов сейчас рассказывать про iproute2, это такая мощная внутренностная программа такая линуксовая, а о возможностях iptables можно рассказать.

(тема CUPS у нас заморожена, мы только начали тыкать).

Достаточно неплохо введение в эту тему излождено в Курячем-Маслинском, в соответствующей главе. Идея состоит в следующем. Тут надо на самом деле... лектор не любит линуксовый фаерволл, бсдшный намного прямее... Идея в том, что у нас приходят пакеты и мы их обрабатываем в нескольких цепочках. Сначала мы обрабатываем пакеты в цепочке правил mangle, для преобразования, потом в цепочке специального преобразования, nat, подмены адресов, потом в цепочке, предназначенной для фильтрации, filter.

Когда разрабатывали всю эту систему, выяснилось, что на самом деле не все пакеты одинаковые в нашей системе. В зависимочсти от того, кто адресат и получатель пакета, очень разные решения нужно принимать. Для этого завели таблицы, состоящие из цепочек. Вы видите (ссылка на учебник?) архитектуру таблиц по умолчанию, а можно завести сколько угодно и таблиц, и цепочек, по-моему.

Идея в следующем: даже по умолчанию есть три типа пакетов: пакеты, которые предназначены нам, пакеты, который от нас уходят, и пакеты, которые мы сквозь себя маршрутизируем. Для этого удобно использовать несколько разных групп правил. Цепочка называется цепочкой, т.к. это упорядоченный список правил, каждое из который состоит из двух частей. Левая половинка правила описывает вид пакета, т.е. условие на пакет, а вторая половинка правила описывает, что с таким пакетом делать.

И способ обработки следующий: если левая половинка, т.е. условие, выполняется, то делается то, что в написано в правой и обработка текущей цепочки закачивается.

Это называется политика thurst wings /?/ (Не очень разборчивый и незнакомый термин. Увы %) --PavelSutyrin)

Таким образом, приходит пакет, мы что-то с ним делаем, пока в цепочке не найдётся правило, которое подходит ему по типу. И есть в цепочке правило по умолчанию, что делать с теми пакетами, к которым не подошло ни одно правило. Например, выбрасывать, или передавать дальше. Кстати, дальше -- куда?.. На следующую таблицу, или цепочку. Все строго. Раньше были только цепочки (ipchains), а теперь таблицы (iptables). Когда пакет проходит через одну цепочку, тем или иным способом, он проходит в следующую (порядок цепочек задан), и так далее. Если только он не попал в такое правило, где в качестве действия указано "выбросить" или "передать в конкретную другую цепочку".

Все-таки по таблицам, если ему сказали DNAT, то он попадет в цепочку NAT, так просто в цепочку NAT он не попадет. Лектор мало ел. Давайте разберемся. Кто из них кто. Лектор никогда не любил эту штуку. Цепочки объединены в таблицу.

Дима: OUTPUT не одна цепочка, их много разных.

ГК: Нет, на линуксе ничего кроме этого безобразия нет. Нельзя, нельзя читать manual к iptables. Дим, попробуйте объяснить эту картинку.

Дима: Прямоугольнички, которые обозначены большими буквами на картинке, то есть pre-routing, input, forward, output, post-routing — это названия цепочек. А в правом верхнем углу каждого прямоугольничка указано, в каких таблицах существует такая цепочка. То есть, когда пакет приходит, он сначала идет в цепочку pre-routing mangle, потом pre-routing nat, потом смотрится, какое решение о маршрутизации принимать...

ГК: Кто во что объединён, Дим?..

Дима: Цепочки объединены в таблицы.

ГК: Зачем? В данном случае наоборот. Или я чего-то непонял?

Дима: Нет, смотрите. Есть input, есть цепочка input в таблице mangle, есть цепочка input в таблице filter. Это разные цепочки. Выполняется сначала одна, потом другая.

ГК: Нет.

?: Прямоугольник — это не одна цепочка.

ГК: Ну и? Давайте тогда про путь пакета.

Дима: Вот пакет пришел из сети. Он пойдёт вначале в цепочку pre-routing таблицы mangle, потом он пойдёт в цепочку pre-routing таблицы nat, потом принимается промежуточное решение о маршрутизации...

ГК: Тогда объясните мне, почему они во что-то объединены?

Дима: .... это, если я правильно помню, обоснование приблизительно такое было. Разные типы ... пакетами разрешены в разных таблицах. Например, сказать слово SNAT, т.е. выполнять...

ГК: Все, я понял. Самое смешное, Дим, что они разрешены везде. У меня получалось это объяснить, когда-то давно... Давайте сделаем так. На сегодня мы бардак прекратим.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

20

1

1

1

1

PavelSutyrin, VladimirLysikov


PspoClasses/080707/04RoutingTheory (last edited 2008-10-09 18:12:31 by MaximByshevskiKonopko)