Firewall Ports für FTP-Backup

[Nortex]

Guten Morgen zusammen,

ich habe einen vServer (mit Ubuntu 16.04) gemietet und bin vor einiger Zeit von mühseliger Handarbeit auf Plesk umgestiegen. Alles super und toll nur die Plesk-Firewall funktioniert nicht. Geht von seiten des Providers nicht. Nun habe ich mich gegen IP-Tables und für UFW entschieden. Alle Portfreigaben sind konfiguriert und ich bin sehr zufrieden mit UFW. Die Plesk Firewall ist mir eh nicht umfangreich genug (mit IP-Tables geht viel mehr als Plesk zulässt). Nun funktioniert allerdings das Backup per FTP im Backup-Manager nicht mehr. Schalte ich die Firewall wieder aus funktioniert alles wunderbar. Nach einigem Googlen habe ich in einigen Foren gelesen, dass ich neben Port 21 auch noch Port 60000-65534 öffnen muss. Dies habe ich getan, allerdings ohne Ergebnis.
Ich weiß leider nicht weiter, vielleicht hat hier ja jemand eine Lösung.

Folgende Fehlermeldung bekomme ich bei Plesk, wenn ich mit eingeschalteter Firewall ein Backup durchführen will:



MOD: Bilder bitte immer als Anhang. Danke!

LG, Nortex

 

[ThomasChr]

Backup über FTP klingt nach unverschlüsselt... ob das eine gute Idee ist?
Jedenfalls kannst du während des Backupversuchs mal ein tcpdump auf dem anderen System starten - da solltest du sehen an welchen Port es Pakete schickt die nicht durchkommen.

 

[GwenDragon]

- Verwende das Modul ip_conntrack
- verwende Passive FTP
- verwende Explizites FTP mit SSL
- Setze Regeln in IPTables

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -j ACCEPT

 

[greystone]

Ich habe auch hierzu mal wieder eine dumme Frage. Dumm deshalb weil sich die Frage durch das lesen der FTP-RFCs bzw. Protokolldokumentation wahrscheinlich erklären würde. Ich erdreiste mich aber trotzdem mal zu fragen.

Die FTP-Datenverbindung wird ja über initiale Verbindung ausgehandelt. D. h. auch die Ports, über die die sekundäre Datenverbindung dann läuft. Ob da jetzt der passive oder der aktive Modus verwendet wird ist unerheblich.

Bei FTPS(FTP over SSL) kann ein ip_conntrack da doch eigentlich nicht funktionieren. Denn die Verbindung ist verschlüsselt und da ist dann Schluss mit Connection Tracking. Die Daten zum Tracking sind ja in Verschlüsselung eingepackt und können so nicht mehr gelesen werden.

D. h. unverschlüsseltes FTP via ip_conntrack funktioniert toll. Aber über FTPS geht das doch schon rein theoretisch nicht, oder?

-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 1024:65535 -j ACCEPT

Damit ist natürlich das halbe Scheunentor offen und Connection Tracking dann natürlich nicht mehr gebraucht.

---

Es gibt wohl noch einige Szenarien, in denen FTP viele Vorteile bringt. Die einfache Firewallintegration gehört aber nie dazu. Deswegen ist eine Alternative(z. B. SFTP(=SSH-FTP) oder rsync) - sofern verfügbar - der einfachere Weg.

 

[ThomasChr]

Ich dachte die Verschlüsselung von FTPS erfolgt erst nach dem aushandeln der Ports...

 

[greystone]

Naja die normale FTP-Sitzung wird aufgebaut und darüber läuft ja schon mal einiges(Verzeichnis wechseln, Dateiliste anschauen,... ). Eine FTP-Datensitzung, die die dynamischen Datenports benötigt, wird nur aufgebaut sofern eine Dateiübertragung initiiert wird. D. h. der Aufbau der letzteren findet erheblich später statt, wohingegen die normale FTP-Sitzung direkt bei Sitzungseinrichtung verschlüsselt wird.

Man möge mich korrigieren, wenn ich Unsinn erzähle.

Vielleicht auch nochmal nachlesen...

https://de.wikipedia.org/wiki/File_Transfer_Protocol

 

[danton]

FTPS mit implizierter Verschlüsselung läuft über Port 990 und ist vollständig verschlüsselt (ähnlich wie z.B. bei HTTPS). Verschlüsselung über Port 21 erfolgt über FTPES und da erfolgt ein unverschlüsselter Verbindungsaufbau und die Verschlüsselung wird nachträglich ausgehandelt (ähnlich wie z.B. das STARTTLS bei SMTP). FTPS gilt meines Wissens zu Gunsten von FTPES als veraltet.