Hello community,
correct me if i was wrong :
The Linux hardened repository involves software immutability at the Linux OS level, where Veeam adds an "immutable" attribute (-i) to its backup file to prevent modification or deletion. However, users with root or sudo privileges can remove this attribute, turning the data into a mutable state. Therefore, necessitating monitor root/sudo logins effectively to minimize potential impacts.
# lsattr local_harden_folder_-_192.168.2.199/
----i--------------- local_harden_folder_-_192.168.2.199/local hard2023-09-18T165829.vbk
-------------------- local_harden_folder_-_192.168.2.199/local hard.vbm
-
- Enthusiast
- Posts: 31
- Liked: 1 time
- Joined: Nov 09, 2022 2:20 pm
- Full Name: Dan
- Contact:
-
- Chief Product Officer
- Posts: 32220
- Liked: 7586 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Linux hardened repository "immutable" attribute (-i)
You are correct except the logins part: they are generally impossible because the SSH Server should always be disabled on hardened repository servers to make remote attacks impossible even in theory. You will be getting warnings from the built-in Security & Compliance Analyzer if you don't disable the SSH Server.
But with SSH disabled, only a person with physical server console access (and with a privileged account of course) would be able to remove the immutable attribute.
But with SSH disabled, only a person with physical server console access (and with a privileged account of course) would be able to remove the immutable attribute.
-
- Enthusiast
- Posts: 31
- Liked: 1 time
- Joined: Nov 09, 2022 2:20 pm
- Full Name: Dan
- Contact:
Re: Linux hardened repository "immutable" attribute (-i)
@Gostev thanks
-
- Chief Product Officer
- Posts: 32220
- Liked: 7586 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Linux hardened repository "immutable" attribute (-i)
NP. I also want to add that it's super important to keep in mind the sheer power of physical server access. There're just too many ways for an actor from my previous post to destroy your data, and removing immutable flags is arguably the hardest. Why mess with that when you can just quickly format the entire volume instead?
Even credentials to the server are not really needed. Because the same actor could boot your server from bootable USB/ISO, mount all your disks in that environment and destroy all data this way, staying completely under radar of any logon monitoring you have set up for the original OS.
I'm not even talking about physical destruction of server/disks that is always possible... so securing physical server access is basically the cornerstone of IT security.
Even credentials to the server are not really needed. Because the same actor could boot your server from bootable USB/ISO, mount all your disks in that environment and destroy all data this way, staying completely under radar of any logon monitoring you have set up for the original OS.
I'm not even talking about physical destruction of server/disks that is always possible... so securing physical server access is basically the cornerstone of IT security.
Who is online
Users browsing this forum: No registered users and 80 guests