In the time of ransomware and and cybersecurity attacks being in the news almost daily things like our disaster recovery applications have to start taking those protections very seriously. Often the easiest rung to reach in terms of good application security is having Multi-Factor Authentication (MFA) required for logins. For most MFA is old hat but for those unfamiliar modern MFA can take various forms including:

• SMS One Time Passcode (OTP): codes that are pushed from the website to you via SMS text messages. Better than nothing but easily spoofable.
• OTP Apps: apps such as Google Authenticator, Authy or 1password that provide the codes based on scanning a QR code typically to setup then using your mobile device to generate the code
• Push MFA: apps such as Duo or Gmail that when you authenticate it triggers a push notification to a particular instance of a mobile app that is also authenticated

With Veeam’s upcoming v12 release of Veeam Backup and Replication they are now supporting OTP App MFA in their console application. This takes a little bit of setup and in my particular case is a little quirky to setup but it does definitely work. Let’s walk through how to put this in effect.

Enable MFA in VBR v12

1. Once you have v12 Console installed, either the local or remote version, open it and navigate to Users and Roles

2. MFA in VBR is not supported with any use of groups. By default members of the local Adminstrators group are given the Veeam Backup Administrator role so we need to start by adding your own login first. You can do this with the Add… button.

If you weren’t already aware you’ll notice that there are number of roles that can be selected. More information about what each of these can do is available in the helpcenter documentation.

Bug: One other thing I’ll add here is that I noticed a quirk in some of our setups. If you use the browse method and if for some reason the NetBIOS domain is not just the portion before the first dot in the FQDN domain (for example prem for prem.lab.internal) then by default the User or group in the blank above is filled in incorrectly. In a few of our test environments we use the full FQDN without the dots as the NetBIOS name and it led to some issues that were easily fixed by just typing the correct domain in the blank. This feedback has been shared and I imagine it will be fixed before GA.

2a. If by chance you do not remove the groups before enabling MFA and hitting OK you will be presented with an error. Again, simply remove the groups to get past this.

3. It is important to understand that once you protect an account with MFA you will not be able to use it with automation methods such as PowerShell. To allow for this you will need to create an automation specific user, preferably with a very robust and often changed password, and set it in VBR as a service account to disable MFA. Complete adding your needed users and check the “Require two-factor authentication for interactive logon” to complete the server setup portion.

4. Once you setup your accounts in Veeam Console you will need to close out and relaunch to get into the MFA registration wizard. You would do this as you normally would, either using Windows session authentication or filling in the username and password.

5. Once you hit Connect you will get the standard MFA QR code for registration. Simply open the app of your choice and add by scanning the QR code then supply an active confirmation code to complete setup.

And with that you have now enabled 2 factor authentication for your Veeam Backup and Replication Users. You can potentially increase this further by not giving permissions to the user’s Windows logon account but instead doing a secondary, application specific account making them type in a username and password in step 4 above. With that you would have to authenticate to Windows, authenticate to Veeam and then provide an MFA code. That would all just depend on your organization’s security needs.

Conclusion

At the end of the day security practices should be a part of everything we do as IT and Disaster Recovery administrators. Little things like requiring MFA for our critical backups add up to a well design, layered security model.

In the past few years Immutability, the concept of making data unable to be deleted or modified, has been a core tenant of disaster recovery design and has driven the rise of Object Storage for backup purposes. To this point in the Veeam ecosphere immutability has been contained to traditional Infrastructure backups, virtual machines, and cloud native instances, but there has been a great appetite for this capability to apply to SaaS backups as well.

With the upcoming v7 release of Veeam’s Backup for Microsoft365 (VB365) the product now has a method of allowing true, verifiable immutability or object-lock on backup sets. In their interpretation of how to make this capability happen Veeam has incorporated a long known best practice for all things backup, adhering to the 3-2-1 backup methodology where there are 2 copies of the backup. This happens because immutability can only occur on the secondary copy of the backup set, leaving the primary set on unlocked, performant object storage to ensure that recovery operations are capabilities in a optimized manner.

So What’s Changed?

Starting with VB365 v6 support for backup copies have been available but only in very limited situations. First the backups must land in Azure Blob or Amazon S3 for the first copy, second the copies could only go to related secondary locations. For example, backups residing in AWS S3 could only be copied to S3, S3 Infrequent Access or AWS Glacier storage. Further while these backups could be encrypted, they could not have the object-lock attribute, the object storage attribute that powers immutability, set.

With VB365 v7 both statements have changed. First backup copies can now land on Azure, S3 or any S3 compatible backup storage that supports the necessary functions of the S3 API. Further those backups can now optionally have the object-lock attribute set at the object repository level, with the immutability expiration automatically set to the duration of the retention period. In other words, unlike Veeam Backup and Replication where retention points are set at the job level and immutability is set at the repository level, with VB365 both are set together at the repository level.

VB365 Immutability in Action

1. Add primary object storage and backup repository. On this repository is when you want to set your long-term retention as needed.  Repeat the process until you have repositories to support your organization’s backup needs in accordance with best practices for maximum supported objects per repository.

2. Add your secondary object storage and VBO repositories. These should arguably be setup in a different object storage environment as your primary copy but still well connected. Because you will be writing data that is set to object-lock for the retention period of the repository you should consider the shortest retention period here in accordance with your organization’s data policy and standards.

3. Create backup jobs targeting your primary backup repositories. These will automatically copy to the secondary repository and become immutable as it is written.

Conclusion

This capability is going to be a game changer for everyone who uses VB365 to protect their M365 workloads. While this capability is only supported for VB365 data residing on object storage there’s an argument to be made that if you haven’t already moved or reseeded that data to object by now you should be working on it. Customers will be able to maintain a secondary copy of their backup sets on disparate systems to ensure the durability of their backups. If you can’t tell I’m actually very excited by this capability and look forward to using it in production!

So if you haven’t heard of it yet Microsoft is doing some pretty cool stuff in terms of Local Server management in what they are calling Project Honolulu. The latest version, 1802, was released March 1, 2018, so it is as good a time as any to get off the ground with it if you haven’t yet. If you’ve worked with Server Manager in versions newer than Windows Server 2008 R2 then the web interface should be comfortable enough that you can feel your way around so this post won’t be yet another “cool look at Project Honolulu!” but rather it will help you with a hiccup in getting it up and running well.

I was frankly a bit amazed that this is evidently a web service from Microsoft not built upon IIS. As such your only GUI based opportunity to get the certificate right is during installation, and that is based on the thumbprint at that, so still not exactly user-friendly. In this post, I’m going to talk about how to find that thumbprint in a manner that copies well (as opposed to opening the certificate) and then replacing the certificate on an already up and running Honolulu installation. Giving props where they do this post was heavily inspired by How to Change the Thumbprint of a Certificate in Microsoft Project Honolulu by Charbel Nemnom.

Step 0: Obtain a certificate: A good place to start would be to obtain or import a certificate to the server where you’ve installed Project Honolulu. If you want to do a public one, fine, but more likely you’ll have a certificate authority available to you internally. I’m not going to walk you through this again, my friend Luca Dell’Oca has a good write up on it here. Just do steps 1-3.

Make note of the Application ID here, you’ll use it later

Step 1: Shut it down and gather info: Next we need to shut down the Honolulu service. As most of what we’ll be doing here today is going to be in Powershell let’s just do this by CLI as well.

Get-Service *Gateway | Stop-Service

Now let’s take a look at what’s currently in place. You can do this with the following command, the output should look like the figure to the right. The relevant info we want to take note of here is 1) The port that we’ve got Honolulu listening on and 2) The Application ID attached to the certificate. I’m just going to reuse the one there but as Charbel points out this is generic and you can just generate a new one to use by using a generator.

netsh http show sslcert

Pick a cert, not any cert

Finally, in our quest to gather info let’s find the thumbprint of our newly loaded certificate. You can do this by using the Get-ChildItem command like this

Get-ChildItem -path cert:\LocalMachine\my

As you can see in the second screenshot that will give you a list of the certificates with thumbprints installed on your server. You’ll need the thumbprint of the certificate you imported earlier.

Step 2: Make it happen: Ok now that we’ve got all our information let’s get this thing swapped. All of this seems to need to be done from the legacy command prompt. First, we want to delete the certificate binding in place now and the ACL. For the example shown above where I’m using port 443 it would look like this:

cmd
netsh http delete sslcert ipport=0.0.0.0:443
netsh http delete urlacl url=https://+:443/

Now we need to put it back into place and start things back up. Using the port number, certificate thumbprint, and appid from our example the command to re-add the SSL certificate would look like this. You, of course, would need to sub in your own information.  Next, we need to put the URL ACL back in place. Finally, we just need to start the service back up from PowerShell.

netsh http add sslcert ipport=0.0.0.0:443 certhash=C9BB91F7D8755BD217444046A7E68CEF56E15717 appid={1fb046ab-09b5-4029-9ec5-6e17002d495f}
netsh http add urlacl url=https://+:443/ user="NT Authority\Network Service"
Get-Service *Gateway | Start-Service

Conclusion

At this point, you should be getting a shiny green padlock when you go the site and no more nags about a bad certificate. I hope as this thing progresses out of Tech Preview and into production quality this component gets easier but at least there’s a way.

Hi all, I’m writing this to document a fix to an interesting challenge that has pretty much been my life for the last 24 hours or so. Through a comedy of errors and other things happening, we had a situation where the upstream CA from our VMware Certificate Authority (and other things) became very unavailable and the certificate authorizing it to manage certificates expired. Over the course of the last couple of days I’ve had to reissue certificates for just about everything including my Nimble Storage array and as far as vSphere goes we’ve had to revert all the certificate infrastructure to essentially the same as the out of the box self-signed guys and then reconfigure the VMCA as a subordinate again under the Root CA.

Even after all that I continued to have an issue where my Production VVOLs storage was inaccessible to the hosts. That’s not to say they weren’t working, amazingly and as a testament to the design of how VVOLs works my VMs on it ran throughout the process, but I was very limited in terms of the management of those VMs. Snapshots didn’t work, backups didn’t work, for a time even host migrations didn’t work until we reverted to the self-signed certs.

Thanks for a great deal of support and help from both VMware support and Nimble Storage Support we were finally able to come up with a runbook in dealing with a VVOL situation where major certificate changes occurred on the vSphere side. There is an assumption to this process that by the time you’ve got here all of your certificates both throughout vSphere as well as with the Nimble arrays are good and valid.

1. Unregister the VASA provider and Web Client integration from the Nimble array. This can be done either through the GUI in Administration>VMware Integration by editing your vCenter, unchecking the boxes for the Web Client and VASA Provider and hitting save. This can also be done via the CLI using the command

   vcenter --unregister <vcenter_name> --extension vasa
   vcenter --unregister <vcenter_name> --extension web

2. Register the integrations back in. Again, from the GUI simply just check the boxes back and hit save. If successful you should see a couple of little green bars briefly appear at the top of the screen saying the process was successful. From the CLI the commands are pretty similar

   vcenter --register <vcenter_name> --extension vasa
   vcenter --register <vcenter_name> --extension web

3. Verify that your VASA provider is available in vCenter and online. This is just to make sure that the integration was successful. In either the Web Client or the HTML5 client go to vCenter> Configure> Storage Provider and look for the entry that matches the name of your array group and in the URL has the IP address of your array’s management interface. This should show as online. As you have been messing with certificates its probably worth looking at the Certificate Info tab as well while you are here to verify that the certificate is what you expect.
4. Refresh the CA Certificates on each your hosts. Next, we need to ensure that all of the CA certificates are available on the hosts to ensure they can verify the certificates presented to them by the storage array. To do this you can either right-click each host > Certificates > Refresh CA Certificates or if you navigate to the configuration tab of each host, go to Certificate there is a button there as well. While in the window it is worth looking at the Status of each host’s certificate and ensure that it is Good.
   
5. Restart the vvold service on each host. This final step was evidently the hardest one to nail down and find in the documentation. The simplest method may be to simply reboot each of your hosts as long as you can put them into maintenance mode and evacuate them first. The quicker way and the way that will let you keep things running is to enter a shell session on each of your hosts and simply run the following command:

   /etc/init.d/vvold restart

   Once done you should see a response like the feature image on this post and a short while later your VVOLs array will again become available for each host as you work on them.

That’s about it. I really cannot thank the engineers at VMware (Sujish) and Nimble (Peter) enough for their assistance in getting me back to good. Also I’d like to thank Pete Flecha for jumping in at the end, helping me and reminding me to blog this.

If nothing else I hope this serves as a reminder to you (as well as myself) that certificates should be well tended to, please watch them carefully. 😉

Just a quick post related to today’s VMware security advisories. VMware released a pair of advisories today, CVE-2016-5330 and CVE-2016-5331 and while both are nasty their scopes are somewhat limited. The 5331 issue is only applicable if you are running vCenter or ESXi 6.0 or 6.0U1, Update 2 patches the bug. The 5330 is limited to Windows VMs, running VMware Tools, and have the option HGFS component installed. To find out if you are vulnerable here’s a Power-CLI script to get all your VMs and list the installed components. Props to Jason Shiplett for giving me some assistance on the code.

$vms = Get-VM | where {$_.PowerState -eq "PoweredOn" -and $_.GuestId -match "Windows"}
 
ForEach ($vm in $vms){
	Write-Host $vm
	$namespace = "root\CIMV2"
	$componentPattern = "hcmon|vmci|vmdebug|vmhgfs|VMMEMCTL|vmmouse|vmrawdsk|vmxnet|vmx_svga"
	(Get-WmiObject -class Win32_SystemDriver -computername $vm -namespace $namespace |
		where-object { $_.Name -match $componentPattern } |
		Format-Table -Auto Name,State,StartMode,DisplayName
	)
}

While the output is still a little rough it will get you there. Alternatively if you are just using this script for the advisory listed you can change where-object { $_.Name -match $componentPattern }  to where-object { $_.Name -match “vmhgfs” } . This script is also available on GitHub.

I’ve been a long time user of RANCID for change management on network devices but frankly it’s always left me feeling a little bit of a pain to use and not particularly modern. I recently decided it was time for my OpenNMS/RANCID server to be rebuilt, moving OpenNMS up to a CentOS 7 installation and in doing so thought it was time to start looking around for an network device configuration management alternative. As is many times the way in the SMB space, this isn’t a task that actual budgetary dollars are going to go towards so off to Open Source land I went!  rConfig immediately caught my eye, looking to me like RANCID’s hipper, younger brother what with its built in web GUI (through which you can actually add your devices), scheduled tasks that don’t require you to manually edit cron, etc. The fact that rConfig specifically targets CentOS as its underlaying OS was just a whole other layer of awesomesauce on top of everything else.

While rConfig’s website has a couple of really nice guides once you create a site login and use it, much to my dismay I found that they hadn’t been updated for CentOS 7 and while working through them I found that there are actually some pretty significant differences that effect the setup of rConfig. Some difference of minor (no more iptables, it’s firewalld) but it seems httpd has had a bit of an overhaul. Luckily I was not walking the virgin trail and through some trial, error and most importantly google I’ve now got my system up and running. In this post I’m going to walk through the process of setting up rConfig on a CentOS minimal install with network connectivity with hopes that 1) it may help you, the two reader’s I’ve got, and 2) when I inevitably have to do this again I’ll have documentation at hand.

Before we get into it I will say there are few artistic licenses I’ve taken with rConfig’s basic setup.

1. I’ll be skipping over the network configuration portion of the basic setup guide. CentOS7 has done a great job of having a single configuration screen at install where you setup your networking among other things.
2. The system is designed to run on MySQL but for a variety of reasons I prefer MariaDB. The portions of the creator’s config guide that deal with these components are different from what you see here but will work just fine if you do them they way described.
3. I’m virtualized kind of guy so I’ll be installing the newly supported open-vm-tools as part of the config guide. Of course, if you aren’t installing on ESXi you won’t be needing these.
4. Finally before proceeding please be sure to go ahead and run a yum update to make sure everything’s up to date and you really do have connectivity.

Disabling Stuff

Even with the minimal installation there are things you need to stop to make things work nice, namely the security measures. If you are installing this in the will this would be a serious no no, but for a smaller shop behind a well configured firewall it should be ok.

vi /etc/sysconfig/selinux

Once in the file you need to change the “SELINUX=enforcing ” line to “SELINUX=disabled “. To do that hit “i” and then use vi like notepad with the arrow keys. When done hit Esc to exit insert mode and “:wq ” to save and exit.

systemctl disable firewalld.service
systemctl stop  firewalld.service

Installing the Prerequisites

Since we did the minimal install there are lots of things we need to install. If you are root on the box you should be able to just cut and paste the following into the cli and everything gets installed. As mentioned in the original Basic Config Guide, you will probably want to cut and past each line to make sure everything gets installed smoothly.

yum install -y wget mlocate attr open-vm-tools
yum -y install httpd openssl-devel openssl mod_ssl vsftpd
yum -y groupinstall 'Development Tools'
yum -y install telnet bind-utils
yum -y install vixie-cron crontabs
yum -y install mariadb-client mariadb-server  mod_authn_dbd mariadb-devel

Autostart Services

Now that we’ve installed all that stuff it does us no good if it isn’t running. CentOS 6 used the command chkconfig on|off to control service autostart. In CentOS 7 all service manipulation is now done under the systemctl command. Don’t worry too much, if you use chkconfig or service start both at this point will still alias to the correct commands.

systemctl enable ntpd.service
systemctl start ntpd.service
systemctl enable httpd.service
systemctl start httpd.service
systemctl enable mysqld.service
systemctl start mysqld.service
systemctl enable vsftpd.service
systemctl start vsftpd.service
systemctl enable crond.service
systemctl start crond.service

Finalize Disable of SELinux

One of the hard parts for me was getting the step 5/6 in the build guide to work correctly. If you don’t do it the install won’t complete, but it also doesn’t work right out of the box. To fix this the first line in prerequisites installs the attr package which contains the setfattr executable. Once that’s installed the following checks to see if the ‘.’ is still in the root directories ACLs and removes it from the /home directory. By all means if you know of a better way to accomplish this (I thought of putting the install in the /opt directory) please let me know in the comments or on twitter.

cd /
ll | grep home
**output**  drwxr-xr-x.   2 root root  4096 Sep 23  2011 home
find /home -print0 | xargs -0 -n 1 sudo setfattr -h -x security.selinux

MySQL Secure Installation on MariaDB

MariaDB accepts any commands you would normally use with MySQL. the mysql_secure_installation script is a great way to go from baseline to well secured quickly and is installed by default. The script is designed to

• Set root password
• Remove anonymous users
• Disallow root logon remotely
• Remove test database and access to it
• Finally reload the privilege tables

I tend to take all of the defaults with the exception of I allow root login remotely for easier management. Again, this would be a very bad idea for databases with external access.

#Verify that MariaDB is running
systemctl status mariadb.service
**output** mariadb.service - MariaDB database server
**output** Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled)
**output** Active: active (running) since
mysql_secure_installation

Then follow the prompts from there.

As a follow up you may want to allow remote access to the database server for management tools such as Navicat or Heidi SQL. To do so enter the following where X.X.X.X is the IP address you will be administering from. Alternatively you can use root@’%’ to allow access from anywhere.

mysql -u root -p
***output*** password:
mysql> GRANT ALL ON *.* to root@'X.X.X.X' IDENTIFIED BY 'your-root-password';
mysql> FLUSH PRIVILEGES;

 # Install VSFtpd and configure it
 mv /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.original
 echo "#Custom rConfig VSFTPD conf file" > /etc/vsftpd/vsftpd.conf;
 echo "anonymous_enable=NO" >> /etc/vsftpd/vsftpd.conf;
 echo "listen=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "local_enable=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "write_enable=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "local_umask=022" >> /etc/vsftpd/vsftpd.conf;
 echo "dirmessage_enable=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "xferlog_enable=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "connect_from_port_20=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "xferlog_std_format=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "pam_service_name=vsftpd" >> /etc/vsftpd/vsftpd.conf;
 echo "userlist_enable=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "tcp_wrappers=YES" >> /etc/vsftpd/vsftpd.conf;
 echo "idle_session_timeout=600" >> /etc/vsftpd/vsftpd.conf;
 echo "data_connection_timeout=120" >> /etc/vsftpd/vsftpd.conf;
 echo "ftpd_banner=Welcome to the FTP Service" >> /etc/vsftpd/vsftpd.conf;
echo "ls_recurse_enable=YES" >> /etc/vsftpd/vsftpd.conf;

systemctl enable vsftpd.service
systemctl start vsftp.service

apache  ALL = (ALL) NOPASSWD: /usr/bin/crontab, /usr/bin/zip, /bin/chmod, /bin/chown, /usr/bin/whoami
Defaults:apache !requiretty

cd /home
unzip rconfig-3.0.3.zip    #3.0.3 is the latest version at time of writing, this may differ for you.
chown -R apache /home/rconfig

mv /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.original

cp /home/rconfig/httpd.txt /etc/httpd/conf/httpd.conf

systemctl start httpd.service

This week Veeam Software officially released their new Endpoint Backup Free product introduced at VeeamON last October after a few months of beta testing. The target for this product is to allow image based backup of individual physical machines, namely workstations, allowing for Change Block Tracking much like users of their more mature Backup & Replication product have been used to in virtualized environments. Further Veeam has made a commitment that in the product is and should always be freely available making it possible for anybody to perform what is frankly enterprise level backup of their own computers with no cost other than possibly a external USB drive to store the backup data.  I’ve been using the product throughout the beta process and in this post I’ll outline some of the options and features and review how to get started with the product.

Also released this month by Veeam is the related Update 2 for Backup & Replication 8. This update in this case allows a Backup Repository to be selected as a target for your Endpoint Backup job after some configuration as shown here. Keep in mind if you are wanting to backup to local USB or a network share this isn’t necessary but if you are already a B&R user this will make managing these backups much better.

Getting Started with Installation

I have to say Veeam did very well keeping the complexity under the water in this one. Once downloaded and run the installation choices consist completely of one checkbox and one button. That’s it. Veeam Endpoint Backup seems to rely on a local SQL Server Express installation to provide backend services just like the bigger Backup & Replication install but it is installed on the fly. I have found that if there is pending Windows Updates to complete the installer will prompt you to restart prior to continuing to configuring your backup.

Configuring the Job

Once the installation is complete the installer will take you directly into configuring the backup as long as you are backing up to an external storage device. If you plan to use a network share or Veeam Backup Repository you will need to skip the step and configure the job once in the application. Essentially you have the following options:

• What you wantto backup
  • Entire computer; which is image based backup
  • Specific volumes
  • File level backup
• Where you want to back it up to (each will generate another step or two in the wizard)
  • Local storage
  • A shared folder
  • Veeam Backup & Replication repository
• Schedule or trigger for backups
  • Daily at a a specific time
  • Trigger a backup on a lock, log off or when the backup target is connected

Creating the Recovery Media

The last step of installing/configuring Endpoint Backup is to create the restore media. This creates a handy disk or ISO that you can boot off of to allow you to do a Bare Metal (or Bare VM :)) recovery of the machine. From an enterprise standpoint if you are rolling Endpoint Backup out to a fieldful of like machines I really can’t find a good reason to create more than one of these per model of device. Personally I’ve been creating the ISOs for each model and using it in conjunction with a Zalman VE-300 based external hard drive to keep from having lots of discs/pen drives around. If you are using this to backup physical servers it would also be a first step to being able to quickly restore to a VM if that is part of your disaster recovery plan.

As a trick what I’ve found is I have installed the product on a VM for no other reason but to create the recovery media. This way I know I’ll have the drivers to boot to it if need be. Further once you boot to the recovery media you’ll find all kinds of little goodies that make it a good ISO to have available in your bag.

Conclusion

I’ve played with lots of options, both paid and free, over the years for backing up a physical computer on a regular basis and even setting the general Veeam fanboy type stuff aside, this is the slickest solution for this problem I’ve ever seen. The fact that it is free and integrates into my existing Enterprise solution are definitely major added bonuses, but even in a standalone, “I need to make backups of Grandma’s computer” situation it is a great choice. If you find you need a little help with getting started the Veeam has created a whole Endpoint Backup forum just for this product. My experience both here and with other products is that there is generally very quick response from very knowledgeable Veeam engineers, developers and end users happy to lend a hand.

I’m pretty well versed in the ways of Anti-Virus in Windows but I’ve wanted to get an AV engine installed on my Linux boxes for a while now. In looking around I’ve found a tried and true option in ClamAV and after a few stops and starts was able to get something usable. I’d still like to figure out how to have it send me a report by e-mail if it finds something but that’s for another day; I don’t have enough Linux in my environment to necessitate me putting the time in for that.

So with that here’s how to quickly get started.

Step 0: If not already there, install the EPEL repository

sudo yum install epel-release -y

Step 1: Install ClamAV

sudo yum install clamav clamd -y

Step 2: Perform the 1st update of ClamAV definitions (this will happen daily by default afterwards)

sudo /usr/bin/freshclam

Step 3: Enable and Start Services

sudo chkconfig clamd on
sudo service clamd start

Step 4: Configure Daily Cron Job

I chose to have it scan the whole system and only report infected files, you may want to do differently

sudo vi /etc/cron.daily/daily_clamscan

Enter the following:

#!/bin/bash
SCAN_DIR="/"
LOG_FILE="/var/log/clamav/daily_clamscan.log"
/usr/bin/clamscan -i -r $SCAN_DIR >> $LOG_FILE

Note the -i option tells it to only return infected files, the -r tells it to recursively search. You may want to add the –remove option as well to remove files that are seen as infected.

Step 6: Make Cron Job Executable

sudo chmod +x /etc/cron.daily/daily_clamscan

You can then kick of a manual scan if you’d like using

sudo /etc/cron.daily/daily_clamscan

That’s it! pretty simple and all of your output will be logged daily to the /var/log/clamav/daily_clamscan.log file for review.