Re: Bypass rules using conntrack helpers

[Roman Tsisyk <roman@tsisyk.com>]

On Sun, Dec 27, 2009 at 6:16 PM, Jan Engelhardt <jengelh@medozas.de> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html