Linux reverse path filtering

How rp_filter works on Linux?

Rp_filter is short for reverse path filtering on Linux. We can use this to filter packets on Linux. Here are 5 common questions about rp_filter.

What is reverse path filtering?

Reverse path filtering is a mechanism adopted by the Linux kernel, as well as most of the networking devices out there to check whether a receiving packet source address is routable.

So in other words, when a machine with reverse path filtering enabled receives a packet, the machine will first check whether the source of the received packet is reachable through the interface it came in.

If it is routable through the interface which it came, then the machine will accept the packet.

If it is not routable through the interface, which it came, then the machine will drop that packet.

The latest redhat machines will give you one more option. This option is kind of liberal in terms of accepting traffic.

If the recieved packet’s source address is routable through any of the interfaces on the machine, the machine will accept the packet.

How to check if reverse path is enabled in Linux?

In Linux machine’s Reverse Path filtering is handled by sysctl, like many other kernel settings.

The current value on your machine can be found from the following method.

[root@localhost ~]# cat /proc/sys/net/ipv4/conf/default/rp_filter
1
[root@localhost ~]#

Let’s understand the boolean values for rp_filter first then go ahead with configuration.

1 indicates, that the kernel will do source validation by confirming reverse path. 0 indicates, no source validation.

How to check if the packet is dropped by reverse path filter?

In RHEL7, we can check this metric.

# netstat -s | grep Filter
ArpFilter: 0
IPReversePathFilter: 80
# netstat -s | grep Filter
ArpFilter: 0
IPReversePathFilter: 84
Between these two commands four packets were discarded by the reverse path filter.

Capture Rp_filter Log

We can enable log_martians and monitor syslog.

We can monitor syslog with the following command.

Which RP filter should we use in Oracle RAC env?

Red Hat Enterprise Linux 7 defaults to the use of Strict Reverse Path filtering. The reason strict mode is the default is to prevent IP spoofing from Distributed Denial-of-service (DDos) attacks.

However, having strict mode enabled on the private interconnect of an Oracle RAC database cluster may cause disruption of interconnect communication. It is recommended to set the RP_FILTER from strict mode to loose mode. Loosening the security on the private Ethernet interfaces should not be of concern as best practices recommend for an isolated private network that can only communicate between nodes specifically for Oracle’s private interconnect.

Example of Rp filter in Oracle RAC env

We got a high interconnect latency issue in our oracle RAC env recently. The ping latency is very high between nodes. It is related to this configuration. After we set it from 1 to 0, the issue is gone. The ping latency betweens Oracle nodes drops a lot. The GC wait is also gone on Oracle database side.

David is a Cloud & DevOps Enthusiast. He has years of experience as a Linux engineer. He had working experience in AMD, EMC. He likes Linux, Python, bash, and more. He is a technical blogger and a Software Engineer. He enjoys sharing his learning and contributing to open-source.

howtouselinux.com is dedicated to providing comprehensive information on using Linux.

We hope you find our site helpful and informative.

Источник

Глава 13. Параметры настройки сети в ядре.

В ядре имеется масса параметров, которые могут быть изменены под различные нужды. Хотя, заданные по-умолчанию параметры удовлетворяют потребности в 99% случаев, но не зря же мы назвали это руководство Advanced HOWTO!

Очень интересные настройки вы найдете в /proc/sys/net , загляните туда. Конечно же, изначально не все тонкости будут описаны здесь, но мы работаем над этим.

Между прочим, значительная часть настроек описана в файле Documentation/filesystems/proc.txt , в дереве каталогов с исходными текстами ядра.

13.1. Reverse Path Filtering.

Reverse Path Filtering — Проверка Обратного Адреса, хотя это слишком вольный перевод термина, но мне он кажется наиболее близким по смыслу. прим. перев. .

По-умолчанию, маршрутизаторы перенаправляют все подряд, даже пакеты, которые не принадлежат вашей сети. В качестве примера можно привести утечку локального трафика в Интернет. Если у вас имеется интерфейс с маршрутом к нему 195.96.96.0/24, то вы наверняка не ожидаете получить на него пакеты от 212.64.94.1.

В файловой системе /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

Источник