netfilter / iptables: dlaczego nie użyć surowego stołu?

W Linuksie zwykle używamy tabeli „filtr” do wspólnego filtrowania:

iptables --table filter --append INPUT --source 1.2.3.4 --jump DROP
iptables --table filter --append INPUT --in-interface lo --jump ACCEPT

Zgodnie z poniższym schematem przepływu netfilter, pakiety najpierw przechodzą przez tabelę „surową”:

Możemy więc napisać:

iptables --table raw --append PREROUTING --source 1.2.3.4 --jump DROP
iptables --table raw --append PREROUTING --in-interface lo --jump ACCEPT

• pakiety są obsługiwane wcześniej, bez potrzeby przechodzenia przez conntrack + mangle + nat + routing. Tak niewiele mniej procesora / pamięci (i to z kolei lekko kompensowane przez fakt, że moduł iptable_raw musi zostać załadowany)
• tylko jedna reguła w przypadku, gdy pudełko jest również routerem (oczywiście nie będzie w porządku dla każdej reguły), ponieważ nie ma potrzeby dodawania tej samej reguły dla filtrowania / przekazywania

Zrobiłem tylko szybkie testy i działa to doskonale.
Dokumentacje, które znalazłem, zawsze opisują surową tabelę, którą należy stosować w ściśle określonych przypadkach. Ale żadne nie podaje nawet najmniejszego uzasadnienia.

Pytanie: czy są jakieś powody, by nie używać surowego stołu, poza dogmatycznymi?

Od człowieka iptables :

raw: This table is used mainly for configuring exemptions from connection
     tracking in combination with the NOTRACK target. It registers at the
     netfilter hooks with higher priority and is thus called before
     ip_conntrack, or any other IP tables.
     It  provides the following built-in chains:

     - PREROUTING (for packets arriving via any network interface)
     - OUTPUT (for packets generated by local processes)

Analiza :

Tak więc tabela RAW znajduje się przed conntrack i została zaprojektowana w celu ustawienia znaku NOTRACK na pakietach, których nie chcesz śledzić w netfilter.

Cele -j nie są ograniczone tylko do NOTRACK, więc tak, możesz filtrować pakiety w surowej tabeli z korzyściami wynikającymi z mniejszego zużycia procesora / pamięci.

Najczęściej serwery nie muszą śledzić wszystkich połączeń. Śledzenie jest potrzebne tylko wtedy, gdy trzeba filtrować pakiety w iptables na podstawie wcześniej ustanowionych połączeń. Na serwerach, które służą tylko prostemu celowi, na przykład z otwartym portem 80 (i może 21), nie wymagają tego. W takich przypadkach możesz wyłączyć śledzenie połączeń.

Jeśli jednak próbujesz uruchomić router NAT, sprawy nieco się skomplikują. Aby coś NAT, musisz śledzić te połączenia, aby móc dostarczać pakiety z sieci zewnętrznej do sieci wewnętrznej.

Jeśli całe połączenie jest ustawione za pomocą NOTRACK, wtedy nie będziesz w stanie śledzić powiązanych połączeń, pomocnicy conntrack i nat po prostu nie będą działać dla nieśledzonych połączeń, ani pokrewne błędy ICMP. Innymi słowy, będziesz musiał otworzyć je ręcznie. Jeśli chodzi o złożone protokoły, takie jak FTP i SCTP i inne, zarządzanie nimi może być bardzo trudne.

Przypadki użycia :

Przykładem może być router o dużym natężeniu ruchu, który ma zaporę sieciową dla ruchu przychodzącego i wychodzącego, ale nie ruch routowany. Następnie można ustawić znak NOTRACK, aby zignorować przesyłany ruch w celu zaoszczędzenia mocy obliczeniowej.

Innym przykładem, w którym można użyć NOTRACK, jest to, że masz bardzo obciążony serwer internetowy, możesz następnie skonfigurować regułę, która włącza śledzenie dla portu 80 na wszystkich lokalnych adresach IP lub tych, które faktycznie obsługują ruch internetowy. Następnie możesz cieszyć się stanowym śledzeniem we wszystkich innych usługach, z wyjątkiem ruchu sieciowego, który może zaoszczędzić trochę mocy obliczeniowej w już przeciążonym systemie.

Przykład -> działający-częściowo-bezstanowy-linux-router-dla-prywatnej sieci

Wniosek : Nie ma silnego powodu, aby nie używać tabeli surowej, ale istnieją pewne powody, dla których należy zachować ostrożność, stosując cel NOTRACK w tabeli surowej.