Aktuelles Strech, nf_conntrack_ftp funktioniert nicht

[Heiko Schlittermann]

Hallo,

ich habe auf einer Firewall ein aktuelles Stretch,
der Kernel sieht so aus:

$ uname -a
Linux tigger-a 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64 GNU/Linux

$ modinfo nf_conntrack_ftp
filename: /lib/modules/4.9.0-4-amd64/kernel/net/netfilter/nf_conntrack_ftp.ko
alias: nfct-helper-ftp
alias: ip_conntrack_ftp
description: ftp connection tracking helper
author: Rusty Russell <ru...@rustcorp.com.au>
license: GPL
depends: nf_conntrack
intree: Y
vermagic: 4.9.0-4-amd64 SMP mod_unload modversions
parm: ports:array of ushort
parm: loose:bool

Hinter dieser Firewall steht ein FTP-Server. Die relevanten
Firewallrules habe ich versucht, so isolieren:

iptables -I FORWARD -s x.x.x.x -j testing

Chain testing (1 references)
pkts bytes target prot opt in out source destination
75 4628 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
6 340 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
5 300 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable


Damit sollte FTP eigentlich gehen. Früher ging es auch (aber da war
diese Regel noch nicht drin, sondern etwas komplexere Regeln.)

Vermutlich seit dem letzten Reboot (Kernel-Update?) geht das
Connection-Tracking für das FTP nicht mehr. (Ähnliche Symptome habe ich
mit Clients hinter einer aktuellen Stretch-Firewall, aber den o.a.
Test habe ich von einem anderen Host mit einer öffentlichen Adresse
gemacht.) Es ist also kein NAT im Spiel.

Es sieht schlicht so aus, als wenn der Port, den der FTP-Server öffnet,
nicht in der Firewall durch „RELATED“ abgedeckt wird:

---> USER www.sempa.de
<--- 331 Password required for www.sempa.de
---> PASS XXXX
<--- 230 User www.sempa.de logged in
---> PWD
<--- 257 "/" is the current directory
---> EPSV
<--- 229 Entering Extended Passive Mode (|||15278|)
---- Connecting data socket to (212.80.235.133) port 15278
**** Data socket error (Connection refused) - reconnecting

Im Passive Mode (Also nur PASV, nicht EPSV) ist es vergleichbar.

Nun habe ich
https://lists.debian.org/debian-kernel/2017/08/msg00006.html
gefunden, da steht im Follow-Up, daß das gelöst wäre.

Kenn jemand das eine oder das andere bestätigen?

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -

[Heiko Schlittermann]

Heiko Schlittermann <h...@schlittermann.de> (Di 24 Okt 2017 15:11:33 CEST):
> Hallo,
…

> Nun habe ich
> https://lists.debian.org/debian-kernel/2017/08/msg00006.html
> gefunden, da steht im Follow-Up, daß das gelöst wäre.

Und wenn man das bis zum Ende liest, dann findet man
z.B. https://home.regit.org/netfilter-en/secure-use-of-helpers/
Und damit ist das gelöst.

--
Heiko