Hallo Leute!
Auf einem Debian 11 Server ist Proftp installiert. In sich funktioniert das Programm problemlos. Sobald aber die Firewall (iptables) eingeschaltet wird, ist FTP nicht mehr zu nutzen.
Ich habe bereits die Regel
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -m comment --comment "Connection tracking"
hinzugefügt und das Modul nf_conntrack_ftp ist auch geladen.
Ich bin 100% sicher, dass als das System noch mit Debian 10 lief, funktionierte das FTP einwandfrei.
Hat jemand eine Ahnung, was geändert wurde und wie ich das Problem lösen kann?
Besten Dank Luca Bertoncello (lucabert@lucabert.de)
Am 12.12.2023 um 22:15 schrieb Ronny Seffner:
Moin!
FTP aktiv oder passiv? Platin oder mit SSL. Was genau heißt "geht nicht"
- kein Banner, kein Login oder "nur" kein Dateilisting/Übertragung?
Login kein Problem, aber keine Dateiauflistung und Übertragung.
Zeig 'lsmod', 'iptables -S' und 'iptables -S -t nat'. Oder hast Du doch schon nftables, dann 'nft list ruleset'.
root@ns:~# lsmod | grep conn nf_conntrack_netlink 57344 0 nfnetlink 20480 2 nf_conntrack_netlink xt_conntrack 16384 2 nf_conntrack_ftp 24576 0 nf_conntrack 176128 7 xt_conntrack,nf_nat,xt_state,xt_helper,nf_conntrack_netlink,nf_conntrack_ftp,xt_MASQUERADE nf_defrag_ipv6 24576 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack x_tables 53248 15 ip6table_filter,xt_conntrack,iptable_filter,xt_LOG,xt_multiport,xt_state,xt_tcpudp,xt_addrtype,xt_comment,xt_helper,ip6_tables,ipt_REJECT,ip_tables,xt_limit,xt_MASQUERADE libcrc32c 16384 3 nf_conntrack,nf_nat,raid456
root@ns:~# iptables -S INPUT -P INPUT DROP -A INPUT -m comment --comment "Alle Anfragen in DYNIPS akzeptieren" -j DYNIPS -A INPUT -m comment --comment "Alle Anfragen in DROPIPS ablehnen" -j DROPIPS -A INPUT -m comment --comment "Alle Anfragen in CRACKERIPS ablehnen" -j CRACKERIPS -A INPUT -s 91.216.245.10/32 -i isp0 -p tcp -m comment --comment "Server ns.ricoltz.de (ALTER SERVER)" -j ACCEPT -A INPUT -s 185.242.112.224/32 -i isp0 -p tcp -m multiport --dports 22 -m comment --comment "Server ns.lucabert.de" -j ACCEPT -A INPUT -s 87.138.108.42/32 -i isp0 -m comment --comment "Gateway Hutzel" -j ACCEPT -A INPUT -s 87.191.224.158/32 -i isp0 -m comment --comment "Gateway Werkstatt" -j ACCEPT -A INPUT -i lo -m comment --comment "Vom localhost alles akzeptieren" -j ACCEPT -A INPUT -i intlan0 -m comment --comment "Vom Host-Netzwerk (KVM) alles akzeptieren" -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -m comment --comment "Connection tracking" -j ACCEPT -A INPUT -d 91.216.245.10/32 -i isp0 -p tcp -m multiport --dports 25,465,587,53,80,443,110,995,143,993 -m comment --comment Rico -j ACCEPT -A INPUT -d 91.216.245.10/32 -i isp0 -p tcp -m multiport --dports 20,21 -m comment --comment Rico -j ACCEPT -A INPUT -d 91.216.245.10/32 -i isp0 -p udp -m multiport --dports 53 -m comment --comment Rico -j ACCEPT -A INPUT -d 91.216.245.11/32 -i isp0 -p tcp -m multiport --dports 25,465,587,143,993 -m comment --comment CarConcept -j ACCEPT -A INPUT -i isp0 -p udp -m udp --dport 1194 -m comment --comment OpenVPN -j ACCEPT -A INPUT -i vpnsrv0 -m comment --comment VPN-Verbindungen -j ACCEPT -A INPUT -i isp0 -p udp -m udp --dport 694 -m comment --comment "Wegen Heartbeat in Multicast im Netz" -j DROP -A INPUT -i isp0 -p udp -m udp --dport 137 -m comment --comment "Wegen Heartbeat in Multicast im Netz" -j DROP -A INPUT -i isp0 -p udp -m udp --dport 67 -m comment --comment "Wegen DHCP im Netz" -j DROP -A INPUT -i isp0 -p icmp -m icmp --icmp-type 0 -m comment --comment "PONG erlauben" -j ACCEPT -A INPUT -i isp0 -p icmp -m icmp --icmp-type 8 -m limit --limit 6/min -m comment --comment "PING burst: 5 Mal erlauben, dann nur Einmal alle 10 Sekunden" -j ACCEPT -A INPUT ! -p icmp -j LOG --log-prefix IPv4
NAT wurde nicht definiert.
Danke Luca Bertoncello (lucabert@lucabert.de)
Moin,
FTP unterscheidet sich ein wenig von den meisten Protokollen mit denen man sonst so zu tun hat. Es ist aufgeteilt in einen Steuerkanal (i.d.R. TCP 21) und einen Datenkanal (kann TCP 20 sein, kann aber auch ein beliebiger highport sein).
Der Steuerkanal macht z.B. login oder changedir. Dazu baut der Client von einem TCP highport eine Verbindung zum FTP-Server TCP 21 auf, dieser antwortet dann auch auf diesem Wege. Das ist das übliche für Paketfilter - auf der Clientseite ausgehend erlaubt, vermutlich noch NAT und auf Serverseite in&out erlaubt.
Nun ist die Frage, hat Dein Client aktives oder passives FTP angefordert? Aktiv läuft so, dass der Server den Client über den Steuerkanal mitteilt, dass der Client an einem beliebigen highport _lauschen_ und diesen dem Server mitteilen soll. Datentransfer würde dann so laufen, dass der Server von TCP 20 den Client am vereinbarten highport kontaktiert. Server out sicher erlaubt aber Client in (und dann ggf noch das NAT)? Das versucht das connection tracking modul zu lösen, indem es auf dem Steuerkanal mithört was vereinbart wird und dann dynamisch Regeln nachbaut. Wann funktioniert das nicht? Richtig, wenn TLS im Einsatz ist.
Das war wohl auch den Protokolldesignern aufgefallen und man entwarf noch den passive-mode. Hier teilt der Server dem Client mit, auf welchem highport (die Range kannst Du i.d.R am FTP-Server definieren) der Server auf Clientanfragen lauscht. Hier müssen am Server also noch diese möglichen highports in offen sein (auch das kann conntrack wohl übernehmen) und auf Clientseite das entsprechende out (was man aber i.d.R. zu hat, also auch hier conntrack).
Login kein Problem, aber keine Dateiauflistung und Übertragung.
Der Steruerkanal läuft bei Dir - Du sagtest ja: login geht.
root@ns:~# lsmod | grep conn nf_conntrack_ftp 24576 0 nf_conntrack 176128 7
Auf connection tracking bist Du auf Serverseite auch vorbereitet, die nötigen Module sind geladen.
-A INPUT -m state --state RELATED,ESTABLISHED -m comment --comment "Connection tracking" -j ACCEPT -A INPUT -d 91.216.245.10/32 -i isp0 -p tcp -m multiport --dports 20,21 -m comment --comment Rico -j ACCEPT
Die eingehenden Server-Regeln für die bekannten Ports hast Du und alles Verbindungszugehörige (established, related) auch.
Leider bist Du schuldig geblieben, wie das ausgehend so aussieht. Ob Du den FTP auch wirklich an 21 gebunden hast und ob die IF stimmen, musst du allein prüfen. Vom Client wissen wir auch nix.
Wie Du meiner Beschreibung nun aber hoffentlich entnehmen kannst, ist auch der Paketfilter auf Clientseite entscheidend - hier könntest Du mit z.B. 'tcpdump' mal einem Verbindungsaufbau und dann vor allem versuchtem PUT/GET/DIR|LS auf beiden Kisten zuschauen, um herauszufinden, welche Seite hier Pakete verwirft/blockiert.
Ferner ist mir so, als müsse man bei neueren Kernen (ab oder größer 4.7?) das connection tracking jetzt erst "initialisieren". In 'nftables'/'nft' läuft das z.B. so
nft add ct helper inet $TABLE ftp { type "ftp" protocol tcp; } nft add rule inet $TABLE INPUT ct helper ftp accept #auch für OUTPUT und FORWARD ggf.
mit 'iptables' sollte das wohl so aussehen
iptables -A $CHAIN -m conntrack --ctstate RELATED -m helper --helper ftp -d $DESTINATION -p tcp --dport 1024: -j ACCEPT #statt der 1024: auch gern die Portrange des FTP-Servers; gilt dann für passives FTP
conclusion - SSL am FTP-Client aus - active und passive probieren - vielleicht geht ein Mode schon - kernel und helper initialisierung prüfen - mit 'tcpdump' debuggen
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Am 13.12.2023 10:52, schrieb ronny@seffner.de:
Hallo Ronny
(omissis)
conclusion
- SSL am FTP-Client aus
- active und passive probieren - vielleicht geht ein Mode schon
- kernel und helper initialisierung prüfen
- mit 'tcpdump' debuggen
Also, FTP lauscht auf die richtige IP. Wenn ich die Firewall an dem Server deaktiviere, läuft alles prima. Das Problem ist also definitiv die Firewall... Das mit dem ctstate habe ich auch probiert, leider hat das auch nichts gebraucht. OUTPUT-Regel gibt es weder bei dem Server noch bei dem Client. Ich sehe definitiv in dem IPTables-Log, dass das Problem ist, das die hohe Port, die für die Übertragung benutzt werden soll, blockiert wird. Leider konnte ich nicht finden, wie ich diese erlauben kann, ohne pauschal alles, was über 1024 ist, zu erlauben...
FTP geht weder mit Aktiv noch mit Passiv, sobald die Firewall läuft. Und ja, ich habe dem Nutzer schon gesagt, SFTP ist besser, aber aktuell bei ihm geht nur über FTP (ich weiß nicht genau warum).
Grüße Luca Bertoncello (lucabert@lucabert.de)
Hallo Ronny,
On Wed, Dec 13, 2023 at 10:52:11 +0100, ronny@seffner.de wrote:
FTP unterscheidet sich ein wenig von den meisten Protokollen mit denen man sonst so zu tun hat. Es ist aufgeteilt in einen Steuerkanal (i.d.R. TCP 21) und einen Datenkanal (kann TCP 20 sein, kann aber auch ein beliebiger highport sein).
Der Steuerkanal macht z.B. login oder changedir. Dazu baut der Client von einem TCP highport eine Verbindung zum FTP-Server TCP 21 auf, dieser antwortet dann auch auf diesem Wege.
Man koennte auch sagen: FTP ist broken by design :)
Jedes halbwegs vernuenftige "FTP-Tool" bringt inzwischen auch Support fuer sftp mit (ich meine das SSH-Subsystem, nicht FTP ueber SSL). Das sftp-Protokoll benutzt SSH als Transport und kommt deshalb mit einer einzelnen TCP-Verbindung aus -- keine ausgewuerfelten Portnummern fuer eine zweite Verbindung, kein Gehampel mit irgendwelchen conntrack-Helpern noetig. Zudem ergibt sich noch der Vorteil der pubkey-basierten Anmeldung -- idealerweise kombiniert mit dem Abschalten der Passwort-basierten Anmeldung.
Welchen Grund ausser "wir machen das schon immer so" gibt es, heute noch FTP zu benutzen?
Gruss, Christian
Das mit dem ctstate habe ich auch probiert, leider hat das auch nichts gebraucht.
Ich denke aber hier ist die Ursache.
OUTPUT-Regel gibt es weder bei dem Server noch bei dem Client.
Eine Policy? Irgenwas muss es ja geben.
Leider konnte ich nicht finden, wie ich diese erlauben kann, ohne pauschal alles, was über 1024 ist, zu erlauben...
Du kannst in Deinem FTP-Server die Portrange dafür festlegen. Z.B. "PassivePorts 49152 49161" für proFTPd Wie viele parallele FTP-Verbindungen erwartest Du? 10? Dann mach doch quick-and-dirty diese 10 Ports auf (habe ich hier auch so, wegen FTPs wo conntrack keine Macht hat).
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Man koennte auch sagen: FTP ist broken by design :)
Lag mir auf der Zunge - hilft dem Luca ja aber nicht.
fuer sftp mit (ich meine das SSH-Subsystem, nicht FTP ueber SSL).
... heißt ja dann auch FTPs ... während du in deinem FTP-Server aber oft mehr oder weniger out-of-the-Box virtuelle Nutzer und chroot hast, konfrontiert dich sftp(scp|ssh) gleich mit Systemnutzern und den Schwesterprotokollen - Luca meint ja auch, der Client kann/will nicht anders und von FTP(s) zu SFTP ist es eben ein konzeptioneller Wechsel
eine zweite Verbindung, kein Gehampel mit irgendwelchen conntrack- Helpern
Es sei denn du machst über diesen Portfilter auch noch VoIP oder so, das ist kaum besser.
Welchen Grund ausser "wir machen das schon immer so" gibt es, heute noch FTP zu benutzen?
S.o.: Konzeptwechsel, virtuelle Nutzer, ..., keinen, der nicht lösbar wäre
Mit freundlichen Grüßen / Kind regards Ronny Seffner
lug-dd@mailman.schlittermann.de
-
Christian Perle -
Luca Bertoncello -
Ronny Seffner -
ronny＠seffner.de