Подход Zorp

Настраиваем эффективную систему сетевой защиты Zorp

Фильтры пакетов вроде ipchains во время работы используют самые простые критерии, и для фильтрации основываются на информации, содержащейся в заголовках IP-пакетов: IP-адреса источника и назначения, протокол и номера портов источника и назначения, взятые с TCP/UDP-протоколов следующего уровня.

По сегодняшним меркам такой подход может обеспечить только самую минимальную защиту. Система защиты, использующая этот принцип, не владеет более подробной информацией о соединении. И приняв пакет, не может определить – устанавливается новое соединение либо пришедший пакет является частью уже установленного соединения, а может, это вообще случайный или враждебный пакет. Так работал ipchains, используемый совместно с Linux-ядром серии 2.2.

В Netfilter/iptables ядра 2.4/2.6 эта проблема решается за счет контроля состояния (stateful) флагов и порядковых номеров ТСР. Такой фильтр работает аналогично предыдущему и дополнительно просматривает флаги TCP и UDP-пакетов, а поэтому может определить, является ли этот пакет попыткой установления нового соединения. Если да, то в таблице состояний делается новая запись и действие разрешается, если нет, то проверяется принадлежность существующим соединениям и при положительном результате пакет пропускается. Кроме явного отсеивания приходящего мусора, такие фильтры упрощают написание правил фильтрации. Например, если ранее требовалось явно разрешить в правиле оба направления, т.е. от клиента к серверу и от сервера к клиенту, то теперь достаточно просто разрешить соединение с сервером, забота же о доставке информации клиенту полностью ляжет на плечи фильтра пакетов.

Кроме того, при использовании stateful-фильтров можно смело запрещать все соединения на номера портов выше 1024. Но опять же при всех положительных качествах контроль состояний не сможет защитить сервер от атак, направленных на конкретное приложение. Например, никто не помешает злоумышленнику послать запрос большой длины или попробовать реализовать сross-site scripting атаку. Без посредника здесь точно не обойтись.

Создатель Syslog-NG венгр Балазс Шайдлер (Balazs Scheidler) разработал еще одно полезное приложение – Zorp. На заглавной странице сайта проекта https://www.balabit.com он дословно именуется как Modular Application Level Gateway (хотя в некоторых документах его название несколько другое – new generation proxy firewall).

Но как бы ни звучало его название, назначение остается неизменным – защита приложений от направленных атак. Принцип действия похож на рассматриваемый ранее ModSecurity [1]. Zorp представляет собой прозрачный (transparent) прокси, который выступает посредником при работе клиента и сервера. В этом случае для клиента, который хочет установить новое соединение, Zorp выступает как сервер, а реальный сервер видит Zorp как клиента. Находясь посередине, такой прокси знает особенности своего протокола и на основании имеющейся информации и настроек может принять решение о необходимости продолжения текущего соединения.

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

Взаимодействие сервера и клиента в случае использования Zorp показано на рис. 1. Клиент, желая установить соединение, посылает TCP SYN-пакет, который поступает на маршрутизатор с установленным iptables (ipchais), использующим Zorp. Полученный пакет проверяется на соответствие правил iptables. Если он должен быть обработан Zorp, то в записи следует указать цель TPROXY (iptables) или REDIRECT (ipchains). В качестве одного из параметров указывается порт, где Zorp будет ждать подключения. Zorp получает пакет, проверяет его на соответствие со своими правилами и запускает соответствующий прокси, который инициализирует соединение с сервером и дальше действует уже от имени клиента, а в процессе работы проверяет проходящий поток данных. Естественно, и остальные цепочки также должны пропускать обработанные Zorp пакеты.

Теперь аномалии более низкого уровня будут отсеиваться сразу. Такой принцип работы позволяет делать то, что недоступно многим IDS, а именно проверять защищенные HTTPS, POP3S, IMAPS или SSH-соединения. То есть когда пользователь подключается к веб-серверу, последний отсылает ему сертификат, прокси может перехватить этот сертификат и отправить пользователю свой. Теперь, находясь посередине, можно беспрепятственно контролировать любой трафик. Таким же образом можно автоматически проверять сертификаты и разрешать доступ только к определенным ресурсам.

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