Hallo Carsten,
Carsten Friede wrote:
Moin.
Ich habe mir die Geschichte von wegen stateful filtering nochmal angesehen, und gleich mal ueberprueft, ob das bei mir auch geht. Anscheinend ist dem nicht so.
hier meine state-Chain:
$IPT -A states -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A states -m state --state NEW,INVALID -j REJECT
Wenn ich mich damit bspw. auf ftp.de.debian.org einlogge, dann kann ich auch in die Verzeichnisse wechseln. Allerdings schlaegt ein ls immer fehl. Warum?
Bei LIST macht FTP ne extra Datenverbindung auf, wie beim GET.
Bei FTP wird normalerweise im Active mode Dateitransfer gemacht: da verbindet sich der Server an einen Port zum Client, aber das wird ja sicherlich von den Iptables geblockt. Dann gibts da noch den Passive mode, da verbindet sich der Client zum Server, ist also ne ausgehende und sollte zugelassen werden.
Wenn ich die hohen Ports extra freigeben muss, dann kann ich auch auf stateful filtering verzichten.
Entweder Du benutzt passives FTP oder Du versuchst es mit dem Helpermodul für FTP, womit Iptables auch aktives FTP verstehen könnte...
--- http://www.netfilter.org/documentation/HOWTO/de/NAT-HOWTO-7.html
"Manche Protokolle werden nicht gern geNATted. Fuer jedes dieser Protokolle muessen zwei Erweiterungen geschrieben werden; eine fuer das Connection-Tracking des Protokolls, und eine fuer das eigentliche NAT.
In der netfilter-Distibution gibt es zur Zeit Module fuer FTP: ip_conntrack_ftp.o und ip_nat_ftp.o. Wenn Du diese Module mit insmod in den Kernel laedst (oder sie permanent hineinkompilierst), sollte NAT auf FTP-Verbindungen funktionieren. Wenn Du das nicht tust, kannst Du nur passives FTP verwenden, und sogar das koennte nicht zuverlaessig funktionieren, wenn Du mehr als einfaches Source-NAT machst." ---
Hm... da hätte ich ne Frage, falls sich jemand gut damit auskennt: Analysiert ip_conntrack_ftp.o richtig den Datenstrom auf Port 21? Also diese PORT-Befehle im Protokoll? Das wär ja krass...
Carsten
Stephan.