Определяемые пользователем цепочки

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

Создание своих цепочек IP Firewall позволит решить почти все эти проблемы. Каждая такая цепочка может использоваться наравне со встроенными. Вы можете использовать параметр -N команды

ipchains, чтобы создать новую цепочку с именем не более 8 символов. Ограничение имени символами только нижнего регистра, может быть, неплохая мысль. Опция -j позволяет задать реакцию на соответствие пакета данному правилу. Она может определять, что если пакет подходит под правило, дальше он должен тестироваться по заданному пользователем набору правил. Рассмотрим команды ipchains :

ipchains -P input DENY ipchains -N tcpin ipchains -A tcpin -s ! 172.16.0.0/16 ipchains -A tcpin -p tcp -d 172.16.0.0/16 ssh -j ACCEPT ipchains -A tcpin -p tcp -d 172.16.0.0/16 www -j ACCEPT ipchains -A input -p tcp -j tcpin ipchains -A input -p all

Мы задали реакцию по умолчанию deny для набора правил input. Вторая команда создает определенную пользователем цепочку tcpin, которая соответствует любому пакету, пришедшему снаружи нашей локальной сети. Третья команда добавляет в нее правило, которое пока не выполняет никаких действий. Это правило нужно для учета и подробно рассмотрено в главе 10. Следующие два правила соответствуют любому пакету, который предназначен для нашей локальной сети и любого из портов ssh или www , такие пакеты будут приняты. Следующее правило как раз то, когда реально начинается волшебство ipchains. Оно вызывает firewall для проверки всех пакетов протокола TCP по набору правил, заданному пользователем. Наконец, мы добавляем правило к нашему набору input, которое соответствует любому пакету. Это еще одно правило учета.

Наши наборы правил input и

tcpin заполняются нашими правилами. Процесс обработки пакета всегда начинается в одной из встроенных цепочек. Наша собственная цепочка вступает в дело по команде из одной из встроенных цепочек. Сначала, давайте рассмотрим, что происходит, когда для одного из наших компьютеров получен пакет UDP.

Пакет на приеме попадает в цепочку input. Первые два правила его игнорируют, поскольку они соответствуют ICMP и TCP. Пакет соответствует третьему правилу в input, но оно не определяет адресата, так как просто модифицирует счетчики байтов и пакетов, и не выполняет никакого действия непосредственно с пакетом. Он достигает конца input, встречается с заданной по умолчанию стратегией для input и отклоняется.

Чтобы увидеть нашу определяемую пользователем цепочку в действии, давайте теперь рассматривать что случается, когда мы получаем TCP-пакет предназначенный для порта ssh одного из наших компьютеров.

На это раз второе правило в цепочке input

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

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

У определяемых пользователем цепочек нет заданной по умолчанию реакции на внешние раздражители. Когда все правила в определяемой пользователем цепочке будут проверены, и ни одно не соответствует ситуации, firewall действует, как если бы правило было задано правило RETURN. В нашем примере проверка вернется к набору input. В конечном счете мы достигаем конца цепочки input, которая имеет заданную по умолчанию стратегию, и пакет будет отклонен.

Этот пример очень прост, но иллюстрирует основную логику работы. Немного более сложный пример:

# Set default forwarding policy to REJECT ipchains -P forward REJECT # # create our user-defined chains ipchains -N sshin ipchains -N sshout ipchains -N wwwin ipchains -N wwwout # # Ensure we reject connections coming the wrong way ipchains -A wwwin -p tcp -s 172.16.0.0/16 -y -j REJECT ipchains -A wwwout -p tcp -d 172.16.0.0/16 -y -j REJECT ipchains -A sshin -p tcp -s 172.16.0.0/16 -y -j REJECT ipchains -A sshout -p tcp -d 172.16.0.0/16 -y -j REJECT # # Ensure that anything reaching the end of a user-defined chain is rejected. ipchains -A sshin -j REJECT ipchains -A sshout -j REJECT ipchains -A wwwin -j REJECT ipchains -A wwwout -j REJECT # # divert www and ssh services to the relevant user-defined chain ipchains -A forward -p tcp -d 172.16.0.0/16 ssh -b -j sshin ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 ssh -b -j sshout ipchains -A forward -p tcp -d 172.16.0.0/16 www -b -j wwwin ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 www -b -j wwwout # # Insert our rules to match hosts at position two in our user-defined chains. ipchains -I wwwin 2 -d 172.16.1.2 -b -j ACCEPT ipchains -I wwwout 2 -s 172.16.1.0/24 -b -j ACCEPT ipchains -I sshin 2 -d 172.16.1.4 -b -j ACCEPT ipchains -I sshout 2 -s 172.16.1.4 -b -j ACCEPT ipchains -I sshout 2 -s 172.16.1.6 -b -j ACCEPT

<

/p>

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

Наш пример создает определяемые пользователем цепочки для сервисов ssh и www в каждом направлении подключения. Есть цепочка wwwout, в ней мы помещаем правила для компьютеров, имеющих право создавать исходящие подключения World Wide Web, и цепочка sshin, хранящая правила для машин, которым можно приинимать входящие подключения ssh. Допустим, нам надо гибко задавать эти разрешения для каждого компьютера в нашей сети. Упрощение происходит, потому что определяемые пользователем цепочки позволяют нам аккуратно группировать правила для прав доступа входящих и исходящих пакетов с компьютеров. Рост эффективности происходит потому, что для любого пакета мы уменьшили среднее число тестов, требуемых для поиска адресата. Если бы мы не использовали определяемые пользователем цепочки, нам бы пришлось искать целый список правил, чтобы узнать какое действие выполнить с каждым пакетом. Даже при условии равномерности поступления пакетов в среднем мы просматривали бы половину списка. Определяемые пользователем цепочки позволяют нам избегать проверки большого числа правил, если проверяемый пакет не соответствует простому правилу во встроенной цепочке, которая вызывает наши цепочки.

Содержание раздела