First, as @ddench47 describes,
openSUSE has never had a reputation hardened to paranoid levels, if you want to start with a system that is advertised as “secure by default” you’d want to install something like Arch.
openSUSE instead is the product of many years of development balancing security and usability… In other words, on a newly installed openSUSE you should have a system you can work with right away and when applications are installed more often than not your application can be used right away and you shouldn’t run into unexpected problems that require difficult modification.
This does not mean that openSUSE is insecure, far from it.
Only means that
- If you are running very sensitive applications, you will likely want to multiply the safeguards to protect your system and data.
- If you need to comply with a security specification, you will likely have work to do.
The other thing to know is that security in general is a complex evaluation and never a simple, binary answer.
For instance, a network application may be configured to support unnecessary functions but those extra functions might be accessible only with a special firewall configuration, and a firewall is always installed by default on every openSUSE and likely blocks access to the optional port. This means that the security scan warning about this example app would not constitute an actual vulnerability, but might be considered a latent issue that might be exposed if the firewall is mis-configured.
Following is a quick IMO of some of the 26 Lynis “suggestions” in your scan…
Disabling core dumps is a good idea for paranoids but means that if your system crashes, you might not be able to troubleshoot. But on the other hand, an ordinary User probably will never be able to read a core dump if it ever actually happens. Disabling should still allow the system to record the reason for a core dump in the system logs.
Default password hashing should be adequate for nearly everyone. Modify if you’re paranoid.
Default Password policy is nearly non-existent by default on openSUSE, you can modify in YaST Users and Security module easily.
Disabling USB is important if you want to prevent the most likely way someone will hack your system if you walk away from it and anyone else has physical access while you’re gone. AFAIK Linux is not subject to the same USB vulnerabilities of a MSWindows system It can be extremely inconvenient if you use your USB and disable it.
The suggestion about splitting resolving localhost and your system’s hostname is interesting… I’m pretty sure openSUSE does that by default. But, by default openSUSE resolves both ways due to an entry in the /etc/hosts file. So, I’m not sure what this test is actually doing. I’m pretty sure if this bothers someone, modifying /etc/hosts should resolve.
The various TCP/IP Congestion Control protocols can be left alone. I don’t know why the scanner marked them for recommended removal, AFAIK leaving them alone is not a security risk. Seeing these suggestions, I doublechecked what is actually actively set by default on an openSUSE (and I suspect nearly all Linux distros) and it’s the same as has been for decades… cubic. If anyone wants to know what this is, I can repost an article I wrote about this a long time ago… which can be a performance enhancer if your machine isn’t tiny, resource constrained and using only a wired ethernet network connection(hint - Unless you install on 15 year or older hardware, you can get an easy network performance boost).
Storing your logs on a remote system is always a good idea when appropriate, but how many users are logging into an Enterprise network? From the other results in your security scan, this machine certainly isn’t.
Interesting that your scan says to check use of deleted files. That shouldn’t normally be happening under any circumstance, I don’t know if the suggestion is because it located temporary files in use or actually discovered temporary file(s) with locks that might be suspicious. So, I can’t say whether this is simply a precautionary suggestion or something that’s actually not functioning properly.
Adding a legal banner to /etc/issue is probably a good idea should the file be improperly accessed, but I wonder again how this scanner determines if the suggested banner exists or not.
Turning on process accounting and sysstat may be a requirement or suggestion for high security compliance or practice… But this kind of functionality can put a heavy load on a system and would be undesirable for most Users because it could mean high system latencies.
Installing a file integrity tool is typically a good idea if you suspect or want to know if someone/something alters your system files, but IMO this is something most Users won’t understand how to use and don’t usually pay that much attention to what’s happening (eg be able to match file change timestamps to system maintenance). If you’re not going to invest that much effort in this, better not to implement or you could find yourself chasing false alarms or not notice when a problem actually happens.
If you want to harden file permissions, I’d suggest learning AppArmor which is what openSUSE implements to apply security by policy. The alternative is SElinux. There is documentation for both in the openSUSE documentation. I don’t recommend monkeying around with permissions ad hoc.
You’ll notice that the results also note that your results are incomplete because you ran the scan in unprivileged (normal User) mode. If you trust that the software won’t harm your system, you should actually run it with elevated permissions (don’t know if it’ll work using sudo, you may need to su).
HTH,
TSU