Source : Wikipedia |
Il faudrait parler de Livre Blanc...Il le faudrait vraiment mais l'humeur du moment est décidément technique, au moins en ce qui me concerne. C'est donc de cela que je vais vous parler puisque lors j'ai eu téléchargé le "pdf" du LBDSN, la première chose que j'ai faite, c'est de transformer le pdf en texte (pdftotext) puis de "faire un grep" sur le motif "cyber" et de le compter...J'ai trouvé 37 occurrences du terme, souvent associés avec d'autres suffixes comme "défense", "attaque" ou encore "espace". A titre de comparaison, "nucléaire" est présent 69 fois et NRBC 6 fois...
Toutefois, l'humeur du jour me pousse plutôt à vous évoquer le quotidien des attaques "ordinaires" et les problèmes qui se posent aux administrateurs et responsables sécurité. Sans forfanterie j'espère, mon cas personnel me semble fournir matière à réflexion. En effet, je suis client et titulaire d'un serveur disponible sur Internet et suis régulièrement confronté à des questions de sécurité...
L'utilité de ce serveur est essentiellement de procurer des services réseaux, notamment des tunnels, que je peux facilement utiliser à partir d'une connexion non connue et donc potentiellement dangereuse. Entre autres...Pour compliquer l'affaire, il s'agit d'un serveur virtualisé qu'une petite société loue en louant elle-même des serveurs physiques à une seconde, et plus grande, entreprise.
Considérant mes intérêts, je me suis intéressé à la sécurité du serveur...Bien que j'ai oublié de le préciser, le serveur fonctionne sous Linux Debian et la lecture du manuel est très utile. Parmi plusieurs réglages, l'exposition du serveur a été limité par l'usage d'un firewall, les protocoles d'administration à distance ont été limités. J'ai également mis en oeuvre quelques outils afin d'obtenir une meilleure visibilité sur le danger qu'un serveur court sur Internet...et puis pour s'amuser avec les logs.
Ainsi, un outil automatique d'exclusion a été installé ainsi qu'un système de détection d'intrusion ou encore un antivirus....Puis j'ai installé mes outils réseaux avant de laisser vivre un peu le serveur. Régulièrement, je m'y connecte pour le mettre à jour et surtout m'intéresser aux logs...
On en retire plusieurs leçons...
D'une part, sur un serveur lambda présentant des caractéristiques génériques - comme l'usage d'un port d'administration classique - le taux de scan est véritablement affolant. Je m'intéresse ainsi aux tentatives de connexions ratées puis réussies ou encore aux informations remontées par les outils de détection ou de prévention d'intrusion. Par exemple, sur 5 jours, il est possible de constater plus de 2000 tentatives échouées de connexion...
Les adresses IP ayant émises ces connexions sont d'ailleurs au final peu nombreuses et sont identifiées comme appartenant à des entités russes ou chinoises (sic...). Si l'on s'amuse un peu, on remarque ensuite que les tentatives de connexion se font par paquets d'environ une petite centaine de tentatives à chaque heure de la journée. Cela fait songer au comportement automatisé d'un outil quelconque.
Toutefois, la recherche de ces informations n'est pas nécessairement intéressantes mais elle permet parfois de se rendre compte de certaines limites : par exemple, le comportement d'une des adresses est tel que une ou deux minutes se passent entre plusieurs tentatives. Cela déjoue donc mon système et c'est pourquoi le système d'exclusion n'est pas efficace en l'état.
D'autre part, la lecture et l'analyse de ces logs n'est pas évidente. Pour être franc et puisque ce n'est pas une action que je réalise chaque jour - la plupart du temps, les vérifications sont moins poussées - il serait difficile de tout détecter. Rappelez-vous qu'un fichier log est une succession de lignes contenant des informations "techniques" : il faut donc l'analyser intelligemment pour en tirer quelque chose !
De plus, dans mon cas, la quantité de logs est raisonnable et ce que je recherche est relativement simple. Imaginez alors des équipements concernant une organisation de taille importante (et son trafic quotidien) et l'importance des journaux d'évènements ! Il est alors nécessaire de disposer d'outils efficaces et d'une équipe aguerrie et bien formée surtout si l'on cherche à comprendre les ressorts d'une attaque.
Cette chronique d'une attaque ordinaire permet donc de comprendre que non seulement l'Internet est un milieu agressif mais que le paisible internaute ne le voit guère. D'autre part, il est facile de ne pas détecter l'attaque et de passer à côté de l'élément intéressant !
Ceci nous amène à conclure qu'en matière de lutte informatique, la "matière grise" est aussi importante que les bons outils et que les problématiques sont complexes...Au final, nous ne sommes pas si loin du Livre Blanc...
Source : dans le texte
Aucun commentaire:
Enregistrer un commentaire