Чтение онлайн

3. Производится подстановка адреса назначения, однако адрес отправителя не подменяется, т.е. исходный адрес остается в пакете без изменения.

4. Пакет покидает брандмауэр и отправляется на HTTP сервер.

5. HTTP сервер, готовясь к отправке ответа, обнаруживает, что клиент находится в локальной сети (поскольку пакет запроса содержал оригинальный IP адрес, который теперь превратился в адрес назначения) и поэтому отправляет пакет непосредственно на $LAN_BOX.

6. Пакет поступает на $LAN_BOX. Клиент «путается», поскольку ответ пришел не с того узла, на который отправлялся запрос. Поэтому клиент «сбрасывает»

пакет ответа и продолжает ждать «настоящий» ответ.

Проблема решается довольно просто с помощью SNAT. Ниже приводится правило, которое выполняет эту функцию. Это правило вынуждает HTTP сервер передавать ответы на наш брандмауэр, которые затем будут переданы клиенту.

iptables -t nat -A POSTROUTING -p tcp –dst $HTTP_IP –dport 80 -j SNAT \ –to-source $LAN_IP

Запомните, цепочка POSTROUTING обрабатывается самой последней и к этому моменту пакет уже прошел процедуру преобразования DNAT, поэтому критерий строится на базе адреса назначения $HTTP_IP.

Если вы думаете, что на этом можно остановиться, то вы ошибаетесь! Представим себе ситуацию, когда в качестве клиента выступает сам брандмауэр. Тогда, к сожалению, пакеты будут передаваться на локальный порт с номером 80 самого брандмауэра, а не на $HTTP_IP. Чтобы разрешить и эту проблему, добавим правило:

iptables -t nat -A OUTPUT –dst $INET_IP -p tcp –dport 80 -j DNAT \ –to-destination $HTTP_IP

Теперь никаких проблем, с доступом к нашему WEB-серверу, уже не должно возникать.

ПРИМЕЧАНИЕ: Каждый должен понять, что эти правила предназначены только лишь для корректной обработки адресации пакетов. В дополнение к этим правилам вам может потребоваться написать дополнительные правила для цепочки FORWARD таблицы filter. Не забудьте при этом, что пакеты уже прошли цепочку PREROUTING и поэтому их адреса назначения уже изменены действием DNAT.

Данное действие просто «сбрасывает» пакет и iptables «забывает» о его существовании. «Сброшенные» пакеты прекращают свое движение полностью, т.е. они не передаются в другие таблицы, как это происходит в случае с действием ACCEPT. Следует помнить, что данное действие может иметь негативные последствия, поскольку может оставлять незакрытые «мертвые» сокеты как на стороне сервера, так и на стороне клиента, наилучшим способом защиты будет использование действия REJECT особенно при защите от сканирования портов.

LOG – действие, которое служит для журналирования отдельных пакетов и событий. В журнал могут заноситься заголовки IP пакетов и другая интересующая вас информация. Информация из журнала может быть затем прочитана с помощью dmesg или syslogd либо с помощью других программ. Превосходное средство для отладки ваших правил. Неплохо было бы на период отладки правил вместо действия DROP использовать действие LOG, чтобы до конца убедиться, что ваш брандмауэр работает безупречно. Обратите ваше внимание так же на действие ULOG, которое наверняка заинтересует вас своими возможностями, поскольку позволяет выполнять запись журналируемой информации не в системный журнал, а в базу данных MySQL и т.п..

ПРИМЕЧАНИЕ:

Обратите внимание – если у вас имеются проблемы с записью в системный журнал, то это проблемы не iptables или netfilter, а syslogd. За информацией по конфигурированию syslogd обращайтесь к man syslog.conf.

Действие LOG имеет пять ключей, которые перечислены ниже.

Таблица 6-17. Ключи действия LOG

(Ключ – Пример – Описание)

Ключ:–log-level

Пример: iptables -A FORWARD -p tcp -j LOG –log-level debug

Описание: Используется для задания уровня журналирования (log level). Полный список уровней вы найдете в руководстве (man) по syslog.conf. Обычно, можно задать следующие уровни: debug, info, notice, warning, warn, err, error, crit, alert, emerg и panic. Ключевое слово error означает то же самое, что и err, warn – warning и panic – emerg. Важно: в последних трех парах слов не следует использовать error, warn и panic. Приоритет определяет различия в том как будут заноситься сообщения в журнал. Все сообщения заносятся в журнал средствами ядра. Если вы установите строку kern.=info /var/log/iptables в файле syslog.conf, то все ваши сообщения из iptables, использующие уровень info, будут заноситься в файл /var/log/iptables Однако, в этот файл попадут и другие сообщения, поступающие из других подсистем, которые используют уровень info. За дополнительной информацией по syslog и syslog.conf я рекомендую обращаться к manpages и HOWTO.

Ключ: –log-prefix

Пример: iptables -A INPUT -p tcp -j LOG –log-prefix «INPUT packets»

Описание: Ключ задает текст (префикс), которым будут предваряться все сообщения iptables. Сообщения со специфичным префиксом затем легко можно найти, к примеру, с помощью grep. Префикс может содержать до 29 символов, включая и пробелы.

Ключ: –log-tcp-sequence

Пример: iptables -A INPUT -p tcp -j LOG –log-tcp-sequence

Описание: Этот ключ позволяет заносить в журнал номер TCP Sequence пакета. Номер TCP Sequence идентифицирует каждый пакет в потоке и определяет порядок «сборки» потока. Этот ключ потенциально опасен для безопасности системы, если системный журнал разрешает доступ «НА ЧТЕНИЕ» всем пользователям. Как и любой другой журнал, содержащий сообщения от iptables.