CERTA
|
CERTA Centre d'Expertise Gouvernemental de |
 |
|
Affaire suivie par : CERTA Objet : Bulletin d'actualité
N^2005-08
Gestion du document
Une gestion de version détaillée se trouve à la fin de ce document. 1 Activité en coursLe tableau 3 montre les rejets pour les ports sous surveillance que nous avons constatés sur deux dispositifs de filtrage, entre le 10 et le 17 février 2005. 2 Le « Google Hacking »Les moteurs de recherche indexent des pages Internet, mises à disposition par l'intermédiaire de serveurs web, en vue d'une recherche ultérieure par des utilisateurs à l'aide d'un navigateur Internet et de certains mots clefs. Ces moteurs de recherche sont de plus en plus précis et exhaustifs. Les techniques d'indexation de pages Internet comprennent entre autre le parcours exhaustif des sites Internet en suivant les différents liens se trouvant dans le code source des pages renvoyées par le serveur web. Google est actuellement le moteur de recherche reconnu comme le plus efficace et le plus populaire. A ce jour, si l'on s'en tient à ce qui est mentionné sur la page d'accueil du moteur de recherche Google, plus de 8 milliards de pages Internet sont indexées. Depuis plusieurs mois, nous assistons à un détournement de certaines des fonctionnalités des moteurs de recherche à des fins malveillantes. Il est en effet possible, via des requêtes judicieusement construites, d'accéder rapidement à des contenus sensibles ou à des applications vulnérables (webcam en accès non protégé, documents confidentiels, failles de sécurité connues d'un applicatif ...). Les moteurs de recherche sont ainsi utilisés afin de rechercher des informations sur des serveurs vulnérables. Des outils graphiques automatiques, couplés à des bases de connaissance mises à jour quotidiennement, sont également disponibles sur l'Internet. Ceci permet à un utilisateur mal intentionné, à l'aide d'un simple outil ou d'un simple navigateur, d'accéder à des informations sensibles, potentiellement exploitables en vue d'une attaque informatique. Depuis peu, Google semble avoir réagi contre ce phénomène en masquant certains résultats relatives à certaines requêtes ou en affichant une page d'erreur ("We are sorry...but we can't process your request right now."). Comme toujours dans le monde de la sécurité, il s'agit du jeu du chat et de la souris. A toute parade, une contre-parade. Et ainsi de suite. Le phénomène va donc probablement se poursuivre, indépendamment de la volonté des moteurs de recherche (Google en première ligne) d'endiguer le phénomène. Ces techniques de recherche ne laissent aucune trace dans les journaux des applications vulnérables dans la mesure où seul le cache des moteurs de recherche est interrogé. En revanche, l'exploitation d'une vulnérabilité ainsi identifiée va laisser des traces dans les journaux des serveurs concernés. Il est, comme toujours, très important d'analyser périodiquement ces journaux afin de détecter les attaques sur son système d'information. Il est en outre important de noter que dans la plupart des cas, les flux sont en direction des serveurs web. Dans ce cas, le pare-feu n'est donc généralement que de peu d'utilité dans la mesure où le flux autorisé (dans la mesure où l'on dispose d'un serveur web) est assimilé à une requête standard (même si malveillante a priori). Ainsi, il est important de configurer correctement ses serveurs web afin de ne mettre à disposition uniquement l'information voulue et de n'activer uniquement les services désirés. Ensuite, il est important de mettre à jour tout son système d'information au rythme des découvertes et des publications des vulnérabilités ; ceci de manière d'autant plus rapide que le système est accessible par tout le monde depuis l'Internet. Il est enfin important de surveiller les informations concernant son système d'information disponibles par le biais des moteurs de recherche, Google en particulier. 3 Rappel des avis et des mises à jour émisDurant la période du 07 au 11 février 2005, le CERTA a émis l'avis suivant :
Pendant cette même période, les mises à jour suivantes ont été publiées :
4 Actions suggérées4.1 Respecter la politique de sécuritéQuoique puisse suggérer ce document, la politique de sécurité en vigueur dans votre service doit primer. Cette section précise néanmoins quelques mesures générales de nature à vous prémunir contre les agressions décrites dans ce document. 4.2 Concevoir une architecture robusteA la lumière des enseignements tirés de ce qui
a été présenté dans les bulletins
d'actualité, il convient de vérifier que les
applications mises en 4.3 Appliquer les correctifs de sécuritéLe tableau 2 rappelle les avis du CERTA correspondant aux applications ou codes malveillants relatifs aux ports étudiés dans les sections précédentes. 4.4 Utiliser un pare-feuL'application des correctifs sur un parc informatique important n'est probablement pas immédiat. Un pare-feu correctement configuré peut retenir certaines attaques informatiques le temps d'appliquer les correctifs. Cependant un pare-feu peut donner une illusion de protection. Cette protection est brisée par la moindre introduction d'un ordinateur nomade dans la partie protégée. On remarque qu'il y a de nombreux paquets rejetés à destination de ports légitimement utilisés par des applications de prise de main à distance. La téléadministration correspond à une demande qui grandit avec la taille du parc à gérer. Les paquets rejetés montrent le risque associé à ce type d'application. Ce risque peut être amoindri par l'usage correct d'un pare-feu. 4.5 Analyser le réseauDe nombreux paquets rejetés étudiés correspondent aux ports ouverts par divers virus/vers/chevaux de Troie. Si votre politique de sécurité autorise le balayage des ports ouverts sur les postes de travail ou les serveurs, il peut s'avérer utile de le faire régulièrement afin de découvrir les machines potentiellement contaminées avant qu'un intrus ne le fasse à votre place. 4.6 Réagir aux incidents de sécuritéOrganisez-vous pour réagir aux incidents de sécurité, en particulier, pour assurer une certaine continuité dans les équipes d'administration et de sécurité. Le CERTA a pour mission de vous aider à répondre aux incidents de sécurité informatique. Ne traitez pas les dysfonctionnements des machines à la légère. Dans certains incidents dans lesquels le CERTA intervient, les administrateurs des machines font spontanément part de petits dysfonctionnements inexpliqués et d'apparence anodine qui s'avèrent, au cours de l'analyse, être liés à un incident majeur de sécurité. N'hésitez pas à prendre contact avec le CERTA si vous constatez de l'activité sur les ports décrits ci-dessus.
,D,,2 /D//2
Liste des tableaux
Gestion détaillée du document
CERTA 2012-01-04 |
|
||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
)
uvre (ou à
l'étude) ont une architecture qui résiste aux
incidents décrits.