Брандмауэры и специальное программное обеспечение 8 Часть 4

Вид материалаРеферат

Содержание


Как работает ipchains
Простые политики брандмауэра
Что фильтровать и где
Что не следует отфильтровывать
Подобный материал:
1   ...   58   59   60   61   62   63   64   65   ...   101

Как работает ipchains


Когда ipchains анализирует заголовок пакета IP, производятся следующие действия в указанном порядке.

Сравнение контрольной суммы: пакет либо принимается и передается даль ше, либо отклоняется и отбрасывается.

Проверка корректности: не является ли пакет искаженным? Если да, то такой пакет отбрасывается.

Обработка цепочки input: если не выполнены действия DENY или REJECT, про исходит переход к следующему шагу.

Демаскировка (demasquerade): в ответах, адресованных маскированным узлам, происходит перезапись адреса, в противном случае этот шаг пропускается.

Маршрутизация: передать пакет локальному процессу (local process) или в це почку forward.

Обработка локальным процессом: интерфейс изменяется на lо, и если пакет адресован локальному процессу, происходит обработка цепочек output и input, в противном случае производится обработка только цепочки output, а поддер живает ее локальный процесс.

Локальная маршрутизация: если пакет прошел через локальный процесс, но был отправлен не с локального сетевого узла — иными словами, пакет получен от удаленного узла, был обработан локально (см. ранее) для дальнейшего перенап равления (обработка proxy, перенаправление портов и т. п.), и предназначен для передачи на удаленный узел, — пакет передается в цепочку, forward, в противном случае (если пакет локальный) он передается в цепочку output, и если в ней не выполняются ни DENY, ни REJECT, пакет передается локальному узлу localhost).

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

Обработка цепочки output: для всех пакетов, покидающих данный узел.


СОВЕТ

Пункт «обработка локальным процессом» несколько сбивает с толку. Однако примите во внимание, что HOST и LOCALHOST — это два различных сетевых узла, и вам многое станет понятным. Чтобы перейти от HOST к LOCALHOST, пакет должен пройти сквозь все правила (за исключением forward), при этом он должен покинуть узел HOST и войти в узел LOCALHOST, затем пройти все процессы, предназначенные для удаленных узлов.

Простые политики брандмауэра


Теперь вы готовы к формированию набора правил брандмауэра. Прежде чем вы приступите к этому, я хочу заострить ваше внимание на нескольких важных моментах. Перед модификацией набора правил лучше изменить значение /proc/sys/net/ ipv4/ip_forward с 1 на 0 для того, чтобы отключить передачу пакетов через брандмауэр. Завершив формирование набора правил, передачу пакетов следует включить. Благодаря этому вы предотвратите непреднамеренное проникновение нежелательных пакетов во внутреннюю сеть, которое может произойти, пока вы редактируете набор правил. Значение этого параметра следует также проверить в случае, если пакеты не передаются через брандмауэр в то время, как вы этого хотите.


ВНИМАНИЕ

Если вы измените все политики во всех встроенных цепочках на DENY и REJECT, убедитесь в том, что вы не используете правил, которые требуют сопоставления имен. Вместо имен сетевых узлов используйте IP-адреса.

Также не стоит забывать о том, что проверка правил осуществляется в определенном порядке. Как только в процессе проверки некоторого правила, содержащего специальное значение, обнаруживается совпадение, обработка цепочки завершается (за исключением ранее описанных ситуаций). Таким образом, следует обращать внимание на то, какие правила располагаются в начале цепочки. Например, правило ipchains -I input 1 -j REJECT (самым первым правилом цепочки input становится правило REJECT) может сработать не так, как вы этого хотите. В правиле отсутствует параметр -s, поэтому оно будет действовать в отношении всех адресов. Более того, так как в нем нет параметра -i, оно будет применяться ко всем интерфейсам. Наконец, благодаря тому, что в нем отсутствует параметр -р, оно будет действовать в отношении всех протоколов. Фактически это правило отклоняет абсолютно все пакеты, даже сообщения локального узла. Иными словами, локальные процессы не смогут обмениваться сообщениями. Скорее всего, это не то, что вам нужно.

Правила необходимо делать простыми и понятными. Формируя набор правил, выполняйте тестирование на каждом этапе.

Что фильтровать и где

Иногда следует учитывать не только то, что вы фильтруете, но и где вы это делаете. Допустим, вы хотите предотвратить отправку ответов на внешние запросы ping для всех узлов внутренней сети. Вы можете использовать один из двух методов.

Во-первых, вы можете запретить или отклонять все эхо-запросы ping следующим правилом:

ipchains -A input -s echo-request -j DENY

Во-вторых, вы можете блокировать эхо-ответ ping, прежде чем он покинет сеть:

ipchains -A output -s echo-response -j DENY

Конечный результат обоих методов одинаков: эхо-ответы не будут покидать пределов внутренней сети, однако эффект обоих правил различается. Скорее всего, предпочтительным окажется первый метод. Первый метод блокирует проникновение в сеть любых пакетов ping извне, в то время как второй пропускает внутрь сети эхо-запросы, но блокирует исход из сети эхо-ответов. Если пакет ping, пытающийся проникнуть в сеть, окажется пакетом ping of death (большой ping) и будет адресован внутреннему узлу, подверженному такому типу атак, то первый метод предотвратит атаку, в то время как второй — нет. С другой стороны, первый метод будет блокировать помимо прочих пакеты ping, адресованные локальному узлу. Если в правиле вы укажете интерфейс и будете отбрасывать только пакеты ping, приходящие из Интернета, то вы сможете связываться с брандмауэром при помощи ping (в тестовых целях) как из внутренней сети, так и с узла localhost.

Что не следует отфильтровывать

Некоторые администраторы ошибочно считают, что пакеты ICMP можно не пропускать через брандмауэр, так как эти пакеты не так важны для нормального функционирования сети. Между пакетами ICMP любых типов и пакетами ping ставится знак равенства, что на самом деле неправильно. Помимо запросов ping протокол ICMP используется для передачи через сеть многих других чрезвычайно важных сообщений. В частности, при помощи ICMP через сеть передаются сообщения destination-not-reachable (место назначения недоступно), поэтому если вы блокируете ICMP, внутренние сетевые узлы не смогут принимать подобные сообщения. Помимо этого система OpenLinux использует сообщения ICMP для настройки MTU (Maximum Transmission Unit — максимально допустимая единица передачи). Для сетевых карт Ethernet значение этого параметра в нормальных условиях равно 1500 для максимизации объема передаваемых данных. Фрагментация пакетов вызывает более длительные задержки, чем уменьшение MTU. По этой причине Linux устанавливает бит DF (Do not Fragment — не фрагментировать). Если сетевой узел или маршрутизатор требует фрагментации пакета, он не сможет это сделать, так как бит DF установлен, по этой причине пакет отбрасывается, а сетевому узлу-источнику посылается сообщение ICMP. Получив такое сообщение, Linux уменьшает размер MTU и пытается передать пакет снова. Так происходит до тех пор, пока пакет не получается передать к месту назначения. Но если вы полностью блокируете ICMP, операционная система не сможет подобрать наиболее эффективное значение MTU, поэтому обмен данными с некоторыми узлами может происходить чрезвычайно медленно.

Многие администраторы, зная о том, что DNS использует UDP через порт 53, пытаются блокировать TCP через этот порт. Однако следует учитывать, что когда DNS выполняет трансферт зоны или любую другую объемную передачу данных, эта система переключается на использование TCP.

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