Re: letztes Treffen im Jhr 2023?
Hi zusammen, Bin auch dabei. Bis nachher, Andreas > Am 13.12.23 um 10:11 schrieb Bernhard Schiffner: > >> Gerd und ich wären dabei ... > > +1, auch wenn ich wahrscheinlich etwas später komme. > >> Weiss jemand eine "Kontraidikation" (Gaga zu etc.)? > > 0 > >> Bis dann! >> Bernhard > > Viele Grüße und schon einmal schöne Feiertage an alle > Jakob
AW: Kein FTP mehr möglich mit Debian 11 - Firewallproblem
> 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
AW: AW: Kein FTP mehr möglich mit Debian 11 - Firewallproblem
> 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 -- Ronny Seffner | Alter Viehweg 1 | 01665 Klipphausen www.seffner.de | ro...@seffner.de | +49 35245 72950 7EA62E22D9CC4F0B74DCBCEA864623A568694DB
Re: Kein FTP mehr möglich mit Debian 11 - Firewallproblem
Hallo Ronny, On Wed, Dec 13, 2023 at 10:52:11 +0100, ro...@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 -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
Re: letztes Treffen im Jhr 2023?
Hallo Bernhard, Am 13.12.23 um 10:11 schrieb Bernhard Schiffner: Gerd und ich wären dabei ... +1, auch wenn ich wahrscheinlich etwas später komme. Weiss jemand eine "Kontraidikation" (Gaga zu etc.)? 0 Bis dann! Bernhard Viele Grüße und schon einmal schöne Feiertage an alle Jakob
Re: letztes Treffen im Jhr 2023?
Hallo Bernhard, On Wed, Dec 13, 2023 at 10:11:51 +0100, Bernhard Schiffner wrote: > Gerd und ich wären dabei ... Ich schaffe es heute nicht. Schoene Weihnachtstage, Christian -- Christian Perlechris AT linuxinfotag.de 010111 http://chris.silmor.de/ 101010 LinuxGuitarKitesBicyclesBeerPizzaRaytracing
Re: AW: Kein FTP mehr möglich mit Debian 11 - Firewallproblem
Am 13.12.2023 10:52, schrieb ro...@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 (lucab...@lucabert.de)
AW: Kein FTP mehr möglich mit Debian 11 - Firewallproblem
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
letztes Treffen im Jhr 2023?
Gerd und ich wären dabei ... Weiss jemand eine "Kontraidikation" (Gaga zu etc.)? Bis dann! Bernhard