Hat jemand jemals die Standardregeln der OpenWrt-Firewall überprüft?

7

Ich habe ein Openwrt 10.03.1 installiert von: openwrt-ar71xx-wrt160nl-squashfs-factory.bin (Firewall nur mit diesem angepasst: sed's / REJECT / DROP / g '/ etc / config / firewall) - also außerdem ES IST EINE STANDARD-OFFENE INSTALLATION
Ich habe 3 SSIDs für 3 Clients. Es ist ein WRT160NL.
Es stellt über pppoe eine Verbindung zum Internet her, daher ist pppoe-wan die WAN-Schnittstelle (in Wirklichkeit ist "eth1" die WAN-Schnittstelle, das Kabel ist an diesen Port angeschlossen).
Also habe ich die nächsten Dinge auf Papier ausgedruckt:

iptables-save

root@OPENWRT:~# iptables-save
# Generated by iptables-save v1.4.6 on Wed Nov 21 16:59:23 2012
*nat
:PREROUTING ACCEPT [282:28098]
:POSTROUTING ACCEPT [12:748]
:OUTPUT ACCEPT [170:12487]
:nat_reflection_in - [0:0]
:nat_reflection_out - [0:0]
:postrouting_rule - [0:0]
:prerouting_lan - [0:0]
:prerouting_rule - [0:0]
:prerouting_wan - [0:0]
:zone_lan_nat - [0:0]
:zone_lan_prerouting - [0:0]
:zone_wan_nat - [0:0]
:zone_wan_prerouting - [0:0]
-A PREROUTING -j prerouting_rule 
-A PREROUTING -i br-lan -j zone_lan_prerouting 
-A PREROUTING -i pppoe-wan -j zone_wan_prerouting 
-A POSTROUTING -j postrouting_rule 
-A POSTROUTING -o br-lan -j zone_lan_nat 
-A POSTROUTING -o pppoe-wan -j zone_wan_nat 
-A postrouting_rule -j nat_reflection_out 
-A prerouting_rule -j nat_reflection_in 
-A zone_lan_prerouting -j prerouting_lan 
-A zone_wan_nat -j MASQUERADE 
-A zone_wan_prerouting -j prerouting_wan 
COMMIT
# Completed on Wed Nov 21 16:59:23 2012
# Generated by iptables-save v1.4.6 on Wed Nov 21 16:59:23 2012
*raw
:PREROUTING ACCEPT [88762:5585776]
:OUTPUT ACCEPT [32677:185865297]
:zone_lan_notrack - [0:0]
:zone_wan_notrack - [0:0]
-A PREROUTING -i br-lan -j zone_lan_notrack 
-A PREROUTING -i pppoe-wan -j zone_wan_notrack 
COMMIT
# Completed on Wed Nov 21 16:59:23 2012
# Generated by iptables-save v1.4.6 on Wed Nov 21 16:59:23 2012
*mangle
:PREROUTING ACCEPT [88762:5585776]
:INPUT ACCEPT [86059:4425898]
:FORWARD ACCEPT [2664:1156339]
:OUTPUT ACCEPT [32677:185865297]
:POSTROUTING ACCEPT [35338:187021465]
:zone_wan_MSSFIX - [0:0]
-A FORWARD -j zone_wan_MSSFIX 
-A zone_wan_MSSFIX -o pppoe-wan -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
COMMIT
# Completed on Wed Nov 21 16:59:23 2012
# Generated by iptables-save v1.4.6 on Wed Nov 21 16:59:23 2012
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:forward - [0:0]
:forwarding_lan - [0:0]
:forwarding_rule - [0:0]
:forwarding_wan - [0:0]
:input - [0:0]
:input_lan - [0:0]
:input_rule - [0:0]
:input_wan - [0:0]
:nat_reflection_fwd - [0:0]
:output - [0:0]
:output_rule - [0:0]
:reject - [0:0]
:syn_flood - [0:0]
:zone_lan - [0:0]
:zone_lan_ACCEPT - [0:0]
:zone_lan_DROP - [0:0]
:zone_lan_REJECT - [0:0]
:zone_lan_forward - [0:0]
:zone_wan - [0:0]
:zone_wan_ACCEPT - [0:0]
:zone_wan_DROP - [0:0]
:zone_wan_REJECT - [0:0]
:zone_wan_forward - [0:0]
-A INPUT -m state --state INVALID -j DROP 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j syn_flood 
-A INPUT -j input_rule 
-A INPUT -j input 
-A FORWARD -m state --state INVALID -j DROP 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -j forwarding_rule 
-A FORWARD -j forward 
-A OUTPUT -m state --state INVALID -j DROP 
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -o lo -j ACCEPT 
-A OUTPUT -j output_rule 
-A OUTPUT -j output 
-A forward -i br-lan -j zone_lan_forward 
-A forward -i pppoe-wan -j zone_wan_forward 
-A forwarding_rule -j nat_reflection_fwd 
-A input -i br-lan -j zone_lan 
-A input -i pppoe-wan -j zone_wan 
-A output -j zone_lan_ACCEPT 
-A output -j zone_wan_ACCEPT 
-A reject -p tcp -j REJECT --reject-with tcp-reset 
-A reject -j REJECT --reject-with icmp-port-unreachable 
-A syn_flood -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 25/sec --limit-burst 50 -j RETURN 
-A syn_flood -j DROP 
-A zone_lan -j input_lan 
-A zone_lan -j zone_lan_ACCEPT 
-A zone_lan_ACCEPT -o br-lan -j ACCEPT 
-A zone_lan_ACCEPT -i br-lan -j ACCEPT 
**-A zone_lan_DROP -o br-lan -j DROP**
**-A zone_lan_DROP -i br-lan -j DROP**
**-A zone_lan_REJECT -o br-lan -j reject**
**-A zone_lan_REJECT -i br-lan -j reject**
-A zone_lan_forward -j zone_wan_ACCEPT 
-A zone_lan_forward -j forwarding_lan 
-A zone_lan_forward -j zone_lan_DROP 
-A zone_wan -p udp -m udp --dport 68 -j ACCEPT 
-A zone_wan -p icmp -m icmp --icmp-type 8 -j DROP 
-A zone_wan -j input_wan 
-A zone_wan -j zone_wan_DROP 
-A zone_wan_ACCEPT -o pppoe-wan -j ACCEPT 
-A zone_wan_ACCEPT -i pppoe-wan -j ACCEPT 
-A zone_wan_DROP -o pppoe-wan -j DROP 
-A zone_wan_DROP -i pppoe-wan -j DROP 
-A zone_wan_REJECT -o pppoe-wan -j reject 
-A zone_wan_REJECT -i pppoe-wan -j reject 
-A zone_wan_forward -j forwarding_wan 
-A zone_wan_forward -j zone_wan_DROP 
COMMIT
# Completed on Wed Nov 21 16:59:23 2012
root@OPENWRT:~#

ifconfig

root@OPENWRT:~# ifconfig
br-lan    Link encap:Ethernet  HWaddr AA:AA:AA:AA:AA:AA
      inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:87174 errors:0 dropped:0 overruns:0 frame:0
      TX packets:137186 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:4532245 (4.3 MiB)  TX bytes:192952659 (184.0 MiB)

eth0      Link encap:Ethernet  HWaddr AA:AA:AA:AA:AA:AA
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:0 (0.0 B)  TX bytes:2578 (2.5 KiB)
      Interrupt:4 

eth1      Link encap:Ethernet  HWaddr BB:BB:BB:BB:BB:BB
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:3661 errors:0 dropped:0 overruns:0 frame:0
      TX packets:3447 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:1221049 (1.1 MiB)  TX bytes:224533 (219.2 KiB)
      Interrupt:5 

lo        Link encap:Local Loopback  
      inet addr:127.0.0.1  Mask:255.0.0.0
      UP LOOPBACK RUNNING  MTU:16436  Metric:1
      RX packets:24 errors:0 dropped:0 overruns:0 frame:0
      TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0 
      RX bytes:2088 (2.0 KiB)  TX bytes:2088 (2.0 KiB)

mon.wlan0 Link encap:UNSPEC  HWaddr CC-CC-CC-CC-CC-C1-00-00-00-00-00-00-00-00-00-00  
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:263 errors:0 dropped:0 overruns:0 frame:0
      TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:32 
      RX bytes:20929 (20.4 KiB)  TX bytes:0 (0.0 B)

pppoe-wan Link encap:Point-to-Point Protocol  
      inet addr:1.2.3.4  P-t-P:10.0.0.1  Mask:255.255.255.255
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
      RX packets:1646 errors:0 dropped:0 overruns:0 frame:0
      TX packets:1448 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:3 
      RX bytes:1063783 (1.0 MiB)  TX bytes:132628 (129.5 KiB)

wlan0     Link encap:Ethernet  HWaddr CC:CC:CC:CC:CC:C1
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:32 
      RX bytes:0 (0.0 B)  TX bytes:2850 (2.7 KiB)

wlan0-1   Link encap:Ethernet  HWaddr CC:CC:CC:CC:CC:C2
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:32 
      RX bytes:0 (0.0 B)  TX bytes:2850 (2.7 KiB)

wlan0-2   Link encap:Ethernet  HWaddr CC:CC:CC:CC:CC:C3
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:32 
      RX bytes:0 (0.0 B)  TX bytes:2850 (2.7 KiB)

brctl show

root@OPENWRT:~# brctl show
bridge name bridge id       STP enabled interfaces
br-lan      8000.129ce121c98e   no      eth0
                            wlan0
                            wlan0-1
                            wlan0-2
root@OPENWRT:~#

... und schauen Sie es sich mehrmals genauer an. Ich habe ein paar Dinge gefunden, die ich nicht verstehe:

1)
Diese Regeln sind völlig USELESS, da bin ich mir sicher, daher gibt es diesbezüglich keine wirkliche Frage, zumindest kein "Fixme".
-A zone_lan_DROP -o br-lan -j DROP
-A zone_lan_DROP -i br-lan -j DROP
-A zone_lan_REJECT -o br-lan -j ablehnen
-A zone_lan_REJECT -i br-lan -j ablehnen

2)
Die eigentliche Frage ist ... warum gibt es so viele Tische?
nat_reflection_in, nat_reflection_out, postrouting_rule, prerouting_lan, prerouting_rule, prerouting_wan, zone_lan_nat, zone_lan_prerouting, zone_wan_nat, zone_wan_prerouting, zone_lan, zone_lan_forward, zone_wan, zone_wan,
Könnten die Regeln nicht ohne Tabellen gemacht werden? OpenWrt-Router haben normalerweise eine kleine CPU. Warum komplexe Regeln verwenden? Warum nicht einfacher? Ohne Tische?

3)
... Wenn niemand eine gute Antwort darauf geben kann, warum diese Tabellen benötigt werden ...... dann werde ich afaik alle Regeln usw. spülen und es von Hand tun .. in einer einfacheren Form Weg..

iptables openwrt gasko peter
quelle
Gute Frage oder besser gesagt, guter Punkt. Ich glaube zwar nicht, dass die Komplexität der Regeln einen signifikanten Einfluss auf die CPU hat (ein bisschen Verzweigung, nicht mehr), aber ich bin mehr besorgt über die Auswirkungen, die diese Art von Komplexität auf das Gehirn des Benutzers hat. Zumindest bei mir! :) OpenWrt wird in Heimroutern verwendet, daher sollten die Regeln und Gründe dahinter von Heimanwendern verstanden werden. Aus diesem Grund habe ich Ihre Frage neu formuliert und etwas detaillierter darauf eingegangen.
Lumi

Antworten:

6

1) Diese Regeln sind völlig USELESS, da bin ich mir sicher, daher gibt es keine wirkliche Frage, zumindest keine "Fixme".

Nein, diese Regeln sind nützlich. Ich sage dir warum, wenn du mir sagst, warum du denkst, dass sie nutzlos sind.

Ok, ich mache Witze, ich werde dir sagen, ob du es willst oder nicht. Der Zweck dieser Regeln ist es, das Design einfach zu halten. Die Einfachheit wird nicht an der Anzahl der Regeln gemessen. Es gibt eine Methode für diese Regeln. Jede Tabelle hat einen einfach zu verstehenden Zweck, der sich in ihrem Namen zeigt. Es kommt vor, dass in der Standardkonfiguration einige Tabellen eine einzige Regel haben. Es würde wesentlich komplexeren Code in OpenWRT erfordern, um Einzelregel-Tabellen zu optimieren. Dies würde es einem Systemadministrator auch erschweren, die Regeln zu optimieren, ohne diesen hypothetischen Compiler durchzugehen.

2) Die eigentliche Frage ist ... warum gibt es so viele Tische?

Die Tabellen entsprechen den Funktionen des Firewall-Setups von OpenWRT. Sie könnten weniger Regeln haben, aber dann würden Sie Funktionen verlieren, die für einige Benutzer nützlich sind.

Könnten die Regeln nicht ohne Tabellen gemacht werden? OpenWrt-Router haben normalerweise eine kleine CPU. Warum komplexe Regeln verwenden? Warum nicht einfacher? Ohne Tische?

Sie könnten zweifellos Ihre eigene Konfiguration mit weniger Tabellen vornehmen (wenn Ihre Firewall nicht extrem einfach ist, werden Sie wahrscheinlich einige erstellen). OpenWRT ist flexibler, da es viele Benutzer beherbergt.

Die Anzahl der Regeln hängt nicht von der CPU-Geschwindigkeit oder der RAM-Größe ab. Der Effekt der Anzahl der Tabellen ist ziemlich unkorreliert mit der Zeit, die zum Durchlaufen benötigt wird. Im Gegenteil, mehr Tabellen und weniger Regeln pro Tabelle bedeuten, dass der Pfad, den jedes Paket durchläuft, kürzer ist (ein breiterer Baum hilft) mach es weniger tief). Die Auswirkungen auf den Speicher sind vernachlässigbar: einige hundert Bytes pro Tabelle gegenüber einigen Megabyte RAM.

Gilles 'SO - hör auf böse zu sein'
quelle
2
»Diese Regeln haben eine Methode. Jeder Tisch hat einen einfach zu verstehenden Zweck, der sich in seinem Namen zeigt. «Es ist die Vielzahl der Ketten, die dies für den Neuling (wie mich) verwirrend macht. Ich kann sehen, dass dies ein System ist, in dem Sie Dinge auf bestimmte Weise ablegen sollen. Genau wie würden Sie gehen über das nicht offensichtlich überhaupt. In dieser Hinsicht stimme ich dem OP voll und ganz zu. Wenn Sie zufällig Hinweise auf Beispiele haben, wie Sie in realen Anwendungsfällen in diesem Schema einreichen sollen, würde ich das begrüßen.
Lumi
zone_lan_notrack ist eine, über die ich mich gewundert habe. Es gibt einige, die keinen Sinn ergeben oder einen klaren Zweck haben. Um nicht zu sagen, dass es keinen gibt.
Sneaky Wombat
Es gibt einen Text in deutscher Sprache , der die verschiedenen Ketten des OpenWrt-Paketfilters erklärt. Die in diesem Text verwendeten Diagramme wurden mit dem Perl-Modul App-Iptables2Dot generiert . Vielleicht hilft das, sich einen Überblick zu verschaffen.
Mathias Weidner