Ceci est une ancienne révision du document !
From Thomas Brooks: As part of the hardening determination process, will Lynis offer the option to apply its suggestions? If necessary, will it download the appropriate tools (for example firewall) using APT? MB: Lynis, in its current form, will be mainly focused on auditing a system and providing help to the owner of the system. Automatically hardening is possible, but due to the risks involved, won’t be fully automated. For customers of the Lynis Enterprise version, however, scripts will be provided to assist in hardening, with main focus on configuration management tools like cfengine and Puppet. From Thomas Brooks: Whitelists, even more than Blacklists, seem to be among the most useful tools in keeping a system from connecting up to a compromised server. Does Lynis offer any such support? Do you have any recommendations? MB: Lynis is used for auditing and hardening a system. However, it does not harden the system itself. It is up to the system administrator to pick the right tools and configure them according to the goals of the system. Whitelisting is a generic concept and usually better than blacklisting. The main reason is that you can define upfront what you want to accept, instead of deciding what is possibly bad. Several software packages support some ways of whitelisting, like iptables in which you define what information flows are allowed (and denying all others).
From Jim Barber: How do we detect and remove rootkits? MB: Rootkits are a special case of malware (malicious software), as their main goal is to provide the attacker with a backdoor into the system, and, additionally, make detection as hard as possible. To avoid detection, rootkits will alter binaries, intercept special kernel functions, or just hide in plain sight (e.g. in /bin). So, to detect a rootkit, software needs to be a little bit smarter than the one who tried to hide it in the first place. It must use alternative or static compiled binaries, and different ways to find files (echo * and ls –l), and compare results, etc. In some cases, we get a different result than expected, and that’s usually a first sign to investigate the machine or the discovered binaries. Regarding removing: would you ever trust a system which was compromised? Sure, a file with a virus could be removed or cleaned. But if fatal parts of the system were replaced, or common binaries were backdoored, I would never trust the system from that moment. Best way to remove rootkits is by a fresh install of the machine and building it up properly.
From Jim Barber: Also, I have heard of a trojan horse that is currently in the wild for Linux. How can it be detected and dealt with? MB: Trojan horses and backdoors are common on most platforms. The best way is to avoid them by not using untrusted software (e.g. not using software not in repositories). Malicious binaries can be detected with common malware detection tools like ClamAV, Rootkit Hunter, Chkrootkit, OSSEC, and file integrity tools like AIDE, Samhain and Tripwire. From Wade Smart: [Regarding backdoor control of systems] How can I explain [to Linux users] the reality of what is possible compared to what is probable? MB: The best way to explain to others what is real, is to find real malicious software and try it in a sandbox environment (e.g. a virtual machine without network connections). Surprisingly enough, there are many attacks (and samples) available, yet it takes some time to find or investigate them. Some are even hard to get them working! Backdoor control, in general, is always possible, especially if one achieved root access to the system. Can we trust the whole chain of people who worked on an operating system? Can we trust the compilers which build the binaries we are using? At some stage, we simply have to trust others. For normal Linux users, keeping their systems patched should be the number one priority. People who are still not feeling safe might switch to OpenBSD: less functionality, but more focus on security.