Еще раз о том, о чем догворились в прошлый раз. Примерное изложение взгляда на информационное пространство ближайшего семестра.
В прошлый раз остановились на том, что по мере возможности и понимания будет воспроизведен курс 2009 года, который посвящен был инструменту довольно узкому в смысле количества методов работы, но весьма функциональному в смысле количества задач, который мы условно называли фаерволл на уровне ядра. Спецкурс называется межсетевые экраны в UNIX, спецкурс кафедры АСВК.
Что будет? Попробуем определиться, что такое межсетевой экран, он же фаерволл, он же брэндмауэр. У нас есть общая задача "Защита". "Защита" абонентов от сети. Эта задача большая, её надо конкретизировать. Задача большая, вряд ли мы будем защищать от скачков напряжения. Поэтому уточним.
Речь идет о программной защите. Даже на этом уровне это широкое определение, куда вклинивается понятие безопасность, которая наполовину дисциплинарные процедуры, а не инструменты. Видимо, более конкретная
- постановка задачи будет выглядеть такое. У нас есть сеть, которая генерит трафик. Понятие защита мы смотрим в первую очередь, как то, что этот трафик можетбыть нежелательным для нашего абнента. И поскольку сеть представляется как некоторая данность, то задача по недопущению какого-то нежелательного трафика до нашего абонента сети сводится к следующему:
- Фильтрация. Просто чтобы его не было.
- Ограничение, например, по пропускной способности. Совсем не тоже самое, что фильтрация. Во многих случаях предпочтительней полного отрезания.
- Перенаправление. Когда в силу тех или иных причин наша сеть устроена таким образом, что одними только манипуляциями стандартных сетевых протоколов мы не можем обеспечить попадание трафика туда куда надо,
- и непопадание туда, куда не надоо.
- Преобразование трафика. Идея в том, что в том виде, в котором он есть, трафик нежелателен, а в преобразованном -- нормально.
- Отслеживание трафика. Её не надо путать с задачей биллинга или чего-то такого. Возвращаясь к исходной задаче "защиты" -- мы не хотим полностью знать, что там в этом трафике было. Мы вообще не хотим знать
- что в нем было. Мы всего лишь хотим по внещшним признакам определить, желателен он или нет.
Напоминаю, что трафик может быть нежелателен по двум причинам:
- Нам так захотелось. Например, определенного размера пинг нам роняет ОС. Административное ограничение.
- Логика отдельных проотоклов такова, что можно сделать глупости, которые делать не надо. Например, отправлять в сеть пакет, у которого будет написано в адресе 127.0.0.1. Расширение логики проотокола.
Уровень MAC-адресов. Можно отслеживать ситуацию, когда идут некорректные мак-адреса, или слишком много мак-адресов. Отслеживать, что в каком-то сегменте сети творится фигня с мак-адресами, отрубать этот сегмент и ждать администратора.
Или определять, что один компьютер пользуется разными мак-адресами. Или что два компьютера пользуются одним и тем же мак-адресом.
Следующий уровень сетевой. Там полное раздолье с тем, что мы хотим сделать с трафиком. Там полное раздолье с тем, что мы хотим сделать с трафиком. Например, запретить ходить на опеределенные ип-адреса. Вспоминаем также то, что говорилось о расширении логики. Например, запрет приема внешних пакетов с адресом лупбэка или вашим собственным адресом. Перенаправление. Policy routing. NAT -- можно вообразить пример. Например, у вас 10 абонентов и 10 белых адресов, и вы хотите их преобразовывать один в один во внешние. Обратите внимение, что типичный NAT, как и типичное перенаправление пакетов, как правило делается на основании tcp-трафика, а не ip. Хотя можно их вообразить и на сетевом уровне.
Пропустили момент -- журналирование. На уровне интерфейса. Если бы этого не было, мы не могли бы видеть, например, дубликать мак-адресов. На уровне ip журналирование ещё более востребовано, потому что только на основании журнала и его анализа мы могли бы сделать выводы о нездоровой активности того или иного ип-адреса. Но опять так, на транпсортном уровне это граздо более важно.
Выясняется, что несмотря на то, что идентифкация происходит на уровне ip, уже несколько раз лектор оговаривался, что наиболее важная информация извлекается из трафика транпсортного уровня.
На транспортном уровне мы ззнаем несколько проотоклов, то udp до sctp. Почему на транспортном уровне, который, казалось бы, довольно технический, нам часто встречаются важные задачи, которые можно решить только так. Потому что определить нежелательный трафик, как правило, нельзя по одному только ип-адресу. Как правило нежелательный трафик определяется по привязке к порту, или, что бывает реже, по контенту -- а это вообще прикладной уровень.
Само определение нежелательности трафика как правило исходит из анализа протоклов транспортного уровня.
Транспортный уровень.
Трафик-шейпинг. Помимо того, что можно просто фильтровать порт, можно органичивать трафик с конкретного ип-адреса. Допустим у нас открфто 20 тцп-соединений на одного абонента. Чтобы не получилось так, чтобы одно совсем упало. Ограничение пропускной способности потока данных.
Тоже самое относится к перенаправлению -- порт-форвардинг, проброс портов. Просто потому что порт -- это понятие транспортного уровня. Не будем же мы заглядывать в каждый ip пакет и искать в нем порт.
Проброс портов это как раз ситуация, когда надо анализировать трафик транспортного уровня.
NAT. Напоминаю, что эта технология просто так не работает. Когда есть трансляция много в один, вы не можете принять решения о том, кому предназначается ип-пакет без дополнительной информации из тцп-трафика, в котором будут прописаны не только ип-адреса, но и порты. Четверка 2 ип + 2 порта будет однозначно определять, кому трафик и как подменять. Это называется обработка сетевого трафика с сохранением состояния. Идея в том, что вы имеете в памяти сетевого устройства определенный буфер, в котором запоминаете некое состояние, для того чтобы понять к какому из состояний относится полученный пакет. С помощью такого механизма можно делать разные чудеса.
Честно говоря, лектор не знает, насколько разумно преобразование на уровне tcp. Лектор не смог придумать пример.
Что бывает на уровне прикладном? Контент-фильтрация. Если у нас административно задано, что нельзя вирусы пропускать. Вплоть до фильтрации "запрещенного контента", хотя это отдельная песня.
Правда, все равно мы не своодны от того, чтобы признать, что на тысячи прикладных проотоколов существуют тысячи прикладных фаерволлов. Тот же spam assasin занимается именно этой задачей.
Сухой остаток -- нас с вами, возможно, будет интересовать ситуация, когда на основании анализа прикладного трафика мы сможем сделать выводы о состоянии, и не более того.
Если внимательно посмотреть на то. что лектор нарисовал, примерно будет понятен объем и содержимое того, что будет в этом семестре, за исключением одного дополнения и одного замечания.
Есть еще один класс приложений -- intrusion detection. Это такой софт, который довольно плотно сидит на журнале всех уровней, анализирует содержимое этого журнала и определяет, не является ли этот абонент потенциально опасным.
Задача решается та же самая -- защита. Но защищаемся мы не от трафика, мы на основании его принимаем решение о наличии атаки. Это уже защита от атак. А это отдельная большая тема.
Ещё одно замечание. Как мы прекрасно помним из практически всех курсов по сетям, в стеке тцп/ип есть такое понятие, как инкапсуляция.
Что собственно называется пакетом, когда мы фильтруем трафик? Есть у нас запрет на подключение к нашей машине по 80 порту. Или, перенаправлеям пакеты с 80 порта в другое место. В реальности это означает, что мы должны получить пакет, собрать из него фрейм, из фрейма собрать ип-пакет, здесь принять решение о маршрутизации, начать собирать тцп пакет, и только тут понимаем, что мы должны его перенаправить. Тогда мы, в рамках нашей машины, производим какую-то махинацию и спускаем его обратно по этой лестнице, чтобы он поехал на другую машину. Откду на ип уровне нам узнать, какому тцп сеансу принадлежит пакет?
Поэтому, при кажущейся просоте, далеко не всегда понятно, что имеется в виду при запрете пакетов.
Когда мы говорим про фаерволлы уровня ядра, мы постоянно смешиваем трафики различных уровней.
Задача банальной фильтрации может влиять на то, как пакеты будут обрабатываться.
Объектом нашего изучения будет вышеописанное, потому что:
- Инструменты, работающие с ип и тцп познаваемы. В отличие от инструментов работы с езернет и прикладными проотоколоами.
- Большая часть задач делается на этих уровнях.
- Лектор собирается рассказать сразу о трех инструментах, каждый из которых решает задачу слегка по разному.
Как может быть устроено описание того, что мы будем делать с нежелательным трафиком?
Очевидно, надо три вещи:
- Весь процесс обработки сетевого трафика в ядре реализовать таким образом, чтобы была возможность на каждом уровне обработки сетевого трафика посмотреть на пакет, почитать приложенный к пакету паспорт, и на основании этого предпринять какоое-то действие(прибить пресловутое расширение логики).
- Расширение логики на основании некоторых правил, которые закладываются. Свод правил, что делать с пакетом.
- Утилита юзерспейс, которая будет работать с этим самым сводом правил.
Итого, вместо прямой реализации тцп/ип -- реализация с возможностью применения некоторых правил.
И последнее на сегодня -- это о том, как могут быть организованы правила. Это непростая штука, особенно, если учитывать мутность понятия пакета вообще. Тем паче, что делать то мы что-то хотим не с пакетами, а с трафиком.
Первое, что приходит в голову -- написать список правил вида
тест пакета -> действие с пакетом
Как алгоритмы Маркова.
Сработало правило -- разобрались.
Это так называемый "линейный" фаерволл по принципу first wins.
Главный недостаток -- линейность. Есть устройства, там три сети различных классов, для них надо длетаь разные действия. И все эти правила надо взять и написать в один столбик. И следить за тем, чтобы для каждой системы не сработало случайно чужое правило.
Довольно быстро народ приходит к идее сделать в этой линейно таблице оператор go to. С go to назад такая штука становится неписаемой, нечитаемой и неудобоваримой.
Есть три пути выхода из этой ситуации.
- Написать генератор правил более высокого уровня. То, что называется shorewall. Если кажется, что это противоестественно, то могу сказать, что на нашем факультете долго функционировала такая штука, написанная с нуля на перле.
- Организовать не линейный фаерволл, а фаерволл в виде графа. Мы заранее предусмотрим несколько сводов правил, каждое будет известно, в каких случаях применяется. Большинство задач укладываются в пополнения веток графа. Вместо линейного свода получается их несколько. В 80 процентов случаев это сильно облегчает жизнь. Недостаток, что такой граф получается запутанным изначально.
- Вообще переопределение самого смысла фаерволла. "Таблица". Тоже самое, что в первом пункте, но принцип last wins. Хуже -- медленней линейного. Плюсы -- всегда работает так медленно, сколько записей в таблице. Нет необходимости заморачиваться гоуту и несуществующей структурой. Авторы этого фаерволла (pf), говорят, что правильные хеши и возможность работы с большими блоками адресов делают его недостатки незаметными.