Is this iptables NAT exploitable from the external side?

Question

Could you please have a short look on this simple iptables/NAT-Setup, I believe it has a fairly serious security issue (due to being too simple).

On this network there is one internet-connected machine (running Debian Squeeze/2.6.32-5 with iptables 1.4.8) acting as NAT/Gateway for the handful of clients in 192.168/24.

The machine has two NICs:

eth0: internet-faced
eth1: LAN-faced, 192.168.0.1, the default GW for 192.168/24

Routing table is two-NICs-default without manual changes:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
(externalNet)   0.0.0.0         255.255.252.0   U     0      0        0 eth0
0.0.0.0         (externalGW)    0.0.0.0         UG    0      0        0 eth0

The NAT is then enabled only and merely by these actions, there are no more iptables rules:

echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# (all iptables policies are ACCEPT)

This does the job, but I miss several things here which I believe could be a security issue:

1. there is no restriction about allowed source interfaces or source networks at all

2. there is no firewalling part such as:

   (set policies to DROP)
   /sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
   /sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

And thus, the questions of my sleepless nights are, while the first one is more important to me:

1. Is this NAT-service available to anyone in the same ISP-subnet who sets this machine as his default gateway?
   I'd say yes it is, because there is nothing indicating that an incoming external connection (via eth0) should be handled any different than an incoming internal connection (via eth1) as long as the output-interface is eth0 - and routing-wise that holds true for both external und internal clients that want to access the internet. So if I am right, anyone could use this machine as open proxy by having his packets NATted here. So please tell me if that's right or why it is not.
   As a "hotfix" I have added a "-s 192.168.0.0/24" option to the NAT-starting command. I would like to know if not using this option was indeed a security issue or just irrelevant thanks to some mechanism I am not aware of.

2. As the policies are all ACCEPT, there is currently no restriction on forwarding eth1 to eth0 (internal to external). But what are the effective implications of currently NOT having the restriction that only RELATED and ESTABLISHED states are forwarded from eth0 to eth1 (external to internal)?
   In other words, should I rather change the policies to DROP and apply the two "firewalling" rules I mentioned above or is the lack of them not affecting security?

Thanks for clarification!

Answer 1

1. Yes it is, however, the machine must be on the same subnet as you on the ISP side. But in that case, the attacker could simply forge his source IP addresses to be yours or use an unallocated address instead. However, as your rules are written, an external attacker could browse your LAN, however he will have to cope with the fact that your server may masquerade packets on the return path. Thus, you should drop packets going to 192.168.0/16 from eth0 using iptables (no, using policy routing is too late here).

2. Forwarding invalid packets could result in private addresses leaking on the internet, or untranslated packets reaching the hosts. MASQUERADE may refuse to masquerade/unmasquerade invalid packets, or these invalid packets may not even reach the nat table. It is generally a good idea to at least drop packets in the INVALID state. Then only accept packets from eth0 with ESTABLISHED or RELATED state. I don't think it could have any security issue if the hosts in your LAN behave correctly, but i would do it anyway.

Answer 2

1) short answer "the whole world" - no, people in your external network, yes.

You can only set the gateway to be in your current LAN, so anyone from externalNet can set your box as a gateway, and even access the machines behind it (for example, he can access 192.168.0.2 behind the NAT - packets will get forwarded, but packets returning will be NATed to externalNet-ip, which he will have to translate again - which is doable).

The "-s" rule will fix the 'proxy' issue, but you should also block all packets coming to eth0 with 192.168.0.0/24 as the destination.

2) It depends. If you trust the clients behind NAT, and wish to have no restrictions, then it's fine. If you wish to block/only allow certain services, you have to block them (e.g. allow only destination tcp ports 80,443 and tcp/udp port 53 out, etc, and block everything else).

If you only allow established and related connections on the outgoing traffic, there will be no way to establish the connection at all, so nothing will go through.

Answer 3

1) Yep. ISP ethernet part - MAC addr is used for gateway transport.

2) I would recommend to take a look at default configuration in RedHat/Fedora/CentOS distributions, they know what and why are they doing it: https://fedoraproject.org/wiki/How_to_edit_iptables_rules?rd=User_talk:Rforlot

BTW: DO NOT USE REJECT WITH FORWARD CHAIN http://bugs.centos.org/view.php?id=5636

Answer 4

If I am reading correctly assuming you were to enact those proposed rules, it should alleviate your restlessness.

You have a default policy to drop anything hitting the INPUT or FORWARD chain.

Then you only allow the forwarding of RELATED, ESTABLISHED packets that come in on your external interface and leave via your internal interface.

So the only way NEW packets get forwarded is then covered by the last rule, only packets that come in via your internal interface and leave via your external interface will be forwarded.

So even if a host on the external network tried to use your host as a gateway, a NEW packet would arrive on eth0, hit the forward chain and then get dropped because it's satisfied no rule.