passives FTP will nicht

[feldmaus]

Guten Abend,

ich hoffe ihr könnt mir helfen.

In meinem Heim-Netzwerk läuft ein Internet-Router mit Debian 6.0 Kernel 3.6.11(selbst kompiliert am 2012-12-23). Auf diesem Router läuft meine Firewall(iptables 1.4.8 ) die ich vor Jahren das letzte mal angefasst habe bzw. mit der ich mich seit c.a. 2 Jahren nicht mehr beschäftigt habe. Nun benötige ich für ein Online-Spiel Zugriff auf einen passiven FTP-Server, was laut meiner Log-Datei durch die Firewall verweigert wird.

Folgende Fehlermeldungen bekomme ich:

Code: Alles auswählen

[49709.311553] INTFW: IN=br0 OUT=ppp0 PHYSIN=eth1 MAC=00:0b:6b:02:01:99:d4:3d:7e:91:21:32:08:00 SRC=192.168.0.111 DST=94.23.199.47 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=14848 DF PROTO=TCP SPT=49863 DPT=63563 WINDOW=8192 RES=0x00 SYN URGP=0 

Hier der Abschnitt von meiner Firewall:
http://nopaste.debianforum.de/39058

Kurze Erklärungen zu meinen Chains:
int-fw Chain enthält sämtliche Kommunikation von meinem privaten Netzwerk über meinen Router ins Internet.
ext-fw Chain enthält sämtliche Kommunikation vom Internet über meinen Router in mein privates Netzwerk.

Modul NF_CONNTRACK_FTP ist glaube ich fest integriert in mein Kernel:
http://nopaste.debianforum.de/39059

Benötige ich auf jeden Fall die Optionen ESTABLISHED, RELATED in meinen Firewall-Regeln?

Grüße

[wanne]

Interessant wären erstmal die Tabellen filter und nat.
Ansonsten ist das vermutlich ein DSL Anschluss, wenn die Verbindung DSL heißt.
Ich glaube mittlerweile tun alle Internetanbieter irgend welche NAT-Boxen zu ihren Internetanschlüssen ausgeben. Da kommt typischerweise kein FTP durch. Kannst hoffen, dass du das oder den Router ändern kannst. (Über exposed host meistens.)

Benötige ich auf jeden Fall die Optionen ESTABLISHED, RELATED in meinen Firewall-Regeln?

Prinzipiell brauchst du gar keine Regeln, wenn du einfach alles akzeptierst. Erst sobald du irgend was wegwirfst, brauchst du das. (Bei FTP passiert das meistens durch irgend welche NAT regeln.)
Sonst sieht das ziemlich redundant aus. Glaube, die hälfte der Regeln macht nichts, außer die CPU zu belasten. Aber ohne das volle iptables kann man da nicht viel sagen.

[feldmaus]

Hi Wanne,

ich poste mal meine ganzen Firewall-Regeln, aber bitte nicht aus den Latschen kippen. Ich habe es soweit ich konnte sortiert.

http://nopaste.debianforum.de/39060

Wobei Du musst nicht alle meiner Firewallregeln angucken. Meine oben gepostete Fehlermeldung besagt ja das der Fehler in der <int-fw> Chain aufgetreten ist. D.h. du musst dir auch nur die <int-fw> Chain angucken, also Zeile 290 bis 311. Und nur diese wird modifiziert.

Grüße

[MSfree]

Nun benötige ich für ein Online-Spiel Zugriff auf einen passiven FTP-Server, was laut meiner Log-Datei durch die Firewall verweigert wird.

Folgende Fehlermeldungen bekomme ich:

Code: Alles auswählen

[49709.311553] INTFW: IN=br0 OUT=ppp0 PHYSIN=eth1 MAC=00:0b:6b:02:01:99:d4:3d:7e:91:21:32:08:00 SRC=192.168.0.111 DST=94.23.199.47 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=14848 DF PROTO=TCP SPT=49863 DPT=63563 WINDOW=8192 RES=0x00 SYN URGP=0 

Die Meldung deutet aber darauf hin, daß der Client nicht im passiven Modus läuft. Passive-FTP sollte meines Wissens komplett über DPT=21 abgewickelt werden.

Modul NF_CONNTRACK_FTP ist glaube ich fest integriert in mein Kernel:
http://nopaste.debianforum.de/39059

Symbol: NF_CONNTRACK_FTP [=m] bedeutet aber "Module" und nicht fest einkompiliert. Du mußt also nf_contrack_ftp mit modprobe laden und in die Datei /etc/modules eintragen, damit es bei Booten automatisch geladen wird (oder den Kernel neu kompilieren)

Benötige ich auf jeden Fall die Optionen ESTABLISHED, RELATED in meinen Firewall-Regeln?

Nein, die Regel wird nicht zwingend benötigt, es ist aber eine gute Idee, sie zu setzen, weil es den Kernel ziemlich entlastet und auch für zusätzliche Sicherheit gegen DOS-Atacken darstellt.

[wanne]

OK, Jetzt kapiere ich was du machst.
Ich glaube, dass du die regel das falsch benutzt:

Code: Alles auswählen

iptables -A int-fw -p tcp --sport 1024:65535 --dport 1024:65535 -m helper --helper ftp -j ACCEPT

Ganz sicher bin ich mir da nicht, aber ich glaube das will eingehende Verbindungen zu einem Server kontrollieren.
Das kannst du mal Testweise ausprobieren (sollte zumindest mit ftp ohne TLS funktionieren, wenn die Verschlüsseln hast du pech.):

Code: Alles auswählen

iptables -A int-fw -p tcp --sport 1024:65535 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Sonst sehe ich nicht so wirklich den Sinn hinter dem Ding: 99% der Anwendungen sprechen sowieso nur mit Port 80 oder 443. (Ausnahme sind lange etablierte Protokolle wie E-Mail oder FTP.)
In sofern hast du eh mehr oder weniger nichts real existierendes geblockt. (Und vor allem nichts, dass darauf ausgelegt ist, gegen dein Wissen zu operieren. Das wird sich schön braf auf Port 443 verstecken.) Das einzige was du damit blockierst sind Anwendungen die einiges besser machen wollen als das etablierte. (sctp, DCCP, FTPS...)


Würde halt an deiner stelle 0:1024 dicht machen und ggf. etwas syn-Filtering machen. Sonst bin ich mittlerweile dazu übergegangen eher owner spezifisch zu filtern. (wine darf nicht ans Internet...) Ist glaube ich sinnvoller. – Aber nur meine Meinung.

[dufty2]

Nun benötige ich für ein Online-Spiel Zugriff auf einen passiven FTP-Server, was laut meiner Log-Datei durch die Firewall verweigert wird.

Folgende Fehlermeldungen bekomme ich:

Code: Alles auswählen

[49709.311553] INTFW: IN=br0 OUT=ppp0 PHYSIN=eth1 MAC=00:0b:6b:02:01:99:d4:3d:7e:91:21:32:08:00 SRC=192.168.0.111 DST=94.23.199.47 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=14848 DF PROTO=TCP SPT=49863 DPT=63563 WINDOW=8192 RES=0x00 SYN URGP=0 

Die Meldung deutet aber darauf hin, daß der Client nicht im passiven Modus läuft. Passive-FTP sollte meines Wissens komplett über DPT=21 abgewickelt werden.

Nö, meines Wissens nach tut es das nicht

Beim "aktiven FTP" macht der Server die 2. Verbindung (die eigentliche Daten-Verbindung) zum ftp-client hin auf.
Aufgrund der schon genannten NAT-Problematik geht das oft nicht.
Also hat man "passives FTP", bei der ftp-client die 2. Verbindung zum Server aufspannt (port:HIGH -> port:HIGH).
Den HIGH-Port des Servers bekommt der ftp-client aber zuvor vom FTP-Server mitgeteilt.
Und darauf kann man nun seine Firewall einstellen, weil man ja ansonsten alle HIGH-Ports server- wie client-seitig offen halten müsste, was ja dann die ganze Firewall in Frage stellen würde.

[feldmaus]

So habe mein FTP Regeln geändert und es tat sich ein bisschen was, hier die Änderung

http://nopaste.debianforum.de/39061

Die Fehlermeldung lautet,

Code: Alles auswählen

[ 7238.870817] INTFW: IN=br0 OUT=ppp0 PHYSIN=eth1 MAC=00:0b:6b:02:01:99:d4:3d:7e:91:21:32:08:00 SRC=192.168.0.111 DST=94.23.199.47 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=26542 DF PROTO=TCP SPT=61389 DPT=21 WINDOW=8192 RES=0x00 SYN URGP=0 

Ich habe überall das <helper ftp> Modul eingebaut in der Hoffung das dies alle FTP Verbindungen protokolliert und es iptables leichter macht.

Kann mir Jemand das <helper ftp> Modul erklären?

[wanne]

So jetzt hast du dir den Kontroll-Port zu gemacht. Jetzt dürfte auch kein Aktives-FTP mehr tun.
Die regel brauchst du natürlich weiterhin:

Code: Alles auswählen

iptables -A int-fw -p tcp --sport 1024:65535 --dport 21 -j ACCEPT

Sonst würde ich von dem ftp-Helper die Finger lassen, solange du nicht weißt, was die tut. (Ich habe da auch keine Doku gefunden.)

[feldmaus]

Danke Wanne,

habe gerade gemerkt, dass ich sehr viele Regeln mit dem Negations-Symbol <!> verwende, dies sollte ich lieber lassen oder? Sonst kann es doch gar nicht funktionieren oder?

ERGÄNZUNG, vielleicht sollte ich doch mal <nf_conntrack_ftp> modular in meinen Kernel packen? Eventuell braucht das <helper>?

[feldmaus]

Ohne das <helper ftp> Modul gehts besser, zudem war die Negation <!> auch falsch. Hier meine jetzigen Änderungen.

http://nopaste.debianforum.de/39062

Ich hätte das <helper> Modul schon gerne, dies würde mehr Sicherheit bringen. Allerdings ohne Doku???? Ich schau die Tage nochmal wegen dem <nf_conntrack_ftp>.

Grüße

[dufty2]

iptables -A int-fw -p tcp --sport 1024: --dport 1024: -j ACCEPT

Na, das ist aber mal 'ne Regel

Falls das Modul nf_conntrack_ftp geladen ist, sollte ein

Code: Alles auswählen

iptables -A int-fw -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A ext-fw -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT

iptables -A int-fw -p tcp --sport 1024: --dport 1024:  -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A ext-fw -p tcp --sport 1024: --dport 1024:  -m state --state ESTABLISHED -j ACCEPT

reichen. Ungetestet!

[feldmaus]

So habe es ein wenig abgeändert.

http://nopaste.debianforum.de/39063

und werde die Tage nochmal versuchen ob ich das <helper ftp> mit ran basteln kann. Ich erhoffe mir davon zusätzliche Sicherheit.

[dufty2]

So habe es ein wenig abgeändert.

http://nopaste.debianforum.de/39063

Mmh, mich wundert, dass bei Deinem letzten Versuch das _aktive_ FTP noch funktioniert, denn nach meinen Verständnis müsste das "RELATED" genau 'andersrum" gesetzt werden, also

Code: Alles auswählen

iptables -A ext-fw -p tcp --dport 1024: --sport 20 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT &&
iptables -A int-fw -p tcp --sport 1024: --dport 20 -m conntrack --ctstate ESTABLISHED -j ACCEPT &&

Vgl. http://fibrevillage.com/sysadmin/199-li ... figuration

Und das "ftp-helper" braucht man nicht mehr dranhängen, denn durch das Laden von "nf_conntrack_ftp" hat man genau den Effekt erreicht, den man haben will:
Nur der eine HIGH-Port soll geöffnet, der benötigt wird und alle anderen 65535 bleiben zu.
Und diesen HIGH-Port ermittelt das "nf_conntrack_ftp" durch "deep-packet-inspection".

[feldmaus]

So habe es ein wenig abgeändert.

http://nopaste.debianforum.de/39063

Mmh, mich wundert, dass bei Deinem letzten Versuch das _aktive_ FTP noch funktioniert, denn nach meinen Verständnis müsste das "RELATED" genau 'andersrum" gesetzt werden, also

Code: Alles auswählen

iptables -A ext-fw -p tcp --dport 1024: --sport 20 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT &&
iptables -A int-fw -p tcp --sport 1024: --dport 20 -m conntrack --ctstate ESTABLISHED -j ACCEPT &&

Funktionierte ohne Fehler. Davon abgesehen, ist es auch Sicherheitstechnisch besser. Denn ESTABLISHED ist sicherer als RELATED vor allen Dingen für eingehende Verbindungen.

[dufty2]

Funktionierte ohne Fehler. Davon abgesehen, ist es auch Sicherheitstechnisch besser. Denn ESTABLISHED ist sicherer als RELATED vor allen Dingen für eingehende Verbindungen.

Also ich habs mal bei mir nachgespielt:
Wie ich erwarte habe bleibt die Ausgabe beim ftp-Befehl "dir" hängen.
Erst nachdem das RELATED "die Seite gewechselt hat" geht es.
Sollte auch so sein, denn ein "ESTABLISHED" sollte nur dann funktionieren, wenn schon zuvor mindestens ein Paket erfolgreich vorbeigesaust ist, also nach einem NEW bzw. RELATED.

Keine Ahnung, warum es bei Dir funktioniert

[feldmaus]

@dufty
der aktive FTP-Teil(Datenkommunikation) kommt nach den Kontrollverbindungen, so gesehen war ja vorher schon eine Verbindung zum FTP-Server. Der einzigste Grund warum ich das RELATED hier mit eingebaut habe, abgesehen davon, dass es technisch wahrscheinlich mit eingebaut werden muss, ist, dass es eine ausgehende Verbindung ist und somit nicht so gefährlich, wie eine eingehende Verbindungsregel.

Ich habe meine Regeln aufgefrischt,
http://nopaste.debianforum.de/39067

ich denke den passiven Teil sollte man aus Sicherheitsgründen auf jeden Fall mit einer IP-Adresse verknüpfen.

Und vom Resultat her müsste ESTABLISHED,RELATED und RELATED,ESTABLISHED gleich sein. Ist doch eine ODER Verknüpfung? Nur die Reihenfolge der Abfrage ist interessant, bringt vielleicht speed.

Grüße