[Erledigt] iptables und conntrack

[borgx]

Hallo, ich habe seit längerer Zeit mal wieder iptables ausprobiert und wie in http://freetz.org/wiki/packages/iptables eingerichtet. Es scheint im Wesentlichen wieder zu funktionieren (7270 v2, Firmware: 54.06.05 rev27949 mit Replace-Kernel), wenn ich statt ip_conntrack nf_conntrack lade. Es gibt keine offensichtlichen Lade- oder Absturzprobleme. Sogar Log mit dmesg geht.

Einen Effekt verstehe ich aber nicht. Damit nicht alles sofort kaputt geht, logge ich die eigentlich zu verwerfenden Pakete und lasse sie dann doch durch. Ein normaler state- oder ctstate-RELATED,ESTABLISHED-Match nimmt aber nur etwa 2/3 der erwarteten Pakete an, die anderen würden eigentlich verworfen:

Chain TRANS (1 references)
 pkts bytes target     prot opt in     out     source               destination         
24186 2638K ACCEPT     tcp  --  any    any     192.168.178.0/23     anywhere             multiport dports 20,21,22,25,80,110,143,443,465,993,995,5060
  198 15048 ACCEPT     udp  --  any    any     192.168.178.0/23     anywhere             multiport dports 53,67,68,80,123,5060
    0     0 ACCEPT     icmp --  any    any     192.168.178.0/23     anywhere            
[B]12148[/B] 4690K ACCEPT     all  --  any    any     anywhere             anywhere             ctstate RELATED,ESTABLISHED
 [B]6809[/B]  620K LOG        all  --  any    any     anywhere             anywhere             LOG level warning prefix "[IPT] DENY-LAN-ACCESS "

Im Log sehen die zu verwerfenden Pakete wie normale Mail- oder HTTP-Server-Antworten auf den erwarteten Ports aus. (Die zugehörigen ausgehenden Pakete habe ich auch mal testweise geloggt.)

Hat jemand eine Idee, was da los sein kann oder wie ich das Problem eingrenzen könnte? Kann das ein erwartetes Verhalten sein, weil CONFIG_GENERIC_CONNTRACK gesetzt ist oder müsste es eigentlich funktionieren?

Schonmal danke und beste Grüße

 

[RalfFriedl]

Wenn Du die Pakete an der Stelle blockieren würdest, wären sie weg. Also sind sie entweder wichtig, oder sie sind es nicht. Ein Drittel der Pakete erscheint mir dafür recht viel zu sein.

Wie sehen denn die Pakete aus, die von RELATED,ESTABLISHED nicht angenommen werden?

 

[borgx]

Hier ist ein Log einer Mail-Server-Kommunikation. (Habe für Port 993 noch ein Log eingetragen.) Woran würde ich erkennen, dass das ESTABLISHED sein müsste?

DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=80.**.9.191	        LEN=89	TOS=0x00	PREC=0x00	TTL=63	ID=48507	DF	PROTO=TCP	SPT=59664	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=74.1**.136.109	LEN=83	TOS=0x00	PREC=0x00	TTL=63	ID=393	        DF	PROTO=TCP	SPT=59651	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=74.1**.136.108	LEN=83	TOS=0x00	PREC=0x00	TTL=63	ID=15665	DF	PROTO=TCP	SPT=59662	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=80.**.9.191	        LEN=89	TOS=0x00	PREC=0x00	TTL=63	ID=62982	DF	PROTO=TCP	SPT=59660	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=74.1**.136.108	LEN=83	TOS=0x00	PREC=0x00	TTL=63	ID=38266	DF	PROTO=TCP	SPT=59667	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=80.**.9.191	        LEN=89	TOS=0x00	PREC=0x00	TTL=63	ID=38267	DF	PROTO=TCP	SPT=59663	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=74.1**.136.108	LEN=83	TOS=0x00	PREC=0x00	TTL=63	ID=11219	DF	PROTO=TCP	SPT=59665	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DEBUG-MAIL	IN=lan	OUT=dsl	SRC=192.168.178.36	DST=80.**.9.191	        LEN=89	TOS=0x00	PREC=0x00	TTL=63	ID=37098	DF	PROTO=TCP	SPT=59661	DPT=993	WINDOW=8192	RES=0x00	ACK	PSH	URGP=0
DENY-LAN-ACCESS	IN=dsl	OUT=lan	SRC=74.1**.136.109	DST=192.168.178.36	LEN=52	TOS=0x00	PREC=0x00	TTL=46	ID=33019		PROTO=TCP	SPT=993	DPT=59651	WINDOW=366	RES=0x00	ACK		URGP=0
DENY-LAN-ACCESS	IN=dsl	OUT=lan	SRC=74.1**.136.108	DST=192.168.178.36	LEN=52	TOS=0x00	PREC=0x00	TTL=46	ID=51501		PROTO=TCP	SPT=993	DPT=59662	WINDOW=358	RES=0x00	ACK		URGP=0
DENY-LAN-ACCESS	IN=dsl	OUT=lan	SRC=74.1**.136.108	DST=192.168.178.36	LEN=52	TOS=0x00	PREC=0x00	TTL=46	ID=1981             	PROTO=TCP	SPT=993	DPT=59667	WINDOW=358	RES=0x00	ACK		URGP=0
DENY-LAN-ACCESS	IN=dsl	OUT=lan	SRC=74.1**.136.108	DST=192.168.178.36	LEN=52	TOS=0x00	PREC=0x00	TTL=46	ID=27553		PROTO=TCP	SPT=993	DPT=59665	WINDOW=358	RES=0x00	ACK		URGP=0
DENY-LAN-ACCESS	IN=dsl	OUT=lan	SRC=80.**.9.191	        DST=192.168.178.36	LEN=52	TOS=0x00	PREC=0x00	TTL=51	ID=58973	DF	PROTO=TCP	SPT=993	DPT=59664	WINDOW=62	RES=0x00	ACK		URGP=0

Ähnliche Fälle scheint es auch auf anderen Ports zu geben.

 

[RalfFriedl]

Established erkennst Du daran, dass Log-Target nicht erreicht wird.
Welche Verbindungen bekannt sind, kannst Du in /proc/net/ip_conntrack oder /proc/net/nf_conntrack erkennen, je nach Kernel Version.

 

[JohnDoe42]

@ borgx:

Kurze Nachfrage - kannst Du das Modul nf_nat bauen und/oder laden ?
Falls ja: Was passiert mit (testweise) eingerichteten REDIRECTS ?

 

[borgx]

@ borgx:

Kurze Nachfrage - kannst Du das Modul nf_nat bauen und/oder laden ?
Falls ja: Was passiert mit (testweise) eingerichteten REDIRECTS ?

Bauen und laden geht. Was für ein REDIRECT sollte ich machen, um neue Erkenntnisse zu gewinnen? Einfach hinter

iptables -A TRANS -m state --state RELATED,ESTABLISHED -j ACCEPT

nochmal Port (und Target) ändern?

 

[JohnDoe42]

Was für ein REDIRECT sollte ich machen, um neue Erkenntnisse zu gewinnen?

Z.B. sowas wie

iptables -t nat -A PREROUTING -p tcp -i lan --dport 80 -j REDIRECT --to 8080

Kannst Du bei geladenem nf_nat mal das Ergebnis von lsmod posten ?

Was passiert bei

iptables -t nat -A POSTROUTING -o dsl -j SNAT --to 1.2.3.4

?

P.S.:

Könnte es sein, das Deine Signatur teilweise fehlerhaft ist ?


Router: FB-7270v2 freetz-trunk 54.06.05 rev27949

 

[borgx]

Z.B. sowas wie

iptables -t nat -A PREROUTING -p tcp -i lan --dport 80 -j REDIRECT --to 8080

Das hätte ich so erwartet: im LAN geht Port 80 nicht mehr:

borg@presario:~$ nmap www.ip-phone-forum.de -p 80

Starting Nmap 6.46 ( http://nmap.org ) at 2014-12-02 23:54 CET
Nmap scan report for www.ip-phone-forum.de (176.28.12.60)
Host is up (0.0045s latency).
rDNS record for 176.28.12.60: web1.ip-phone-forum.de
PORT   STATE  SERVICE
80/tcp closed http

Nmap done: 1 IP address (1 host up) scanned in 0.09 seconds
borg@presario:~$

Wenn ich es auf einen Port lege, auf dem die FB antwortet, ist der Port wieder offen.

Kannst Du bei geladenem nf_nat mal das Ergebnis von lsmod posten ?

root@fritz:/var/mod/root# lsmod|sort
Module                  Size  Used by    Tainted: P  
Piglet_noemif          41760  0 
ath_dfs                33216  3 wlan_scan_ap,ath_pci,wlan
ath_hal               276400  6 ath_pci,ath_spectral,ath_rate_atheros,wlan,ath_dfs
ath_pci               131504  0 
ath_rate_atheros       56592  1 ath_pci
ath_spectral           83808  1 ath_pci
avm_ath_extensions     29568  6 wlan_scan_ap,ath_pci,ath_rate_atheros,wlan,ath_dfs,ath_hal
avm_dect              216608  1 dect_io
capi_codec            348944  0 
crc16                    928  1 ext4
dect_io                10192  2 
dsl_ur8               155744  1 
ext4                  217888  0 
fat                    45376  1 vfat
hfsplus                75584  0 
ip_tables              10032  2 iptable_nat,iptable_filter
ipt_LOG                 4976  0 
ipt_REDIRECT             624  1 
ipt_REJECT              1936  0 
iptable_filter           768  0 
iptable_nat             2352  1 
isdn_fbox_fon5        729904  6 
jbd2                   46704  1 ext4
kdsldmod             1065632  9 userman_mod
led_modul_Fritz_Box_7270_16    66496  8 
lzo_compress            1664  1 ramzswap
lzo_decompress          1824  1 ramzswap
nf_conntrack           47344  6 iptable_nat,nf_nat,nf_conntrack_ftp,nf_conntrack_ipv4,xt_conntrack,xt_state
nf_conntrack_ftp        4624  0 
nf_conntrack_ipv4       7936  3 iptable_nat,nf_nat
nf_defrag_ipv4           608  1 nf_conntrack_ipv4
nf_nat                 11232  2 ipt_REDIRECT,iptable_nat
pcmlink               276400  4 avm_dect,capi_codec,isdn_fbox_fon5
ramzswap               14336  1 
reiserfs              220976  0 
rtc_avm                 3488  1 pcmlink
rtc_core               11232  1 rtc_avm
sch_llq                 7152  1 
sch_sfq                 4480  4 
sch_tbf                 3584  1 
userman_mod            47680  4 
vfat                    8528  1 
wlan                  175712  9 wlan_scan_ap,wlan_acl,wlan_wep,wlan_tkip,wlan_ccmp,wlan_xauth,ath_pci,ath_rate_atheros
wlan_acl                2592  2 
wlan_ccmp               5456  6 
wlan_scan_ap            6864  1 
wlan_tkip               8752  4 
wlan_wep                3792  0 
wlan_xauth               400  0 
x_tables               10192  9 ipt_REDIRECT,iptable_nat,xt_conntrack,xt_state,xt_multiport,ipt_REJECT,ipt_LOG,xt_tcpudp,ip_tables
xt_conntrack            1728  0 
xt_multiport            1872  0 
xt_state                 752  0 
xt_tcpudp               1776  1 
root@fritz:/var/mod/root#

Ich hatte vorsorglich alles mögliche geladen. Die ipt_REDIRECT-Abhängigkeit kommt aber durch das REDIRECT neu dazu.

Was passiert bei

iptables -t nat -A POSTROUTING -o dsl -j SNAT --to 1.2.3.4

?

Laden einer Mini-Seite, Ausgabe von tcpdump -i dsl

00:30:39.731195 IP 1.2.3.4.35550 > tinuviel.miswebdesign.co.uk.80: Flags [S], seq 2452356691, win 29200, options [mss 1460,sackOK,TS val 13753121 ecr 0,nop,wscale 7], length 0
00:30:39.765054 IP tinuviel.miswebdesign.co.uk.80 > 1.2.3.4.35550: Flags [S.], seq 677867513, ack 2452356692, win 5792, options [mss 1380,sackOK,TS val 2248057303 ecr 13753121,nop,wscale 7], length 0
00:30:39.767791 IP 1.2.3.4.35550 > tinuviel.miswebdesign.co.uk.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 13753158 ecr 2248057303], length 0
00:30:39.768747 IP 1.2.3.4.35550 > tinuviel.miswebdesign.co.uk.80: Flags [P.], seq 1:561, ack 1, win 229, options [nop,nop,TS val 13753158 ecr 2248057303], length 560
00:30:39.809519 IP tinuviel.miswebdesign.co.uk.80 > 1.2.3.4.35550: Flags [.], ack 561, win 54, options [nop,nop,TS val 2248057348 ecr 13753158], length 0
00:30:39.812608 IP onario.fritz.box.35550 > tinuviel.miswebdesign.co.uk.80: Flags [.], ack 677867690, win 237, options [nop,nop,TS val 13753203 ecr 2248057349], length 0

Ich kann hier nichts besonderes erkennen, es steht halt eine falsche lokale Absenderadresse drin. (Warum in der letzten Zeile der Original-lokale-Absender steht, verstehe ich dann aber doch nicht.)

Es ist aber klar, dass ich trotz nf_nat das AVM-NAT verwende, oder? (DSL <—> AVM-Firewall (NAT) <—> iptablesFirewall <—> LAN)

P.S.:

Könnte es sein, das Deine Signatur teilweise fehlerhaft ist ?


Router: FB-7270v2 freetz-trunk 54.06.05 rev27949

Oh ja, natürlich. Hier mal ein neuer Versuch.

Und schon mal danke für die Hinweise!

 

[JohnDoe42]

Das hätte ich so erwartet: im LAN geht Port 80 nicht mehr

Das ist auch nicht weiter verwunderlich - die Zugriffe aus dem LAN ins WAN auf Port(s) 80 werden ja mittels REDIRECT auf Port 8080 umgelenkt. Und scheinbar antwortet unser Forum auf dem Port nicht. Das Ganze diente dazu herauszufinden, ob die Box mit dieser Regel und geladenem nf_nat rebootet, wenn Pakete dieser Regel entsprechend von nf_nat bearbeitet werden.

Es ist aber klar, dass ich trotz nf_nat das AVM-NAT verwende, oder? (DSL <—> AVM-Firewall (NAT) <—> iptablesFirewall <—> LAN)

Wenn Du mittels nf_conntrack, nf_nat usw. die beiden von mir genannten Regeln lädst, verwendest Du sicher kein AVM-NAT. NAT macht AVM mittels des dsld's (s. z.B. hier).

Kannst Du mal mit meinen genannten Regeln die Ausgabe von

iptables -nvL

posten ?

 

[borgx]

Das ist auch nicht weiter verwunderlich - die Zugriffe aus dem LAN ins WAN auf Port(s) 80 werden ja mittels REDIRECT auf Port 8080 umgelenkt. Und scheinbar antwortet unser Forum auf dem Port nicht.

Ich verstehe es so, dass die Anfrage auf Port 8080 der Fritzbox selbst umgeleitet wird. (Ich habe es zum Vergleich mit einem auf der Fritzbox offenen anderen Port probiert.)

Kannst Du mal mit meinen genannten Regeln die Ausgabe von

iptables -nvL

posten ?

root@fritz:/var/mod/root# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  *      *       0.0.0.0              255.255.255.255      udp spt:68 dpt:67
   44  4055 ACCEPT     all  --  *      *       127.0.0.1            127.0.0.1           
  728 55185 ACCEPT     all  --  *      *       192.168.178.0/23     0.0.0.0/0           
    0     0 ACCEPT     all  --  lan    *       169.254.0.0/16       0.0.0.0/0           
   25  3470 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5060
    2    64 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:5060
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:54234
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:54234
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "[IPT] DENY-FRITZ-ACCESS "

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  930  267K TRANS      all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  610 81028 ACCEPT     all  --  *      *       0.0.0.0/0            192.168.178.0/23    
    1    36 ACCEPT     all  --  *      *       0.0.0.0/0            224.0.0.0/24        
   15  4845 ACCEPT     all  --  *      *       0.0.0.0/0            239.255.255.250     
   44  4055 ACCEPT     all  --  *      *       0.0.0.0/0            127.0.0.1           
   25  1598 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 53,123,5060
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:5060
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            63.208.196.0/24      tcp dpt:80
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            212.42.244.73        tcp dpt:80
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "[IPT] WARNING-CALL-HOME "

Chain TRANS (1 references)
 pkts bytes target     prot opt in     out     source               destination         
  467 43949 ACCEPT     tcp  --  *      *       192.168.178.0/23     0.0.0.0/0           
    9   684 ACCEPT     udp  --  *      *       192.168.178.0/23     0.0.0.0/0           
    0     0 ACCEPT     icmp --  *      *       192.168.178.0/23     0.0.0.0/0           
  266  205K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  188 16755 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "[IPT] DENY-LAN-ACCESS "
  188 16755 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           
borg@presario:~$

oder meintest du

root@fritz:/var/mod/root# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 133 packets, 11900 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  400 24000 REDIRECT   tcp  --  lan    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 8080

Chain POSTROUTING (policy ACCEPT 27 packets, 2490 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   89  8474 SNAT       all  --  *      dsl     0.0.0.0/0            0.0.0.0/0            to:1.2.3.4

Chain OUTPUT (policy ACCEPT 29 packets, 2621 bytes)
 pkts bytes target     prot opt in     out     source               destination         
root@fritz:/var/mod/root#

 

[JohnDoe42]

Ich verstehe es so, dass die Anfrage auf Port 8080 der Fritzbox selbst umgeleitet wird.

Okay, ganz richtig hätte ich schreiben sollen

iptables -t nat -A PREROUTING -p tcp -i lan -o dsl --dport 80 -j REDIRECT --to 8080

Wobei es in Deinem Fall egal war/ist: Du versuchst, auf eine Internet-(WAN-)Seite auf Port 80 zuzugreifen - dieser Zugriff wird redirected auf Port 8080.
Wobei Du mit meiner ersten, fehlerbehafteten Regel Recht hast: Auch der Zugriff auf Port 80 der Box selbst wird auf Port 8080 umgebogen. Und dieser scheint in Deinem Fall geschlossen zu sein.
Oft wird diese Regel angewendet, um transparente Proxys zu verwenden.

oder meintest du

Das meinte ich.

Wichtig ist, daß das Modul geladen wird, funktioniert und die Box nicht rebootet.

 

[borgx]

Wichtig ist, daß das Modul geladen wird, funktioniert und die Box nicht rebootet.

Mist, nach etwa einer Stunde hat sie dann doch rebootet. Das REDIRECT und SNAT hatte ich schon vorher abgeschaltet, weil ich ein Internet brauchte.

 

[JohnDoe42]

Hast Du noch Logs für den Vorgang ?
Kannst Du die REDIRECT-Regel mal mit einer Umleitung von Port 80 auf Port 443 über nacht laufen lassen und gucken, ob das stabil funktioniert ?

 

[borgx]

Hast Du noch Logs für den Vorgang ?

Syslog habe ich. Hier ist die letzte Minute (notdürftig manuell anonymisiert). Verdächtige Einträge: nf_conntrack: table full, dropping packet....

Dec  3 21:20:43 fritz daemon.info hostapd: ath0: STA 00:26:5e:**:**:35 IEEE 802.11: associated
Dec  3 21:20:43 fritz daemon.info hostapd: ath0: STA 00:26:5e:**:**:35 WPA: pairwise key handshake completed (RSN)
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=80 DPT=59572 WINDOW=14480 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=74.1**.136.16 DST=192.168.178.21 LEN=40 TOS=0x00 PREC=0x00 TTL=47 ID=22481 PROTO=TCP SPT=993 DPT=34760 WINDOW=0 RES=0x00 RST URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=guest SRC=74.1**.206.94 DST=192.168.179.32 LEN=52 TOS=0x00 PREC=0x00 TTL=45 ID=45421 PROTO=TCP SPT=80 DPT=33833 WINDOW=344 RES=0x00 ACK URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=212.2**.15.171 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=993 DPT=45220 WINDOW=14480 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=guest SRC=74.1**.206.94 DST=192.168.179.32 LEN=382 TOS=0x00 PREC=0x00 TTL=45 ID=45422 PROTO=TCP SPT=80 DPT=33833 WINDOW=344 RES=0x00 ACK PSH URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=74.1*.136.108 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=24097 PROTO=TCP SPT=993 DPT=34482 WINDOW=42540 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=212.2**.15.171 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=55 ID=53609 DF PROTO=TCP SPT=993 DPT=45220 WINDOW=31 RES=0x00 ACK URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=74.1**.136.108 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=47 ID=24098 PROTO=TCP SPT=993 DPT=34482 WINDOW=341 RES=0x00 ACK URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=89.2**.90.114 DST=192.168.178.21 LEN=56 TOS=0x00 PREC=0xC0 TTL=63 ID=22920 PROTO=ICMP TYPE=3 CODE=13 [SRC=192.168.178.21 DST=89.245.90.114 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=22920 DF PRO
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=80 DPT=59581 WINDOW=14480 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: nf_conntrack: table full, dropping packet.
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=0 DF PROTO=TCP SPT=80 DPT=59586 WINDOW=14480 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: nf_conntrack: table full, dropping packet.
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=74.1**.136.95 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=52507 PROTO=TCP SPT=80 DPT=42750 WINDOW=42540 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=19569 DF PROTO=TCP SPT=80 DPT=59581 WINDOW=126 RES=0x00 ACK URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=13116 DF PROTO=TCP SPT=80 DPT=59586 WINDOW=126 RES=0x00 ACK URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=guest SRC=74.1**.206.94 DST=192.168.179.32 LEN=382 TOS=0x00 PREC=0x00 TTL=45 ID=45423 PROTO=TCP SPT=80 DPT=33833 WINDOW=356 RES=0x00 ACK PSH URGP=0 
Dec  3 21:20:55 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=194.**.41.23 DST=192.168.178.21 LEN=133 TOS=0x00 PREC=0x00 TTL=117 ID=6702 DF PROTO=TCP SPT=110 DPT=48877 WINDOW=517 RES=0x00 ACK PSH URGP=0 
Dec  3 21:20:56 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=23.**.43.27 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=11102 DF PROTO=TCP SPT=80 DPT=48918 WINDOW=486 RES=0x00 ACK URGP=0 
Dec  3 21:20:56 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=194.**.41.23 DST=192.168.178.21 LEN=79 TOS=0x00 PREC=0x00 TTL=117 ID=6776 DF PROTO=TCP SPT=110 DPT=48877 WINDOW=517 RES=0x00 ACK PSH URGP=0 
Dec  3 21:20:56 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=guest SRC=74.1**.136.154 DST=192.168.179.32 LEN=1470 TOS=0x00 PREC=0x00 TTL=47 ID=50392 PROTO=TCP SPT=80 DPT=38176 WINDOW=353 RES=0x00 ACK URGP=0 
Dec  3 21:20:56 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=194.**.41.23 DST=192.168.178.21 LEN=1492 TOS=0x00 PREC=0x00 TTL=117 ID=6995 DF PROTO=TCP SPT=110 DPT=48877 WINDOW=516 RES=0x00 ACK URGP=0 
Dec  3 21:20:56 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=192.2**.241.200 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=0 DF PROTO=TCP SPT=80 DPT=54261 WINDOW=14480 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:56 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=74.1**.136.139 DST=192.168.178.21 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=23780 PROTO=TCP SPT=80 DPT=45170 WINDOW=42540 RES=0x00 ACK SYN URGP=0 
Dec  3 21:20:57 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=194.**.41.23 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=8746 DF PROTO=TCP SPT=110 DPT=48877 WINDOW=514 RES=0x00 ACK FIN URGP=0 
Dec  3 21:20:57 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=194.**.41.23 DST=192.168.178.21 LEN=40 TOS=0x00 PREC=0x00 TTL=117 ID=8985 DF PROTO=TCP SPT=110 DPT=48877 WINDOW=0 RES=0x00 ACK RST URGP=0 
Dec  3 21:21:00 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=guest SRC=74.1**.136.154 DST=192.168.179.32 LEN=52 TOS=0x00 PREC=0x00 TTL=47 ID=32063 PROTO=TCP SPT=80 DPT=35794 WINDOW=399 RES=0x00 ACK URGP=0 
Dec  3 21:21:01 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=55283 DF PROTO=TCP SPT=80 DPT=59580 WINDOW=195 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:01 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=19576 DF PROTO=TCP SPT=80 DPT=59581 WINDOW=199 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:01 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=74.1**.136.95 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=47 ID=52613 PROTO=TCP SPT=80 DPT=42750 WINDOW=333 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:01 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=19577 DF PROTO=TCP SPT=80 DPT=59581 WINDOW=199 RES=0x00 ACK URGP=0 
Dec  3 21:21:01 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=55284 DF PROTO=TCP SPT=80 DPT=59580 WINDOW=195 RES=0x00 ACK URGP=0 
Dec  3 21:21:01 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=192.2**.241.200 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=47 ID=22439 DF PROTO=TCP SPT=80 DPT=54261 WINDOW=227 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:01 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=13124 DF PROTO=TCP SPT=80 DPT=59586 WINDOW=212 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:02 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=13125 DF PROTO=TCP SPT=80 DPT=59586 WINDOW=212 RES=0x00 ACK URGP=0 
Dec  3 21:21:02 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=38078 DF PROTO=TCP SPT=80 DPT=59578 WINDOW=226 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:02 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=61231 DF PROTO=TCP SPT=80 DPT=59579 WINDOW=228 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:02 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=38079 DF PROTO=TCP SPT=80 DPT=59578 WINDOW=226 RES=0x00 ACK URGP=0 
Dec  3 21:21:02 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=61232 DF PROTO=TCP SPT=80 DPT=59579 WINDOW=228 RES=0x00 ACK URGP=0 
Dec  3 21:21:02 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=16218 DF PROTO=TCP SPT=80 DPT=59572 WINDOW=304 RES=0x00 ACK FIN URGP=0 
Dec  3 21:21:02 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=lan SRC=176.**.12.60 DST=192.168.178.21 LEN=52 TOS=0x00 PREC=0x00 TTL=54 ID=16219 DF PROTO=TCP SPT=80 DPT=59572 WINDOW=304 RES=0x00 ACK URGP=0 
Dec  3 21:21:05 fritz kern.warn kernel: [IPT] DENY-LAN-ACCESS IN=dsl OUT=guest SRC=208.**.122.147 DST=192.168.179.32 LEN=52 TOS=0x00 PREC=0x00 TTL=52 ID=55884 DF PROTO=TCP SPT=443 DPT=46065 WINDOW=514 RES=0x00 ACK URGP=0 
Dec  3 21:23:53 fritz syslog.info syslogd started: BusyBox v1.22.1

Kannst Du die REDIRECT-Regel mal mit einer Umleitung von Port 80 auf Port 443 über nacht laufen lassen und gucken, ob das stabil funktioniert ?

Probiere ich mal.

 

[JohnDoe42]

Verdächtige Einträge: nf_conntrack: table full, dropping packet....

Das dürfte eigentlich nicht zum Reboot führen. Wie dort zu lesen: Die Liste ist voll, die nächsten Pakete werden gedropt.
Wie man das ändern kann, s. u. A. hier.
Verdächtige Einträge, die bisher bei Verwendung von iptables zu Reboots geführt haben, haben z.B. sk_buff zum Gegenstand.

 

[borgx]

Verdächtige Einträge, die bisher bei Verwendung von iptables zu Reboots geführt haben, haben z.B. sk_buff zum Gegenstand.

Oje, ich sehe gerade:

Dec  3 21:23:54 fritz kern.warn kernel: nf_conntrack version 0.5.0 (938 buckets, 3752 max)
Dec  3 21:23:54 fritz kern.warn kernel: CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
Dec  3 21:23:54 fritz kern.warn kernel: nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
Dec  3 21:23:54 fritz kern.warn kernel: sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
Dec  3 21:23:54 fritz kern.info kernel: ramzswap: /dev/ramzswap0 initialized: disksize_kb=8192
Dec  3 21:23:54 fritz kern.info kernel: Adding 8184k swap on /dev/ramzswap0.  Priority:-1 extents:1 across:8184k SS
Dec  3 21:23:54 fritz kern.err kernel: [dsl_ur8] Loading Linux DSL Driver done
Dec  3 21:23:54 fritz kern.debug kernel: [dsl_ur8] DDA_dsl_avm_event_notify: Unbekanntes Event: 13!
Dec  3 21:23:54 fritz kern.debug kernel: [dsl_ur8] DDA_dsl_avm_event_notify: Unbekanntes Event: 13!
Dec  3 21:23:54 fritz kern.info kernel: Adding 65528k swap on /var/media/ftp/UStor01/swapfile.  Priority:-2 extents:1 across:65528k 
Dec  3 21:23:54 fritz kern.info kernel: kdsldmod: init start (Apr 30 2014 17:29:15) [B]sizeof(struct sk_buff)=440[/B]
Dec  3 21:23:54 fritz kern.info kernel: userman: device registerd (userman_url) with major=241
[...]
Dec  3 21:23:53 fritz kern.err kernel: [cpmac] Version: 1.108.1.133 - Revision 811:2535 - Do 27.03.2014 16:13:29
Dec  3 21:23:53 fritz kern.info kernel: cpmac: compiled with [B]sizeof(struct sk_buff) = 448[/B]

Nicht-passende struct-Größe kann doch kaum gutgehen? Ansonsten taucht sk_buff aber nicht im Log auf.

 

[borgx]

Kannst Du die REDIRECT-Regel mal mit einer Umleitung von Port 80 auf Port 443 über nacht laufen lassen und gucken, ob das stabil funktioniert ?

Ok. Über Nacht einfach so abstürzen tut sie nicht:

root@fritz:/var/mod/root# uptime
 06:32:50 up  9:10,  load average: 0.23, 0.11, 0.03
root@fritz:/var/mod/root# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 1167 packets, 177K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   47  2844 REDIRECT   tcp  --  lan    *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 443

Chain POSTROUTING (policy ACCEPT 694 packets, 105K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 508 packets, 89412 bytes)
 pkts bytes target     prot opt in     out     source               destination         
root@fritz:/var/mod/root#

Das war jetzt ohne SNAT und ohne Filter.
Auf Port 443 antwortet meine FB allerdings genausowenig wie auf 8080.

 

[JohnDoe42]

Ich meinte auch sowas:

iptables -t nat -A PREROUTING -p tcp -i lan -o dsl --dport 80 -j REDIRECT --to 443

Die Reboots passieren oft, wenn Pakete zwischen Box und WAN geroutet werden (sollen).
Kannst Du versuchen, das Logging auf einen Stick auszulagern, um so die Zeit vor dem Reboot analysieren zu können ? In den Logs aus #14 ist für mich keine Rebootursache auszumachen.

 

[borgx]

Ich meinte auch sowas:

iptables -t nat -A PREROUTING -p tcp -i lan -o dsl --dport 80 -j REDIRECT --to 443

Das habe ich bis auf "-o dsl" gemacht. Ich dachte, nur die Ketten OUTPUT, FORWARD und POSTROUTING haben eine Output-Schnittstelle. Mir ist nicht ganz klar, was da passieren soll.

Kannst Du versuchen, das Logging auf einen Stick auszulagern, um so die Zeit vor dem Reboot analysieren zu können ? In den Logs aus #14 ist für mich keine Rebootursache auszumachen.

Das ist das normale Freetz-Syslog und es ist auf einem Stick. Ist bekannt, ob Log-Daten beim Reboot typischerweise verloren gehen, weil z.B. die Log-Datei nicht richtig geflusht wird?

 

[JohnDoe42]

Du solltest Dir mal die Doku zu netfilter durchlesen. Der -o-Schalter bestimmt den Filter für das Output-Device, sprich: die konkrete Regel wird verwendet, wenn Pakete in Richtung Output-Device geroutet werden. Im von mir erwähnten Fall ins WAN (via DSL).

Beim Absturz einer Box können im Log Einträge auf einem externen Medium verloren gehen, je nachdem, ob der Prozess noch dazu kommt, etwas zu schreiben. Aus Deinen Logs oben läßt sich jedenfall überhaupt nicht ersehen, warum die Box rebootet.