Родерик Смит - Сетевые средства Linux

Бывают ситуации, при которых обращение к одному узлу должно быть перенаправлено на другой узел либо на другой порт того же компьютера. Эта задача решается с помощью перенаправления портов, организуемого с помощью программы iptables.

Перенаправление портов может потребоваться в следующих ситуациях.

• Если вы перемещаете сервер с одного компьютера на другой, но по каким-либо причинам не можете изменить конфигурацию сервера DNS. Перенаправление портов позволяет разрешить эту проблему.

• Если вы хотите, чтобы один и тот же сервер отвечал на обращения по разным портам. Вы можете настроить систему для перенаправления запроса с одного порта на другой. Некоторые серверы могут принимать обращение через несколько портов, в этом случае перенаправление портов не требуется.

• Если вы хотите установить в сети, защищенной NAT-маршрутизатором, сервер и обеспечить доступ к нему извне. В этом случае вы можете настроить NAT-маршрутизатор для перенаправления трафика, связанного с одним из внешних портов, внутренней системе.

Необходимость в перенаправлении запросов компьютерам локальной сети часто возникает при использовании NAT-маршрутизатора. При этом уровень защиты несколько снижается, так как вы предоставляете внешним узлам доступ к одному из компьютеров (точнее, к одному из портов да нем). Подобное решение допускает выполнение лишь одного внутреннего сервера, ожидающего обращения через определенный порт. Если вы хотите запустить во внутренней сети два сервера одного типа, доступных извне (например, два Web-сервера), то один из них должен использовать нестандартный порт либо эти серверы должны быть представлены на внешних компьютерах с разными IP-адресами.

Обеспечить перенаправление портов на компьютере под управлением Linux, поддерживающем NAT, можно различными способами. Один из них состоит в использовании iptables. Соответствующая команда имеет следующий вид:

# iptables -t nat -A PREROUTING -p tcp -i external-interface \

--destination-port port-num -j DNAT --to dest-addr:port-num

Ниже описаны компоненты данной команды.

• Опция, определяющая таблицу NAT ( -t nat).

• Опция -A PREROUTING, указывающая на то, что изменения должны вноситься в состав пакета перед выполнением маршрутизации. Базовые средства NAT применяются после маршрутизации, но перенаправление портов предшествует маршрутизации.

• Опция, которая задает перенаправление TCP-портов ( -p tcp).

• Правило, применяемое к пакетам, направленным через внешний интерфейс ( -i внешний_интерфейс ) по конкретному порту ( -destination-port номер_порта ).

• Опция -j DNAT, указывающая на то, что вместо NAT источника ( SNAT) выполняется NAT назначения ( DNAT).

• Опция --to адрес_назначения : номер_порта , сообщающая, что пакет должен быть направлен на указанный адрес с использованием указанного номера порта. В качестве адреса назначения можно указать, например, адрес 192.168.9.33, а номер порта может быть равен 80. Заметьте, что номер порта, задаваемый посредством опции --to, не обязательно должен совпадать с номером порта, представляющим значение опции --destination-port.

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

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

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

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

В программе iptablesпредусмотрено специальное действие LOG, управляющее протоколированием. В отличие от других действий, действие LOGне приводит к прекращению дальнейшей проверки; если пакет соответствует правилу, в котором указано данное действие, ядро продолжает поверку, используя остальные правила текущей цепочки. Действие LOGпозволяет решить следующие задачи.

• С помощью действия LOGможно протоколировать события, состоящие в появлении пакетов, которые не удовлетворяют другим правилам. Например, вы можете включить правило для записи информации о тех пакетах, которые не прошли проверку с учетом состояния.

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

• Если вы установили политику по умолчанию DENYили REJECT, вы можете включить правило протоколирования в конце цепочки и получать таким образом информацию о пакетах, по умолчанию отвергаемых системой.

• Если в вашей системе установлена политика по умолчанию ACCEPT, вы можете получать информацию об отвергнутых пакетах, продублировав каждое запрещающее правило аналогичным правилом, в котором действие DENYили REJECTзаменено на LOG.