Leveau Stanislas

Nous avons vu dans notre première partie [0] ce qu’est le social engineering, à savoir une façon d’utiliser l’être humain pour le pousser à faire certaines actions et obtenir de lui quelque chose. Cette méthode se repose sur toutes sortes de techniques (phishing, spearphishing…) plus ingénieuses les unes que les autres et plus ou moins ciblées selon l’objectif voulu. Elle s’appuie dans tous les cas sur des failles humaines comme la curiosité, la cupidité et bien d‘autres qui sont les points clefs de ces arnaques. Nous allons désormais nous intéresser aux victimes, aux conséquences de ce genre de scénario d’attaque sur les entreprises et aux solutions proposées par ces dernières pour sensibiliser leurs utilisateurs. Nous ferons un rappel des différents articles de la loi française qui punissent les fraudes d’ingénierie sociale et nous finirons sur le futur du SE avec notamment des logiciels comme WormGPT, FraudGPT issus du côté obscur de l’Intelligence Artificielle.

Nous avons beau dépenser des centaines de milliers voire de millions d’euros pour sécuriser une infrastructure informatique, des accès à un bâtiment, à la sensibilisation de nos utilisateurs... le maillon faible est et restera l’être humain. Il a beau être ce qu’il est, c’est-à-dire un être inégalable par sa spécificité, mais il reste un être humain avec ses propres failles comme la naïveté, la curiosité, la cupidité... Le facteur humain est le point central des techniques d’attaque rencontrées dans l’ingénierie sociale parce qu’il est l’élément critique dans la chaîne de la cybersécurité. Aucun logiciel n’est capable d’empêcher la manipulation et la tromperie et il n’y a pas de piratage sans conséquence directe ou indirecte.

Vous avez parfois besoin de savoir rapidement la version des noyaux installés sur vos serveurs Linux suite à l'annonce d'une faille de sécurité, de connaître le firmware de vos switchs pour vérifier s’ils sont à jour, ou encore de déployer un correctif… en résumé, avoir un inventaire complet et à jour de votre parc. Le couple GLPI/FusionInventory est là pour ça !

Comment contacter rapidement les responsables d'un site lorsque celui-ci a une coupure internet pour les tenir informés de l'évolution de la situation sachant qu'on ne peut plus utiliser la messagerie pour communiquer?

La supervision est un vaste sujet, avoir une vue d'ensemble de son infrastructure en temps réel, localiser les problèmes, les résoudre, limiter le temps d'indisponibilité des services... tout un programme. Nous avons souvent tendance à utiliser des scripts pour faire des contrôles et nous fournir un code de retour OK WARNING CRITICAL, mais une fâcheuse tendance à oublier les logs, vous savez ces petits fichiers qui fournissent une mine d'informations sur l'état de votre système, tout ce qui transite, les mises à jour, les défaillances, les tentatives d'intrusions... Aujourd'hui, nous allons leur accorder un peu plus d'importance en les centralisant, les analysant et en avertissant notre administrateur systèmes et réseaux en cas de problème.

Tout administrateur systèmes qui se respecte aimerait simplifier au maximum l'installation de ses serveurs, avoir des serveurs homogènes dans son architecture avec les mêmes paquets installés dès le départ. Ne pas avoir à refaire l’installation systématique de différents paquets, de la configuration de Postfix pour l’envoi de mails, de l'installation du client pour les sauvegardes, évite la redondance de nombreuses tâches.

Qui n'a jamais pesté parce qu'il n'avait pas sous la main la bonne version du RPM recherché ou encore parce qu'il se trouvait face à un problème de dépendances. Pour répondre à tous ces problèmes, cet article propose de créer un dépôt local privé. Un dépôt centralisant les RPMS « maison », les RPMS de Dags ainsi qu'un miroir du dépôt officiel RedHat regroupant les isos et les updates. Un dépôt accessible par les différents clients du réseau local via l'outil Yum.