mogse (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} mogse) wrote,@ 2004-11-05 14:35:00 |
|
PortRanges rant
Hello, i'm going to take up a rant something that many people are bugging me about, port ranges.
From what i see there's 2 scenaries where you'd need them:
* scenario 1: you only have 1 public ip but you have multiple computers
* scenario 2: you are under the impression that using a port range will "increase security" (what's up with that?)
In scenario 1, i'm pretty sure you can fix the issue by setting the local port range in /proc/sys/net/ipv4/ip_local_port_range (i have no need for portranges personally, so i haven't bothered with this, it's usage seems obvious though).
In scenario 2 i think you're misguided. You could use iptables locally to match (outgoing packets only, although this might be enough) and this would give you better security (unless you can't trust iptables). Also, using a small port range increases the chance of data connection hijacking, although there chance of this is pretty large in other cases aswell, http://www.google.com/search?q=data+con
And from a programmers perspective, i have found no easy way to code port range, you have to guess what ports are free, although you can to keep track of which ports your own application uses it's a mess to do this, and if you guessed a port which was in use, you have to brute force your way through the jungle of used ports to find a port not in use. The kernel does this MUCH more effectively. Although this overhead is problably not so in a bigger picture.
However some people need this anyways, and zubov has implemented this guess and brute force approach in drftpd CVS. There should be an implementation that uses the kernel's anonymous ports (listen on port 0 and kernel will do the work for you) and it's the approach i'll be using. :)
If you think drftpd already has port range support, it does, but it's ugly, it implements keeping track of used ports, guessing, but not bruteforcing. Since it's ugly it might leak ports over time but this has not been reported by anyone.
Hello, i'm going to take up a rant something that many people are bugging me about, port ranges.
From what i see there's 2 scenaries where you'd need them:
* scenario 1: you only have 1 public ip but you have multiple computers
* scenario 2: you are under the impression that using a port range will "increase security" (what's up with that?)
In scenario 1, i'm pretty sure you can fix the issue by setting the local port range in /proc/sys/net/ipv4/ip_local_port_range (i have no need for portranges personally, so i haven't bothered with this, it's usage seems obvious though).
In scenario 2 i think you're misguided. You could use iptables locally to match (outgoing packets only, although this might be enough) and this would give you better security (unless you can't trust iptables). Also, using a small port range increases the chance of data connection hijacking, although there chance of this is pretty large in other cases aswell, http://www.google.com/search?q=data+con
And from a programmers perspective, i have found no easy way to code port range, you have to guess what ports are free, although you can to keep track of which ports your own application uses it's a mess to do this, and if you guessed a port which was in use, you have to brute force your way through the jungle of used ports to find a port not in use. The kernel does this MUCH more effectively. Although this overhead is problably not so in a bigger picture.
However some people need this anyways, and zubov has implemented this guess and brute force approach in drftpd CVS. There should be an implementation that uses the kernel's anonymous ports (listen on port 0 and kernel will do the work for you) and it's the approach i'll be using. :)
If you think drftpd already has port range support, it does, but it's ugly, it implements keeping track of used ports, guessing, but not bruteforcing. Since it's ugly it might leak ports over time but this has not been reported by anyone.
