Firewall-Rules auf LAN-Port binden

[hobu]

Hallo!

Meine 7170 betreibe ich erfolgreich als Router hinter einem Alice-Modem.
Auf den Webseiten von AVM habe ich nun aber gelesen, dass im Routerbetrieb kein Schutz durch die interne FW mehr vorhanden ist.
Sprich: Die FW-Rules werden nur auf das DSL, bzw. Internet-Interface gebunden.
Quelle: http://www.avm.de/de/Service/Servic...eitsfunktionen_fbox.php?portal=FRITZ!Box_7170

Ich hab' mir mal die ar7.cfg angeschaut, um die Rules vomn DSL- (der ja eh' brach liegt) auf den LAN0-Port "umzubiegen".
Wir unschwer zu erahnen: Ohne Eure Hilfe bekomme ich's nicht hin...

Hat das hier schon mal jemand praktiziert (sofern das überhaupt geht) und kann mir ein paar sachdienliche Tipps geben?
Wenn's hilft, hänge ich hier auch gerne noch einen Auszug der ar7.cfg an.

Danke im Voraus!

 

[hagalabimbo]

Sprich: Die FW-Rules werden nur auf das DSL, bzw. Internet-Interface gebunden.
Quelle: http://www.avm.de/de/Service/Servic...eitsfunktionen_fbox.php?portal=FRITZ!Box_7170

Ich kann in dieser Quelle leider nichts finden, was diese Aussage untermauern würde. Ist das sicher der richtige Link?

 

[andilao]

Das hast Du zum Glück falsch verstanden, denn erst "Im Betrieb als DSL-Modem" (nicht mit einem DSL-Modem) ist die NAT-FW selbstverständlich aus. Im LAN1-Routerbetrieb wird der LAN- zum WAN-Port und die NAT-FW funktioniert so wie über DSL. Ausnahmen (Seriennummern) sind bei AVM dokumentiert, diese 7170 lassen sich dann aber auch per Firmware nicht als LAN1-Router umkonfigurieren.

 

[hobu]

Erstmal Danke für die schnellen Antworten.

Hm... Es gibt noch einen anderen Link, auf den ich meine Aussage stütze.
Aber wie immer: Wenn man was erneut sucht, findet's man ehemals Gefundene nicht...

@andilao:
Die S/N-Problematik ist bekannt, deswegen musste ich "damals" meine alte 7170 auch gg. eine neue auswechseln, damit ich diese dann auch als Router nutzen kann. Dass die FW nicht auf LAN0 aktiv ist (und daher auch mein Gedanke, dass ich in der ar7.cfg eine Änderung vornehmen muss) begründet sich darin, dass ich hier im Log der nativen Win7-FW externe IP-Adressen sehe.

Beispiel:

#Fields: date time action protocol [COLOR="#FF0000"]src-ip[/COLOR] dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2012-09-05 17:37:10 DROP TCP[COLOR="#FF0000"] 69.195.141.178[/COLOR] 192.168.x.x 443 53789 40 FA 3426301053 3402556721 71 - - - RECEIVE
2012-09-05 18:00:07 DROP TCP 212.227.17.185 192.168.x.x 995 55028 40 FA 2577422303 701748785 16 - - - RECEIVE
2012-09-05 18:50:11 DROP TCP 66.135.210.100 192.168.x.x 80 56809 40 A 2618200369 1470659418 4968 - - - RECEIVE

Wenn der Paketfilter auf der Fritz aktiv wäre, dürften die Pakete dich gar nicht bis zum PC durchkommen. Das lokale Netz (Fritz & Rest) hat doch 'ne RFC1918-Adresse. Oder mach' ich hier einen Denkfehler?

Wie kann ich mir die Rules auf der FB anzeigen lassen?
Mit iptables unter Linux bin ich firm, aber unter Busybox guck' ich hier wie ein Schwein ins Uhrwerk: iptables gibt's (in der Form) scheinbar nicht.

 

[sf3978]

Wenn der Paketfilter auf der Fritz aktiv wäre, dürften die Pakete dich gar nicht bis zum PC durchkommen. Das lokale Netz (Fritz & Rest) hat doch 'ne RFC1918-Adresse. Oder mach' ich hier einen Denkfehler?
Wie kann ich mir die Rules auf der FB anzeigen lassen?

Mit vi oder FBeditor. Z. B. aus der ar7.cfg:

dsldpconfig {
                        security = dpsec_firewall;
                        lowinput {
                                policy = "permit";
                                accesslist = 
                                             "deny ip any 242.0.0.0 255.0.0.0", 
                                             "deny ip any host 255.255.255.255";
                        }
                        lowoutput {
                                policy = "permit";
                        }
                        highinput {
                                policy = "permit";
                        }
                        highoutput {
                                policy = "permit";
                                accesslist = 
                                             "reject ip any 242.0.0.0 255.0.0.0", 
                                             "deny ip any host 255.255.255.255", 
                                             "reject ip any 169.254.0.0 255.255.0.0";
                        }
		      forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060";
                }

 

[hobu]

Mit vi oder FBeditor. Z. B. aus der ar7.cfg:

Schon klar...
Ich dachte eher an ein Pendant zu "iptables -L -v".

 

[sf3978]

... ein Pendant zu "iptables -L -v".

cat /var/flash/ar7.cfg | sed -n '/lowinput/,/}/p'

 

[hobu]

cat /var/flash/ar7.cfg | sed -n '/lowinput/,/}/p'

Entweder habe ich mich falsch ausgedrückt oder Du willst mich nicht verstehen:
Ich suche nicht die ACL-Angaben in der Config, sondern wie die Rules 'live' auf den Interfaces aussehen.
Wenn es in der FB kein echtes Binär-Pendant zu iptables gibt, dann sag das doch einfach.

 

[gt40]

Wenn der Paketfilter auf der Fritz aktiv wäre, dürften die Pakete dich gar nicht bis zum PC durchkommen. Das lokale Netz (Fritz & Rest) hat doch 'ne RFC1918-Adresse. Oder mach' ich hier einen Denkfehler?

Ja, Du machst einen Denkfehler, natürlich kommen die Source Adressen von Paketen, die du im Internet angefordert hast bis zu Deinem Rechner. Oder was meinst Du was Du mit www.ip-phone-forum.de aufrufst?
66.135.210.100 ist übrigens ebay, ich glaube nicht, daß die gerade einen Angriff auf Dich vorbereiten.

 

[andilao]

Prinzipell dürften keine verworfenen Pakete angefordert worden sein, außer z.B. verspätete, wenn der Port noch offen war und die Quelle stimmte. Gegenstimmen? Andere Szenarien?

So bei mir:

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2012-09-14 01:00:01 DROP UDP 65.55.21.21 192.168.178.178 123 123 76 - - - - - - - RECEIVE

65.55.21.21 = time.windows.com

 

[gt40]

Weiter oben handelt es sich um TCP Pakete die in zwei Fällen eindeutig von Web Servern stammen (80 und 443), die kommen nicht einfach so. Im Beispiel mit time.windows.com ist es ein verbindungloses UDP Paket. Ich tippe mal eher ein manuelles Zerkonfigurieren des Windows Paketfilters.

 

[andilao]

Bei mir sind 2 neue DROPs im Log, und zwar exakt aus der Zeit des Firmware-Downloads vom AVP-FTP-Server durch das ruKernelTool:
2012-09-16 10:45:34 DROP TCP 212.42.244.77 192.168.178.178 20 1349 60 S 346805628 0 5840 - - - RECEIVE
2012-09-16 10:45:37 DROP TCP 212.42.244.77 192.168.178.178 20 1349 60 S 346805628 0 5840 - - - RECEIVE

Für mich wären mögliche Ursachen:
- Win-FW ist schneller wieder zu als die Box-FW.
- Win-FW verwirft "malformed" Pakete.
Und nein, die FW ist bei mir noch nicht "zerkonfiguriert", nur die private "Datei- und Druckerfreigabe" habe ich für VPN erweitert auf 192.168.0.0.

Wie soll "manuelles Zerkonfigurieren des Windows Paketfilters" nach dem Log von hobu passiert sein, mit der Regel "Jedes 5.762.113.445ste Paket verwerfen, aber zufällig"? ;-)

 

[gt40]

- Win-FW ist schneller wieder zu als die Box-FW.

Oder deren Connection Tracking ist kaputt...

Und nein, die FW ist bei mir noch nicht "zerkonfiguriert"

Und warum "droppst" Du dann ntp Pakete, statt den ntp Dienst auf Deinem System, den Du ja anscheinend nicht brauchst, zu deaktivieren ;-)