Home » Backup & Recovery » Can Linux delete immutable files?

Can Linux delete immutable files?

domalab.com - linux delete file

In this final part of the article series dedicated to immutability, this article shows the most important bits when it comes down to hardening the security on the linux servers hosting the immutable backups. So how is it possible for bad actors (users and apps) to prevent linux delete immutable files?

Primarily connectivity and permissions.

From a connectivity perspective the first and most obvious is to disable SSH access. Otherwise this could let unauthorised access from unsolicited or compromised accounts. Ideally the servers should be secured in a locked down server room. The only access available is through “local” consoles like ILO, iDRAC and similar.

From a permissions point of view the least the better. Also the user intended to connect to the linux server should not be part of the sudo group or equivalent. This prevents a compromised user (that can still remotely connect when SSH is left unattended) to run admin commands.

In the case of Veeam Immutable backups, data is transported using the Data Mover service (veeamtransport). A special and separate service (immunereposvc) is responsible to check and set the immutable bit on the required files (full and incremental backup files) plus the special file .veeam.N.lock which is updated with the immutability time period for each file in the backup chain (Full .vbk – Incremental .vib)

Moreover, assuming other local accounts gain access to the linux server are not able to list, change or modify any file and folder. This is possible when the ownership and access control for the immutable files location is configured only for the intended account. As long as the permissions remain intact, even the root account will receive the “Permission denied” when trying to delete or change any of these files.

The root account, as special user has the ability to add/remove the “i” bit for immutability by mean of the “chattr” change attribute command. As soon as the attribute is removed, the files can be deleted from the root user again. So the following is a best practice:

  • Avoid leaving the SSH service running unattended
  • Only use “local console” to connect to the linux server
  • Employ Single-Use credentials for the user intended to connect to the linux server
  • Deploy the necessary components
  • Remove the user from the sudo group (in case SSH is still on)
  • Disable the SSH service when the install has completed
  • Install a 2FA solution for increased security

Veeam Hardened Repositories follow the Sec 17a-4, FINRA 4511 CFTC 1.31 regulations with regards to W.O.R.M storage (Write Once Read Many). Configuring the Hardened Repositories with the principles above ensures the highest level of protection and safeguard of the backup data.

 

About the author

Michele Domanico

Passionate about Virtualization, Storage, Data Availability and Software Defined Data Center technologies. The aim of Domalab.com is sharing with the Community the knowledge and experience gained with customers, industry leaders and like minded peers. Always open to constructive feedback and new challenges.

Add Comment

Click here to post a comment

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Browse articles

December 2023
M T W T F S S
 123
45678910
11121314151617
18192021222324
25262728293031

Articles by Category

Archives

About Domalab

Welcome to my personal Blog. Feedback is welcome and in case of questions you can also contact me at 

doma-blog@outlook.com

error: Content is protected !!
%d