No Trust/No HDR? ~ Answered: amber (solid confidence) — Nilesh Ozarkar gives a specific, sourced answer (sqlhosts security option s=6 plus a scoped hosts.equiv) directly addressing secure HDR trust; never confirmed by the original asker.

Advisory only.

Is it necessary to use either a hosts.equiv or .rhosts file to maintain a "trust" between two hosts which are members of an HDR pair? Is there any _secure_ method to establish and maintain the trust which the informixserver recognizes aside from using a dated technique that has well-documented vulnerabilities and well-known exploits? Do the DR encryption onconfig parameters have a bearing on this problem?

informix-list-bounces@iiug.org wrote on 03/01/2010 12:16:26 PM: > From: > > "red_valsen@yahoo.com" <red_valsen@yahoo.com> > > To: > > informix-list@iiug.org > > Date: > > 03/01/2010 12:20 PM > > Subject: > > No Trust/No HDR? > > Sent by: > > informix-list-bounces@iiug.org > > Is it necessary to use either a hosts.equiv or .rhosts file to > maintain a "trust" between two hosts which are members of an HDR > pair? Is there any _secure_ method to establish and maintain the > trust which the informixserver recognizes aside from using a dated > technique that has well-documented vulnerabilities and well-known > exploits? There is a way -- refer to http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.sec.doc/ids_am_032.htm In short, you need to set security option (s=6) in sqlhosts file and create hosts.equiv in $INFORMIXDIR/etc. > Do the DR encryption onconfig parameters have a bearing on > this problem? Encryption won't help in authentication, it's for data encryption only. For encryption -- refer -- http://publib.boulder.ibm.com/infocenter/idshelp/v115/topic/com.ibm.admin.doc/ids_admin_0946.htm HTH,: - Nilesh - > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list

Don't ever use .rhosts file. Host equiv only if you know that you're behind a good firewall and that you only do this for one application where you can control the entries in host.equiv. Both are very old and insecure. Especially .rhosts . Can you say "Morris Worm" http://spaf.cerias.purdue.edu/tech-reps/933.pdf http://en.wikipedia.org/wiki/Morris_worm The first link is to Gene Spafford's paper on what happened. The second is the typical wiki entry. If you take the time to read the paper, you'll understand some of the issues of the .rhosts and hosts.equiv. Not good and there are alternatives that exist which may replace this method. Now I'm going to show my age by saying that I used to have a 9 track of the worm and e-mails from admins talking about it.... ;-) -G > From: red_valsen@yahoo.com > Subject: No Trust/No HDR? > Date: Mon, 1 Mar 2010 10:16:26 -0800 > To: informix-list@iiug.org > > Is it necessary to use either a hosts.equiv or .rhosts file to > maintain a "trust" between two hosts which are members of an HDR > pair? Is there any _secure_ method to establish and maintain the > trust which the informixserver recognizes aside from using a dated > technique that has well-documented vulnerabilities and well-known > exploits? Do the DR encryption onconfig parameters have a bearing on > this problem? > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/201469228/direct/01/

red_valsen@yahoo.com wrote: > Is it necessary to use either a hosts.equiv or .rhosts file to > maintain a "trust" between two hosts which are members of an HDR > pair? Is there any _secure_ method to establish and maintain the > trust which the informixserver recognizes aside from using a dated > technique that has well-documented vulnerabilities and well-known > exploits? Do the DR encryption onconfig parameters have a bearing on > this problem? The "good" reply was already sent (at least in IIUG lists). In any case I would like to be pointed to those well-documented vulnerabilities and well-known exploits. My request has a catch as you might expect, but I honestly would like to be proven wrong. Thanks in advance. Regards.