Bert Hubert - Linux Advanced Routing & Traffic Control HOWTO

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

Следующий фрагмент включит проверку исходящего адреса для всех существующих интерфейсов:

# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do

> echo 2 > $i

> done

Возвращаясь к примеру выше: пусть имеется маршрутизатор, построенный на базе Linux, который обслуживает две подсети — net1 и net2 , причем net1 подключена к интерфейсу eth0, а net2 — к интерфейсу eth1. Теперь, если на eth0, придет пакет с обратным адресом net2 , то он будет сброшен. Аналогичным образом будет отвергнут пакет, с обратным адресом net1 , пришедший на интерфейс eth1.

Это есть полная проверка обратного адреса. Но такая фильтрация возможна только на основе анализа IP-адресов сетей связанных напрямую маршрутизатором. Это потому, что полная фильтрация становится невозможной в случае асимметричной маршрутизации (когда пакеты приходят через один интерфейс, а ответный трафик через другой), например через спутник (или в случае динамической маршрутизации (bgp, ospf, rip) в вашей сети), когда данные поступают со спутниковой антенны, а ответы отправляются по обычной наземной линии связи.

Если у вас как раз такой случай (вы наверняка точно знаете об этом), то можете просто выключить rp_filter на интерфейсе, куда приходят данные со спутника. Если вам интересно узнать — сбрасываются ли какие-нибудь пакеты, файл log_martians , в том же самом каталоге, сообщит ядру о необходимости журналирования таких пакетов.

# echo 1 >/proc/sys/net/ipv4/conf//log_martians

FIXME: достаточно ли настроек в файлах conf/[default,all]/* ? — martijn

Итак, имеется целый ряд дополнительных настроек, которые вы можете изменить. Попробуем их перечислить. Кроме того, они частично описаны в файле Documentation/ip-sysctl.txt .

Некоторым из этих параметров присвоены такие значения по умолчанию, которые напрямую зависят от того как вы сконфигурировали свое ядро.

Оскар Андриссон (Oskar Andreasson) написал руководство, в котором значительно лучше нас описал все эти настройки, так что не поленитесь — загляните на http://ipsysctl-tutorial.frozentux.net/. (Русский перевод руководства "ipsysctl tutorial", о котором идет речь, вы найдете по адресу: http://gazette.linux.ru.net/rus/article/index-ipsysctl-tutorial.html, тарболл с исходными текстами документа (на русском языке) — http://gazette.linux.ru.net/archive/ipsysctl-tutorial.1.0.4.tar.gz.

Небольшое примечание: в большинстве своем, приводимые здесь временные параметры не воздействуют на локальный (loopback) интерфейс, так что вы не сможете проверить их, не имея реального сетевого интерфейса. Кроме того, указываемые пределы измеряются в 'тиках', и предполагают использование ранее упомянутого Token Bucket Filter .

Некоторые пункты, из приводимого ниже списка, мы просто скопировали из /usr/src/linux/Documentation/networking/ip-sysctl.txt , написанного Алексеем Кузнецовым и Энди Клином (Andi Kleen) .

От переводчика (А.К.):Я взял на себя смелость привести описание части параметров из "ipsysctl tutorial" , поскольку они более точные и полные.

/proc/sys/net/ipv4/icmp_destunreach_rate

Если ядро решит, что оно не в состоянии доставить пакет, то пакет будет сброшен, а отправителю будет послано соответствующее ICMP-сообщение.

/proc/sys/net/ipv4/icmp_echo_ignore_all

Параметр может принимать два значения — 0 (выключено) и 1 (включено). Значение по-умолчанию — 0 (выключено). Если записана 1, то ядро просто игнорирует все ICMP Echo Request запросы и тогда никто не сможет ping-ануть вашу машину, чтобы проверить ее наличие в сети, что само по себе не есть хорошо. Однако, у каждого из нас может быть свое собственное мнение по поводу этой опции. С одной стороны — окружающие лишены возможности проверить ваше присутствие в сети, с другой — существует масса приложений, которые используют ICMP Echo Request запросы далеко не в благовидных целях. Вобщем все как всегда — что-то плохо, а что-то хорошо.

/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Эта переменная очень близка по смыслу к icmp_echo_ignore_all , только в данном случае будут игнорироваться ICMP-сообщения, отправленные на широковещательный или групповой адрес. Вполне очевидно, почему полезно включить этот параметр — защита от smurf атак.