~ :> + int rover = tcp_port_rover+jiffies%(high-low);
~ :>
~ :> do { rover++;
~ :> if ((rover < low) || (rover > high))
~ :
~ :I'm not qualified to comment whether or not randomizing the port numbers
~ :would be a good idea.
well, it exposes (at least) some problems with ftp. Both client (active
mode) and server (passive mode). While user X is connecting to server to
fetch/put files, user Y could figure out the current binded port number by
simply connecting to the same server and issuing `pasv'. Now he knows that
next ports which would be used in transactions are current+x, where is is
number of transactions which took place since the `pasv' command was
issued. Now he just attempts to connect to current+1 .. current+10
(depends on how heavily the server is loaded) ports simultaneously until
one of connects doesn't get rst. Once he managed to connect, he could
receive/transmit the files, which user X is about to `get' or `put'. I
don't think it's a good idea to leave such problem opened.
~ :However, if you're going to do it, wouldn't it be better to use /dev/random
~ :instead of anything based on the clock? Bad randomness isn't much better
~ :than no randomness.
umm.. while trying to bind several ports in row with while(..) bind(..) I
got following numbers:
2503,2852,3201,3550,3899,4248,4597,4946,1108,1457
looks enough `random' to me for the case. Several routines in linux kernel
(f.e. net_random() in linux/net/core/utils.c) use timer to generate random
numbers. :) I could rework the patch to use /dev/random instead though :)
thanks for comments..
F
--
* Some day this will be a full-fledged user tracking system..
- <linux/sched.h>
http://www.kalug.lug.net/fygrave/
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
