Veeam Dr Orchestrator v.5: VONE – Tagging

Oggi illustreremo come indicare al Veeam Disaster Recovery Orchestrator quali risorse utilizzare per avviare un piano di Disaster Recovery.

Prima di leggere il presente articolo, vi suggeriamo di leggere l’articolo precedente (cliccando qui) che vi permette di verificare lo stato del Server VDrO.

Lo strumento principe dell’etichettatura delle risorse è Veeam One che ricordiamo viene di default installato contestualmente con il Veeam Disaster Recovery Orchestrator v.5.

La procedura è molto semplice:

Dopo essersi collegati via RDP al VDrO Server selezionate sul desktop la voce Veeam One Client (Vedi figura 1)

Figura 1

Dopo aver selezionato la voce Business View (in basso a sinistra), le risorse da etichettare sono:

  1. I Cluster: attraverso tale voce sono identificate le risorse vCenter di Disaster Recovery e di produzione (Figura 2)
  2. I DataStores: attraverso tale voce sono identificate le aree disco ove risiederanno le VM una volta accese (Figura 3)
  3. Le Virtual Machines: attraverso tale voce sono identificate le VM che garantiscono la continuità di servizio in caso di Disastro (Figura 4 e 5).

Figura 2

Figura 3

Figura 4

Figura 5

Nota 1: I job di replica sono stati configurati sul VBR embedded del server VDrO (vedi figura 6)

Figura 6

Nota 2: L’operazione di etichettatura (tagging) è trattata in un precedente post disponibile al seguente link:

https://lnx.gable.it/home-page/veeam-availability-orchestrator-v-3-0-dr-from-replicas/

Per oggi è tutto, a presto!

Ransomware defense part 2: Hardening

There are many documents on the internet that describe how to address this common request.

In this article, I’ll give you a track to move easier around this topic pointing out the most interesting articles.

Before starting let me thank Edwin Weijdema who created an  exhaustive guide to answer the common question (please click here to get it)

Are you ready? Let’s start

1- The first magic point for starting is Wikipedia where I got a good definition:

In computinghardening is usually the process of securing a system by reducing its surface of vulnerability, which is larger when a system performs more functions; in principle, a single-function system is more secure than a multipurpose one. Reducing available ways of attack typically includes changing default passwords, the removal of unnecessary software, unnecessary usernames or logins, and the disabling or removal of unnecessary services.

2- The second point is to understand the concept of Perimeter security:

It is natural barriers or artificially built fortifications that have the goal of keeping intruders out of the area . The strategies can be listed as:

  • Use rack-mount servers
  • Keep intruders from opening the case
  • Disable the drives
  • Lock up the server room
  • Set up surveillance

A complete article is available by clicking here

3- The third point is  Network segmentation:

It is the division of an organization network into smaller and, consequently, a more manageable grouping of interfaces called zones. These zones consist of IP ranges, subnets, or security groups designed typically to boost performance and security.

In the event of a cyberattack, effective network segmentation will confine the attack to a specific network zone and contain its impact by blocking lateral movement across the network via logical isolation through access controls.

Designating zones allows organizations to consistently track the location of sensitive data and assess the relevance of an access request based on the nature of that data.  Designating where sensitive data reside permits network and security operations to assign resources for more aggressive patch management and proactive system hardening.

A complete article is available by clicking here

4- Hardening your Backup Repositories

The next good rules involve your backup architecture and in specific the Backup Repositories:

Windows:

a. Use the built-in local administrator account

b. Set permissions on the repository directory

c. Modify the Firewall

d. Disable remote RDP services

Linux:

e. Create a Dedicated Repository Account

f. Set Permissions on the Repository Directory

g. Configure the Linux Repository in VeeamModify the Firewall

h. Use Veeam Encryption

Do you want to know more about security? If so the Veeam Best Practices are for sure the answer.

The next article will cover monitoring and automatic actions using Veeam-ONE.

5- Prevent injection of shady boot code​

Code injection, also called Remote Code Execution (RCE), occurs when an attacker exploits an input validation flaw in software to introduce and execute malicious code.

To prevent the attack please follow the following rules:

a. Run with UEFI Native Mode​
b. Use UEFI with Secure Boot Standard Mode​
c. Combine Secure Boot with TPM
d. Equip critical servers with a TPM 2.0

Stay tuned and see you soon

Ransomware defense – part 1: Advanced product features are an mandatory requirement

A lot of new challenges came to people who work in IT-Departments these last months.

The number of ransomware attacks has been growing day by day and their attack strategies are becoming more and more evil and dangerous.

The common questions the Managers ask the IT guys are:

a) Are the company protected against these risks?

A good answer is that a successful approach is when the percentage of certainty is more than the percentage of risk.

b) Which are the best practices to be safer?

The key is defining the right process of protection.

The scope of these articles is showing the correct behavior to keep your architecture as safer as possible or, in case of attack, gain as much time as possible to fend off the assault.

The articles will cover the storage point of view and do not deal with perimetral defenses, antimalware, antiviruses, networking strategies, and so on.

Which are the main strategies to adopt?

  1. Having more copies of your data
  2. Hardening the infrastructure
  3. Monitoring behaviors

Are you ready? Let’s start with the first topic !!!

    1. Having more copies of  your data:

Backup software is the right tool to score the goals of this first part.

It has to be able to:

a) Create application consistency backup.

b) Copy backup data to different locations.

Almost all backup software can do that but some additional features can address better the biggest challenges:

Flexible: Backup software should write backup data to different types of repositories and be able to restore it without any required dependency. To be clearer, the backup data have to be self-consistent. The advantage is being able to fit different architecture scenarios (Let’s call it “Data mobility”).

Data-Offline:  back up data should be put into a “quarantine” area where they cannot be either re-written or read. The classic deployment is a Tape Devices architecture or any scripts that automatically detach the repository devices.

Immutability: The backup data cannot be changed until the immutability period is over. This has a double advantage in comparison to data-offline strategy: It changes the repository status as written & online just for the new backup file. It is offline (as Tape technologies) for re-writing to already present backup data. The speed restore option has to remain unchanged.

Immutability can be reached in two ways:

By WORM  (Write Once, Read Many) devices, where the backup files can be used just to restore once they have been added to repositories. For example, technology can be the optical disk, a technology I have been working on in the past.

At Veeam Software this common customer and partner request has been addressed using the immutability propriety of the Object Storage. The good news is that VBR v. 11 implements this great feature directly in Linux Repositories.

Is this enough? I’m still thinking that the backup solution should at least be able to:

  • Check the backup file and the backup content. The only way to check if a backup file is really reusable is restoring it in a separate area where communication with the production environment is forbidden. At Veeam it is called Sure-Backup.
  • Check with your anti-virus/anti-malware that the backup files have not been already attacked somewhere and sometime. At Veeam the technology used is the Data integration API.
  • Before restoring files or VMs in production, check with your anti-virus/anti-malware if your data has been already attacked. At Veeam it is called Secure Restore
  • Perform Replica Jobs. It helps to create a Disaster Recovery Site useful in performing a quick restart of the service.  At Veeam this feature is included from the beginning and the Sure-Backup can be applied with replica too (it is called Sure-Replica). V.11 has a very powerful feature: CDP.
  • Restore backup data to the public cloud when the primary and replication site is totally out of order. I call it Cold Disaster Recovery and it needs at least one restore point available.

The next article topic is how to hardening your backup architecture

See you soon and take care!