[Xorp-users] open ports

[Orion Hodson]

On Aug 10, 2004, at 7:25 AM, Emmanuel Dreyfus wrote:

> Hi
>
> I installed xorp-1.0 as an IPv4 PIM-SM router on NetBSD. It works fine,
> apart from the bug #99 (if build with IPv6 enabled, it won't work on
> an IPv6-unaware kernel, ignoring the configuration directivea that 
> disable
> IPv6s).
>
> Now I have one last concern: it opens a lot of TCP ports:
> $ netstat -na|grep LISTEN
> tcp        0      0  193.54.89.1.64040      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64046      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64052      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64054      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64060      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64062      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64066      *.*                    
> LISTEN
> tcp        0      0  *.12000                *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64071      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64073      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64076      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64077      *.*                    
> LISTEN
> tcp        0      0  193.54.89.1.64079      *.*                    
> LISTEN
> tcp        0      0  127.0.0.1.19999        *.*                    
> LISTEN
>
> I'm a bit paranoid on the security front, and I'm absolutely sure I
> want no remote control of xorp. How do I close these ports? Or at 
> least,
> how do I bind them only to 127.0.0.1?

The are ports used for IPC.  There's a co-ordinator process that 
advertises the ports to other xorp processes.  The default interface is 
chosen to be the first interface that matches some hardcoded criteria.  
The accept() code for each of these sockets checks the incoming IP and 
shouldn't accept connections that are not from the same interface 
address (and maybe loopback, I don't recall).  However, loopback would 
be better from a DDOS perspective.

The default IPC interface is accessed and modified through 
if_get_preferred and if_set_preferred (sockutil.{hh,cc}).  A revised 
version of the default interface picking code could check loopback 
first and use it if available and if not fall back to the current 
default value.

In general, having an argument for all XORP processes at the 
command-line to set this address would probably be useful.  It's a bit 
of tedious chore, but going the extra mile and adding a common 
command-line parser with standard argument handling would fix this and 
would be a good idea anyway.

Any takers?
	Orion