0000715: ClearOS port forwarding creates security risk on internal LAN

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0000715

ClearOS

app-firewall - Firewall

public

2012-08-19 13:36

2015-05-25 15:02

Reporter

tracker

Assigned To

user2

Priority

normal

Severity

major

Reproducibility

always

Status

closed

Resolution

suspended

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0000715: ClearOS port forwarding creates security risk on internal LAN

Description

A ClearOS firewall "port forward" rule (not a "custom" rule, an external -> internal forward) basically translates into 3 types of iptables rules:

- A DNAT rule to map the external ip/port to the internal ip/port.
- Forwarding rules to get the packet forwarded to the internal interface.
- Spurious SNAT rules which have no effect on packets arriving on an external interface.

Unfortunately, these SNAT rules hide the source address of packets routed between internal interfaces. This can create a security risk, or other confusion if the device which is being forwarded to is accessed internally.

Steps To Reproduce

Need a gateway setup with >1 internal interface, lets say LAN and Hot LAN.
Also a device D on the Hot LAN that does http basic auth.
Also a couple of LAN clients L1 and L2.
Create a port forwarding rule from the external interface to the device D on the Hot LAN.
Connect to D from LAN client L1 (using D's internal address, not the external one), and authenticate.
Now connect to D from L2... no authentication required. Boo Hiss. D sees any access from the LAN as being from the address of the firewall itself.

Additional Information

Here's a worked example:

LAN eth0 10.51.8.1 / 24
Hot eth2 10.51.13.1 / 24
ext ip 1.2.3.4

Now create a port forwarding rule to a device on the hot LAN:

port 48101 -> 10.51.13.167:80

Here are the iptables rules created by ClearOS

$ sudo iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 5846K packets, 1786M bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp – any any anywhere 1.2.3.4 tcp dpt:48101 to:10.51.13.167:80

Chain POSTROUTING (policy ACCEPT 7292K packets, 448M bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT tcp – any any 10.51.8.0/24 10.51.13.167 tcp dpt:http to:10.51.8.1
0 0 SNAT tcp – any any 10.51.13.0/24 10.51.13.167 tcp dpt:http to:10.51.13.1

$ sudo iptables -L -v
Chain FORWARD (policy DROP 18 packets, 1080 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp – any eth0 anywhere 10.51.13.167 tcp dpt:http
0 0 ACCEPT tcp – any eth2 anywhere 10.51.13.167 tcp dpt:http

So, those SNAT rules do nothing useful as far as I can see. Certainly they never apply to packets arriving on the external interface. But they do hide the source address of any packet destined for 10.51.13.167 and routed from the LAN to the Hot LAN... to the device on the Hot LAN, any access from the LAN looks like it's coming frrom the firewall itself.

Looking at the code in firewall.lua, it's simple to fix, just delete the SNAT rule generation. The FORWARD rules could be cleaned up too, there's no need to generate one for each LAN interface, just create one rule for the destination ip/port without specifying interface.

Maybe this crept in because "forwarding rule" and "custom forwarding rule" got confused one fine day back in the Jurassic era?

Note that the spurious SNAT rules will have no effect at all if there's only one internal interface.

Relationships

Notes
(0001080) user2 2013-11-01 10:19	The SNAT rules makes it possible for systems on the LAN/HotLAN to use the external IP. Without those rules L1 could not use the public IP to connect to D. That's painful if a user is hosting a web site www.example.com/1.2.3.4 on the HotLAN -- LAN users would not be able to access www.example.com without some DNS hacks.

ClearOS Bug Tracker