RH Taroon Beta Open Ports

rhldevel at assursys.co.uk rhldevel at assursys.co.uk
Mon Aug 25 15:27:07 UTC 2003


On Mon, 25 Aug 2003, Steve Dickson wrote:

> Felipe Alfaro Solana wrote:
> >On Mon, 2003-08-25 at 13:50, rhldevel at assursys.co.uk wrote:
> >>I've just done a "complete" install of Taroon on a scratch box, with
> >>iptables firewalling disabled. The following services are listening on
> >>external network interfaces:
> >>
> >>Port       State       Service
> >>22/tcp     open        ssh
> >>68/udp     open        dhcpclient
> >>111/tcp    open        sunrpc
> >>111/udp    open        sunrpc
> >>123/udp    open        ntp
> >>1010/udp   open        unknown
> >>6000/tcp   open        X11
> >>
> >>ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient
> >>(both manually configured during install) are reasonably justified, IMHO,
> >>but what is the justification for having rpc.statd, portmap and X11
> >>listening by *default* (especially on a machine that hasn't been configured
> >>to use NIS)?

[snip]

> statd (i.e. nfslock) probably does not need to be running if NFS is not 
> configured but
> tunning off portmapper is a bit extreme... Not only do local process 
> expect portmapper
> to be there,

Which local processes? We've already heard about sgi_fam, and we already
know about NIS and NFS, but is this really worth leaving it listening on
external interfaces in a _default_ install?

> remote process also expect portmapper to be there ...

And I expect there have been similar arguments in Redmond regarding their
RPC implementation. In my experience it's not used commonly enough that it
deserves to be listening for random connections.

> The
> point being turning off portmapper could (and probably will) cause 
> unexpect process
> to fail in unexpect ways making very difficult to debug especially 
> during installation...

As a matter of course, I disable portmap and rpc.statd on any machine not
expected to perform NFS or NIS and have not noticed any side effects as a
result.

> Portmapper has been around quite a long time making it pretty bullet 
> proof...

Funny, 'cos in my universe, the portmapper is regarded as one of the most
vulnerable pieces of UNIX software, along with rpc.statd, sendmail and BIND.

> So I see no reason what so ever to turn off portmapper. Lets not make a
> system more difficult to deal with for simply no reason...

...but there is a reason - making new installs secure by default. For a
admin who's already configuring NFS or similar, the extra step of
chkconfig'ing portmap and rpc.statd isn't much of a burden.

> SteveD.

Best Regards,
Alex.





More information about the devel mailing list