Skip to main content

Security Server

Configure the SNMP agent on Security Server

Configuring the SNMP agent on the Bitdefender Security Server will make the communication and information delivery to your SNMP manager possible.

Simple Network Management Protocol (SNMP) is used for collecting information from network devices such as servers, hubs, switches and routers on an Internet Protocol network. It is designed to have minimal transport requirements and to continue working when most other network applications fail. SNMP is collecting information such as CPU and RAM usage, server load, and traffic status on a network interface.

The SNMP agent is a program that is packaged within the network element. Enabling the agent allows it to collect the management information database from the device locally and makes it available to the SNMP manager, when it is queried for.

In typical uses of SNMP, one or more administrative computers called Managers have the task of monitoring or managing a group of hosts or devices on a computer network. Each managed system executes a software component called an Agent, which reports information via SNMP to the Manager.

This section explains how to configure the SNMP agent on Bitdefender Security Server to make possible the communication and information delivery to your SNMP manager.

Note

The SNMP package is present on the Security Server Multi-Platform starting with version 6.1.68.7705.

To configure the SNMP agent on the Security Server, you must follow these steps:

  1. Log in to Security Server via SSH, using the root credentials or another user with administrative privileges, if set.

    Important

    The default password for root is sve. We recommend changing it as soon as possible.

  2. Make sure no SNMP daemon process is running, and if it is, you must terminate it by using the following command:

    root@bitdefender-sva:~# service snmpd stop
  3. Create backup for the /etc/snmp/snmpd.conf file using the following command:

    cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.bak$
    
  4. Open the /etc/snmp/snmpd.conf file using a text editor and configure the SNMP daemon to listen on both a local host and an interface IP. By default, the SNMP agent on is set to allow connections originating only from the local host. Search for the line containing the agentaddress and configure it as follows:

    sudo nano /etc/snmp/snmp.conf
    #agentaddress  127.0.0.1,[::1]
    agentAddress udp:127.0.0.1:161,udp:your_interface_IP:161

    Note

    You can also change the transport protocol over TCP or SSH tunneling, but you must make sure it’s supported by your monitoring appliance. For example, Cacti can’t handle SNMP over TCP.

  5. Create the SNMP v3 user in the /etc/snmp/snmpd.conf file using the following command:

    createUser snmpadmin SHA "your_auth_pass" AES "your_privacy_pass"
    

    Only the following authentication types can be used:

    • MD5

    • SHA

    • SHA-512

    • SHA-384

    • SHA-256

    • SHA-224

    Note

    Not all SHA variations are fully supported on all monitoring tools. You must use the DES and AES privacy protocols.

    The minimum passphrase length is 8 characters. If the privacy passphrase is not specified, the authentication passphrase is selected by default.

  6. Add the user directive, rouser or rwuser, in the /etc/snmp/snmpd.conf file to allow read-only or read-write access, using the following command:

    rouser snmpadmin authpriv

    The SNMP v3 agent supports the following set of security levels as defined in the official The RFC Series USM MIB (RFC 2574) documentation:

    • noAuthNoPriv - communication without authentication and privacy

    • authNoPriv - communication with authentication and without privacy

    • authPriv - communication with authentication and privacy

  7. Start the SNMP daemon and check if the user was added in the /var/lib/snmp/snmpd.conf file by using the following command:

    root@bitdefender-sva:~#service snmpd start
    

    This is a sample of the snmpd.conf file:

    root@bitdefender-sva:~# pgrep snmpd
    202826
    root@bitdefender-sva:~# service snmpd status
    ● snmpd.service - Simple Network Management Protocol (SNMP) Daemon.
         Loaded: loaded (/lib/systemd/system/snmpd.service; disabled; vendor preset: enabled)
         Active: active (running) since Mon 2024-01-15 22:09:27 UTC; 11h ago
        Process: 202815 ExecStartPre=/bin/mkdir -p /var/run/agentx (code=exited, status=0/SUCCESS)
       Main PID: 202826 (snmpd)
          Tasks: 1 (limit: 2258)
         Memory: 3.7M
         CGroup: /system.slice/snmpd.service
                 └─202826 /usr/sbin/snmpd -LOw -u Debian-snmp -g Debian-snmp -I -smux mteTrigger mteTriggerConf -f -p /run/snmpd.pid
    root@bitdefender-sva:~# netstat -nlpu | grep snmp
    udp        0      0 10.18.139.1:161         0.0.0.0:*                           202826/snmpd        
    udp        0      0 127.0.0.1:161           0.0.0.0:*                           202826/snmpd        
    #
    # net-snmp (or ucd-snmp) persistent data file.
    #
    ############################################################################
    # STOP STOP STOP STOP STOP STOP STOP STOP STOP 
    #
    #          **** DO NOT EDIT THIS FILE ****
    #
    # STOP STOP STOP STOP STOP STOP STOP STOP STOP 
    ############################################################################
    #
    # DO NOT STORE CONFIGURATION ENTRIES HERE.
    # Please save normal configuration tokens for snmpd in SNMPCONFPATH/snmpd.conf.
    # Only "createUser" tokens should be placed here by snmpd administrators.
    # (Did I mention: do not edit this file?)
    #
    
    usmUser 1 3 0x80001f88805b165469ceee666500000000 "snmpadmin" "snmpadmin" NULL .1.3.6.1.6.3.10.1.1.7 0x40b337c3ce06edf6b4fd0ebbbdac5dee06fd4fc67c0b1372b9f76a94ed5cc31234d09edc9c03b59a5b8e89676e501ba6a59f>
    usmUser 1 3 0x80001f88805b165469ceee666500000000 "snmpadmin2" "snmpadmin2" NULL .1.3.6.1.6.3.10.1.1.3 0x4707b03a201c155bfabeedce29b16a3e11351661 .1.3.6.1.6.3.10.1.2.4 0x4707b03a201c155bfabeedce29b16a3e >
    usmUser 1 3 0x80001f88805b165469ceee666500000000 "snmpadmin3" "snmpadmin3" NULL .1.3.6.1.6.3.10.1.1.3 0x4707b03a201c155bfabeedce29b16a3e11351661 .1.3.6.1.6.3.10.1.2.4 0x4707b03a201c155bfabeedce29b16a3e >
    usmUser 1 3 0x80001f88805b165469ceee666500000000 "snmpadmin4" "snmpadmin4" NULL .1.3.6.1.6.3.10.1.1.7 0xa1b0e4c0c34c8af1a395d65a71578468f18bfadd2b5cac1477a0f0817925e01d9178bc4b74b3ad7e91c3f9ef6600176221>
    setserialno 582543615
    

    Note

    Once you add the user, if you change the password from the /etc/snmp/snmpd.conf file, the change is not reflected in the /var/lib/snmp/snmpd.conf file and authentication failures will occur. In addition, you must not manually edit the /var/lib/snmp/snmpd.conf file.

  8. Install SNMPwalk, using the apt install snmp command to test the connection. Make sure there are no other network access related issues while checking if the feature works.

    You can now test if the SNMP v3 feature is working by connecting to it from a different machine.

    The following are examples of connection tests when the password is correct or incorrect:

    • using a correct password:

      username@work:~$ snmpwalk -v3 -a SHA-512 -A "password" -x AES -X "password" -l authPriv -u snmpadmin4 SVA_IP | head
      iso.3.6.1.2.1.1.1.0 = STRING: "Linux bitdefender-sva 5.4.0-167-generic #184-Ubuntu SMP Tue Oct 31 09:21:49 UTC 2023 x86_64"
      iso.3.6.1.2.1.1.2.0 = OID: iso.3.6.1.4.1.8072.3.2.10
      iso.3.6.1.2.1.1.3.0 = Timeticks: (1599) 0:00:15.99
      iso.3.6.1.2.1.1.4.0 = STRING: "Me <[email protected]>"
      iso.3.6.1.2.1.1.5.0 = STRING: "bitdefender-sva"
      iso.3.6.1.2.1.1.6.0 = STRING: "Sitting on the Dock of the Bay"
      iso.3.6.1.2.1.1.7.0 = INTEGER: 72
      iso.3.6.1.2.1.1.8.0 = Timeticks: (7) 0:00:00.07
      iso.3.6.1.2.1.1.9.1.2.1 = OID: iso.3.6.1.6.3.10.3.1.1
      iso.3.6.1.2.1.1.9.1.2.2 = OID: iso.3.6.1.6.3.11.3.1.1
    • using an incorrect password:

      username@work:~$ snmpwalk -v3 -a SHA-512 -A "password" -x AES -X " password" -l authPriv -u snmpadmin4 SVA_IP | head
      snmpwalk: Authentication failure (incorrect password, community or key)

    Some SNMP packages and network monitoring tools have restrictions related to the use of special characters in passwords. The most common list is: (, ), ;, !, |, $, <, >, ', ", `, \, {, }.

    The following is an example of an error displayed by the SNMPwalk feature installed on an Ubuntu machine:

    root@administrator-virtual-machine:/home/administrator# snmpwalk -v3 -a SHA -A "!@#4QWEr" -x AES -X "!@#4QWEr" -l authPriv -u snmpadmin SVA_IP | head
    bash: !@#4QWEr: event not found
  9. (Optional) Install Management Information Base (MIB) modules, based on your configuration.

  10. Terminate the SNMP daemon process by running the following command:

    root@bitdefender-sva:~# service snmpd stop
  11. Add the Security Server into your network monitoring tool and enable it.

  12. Comment the mibs line from the /etc/snmp/snmp.conf file, like in the following example:

    root@bitdefender-sva:/etc/snmp# cat snmp.conf
    # As the snmp packages come without MIB files due to license reasons, loading
    # of MIBs is disabled by default. If you added the MIBs you can reenable
    # loading them by commenting out the following line.
    #mibs :
    
    # If you want to globally change where snmp libraries, commands and daemons
    # look for MIBS, change the line below. Note you can set this for individual
    # tools with the -M option or MIBDIRS environment variable.
    #
    # mibdirs /usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf
  13. Start the SNMDP agent using the following command:

    root@bitdefender-sva:~#service snmpd start

By default, the SNMPD service starts manually. To start the service automatically when the Security Server restarts, run the following commands:

# systemctl enable snmpd
# systemctl start snmpd

Update the operating system of the Security Server to Ubuntu 20.04 LTS

This topic provides all the information you need to upgrade Security Servers in your environment to use Ubuntu 20.04.

Introduction

Why updating the OS of the Security Server?

Security. Currently, Security Server relies on Ubuntu 16.04 LTS, which becomes officially EOL on April 30th, 2021. This means it will stop receiving critical fixes and security patches, exposing the appliance to potential threats.

Because you can. You do not need to redeploy any of the appliances like in the past. Since the April 2021 update, GravityZone offers the option to update Security Servers through the Update Security Server task. The task is available for both GravityZone platforms, cloud and on-premises, and all integrations with virtualized environments including cloud integrations.

It is easy. The OS update task is automatic, and you can schedule it to run in a maintenance window. The task applies to both multiplatform and agentless environments.

No icons with issues. After updating GravityZone, you may notice that the Security Server will appear as outdated. This means the Security Server version with OS update is available to download and install.

Warning

If you have a cloud integration (Azure or AWS) and choose to update the OS for your Security Servers, Bitdefender is not accountable for the billing changes that this update might generate according to your service-based model.

Prerequisites

  • The OS update task is available in GravityZone Control Center starting with the April 2021 update for cloud platform, and version 6.23.1-1 for on-premises platform.

  • Compatible Security Server versions:

    • Multiplatform: 6.2.1

    • For VMware NSX-V: 6.2.0

    • For VMware NSX-T: 1.1.0

  • The OS update on Citrix XenServer 7.1 LTSR requires you to apply the Citrix XS71ECU2060 hotfix first.

    Note

    You can install the hotfix automatically from Citrix XenCenter. The installation requires hypervisor reboot.

  • The update requires at least 2 GB of disk space available on the appliance to run.

  • Adjust resource allocation for the Security Server according to the new hardware requirements:

    Consolidation

    Number of protected VMs

    RAM

    CPU

    Low

    1-30

    2 GB

    2

    31 - 50

    4 GB

    2

    Medium

    51 - 100

    4 GB

    4

    High

    101 - 200

    4 GB

    6

  • Update location for the Security Servers must be one of the following:

    • update-onprem.2d585.cdn.bitdefender.net:80

    • upgrade.bitdefender.com

    • Bitdefender Endpoint Security Tools Relay for Linux version 6.2.21.141

    Check the assigned policy, under the Relay > Update section, to have the option Define custom update locations enabled.

    Warning

    Bitdefender Endpoint Security Tools Relay for Windows does not support the OS update.

Best practices

  • Take snapshots of the Security Server appliances, because the changes are major.

  • Since Bitdefender does not have any control on the infrastructure where Security Server runs, the update task does not limit the number or combination of Security Servers to be selected.

    The recommendation is to run several update tasks on groups of Security Servers, considering redundancy and availability. Do not run the task on all Security Servers at once, or you will lose protection.

  • Schedule the Security Server update in a maintenance window, especially for NSX environments, or migrate the VMs from one host to another one before starting the update.

  • Enable the Task status notification to know when the update is complete.

Updating steps

  1. Select the target Security Servers in the Network page.

  2. Run an Update Security Server task with the feature update option.

    This update will prepare the Security Servers for the OS update.

  3. Run again an Update Security Server task, this time with the OS update option.

  4. Select to run now or choose a date from the calendar to schedule the maintenance window.

To check the status of the update task, go to the Tasks page. Follow the links in the Status column to view the status of the task for each target Security Server.

How it will happen

The update process is incremental, the operating system being upgraded to Ubuntu 18.04 LTS, and then to Ubuntu 20.04 LTS, under Canonical official recommendation. The process happens transparently, with no user intervention.

During the update, the following operations will be performed in the backend:

  • Update requirements are checked.

  • Non-Bitdefender repositories are disabled.

  • Third-party packages are uninstalled.

    You can reinstall the third-party packages once the update is complete.

  • Existing Bitdefender services are stopped.

  • The OS is updated to Ubuntu 18.04 LTS.

  • The OS is updated to Ubuntu 20.04 LTS.

  • Repositories are changed to receive Ubuntu 20.04 updates and patches.

  • Non-Bitdefender repositories are enabled.

  • Bitdefender services are started.

    Note

    The appliances will automatically reboot several times.

Frequently asked questions

Q1: What happens with the protection during the update on agentless environments?

A: Protection on that host is lost. This is why we recommend moving the VMs on another protected host while the Security Server is updating. Plan this operation in a maintenance window.

Q2: How long does the OS update last and what is the expected downtime?

A: Depending on the networking and storage characteristics, the update duration can vary. In most cases, it will take between 20-30 minutes.

Q3: Will the update work if the Security Server has various minor Ubuntu 16.04 kernel versions?

A: Yes. Before starting the OS upgrade, all packages are updated to the latest versions available.

Q4: What happens with custom repositories or third-party packages during the update?

A: Any third-party packages will be uninstalled during the OS upgrade. They will not be automatically restored because Bitdefender repositories do not include them. The additional repositories will still be there, so you can reinstall the custom packages after the upgrade is complete.

Q5: How do I know if the update fails on a Security Server?

A: In Control Center, follow the Status link of the update task to open the Task Status window. You will view all target Security Servers and the status of the task on each of them. You can filter to view only where the task status is Failed. Select the Security Server with a failed update and check the error message in the lower part of the window.

Q6: Can I install the Security Server manually?

A: Yes. Follow the steps described in Bitdefender Security Server manual installation.

Q7: What happens if GravityZone is in an offline environment?

A: Follow the usual procedure to download the update archive. For details, refer to GravityZone products offline update.

Q8: Will the task run if Security Server runs on Ubuntu 12.04?

A: No. The task can only run if Security Server runs on Ubuntu 16.04. In this case, you need to redeploy the Security Server.

Q9: Will the task be available for the vShield integration?

A: No, it is not supported. You need to upgrade to VMware NSX.