Пакетный фильтр iptables в ОС Linux
Ядро ОС Linux имеет встроенные возможности фильтрации пакетов, а утилита, облегчающая процесс настройки, называется iptables (ядра версий 2.4.x). Структура пакетного фильтра iptables изображена на рисунке:
Цепочка фильтрации - это список правил. Вот функции цепочек фильтрации:
o цепочка InPUT занимается фильтрацией пакетов, адресованных данному узлу
o цепочка OUTPUT занимается фильтрацией пакетов, сгенерированных данным узлом
o цепочка FORWARD занимается фильтрацией пакетов, проходящих транзитом.
Более подробно схема работы цепочек фильтрации при прохождении транзитного трафика приведена на следующем рисунке:
Кроме этого, имеются модули трансляции адресов. До маршрутизации срабатывает цепочка PREROUTInG, а после маршрутизации - POSTROUTInG. В этих цепочках, кроме обычных правил фильтрации, могут присутствовать правила трансляции адресов.
Краткое описание каждой цепочки приведено в таблице:
Достоинства и недостатки пакетных фильтров
Достоинства пакетных фильтров:
o Низкая стоимость
o Прозрачность для приложений
o Небольшая задержка прохождения пакетов
Недостатки пакетных фильтров:
o «Открытость» (маршрутизируемое^) внутренней сети
o Сложность конфигурирования правил фильтрации
o Отсутствие дополнительных механизмов защиты (аутентификация и т. д.)
o «Статичность», отсутствие контроля соединения
Иллюстрация статичности пакетных фильтров
|
|
|
Статичность означает, что пакетный фильтр манипулирует отдельными пакетами, не учитывая при этом принадлежности пакета к какому-либо соединению, ни, тем более, сопоставляя данные нескольких (взаимосвязанных между собой) соединений.
Следующий пример, иллюстрирует этот основной недостаток пакетных фильтров. Если правила разрешают обращение по протоколу UDP из внутренней сети, то для нарушителя достаточно задать «правильный» порт источника, чтобы подключиться на порты 1024 и выше.
С протоколом TCP ситуация в целом лучше, чем с UDP, но проблема остаётся. Например, правила в следующей таблице обеспечивают возможность отправки почты с помощью внешнего SMTP-сервера.
При этом соединения разрешены только изнутри, но прохождение ответов с 25-го порта (с любого внешнего узла) разрешено, даже если не было запроса. Таким образом, нарушитель может посылать большое количество ответов, создавая тем самым ситуацию бесполезного расходования вычислительных ресурсов.
Практическая реализация этой идеи - троянец, клиентская часть которого подключается к серверной, используя только АСК-пакеты (http://www.ntsecurity.nu/toolbox/ackcmd/). Поскольку пакетный фильтр блокирует подключения к узлу, основываясь только на наличии флага SYN в заголовке, АСК-пакеты будут пропускаться.
|
|
|
Шлюзы уровня соединения
Посредник - это узел, выполняющий запрос на установление соединения по инициативе другого узла. Посредник уровня соединения (circuit-level proxy) - это посредник, статически определяющий, какой трафик должен быть перенаправлен. Он просто
копирует данные между участниками соединения, работая на сеансовом уровне сетевой модели.
Когда клиент (из внутренней сети) запрашивает соединение с сервером (из внешней сети), шлюз принимает запрос и проверяет его на соответствие критериям фильтрации. После того, как шлюз проверил допустимость данного сеанса, он устанавливает соединение.
Начиная с этого момента шлюз просто ретранслирует пакеты в обе стороны, контролируя процесс обмена данными между клиентом и сервером. При этом на шлюзе должна поддерживаться таблица установленных соединений.
Для шлюзов уровня соединения, как правило, требуется установка на клиенте специального программного обеспечения, но это не всегда так. Главная особенность посредников уровня соединения - статичность, т. е. они устанавливают соединение, основываясь исключительно на правилах политики безопасности, а не на особенностях конкретной службы. Например, если правила фильтрации разрешают ftp-соединение, то такой посредник всегда будет ретранслировать трафик на порт 20 (ftp-data), даже если отсутствует управляющее соединение (порт 21, ftp-control).
|
|
|
Шлюз уровня соединения является более универсальным, чем шлюз прикладного уровня, поскольку не учитывает особенностей конкретных служб (TELNET, FTP и пр.).
Примерами шлюзов уровня соединения могут служить узлы, использующие протокол SOCKS и узлы, осуществляющие трансляцию адресов (NAT).
Шлюзы прикладного уровня
Шлюзы прикладного уровня (application-level proxy), часто называемые ргоху-серверами, контролируют и фильтруют информацию на прикладном уровне модели OSI. Они различаются по поддерживаемым протоколам прикладного уровня. Наиболее часто
поддерживаются службы Web (HTTP), FTP, SMTP, POP3/IMAP, NNTP, Gopher, Telnet, DNS, RealAudio/RealVideo.
Когда клиент внутренней сети обращается, например, к серверу Web, то его запрос попадает к посреднику Web (или перехватывается им). Последний устанавливает связь с сервером от имени клиента, а полученную информацию передает клиенту.
Для внешнего сервера посредник выступает в качестве клиента HTTP, а для внутреннего клиента — в качестве сервера HTTP. Аналогично посредник может работать и в случае внешнего клиента и внутреннего сервера.
|
|
|
Работа посредников прикладного уровня основана на типе протокола прикладного уровня, в отличие от шлюзов уровня соединения, базирующихся на номерах портов.Кроме того, установление соединения является здесь обязательным требованием.
Яркий пример посредника прикладного уровня — широко известный SQUID.
Главная особенность шлюзов прикладного уровня — способность просматривать содержимое сетевых пакетов. В частности, можно отфильтровывать отдельные виды команд или ответов для всех служб прикладного уровня.
Достоинства шлюза прикладного уровня:
o Высокая степень контроля соединений за счет проверки содержимого пакетов
o Усиленная аутентификация
o Гибкость правил фильтрации (критериями могут выступать имя пользователя, разрешённые часы работы и т. д.)
Недостатки:
o Высокая стоимость
o Отсутствие прозрачности для пользователей
o Высокие системные требования к узлу
o Замедление работы
Итак, предлагаемый вариант классификации МЭ содержит три различных типа МЭ. Как уже упоминалось, чаще всего все три типа реализованы в одном МЭ. Существуют и отдельные реализации для каждого типа.
Stateful inspection
Выше рассматривались пакетные фильтры и было показано, что недостаточно только лишь просматривать отдельные пакеты. Информация о состоянии, извлеченная из имевших место ранее соединений и других приложений, используется для принятии окончательного решения о текущей попытке установления соединения. В зависимости от типа проверяемого пакета, для принятия решения важными могут быть как текущее состояние соединения, которому он принадлежит (полученное из его истории), так и состояние приложения, его использующего.
Таким образом, для обеспечения наивысшего уровня безопасности, МЭ должен уметь считывать, анализировать и использовать следующую информацию:
o Информацию о соединении - информацию со всех уровней модели.
o Состояние соединения - состояние, полученное из предыдущих пакетов.Например, исходящая команда PORT сессии FTP могла бы быть запомнена для последующей проверки встречного входящего соединения FTP data.
o Состояние приложения - информация о состоянии, полученная из другихприложений. Например, когда-либо авторизованному пользователю был разрешен доступ через firewall только для разрешенных типов сетевых протоколов.
Кроме того, МЭ должен уметь выполнять действия над передаваемой информацией в зависимости от всех вышеизложенных факторов.
Stateful Inspection - технология нового поколения, удовлетворяет всем требованиям к безопасности, приведенным выше.
Технология инспекции пакетов с учетом состояния протокола на сегодня является наиболее передовым методом контроля трафика (она разработана и запатентована компанией Check Point Software Technologies).
Эта технология позволяет контролировать данные вплоть до уровня приложения, не требуя при этом отдельного процесса-посредника (proxy) для каждого защищаемого протокола или сетевой службы. В результате достигаются высокие показатели производительности, высокая гибкость решений и возможность быстро и достаточно просто адаптировать систему под новые нужды.
Основываясь на технологии инспекции пакетов с учетом состояния протокола, МЭ обеспечивает наивысший уровень безопасности. Метод stateful inspection обеспечивает сбор информации из пакетов данных, как коммуникационного, так и прикладного уровня, что достигается сохранением и накоплением ее в специальных контекстных таблицах, которые динамически обновляются. Такой подход обеспечивает максимально возможный уровень безопасности, контролируя соединения на уровнях от 3 до 7 сетевой модели OSI, тогда как proxy посредники могут контролировать соединения только на 5 - 7 уровнях.
Обработка нового соединения при этом осуществляется следующим образом:
После того как соединение занесено в таблицу, обработка последующих пакетов этого соединения происходит на основе анализа таблиц.
Метод stateful inspection обеспечивает контроль не только на уровне соединения, но и на прикладном уровне.
Варианты расположения МЭ
Вопрос размещения МЭ в корпоративной сети рассматривается с учетом конкретных особенностей уже имеющихся средств защиты, целей подключения и т. д. Однако можно выделить несколько общих схем, приемлемых для большинства конфигураций.
Простейшая схема подключения 1 приведена на Рис. 4.23.2 Внутренняя сеть отделена от внешней маршрутизатором с фильтрацией пакетов. Разумеется, этого недостаточно для организации полноценной защиты.
В схеме 2 (Рис. 4.23.3) дополнительно используется МЭ 2-го или 3-го типа (посредник) или 4-го типа (Stateful Inspection). Это, вероятно, одна из самых популярных схем подключения МЭ.
Область сети между пакетным фильтром и основным МЭ часто используется для расположения там дополнительных МЭ. Например, это может быть выделенный посредник для какой-либо службы (Web, почта) как на Рис. 4.23.4
Это может быть и система анализа содержимого (МЭ 5-го типа) как на Рис 4.23.5
Область между пакетным фильтром и основным МЭ играет существенную роль при построении защиты периметра. Эта область называется демилитаризованной зоной и служит для размещения в ней следующих узлов:
o Средств защиты (дополнительных МЭ, систем обнаружения атак)
o Серверов Web, SMTP, DNS и других, требующих доступа снаружи.
Существует два способа организации демилитаризованной зоны:
o Граничная сеть (рассмотренная в схемах выше)
o Тупиковая сеть (Рис. 4.23.6)
Второй вариант (тупиковая сеть) предполагает использование отдельного сетевого интерфейса МЭ для организации демилитаризованной зоны. По соображениям производительности первый вариант (граничная сеть) предпочтительнее.
Приведённые схемы расположения МЭ могут быть дополнены с учётом особенностей подключения к Internet, требований к безопасности и других факторов.
Политика безопасности и МЭ
МЭ - это воплощение в жизнь политики безопасности, принятой в организации в вопросах обмена информацией с «чужими» сетями. Правила политики безопасности формулируются без учёта особенностей используемого МЭ, его синтаксиса и т. п. Политика безопасности гласит «как должно быть», а МЭ - это техническая реализация этой политики. Далее приводится пример реализации политики безопасности.
Допустим, политика безопасности содержит следующие требования:
1. Пользователи внутренней сети имеют неограниченный доступ в Internet
2. Из Internet доступ возможен только к корпоративному Web-cepeepy и почтовому серверу
3. Удалённое управление должно быть аутентифицировано и зашифровано.
Для получения списка правил МЭ на основе предлагаемой политики необходимо проанализировать перечисленные требования и выбрать подходящий вариант размещения МЭ.
Первое требование тривиально и его реализация проста. Второе требование предполагает наличие web-cepeepa и почтового сервера. Лучшим местом для их размещения является DMZ. Выше рассматривалось два варианта DMZ. Допустим, в данном случае используется DMZ типа «тупиковая сеть».
Третье требование можно реализовать, предоставив, например, удалённый доступ для администраторов к отдельным узлам внутренней сети по протоколу SSH.
Дополнительно может потребоваться разрешить прохождение трафика, необходимого для работы перечисленных правил, например, DNS. Также следует обеспечить доступ к МЭ для управления им.
Следующий момент - порядок следования правил. Многие МЭ просматривают правила подряд (сверху вниз) до первого совпадения. Общий принцип здесь - размещать более общие правила в конце списка, более конкретные - в начале списка.
Далее приведён пример реализации правил на МЭ Check Point Firewall-1, но, в общем случае, это может быть и любой другой МЭ.
Первое правило разрешает доступ к МЭ с рабочей станции администратора
Второе правило блокирует доступ к МЭ для всех остальных узлов
Третье правило разрешает доступ к Web-cepeepy по протоколу http
Четвёртое правило разрешает доступ к почтовому серверу по протоколу SMTP
Пятое правило разрешает удалённый доступ к внутренним узлам только с определённых узлов администраторов.
Шестое правило разрешает доступ к почтовому серверу по протоколу POP3 для пользователей внутренней сети
Седьмое правило разрешает пользователям внутренней сети доступ в Internet (при этом исключается DMZ).
Восьмое правило блокирует доступ из DMZ к узлам внутренней сети.
И последнее (9-е) правило запрещает весь остальной трафик (для МЭ Check Point Firewall-1 оно излишне, поскольку запрет работает неявно, но здесь это сделано с целью записи в журнал фактов срабатывания этого правила).
Недостатки МЭ
Общий обзор
МЭ позволяют эффективно реализовать политику безопасности, касающуюся вопросов обмена информацией с «чужими» сетями (например, с внешним миром). Однако, наряду с очевидными достоинствами, МЭ имеют ряд ограничений:
o МЭ обеспечивают безопасность только тех соединений, которые установлены непосредственно через них. Это означает, что применение МЭ будет эффективным только тогда, когда периметр контролируется полностью. МЭ не контролируют соединения, установленные в обход средств защиты периметра, например, с использованием модемов. Кроме того, МЭ не контролируют внутренние соединения, т. е. подключения со стороны внутренних пользователей к внутренним ресурсам.
o МЭ могут содержать ошибки:
- В программном обеспечении (ошибки реализации).
- Допущенные при конфигурировании правил МЭ (ошибки обслуживания)
o МЭ не способны обнаружить запрещённый трафик, передаваемый поверх разрешённого протокола (эта проблема частично решается с помощью средств анализа содержимого). Как известно, механизм передачи трафика заданного типа поверх (внутри) другого называется туннелированием. Далее этот механизм рассматривается подробнее.
Туннелирование
Многоуровневая архитектура стека протоколов TCP ЯР делает возможной передачу трафика какого-либо типа поверх другого. Например, прикладные службы могут использовать в качестве протокола транспортного уровня TCP или UDP. В стандартных реализациях стека TCP/IP можно выделить четыре уровня.
Однако теоретически можно добавить ещё один уровень (над прикладными службами) и передавать произвольный трафик (как правило, это также трафик какой-либо прикладной службы) поверх прикладного.
Очевидно, программа для реализации описанного механизма должна иметьраспределённую архитектуру.
Задачи клиентской части:
o Ожидать соединения со стороны локального пользователя (по возможности, быть привязанной к интерфейсу 127.0.0.1)
o Упаковывать пользовательский трафик в трафик заданного типа и перенаправлять его серверной части (на другой конец туннеля).
Задачи серверной части:
o Ожидать соединения со стороны клиентской части
o Распаковывать трафик, отделяя от него информацию, связанную с работой туннеля
o Осуществлять взаимодействие с целевым сервером
Схема взаимодействия клиента с целевым сервером показана на следующем рисунке:
Реализации клиентской и серверной частей программы, выполняющей туннелирование, для различных ОС можно найти по адресу: http://www.nocrew.org/software/httptunnel.html
Что такое «HoneyNet»?
Введение
Говоря о защите периметра, нельзя не упомянуть о проекте «HoneyNet» (http://project.honeyNet.org/papers), цель которого - изучение поведения нарушителей. «HoneyNet» - это сеть узлов, используемых в повседневной работе, но предназначенных для взлома. В процессе взлома информация фиксируется, а затем анализируется с целью изучения поведения нарушителей.
Назначение и особенности
Основная цепь «HoneyNet» - сбор данных о противнике, изучение его тактики. С её помощью можно решить следующие задачи:
o Получение сведений о рисках в области безопасности и уязвимостях. Поскольку HoneyNet состоит из систем и приложений, используемых в повседневной деятельности, риски и уязвимости, имеющиеся в HoneyNet, полностью отображают риски и уязвимости реальной сети организации.
o Отработка политики реагирования на инциденты.
o Отслеживание действий нарушителя в реальном времени (общение через IRC и т. д.).
Таким образом, с помощью «HoneyNet» можно контролировать любую деятельность, происходящую внутри. Анализ собранных данных дает информацию об использованных инструментах, тактике и мотивах нарушителей.
Типовая схема «HoneyNet»
Схема «HoneyNet» должна быть спроектирована таким образом, чтобы обеспечить:
o Возможность контроля ситуации
o Возможность фиксации как можно большего числа данных
Сеть «HoneyNet» должна работать вместе с корпоративной сетью и быть максимально независимой от нее. Она может быть подключена к Интернет по отдельному каналу или использовать основной маршрутизатор организации.
В предлагаемом варианте сети можно выделить три сегмента:
o Собственно сама сеть «HoneyNet»
o Административная сеть
o Интернет
Сегмент «HoneyNet» состоит из:
o Узлов-приманок. Они создают сетевую среду, моделирующую реальную сеть предприятия. На этих узлах ничего не эмулируется, ничего не сделано специально для ослабления защиты.
o Сервера регистрации. Он собирает данные с узлов-приманок, настроенных так, что все данные сохраняются локально и на сервере-регистрации. На него могут поступать данные и от системы обнаружения атак (через административный сегмент)
o Системы обнаружения атак, собирающей трафик сетевого сегмента «HoneyNet».
Административный сегмент служит для сбора и обработки данных, которые и являются результатом работы «HoneyNet». Источниками данных являются:
o Межсетевой экран
o Сервер регистрации
o Система обнаружения атак
o Системные журналы узлов сегмента «HoneyNet»
Межсетевой экран осуществляет фиксацию событий и контроль соединений, позволяя управлять ситуацией в сегменте «HoneyNet». Маршрутизатор защищает от атак сетевого уровня, исходящих из сегмента «HoneyNet», таких как IPSpoofmg, Ping of Death и т. п., a также ограничивает ICMP- трафик.
Итак, использование «HoneyNet» даёт возможность получить информацию о противнике, изучить аспекты его поведения и сделать соответствующие выводы, относящиеся уже к реальной сети предприятия.
Дата добавления: 2022-01-22; просмотров: 28; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!