Tip: Randomizing and firewalling your tcp port range

scottman · 10-01-2004, 02:00 PM

Hi all,

This post is geared toward people who write their own IPTABLES scripts and want to try a method to secure their ruleset even further. What it does is change the default source ports that your tcp applications use to connect to a host, and allow you to filter traffic based on this new port range. By default their are tens of thousand of ports that
are available to them, making it almost pointless to use that in an existing rule. The script that follows can easily be changed to open more or less ports as needed etc, but I've found that if I have only a small amount of ports open, my applications will just start at the begining of the range. Also, this is useful only in the INPUT and OUTPUT chains, as a gateway/router would have no idea of knowing the new range.

I've tested this with the following applications:
FireFox
ThunderBird
Whois

Here's how I do it:

Code:

port_min=$[RANDOM%24232+32768]
port_max=$[port_min+2000] 
PORT_RANGE="$port_min:$port_max"

echo "$port_min $port_max" > /proc/sys/net/ipv4/ip_local_port_range

unset port_min
unset port_max

$IPT -A OUTPUT -p tcp       --sport $PORT_RANGE \
               -m multiport --dports 20,21,25,110,43,80,443 \
               -m state     --state NEW,ESTABLISHED \
               -j ACCEPT

$IPT -A INPUT  -p tcp        --dport $PORT_RANGE \
               -m multiport  --sports 20,21,25,110,43,80,443 \
               -m state      --state ESTABLISHED \
               -j ACCEPT

This allocates 2000 ports between 32768 and 57000 to be used by email, web, ftp and whois. Using $PORT_RANGE I am able to use the new range in my ruleset.

If anyone can think of any problems with this let me know, anyone is free to use it wherever and however they want..

chort · 10-01-2004, 04:42 PM

You're going to need a lot more than 2000 ephemeral ports if the machines behind the firewall stay up for more than a few days at a time, or if there are more than one or two machines. Other than that, the concept looks nifty.

sh1ft · 10-01-2004, 06:06 PM

hmm I'm getting errors when I run this:

Code:

/etc/ipkungfu/custom.conf: line 30: proc/sys/net/ipv4/ip_local_port_range: No such file or directory

I've checked and yes the file in questions is there. Strange.

scottman · 10-01-2004, 06:38 PM

Hrm, sh1ft, do you have a / before the proc? IE.

/proc/sys/net/ipv4/ip_local_port_range

It looks like your trying

proc/sys/net/ipv4/ip_local_port_range

Chort, I see your point, right now I'm using it on a workstation that is behind a gateway/firewall. I've only used it on the workstation, as I have no way ot letting the firewall know which ports to allow in the FORWARD chain, and changing anything there would effect the wIndoze boxes on my home network. As far as the ports, I noticed when testing it with a 100 port range, it cycled back to the begining of the range when it ran out. So by that logic should I base the amount of open ports on how many apps I have running at once? Or is reusing old ports going to cause me problems somehow?

sh1ft · 10-01-2004, 10:17 PM

Thanks dude, that fixed it, dumb error in copy + paste I should have seen.

Just out of curiosity, what exactly would this defend against, specifically? It's interesting and seems like it would make my box tighter, but could you give a specific example/case of what this could prevent?

Capt_Caveman · 10-01-2004, 11:14 PM

I think this might actually make you less secure in certain circumstances. I can see how it might be helpful if you're rebooting often and starting out with the same source ports and only being online for limited time periods, thereby only using a limited port range. But for someone who doesn't reboot often, you're actually reducing the overall number of source ports in use (thereby increasing the likelihood of using a given port in that range (it will actually be 1/N, so as N decreases, the overall likelihood increases)). Since source port is basically a function of uptime and rate of port usage, it becomes extremely hard to guess the current source port unless the machine has been freshly rebooted. I think the PaX TCP source port randomization feature might be a better way to implement it. You'd still need to allow the full source port range, but the chance of predicting a source port will basically be nil.

For something like passive FTP where you have to open an entire range of ports to NEW connections in order to allow the data channel, this would definitely be useful. But since you're only allowing ESTABLISHED traffic on the INPUT chain, I don't think this gives you that much in the way of overall security.

scottman · 10-02-2004, 12:42 AM

Well, I kind of got the idea when sifting through logs and seeing the huge amount of traffic destined for ports such as 1026. I may be mistaken, but these seem aimed at default port ranges used with a certain "operating system", or cpus with low memory. While I haven't seen anything aimed at the linux defaults, I still figured if I could make my source range unpredictable, it would help avoid these things if they ever came about. It would also provide one more controlled parameter for use in my rulesets.

Capt_Cavemen I see your point, a possible solution would be to call the script from cron periodically, and/or increase the range. However before I do any of that I'm going to check out the PaX randomizer you were talking about.

As far as the passive ftp, I have a seperate rule using the helper match, ESTABLISHED,RELATED state tracking and the dynamic source port. I think IRC works the same way as passive ftp, so it would be helpful there as well. I somehow feel insecure with these two services though.

Thanks for the feedback