[LINK] OT(?) UDP above port 32767

Glen Turner glen.turner at aarnet.edu.au
Wed Feb 7 13:13:24 AEDT 2007


Daniel Rose wrote:
> I've come across an odd problem and the usual resources (Google, uni
> books) don't help me much.  
> 
> Can some of you Unix elders explain to me why UDP traffic to/from ports
> above or below 32767 should be treated differently by a firewall?
> Specifically, what might be special about ports above this number which
> makes the traffic permissable, where traffic involving a port below
> 32767 is blocked?
> 
> Linux selects a port above this magic number for my application to send
> a UDP client request from, Windows does not.
> 
> Thanks in advance...

When a port is not specified when connecting to a remote
machine the operating system needs to select a port to use.

For example, when connecting with a remote web server the
binding requested by the application will be

  Source IP address = let the OS choose
  Source TCP port = let the OS choose
  Destination IP address = www.example.edu.au's IP address
  Destination TCP port = HTTP well known port (80)

When asked to "let the OS choose" the operating system uses
an "ephemeral port". Differing operating systems use differing
ranges for ephemeral ports -- the main requirement being
not to use a port number that another process might try
to bind with explicitly.  So the OS will use a range like
32768 to 61000 stay well clear of ports used by listening
processes.  Differing operating systems use differing
ranges, for example Windows uses 1024 to 4999.  The RFCs
give no advice on the range -- they don't even require
a range, merely that a source port unique to this connection
be used.

Note that this is convention -- any process can explicitly
ask for a source port > 1023. On most operating systems
only a privileged process can ask for a port < 1024 (not
that privileged should imply much trust, even MP3 players
can have web servers).

You'll often see outgoing firewall rules which try to prevent
unauthorised servers on a host -- so if it is compromised the
bot has difficulty getting commands from the bot master. These
might code the ephemeral port range for that particular machine
(since the OS is known, the convention is known).  Having a rule
covering all machines is rather difficult because of the wide
range of operating system conventions, which is a problem if you
are trying to control peer-to-peer traffic.

Since the ephemeral ports are merely a convention, I'm not
sure there would be any safe use on an incoming firewall
rule unless it is to a FTP server (which should be in the
DMZ anyway). I suppose you could deny all incoming connections
to them, but that is merely a special case of denying all
unknown incoming connections.

Cheers, Glen



More information about the Link mailing list