СБ, 04 лекция (от 21 марта)

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

---

Текущая версия

Содержание 1 Межсетевые экраны 1.1 Пакетные фильтры 1.2 Прокси прикладного уровня 1.3 Стейтфул мэ 1.4 Пересборка пакетов

[править] Межсетевые экраны

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

Откуда проблема. Есть сеть. Есть 2 абонента, хотят общаться. Есть сервер принимающий подключения. Сеть -- дикий интернет, не про всех абон знаем что они хоршие. Хотим чтобы плохие не могли нами пользоваться, а хоршие могли без особых проблем. Из необх контроля доступа возн тематика мэ. Представ банальную ситуацию Есть вебсервер, хотим чтобы подключаясь через сеть клиенты ничего не сломали. Допустим у нас исс 1.0, мы должны очень аккуратно относится к выбору клиентов.

Чтобы делать? Закрыть порты Закрыть ип-адреса

Первый способ -- на уровне сервиса настроить. Чем плох способ? С точки зрения архитектуры -- фильтрующая сущность в той же системе что и защищаемая -- накладные расходы. Технология появилась в середине 70, комп большие и медленные. Доп функция на том же хосте было неудобно. Вторая причина разнесения функций -- хотелось в то время разделить администрирования фильтр и основной функциональности. Управляют ими люди с разными бэкграундами и целями. Логично фукн фильтрации отделить от собтсвенно функ хоста.

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

Когда мы вып контроль доступа можно это делать на уровне сервиса или на уровне сети. Если делаем на уровне сети -- вопрос -- где именно распол фильтр устройство. До самого посл времени предполгалось что существ точка в сети где есть граница между сеьбю организации и диким интернетом.

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

В практике принято называть эту границу периметром сети. Фв защита планировалсь для функц на периметре сети. Потихоньку оно развивалось, внутри сети мы могли понимать что есть более именее доверенные уровни. Например финанс док должна быть защищена, а общая -- более открыт. Появлялись сегменты и прочие мелкие участки. в перделе доходим до каждого хоста и возвращаемся к тому, что тчка фильтр появл на каждом хосте и приходим к тому что назыв персональные фв.

Когда есть орг и в ней возник задача защиты периметра сети, то как правило выделяют ещ одну область сети, котораяназывается ДМЗ, демилитаризованная зона. Словосч возникло от дем зоны между юкреей и скореей. ДМЗ это то, куда будет ходить дикий интернет и где ндо четче прописывать справила доступа.

Класс способ построения дмз -- в центре спец узел. На одном интерфейсе сидят системы к которым надо предоставлять доступ извне, на других интерфейсах локадьная сеть, и интерф с интернетом. Главная проблема при такой топологии -- нчертили четкую границу между плохими и хорошими. В реальной жизни когда вы столкнётесь с необх решения таких задач на практике, вы выясните что в совр мире граница сильно размылась и почти исчезла. Во-первых, сильно повысилась мобильнос отрудников. Сотрудники мечатют работать из дома, они ездят в командировки,это размытие в одну сторону. Другая проблема -- в любой достаочно большой организации сотрудники норовят принести из дома собств лэптоп, айпад, айфон и подключить их к рабочему лану. Если есть корпор вайфай, то сотрудник обязательно подключит телефон к вайфаю, даже если им это зпретить. потому что с тз сотрудника элементарное удобство безоговорочно побеждает какую-то там безопасность.

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

Тем не менее, если мы говорим про фв, мы подразумеваем некую точку фильтрации, будь она на периметре сеи или на хосте.

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

[править] Пакетные фильтры

Давайте себе представим, что в внешней сети есть клиент, который хочет получать доступ к серверу через наш мэ. Пакетный фильтр это такой программно аппаратный код, который позволяет принять решение(для простоты у нас тцп/ип ), он будет работать на пути следования пакетов и нализировать трафик.

Как происходит тцп хендшейк? На сервер послыается запрос СИН. Сервер посылает ак и син клиент посылает ак. Отслеживают они по sequence numbers. Клиент посылает 0, сервер акает 1 и посылает син с например 100, клиент акает 101. Так же у нас есть серверный порт и клиентский порт. Пусть клиентский 52712ю. Серверные порты известны. Клиентские порты выбираются случайн из диапазона верхних портов.

Пф принимает решение для каждлого пакета в отдельности.

Пришел СИН от клиент1 с порта 52712, оптрав на сервер порт 80. На основании этих сведений он должен принять решение. Да, еще важный момент. В общем случае пф может в этот момент времени посмотреть на весь пакет целиком. На практике однако решени почти всегда принимаетсяна уровне заголовков трансп и сетевого уровня. Тем не менее, на заголовки м псомтреть можем в полном объёме. Пример синтаксиса ipfwadm -l -a accept -S 192.168.100.0/24 -D 0/0 Описан выход из лок сети в интернет.

Допустим что у нас прописано что от клиента поход на порт 80 к серверу мы разрешаем. Пакет пройдет.

Дальше от сервера идет клиенту пакет СИНАК. Нам надо иметь правило, которое разрешает посылку сервера клиенту пакетов на порт 52712.

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

Что можно выкинуть из такого правила? -клиентский порт -син, аки, синаки пример правила TCP, SYN, client, -> server, p:80 Чаще всего писали в духе TCP, *, p:*, -> server, p:80 TCP, server, p:80 -> *, *

Что плохо? Сервер может по любым портам отправлять любой трафик куда угодно с 80 порта. Если наш сервер поломан, то всё печально. Не очень гибко и не очень безопасно. Вторая проблема -- решили что пакет не прошел филтрацию. Чтомы можем с этим пакетом сделать? Если просто дропнуть, он будет пытаться ещё через таймаут. Можем послать клиенту тцп reset, например. DROP -- просто не пускаем и ничего не делаем. REJECT отправить tcp reset в случае тцп или по ицмп если удп. Чем плох дроп? Клиент будет долбиться, мы будем обрабатывать. Чем плох реджект? Мы сообщаем плохому клиенту информации вида "мы знаем что ты есть и тебяне пустим". Более того, когда мы посылаем режект мы его будем посылать таким образом, что ттл будет другое. Несколько лет назад были модны дискуссии по обнаружению фв в сетях по ттл. Представьте себе что я подделываю адрес отправителя и от его имени послыаю пакет. Фв пакет отклонит, но режект пошлёт по адресу клиента, например внутри сети. Это нехорошо, можно организовать какую нибуд дос отаку, или что-нибудь ещё.

Поэтому в современных сетях действует смешанная стратегия. Для внешних соединений -- дроп. Сделано для повышения безопасности и соблюдения общей гигиены в интернете. Внутри сети делать режект.

Какие проблемы у пакетных фильтров понятно. Люди осозновали что с такими едостатками жить не очень удобно, а в случае сложных протоколов, типа фтп и вовсе плохо.

КАк устроен фтп? Там работают два порта. Первый порт 21 и 20. Клиент устанавливает соединение на 21 порт сервера. Это контрол ченел. Когда клиент хочет получить файл по фтп он передаёт серверу команду -- хочу получить файл. И дальше сервер устаналвивает соединение ему на встречу(это сейас про активный фтп). Он устанавливает с порта 20 на произвольный порт клиента. С пф нам надо с 20 порта сервера обеспечить доступ к любому порту любого клиента в интернете. Было можно говорить nmap --source-port 20 и вам часто всё пропускали.

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

[править] Прокси прикладного уровня

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

Во-первых нет прямого тцп-ип соединения, их два. вл=-вторых мэ видит полностью всё соединение.

Чтобы это нормально работало надо для любого сущ в сети протокола реализовать для мэ. Для некоторых протоколов, типа смтп это несложно. для некоторых соединений это сложнее, для ип телефонии например. Доя каких-то и вовсе невозможно. Главный недостаток состоит в следующем -- да мы понимаем все наше приложение целиком, понимаем функционал, можем фильтровать вплоть до конкр действия на уровне протоклоа. Например для фтп можем сказать что вася может загружать файл такой то и не может загружать файл такой-то. А другому пользователю можно и нельзя что-то другое. А на уроне ххтп прокси мы можем например решить, что запрос вида GET /<script>alert(document.cookie))</script> HTTP/1.0 являетя зловредным и это атака, и на сервер даже не пустить.

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

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

Еще в проксей -- зашифрованные каналы на нем расшифровываются. В случаае пакетного фв удобно организовывать атаку по защищенному каналу. В случае проксей -- сервер тогда не обяан уметь шифровать.

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

Пример -- сквид, fwtk, mod_security.

В 21 веке помимо хттп прокси уже фактически не актуально.

Итак мы поняли что счастья нету. На уровне пфов все плохо потому что негибко. На уровне проксей плохо потому что сложно.

К 90 годам появился нвый подход человеком, который потом организовал компанию чекпйнт.

[править] Стейтфул мэ

Как они работают? Наш клиент устанавливает соединение к сереру, прозрачно, наскозь. Посыает син пакет и какой-то сиквенс-намбер. У нас есть порт клиента, адрес киента, порт-адрес сервера, сиквенс намбер. Наш мэ видит ткой пкет и, если такие подсоединения разрешены, запоминает, что такой пакет прошел. В мэ в этом случае работает конечный автомат с таймаутом. Он понимает, что если сервер сейчас захочет ответить клиенту, то сервер может послать только два пакета -- синак, причем с определённым сиквенс намберами и портами. После того как это пакет прошел у фв появилось состояние и он знает, что может прийти потом -- синак или ресет. Если приходят они, то мэ пропустит это назад и будет знать, что ок, в сторону клиента прошел синак с правильными параметрами. У него опять изменяется состояние в стейт машине и он от клиента может ожидать уже опять же прихода пкета ак с соотв сиквенс намбером. Только такой пакет он и пропустит в этом случае. Вся логика тцп соединения внутри мэ, но сдействие происходит просзрачно для клиента и для сервера, в отличие от проксирования. КАК оно работает для удп? если стейт не обеспечивается на уровне сетвом, то вообще-то он может заглядывать внутрь пакета. Еще он может ориентироваться на то, что происходит внутри соединения. например он увидел что соединение на 25 порту. Если там вдруг пойдут не смтп команды, он может догадаться, что что-то тут не так. В отличие от прокси, соединение проходит через него прозрасно, возникает диллема. Увидел он в соединении на 25 порту хттп команды. Он не может послать ошибку уровня протокола. Единственное что он может сделать -- начать дропать эти пакеты или послть режект. Понимание протоколов у стейтфул фв аналогичн проксям, возможность действий у них аналогична пакетным фильтрам.Мы модем смотреть внутрь сессиии но не можем влиять на его содержимое. Хотя на пример фв циски пытается это делать.

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

[править] Пересборка пакетов

В диком интернете пакеты могут ходить разными путями. Последовательность пакетов может меняться. отправили 1 2 3, на фв пришли 1 3 2. Это не проблема для пакетного фильтра. Это не проблема для прокси(за него соберет тцп стэк). Зато это проблема для мэ с анализом состояний. Пришедший пакет вне очереди будет отброшен. И хорошо если просто отброшен, а не режектнут. Поэтому в практической жизни картина со стейт машиной немножко сложнее. Для каждого соединения существуют менее четкий набор правил каких пакетов можно ожидать, с тамаутами. Поэтому в этом случае нам иногда необходимо дождаться большего числа пакетов. Например пришли 1 и 3, мы держим 3 в памяти пока не приходит 2, и дропаем 3 только если 2 не пришел за таймаут. Добиваемся что соединения не будут случ образом развливаться, но возникают большие требования к объему памяти на фв и скорости поиска этих кусочков. На этом может быть основана одна из дос атак на подобные фв -- попытка забить буфер отведенный под эти фрагменты.

Есть ещё одна замечательна атака -- синфлуд. Как правило от синфлуда предполагается можно защищаться мэ. Берем и вливаем вмэ 100 миллионов синов. Под каждый син придется создать контекст, описывающий сессиию. Например дл циска икса контекс составляет 64 байта. 100 000 пакетов имеют способность заббить большой кусок буферной памяти и если сисадмин не озаботился правильной настройкой то дальшеон не будет знать чего делать.

Как броться с синфлудом? домашнее задание.

ЬФТ ШЗЕФИДУЫ желающие прочитают самостоятельно. Там есть модули для реализации стейтов для разных протколов.

Эволюционно подошли к началу 21 века. Возникают новые, совершенно другие проблемы.

Пусть клиент -- windows termial server с десфтком клиентом. Когда онии ходят к нашему серверу, они все ходят с одного ип адреса. Как нам их друг от друга отличить? Второе домашнее задание -- взять hping или scapy и используя их настроив ближайший фв на reject trop и accept и попытаться выполнить соденине. Записать трафик тцпдампом. Или у нас орагизация, дхцп, и каждое утро у них совершенно новый ип адрес. А нам надо органичивать кто куда из клиентов ходит.

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

Для решения первых задач -- нам адо на уровне сети уметь аутентифицировать соединения или ип адреса. Задача прораной аутентификации на уровне сетевого приложения. 1. mac. Мак адрес оень легко подделывается, раз. Большой административнй оверхед -- два(новая техника часто появляется). 2. ipsec. Мы внутри компании развернули нфраструктуру. тут фв надеется на устойчивость конечного узла 3. Auth . когда клиент подключился к сети, он приходит на спец сервис и рассказывает -- вот он я, сегодня я здесь. Это один способ. Второй способ изобрела чекпойнт. На каждом компьютере спец агент, который рассказывает кто есть на этой машине. Если ваша сеть аткова, что вы можете доверять агентам на компьютерах это нормально. Но если у вас на компьютерах у пользователей админ права или они могут приносить ноутбуки, то это не сработает. треттий вариант 802.1х . Связав порт, аутентиф на порту, мак и адрес мы можем судить что кажется этот клиент имеет тот адрес ок отором мы говорим. Если у нас клиент в проуессе имеет возможность имзенить ип или мак, то эта конструкция может работать не очень удачно. Если уровень доверия к кдиентам не очень плохой.

В случае ипсека что мешает терминировать соединения на фв? Строго говоря ничего, в одной нефтяной компании это реализовали. У них большая сеть на несколько стран. У ней несколько сегентов с разныим уровнями секретности. В одном есте они смыкались на супермега фв. Клиент поднимал впн соединение до фв, фв аутентифицировал клиента, понимал кто он именно и разрешал ходить а одно из трех облаков, например в облако с интернетом или в облако с финанс информацией. одновременно подкл к двум было невозможно. Мэ бфл совмещён с впн поэтому понимал какие правила можно распротсранить на клиаента. Да, можно исхитриться таким образом.

Домашнее задание.