RH Taroon Beta Open Ports
David T Hollis
dhollis at davehollis.com
Mon Aug 25 18:38:59 UTC 2003
Steve Dickson wrote:
> rhldevel at assursys.co.uk wrote:
>
>>> 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?
>>
> third party applications of our beloved customers... There are
> *probably* a few more
> applications other than NFS and NIS that need to advertise ports....
> Remember the
> RPC subsystem has been around for a very long time which means we
> really don't
> what we would be breaking by turning it off... Just because you don't
> know about
> something..... does not mean they don't exist....
Your missing the point here. No one is saying don't ship portmap or nfs
utilities. Just raising the question as to whether they should be
enabled by default.
>
>>> 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.
>>
> So we can assume that your system is an *exact* clone of every other
> linux system
> out there... so what works in your world will work everywhere.... I'm
> sorry but
> I just don't by your logic...
I also disable them on my systems since I don't typically utilize NFS
(nor NIS, or any other RPC based service) and I have not had any
problems either. Using the recent MS DCOM problems, MS' technical
information for the problem suggested a workaround of disabling DCOM
with the following nebulous disclaimer:
*Warning* If you disable DCOM, may you may lose operating system
functionality. After you disable support for DCOM, the following may
result:
* Any COM objects that can be activated remotely may not function
correctly.
* The local COM+ snap-in will not be able to connect to remote
servers to enumerate their COM+ catalog.
* Certificate auto-enrollment may not function correctly.
* Windows Management Instrumentation (WMI) queries against remote
servers may not function correctly.
(http://support.microsoft.com/default.aspx?scid=kb;en-us;825750)
It translates to most folks as "If I disable DCOM, no one knows what is
going to break". With a stock RH install, how many RPC using services
are available? NFS, NIS, sgi_fam, and?? Unlike MS, you know what will
not function if portmap is not running. 3rd party apps are certainly a
different ballgame, but that is the 3rd parties responsibility to
mention the requirement of portmap.
>
>>
>>
>>
>>> 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.
>>
> Educate me... How has it *recently* (i.e within the that 3 years)
> been exploited?
> And what damage was caused?
>
>>> 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.
>>
> Again.... NFS and NIS are not the only user of portmapper... We have
> to keep
> in mind the entire industry... not just or own little worlds....
>
>
> SteveD.
>
>
> --
> Rhl-devel-list mailing list
> Rhl-devel-list at redhat.com
> http://www.redhat.com/mailman/listinfo/rhl-devel-list
More information about the devel
mailing list