Dotaz: iptables brzdí login na ftp

[David Watzke]

Ahoj,

nastavil jsem si iptables a teď když stahuju něco z ftp, tak se dlouho přihlašuju, ať už anonymně, nebo ke svýmu...

Resolving ftp.linux.cz... 147.251.48.205
Connecting to ftp.linux.cz|147.251.48.205|:21... connected.
Logging in as anonymous ... # a tady čekám... když "vypnu" iptables je to ihned

Zajímavý je, že sftp je OK. V logu se vždy objeví:

IN=eth1 OUT= MAC=... SRC=... DST=... LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=33062 DF PROTO=TCP SPT=44600 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
IN=eth1 OUT= MAC=... SRC=... DST=... LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=33063 DF PROTO=TCP SPT=44600 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
IN=eth1 OUT= MAC=... SRC=... DST=... LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=33064 DF PROTO=TCP SPT=44600 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
IN=eth1 OUT= MAC=... SRC=... DST=... LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=5779 DF PROTO=TCP SPT=33477 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
INPUT drop: IN=eth1 OUT= MAC=... SRC=... DST=... LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=5779 DF PROTO=TCP SPT=33477 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0
IN=eth1 OUT= MAC=... SRC=... DST=... LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=5780 DF PROTO=TCP SPT=33477 DPT=113 WINDOW=5840 RES=0x00 SYN URGP=0

a pravidla iptables vypadají takto:

Chain INPUT (policy DROP 20346 packets, 2251K bytes)
 pkts bytes target     prot opt in     out     source               destination
 624K   62M ACCEPT     all  --  lo     any     anywhere             anywhere
    0     0 ACCEPT     tcp  --  eth1   any     anywhere             anywhere            tcp dpt:4000
 680K  577M ACCEPT     tcp  --  eth1   any     anywhere             anywhere            tcp dpt:4663
   21  1222 ACCEPT     tcp  --  eth1   any     anywhere             anywhere            tcp dpt:8010
    0     0 ACCEPT     udp  --  eth1   any     anywhere             anywhere            udp dpt:8010
   55  3300 LOG        tcp  --  eth1   any     anywhere             anywhere            tcp dpt:auth limit: avg 12/hour burst 5 LOG level warning
    2    56 ACCEPT     icmp --  eth1   any     anywhere             anywhere            length 0:100 icmp echo-request
 458K  315M ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED
  597 80409 LOG        all  --  any    any     anywhere             anywhere            limit: avg 12/hour burst 5 LOG level warning prefix `INPUT drop: '

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 624K   62M ACCEPT     all  --  any    lo      anywhere             anywhere
1074K  196M ACCEPT     all  --  any    eth1    anywhere             anywhere
    0     0 LOG        all  --  any    any     anywhere             anywhere            LOG level warning prefix `OUTPUT drop: '

Nevíte prosím jak to vyřešit?

Odpovědi

[ZAH]

Prakticky v každém návodu k iptables najdete toto.

# Sluzbu AUTH neni dobre filtrovat pomoci DROP, protoze to muze
# vest k prodlevam pri navazovani nekterych spojeni. Proto jej
# sice zamitneme, ale vygenerujeme korektni ICMP chybovou zpravu
$IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 113 -m limit --limit 12/h -j LOG
$IPTABLES -A INPUT -i $INET_IFACE -p TCP --dport 113 -j REJECT --reject-with tcp-reset #AUTH server

[David Watzke]

Oops...

root ~ # iptables -A INPUT -i eth1 -p TCP --dport 113 -m limit --limit 12/h -j LOG
root ~ # iptables -A INPUT -i eth1 -p TCP --dport 113 -j REJECT --reject-with tcp-reset
iptables: Unknown error 18446744073709551615

[David Watzke]

Vyřešeno, chyběl mi modul ipt_REJECT. Díky všem za pomoc.

[Michal Kubeček]

Raději zkontrolujte, jestli vám nechybí ještě něco, při použití neznámého targetu by se měla vypsat smysluplná chybová hláška, ne "unknown error".

[David Watzke]

Když dám do Googlu tu chybovou hlášku i s tím všeříkajícím číslem, zjišťuju, že to má milion příčin. Mimochodem, tady je konec strace výpisu, když jsem ještě neměl ten modul.

open("/lib64/iptables/libipt_REJECT.so", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\t\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=6504, ...}) = 0
mmap(NULL, 1053728, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2b6587422000
mprotect(0x2b6587424000, 1044480, PROT_NONE) = 0
mmap(0x2b6587523000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x2b6587523000
close(3)                                = 0
socket(PF_INET, SOCK_RAW, IPPROTO_RAW)  = 3
getsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., [84]) = 0
getsockopt(3, SOL_IP, 0x41 /* IP_??? */, "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., [3768]) = 0
setsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4024) = -1 ENOENT (No such file or directory)
write(2, "iptables: Unknown error 18446744"..., 45iptables: Unknown error 18446744073709551615
) = 45
exit_group(1)                           = ?

Z toho moc chytrej nejsem.

[Michal Kubeček]

  open("/lib64/iptables/libipt_REJECT.so", O_RDONLY) = 3

ale nevypadá, že by tam ten modul nebyl. Spíš to vypadá, jako by k chybě došlo až při komunikaci s jádrem.

[David Watzke]

Jo, je to zvláštní, ale já jsem ten modul skutečně neměl, povolil jsem v jádře REJECT target support, jádro zkompiloval (make; zkompiloval se tedy jen ten modul, jádro už bylo), zkopíroval jsem si novej image do bootu (i když se asi skoro nezměnil) a nainstaloval moduly (make modules_install).

[Michal Kubeček]

Pletete si dvě různé věci: za prvé modul jádra, který potřebujete k tomu, aby jádro bylo schopno aplikovat akci REJECT, tj. soubor (např.) /lib/modules/2.6.13-15.8-default/kernel/net/ipv4/netfilter/ipt_REJECT.ko Za druhé modul příkazu iptables, tj. object file, který je potřeba natáhnout, aby příkaz iptables porozuměl zápisu '-j REJECT' a přetlumočil ho jádru, to je soubor (např.) /usr/lib64/iptables/libipt_REJECT.so. Podle vašeho popisu to vypadá, že jste měl modul iptables, ale ne odpovídající modul jádra.

P.S.: právě z podobných důvodů se snažím přesvědčovat lidi, aby rozlišovali netfilter (paketový filtr v jádře) a iptables (user space rozhraní sloužící ke konfiguraci netfilteru).

[David Watzke]

Aha, už chápu. Tak to bylo - jen jsem to špatně popsal.

[Michal Kubeček]

Mnohem častěji to ovšem bývá tím, že nefunguje reverzní lookup IP adresy klienta.

[David Watzke]

Funguje, tady jsem to testnul...

84.242.75.233 resolves to
"bys-84-242-75-233.karneval.cz"
Top Level Domain: "karneval.cz"

[Libor Klepac]

zkusil bych take moduly ip_nat_ftp a ip_conntrack_ftp, zvlast jestli pouzivas aktivni ftp, a uplne zvlast,pokud sedis nekde na stroji za timhle strojem ;)

[David Watzke]

Ne, to opravdu nesedím... Ty moduly tu mám, ale co s nimi? Aktivní FTP zřejmě používám - trvá to i když wgetu dám --no-passive-ftp.

[David Watzke]

I když... nevím. Když v nastavení připojení v KControl odškrtnu "Enable passive mode (PASV)", tak se v Konqueroru na žádný FTP nedostanu... Když někam vlezu anonymně, tváří se jako když na tom FTP nic není a když zadám login a password, tak píše Login OK, ale taky prázdno.

[Luboš Doležel (Doli)]

Všechny ti KIO jsou podivný a nespolehlivý. Spíš věřím tomu, co řekne (a jak se zachová) konzolový nástroj ftp.

[Petr Šobáň]

Jasný to problém s portem 113 služba auth

Nezahazovat ale odmítat REJECT

[David Watzke]

Viz #1.