Tag Archives: Security

Understanding Immutability Periods for GFS Backups

2 Replies

Determining immutability periods when working with Grandfather, Father, Son (GFS) backups can be a bit tricky considering GFS immutability periods can be determined by either

a) the GFS retention period

b) the Backup Repositories immutability period.

Fortunately, Fabian (@Mildur) from the Veeam R&D forums shared valuable insights that simplify this process. The full discussion can be found here.

The key takeaways from the forum discussion are as follows:

  1. Standalone Repositories: In the case of standalone repositories, data remains immutable throughout the GFS retention period. This means the backup data is secure and unchangeable throughout the entire GFS retention timeline.
  2. Performance Tier without Capacity Tier: When using the Performance Tier without the Capacity Tier, data immutability holds for the complete GFS retention period.
  3. Performance Tier with Move Policy Disabled: Similar to the previous scenario, if the ‘Move Policy’ is disabled within the capacity tier, the data will be immutable for the entire GFS retention period.
  4. Performance Tier with Move Policy Enabled: When the Move Policy is enabled within the Capacity Tier, unlike the previous example, immutability is applied as per the repository’s immutable retention period.
  5. On Capacity Tier: For backup data stored on capacity tier, the immutability aligns with the repository’s settings.
  6. On Archive Tier: Within the Archive Tier, data immutability is for the entire GFS retention period.

An essential note from the forum post highlights that if the GFS retention period is shorter than the Repository immutability period, the Repository immutability period becomes the minimum for all backup files. In other words, whichever is longer out of the two will be the immutability period.

To simplify this further, check out this fabulous table created by a fellow Veeam colleague, John Suh.

2FA for Veeam Servers with Duo

2 Replies

Something that all Veeam administrators should consider is how secure the underlying servers running your Veeam software really are. To help improve security I always try and run through a few recommendations with each Veeam administrator I work with,

  • Inbound connectivity to backup servers from the Internet must not be allowed (3389 anyone?)
  • Any accounts used for RDP access must not have Local Administrator privileges on jump servers, and you must never use the saved credentials functionality for RDP access or any other remote console connections.
  • Ensure timely guest OS updates on backup infrastructure servers

A good resource for keeping up to date on Veeam security recommendations is here. I like to check it out every 3-6 months to ensure I’m still making the right recommendations to my customers.

One other thing I like to recommend in addition to the best practices above is enabling 2FA (Two-Factor Authentication) for all login sessions to underlying servers running Veeam components such as the VBR server, proxies and especially repositories.  With 2FA, even if an attacker illegally acquires the correct username and password, the attacker is also required to gain access to the device used to receive the 2FA verification code. Often this device is a mobile phone or a security token which can easily be disabled if lost or stolen.

It must be noted that 2FA for Veeam consoles is currently not possible (it is a heavily requested feature though) and even with 2FA for login sessions into any Veeam servers there is still a risk that an attacker can access Veeam infrastructure via a Veeam Console running from another machine. This is why off-site/offline backups are so so critical in today’s world of ransomware. Leveraging Veeam Cloud Connect Backup with it’s Insider Protection feature is a great way to easily protect against this kind of risk.

This post will go into detail on how to quickly and easily and enable 2FA for RDP and local logon sessions connecting to your Veeam server.

Continue reading →