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 fedora-devel-list
mailing list