---

Лед и пламя№32(203)/19.08.2002

Сергей ЯРЕМЧУК grinder@ua.fm
(Окончание, начало см. в МК № 30 (201))
-p TCP -d 0.0.0.0/0 ! www

или
-p TCP -d 0.0.0.0/0 ! 80

Заметьте, что условие
-p TCP -d ! 192.168.1.1 www

отличается от
-p TCP -d 192.168.1.1 ! www

Первое означает, что любой TCP-пакет направляется на www-порт любой
машины, кроме 192.168.1.1. Второе назначает любой TCP-пакет на любой
порт машины 192.168.1.1, кроме порта www.
А вот так выглядит конструкция «любой TCP-пакет, кроме адресованных
на любой порт машины 192.168.1.1 и кроме адресованных на www-порт
любой машины»:
-p TCP -d ! 192.168.1.1 ! www

Опция -i означает интерфейс. Для входящих пакетов (входная цепочка)
это будет интерфейс, через который были получены пакеты, а для
выходящих (выходная цепочка) — тот, через который они будут
отправлены.
Для транзитных пакетов, проверяемых по цепочке forward,
предписывается тот интерфейс, через который они будут отправлены.
При проверке по пользовательской цепочке интерфейс определяется в
зависимости от того, из какой встроенной цепочки была вызвана
проверка.
При задании правил можно указывать отсутствующий на данный момент
интерфейс — как только он появится, для него уже будут готовы
правила. При задании интерфейсов можно использовать маски и
инверсии. Так, -i ppp+ означает все интерфейсы, имена которых
начинаются с ppp (даже несуществующие), а -i ! eth0 — все, кроме
eth0.
Иногда необходимо разрешить создание соединений TCP только в одну
сторону, но протокол TCP требует, чтобы пакеты проходили в обеих
направлениях (подтверждение ранее принятых пакетов, например, — без
этого соединение попросту разорвется). Огульная фильтрация всех
TCP-пакетов может только навредить. Каждый пакет, являющийся
запросом на соединение, содержит флаг SYN (FIN и ACK соответственно
сброшены). Для проверки этого условия служит флаг -у (напоминаю, он
используется только с ТСР-протоколом). Команда
-p TCP -s 192.168.1.1 -y

отбирает все запросы на установку соединения с машины с адресом
192.168.1.1.
Еще один момент, связанный с безопасностью. Так как на самом нижнем,
физическом уровне модели OSI (эталон, описывающий взаимодействие
протоколов в сети) может находиться любая аппаратура от любых
производителей (естественно, со своей скоростью передачи и
пропускной способностью), то вполне допустима ситуация, когда длина
пакета превышает максимально допустимую для передачи по некоторому
каналу (MTU-maximum transfer unit). В этом случае пакеты разбиваются
на несколько частей, т. е. фрагментируются, и каждый фрагмент
посылается отдельно. В точке приема (промежуточные станции по
умолчанию бездействуют) пакеты собираются заново —
дефрагментируются. Проблема состоит в том, что все данные,
необходимые для проверки, содержатся только в первом пакете (порт
отправителя, порт получателя, тип ICMP, код ICMP, TCP-флаг SYN).
Раньше считалось, что остальные пакеты не важны, но известны случаи
нарушения работы компьютеров путем посылки фрагментов.
Например, условия -p TCP -s 192.168.1.1 www, как и -p TCP -s
192.168.1.1 ! www, на втором и последующих пакетах попросту не
сработают.
Так вот, если ваша машина является единственным шлюзом, соединяющим
локальную сеть с Интернетом, то пересобрав ядро с параметром
(CONFIG_IP_ALWAYS_DEFRAG), вы можете заставить систему
дефрагментировать все проходящие пакеты. А с помощью флага -f можно
указать правила для второго и следующих пакетов.
Например, с помощью следующего правила можно уничтожить все пакеты,
поступающие на 192.168.1.1:
# ipchains -A output -f -d 192.168.1.1 -j DENY

Если пакет соответствует условию, то действие, применяемое к пакету,
задается флагом -j (jump). Вот таким примерно образом можно отсеять
пакеты, посылаемые довольно известным трояном BackOriffice, если вы
защищаете сеть с Windows-машинами:
# /sbin/ipchains -A output -j REJECT -i ppp0 -p udp -d 0/0 31337 -l
# /sbin/ipchains -A output -j REJECT -i ppp0 -p udp -d 0/0 31338 -l

А примерно так можно отсеять рекламные баннеры:
#/sbin/ipchains -A input -j REJECT -i ppp0 -p tcp -s server_ip_adress -d your_ip_adress

Тем самым мы отбрасываем все ТСР-пакеты, идущие от банерного сервера
на ваш IP-адрес. Все вроде бы логично: ловим на мушку сервер и
запрещаем принимать с него информацию. Но по-моему, слишком
прямолинейно. Давайте посмотрим на этот вопрос с другой стороны.
Откройте в блокноте любой html-файл с кучей баннеров. Видите, в
начале и конце файла полно java-скриптов. Ими-то и вызываются для
загрузки баннеры (кстати, таким же образом можно взять и IP-адрес).
Если записать правило в таком виде, события будут проистекать
примерно так: при загрузке страницы браузер находит вызов javascript
и посылает запрос на выдачу файла (баннера). Сервер, который
прямо-таки кишит ими, естественно, охотно откликается на запрос, а
так как баннер целиком в канал не пролазит, он разбивает его на
пакеты и посылает первую порцию датаграмм. Когда первый пакет
достигает нашего компьютера, он анализируется, а так как он подходит
под наше правило, то тут же отбрасывается, узлу же посылается
сообщение о недоступности узла назначения. Сервер, получив
сообщение, на этом успокаивается, но наш браузер, так ничего и не
дождавшись в ответ, через несколько секунд повторяет запрос, и все
повторяется снова, пока не выйдет отведенное время. Как видите,
такой способ может только увеличить длительность загрузки страниц, и
часть ненужных нам пакетов все таки попадут в канал. Поэтому лучше
поменяем местами IP-адреса назначения и отправителя. Правило будет
выглядеть так:
#/sbin/ipchains -A input -j REJECT -i ppp0 -p tcp -s your_ip_adres -d server_ip_adress

В этом случае браузер, послав запрос, сразу же получает ответ — узел
назначения недостижим (поэтому здесь и используется REJECT а не
DENY), на чем и успокаивается; сервер же не получает запроса и
остается в неведении о происходящем. Так мы существенно ускорим
загрузку документа и облегчим канал. Конечно же, вы должны понимать,
что если баннеры грузятся с того же узла, что и документ, то они
благополучно пройдут все заслоны, но тут уж ничего не поделаешь.
Флаг -l означает, что соответствующие пакеты необходимо
регистрировать в системном журнале. Если не оговорены никакие
действия, то последует простой их подсчет. Например, ipchains -A
input -s 192.168.0.1 (выводится командой ipchains -L -v). Применение
флага -t позволяет манипулировать четырьмя битовыми флагами, так
называемыми TOS (Type Of Service), имеющимися в каждом IP-заголовке
— их значения иногда учитываются маршрутизаторами, и это может
ускорить обработку пакетов на промежуточных станциях. Названия и
рекомендуемые значения приведены в таблице.
Например, для telnet'a и ftp-соединения назначим минимальную
задержку, для получения данных по ftp — максимальную пропускную
способность:
# ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10
# ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
# ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08

Создать свою цепочку правил можно, воспользовавшись флагом -N (new):

# ipchains -N test

Удалить цепочку можно только в том случае, если она пустая (т. е. не
содержит никаких правил) и на нее не ссылаются из других цепочек.
Для удаления используется флаг -Х.
# ipchains -X test

Очистка цепочки (т. е. удаление из нее всех правил) производится
командой -F (flush). Например:
ipchains -F forward

Осторожно! Если имя цепочки не указано, то будут очищены все
цепочки.
Просмотр одной цепочки или всех сразу производится командой -L
(list), например:
ipchains -L input

Вместе с флагом -L для удобства вывода информации можно использовать
флаги: -n (numeric), -v (verbose), -x (expand numbers). Для сброса
счетчика применяется флаг -Z (zero).
Для того чтобы проверить правила, проще всего смоделировать
несколько ситуаций и воспользоваться командой -С с заданием адреса и
порта (-s и -d), параметров -p и -i. Список результатов теста можно
вывести, задав параметр -v — таким образом можно увидеть, прошел
пакет или нет.
Например, тестируем TCP-SYN пакет от 192.162.1.1 по порту 60000 (X
Window System) к 192.168.1.2 на порт www, начиная от входной
цепочки. Это классическое www-соединение.
# ipchains -C input -p tcp -y -s 192.168.1.1 60000 -d 192.168.1.2 www

Еще два слова хочу сказать о фильтрации. Может быть два подхода: 1)
все, что не разрешено явно, запрещено; 2) все, что не запрещено,
разрешено. То есть в первом случае ACCEPTим все необходимое, а все
остальное — REJECTим или отDENYваем, во втором случае наоборот.
Можно, естественно, смешивать эти два варианта: для входящих пакетов
выбрать одну политику, а для исходящих другую. Решать вам.
Вот, в принципе, все, что я хотел рассказать о firewall'е в Linux.
Как видите, основным его достоинством является полный контроль над
происходящим — никакой зависимости от конкретной программы, что
желаем, то и пропускаем, что не нужно — отбрасываем. Недостаток
(если можно так выразиться) вытекает отсюда же — необходимо иметь
соответствующие знания, чтобы правильно все настроить. Новичку, я
думаю, это будет нелегко, ведь необходимо хорошо разбираться не
только в Linux, но и в принципах реализации различных протоколов
Интернета. Но прогресс не стоит на месте. В Интернете можно найти
кучу скриптов, помогающих автоматизировать процесс настройки
брандмауэра. Некоторые из них представлены и в документации к
IPCHAINS — HOWTO, Firewall-HOWTO. В этих же документах расписаны
остальные рекомендуемые опции, которые необходимо включить при
перекомпиляции ядра, приведены примеры. Еще по адресу
http://www.ecst.csuchico.edu/dranch/Linux/index-linux.html вы можете
найти поэтапное руководство по настройке всей TrinityOS, а не только
firewall’а — в нем обстоятельно расписан процесс создания безопасной
системы со множеством примеров хорошо прокомментированных
конфигурационных файлов, автоматически настраивающихся с помощью
различных переменных окружения. Рекомендую разобраться во всем этом
еще из-за того, что правила после перезагрузки не сохраняются,
почему их приходится всякий раз перезаписывать заново, и хоть есть
специальные утилиты, лучше, по-моему, все-таки воспользоваться
скриптом. К тому же IP-адрес может быть непостоянным, а так как в
скриптах предусмотрено использование переменных, то его можно
генерировать с помощью программы ifconfig. Также в последнее время в
Интернете мне встретилось множество графических firewall’oв, но на
поверку все они оказались фронт-эндом к IPCHAIS. Непонятно, зачем
изобретать велосипед и создавать что-то новое, если «старое» отлично
работает. Например, в моем Red Hat 7.3 имеется утилита lokkit (см.
Рис. 1), что-то вроде Wizard’a, позволяющего, отвечая на вопросы,
задавать правила. Естественно, таким образом можно создать только
общие правила, остальное все равно придется проделать вручную.
Итак, мы рассмотрели основные команды, касающиеся фильтрации
пакетов. Я не касался вопроса маскарадинга (соединение нескольких
компьютеров с Интернетом по одному каналу) с помощью данной
программы — думаю, домашнему пользователю этот вопрос менее
интересен, а системные администраторы и сами разберутся, если в том
будет необходимость. Применение команд не должно вызвать особых
затруднений, если определиться с политикой — какие пакеты
отбрасывать и на каком этапе. Как видите, никакого волшебства: все
научно обосновано и логично. Затачивайте фильтры, господа!

Перейти на главную страничку раздела "Интернет"