You can also download it from here.

First, when BitDefender is installed, the MTA with which you want to integrate with must be CommuniGate Pro. If such a product is already installed on the server, the BitDefender installer will automatically detect it and display it as default option for MTA integration.

If BitDefender is already installed and integrated with another MTA, for example Sendmail, you can change it by disabling the milter integration and activating the CommuniGate Pro one:

# ./bdsafe agent disable milter
# ./bdsafe agent enable cgate
# cd /opt/BitDefender/bin

The second step is to add some lines in the Mail.settings file of the CommuniGate Pro server, located in /var/CommuniGate/Settings.

Use your favorite editor to edit the Main.settings file (do not forget to make a backup of it first, in case something goes wrong). Add the following lines somewhere in the configuration file, between the first ‘{’ and the last ‘}’:

ExternalFilters = (
    {
        Enabled = YES;
        LogLevel = 5;
        Name = BitDefender;
        ProgramName = "/opt/BitDefender/bin/bdcgated";
        RestartPause = 1m;
        Timeout = 2m;
    }
);

After this, modify the Rules.settings file (again, make a backup first) and add a rule for the BitDefender filter:

(
    5,
    BitDefender,
    (("Message Size", "greater than", 1)),
    ((ExternalFilter, BitDefender))
)

Another way and the recommended one to enable the BitDefender integration, is to use the CommuniGate management web interface (by default it listens on http://<your-host>:8010):

1. go to Settings → General (you will be required to login);

2. go to the Helpers tab and look at Content Filtering, for the CommuniGate Pro version;

3. do the following actions:

3.1. check the Use Filter box;

3.2. enter BitDefender in the text box;

3.3. set the Log list to Problems;

3.4. set Timeout to 2 minutes

In the Program Path, enter /opt/BitDefender/bin/bdcgated. For CommuniGate Pro version 5 and above, the method is slightly different:

3.1. enable the filter using the drop-down combo box;

3.2. enter BitDefender in the corresponding text box;

3.3. set the Log Level to Problems;

3.4. set Timeout to 2 minutes;

3.5. in the Program Path text box, enter /opt/BitDefender/bin/bdcgated;

3.6. set Auto-Restart to 5 seconds;

3.7. press Update;

4. go to the Settings → Mail → Rules tab;

5. enter BitDefender and press Create New or Add Rule, in version 5;

6. press the Edit button next to the BitDefender filter. Do the following:

6.1. look at the Data list and set it to Message Size;

6.2. set Operation to greater than;

6.3. set Parameter to 1;

6.4. look at the Action list and set it to External Filter;

6.5. enter BitDefender in the Parameters box;

6.6. press Update;

7. restart the BitDefender services;

8. restart the CommuniGate Pro server.

BitDefender will now start scanning your incoming messages.

With the latest update, BitDefender Security for Mail Servers can provide some additional information to CommuniGate Pro server, in order to mark spam messages and to deliver them in the designated folder (Junk), depending on the digital range bar score from the email headers. In order to enable this feature, do the following:

# cd /opt/BitDefender/bin

# ./bdsafe group configure mygroup antispam cgatecompat Y

# ./bdsafe reloadsettings

Change mygroup with the name of your group. If you have a default installation, mygroup is default (bdsafe group configure default antispam cgatecompat Y).

From this moment on, BitDefender will add a new header, which looks something like this: X-Junk-Score: 92 [XXXX]. The number of X-s is given by the value of the spam level, so the digital score bar range will look like this:

0  []
1-39  [X]
40-80  [XX]
81-90  [XXX]
91-95  [XXXX]
96-99  [XXXXX]
100  [XXXXXX]

If the email is not spam, the range is ‘0 []‘, if the value increases, the range bar will do the same, ‘1-39 [X]‘ and so on.

The administrator of the CommuniGate Pro server can set the actions for this kind of emails. From Settings->Users->Domains, the Junk Mail control can set the action for spam e-mails. For example, High probability->Store in junk, Medium probability->Mark as Junk, Low priority->Mark as junk.

If the user receives an e-mail that is marked as spam (X-Junk-Score: 100 [XXXXXX]), this mail will be moved in the Junk directory. Using this header, the administrator of the CommuniGate Pro server can filter the e-mails delivered to the users.

For more information, read the BitDefender user guide and this chapter on CommuniGate Server flags.

For example, in Fedora Core, download the src.rpm file from the repository and install it with:

# rpm -ivh samba-3.0.24.src.rpm

If the install is OK, go to /usr/src/redhat/SPECS and rebuild the src.rpm file:

# cd /usr/src/redhat/SPECS
# rpmbuild -bc samba.spec

It is possible you will need some more packages (libacl-devel, cups-devel, gnutls-devel, autoconf, libtool etc.) to rebuild the src.rpm package. If so, use the distro way to install the missing packages.

The other way is to get the latest source tarball from the Samba web site.

The next step is to compile the BitDefender vfs module. Go to /opt/BitDefender/var/src and unpack the BitDefender-Samba-vfs.tar.gz file using:

# tar -xvf BitDefender-Samba-vfs.tar.gz

To compile the vfs, run in a console:

# ./configure --with-samba-source=samba_source_directory

samba-source_directory is /usr/src/redhat/BUILD/samba-3.0.24 if the src.rpm is used, or it can be the path to the Samba sources from the tar.gz file. If there are no error messages, type:

# make && make install

By default the vfs file bdvfs3.so is installed in /usr/lib/samba/vfs. This path can be changed by setting the ‘–with-install-dir’ parameter in the configure command.

The BitDefender Samba vfs module is activated/deactivated on a per-share basis. You can check it’s status by running the following command:

# bdsafe samba vfs

The output will be something like this:

global
    Path           :
    VFS            : disabled

public
    Path           : /data/500GB/public/
    VFS            : disabled

To enable the BitDefender vfs for the public share, run:

# bdsafe samba vfs enable public

To check the status of the public share, type:

# bdsafe samba vfs status public

The output will look like this:

public
    Path           : /data/500GB/public/
    VFS            : enabled
    Failure action : (default)
    Actions:
        On infected  : (default)
        On suspected : (default)
        On riskware  : (default)

To test if the BitDefender vfs for Samba is working, try to copy the EICAR test file from a windows machine into the public share. If it’s working, in the /opt/BitDefender/var/log/virus.log file, a new entry will appear and the test file will be deleted from the public share:

“05/06/2009 11:15:03 BDFILED MALWARE: /data/500GB/public/eicar.com (/data/500GB/public/eicar.com), malware: EICAR-Test-File (not a virus), status: Infected, action: Deleted (disinfect, delete, deny)”

Now your share is protected against malware by BitDefender.

For more information about the BitDefender vfs module, please read the INSTALL.samba-vfs file from your BitDefender installation.

The minimum required Axigen version is 6.0, previous versions use a different method for integrating with milter interfaces, you’ll be ok with any 6.x version. All commands below should be executed from within the ~bitdefender/bin directory.

First of all, you’ll have to install BitDefender and select the Sendmail-milter agent during the installation wizard, or if it’s already installed just enable it:

# ./bdsafe agent enable milter

BitDefender and Axigen run as different users, and they need to communicate with each other for the integration to work, so you’ll need to make some changes regarding the two users and the default access permissions:

1. Add the axigen user to BitDefender’s LocalUsers and to the bitdefender system group:
   

   # ./bdsafe registry configure localusers add axigen

   • Linux: add the axigen user to the bitdefender group:
     

     # usermod -G axigen,bitdefender axigen

   • FreeBSD: add the axigen user to the bitdefender group:
     

     # pw usermod axigen -G axigen,bitdefender

2. Change the access permissions on /var/run/BitDefender so bdmilterd which will be running as the axigen user will be able to create the milter intercommunication socket:
   

   # chmod 731 /var/run/BitDefender

3. bdmilterd needs to run as the axigen user, and the easiest way to achieve this is by setting the setuid flag for bdmilterd and changing it’s owner to the axigen user:
   

   # chown axigen:bitdefender bdmilterd
   # chmod u+s bdmilterd

The next step is configuring Axigen with a milter filter, so it will know how to talk to BitDefender, and instructing Axigen to send all mails to be scanned by BitDefender. This can be done as follows, from Axigen’s WebAdmin interface in the Security & Filtering -> Acceptance & Routing -> Advanced Settings context:

1. Add a new Acceptance/Routing rule:
   1. Set the name of the rule to BitDefender_Milter
   2. Unless otherwise required, leave the Conditions section unmodified as the default policies will apply to all SMTP connections.
   3. From the Actions section, making use of the drop-down box select Filters-> Add Filter and select the +Add condition button
   4. In the Add milter filter box set the Name field to BitDefender and the Address one to local:///var/run/BitDefender/bdmilterd.sock
   5. Save configuration
2. Activate the filter by creating a second Acceptance/Routing policy that will ensure the first filter execution:
   1. Set the name of the new rule to BitDefender_Execute
   2. Leave the Conditions section unmodified
   3. From the Actions section, making use of the drop-down box select Filters-> Execute Filters and select the +Add condition button
   4. Set the Execute filters Name pattern to BitDefender
   5. Save configuration

And now the final touch, restart them all:

# ./bd restart

# /etc/init.d/axigen restart

Axigen doesn’t send any kind of connection information to BitDefender, like the IP address of the client sending the mail, therefore BitDefender’s RBL filter won’t be able to process mails properly. You’ll need to disable the filter:

# ./bdsafe group configure default antispam userblfilter N

# ./bdsafe reload

You’ll have to add the RBL servers in Axigen’s configuration from the Security & Filtering -> Additional AntiSpam Methods -> DNSBL (DNS BlackList) context.

If the setup works correctly you’ll find the X-BitDefender-Scanner header in the headers of all delivered mails, similar to this:

[...]

X-BitDefender-Scanner: Clean, Agent: BitDefender Milter 3.0.2 on

my.axigen.server, sigver: 7.23354

[..]

Th-That’s all folks, you can now enjoy the two products, BitDefender and Axigen, happily ever after working together, fighting against the bad guys

The rest of this article focuses on explaining how to setup a BitDefender Security product to work with our Management Server and it assumes you have already installed BDMS on a Windows computer found in your local network.

1. Install the BitDefender Management Server AddOn for Linux products, on the computer running BDMS.

NOTE: This addon can not be used together with a BitDefender Security for Windows Mail Servers or BitDefender Security for File Servers. It will install, but the managed products will not be properly registered.

2. Install BitDefender Security for Mail Servers or BitDefender Security for Samba. Please check with the website for the list of supported distributions.

The install procedure is quite simple. Example:

# sh BitDefender-Security-Mail-3.0.2-linuxgcc3x-i586.rpm.run

and follow the instructions displayed on the screen. At some point, the installer will ask if you want to enable the Enterprise Management integration. Type ‘Y’ followed by ENTER. Then you will be asked the name of the computer on which BDMS is installed. Type the name and then hit ENTER again. This is all the installer needed to know about your Management Server and it will now proceed normally with questions about RBL, MTA etc.

If you already have a server installation and wish to enable the integration, then continue reading the rest of the steps, otherwise you can jump past them.

3. Specify the host of the Management Server:

# cd ~bitdefender/bin
# ./bdsafe bdem host <host[:port]>

4. Enable the integration

# cd ~bitdefender/bin
# ./bdsafe bdem enable Y

5. Restart the product

# cd ~bitdefender/bin
# ./bd restart

From this moment, you should be able to see in the BitDefender Management Server Console the installed Linux product(s). You can disable the management integration at any time, using the following commands:

# cd ~bitdefender/bin
# ./bdsafe bdem enable N
# ./bd restart

NOTE: The communication between the BitDefender Management Server and the Linux product(s) takes place once every 5 minutes. As a result, the policies (even the registration information) will need some time to propagate.

Before we end, we also made a little video (ogv, mp4). Enjoy!

The update locations are version and product specific. For example, BitDefender-common-3.0.2-1 (part of both BitDefender Security for Mail Servers and BitDefender Security for Samba version 3.0.x) uses the following update locations: linux-gcc3x-i586-common-302 and update_is_90. For the exact values, see the output of the command:

# bdsafe live

To mirror the necessary update locations, you should invoke the mirror script with the update locations names as parameters, but first, edit the script by modifying the value of OUTPUT_DIR to the location where you want the update directories to be created. The mirroring command is:

# sh bdmirror.sh linux-gcc3x-i586-common-302 update_is_90

The script will create the directories linux-gcc3x-i586-common-302/ and update_is_90/ under $OUTPUT_DIR, containing all files that are needed for securely updating BitDefender-common-3.0.2-1. The task could (and should) be ran periodically for all the product’s update locations.

Next, you need to HTTP-publish the mirrored folders under the root directory of your site.

Finally, you need to tell the Live! Update daemon to use this update server:

# bdsafe live updateservers add [some_name] [mirror_host_name]

The command will add a second update server after the one listed under the name Default. The added server will be used as a backup. See the bdsafe manual page for more details. Another option is to replace the default server:

# bdsafe live updateservers host Default [mirror_host_name]

There is also the possibility to redirect the upgrade.bitdefender.com queries to the mirror.

1) Check that you have the minimum required version (we recommend 2.4.x).

# postconf mail_version

mail_version = 2.4.5

Although the Postfix documentation stipulates that versions 2.3 or later are sufficient, our tests revealed that the setup doesn’t work for 2.3.x versions and that messages similar to the following appear in the postfix log:

warning: milter unix:/var/spool/postfix/BitDefender/bdmilterd.sock:
can't read SMFIC_OPTNEG reply packet header: Success
warning: milter unix:/var/spool/postfix/BitDefender/bdmilterd.sock:
read error in initial handshake
NOQUEUE: milter-reject: CONNECT from localhost[127.0.0.1]: 451 4.7.1
Service unavailable - try again later; proto=SMTP
NOQUEUE: milter-reject: MAIL from localhost[127.0.0.1]: 451 4.7.1
Service unavailable - try again later; proto=SMTP

See this page for more information regarding 2.3 vs. 2.4 version. Specifically, “body replacement is not available in Postfix 2.3“.

2) Add the postfix user to the LocalUsers of BitDefender and to the bitdefender group:

# export POSTFIXUSER=`postconf -h mail_owner`
# ./bdsafe registry configure localusers add $POSTFIXUSER

2.a) Linux: add the postfix user to the bitdefender group

# usermod -G $(groups $POSTFIXUSER |
sed -e 'y/ /,/' -e 's;^.*:,;;'),bitdefender $POSTFIXUSER

2.b) FreeBSD: add the postfix user to the bitdefender group

# pw usermod $POSTFIXUSER -G $(groups $POSTFIXUSER | \
sed -e 'y/ /,/' -e 's;^.*:,;;'),bitdefender

3) Fix access rights on /var/run/BitDefender since bdmilterd will need to write its pid there when running as $POSTFIXUSER

# chmod 731 /var/run/BitDefender

4) bdmilterd needs to be run as the $POSTFIXUSER; this can be done either by:

a) setting the bdmilterd setuid and making it owned by the $POSTFIXUSER – in this way the bd script will control the milter agent, too – easier, but possibly riskier, depending on your mail setup, or by

b) starting bdmilterd as the postfix user, manually or via a wrapper (bdmilterd should also be stopped manually or via a wrapper before a “bd stop” command)

4.a) use suid and enable the milter agent:

# chown $POSTFIXUSER bdmilterd
# chmod u+s bdmilterd
# ./bdsafe agent enable milter

4.b) manually start/stop bdmilterd as $POSTFIXUSER after “bd start” / after “bd stop“. After bd start the following should be run

# ./bdsu postfix ./bdmilterd -s

and, respectively, before bd stop:

# ./bdmilterd -k

5) Depending on your distribution, your Postfix MTA might start in a chroot. Debian and Debian-based distributions start in a chroot (var/spool/postfix), while RedHat based distributions don’t. Because of this, we have to make sure the socket used for Postfix <-> bdmilterd communication is visible in that chroot. We have seen that the chroot is usually placed in the queue_directory. The following commands should make sure that happens no matter if your setup uses chroot or not when starting the MTA. Please adapt to your needs.

5.1) find out the queue_directory and set things up for the socket

# export POSTFIXCHROOT=`postconf -h queue_directory`
# mkdir -p $POSTFIXCHROOT/BitDefender $POSTFIXCHROOT/$POSTFIXCHROOT
# chown bitdefender:bitdefender $POSTFIXCHROOT/BitDefender
# chmod 731 $POSTFIXCHROOT/BitDefender

5.2) create a relative symlink to the $POSTFIXCHROOT/BitDefender directory in the $POSTFIXCHROOT/$POSTFIXCHROOT directory.

# ln -s `echo $POSTFIXCHROOT | sed 's#[^/]+#..#g' | \
sed 's#^/##'`/BitDefender $POSTFIXCHROOT/$POSTFIXCHROOT

Example: for $POSTFIXCHROOT=/var/spool/postfix, the command above should create the /var/spool/postfix/var/spool/postfix/BitDefender symlink which should point to ../../../BitDefender, thus pointing to /var/spool/postfix/BitDefender. Please make sure this link is created correctly on systems using chroots to run the MTA.

6) Configure the location of the bdmilterd socket file:

# ./bdsafe agent configure milter sockpath "$POSTFIXCHROOT/BitDefender/"

7) Configure Postfix to know the location of the bdmilterd socket (usually $POSTFIXCHROOT is /var/spool/postfix; adapt to your case). Append these lines to main.cf:

smtpd_milters=unix:/var/spool/postfix/BitDefender/bdmilterd.sock
milter_protocol = 2
milter_default_action = tempfail
milter_connect_timeout = 30s
milter_command_timeout = 30s
milter_content_timeout = 30s

Note: all options other than smtpd_milters can be omitted entirely. If milter_protocol is present, it must be set to 2.

8 ) restart Postfix or reload its configuration:

# postfix reload

9 ) Make sure BitDefender is (re)started

10 ) If the setup works correctly the Received: and X-BitDefender-Scanner: headers of a delivered mail should be of a form similar to this:

[...]
Received: from foo.example.com (foo.example.com [1.2.3.4])
by myexampleserver.com (Postfix) with ESMTP id 123456789AB
[...]
X-BitDefender-Scanner: Clean, Agent: BitDefender Milter 3.0.2 on
myexampleserver, sigver: 7.15108
[..]

Bitdefender Scanner is very easy to install. The package comes as .rpm, .deb and .tar. For example, type in your console:

$ sh -x BitDefender-scanner-7.5-4.linux-gcc3x.i586.deb.run

and follow the install procedure.

Once you have completed the installation, you should update the antimalware engines, as follows:

$ cd /opt/BitDefender-scanner/bin
$ ./bdscan --update

or just:

$ bdscan --update

If your LDA in Postfix is procmail, then you don’t need to make any changes in your main.cf file. Otherwise add this line in /etc/postfix/main.cf:

mailbox_command = /usr/bin/procmail -a "$EXTENSION"

Now, restart the Postfix server.

If your Postfix server is using another LDA, but it is using .forward files, a solution per user, not system wide, is to add a .forward file in your home directory and then put the following line in it:

|/usr/bin/procmail

Make sure you have the procmail package installed and that you use the actual path to your procmail binary, which is system specific.

In your home directory, edit the .procmailrc file. If it is not there, then create it as follows:

$ echo >$HOME/.procmailrc

You can enable the pre-delivery scanner, system wide, by editing /etc/.procmailrc as root.

Add the following lines in .procmailrc:

PATH=/usr/local/bin:/usr/bin:/bin
MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
LOGFILE=$MAILDIR/procmail.log
FILE=`mktemp`
:0 fw
|cat > $FILE; if bdscan $FILE &>/dev/null; then formail -a "X-BDScan:
clean" <$FILE; else formail -a "X-BDScan: infected" <$FILE; fi; rm -f $FILE

You must modify the MAILDIR variable and bdscan must be in your path.

Procmail will add to your email, a header that contains:

X-BDScan: clean

or

X-BDScan: infected

depending on the bdscan result.

If you want the infected email to be deleted, then add the following lines to .procmailrc:

:0
* ^X-BDScan: infected
/dev/null

If you want to move the infected files to a local directory, add:

:0
* ^X-BDScan: infected
Maildir/infected