Jeff Bryer wrote:
> If switching away from Windows as the NBU server is not an option,
> then try to minimize the threats as much as possible.

so that becomes the real question.

(1) how does one minimize the threats?

  (a) is it possible to control access from the unix server 
      (the backup client) adequately to minimize threats?

  (b) is is possible to configure the veritas connection in 
      such a way as to minimize threats?

  (c) or is it necessary to require that the Windows server 
      (that is the NBU server) be secured and certified as secure? 
      (and I realize this has to become a process).


---------------

(2) scenario: disastor recovery. suppose, for some reason, we had to
recover /etc/passwd and /etc/shadow using the NBU server and putting the
recovered files back on a unix server through the NBU client. can I do
that? what's to stop someone who has hacked into the system from doing
that? if they can do that, then they can gain total control. step 1,
recover the files locally on the NBU server (into which you have
hacked). step 2, add a user with the same uid as root and a password you
know encrypted into the shadow file. step 3, backup those files. step 4,
recover them to the unix server. step 5, login to the unix server as
root. step 6, do anything you want.

tripwire would catch that. but, by the time you have caught it, your
only completely safe recourse is to rebuild or recover the server from a
date before any of the hacking took place. you don't know what the
hacker has done between the time they got in and the time you noticed
and disconnected the server from the network. it would always have to be
regarded as a tainted system if you didn't rebuild it.



---------------

Chris Hoogendyk

-- 
   O__  ---- Network Specialist & Unix Systems Administrator
  c/ /'_ --- Library Information Systems & Technology Services
 (*) \(*) -- W.E.B. Du Bois Library
~~~~~~~~~~ - University of Massachusetts, Amherst

<choogend AT library.umass DOT edu>

---------------