EMC Networker security exploit that “Remote access”

If you didn’t care when you installed EMC networker software, some consultants enter an option *@* for every client, this means that every networker client on the your network can restore data from any other clients. So, anybody can restore data of your important servers, then they can lookup and/or copy your important datas.

You can check and change this option on “EMC Networker Administration –> Configuration –> Clients” then double click on client(or right click and select Modify Client Properties) and select Globals(2 of 2)


remote access       (read/write, string list)
              This  attribute  controls who may back up, browse, and recover a
              client's files.  By default this attribute  is  an  empty	 list,
              signifying that only users on the client are allowed to back up,
              browse, and recover its files.   Additional  users,  hosts,  and
              netgroups	 may  be  granted  permission  to access this client's
              files by adding their names to this attribute.   Netgroup	 names
              must  be	preceded by an ampersand ('&').	 Each line specifies a
              user  or	a  group  of  users,  using  one  of  these   formats:
              user/host@domain , group/host@domain , user@host , user@domain ,
              group@host , group@domain , &netgroup (only available  on	 plat-
              forms that support netgroups) , user_attribute=value[, ...].

              where  user is a user name; host is a host name; group is a user
              group name; domain is a domain name; user_attribute can be user,
              group,  host,  nwinstname, nwinstancename, domain, or domaintype
              (type of the domain, NIS or WINDOMAIN).

              The user attributes: nwinstname and nwinstancename are  used  to
              indicate	a  NetWorker  instance name.  The value that should be
              entered for either of these  attributes  is  the	value  in  the
              "name"  field  in	 the  NSRLA  resource  for the machine where a
              matched user is connecting from.

              value can be any string delimited by white space. If  the	 value
              has  space in it, then it can be quoted with double quotes.  The
              value may contain wild cards, "*".  Entering just	 a  user  name
              allows  that user to administer NetWorker from any host (equiva-
              lent to user@* or */user	or  user=user).	  Netgroup  names  are
              always preceded by an "&".

              The  format:  user_attribute=value[, ...] is more secure because
              the format is not overloaded. For example, if test@test.acme.com
              is entered, then any users in the test group or users named test
              and that are in the domain;  test.acme.com  or  from  the	 host;
              test.acme.com will match this entry.
              Example: The entries:

              remote access: mars, *@jupiter, sam@pluto, */root;

              remote  access:  host=mars, host=jupiter, "user=sam,host=pluto",

              are equivalent.

How to Expand a Striped Meta on EMC VMAX (Disk büyütme işlemi)

1. Create new meta devices that you will add to disk:

symconfigure -cmd “create dev count=X, size=cyl, emulation=FBA, config=TDEV, mvs_ssid=0, device_attr=SCSI3_persist_reserv;” prepare / commit

·        Change the X and Y to the correct values for your environment

·         Make a note of the device IDs, I’ll call them AAAA and BBBB, assuming you created two

Example: symconfigure -sid 096 -cmd “create dev count=8, size=27776 cyl, emulation=FBA, config=TDEV, mvs_ssid=0, device_attr=SCSI3_persist_reserv;” commit

New symdevs: 01D1C:01D23 [TDEVs]


2.      Create new BCV meta devices that exactly same as Striped Meta that you want expand :

symconfigure -cmd “create dev count=1, size=Y cyl, config=BCV+TDEV, emulation=FBA, mvs_ssid=0;” prepare / commit

·        Change the Y to the current size of the meta you are expanding

·         Note the device IDs, I’ll call them XXXX and YYYY, assuming auto meta settings created two devices

Example: symconfigure -sid 096 -cmd “create dev count=8, size=27776 cyl, config=BCV+TDEV, emulation=FBA, mvs_ssid=0;” commit

New symdevs:  01AAC-01AB3


3.       Create volume from BCV meta devices:

symconfigure -cmd “form meta from dev XXXX, config=striped, stripe_size=1 cyl; add dev YYYY to meta XXXX;” prepare / commit

you can make 2nd and 3th steps with unisphere:

a.        Select Storage -> volumes -> “Create meta volume” under BCV+TDEVS 


b.        Select “Create volumes” and “Using New Virtual Volumes”.


c.       Enter Member Count and Member Capacity that exacly same as stiraped meta that you want to expand , then select BCV+TDEV.

Number of Meta Volumes 1 * Meta Volume Capacity Meta Volume Member Count including Head Meta Volume Member Capacity 2776JJ Calculated Meta Volume Capacity 2034 GB ¡ 222 S Cyl * Volume Configuration B+TDEV

d.        Select “Run Now”, then copy device IDs.


4.      Bind this meta to a pool – symconfigure -cmd “bind tdev XXXX to Pool <POOL> preallocate size =ALL allocate_type = persistent;” prepare / commit

·         Replace <POOL> with one of your pool names

with unisphere:

a.        Select Bind under Storage -> Thin Pools -> Pool:

Rebalance Variance (1-50) 1 Maximum Volumes per Rebalance Scan .. 256 Pool Reserved Capacity Enabled ü Expand Bind

b.        Enter Volume ID, then select “Find Volumes” :

Thin Volunıes Wizard 1 Find Volumes Find volumes that match the following criteria Capacity equal to GB %. Volume ID 3335 (e.g. 001 or 001-OFF or 001 ,003-OTF) Volume Identifier Name Additional Criteria Select Category Add Another Clear All Find Volumes> Cancel Help


c.    Select related volume, “Allocate Full Volume Capacity” and “Persist preallocated capacity …” , then click Bind :

Selected 0 items Allocate Full Volume Capac) Persist preallocated capacity through reclaim or <Modify Criteria Bind Cancel Help


Not: if Dynamic RDF is enabled you will get  “ Error occurred while Defining change number 1:

   The devices being acted on are a mixture of dynamic and Non dynamic DRDF devices

   Device 1D1C generated the failure”

errors at 5th step. So you must enable Dynamic RDF on AAAA:BBBB devices

To enable Dynamic RDF :

symconfigure -sid aaa -cmd “set device AAAA:BBBB attribute=dyn_rdf;” commit

Example: symconfigure -sid 096 -cmd “set device 01D1C:01D23 attribute=dyn_rdf;”  commit

5.     Now you can add new meta devices:

symconfigure -cmd “add dev AAAA:BBBB to meta ZZZZ, protect_data=TRUE, bcv_meta_head=XXXX;” prepare / commit

·         AAAA and BBBB are the device IDs created in step 1

·         ZZZZ is the device IDs of the meta head you want to expand

·         XXXX is the device IDs of the BCV meta head created in step 3

·         Example: symconfigure -sid 096 -cmd “add dev 1D1C:1D23 to meta 08BC, protect_data=TRUE, bcv_meta_head=1AAC;” commit


6.    After expand operation you can unbind BCV volume, then dissolve and delete BCV meta devices. Look at: “EMC VMAX – Removal Of A TDEV”