Using Bacula to Improve Computer Security
Since Bacula maintains a catalog of files, their attributes, and either SHA1 or MD5 signatures, it can be an ideal tool for improving computer security. This is done by making a snapshot of your system files with a Verify Job and then checking the current state of your system against the snapshot, on a regular basis (e.g. nightly).
The first step is to set up a Verify Job and to run it with:
Level = InitCatalog
The InitCatalog level tells Bacula simply to get the information on the specified files and to put it into the catalog. That is your database is initialized and no comparison is done. The InitCatalog is normally run one time manually.
Thereafter, you will run a Verify Job on a daily (or whatever) basis with:
Level = Catalog
The Level = Catalog level tells Bacula to compare the current state of the files on the Client to the last InitCatalog that is stored in the catalog and to report any differences. See the example below for the format of the output.
You decide what files you want to form your “snapshot” by specifying them in a FileSet resource, and normally, they will be system files that do not change, or that only certain features change.
Then you decide what attributes of each file you want compared by specifying comparison options on the Include statements that you use in the FileSet resource of your Catalog Jobs.
The Details
In the discussion that follows, we will make reference to the Verify Configuration Example that is included below in the A Verify Configuration Example section. You might want to look it over now to get an idea of what it does.
The main elements consist of adding a schedule, which will normally be run daily, or perhaps more often. This is provided by the VerifyCycle Schedule, which runs at 5:05 in the morning every day.
Then you must define a Job, much as is done below. We recommend that the Job name contain the name of your machine as well as the word Verify or Check. In our example, we named it MatouVerify. This will permit you to easily identify your job when running it from the Console.
You will notice that most records of the Job are quite standard, but that the FileSet resource contains verify=pins1 option in addition to the standard signature=SHA1 option. If you don't want SHA1 signature comparison, and we cannot imagine why not, you can drop the signature=SHA1 and none will be computed nor stored in the catalog. Or alternatively, you can use verify=pins5 and signature=MD5, which will use the MD5 hash algorithm. The MD5 hash computes faster than SHA1, but is cryptographically less secure.
The verify=pins1 is ignored during the InitCatalog Job, but is used during the subsequent Catalog Jobs to specify what attributes of the files should be compared to those found in the catalog. pins1 is a reasonable set to begin with, but you may want to look at the details of these and other options. They can be found in the FileSet Resource section of this manual. Briefly, however, the p of the pins1 tells Verify to compare the permissions bits, the i is to compare inodes, the n causes comparison of the number of links, the s compares the file size, and the 1 compares the SHA1 checksums (this requires the signature=SHA1 option to have been set also).
You must also specify the Client and the Catalog resources for your Verify job, but you probably already have them created for your client and do not need to recreate them, they are included in the example below for completeness.
As mentioned above, you will need to have a FileSet resource for the Verify job, which will have the additional verify=pins1 option. You will want to take some care in defining the list of files to be included in your FileSet. Basically, you will want to include all system (or other) files that should not change on your system. If you select files, such as log files or mail files, which are constantly changing, your automatic Verify job will be constantly finding differences. The objective in forming the FileSet is to choose all unchanging important system files. Then if any of those files has changed, you will be notified, and you can determine if it changed because you loaded a new package, or because someone has broken into your computer and modified your files. The example below shows a list of files that I use on my Red Hat 7.3 system. Since I didn't spend a lot of time working on it, it probably is missing a few important files (if you find one, please send it to me). On the other hand, as long as I don't load any new packages, none of these files change during normal operation of the system.
Running the Verify
The first thing you will want to do is to run an InitCatalog level Verify Job. This will initialize the catalog to contain the file information that will later be used as a basis for comparisons with the actual file system, thus allowing you to detect any changes (and possible intrusions into your system).
The easiest way to run the InitCatalog is manually with the console program by simply entering run. You will be presented with a list of Jobs that can be run, and you will choose the one that corresponds to your Verify Job, MatouVerify in this example.
The defined Job resources are:
1: MatouVerify
2: kernsrestore
3: Filetest
4: kernsave
Select Job resource (1-4): 1
Next, the console program will show you the basic parameters of the Job and ask you:
Run Verify job JobName: MatouVerify FileSet: Verify Set Level: Catalog Client: MatouVerify Storage: DLTDrive Verify Job: Verify List: /tmp/regress/working/MatouVerify.bsr OK to run? (yes/mod/no): mod
Here, you want to respond mod to modify the parameters because the Level is by default set to Catalog and we want to run an InitCatalog Job. After responding mod, the console will ask:
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Client
6: When
7: Priority
8: Pool
9: Verify Job
Select parameter to modify (1-5): 1
you should select number 2 to modify the Level, and it will display:
Levels:
1: Initialize Catalog
2: Verify Catalog
3: Verify Volume to Catalog
4: Verify Disk to Catalog
5: Verify Volume Data
Select level (1-4): 1
Choose item 1, and you will see the final display:
Run Verify job JobName: MatouVerify FileSet: Verify Set Level: Initcatalog Client: MatouVerify Storage: DLTDrive Verify Job: Verify List: /tmp/regress/working/MatouVerify.bsr OK to run? (yes/mod/no): yes
at which point you respond yes, and the Job will begin.
Thereafter the Job will automatically start according to the schedule you have defined. If you wish to immediately verify it, you can simply run a Verify Catalog which will be the default. No differences should be found.
To use a previous job, you can add jobid=xxx option in run command line. It will run the Verify job against the specified job.
*run jobid=1 job=MatouVerify Run Verify job JobName: MatouVerify Level: Catalog Client: 127.0.0.1-fd FileSet: Full Set Pool: Default (From Job resource) Storage: File (From Job resource) Verify Job: MatouVerify.2010-09-08_15.33.33_03 Verify List: /tmp/regress/working/MatouVerify.bsr When: 2010-09-08 15:35:32 Priority: 10 OK to run? (yes/mod/no):
What To Do When Differences Are Found
If you have setup your messages correctly, you should be notified if there are any differences and exactly what they are. For example, below is the email received after doing an update of OpenSSH:
HeadMan: Start Verify JobId 83 Job=RufusVerify.2002-06-25.21:41:05 HeadMan: Verifying against Init JobId 70 run 2002-06-21 18:58:51 HeadMan: File: /etc/pam.d/sshd HeadMan: st_ino differ. Cat: 4674b File: 46765 HeadMan: File: /etc/rc.d/init.d/sshd HeadMan: st_ino differ. Cat: 56230 File: 56231 HeadMan: File: /etc/ssh/ssh_config HeadMan: st_ino differ. Cat: 81317 File: 8131b HeadMan: st_size differ. Cat: 1202 File: 1297 HeadMan: SHA1 differs. HeadMan: File: /etc/ssh/sshd_config HeadMan: st_ino differ. Cat: 81398 File: 81325 HeadMan: st_size differ. Cat: 1182 File: 1579 HeadMan: SHA1 differs. HeadMan: File: /etc/ssh/ssh_config.rpmnew HeadMan: st_ino differ. Cat: 812dd File: 812b3 HeadMan: st_size differ. Cat: 1167 File: 1114 HeadMan: SHA1 differs. HeadMan: File: /etc/ssh/sshd_config.rpmnew HeadMan: st_ino differ. Cat: 81397 File: 812dd HeadMan: st_size differ. Cat: 2528 File: 2407 HeadMan: SHA1 differs. HeadMan: File: /etc/ssh/moduli HeadMan: st_ino differ. Cat: 812b3 File: 812ab HeadMan: File: /usr/bin/scp HeadMan: st_ino differ. Cat: 5e07e File: 5e343 HeadMan: st_size differ. Cat: 26728 File: 26952 HeadMan: SHA1 differs. HeadMan: File: /usr/bin/ssh-keygen HeadMan: st_ino differ. Cat: 5df1d File: 5e07e HeadMan: st_size differ. Cat: 80488 File: 84648 HeadMan: SHA1 differs. HeadMan: File: /usr/bin/sftp HeadMan: st_ino differ. Cat: 5e2e8 File: 5df1d HeadMan: st_size differ. Cat: 46952 File: 46984 HeadMan: SHA1 differs. HeadMan: File: /usr/bin/slogin HeadMan: st_ino differ. Cat: 5e359 File: 5e2e8 HeadMan: File: /usr/bin/ssh HeadMan: st_mode differ. Cat: 89ed File: 81ed HeadMan: st_ino differ. Cat: 5e35a File: 5e359 HeadMan: st_size differ. Cat: 219932 File: 234440 HeadMan: SHA1 differs. HeadMan: File: /usr/bin/ssh-add HeadMan: st_ino differ. Cat: 5e35b File: 5e35a HeadMan: st_size differ. Cat: 76328 File: 81448 HeadMan: SHA1 differs. HeadMan: File: /usr/bin/ssh-agent HeadMan: st_ino differ. Cat: 5e35c File: 5e35b HeadMan: st_size differ. Cat: 43208 File: 47368 HeadMan: SHA1 differs. HeadMan: File: /usr/bin/ssh-keyscan HeadMan: st_ino differ. Cat: 5e35d File: 5e96a HeadMan: st_size differ. Cat: 139272 File: 151560 HeadMan: SHA1 differs. HeadMan: 25-Jun-2002 21:41 JobId: 83 Job: RufusVerify.2002-06-25.21:41:05 FileSet: Verify Set Verify Level: Catalog Client: RufusVerify Start time: 25-Jun-2002 21:41 End time: 25-Jun-2002 21:41 Files Examined: 4,258 Termination: Verify Differences
At this point, it was obvious that these files were modified during installation of the RPMs. If you want to be super safe, you should run a Verify Level=Catalog immediately before installing new software to verify that there are no differences, then run a Verify Level=InitCatalog immediately after the installation.
To keep the above email from being sent every night when the Verify Job runs, we simply re-run the Verify Job setting the level to InitCatalog (as we did above in the very beginning). This will re-establish the current state of the system as your new basis for future comparisons. Take care that you don't do an InitCatalog after someone has placed a Trojan horse on your system!
If you have included in your FileSet a file that is changed by the normal operation of your system, you will get false matches, and you will need to modify the FileSet to exclude that file (or not to Include it), and then re-run the InitCatalog.
The FileSet that is shown below is what I use on my Red Hat 7.3 system. With a bit more thought, you can probably add quite a number of additional files that should be monitored.
A Verify Configuration Example
Schedule {
Name = "VerifyCycle"
Run = Level=Catalog sun-sat at 5:05
}
Job {
Name = "MatouVerify"
Type = Verify
Level = Catalog # default level
Client = MatouVerify
FileSet = "Verify Set"
Messages = Standard
Storage = DLTDrive
Pool = Default
Schedule = "VerifyCycle"
}
#
# The list of files in this FileSet should be carefully
# chosen. This is a good starting point.
#
FileSet {
Name = "Verify Set"
Include {
Options {
verify=pins1
signature=SHA1
}
File = /boot
File = /bin
File = /sbin
File = /usr/bin
File = /lib
File = /root/.ssh
File = /home/kern/.ssh
File = /var/named
File = /etc/sysconfig
File = /etc/ssh
File = /etc/security
File = /etc/exports
File = /etc/rc.d/init.d
File = /etc/sendmail.cf
File = /etc/sysctl.conf
File = /etc/services
File = /etc/xinetd.d
File = /etc/hosts.allow
File = /etc/hosts.deny
File = /etc/hosts
File = /etc/modules.conf
File = /etc/named.conf
File = /etc/pam.d
File = /etc/resolv.conf
}
Exclude = { }
}
Client {
Name = MatouVerify
Address = lmatou
Catalog = Bacula
Password = ""
File Retention = 80d # 80 days
Job Retention = 1y # one year
AutoPrune = yes # Prune expired Jobs/Files
}
Catalog {
Name = Bacula
dbname = verify; user = bacula; password = ""
}
Bacula Antivirus Verify Job Plugin
Distinction between Antivirus Plugin and Malware
In an Antivirus Check, Bacula will transmit the files to the ClamAV Antivirus Socket, which will perform the scan and report to Bacula if any viruses are discovered. In the instance of (here), Bacula will retrieve the Malware database signatures from https://abuse.ch/ and then do a file verification with those signatures. If a Backup job finds malware in the backup content, an error message is generated and the Job status is changed.
Overview
The Bacula Antivirus Plugin provides integration between the ClamAV Antivirus daemon and Bacula verify jobs, allowing post-backup virus detection within Bacula.
ClamAV Installation
ClamAV is an open source (GPLv2) anti-virus toolkit. It provides a flexible and scalable multi-threaded daemon. For more information on ClamAV architecture, best practices and options, please refer to https://docs.clamav.net/
Debian / Ubuntu
Installation
Use the existing Debian packages:
sudo apt-get update sudo apt-get install clamav clamav-daemon
TCP Configuration
The ClamAV 'clamd' daemon is configured with the clamav.conf file (located in /etc/clamav/). By default, the ClamAV daemon listens on a Unix LocalSocket:
LocalSocket /var/run/clamav/clamd.ctl
FixStaleSocket true
LocalSocketGroup clamav
LocalSocketMode 666
In order for Bacula to interact correctly with ClamAV, it is essential to reconfigure the ClamAV daemon so it allows TCP connections instead.
On Debian you can do so automatically by running:
sudo dpkg-reconfigure clamav-daemon
Answer "yes" to reconfigure automatically Make sure to change the socket type to "TCP". Choose the TCP port clamd will listen on (The default port 3310 will be assumed in the rest of the documentation). Continue the reconfiguration according to your needs (press enter to keep the default settings) At the end of the reconfiguration process, the ClamAV daemon restarts. You can verify that the clamav.conf file now contains:
TCPSocket 3310
Alternatively, you can reconfigure manually, by editing clamav.conf. Replace:
LocalSocket /var/run/clamav/clamd.ctl
FixStaleSocket true
LocalSocketGroup clamav
LocalSocketMode 666
with:
TCPSocket 3310
and restart the ClamAV daemon:
sudo systemctl restart clamav-daemon
Fedora / Redhat / Centos
Installation
EPEL creates ClamAV packages for Fedora. To enable the EPEL repository for CentOS:
sudo dnf install -y epel-release
EPEL offers a selection of packages to install ClamAV:
clamd - The ClamAV Daemon
clamav - End-user tools for the ClamAV scanner
clamav-data - Virus signature data for the ClamAV scanner
clamav-devel - Header files and libraries for the ClamAV scanner
clamav-lib - Dynamic libraries for the ClamAV scanner
clamav-milter - Milter module for the ClamAV scanner
clamav-update - Auto-updater for the ClamAV scanner data-files
Bacula minimally requires clamav, clamd, and clamav-update to run:
sudo dnf install -y clamav clamd clamav-update
TCP Configuration
The ClamAV daemon is configured with the clamav.conf file (located in /etc/clamav/).Edit the configuration file:
sudo dnf install nano -y
sudo nano /etc/clamd.d/scan.conf
Make sure the Example line is commented out:
#Example
By default, the ClamAV daemon connects over Unix LocalSocket. In order for Bacula to interact correctly with ClamAV, it is essential to reconfigure the ClamAV daemon so it allows TCP connections instead. enable TCP connection instead by uncommenting the following line:
TCPSocket 3310
Optionally, you can also restrain the TCP binding (by default the ClamAV daemon binds to INADDR_ANY):
TCPAddr 127.0.0.1
Once thatâs done, you can run the virus definition database update:
sudo freshclam
Lastly, start the clamd service and run it on boot:
sudo systemctl enable clamd@scan
sudo systemctl start clamd@scan
Bacula Antivirus Plugin Installation
Installation of the Bacula Antivirus Plugin can be installed from community binary repository, or via the ./configure command line.
Bacula Verify Job Configuration
Parameters
The Bacula Antivirus Plugin accepts two parameters:
- hostname The binding address of the ClamAV daemon (specified in clamav.conf as TCPAddr). Can be any IP4 TCP address. Default is 'localhost'
- port The ClamAV daemon port number (specified in clamav.conf as TCPSocket). Default port is 3310.
Plugin Options
Contrary to "classical" Bacula FD plugins, these parameters are configured in the Verify Job as PluginOptions rather than a "Plugin =" in a FileSet.There are three possible ways to instruct a Bacula Verify Job to run the antivirus plugin:
# Add a PluginOptions directive to the Verify Job configuration (recommended):
Job {
Name = Verify_and_AV_Scan
Type = Verify
Level = Data
Client = localhost-fd
FileSet = LinuxHome
Storage = File
Pool = Default
Messages = Standard
PluginOptions = "antivirus: hostname=127.0.0.1 port=3310" # <---- Add this line here
}
# Specify the "pluginoptions" as a parameter to the 'run' command in bconsole:
*run job=Verify_and_AV_Scan jobid=1 storage=File1 pluginoptions="antivirus: hostname=localhost port=3310"
# Dynamically modify the verify job within bconsole
*run job=Verify_and_AV_Scan jobid=1 storage=File1
JobName: Verify_and_AV_Scan
Level: Data
Client: localhost-fd
FileSet: LinuxHome
Pool: Default (From Job resource)
Storage: File1 (From Command input)
Verify Job: LinuxHome.2021-10-12_05.31.58_03
Verify List:
When: 2021-10-12 05:40:12
Priority: 10
OK to run? (yes/mod/no): m
Parameters to modify:
1: Level
2: Storage
3: Job
4: FileSet
5: Client
6: When
7: Priority
8: Pool
9: Verify Job
10: Plugin Options
Select parameter to modify (1-10): 10
Please Plugin Options string: antivirus: hostname=127.0.0.1 port=3310
Run Verify Job
JobName: Verify_and_AV_Scan
Level: Data
Client: localhost-fd
FileSet: LinuxHome
Pool: Default (From Job resource)
Storage: File1 (From Command input)
Verify Job: LinuxHome.2021-10-12_05.31.58_03
Verify List:
When: 2021-10-12 05:40:12
Priority: 10
Plugin Options: antivirus: hostname=127.0.0.1 port=3310
OK to run? (yes/mod/no): yes
Bacula Antivirus Plugin Behavior
Under normal conditions, the Verify Job will silently scan existing files from the specified backup and should terminate with a "Verify OK" Job status:
run job=Verify_and_AV_Scan jobid=1 storage=File1
JobName: Verify_and_AV_Scan
Level: Data
Client: localhost-fd
FileSet: LinuxHome
Pool: Default (From Job resource)
Storage: File1 (From Command input)
Verify Job: LinuxHome.2021-10-12_06.04.11_03
Verify List:
When: 2021-10-12 06:04:17
Priority: 10
Plugin Options: antivirus: hostname=localhost port=3310
OK to run? (yes/mod/no): yes
12-Oct 06:04 localhost-dir JobId 2: Verifying against JobId=1 Job=LinuxHome.2021-10-12_06.04.11_03
12-Oct 06:04 localhost-dir JobId 2: Start Verify JobId=2 Level=Data Job=Verify_and_AV_Scan.2021-10-12_06.04.17_05
12-Oct 06:04 localhost-dir JobId 2: Connected to Storage "File1" at localhost:8103 with TLS
12-Oct 06:04 localhost-dir JobId 2: Using Device "FileStorage1" to read.
12-Oct 06:04 localhost-dir JobId 2: Connected to Client "localhost-fd" at localhost:8102 with TLS
12-Oct 06:04 localhost-fd JobId 2: Connected to Storage at localhost:8103 with TLS
12-Oct 06:04 localhost-sd JobId 2: Ready to read from volume "TestVolume001" on File device "FileStorage1" (/mnt/archive).
12-Oct 06:04 localhost-fd JobId 2: Got plugin command = antivirus: hostname=localhost port=3310
12-Oct 06:04 localhost-sd JobId 2: Forward spacing Volume "TestVolume001" to addr=228
12-Oct 06:05 localhost-sd JobId 2: End of Volume "TestVolume001" at addr=98844823 on device "FileStorage1" (/mnt/archive).
12-Oct 06:05 localhost-sd JobId 2: Elapsed time=00:00:51, Transfer rate=1.935 M Bytes/second
12-Oct 06:05 localhost-dir JobId 2: Bacula localhost-dir 12.9.2 (11Oct21):
Build OS: x86_64-pc-linux-gnu ubuntu 9.12
JobId: 2
Job: Verify_and_AV_Scan.2021-10-12_06.04.17_05
FileSet: LinuxHome
Verify Level: Data
Client: localhost-fd
Verify JobId: 1
Verify Job:
Start time: 12-Oct-2021 06:04:19
End time: 12-Oct-2021 06:05:21
Elapsed time: 1 min 2 secs
Accurate: no
Files Expected: 2,238
Files Examined: 2,238
Non-fatal FD errors: 0
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: **Verify OK**
When a virus is detected by ClamAV, an error is reported in the Bacula job log and the Job will continue to verify the rest of the files, but it will terminate with a "Verify OK - with warnings" Job status.
Within the job output, the antivirus plugin specifies the infected file(s) and the virus name(s) detected.
run job=Verify_and_AV_Scan jobid=3 storage=File1
JobName: Verify_and_AV_Scan
Level: Data
Client: localhost-fd
FileSet: LinuxHome
Pool: Default (From Job resource)
Storage: File1 (From Command input)
Verify Job: LinuxHome.2021-10-12_06.05.22_07
Verify List:
When: 2021-10-12 06:05:27
Priority: 10
Plugin Options: antivirus: hostname=localhost port=3310
OK to run? (yes/mod/no): yes
12-Oct 06:05 localhost-dir JobId 4: Verifying against JobId=3 Job=LinuxHome.2021-10-12_06.05.22_07
12-Oct 06:05 localhost-dir JobId 4: Start Verify JobId=4 Level=Data Job=Verify_and_AV_Scan.2021-10-12_06.05.27_09
12-Oct 06:05 localhost-dir JobId 4: Connected to Storage "File1" at localhost:8103 with TLS
12-Oct 06:05 localhost-dir JobId 4: Using Device "FileStorage1" to read.
12-Oct 06:05 localhost-dir JobId 4: Connected to Client "localhost-fd" at localhost:8102 with TLS
12-Oct 06:05 localhost-fd JobId 4: Connected to Storage at localhost:8103 with TLS
12-Oct 06:05 localhost-sd JobId 4: Ready to read from volume "TestVolume001" on File device "FileStorage1" (/mnt/archive).
12-Oct 06:05 localhost-fd JobId 4: Got plugin command = antivirus: hostname=localhost port=3310
12-Oct 06:05 localhost-sd JobId 4: Forward spacing Volume "TestVolume001" to addr=98844823
12-Oct 06:05 localhost-sd JobId 4: End of Volume "TestVolume001" at addr=98845442 on device "FileStorage1" (/mnt/archive).
12-Oct 06:05 localhost-sd JobId 4: Elapsed time=00:00:01, Transfer rate=197 Bytes/second
12-Oct 06:05 localhost-fd JobId 4: **Error: /home/nbizet/src/bacula-bee/regress/tmp/eicar Virus detected stream: Eicar-Signature FOUND**
12-Oct 06:05 localhost-dir JobId 4: Bacula localhost-dir 12.9.2 (11Oct21):
Build OS: x86_64-pc-linux-gnu ubuntu 9.12
JobId: 4
Job: Verify_and_AV_Scan.2021-10-12_06.05.27_09
FileSet: LinuxHome
Verify Level: Data
Client: localhost-fd
Verify JobId: 3
Verify Job:
Start time: 12-Oct-2021 06:05:29
End time: 12-Oct-2021 06:05:29
Elapsed time: 1 sec
Accurate: no
Files Expected: 1
Files Examined: 1
Non-fatal FD errors: 1
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: **Verify OK -- with warnings**
The Antivirus Plugin will record events into the catalog for each problem that is detected. The list fileevents command can be used to list them.
*list fileevents jobid=3
Using Catalog "MyCatalog"
+-------+-------------------+----------+----------+------+-------------------------------+
| jobid | path | filename | severity | type | description |
+-------+-------------------+----------+----------+------+-------------------------------+
| 3 | /home/johndoe/mp/ | eicar | 100 | a | stream: Eicar-Signature FOUND |
+-------+-------------------+----------+----------+------+-------------------------------+
The severity represents the level of threat, 0 behing harmless, 100 and above harmful.
The type indicates which kind of event is listed, here `a` meaning "antivirus".
Bacula Malware Detection
Bacula allows you to configure your jobs to detect known Malware. The detection can be done at the end of the Backup job and/or with a Verify job.
The Job directive Check Malware = yes/No can control the behavior.
Job {
Name = MyBackup
Check Malware = yes
FileSet = FullSet
JobDefs = Default
}
FileSet {
Name = FullSet
Include {
Options {
Signature = md5
}
File = /home
}
}
The FileSet of the Backup Job must use the Signature = MD5 or Signature = SHA256 option to use the Check Malware directive.
By default, the Malware database is fetched from abuse.ch. If needed, it can be adapted with the Director MalwareDatabaseCommand directive.
If a Backup job detects a malware in the backup content, an error is reported and the Job status is adapted.
20-Sep 12:26 zog8-dir JobId 9: Start Backup JobId 9, Job=backup.2022-09-20_12.26.30_13
...
20-Sep 12:26 zog8-dir JobId 9: [DI0002] Checking file metadata for Malwares
20-Sep 12:26 zog8-dir JobId 9: Error: [DE0007] Found Malware(s) on JobIds 9
Build OS: x86_64-pc-linux-gnu archlinux
JobId: 9
Job: backup.2022-09-20_12.26.30_13
Backup Level: Full
...
Last Volume Bytes: 659,912,644 (659.9 MB)
Non-fatal FD errors: 1
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Backup OK -- with warnings
The list of the Malware detected in a given Job can be displayed with the list files type=malware command.
*list files type=malware jobid=1
+-------+-----------------------------+---------------+----------+
| jobid | filename | description | source |
+-------+-----------------------------+---------------+----------+
| 1 | /tmp/regress/build/po/fr.po | Malware found | abuse.ch |
+-------+-----------------------------+---------------+----------+
A Verify Job with the level VolumeToCatalog or Data can be configured with the Check Malware=yes directive to report malware in addition to standard errors detected by the Verify Job feature.
*run job=VerifyVolCat jobid=1 yes
Job queued. JobId=7
*wait
You have messages.
*messages
20-Sep 12:26 zog8-dir JobId 7: Verifying against JobId=1 Job=backup.2022-09-20_12.25.48_03
20-Sep 12:26 zog8-dir JobId 7: [DI0002] Checking file metadata for Malwares
20-Sep 12:26 zog8-dir JobId 7: Error: [DE0007] Found Malware(s) on JobIds 1
20-Sep 12:26 zog8-sd JobId 7: Ready to read from volume "TestVolume001" on File device "FileChgr1-Dev1" (/tmp/regress/tmp).
20-Sep 12:26 zog8-sd JobId 7: Forward spacing Volume "TestVolume001" to addr=216
20-Sep 12:26 zog8-sd JobId 7: Elapsed time=00:00:01, Transfer rate=94.08 M Bytes/second
20-Sep 12:26 zog8-dir JobId 7: Bacula zog8-dir 14.1.1 (12Aug22):
Build OS: x86_64-pc-linux-gnu archlinux
JobId: 7
Job: VerifyVolCat.2022-09-20_12.26.14_09
FileSet: Full Set
Verify Level: VolumeToCatalog
Client: zog8-fd
Verify JobId: 1
Verify Job:
Start time: 20-Sep-2022 12:26:16
End time: 20-Sep-2022 12:26:25
Elapsed time: 9 secs
Accurate: yes
Files Expected: 3,640
Files Examined: 3,640
Non-fatal FD errors: 1
SD Errors: 0
FD termination status: OK
SD termination status: OK
Termination: Verify OK -- with warnings