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).
De Thomas Brooks : Dans le cadre du processus de détermination du renforcement de la sécurité, est-ce que Lynis offrira la possibilité d'appliquer ses suggestions ? Et si besoin est, téléchargera-t-il les outils appropriés (par exemple un pare-feu) en utilisant APT ? MB : Lynis, dans sa forme actuelle, sera principalement dédié à vérifier les systèmes et à fournir de l'aide aux propriétaires. Renforcer automatiquement est possible, mais en raison des risques encourus, tout ne sera pas entièrement automatisé. Pour les clients de la version Lynis Entreprise, cependant, des scripts seront fournis pour aider au renforcement, en se focalisant principalement sur les outils de gestion de configuration comme cfengine et Puppet.
De Thomas Brooks : Les listes blanches, plus encore que les listes noires, semblent être parmi les outils les plus utiles pour empêcher un système de se connecter à un serveur compromis. Lynis offrira-t-il une telle fonctionnalité ? Avez-vous des recommandations ? MB : Lynis est utilisé pour la vérification et le renforcement d'un système. Cependant, il ne renforce pas lui-même le système. C'est à l'administrateur système de choisir les bons outils et les configurer en fonction des objectifs du système. Utiliser des listes blanches est un concept générique et généralement meilleur qu'utiliser des listes noires. La raison principale en est que vous pouvez définir d'avance ce que vous voulez accepter, au lieu de décider ce qui est peut-être mauvais. Plusieurs logiciels permettent de faire une quelconque liste blanche, comme iptables dans lequel vous définissez quels flux d'information sont autorisés (et rejetez tous les autres).
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.
De Jim Barber : Comment détecter et supprimer les rootkits ? MB : Les rootkits sont un cas particulier de malware (logiciel malveillant), car leur principal objectif est de fournir à l'attaquant une porte dérobée dans le système et, de plus, de rendre leur détection la plus difficile possible. Pour éviter la détection, les rootkits vont modifier des fichiers binaires, intercepter des fonctions spéciales du noyau, ou tout simplement se cacher au nez et à la barbe de tous (par exemple dans /bin). Ainsi, pour détecter un rootkit, le logiciel doit être un peu plus intelligent que celui qui a essayé de le cacher en premier lieu. Il doit utiliser des compilations alternatives ou statiques de fichiers binaires et différentes façons de trouver les fichiers (echo * et ls -l), et comparer les résultats, etc. Dans certains cas, nous obtenons un résultat différent de celui attendu et ceci signale généralement qu'il faudrait vérifier la machine ou les binaires découverts. En ce qui concerne la suppression : feriez-vous jamais confiance à un système qui a été compromis ? Bien sûr, un fichier avec un virus pourrait être retiré ou nettoyé. Mais si des parties vitales du système ont été remplacées, ou des binaires ordinaires ont été piégés par une porte dérobée, je ne ferai plus jamais confiance au système. La meilleure façon de supprimer les rootkits est de faire une nouvelle installation de la machine et une reconstruction correcte.
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.
De Jim Barber : J'ai aussi entendu parler d'un cheval de Troie pour Linux qui se trouve actuellement dans la nature. Comment peut-il être détecté et géré ? MB : Les chevaux de Troie et les portes dérobées sont communs sur la plupart des plates-formes. La meilleure politique est de les éviter en n'utilisant pas de logiciel non approuvé (par exemple, ne pas utiliser un logiciel qui n'est pas dans les dépôts). Les binaires malveillants peuvent être détectés avec des outils communs de détection de logiciels malveillants comme ClamAV, Rootkit Hunter, Chkrootkit, OSSEC et des outils de test de l'intégrité des fichiers tels que AIDE, Samhain et Tripwire.
De Wade Smart : [En ce qui concerne le contrôle de systèmes par porte dérobée.] Comment puis-je expliquer [aux utilisateurs de Linux] la réalité de ce qui est possible par rapport à ce qui est probable ? MB : La meilleure façon d'expliquer aux autres ce qui est réel est de trouver de vrais logiciels malveillants et les essayer dans un bac à sable (par exemple une machine virtuelle sans connexion réseau). Curieusement, il existe de nombreuses attaques (et des exemples) disponibles, mais il faut un certain temps pour les trouver ou enquêter sur eux. Il est même difficile d'en faire fonctionner certains d'entre eux ! Le contrôle par porte dérobée, en général, est toujours possible, surtout si l'on a obtenu un accès root au système. Peut-on faire confiance à l'ensemble de la chaîne des personnes qui ont travaillé sur un système d'exploitation ? Peut-on faire confiance aux compilateurs qui construisent les binaires que nous utilisons ? À un certain moment, nous devons tout simplement faire confiance aux autres. Pour les utilisateurs normaux de Linux, garder leurs systèmes à jour devrait être la priorité numéro un. Les personnes qui ne se sentent toujours pas en sécurité pourrait passer à OpenBSD : il y a moins de fonctionnalités, mais c'est davantage préoccupé par la sécurité.