Contactez-nous
Identifier les faiblesses du système
Attaques des systèmes - Prendre le contrôle du bastion
H5833 v1 Article de référence

Identifier les faiblesses du système
Attaques des systèmes - Prendre le contrôle du bastion

Auteur(s) : Laurent LEVIER

Relu et validé le 17 févr. 2020 | Read in English

Logo Techniques de l'Ingenieur Cet article est réservé aux abonnés
Pour explorer cet article plus en profondeur Consulter l'extrait gratuit

Déjà abonné ?

Sommaire

Présentation

RÉSUMÉ

Nuire aux réseaux informatiques et aux plateformes qu’ils hébergent est tout à fait possible pour une personne mal intentionnée, en s’en prenant par exemple à ses fonctions de routage ou en usurpant les adresses IP. Cet article présente les moyens d’identifier les faiblesses du système, qu’elles soient d’architecture, d’authentification, de configuration ou de programmation. Sont ensuite détaillés les outils disponibles à ce jour permettant de concevoir des attaques de machines, la vulgarisation des techniques facilite malheureusement leur utilisation par des pirates même inexpérimentés.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

Auteur(s)

  • Laurent LEVIER : Certified Information Systems Security Professional (CISSP) - Certified Information Security Manager (CISM) - Officier de sécurité du réseau interne, Equant Télécommunications

INTRODUCTION

Nous avons vu dans les dossiers Attaques des réseaux et Attaques des systèmes- Identifier les faiblesses du bastion qu’il est possible pour une personne mal intentionnée d’établir la cartographie d’un réseau, même si celui-ci est protégé par des équipements de sécurité, mais également, tout en restant à distance, de nuire à ce réseau en altérant par exemple ses fonctions de routage, en trompant certains des équipements qu’il héberge par l’usurpation d’adresses IP et maintes autres techniques.

Nous avons également découvert que les machines placées sur des réseaux distants pouvaient être elles-mêmes la proie du pirate, soit pour accéder aux informations qu’elles contiennent, soit pour les utiliser comme plate-forme de « rebond » afin d’être mieux placé pour atteindre d’autres équipements, comme le pare-feu Pare-feu depuis le réseau qu’il protège, ou un système secondaire dans une architecture trois tiers par exemple.

Jusqu’à présent, le pirate n’a travaillé qu’au niveau 3 du modèle OSI du protocole TCP/IP. S’il a découvert l’existence de services réseaux en écoute, il n’a toujours pas la certitude de pouvoir utiliser tel ou tel port pour réaliser son attaque. Il lui manque encore une information : quel est le point faible le plus intéressant ?

Nous allons aborder ici le concept de faiblesse, et les conséquences qu’elle induit pour un pirate, et inversement pour la victime. Bien sûr, l’évaluation de la présence d’une faiblesse particulière exige que nous considérions non plus seulement la couche réseau, mais aussi les couches supérieures qui offrent plus de possibilités.

Logo Techniques de l'Ingenieur

Cet article est réservé aux abonnés.
Il vous reste 93 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ?


DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-h5833

Lecture en cours
Présentation

Article inclus dans l'offre

"Sécurité des systèmes d'information"

(80 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

1. Identifier les faiblesses du système

Le pirate travaille donc maintenant au niveau de la couche application pour trouver les faiblesses de chaque service réseau accessible par lui. En effet, dans la plupart des cas, un pirate réussit à pénétrer un système uniquement à cause de faiblesses qui pourraient être facilement évitées ou corrigées, pour peu que l’administrateur du système et le constructeur des logiciels qu’il utilise y prêtent attention.

Les faiblesses sont classées en quatre grands groupes. Certains de ces groupes – les faiblesses d’authentification 1.2 et de configuration 1.3 par exemple – sont sous la responsabilité de l’administrateur de la machine et de la politique de sécurité de l’entreprise. En revanche, d’autres, telles que les faiblesses d’architecture 1.1 ou de programmation 1.4, relèvent de la responsabilité du constructeur du logiciel ou du matériel.

1.1 Faiblesses d’architecture : design

Certains services réseaux ont été définis dès les premiers RFC, après la définition du protocole TCP/IP lui-même. À cette époque, le pirate ne sévissait que sur les réseaux téléphoniques (phreaking) sur lequel on trouvait entre autres les BBS (Bulletin Board System), précurseurs des premiers forums informatiques d’échange.

À cause de ce risque très faible et peut-être également parce que le monde universitaire, d’où provenaient un nombre élevé de contributeurs des RFC, était encore pour ainsi dire vierge de ces comportements indélicats, nombre de services réseaux n’ont pas été conçus pour demander de l’authentification, même simple. De plus, la puissance des calculateurs était également peu performante, aussi le chiffrement était-il une notion purement militaire,...

Logo Techniques de l'Ingenieur

Cet article est réservé aux abonnés.
Il vous reste 94 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ?


Lecture en cours
Identifier les faiblesses du système

Article inclus dans l'offre

"Sécurité des systèmes d'information"

(80 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - PLUMMER (D.C.) -   Ethernet Address Resolution Protocol : Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware  -  . RFC 826, IETF, nov. 1982.

  • (2) -   Internet Protocol  -  . RFC 791, IETF, sept. 1981.

  • (3) -   Transmission Control Protocol  -  . RFC 793, IETF, sept. 1981.

  • (4) - BRADEN (R.) -   Requirements for Internet Hosts – Communication Layers  -  . RFC 1122, IETF, oct. 1989.

  • (5) - BRADLEY (T.), BROWN (C.) -   Inverse Address Resolution Protocol  -  . RFC 1293, IETF, janv. 1992.

  • (6) - JOHNS (M.St.) -   Identification Protocol  -  . RFC 1413, IETF, fév. 1993.

  • ...

Logo Techniques de l'Ingenieur

Cet article est réservé aux abonnés.
Il vous reste 95 % à découvrir.

Pour explorer cet article Consulter l'extrait gratuit

Déjà abonné ?


Article inclus dans l'offre

"Sécurité des systèmes d'information"

(80 articles)

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques.

Des contenus enrichis

Quiz, médias, tableaux, formules, vidéos, etc.

Des modules pratiques

Opérationnels et didactiques, pour garantir l'acquisition des compétences transverses.

Des avantages inclus

Un ensemble de services exclusifs en complément des ressources.

Voir l'offre

Ressources documentaires

Annuaires LDAP - Aspects sécurité

La sécurité et les annuaires électroniques ont toujours été indéfectiblement liés, et cela dans deux ...

Logiciels libres - Licences et gestion de projet

L’édition de logiciels libres a vu le jour grâce à l'expansion et à la vulgarisation de l'informatique. ...