Skip to main content

Configure Control Center settings

After the initial setup, you need to configure Control Center settings. As Company Administrator, you can do the following:

  • Configure mail, proxy and other general settings.

  • Run or schedule a Control Center database backup.

  • Install security certificates.

Mail server

Control Center requires an external mail server to send email communications.

Note

It is recommended to create a dedicated mail account to be used by Control Center.

To enable Control Center to send emails:

  1. Go to the Configuration page.

  2. Select the Mail Server tab.

  3. Select Mail Server Settings and configure the required settings:

    • Mail server (SMTP)

      Enter the IP address or hostname of the mail server that is going to send the emails.

    • Port

      Enter the port used to connect to the mail server.

    • Encryption type

      If the mail server requires an encrypted connection, choose the appropriate type from the menu (SSL, TLS or STARTTLS).

    • From email

      Enter the email address that you want to appear in the From field of the email (sender's email address).

    • Use authentication

      Select this check box if the mail server requires authentication.

      You must specify a valid username / email address and password.

  4. Click Save.

Control Center automatically validates the mail settings when you save them. If the provided settings cannot be validated, an error message informs you of the incorrect setting. Correct the setting and try again.

Proxy

If your company connects to the Internet through a proxy server, you must configure the proxy settings:

  1. Go to the Configuration page.

  2. Select the Proxy tab.

  3. Select Use Proxy Settings and configure the required settings:

    • Address - type in the IP address of the proxy server.

    • Port - type in the port used to connect to the proxy server.

    • Username - type in a user name recognized by the proxy.

    • Password - type in the valid password of the previously specified user.

  4. Click Save.

Miscellaneous

From the Configuration page > Miscellaneous tab you can configure the following general preferences:

  • When an unavailable kit is needed

    You can configure an automated action for this situation by choosing one of the following options:

    • Download the package automatically

    • Notify the administrator and do not download

  • Concurrent deployments

    Administrators can remotely deploy security components by running installation tasks.

    Use this option to specify the maximum number of simultaneous deployments that can be performed at a time.

    For example, if the maximum number of concurrent deployments is set to 10 and a remote client installation task is assigned to 100 computers, Control Center will initially send 10 installation packages through the network.

    In this case, the client installation is performed simultaneously on a maximum number of 10 computers, all the other sub-tasks being in pending state.

    As soon as a sub-task is done, another installation package is sent, and so on.

  • Enforce two-factor authentication for all accounts

    The two-factor authentication (2FA) adds an extra layer of security to GravityZone accounts, by requiring an authentication code in addition to Control Center credentials.

    This feature requires downloading and installing either the Google Authenticator, Microsoft Authenticator, or any two-factor TOTP (Time-Based One-Time Password Algorithm) authenticator app - compatible with the standard RFC6238 - on the user's mobile device, then linking the app to the GravityZone account and using it with each Control Center login. The authentication app generates a six-digit code each 30 seconds. To complete the Control Center login, after entering the password, the user will have to provide also the authentication app's six-digit code.

    Two-factor authentication is enabled by default when creating a company. After that, at login, a configuration window will prompt users to enable this feature. Users will have the option to skip enabling 2FA for three times only. At the fourth login attempt, skipping the 2FA configuration will not be possible and the user will not be allowed to log in.

    If you want to deactivate the 2FA enforcement for all GravityZone accounts in your company, just uncheck the option. You will be prompted with a confirmation message before the changes come into effect. From this point on, users will still have 2FA activated, but they will be able to deactivate it from their account settings.

    Note

    • You can view the 2FA status for a user account in the Accounts page.

    • If a user with 2FA enabled cannot log in to GravityZone (because of new device or lost secret key), you can reset its two-factor authentication activation from the user account page, under Login Security section. For more details, refer to this section.

  • Users trust their browsers

    This option allows to trust the browsers used for connecting to Control Center. After enabling the Trust this browser check box on the login screen, users do not need to enter the six-digit code any longer until the interval expires.

    The maximum interval you can select is 90 days. When the interval expires, users must enter the six-digit code in addition to their credentials. When selecting Never, browsers and not trusted and users cannot skip two-factor authentication.

  • NTP Server Settings.

    The NTP server is used to synchronize time between all GravityZone appliances. A default NTP server address is provided, which you can change in the NTP Server Address field.

    Note

    For the GravityZone appliances to communicate with the NTP Server, 123 (UDP) port must be open.

  • Enable Syslog.

    By enabling this feature, you allow GravityZone to send notifications to a logging server that uses the Syslog protocol. This way you have the possibility to better monitor GravityZone events.

    To enable logging to a remote Syslog server:

    1. Select the Enable Syslog check box.

    2. Enter the server name or IP, the preferred protocol and the port Syslog listens to.

    3. Select in the format in which to send the data to the Syslog server:

      • JSON Format. JSON is a lightweight data-interchange format that is completely independent from any programming language. JSON represents the data in human readable text format. In JSON format, the details of each event are structured into objects, each object consisting in a name/value pair.

        For example:

        {
    "name":"Login from new device",
    "created":"YYYY-MM-DDThh:mm:ss+hh:ss",
    "company_name":"companyname",
    "user_name":"username",
    "os":"osname",
    "browser_version":"browserversion",
    "browser_name":"browsername",
    "request_time":"DD MMM YYYY, hh:mm:ss +hh:ss",
    "device_ip":"computerip"
}

        For more information, refer to www.json.org.

        This is the default format in GravityZone.

      • Common Event Format (CEF). CEF is an open standard developed by ArcSight, which simplifies log management.

        For example:

        CEF:0|Bitdefender|GZ|<GZ version>|NNNNN|Login from new
device|3|start=MMM DD YYYY hh:mm:ss+hh:mm
BitdefenderGZCompanyName=companyname suser=username
BitdefenderGZLoginOS=osname
BitdefenderGZAuthenticationBrowserName=browsername
BitdefenderGZAuthenticationBrowserVersion=browserversion
dvchost=computerip

        For more information, refer to ArcSight Common Event Format (CEF) Implementation Standard.

      In the Notifications chapter of the Administrator's Guide, you can view the available notification types for each format.

    4. Click the add.pngAdd button from the Action column.

Click Save to apply the changes.

Backup

To make sure all your Control Center data are safe, you may want to back up the GravityZone database. You can run as many database backups as you want, or you can schedule periodic backups to run automatically at a specified time interval.

Each database backup command creates a tgz file (GZIP Compressed Tar Archive file) to the location specified in the backup settings.

When several administrators have manage privileges over the Control Center settings, you can also configure the Notification Settings to alert you each time a database backup has been completed. For more information, refer to Configuring notification settings.

Creating database backups

To run a database backup:

  1. Go to the Configuration page in Control Center and click the Backup tab.

  2. Click the backup.pngBackup Now button at the upper side of the table. A configuration window will appear.

  3. Select the type of location where the backup archive will be saved:

    • Local, for saving the backup archive to the GravityZone appliance. In this case, you have to specify the path to the specific directory from the GravityZone appliance where the archive will be saved.

      The GravityZone appliance has a Linux directory structure. For example, you can choose to create the backup to the tmp directory. In this case, enter /tmp in the Path field.

    • FTP, for saving the backup archive to a FTP server. In this case, enter the FTP details in the following fields.

    • Network, for saving the backup archive to a network share. In this case, enter the path to the network location that you want (for example, \\computer\folder), the domain name and the domain user credentials.

  4. Optionally, you can back up your update staging settings for endpoints along with the status of the published packages. The Staging backup option is available only for environments with staging enabled and may require large storage.

  5. Click the Test Settings button. A text notification will inform you if the specified settings are valid or invalid.

    To create a backup, all the settings have to be valid.

  6. Click Generate. The Backup page will be displayed. A new backup entry will be added to the list. Check the Status of the new backup. When the backup is completed, you will find the tgz archive at the specified location.

    Note

    • The list available in the Backup page contains the logs of all created backups. These logs do not provide access to the backup archives; they only display details of the created backups.

    • Database backups with staging settings may require large storage and take longer than usual backups.

To schedule a database backup:

  1. Go to the Configuration page in Control Center and click the Backup tab.

  2. Click the backup_settings.pngBackup Settings button at the upper side of the table. A configuration window will appear.

  3. Select Scheduled Backup.

  4. Configure the backup interval (daily, weekly or monthly) and the start time.

    For example, you can schedule backups to run weekly, every Friday, starting at 22:00.

  5. Configure the scheduled backup location.

  6. Select the type of location where the backup archive will be saved:

    • Local, for saving the backup archive to the GravityZone appliance. In this case, you have to specify the path to the specific directory from the GravityZone appliance where the archive will be saved.

      The GravityZone appliance has a Linux directory structure. For example, you can choose to create the backup to the tmp directory. In this case, enter /tmp in the Path field.

    • FTP, for saving the backup archive to a FTP server. In this case, enter the FTP details in the following fields.

    • Network, for saving the backup archive to a network share. In this case, enter the path to the network location that you want (for example, \\computer\folder), the domain name and the domain user credentials.

  7. Optionally, you can back up your update staging settings for endpoints along with the status of the published packages. The Staging backup option is available only for environments with staging enabled and may require large storage.

  8. Click the Test Settings button. A text notification will inform you if the specified settings are valid or invalid.

    To create a backup, all the settings have to be valid.

  9. Click Save to create the scheduled backup.

Restoring a database backup

When for various reasons your GravityZone instance is working improperly (failed updates, dysfunctional interface, corrupted files, errors, etc.), you can restore the GravityZone database from a backup copy using:

  • The same appliance

  • A fresh GravityZone image

  • The Replica Set feature

Choose the option that best suits your situation and proceed with the restoration procedure only after you have carefully read the prerequisites described hereinafter.

Restoring the database to the same GravityZone VA

Prerequisites

  • A SSH connection to the GravityZone appliance, using the root privileges.

    You can use putty and bdadmin’s credentials to connect to the appliance via SSH, then run the command sudo su to switch to the root account.

  • The GravityZone infrastructure has not changed since the backup.

  • The backup is more recent than April 30th, 2017 and the GravityZone version is higher than 6.2.1-30. If otherwise, contact the Technical Support team.

  • In distributed architectures, GravityZone has not been configured to use database replication (Replica Set).

    To verify the configuration, follow these steps:

    1. Open the /etc/mongodb.conf file.

    2. Check that replSet is not configured, as in the example below:

      # replSet = setname

    Note

    To restore the database when Replica Set is enabled, refer to install.deployment.root.backup.restore.replica.

  • No CLI processes are running.

    To make sure all CLI processes are stopped, run the following command:

    # killall -9 perl

  • The mongoconsole package is installed on the appliance.

    To verify the condition is met, run this command:

    # /opt/bitdefender/bin/mongoshellrestore --version

    The command should not return any errors, otherwise run:

    # apt-get update
# apt-get install --upgrade mongoconsole
Restoring the database

  1. Go to the location containing the database archive:

    # cd /directory-with-backup

    , where directory-with-backup is the path to the location with the backup files.

    For example:

    # cd /tmp/backup

  2. Restore the database.

    # /opt/bitdefender/bin/mongoshellrestore -u bd -p 'GZ_db_password' \

--authenticationDatabase admin --gzip --drop --archive < \

gz-backup-$YYYY-$MM-$DD(timestamp).tar.gz

    Important

    Make sure to replace GZ_db_password with the actual password of the GravityZoneDatabase Server and the timestamp variables in the archive's name with the actual date.

    For example, the actual date should look like this:

    gz-backup-2019-05-17(1495004926).tar.gz

  3. Optionally, to be able to download again previously published kits in the GravityZone console run the following command:

    /opt/bitdefender/bin/mongoshell -u bd -p 'GZ_db_password' --eval 'db.endpointKits.update({state:{$ne:1}},{$set:{internalState:1,isProcessing:true,"applianceIds.downloaded":[],"applianceIds.published":[]}},{multi:true})' --quiet devdb

    Note

    Enabling this option may generate a large amount of data and take a long time depending on your previous update staging settings.

  4. Restart the appliances.

    Database restoration is now complete.

Restoring the database from a decommissioned GravityZone VA

Prerequisites

  • A fresh GravityZone VA installation:

    • With the same IP as the old appliance

    • Having ONLY the Database Server role installed.

  • A SSH connection to the GravityZone virtual appliance, using the root privileges.

  • The GravityZone infrastructure has not changed since the backup was made.

  • The backup is more recent than April 30th, 2017.

  • In distributed architectures, GravityZone has not been configured to use database replication (Replica Set).

    If you use Replica Set in your GravityZone environment, you also have the Database Server role installed on other appliance instances.

    To restore the database when Replica Set is enabled, refer to Restoring thedatabase in a Replica Set environment.

Restoring the database

  1. Connect to the GravityZone appliance via SSH and switch to root.

  2. Stop VASync:

    # stop vasync

  3. Stop CLI:

    # # killall -9 perl

  4. Go to the location where the backup is:

    # cd /directory-with-backup

    , where directory-with-backup is the path to the location with the backup files.

    For example:

    # cd /tmp/backup

  5. Restore the database.

    # /opt/bitdefender/bin/mongoshellrestore -u bd -p 'GZ_db_password' \

--authenticationDatabase=admin --gzip --drop \

--archive='/home/bdadmin/gz-backup-$YYYY-$MM-$DD(timestamp).tar.gz

    Important

    Make sure to replace GZ_db_password with the actual password of the GravityZoneDatabase Server and the timestamp variables in the archive's name with the actual date.

    For example, the actual date should look like this:

    gz-backup-2019-05-17(1495004926).tar.gz

  6. Restore the old appliance ID:

    # /opt/bitdefender/bin/mongoshell -u bd -p 'GZ-db_password' \

––eval print(db.applianceInstalls.findOne({name:'db'}).\

applianceId)" --quiet > /opt/bitdefender/etc/applianceid

    Important

    Make sure to replace GZ_db_password with the actual password of the GravityZoneDatabase Server.

  7. Remove the reference to the old roles.

    # /opt/bitdefender/bin/mongoshell -u bd -p 'GZ_db_password' --eval\

'db.applianceInstalls.remove({ip:db.applianceInstalls.findOne(

{name:"db"}).ip,name:{"$ne": "db"}});' --quiet devdb

    Important

    Make sure to replace GZ_db_password with the actual password of the GravityZoneDatabase Server.

  8. Start VASync:

    # start vasync

  9. Optionally, to be able to download again previously published kits in the GravityZone console run the following command:

    /opt/bitdefender/bin/mongoshell -u bd -p 'GZ_db_password' --eval 'db.endpointKits.update({state:{$ne:1}},{$set:{internalState:1,isProcessing:true,"applianceIds.downloaded":[],"applianceIds.published":[]}},{multi:true})' --quiet devdb

    Note

    Enabling this option may generate a large amount of data and take a long time depending on your previous update staging settings.

  10. Start CLI:

    # /opt/bitdefender/eltiw/installer

  11. Install the other roles.

    # dpkg -l gz*

    Note that the database schema has been successfully upgraded to the latest version:

    > db.settings.findOne().database
{
"previousVersion" : "000-002-009",
"ranCleanUpVersions" : {
"b0469c84f5bf0bec0b989ae37161b986" : "000-002-008"
},
"updateInProgress" : false,
"updateTimestamp" : 1456825625581,
"version" : "000-002-011"
}

  12. Restart the appliance.

    Database restoration is now complete.

Restoring the database with staging settings

Prerequisites

  • The Database and the Update Server roles should be installed on separate appliances

  • A fresh GravityZone VA installation, with the same IP as the old appliance and having only the Database Server role installed. You can download the GravityZone VA image from here.

  • A SSH connection to the GravityZone virtual appliance, using the root privileges.

  • The GravityZone infrastructure has not changed since the backup was made.

  • The backup is more recent than April 30th, 2017.

  • In distributed architectures, GravityZone has not been configured to use database replication (Replica Set). If you use Replica Set in your GravityZone environment, you also have the Database Server role installed on other appliance instances.

Restoring the database and staging settings

To restore the database follow the steps below:

  1. Download the Virtual Appliance.

  2. Install the Database Server role.

    For more information about installing the Database Server role, refer to Deploy and set up GravityZone VA.

  3. Stop VASync:

    # service vasync stop

  4. Stop CLI:

    # killall -9 perl

  5. Go to the location containing the database archive:

    # cd /directory-with-backup

    Where directory-with-backup is the path to the location with the backup files.

    For example: # cd /tmp/backup

  6. Restore the database:

    /opt/bitdefender/bin/mongoshellrestore -u bd -p 'GZ_db_password' --authenticationDatabase admin --gzip --drop --archive < 'gz-backup-$YYYY-$MM-$DD(timestamp).tar.gz'

    Important

    Make sure to replace GZ_db_password with the actual password of the GravityZone Database Server and the timestamp variables in the archive's name with the actual date.

    For example, the actual date should look like this:

    gz-backup-2019-05-17(1495004926).tar.gz

  7. Test to make sure you have entered the correct password by running the following command:

    mongo admin -u bd -p 'GZ_db_password'

    Note

    If you receive error messages, contact Bitdefender Enterprise Support.

  8. Restore the appliance ID:

    /opt/bitdefender/bin/mongoshell -u bd -p 'GZ_db_password' --eval 'print(db.applianceInstalls.findOne({name:"db"}).applianceId);' --quiet devdb > /opt/bitdefender/etc/applianceid

    Important

    Make sure to replace GZ_db_password with the actual password of the GravityZone Database Server.

  9. Remove the reference to the old roles:

    /opt/bitdefender/bin/mongoshell -u bd -p 'GZ_db_password' --eval 'db.applianceInstalls.remove({name:{"$ne": "db"}});' --quiet devdb

    Important

    Make sure to replace GZ_db_password with the actual password of the GravityZone Database Server.

  10. Start VASync:

    # service vasync start

  11. Optionally, to be able to download again previously published kits in the GravityZone console run the following command:

    /opt/bitdefender/bin/mongoshell -u bd -p 'GZ_db_password' --eval 'db.endpointKits.update({state:{$ne:1}},{$set:{internalState:1,isProcessing:true,"applianceIds.downloaded":[],"applianceIds.published":[]}},{multi:true})' --quiet devdb

    Note

    Enabling this option may generate a large amount of data and take a long time depending on your previous update staging settings.

  12. Start CLI:

    /opt/bitdefender/eltiw/installer

  13. Restart the appliance.

    Database restoration is now complete.

To restore the staging settings follow the steps below:

  1. Go to the location containing the backup archives.

  2. Copy or move the gz-backup-staging archive to a directory of your choice on the appliance where the Update Server role will be installed.

    For example: /home/bdadmin/backup-staging

  3. Start CLI:

    /opt/bitdefender/eltiw/installer

  4. Connect to the existing database previously created.

  5. Install the Update Server role.

  6. Stop the update server service:

    # service arrakis stop

  7. Remove the product updates directories:

    # rm -rf /opt/bitdefender/var/data/products/v2

    # rm -rf /opt/bitdefender/var/data/products/bst_nix

    # rm -rf /opt/bitdefender/var/data/products/bst_nix7_update

  8. Unpack the gz-backup-staging archive from the location it was saved:

    # tar -xvzf archive

  9. Copy all directories:

    # rsync -a -v -r --chown=bitdefender:bitdefender /home/bdadmin/extracted_archive_folder/opt/bitdefender/var/data/products/ /opt/bitdefender/var/data/products/ > /home/bdadmin/rsync_output.txt

    Replace the extracted_archive_folder with the exact location where the archive was extracted.

    To check the status of the process open /home/bdadmin/rsync_output.txt.

  10. Make sure the copying process ended successfully then start the update server service:

    # service arrakis start

You can continue to install the remaining roles on the database appliance or on separate appliances. Make sure no other roles are installed on the update server appliance.

Restoring the database in a Replica Set environment

If you have deployed the database in a Replica Set environment, you can find the official restore procedure on the mongoDB online manual (English only).

Note

The procedure requires advanced technical skills and should be done only by a trained engineer. If you encounter difficulties, please contact our Technical Support to assist you in restoring the database.

Access permissions

With access permissions you can grant GravityZoneControl Center access to Active Directory (AD) users, based on access rules. To integrate and synchronize AD domains, refer to Active Directory. For more information on managing user accounts via access rules, refer to the User Accounts section.

In this section: