- Messages
- 6,401
In Windows, you have no control over the encryption/decryption components so you have to rely on other methods to stop ransomware. With Linux though, this is far easier. Before we get into this simple mitigation though, do not forget the best defense for ransomware by far: BACKUPS. MAKE FUCKING BACKUPS, PEOPLE. They're good for many other things besides restoring from ransomware attacks anyway. But yes, let's move on.
On Linux, most commands are stored in /usr/bin. If we want to encrypt an individual file or files, we would use one of two probably already installed command executables. They are
When you do this, gpg and openssl will now require sudo/root permissions to be run in any capacity. This also doesn't harm Veracrypt either as Veracrypt uses its own encryption solutions, starts in a window, and should require admin privileges to open any encrypted container anyway. Now, this won't prevent any ransomware that has all its encryption software built directly into itself, so this is not a 100% foolproof way to stop it. Nevertheless though, it should stop most common attacks.
There's another method as well that will work much better but will also be much more of a pain in the ass for normal everyday use. Using the
EDIT: You can also do
EDIT2: Disabling gpg from allowing others to execute it will cause the flatpak system to not work properly. Just reinstate permissions when you need to obtain, change, or update flatpaks. Also keep in mind, if you have a GPU driver update with your Linux kernel update (likely), you will probably have to update your flatpaks as well since they're set to work with your older GPU drivers. Not doing so after said kernel update will cause your flatpak apps to completely crash on launch with a GLX error.
On Linux, most commands are stored in /usr/bin. If we want to encrypt an individual file or files, we would use one of two probably already installed command executables. They are
gpg and openssl. For this mitigation technique, just open your file browser and make sure that you run it as root. Then right click gpg/openssl and go to the file properties and then the permissions page. Specifically, we want to deny execute or 'e' permissions to "Others". Deny the execute permission for Others with both commands.When you do this, gpg and openssl will now require sudo/root permissions to be run in any capacity. This also doesn't harm Veracrypt either as Veracrypt uses its own encryption solutions, starts in a window, and should require admin privileges to open any encrypted container anyway. Now, this won't prevent any ransomware that has all its encryption software built directly into itself, so this is not a 100% foolproof way to stop it. Nevertheless though, it should stop most common attacks.
There's another method as well that will work much better but will also be much more of a pain in the ass for normal everyday use. Using the
sudo chattr +i -RV /<directory>/ command, you can make any directory and all its contents immutable. This way, if someone doesn't have root or sudo permissions, the directory is utterly untouchable. The problem with this method though is rather obvious. The directory is untouchable and cannot be modified or added to by legitimate users conveniently, requiring a sudo chattr -i -RV /<directory>/ command to undo the immutable attribute. And then you have to set the attribute again when you're done with any changes you wish to make. I wouldn't recommend this method unless there's a directory you know just doesn't get touched a lot but is still valuable.EDIT: You can also do
sudo find . -maxdepth 2 -type f -exec chattr -RV +i {} \; and this would set the immutable attribute on all files but NOT directories up to a certain depth specified by -maxdepth, which, in this case, is a depth of 2. Alternatively, if you want it done to all files it finds recursively regardless of depth, you can just get rid of -maxdepth entirely and enter sudo find . -type f -exec chattr -RV +i {} \;. I suppose the -R argument to chattr might be redundant here as find is now doing the seeking, but whatever. The command works.EDIT2: Disabling gpg from allowing others to execute it will cause the flatpak system to not work properly. Just reinstate permissions when you need to obtain, change, or update flatpaks. Also keep in mind, if you have a GPU driver update with your Linux kernel update (likely), you will probably have to update your flatpaks as well since they're set to work with your older GPU drivers. Not doing so after said kernel update will cause your flatpak apps to completely crash on launch with a GLX error.
Last edited:
