Are you Monitoring RAP?

 NetWorker, Security  No Responses »
Jul 032009
 

Introduced in NetWorker v7 was a feature called “Monitor RAP”. There’s two unfortunate aspects to this setting in the NetWorker server resource (“NSR”):

  • It is not enabled by default;
  • The setting name obfuscates the purpose of the setting for most users.

Personally, I would have preferred when this option was made available that it was called “Audit Changes”, and that it was enabled by default.

In the NetWorker management console, with diagnostic mode enabled, this option is available in the first tab of the NetWorker server properties:

Monitor RAP setting

Monitor RAP setting

With this setting enabled, NetWorker maintains a new log, rap.log, within the logs directory. This tracks changes that are made to the NetWorker configuration, as they are made.

Here’s an example:

06/30/2009 06:49:19 PM MONITOR_RAP: preston@archon CHANGED 'NSR group'
resource, Staging Development:
 autostart: Enabled;
 autostart: Disabled;

This tells us that at 18:49:19 on 30 June 2009, user ‘preston’ on host ‘archon’ changed the group ‘Staging Development’, changing ‘autostart’ from ‘Enabled’ to ‘Disabled’.

This means that from the NetWorker level*, you can easily keep track of who does what to the NetWorker configuration. Interestingly, you can also use this information to also track self-changes to the system – i.e., where NetWorker updates its own configuration. As an example, if you use a license manager, then whenever NetWorker updates/checks its licenses against the license server, you’ll get entries in the logs such as:

06/30/2009 05:10:00 PM MONITOR_RAP: root@nox CHANGED 'NSR license' resource,
Autochanger Module, 40 slots/40:
 checksum: \
"'j&P_-QFc]]D~GIQ\\_[q-jMFx;ajW%U~\\1^UvCm`dJEwg/
T#XGMpaVYet\\l]M\\w\\{QQ\\\\\
WuR]\"Ax*@^XX'[ZAG388M)I6fvztWrC9q\"G3PeML!wl
{P6L0]JU9a9[{WYZ";
 checksum: \
"Z$EP_Jts]gYNZV_ATn]AZSxcTorL#f2(\"8/PTcIYec}K+}
e_GGsJ$6IC)QLTz\\_aS?[|lc^\\Z\
rN9}A~L@}?b^Vlud-e:SD+Js<U]T!eXR\"y/,bQHO
0_CShOlw?U1h\\g?";

Using the Monitor RAP setting allows you to easily monitor changes to the NetWorker configuration, and I believe that every NetWorker site should always have this setting enabled.

–
* Auditing is also available within NMC. For maximum auditing, I always recommend that both options be used.

 Posted by at 16:38  Tagged with: , ,

Your datazone is only as secure as your NetWorker server

 NetWorker, Policies, Security  1 Response »
Jun 262009
 

A topic I discuss in my book that’s worth touching on here is that of datazone security.

Backup is one of those enterprise components that touches on a vast amount of infrastructure; so much so that it’s usually one of those most broadest reaching pieces of software within an environment. As such, the temptation is always there to make it “as easy as possible” to configure. Unfortunately this sometimes leads to making it too easy to configure. By too easy, I mean insecure.

Regardless of the “hassle” that it creates, a backup server must be highly secured. Or to be perhaps even blunter – the entire security of everything backed up by your backup server depends on the security of your backup server. Having an insecure NetWorker server, on the other hand, is like handing over the keys to your datacentre, as well as having the administrator/root password for every server stuck to each machine.

Thinking of it that way, do you really want the administrator list on your backup server to include say, any of the following?

  • *@*
  • *@<host>
  • <user>*@

If your answer is yes, then you’re wrong*.

However, datazone security isn’t only about the administrator list (though that forms an important part). At bare minimum, your datazone should have the following security requirements:

  1. No wild-cards shall be permitted in administrator user list definitions (server, NMC).
  2. No client shall have an empty servers file (client).
  3. No wild-cards shall be permitted in remote access user list definitions (client resources).

Note: With the advent of lockboxes in version 7.5, security options increase – it’s possible, for instance, to have passwords for application modules stored in such a way that only the application module for the designated host can retrieve the password.

–
* I do make allowance for some extreme recovery issues that have temporarily required users to enter wild-card administrators temporarily where it was not possible to wait for a bug fix.

 Posted by at 17:27  Tagged with: , , , ,

(In)securing your daemon.raw with nsr_render_log -z

 NetWorker, Security  2 Responses »
Jun 042009
 

As you may know, the jump from NetWorker 7.3 to 7.4 saw the introduction of a language/locale-neutral log format in NetWorker, referred to as “raw” format. The primary purpose of this format is to allow logs to be generated by NetWorker that can then be rendered into a support-addressable language for EMC.

One of the options for nsr_render_log is “-z”, which according to the man page:

-z   Obfuscate secure information. Hostnames, usernames and network
     addresses shall be aliased.

In theory, this replaces hostnames with neutral hostnames – e.g., the backup server gets renamed to ‘host1′.

If you’re relying on nsr_render_log to totally mask your site details, don’t. You still need to manually review the file and determine whether there are any references to hostnames, usernames, etc., that need to be modified.

Here’s a few examples of where details aren’t aliased:

  • Index paths in initial startup of the NetWorker server.
  • License count details in initial startup of the NetWorker server.
  • Entries of the form client:Saveset Name when referencing savesets starting, stopping, etc. This includes the server hostname, which “-z” mainly seems to be trying to masquerade (e.g., you’ll get lines like: ‘host1 nsrd cerberus:index:mars’).
  • The infamous “NSR peer information” entries.
  • Usernames from browsing for browsing recoveries and completing recoveries.

While I don’t normally like to poke sticks at NetWorker, this isn’t a good implementation of security. Security by obfuscation never is, but if you say you’re going to hide hostnames and usernames, you should at least make every effort to do just that. In fact, using the Australian vernacular, this is a very half arsed implementation of an advertised feature.

In short, if you’re needing to completely “secure” your daemon.raw output before sending to your support provider, don’t rely on -z, but instead do a manual search and replace.

As a starting point, you may want to consider a procedure such as:

  1. Using nsradmin, extract a list of all client names.
  2. Search and replace each client name with an arbitrary name in the daemon.raw file.
  3. Search for “done browsing” and extract the unique usernames.
  4. Map those unique usernames to arbitrary usernames, and search and replace in the daemon.raw file.

That will not likely replace everything, but will give you a good starting point.

 Posted by at 05:47  Tagged with:
 Newer Entries
© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha