NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
true, but it's not as good as disabled ;) Sent from my iPhone On Sep 28, 2009, at 5:14 PM, Bret Whissel <bret@xxxxxxxxxxx> wrote:
One could reduce portmapper/rpcbind exposure by configuring hosts.deny and hosts.allow to disable access to ports 111 and 388 to ALL, and enabling access to 111 and 388 to upstream/downstream sites. (I'm confident that rpcbind is generally TCPwrappers-enabled on supported platforms; anyone know if LDM is?) Bret On Mon, 2009-09-28 at 16:21 -0500, Peter Laws wrote:Tyler Allison wrote:I've run LDM without portmapper/rpcbind given they are both ginormous security risks. It delays the startup/shutdown and other admin functions since LDM tries to RPC but fails, then it tries again, etc...until it figures out it is never going to work and defaults to 388 and everythingworks fine afterwards. Personally, I'd rather see it assume 388 and fall back toportmapper/rpcbind in the event of 388 failure, but that's just me :)Actually, Steve E wrote to me off-list and indicated that this is exactlyhow it works. Change in the code at some point?? I'd still like to disable it. :-)_______________________________________________ ldm-users mailing list ldm-users@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
ldm-users archives: