Vous pouvez installer un antivirus si tu veux. Cela ne devrait pas nuire à votre machine, mais n'attendez pas beaucoup de protection pour votre système et ne vous considérez pas comme entièrement en sécurité . L'efficacité des logiciels antivirus est très relative, et ils sont principalement utilisés pour éviter de propager d'anciens logiciels malveillants, en particulier si vous avez des machines Windows dans votre écosystème. Vous devriez vous attendre à une baisse des performances, bien qu'il n'y ait pas de référence de performances AV sous Linux à ce jour, donc cela ne peut pas être quantifié.
Pourquoi n'êtes-vous pas en sécurité avec un simple antivirus ? Parce qu'ils ne sont qu'une partie des mécanismes nécessaires. À l'heure actuelle, il manque de nombreux outils pour la sécurité des postes de travail sous Linux. Quels sont les différents mécanismes de sécurité pertinents pour les postes de travail ?
- Sécurité de la pile graphique (pour empêcher les enregistreurs de frappe, le détournement de clics, l'enregistrement d'écran, le reniflage du presse-papiers, etc.)
- Schémas de distribution d'applications avec des contrôles de sécurité (magasins d'applications et référentiels avec analyse statique sur les applications) et des mises à jour de sécurité rapides
- Détection des logiciels malveillants :basé sur la signature (pour se protéger des menaces identifiées) et basé sur l'heuristique (ou du moins, je n'ai jamais utilisé d'AV basé sur l'heuristique et je soupçonne que c'est principalement un discours marketing pour dire "nous lancerons des tonnes d'avertissements de sécurité face à face lorsque vous utilisez une nouvelle application")
- Sandboxing (qui consiste à isoler les applications les unes des autres par conception)
- Autorisation contextuelle d'utiliser les appareils et les données utilisateur avec sécurité par désignation / contrôle d'accès piloté par l'utilisateur / powerboxes / contrats; nécessite un bac à sable
Actuellement, la seule chose décente sur Linux est les mises à jour de sécurité des applications, via des référentiels. Tout le reste est de qualité inférieure.
Sécurité de la pile graphique
Nous comptons tous sur le serveur graphique X11. X.Org existe depuis 30 ans et la conception originale est toujours utilisée sur le serveur. À l'époque, il n'y avait aucun problème de sécurité sur le bureau et vous ne serez pas surpris d'apprendre qu'il n'est pas du tout sécurisé. Vous avez des API prêtes à l'emploi pour implémenter des enregistreurs de frappe, faire des exploitations de code à distance si l'utilisateur a une console racine ouverte, remplacer le casier de session pour voler des mots de passe, etc, etc.
Il est difficile d'évaluer comment Windows 8 et OS X s'en sortent sur ce sujet car je n'ai trouvé aucune explication détaillée sur l'implémentation de leur pile graphique. Leurs applications en bac à sable ont un accès restreint aux vecteurs d'attaque les plus évidents, mais on ne sait vraiment pas à quel point tout cela est bien conçu et mis en œuvre. Il me semble que Win 8 oblige Store Apps à s'exécuter en plein écran et une à la fois cache les problèmes de conception d'un gestionnaire de fenêtres sécurisé à grande échelle. Il y a beaucoup de problèmes à prendre en considération. position et taille de la fenêtre, utilisation de la transparence et du plein écran, etc. lors de la mise en œuvre d'un gestionnaire de fenêtres dans un souci de sécurité. Je n'ai aucune idée de comment fonctionne OS X.
Linux passera à Wayland dans les années à venir, qui est conçu dans un souci de sécurité. Nous avons un modèle clair des capacités qui devraient exister et une idée générale de la manière dont elles seront appliquées et de la manière dont l'autorisation peut être obtenue. La personne principale derrière ce travail est Martin Peres, bien que je sois impliqué dans la discussion de l'expérience utilisateur et développeur derrière les fonctionnalités. La conception et le développement sont en cours, alors ne vous attendez à rien de si tôt. Lisez cet article pour plus d'informations. Wayland fournira une sécurité transparente lorsqu'il est utilisé conjointement avec le sandboxing de l'application.
Distribution d'applications
Linux dispose d'un système de référentiels avec différents niveaux de confiance, qui ont entraîné nos utilisateurs à ne se fier qu'aux applications fournies et à se méfier du code propriétaire. C'est très bien en théorie.
En pratique, je ne connais pas un seul distributeur qui applique même les contrôles de sécurité les plus élémentaires sur leurs applications packagées . Aucune analyse statique pour les appels système étranges, et pour toute communauté, il n'est vraiment pas clair si les scripts de pré- et post-installation (qui s'exécutent en tant que root) sont vérifiés pour les mauvaises choses évidentes.
Les vérifications de sécurité effectuées sur les extensions de GNOME Shell sont très légères et manuelles, mais existent au moins. Je ne connais pas les extensions de KDE ou d'autres applications.
Un domaine dans lequel nous brillons est que nous pouvons extraire des mises à jour de sécurité très rapidement, généralement en quelques jours pour toute faille de sécurité. Jusqu'à récemment, Microsoft était beaucoup plus lent que cela, bien qu'il ait rattrapé son retard.
Détection de logiciels malveillants
Le seul logiciel antivirus que je connaisse sous Linux est ClamAV. Il me semble que cela ne fonctionne que sur la base des signatures, mais là encore, comme vous l'avez souligné, nous n'avons aucun malware de bureau identifié contre lequel nous protéger.
Il y a probablement des personnes qui écrivent des logiciels malveillants pour les postes de travail Linux dans le monde des menaces persistantes avancées. Voir Masque pour un exemple. Il est peu probable que l'antivirus standard puisse faire quoi que ce soit contre ceux-ci, car les auteurs de logiciels malveillants APT sont généralement assez talentueux pour proposer des exploits zero-day.
Désormais, Microsoft annonce des tests fuzz de tous ses logiciels pendant des dizaines de milliers d'heures, contrairement à pratiquement aucune pratique de codage sécurisé dans l'écosystème Linux. À partir d'expériences personnelles avec le fuzzing, je suis absolument convaincu qu'il existe une poignée d'exploits zero-day à portée de main dans certains logiciels Linux populaires . Cela viendra nous frapper le jour où nous aurons une base d'utilisateurs financièrement viable pour les auteurs de logiciels malveillants courants, et nous verrons ensuite à quel point ClamAV s'avèrera bon, mais je soupçonne que le mécanisme de mise à jour de l'application aura un impact plus important sur le traitement avec des vulnérabilités découvertes.
Inutile de dire que Windows et OS X font nettement mieux que Linux sur ce critère.
Sandboxing et autorisation contextuelle
OS X et Windows 8 fournissent tous deux un sandboxing pour les applications hébergées sur leur magasin. Je n'ai pas fini d'examiner les bizarreries d'OS X, mais les applications Windows 8 Store ont de très sérieuses limitations en termes de langues et d'API prises en charge, de fonctionnalités disponibles et d'expérience utilisateur générale qui peuvent être fournies avec elles. Cela signifie que les applications de bureau sans bac à sable sont là pour rester et que le bac à sable de Microsoft ne le sera pas protéger contre les logiciels malveillants, uniquement contre les documents fabriqués dans un logiciel bogué (Store App). OS X semble faire beaucoup mieux bien que toute application non-store ne soit pas non plus en bac à sable.
Linux n'a pas de sandbox d'application graphique fonctionnant de manière suffisamment transparente pour le moment. Nous avons la technologie de confinement sous-jacente (les meilleurs candidats étant les conteneurs basés sur les espaces de noms Linux, voir LXC et Docker, et les meilleurs étant les systèmes d'application MAC qui devraient être développés pour prendre en charge une certaine dynamique). Nous avons presque les mécanismes IPC et de gestion des processus nécessaires pour déployer et gérer ces applications en bac à sable grâce à un travail incroyable sur kdbus et systemd. Il manque quelques éléments, avec quelques propositions poussées principalement par la Fondation GNOME (voir cette vidéo sur Sandboxing à GUADEC 13). Je suis également impliqué dans la discussion sur la manière dont l'accès aux données et l'autorisation peuvent se produire, mais il n'y a pas de consensus entre les quelques personnes intéressées, et la conception et le développement prennent du temps. Il faudra probablement encore quelques années avant que des prototypes décents n'existent et avant que le sandboxing ne soit déployé sur Linux à une échelle pertinente.
L'un des grands problèmes rencontrés sur toutes les plates-formes est de savoir comment autoriser les applications à accéder aux données et aux capacités des appareils à la bonne échelle. Cela signifie, comment les laisser faire ce qu'ils doivent faire sans harceler les utilisateurs avec des invites d'autorisation tout en empêchant les applications d'abuser des privilèges. Il existe de sérieuses failles dans la façon dont Windows 8 permet aux applications Store de gérer les documents récents et la futureAccessList des applications. À ce stade, sécuriser davantage l'accès aux documents sans aggraver le coût de la sécurité pour les développeurs et les utilisateurs est une question ouverte, sur laquelle un groupe de personnes travaille également :)
Les logiciels malveillants ne se soucient pas que vous exécutiez un "bureau Ubuntu à installation standard uniquement". Les logiciels malveillants fonctionneront tant que le système prend en charge le jeu d'instructions correct pour lequel le binaire ELF a été compilé. Ubuntu est basé sur Debian et prend en charge les jeux d'instructions suivants :IA-32, x86-64, ARMv7, ARM64, PowerPC. En général, la plupart sont construits sur des systèmes IA-32 ou x86-64.
Comme mon travail consiste à inverser les logiciels malveillants, il m'arrive parfois de devoir les déboguer. J'ai donc des machines virtuelles Ubuntu Desktop (32 et 64 bits) que j'utilise pour effectuer quotidiennement le débogage à distance des logiciels malveillants Linux via IDA.
Si vous voulez parler de la méthode d'infection, alors bien sûr, vous êtes moins susceptible d'avoir un drive-by sous Linux que sous Windows. Cependant, j'ai remarqué au cours des derniers mois en jouant avec certains des scripts PHP drive-by qu'ils prennent en charge de plus en plus de plates-formes non Windows. Vérifiez simplement la plate-forme annoncée par le navigateur et diffusez l'exploit correspondant.
TL;DR- J'infecte quotidiennement les installations de bureau (VM) d'Ubuntu tout en inversant les logiciels malveillants Linux.
La question est posée pour Ubuntu.Si je peux élargir la question aux éditions de bureau Linux, tapez SELinux "Walled Garden " serait très utile. Dans SELinux, les politiques de contrôle d'accès obligatoires (MAC) peuvent arrêter ou limiter les dommages lors d'une tentative d'infection. les étiquettes sont stockées dans des inodes.
Avantages :
Vous pouvez implémenter des politiques de sécurité très compliquées. (C'est-à-dire que le navigateur Web ne peut pas accéder à un dossier autre que ~/.mozilla)
Inconvénients :
Cependant, dans SELinux, vous aurez besoin d'une bonne politique de sécurité. L'inconvénient est que la modification de ces règles est compliquée.
Comme je sais qu'Ubuntu ne prend pas en charge SELinux par défaut. Mais les systèmes d'exploitation comme Fedora le font.
Conclusion :
En fin de compte, Linux dispose en effet de bons mécanismes de sécurité (File Permission, SELinux ) qui rendent la vie des malwares très difficile à moins que vous ne les ayez gâchés.