On Sun, Dec 27, 2009 at 6:16 PM, Jan Engelhardt <jengelh@xxxxxxxxxx> wrote: > > On Sunday 2009-12-27 09:11, Роман Цисык wrote: >> >>А questionable point exists in the conntrack expectations design. What >>happens if somebody opened fake outgoing connection which would match >>conntrack helpers' signatures? Conntrack module will be able to add >>records in expectation table. >>Unfortunately, all users from 192.168.0.0/24 will have problems with >>an active FTP. Users will force administrators to read boring manuals >>as alredy founded and load nf_connrack_ftp + nf_nat_ftp to "overcome" >>the problem. >>Next, if malicious software would initiate connection as in the >>previous case, NAT subsystem will forward (y << 8 | z) port to outside >>by changing source PORT command and, in fact, forwarding a port >>inside. So, if we something would open connections to remote 21 port >>and send our PORT commands, we can transparently open ANY port from >>INTERNAL server to the public Internet, regardless NAT. Hereinafter, >>I'll call this "conntrack back-connection issue". > > That is what helpers are supposed to do. If that poses a security risk, > to your network, I advise not to use them. In case of FTP that is easily > worked around by using passive ftp. > > Furthermore, the problems NAT brings with itself (ETE connectivity is > just one) are well-known. Getting your own IPv6 tunnel is a > no-brainer these days. > >>Furthermore, various ways to inititate connections from client exists. >>It can be malicious software, that needs only user permisions to open >>connection outgoing connection, or user himself, or ... surprise, just >>a web-browser. > > That is why, as far as I gather, security standards advise to use > proxies for the connections from the internal network to the > Internet. > Of course, various solution exists, as you already pointed out a passive FTP and a directly connection using IPv4 or IPv6. However, NAT is still being widely used today. Sometimes this scheme includes transparent squid with REDIRECT rule. Moreover, I noticed that other helpers also can create problems like these, not just ftp helper. Not everyone will think how helpers works, so a lot of manual errors and buggy configurations exists. For first case we can avoid problem by changing net.ipv4.ip_local_port_range and specifying only these values in --dport at the "-m state --state" rule. For second case, we can play with FORWARD chain rules and make its conntrack-based (and specify --dport for tcp / udp). We can simple unload conntrack_ftp too. BTW, I've never seen such settings in small, especially in the box Linux routers (e.g. Linksys, D-link, etc.), but ip/nf_conntrack_ftp was loaded or built-in. I've just asked friend of mine to connect remote ftp through a particular 2.4.x ADSL router with probably loaded ip_conntrack_ftp, and his records showed me, that active ftp worked without any problems, lsmod was almost empty (i.e. modules really built-in), but no appropriate rules existed in iptables. PS: it seems that Dan Carpenter has founded another problem with the module -- WBR, Tsisyk Roman -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
