INFO-VAX Fri, 19 Jan 2007 Volume 2007 : Issue 38 Contents: Re: DECWindows SET/DISPLAY & CREATE/TERM/DETACH problem on Alphaserver DS10L Re: File rename fault tolerance?? Re: Nonstop UNIX takes another loss Securing router/switch config files via TFTP on VMS Re: Securing router/switch config files via TFTP on VMS Re: Securing router/switch config files via TFTP on VMS Re: Securing router/switch config files via TFTP on VMS ---------------------------------------------------------------------- Date: 19 Jan 2007 00:59:24 -0800 From: "urbancamo" Subject: Re: DECWindows SET/DISPLAY & CREATE/TERM/DETACH problem on Alphaserver DS10L Message-ID: <1169197164.111926.227630@v45g2000cwv.googlegroups.com> The VPN problem must have been a hiccup - this morning everything worked fine. Thanks again for all the help. Regards, Mark. ------------------------------ Date: 19 Jan 2007 07:32:42 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: File rename fault tolerance?? Message-ID: In article <1169151429.398844.106240@q2g2000cwa.googlegroups.com>, "Don" writes: > > If the system is powered off (or similar failure) in the middle of this > operation, and assuming the disk still functions after reboot, will one > of the files exist? Yes, the file will exist. Nothing you are doing will remove the file, it's header, or its INDEX.SYS entry. At least one of the names will be entered in the directory. If the directory entries are located in two different physical blocks in the directory file there is a small possibility that both entries will exist, in which case one of them will look like an alias (the header has to get updated, it can only back link to one of them). I've endured a lot of power offs and some bad disk blocks and never seen this happen. I'm sure you've got much more importants things to worry about somewhere else on your job. With VMS your data is safe. ------------------------------ Date: Fri, 19 Jan 2007 20:50:18 +0200 From: "Teijo Forsell" Subject: Re: Nonstop UNIX takes another loss Message-ID: "Robert Deininger" wrote in message news:rdeininger-1701072017170001@dialup-4.233.173.68.dial1.manchester1.level3.net... > In article <1169065892.501523.148290@a75g2000cwd.googlegroups.com>, > "n.rieck@sympatico.ca" wrote: > >>Robert Deininger wrote: >>> In article <1169042285.377185.315540@51g2000cwl.googlegroups.com>, >>> "n.rieck@sympatico.ca" wrote: >>> >>> >Nonstop UNIX takes another loss as the Toronto stock exchange moves to >>> >LINUX on AMD Opteron or Intel Xeon >>> > >>> >http://www.itbusiness.ca/it/client/en/home/News.asp?id=41862 >>> >>> I wonder what they mean by "HP NonStop Unix". That name isn't familiar > to me. ... Tandem has two different hardware lines: PUMA and Himalaya. Himalayas run the NonStop Kernel aka NSK, but the PUMA series runs the NonStop-UX, which indeed is another variation of some common UNIX breed (which could the System V that someones mentioned, but I don't know that). The PUMA series definitely is much more unknown. Regards, Teijo ------------------------------ Date: Fri, 19 Jan 2007 05:28:58 -0500 From: JF Mezei Subject: Securing router/switch config files via TFTP on VMS Message-ID: <45b09d7b$0$5289$c3e8da3@news.astraweb.com> Many routers/switches interface via TFTP to save/load config files. These config files often contain clear text sensitive information. TFTP is an inherently insecure protocol. And the files that are in those "public" directories have to be accessible by the TFTP account. Is there a well established philosophy on how to manage such files to prevent them from being publically accessible ? ------------------------------ Date: Fri, 19 Jan 2007 08:07:12 -0500 From: Javier Subject: Re: Securing router/switch config files via TFTP on VMS Message-ID: JF Mezei wrote: > Many routers/switches interface via TFTP to save/load config files. > These config files often contain clear text sensitive information. > > TFTP is an inherently insecure protocol. And the files that are in those > "public" directories have to be accessible by the TFTP account. > > Is there a well established philosophy on how to manage such files to > prevent them from being publically accessible ? If using IOS devices, switch to scp. -jav ------------------------------ Date: 19 Jan 2007 07:40:02 -0600 From: koehler@eisner.nospam.encompasserve.org (Bob Koehler) Subject: Re: Securing router/switch config files via TFTP on VMS Message-ID: <$RLBRYchmPrS@eisner.encompasserve.org> In article <45b09d7b$0$5289$c3e8da3@news.astraweb.com>, JF Mezei writes: > > Is there a well established philosophy on how to manage such files to > prevent them from being publically accessible ? 1) Make sure the file protections are correct. 2) Make sure you trust all the people who have the ability to override the file protections. 3) Make sure you trust all the people who have physical access to the computer; keep it in a locked computer room. 4) Make sure you trust all the people who have access to the system's backup media (tape, CD, DVD, whatver you're using); keep those in a different locked location. 5) Make sure you trust all the people who have physical access to the network (that includes all those network cables in offices, conference rooms, and running down the hallway ceiling between rooms). That's usually the hardest one, it can be impossible to put the hallway in a locked room. Or better, buy network products that don't have this problem. ------------------------------ Date: 19 Jan 2007 09:47:15 -0600 From: Kilgallen@SpamCop.net (Larry Kilgallen) Subject: Re: Securing router/switch config files via TFTP on VMS Message-ID: In article <$RLBRYchmPrS@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes: > In article <45b09d7b$0$5289$c3e8da3@news.astraweb.com>, JF Mezei writes: >> >> Is there a well established philosophy on how to manage such files to >> prevent them from being publically accessible ? > > 1) Make sure the file protections are correct. > > 2) Make sure you trust all the people who have the ability to > override the file protections. > > 3) Make sure you trust all the people who have physical access to > the computer; keep it in a locked computer room. > > 4) Make sure you trust all the people who have access to the > system's backup media (tape, CD, DVD, whatver you're using); > keep those in a different locked location. > > 5) Make sure you trust all the people who have physical access to > the network (that includes all those network cables in offices, > conference rooms, and running down the hallway ceiling between > rooms). That's usually the hardest one, it can be impossible to > put the hallway in a locked room. > > Or better, buy network products that don't have this problem. Translation: Make sure you trust the competence of the people who designed the network products. ------------------------------ End of INFO-VAX 2007.038 ************************