This blogpost is all about… what if…

What I want to prevent with the anomalities and the inline scanning is that people start to believe that we (as a (very good and trustworthy) backupvendor) are going to give the impression that clients don’t need any security anymore… because… we can detect anomalities during the moment we take backups.
Well.. that last part is true, but keep in mind… that means it is already too late! way too late!
Your first line of defense is the one we don’t provide: firewalls, anti-virus, segmentation on networks,…

Now… what if… your first line of defense actually detects something and were able to do some sort of a “ping” to us.
Great news!!! We can accept those requests and it is brand new in V12.1. It is called “Veeam Incident API”. A very nice (and yet again simple) effective way to take yet another quick and last backup when a third-party notifies something wrong.

The main concept was explained very well by my colleague in France. And I’ll be re-using his sample file.

Adding this little check checkbox would allow us to take that additional last backup whenever some device detects something strange going on. So at that moment it might not be too late yet… but potentially the malware is only in its startup-phase and impact at that moment is just extremely low(and therefore still easy to extract with for instance secure restore).

Now… how would that external device do that: it’s easy: talk to us/the API.

I bet yet another colleague of me Steve (Stephan Herzig) made the test-powershell script. But those triggers can be executed by any other device. The most important is the timestamp and the indication of what it is all about (description and impacted machine). This generates an event and this event then captured by VBR to perform this quick backup.

So let’s combine the forces of those gentlemens and trigger an event on my AD-server.

So the main important part of the code is:

# Trigger a test event

#Building Body trigger a malware alert - Mimimun 2. Others are uuid or ipv6
$body_data = @{
    detectionTimeUtc = "$($utcNow)"
    machine = @{
                 fqdn          = "**********yourfqdn"
                 ipv4          = "**********yourIP"
                }
    details = "Steve's malware Detection Test script"
    engine  = "baptistetellier.fr made me do it"
}

Write-Host "Trigger malware detection event...." -ForegroundColor White
Write-Host ""
$appURI             = "/api/$APIversion/malwareDetection/events"
$body_json          = $body_data | ConvertTo-Json
Post-VeeamRestAPI-Audit -AppUri $appURI -Token $token -body $body_json

They always say save the best for last… because in this example Steve’s script triggered the event (or in real live a security device)… but it actually pops up in the GUI as well. And when we dig a little deeper we’ll get the full details that were passed on to the API too:

For those looking for that last screenshot(I was searching myself quite some time;)) … that is actually the “history-tab”. And with this little trick… I’ll leave the rest for the post of tomorrow… back to the real scanning – anomalities!

To continue on the scanning part and to continue on how it was in the past compared to now let’s make a small comparison on the potential post-operational scanning.

V12	V12.1
Surebackup scan	Surebackup scan + verification and content scan
Secure Restore	Secure restore
Data integration API	Data Integration API + Scan disk
	Index anomalities

Let’s start with the added features. Surebackup job now allows to add a verification and content scan.

It does NOT allow you to test the time to restore a machine, nor the ability to test the OS, but it allows you to scan the integrity of the filesystem and verify certain items are “not there”… example: some malware, some visa-card numbers…
The good thing is that with this setup you can randomly select machines to get processed… pré 12.1 you ware obligated to create a fixed lab, and schedule wisely. Nowadays you could randomly have Veeam select a few jobs, process some in parallel, and thus easily do additional scanning on the complete environment on a monthly base.
Like shown in the right screencap, I’ll be scanning my machines on a malware. Which is not very common, because if I were in that situation I had some unwanted visitors or behavior already in my production environment… and currently checking if I would be able to detect some more traces.
I’m also performing the integrity check. Previously known as health-check. Both as post-processing option available in the job-settings, but also(very unknown) available on our ISO as standalone program.

(after limiting the scope because of limited resources in my lab)
The result is that the disks of the servers are being mounted by our mount server. Followed by actions on this mount (VeeamFLR-folder!).

And if we are going to look after the running processes on our resource monitor in windows we can quickly discover some YARA -executables running. Keep track of the consumed CPU and additional diskload. Make sure that production is not being impacted.

If all goes well, no harmful files were discovered. Now this was “just” 1 rule being used for scanning… it is possible however to combine rules with

include "C:\Program Files\Veeam\Backup and Replication\Backup\YaraRules\file1.yara"
include "C:\Program Files\Veeam\Backup and Replication\Backup\YaraRules\file2.yara"

That would allow you to make some kind of “mother-yara” file. Or yara-file dedicated for silver, gold, premium,… If you want to automate and include all the yara feel free to use explore the following post from my colleague Steve or use the dedicated script directly.
Now we can proceed to the next potential scan for animalities during or partially after the backup was taken. That will be covered tomorrow…

In order to understand the scanning possibilities on V12.1 we must make a very clear distinction on “when” the scanning might happen. I’ll be focussing in the next few posts more on the post-scanning.

pré-V12.1 (yes… I’ll teach you some french :-)) there were already post-scanning possibilities. But they were not very frequently used as they are not very known.
One of the most known was the use of SureBackupJob with some added script on it. This allowed to boot up a server (or a portion of the environment), launch a scanning script in order to achieve something. More information and even an example can be discovered in our helpcenter.
The others were less known/used:
Secure restore that uses the same principle as the surebackup (mount everything temporarily, do something with it and push through in production). Perfect usecase:

• Someone applied the right to be forgotten, a restore of an older version was required and prior pushing everything in production again we remove the person before pushing it in production.
• You’ve been “attacked” or had an issue with a virus-outbreak. You use the isolated step in between to remove the malicious soft prior pushing it back in production (obviously makes more sense)

Now the other one was the least known: data integration API. In short, what does it do? You can (ab-)use Veeam to publish a disk (like we always during in file level restore) and capture the data at C:\VeeamFLR\ on the mountserver. You could potentially mount it on ISCI and access it from another (powerful scanning) server. This will become a disk with read-only(content is coming from backups… and backupdata is not allowed to be “manipulated”). In my early days during a tech session someone asked why not… the answer is actually obvious :-)… otherwise I would be as a backupadmin thé perfect person to commit fraud and manipulate the logfiles in the backups of those financial servers… I would be rich and untraceable ;-).

With V12.1 we cannot “just forget” everything, but we can use more function and even GUI. Just like the data integration API-method –> we just implemented this in the GUI as “publish disk“. It allows you to do more or less exactly the same in the GUI, and do the same operations.
Scanning that: piece of cake… just mount and scan.

Now why so much text and no images in this post? Because the basics are now covered and we can proceed on “guest file indexing” to jump to the “file system activity analysis” which is super-new in VBR. I’ll be covering the main advantages, but also the caveats… stay tuned for tomorrows post because: 1 post a day will keep the hacker away…

What if… your CIO comes to your desk and requests a copy of some data for audit purposes…
Source: some backupjob
Target: somewhere on a Veeam-repository that is shared with an auditor
OR(other usecase)… something is required to seed somewhere else in another geo over an untrustworthy line that would force you to manually restart (over and over) the copy.

Well there are 2 ways to do this. An export data which is explained here: https://veeamclick.be/v12-1-an-unusual-export/

or a simple “copy backup”… NOT a job that would do this permanently, but a one-time-hit-and-run.

By selecting the “copy backup” option it would allow you to simply get another copy of the latest restore point into a new repository.

Next to the export backup (that extracts a specific restore point) this is one of the most frequently forgotten features with many potential usecases.

will keep the hacker away…

To finish the year i’ll be posting every day a new blogpost.

How will this work: easy, just keep a closer look at the blogs section as it will continue to grow every day.

What are the main topics: security related and linked with 12.1; some insights on V-One, some new items on VB365 and much more.