Un article fourni (pour une fois) de ZDNet reprend un ensemble de bonnes pratiques, pour un usage personnel. Les outils proposés vont évoluer dans le temps (de nouveaux non cités vont apparaître, d’autres vont disparaître), mais les bases devraient rester stables, et cet article est donc instructif à ce titre.
Continuer la lectureArchives de catégorie : Bonnes pratiques
La NSA est notre amie
Sans rire. Après avoir passé la majeure partie de son temps à attaquer les autres, la NSA a compris (ou on lui a demandé de comprendre) qu’il fallait aussi savoir se protéger contre les méchants.
Continuer la lectureCloud, sécurisation
Soyons modeste : impossible de traiter le sujet en un article de blog. Néanmoins, quelques petits conseils et sources d’information peuvent s’averer utiles…
Continuer la lectureWordPress
Etant le CMS (Content Management System) le plus répandu, il est fatalement intéressant pour des attaquants. Cela étant, les développeurs ont l’air de faire sérieusement leur boulot, et c’est plutôt du côté des plugins qu’il faut voir les risques.
Continuer la lectureDéveloppement
Plutôt que de réinventer la roue (et mal), voici le guide de la CNIL à destination des développeurs.
Les gestionnaires de mots de passe faillibles ?
Vraiment ? L’actualité court sur tous les sites web (enfin, quelques uns) pour indiquer que les gestionnaires de mots de passe comme KeePass ou 1Password laisseraient des informations critiques en clair.
Continuer la lectureBastion
Le bastionnage (pas sûr que le terme existe) consiste à créer un bastion pour accéder à vos ressources (informatiques). On les utiliser sur des ressources sensibles par leur positionnement (ex : production), par leur nature (ex : outil de gestion de droits), leur contenu, etc.
Ainsi, personne ne peut (en théorie) accéder à vos ressources sans montrer patte blanche et sans passer par ce bastion, qui peut surveiller et mettre en historique les actions effectuées, filtrer les éléments indésirables, gérer des droits d’accès différenciés, etc.
AWS
- Création d’un seul VPC ayant 2 sous-réseaux
- Un premier subnet « privé » routant tout le trafic de son CIDR en local, tout le reste est dirigé vers une Nat Gateway créée dans le subnet suivant (public) ;
- Un second subnet « public » routant tout le trafic de son CIDR en local, tout le reste est dirigé vers une Internet Gateway ;
- Enfin une route supplémentaire, associée à aucun des subnets mais directement au VPC, ne route que le trafic local.
- Création de 3 Security Groups
- Le 1er permet le trafic sortant HTTP/HTTPS (pour permettre le SSH via l’agent SSM), et n’autorise rien en entrée ;
- Le 2e permet le trafic entrant sur HTTPS uniquement et autorise tout en sortie ;
- Le 3e permet tout le trafic en sortie (sans restriction), ainsi que tout le trafic en entrée mais uniquement quand la source est… lui-même (inutile) ?
- Création d’un Endpoint
Sources
- https://aws.amazon.com/fr/blogs/mt/replacing-a-bastion-host-with-amazon-ec2-systems-manager/
- https://docs.aws.amazon.com/quickstart/latest/linux-bastion/architecture.html
- https://www.g2techgroup.com/new-aws-management-tools-blog/
- https://easycloudsupport.zendesk.com/hc/en-us/articles/360001941591-AWS-Security-Bastion-Host-NAT-instances-and-VPC-Peering
Antivirus
Un logiciel antivirus combat les virus. Après ça on est bien avancé, non ? Le nom antivirus est un nom générique donné aux programmes de sécurité, dont le but est de détecter et supprimer les virus (ce qui est un abus de langage pour désigner les programmes malveillants).
La question mérite d’être posée : a-t-on besoin d’un anti-virus ? Sur un serveur web ? Sur un poste client ? Sur un smartphone ?
Continuer la lectureVieux pots
C’est dans les vieux pots1 qu’on fait les meilleures confitures. En 2016, la vulnérabilité la plus utilisée sur Windows date de 20102 ! Pour la petite histoire, à l’époque, il s’agissait d’une faille Windows inconnue du public et des spécialistes, sans correctif, et qui a servi à l’opération contre les centrifugeuses nucléaires iraniennes. Probablement utilisée par des équipes de très haut niveau, ayant des moyens considérables, soit pour découvrir cette faille soit pour l’acheter (puisqu’il existe un marché pour cela).
Ensuite, cette vulnérabilité entre dans un cycle de vie prévisible : elle finit par être connue en juillet 20103, corrigée rapidement par l’éditeur concerné (Microsoft en l’occurrence, puisqu’il s’agit de Windows), en août 20104. La suite ? Il suffit à tous les utilisateurs (particuliers ou entreprises) de mettre à jour leur(s) Windows, et ils sont protégés.
Protégés ?
Oui. A condition d’avoir mis à jour Windows, donc. Et que constate-t-on en 2017 ? Que la faille est encore très utilisée. Donc que de très nombreuses installations de Windows n’ont pas été mises à jour depuis au moins 6 ans ! Et c’est bien tout le problème : une excellente mesure d’hygiène informatique consiste à avoir des composants (système d’exploitation, logiciels importants et/ou souvent utilisés) à jour, pour laisser peu de temps à l’exploitation des failles. Or on voit bien qu’on est très loin de ça…
Pour enfoncer le clou, une étude de Fortinet5 de 2017 ne dit rien d’autre :
[…] dans 90 % des cas, les victimes ont été attaquées par le biais de failles datant de plus de 3 ans et dans 60 % des cas, ces failles étaient vieilles de 10 ans voire plus.
Idem en 2020, on pourrait multiplier les exemples : Palo Alto nous indique que les vulnérabilités les plus fréquemment utilisées ont été identifiées en… 2012 !
Applications web
Il en est de même, mais de façon légèrement différente, dans le monde des applications web. L’OWASP, ainsi que d’autres entreprises de sécurité6, recensent depuis longtemps les types de vulnérabilités les plus utilisées et les plus présentes dans les applications web, et force est de constater que depuis de très nombreuses années, on retrouve immanquablement les mêmes typologies de failles. Les failles XSS et d’injection SQL sont indéboulonnables.
Applications mobiles
Errare humanum est, perseverare diabolicum. L’adage bien connu s’applique toujours, et les développeurs d’applications mobiles ont l’air de répéter les mêmes erreurs que pour les applications web. Personne ne peut écrire de code parfait et exempt de toute faille de sécurité, mais tout le monde doit savoir qu’aujourd’hui il faut protéger son code d’une façon ou d’une autre, en appliquant de bonnes pratiques de codage, de conception ou d’architecture. Et quand on ne sait pas le faire soi-même, on s’appuye sur des frameworks, des outils, des gens qui savent, etc. Et donc, malgré l’expérience des anciens, le code des applications mobiles conservent les mêmes erreurs7 et vulnérabilités, au grand désespoir de tous : les chiffres sont éloquents.
Vu en 2019
Majority of 2019 breaches were the result of unapplied security patches.
HelpNetSecurity
Conclusion
Une seule : faire régulièrement et à fréquence rapide les mises-à-jour de tous vos programmes, surtout le système d’exploitation, les programmes de sécurité (antivirus, pare-feux, etc.). Et faire preuve de discernement quand on reçoit du spam !
Sources
Mise à jour du système
La mise-à-jour du système d’exploitation est, me semble-t-il, une des précautions essentielles à prendre sur toute machine connectée à internet, qu’il s’agisse d’un serveur web ou d’un PC.
Il existe plusieurs écoles sur le sujet. Certains recommandent de mettre-à-jour son système automatiquement (dès la parution des correctifs), d’autres préfèrent choisir manuellement les correctifs à installer. Alors que choisir ?
Quelle stratégie adopter ?
Choisir ses mises-à-jour ?
Cela semble la meilleure solution : le webmaster sélectionne les mises-à-jour pour n’appliquer que celles qui sont indispensables et qui répondent à un problème de sécurité.
Avantages
- Ben on est sûr de ce que l’on fait : on n’introduit pas de mise-à-jour comportant une faille connue ;
- On ne surcharge pas le système : les mises-à-jour sont réduites, et le système est stable car évoluant peu (juste le nécessaire)
Inconvénients
- Le webmaster doit être hyper-vigilant : il doit effectuer une vérification très régulière (quotidienne). Cela prend donc énormément de temps et d’énergie ;
- Il faut connaître ses packages sur le bout des doigts et opérer une veille très active sur les correctifs. Or un système Linux comporte habituellement des centaines de packages qu’il est impossible de maîtriser pour une seule personne.
Installer automatiquement ses mises-à-jour ?
Option inverse : déléguer la mise-à-jour au système en lui demandant périodiquement de se mettre à jour automatiquement (quand c’est possible). A noter que certains packages demandent une validation (pour se conformer aux licences d’utilisation), ceux-ci peuvent ne pas être chargés. Il convient donc malgré tout d’opérer une mise à niveau manuelle régulièrement.
Avantages
- Aucune perte de temps et moins de travail pour l’administrateur ;
Inconvénients
- On ne maîtrise plus rien : on fait confiance aux distributions et à la gestion des packages. On peut donc se retrouver avec des fonctionnalités non souhaitées, des packages inutiles ou moins performants.
Course poursuite
Bien que la mise à niveau manuelle semble plus précise et plus pertinente, il faut garder à l’esprit qu’aujourd’hui la sécurité est avant tout une course poursuite :
- Les pirates cherchent par eux-même des failles, mais leur démarche est également souvent inverse : ils se basent sur les failles connues et publiées pour les utiliser et les exploiter tant qu’elles n’ont pas été corrigées. Or quand elles sont publiques (connues), c’est bien souvent lors de la mise en ligne d’un correctif. Les pirates escomptent donc que les systèmes ne seront pas mis-à-jour immédiatement pour exploiter le plus longtemps possible une faille connue.
- Or peu de pirates ont le temps, les compétences et les moyens de traquer méthodiquement et de découvrir des failles dans les différents logicels et autres packages Linux.
La bonne approche est donc le plus souvent de maintenir son système à jour dès que possible pour l’exposer le moins longtemps aux failles connues. On sait maintenant que ce sont dans les vieux pots qu’on fait les meilleurs confitures, et que les failles même anciennes sont toujours testées et utilisées par les attaquants.
Bien sûr, ce conseil vaut dans le cadre d’une utilisation personnelle, comme mentionné : c’est le meilleur compromis entre la charge qu’on peut accorder à cette tâche et la qualité de protection attendue, pour un usage non-critique.
Fedora, CentOS, Red Hat-like
Avec ces distributions Linux, le plus simple est de passer par le gestionnaire de paquet yum
, qui est installé par défaut sur toutes les distributions récentes.
Pour automatiser, rien de plus simple :
chkconfig yum on
En version longue, pour les utilisateur de sudo :
su -c '/sbin/chkconfig --level 345 yum on; /sbin/service yum start'
Ubuntu, Debian-like
Il existe un package gérant tout cela : unattended-upgrades. Il suffit de l’installer et de le configurer.
$ sudo apt install unattended-upgrades
$ sudo dpkg-reconfigure --priority=low unattended-upgrades
D’autres informations utiles sont ici :
- https://guide.ubuntu-fr.org/server/automatic-updates.html
- https://wiki.debian.org/UnattendedUpgrades
Il convient également de vérifier les deux fichiers de configuration suivants :
/etc/apt/apt.conf.d/50unattended-upgrades
/etc/apt/apt.conf.d/20auto-upgrades
Mise-à-jour du noyau sans reboot
Des solutions (hélas payantes) existent : http://www.ksplice.com/uptrack/install#. Toutefois, Ubuntu semble s’y mettre, mais je ne sais pas encore si cela est réservé aux utilisateurs ayant souscrit une formule de support ou pas.