 Bla-Bla Club  sur le forum Blabla moins de 15 ans - 08-08-2003 01:16:46 - page 362

TommyVercettiii

Niveau 9

08 août 2003 à 01:16:46

je crois que non...

Dark-SZ

Niveau 10

08 août 2003 à 01:18:42

asta_la_vista

Niveau 10

08 août 2003 à 01:18:57

TommyVercettiii

Niveau 9

08 août 2003 à 01:21:09

lol!!

Dark-SZ

Niveau 10

08 août 2003 à 01:21:59

Bon je vais allez voir ailleur, @++

TommyVercettiii

Niveau 9

08 août 2003 à 01:23:21

Mon 300ème msg!

asta_la_vista

Niveau 10

08 août 2003 à 01:23:45

ok @++

Dark-SZ

Niveau 10

08 août 2003 à 01:24:23

Bienvenue au Bla-Bla Club.
Veuillez me dire votre pseudo pour être membre de mon club.
Grades du Club :

1:Président:Dark-SZ
2:World Posteurs:[1.660msg posté]:
3:Assistant du Président:[Aimé par le président + 1.000msg posté + Aimé par tous + Élu a plus de 50%]:
4:Vice Président:[Aimé par le président + 500msg posté + Aimé par tous]:
5:Meilleurs posteurs:[660msg posté]:
6:Les plus aimé:[Il faut etre aimé beaucoup par tous]:
7:Top Sympas + Top Posteurs:[500msg posté sur le topic + Aimé par tous]:
8:Top Posteurs:[350msg posté]:Asta_la_vista, lourdmachinery,
9:Top Sympas:[Aimé par Tous]:beber,
10:Posteur#1:[300msg posté]:
11:Posteur#2:[200msg posté]:bastou78,
12:Posteur#3:[100msg posté]:Dauer, TiffaniTendo,
13:Sympa#1:[Aimé par 6 membres]:ticop, chevalierblanc,
14:Sympa#2:[Aimé par 5 membres]:yuna], [soul]
15:Sympa#3:[Aimé par 4 membres]:Xators, duff360,
16:Sympa#4:[Aimé par 3 membres]:suneemon, Tite_Miss,
17:Sympa:[Aimé par 2 membres]:shadowmaniac, monster3,
18:Simples membres:[Être membres]:LeFlicDeMiami, Mark_roy, LECOCHONDINDE, dauphine03, Mario_Cipollini, darkness-0, le-ptit-Yugi, Shadye, catpredator, AngeDePaix, Ak47Soda, PerfectCed, ]--explicit--[, Stryer, Socoman, SPE6MAN, jonathan56100, LeLoss, THE-DIABLE, chtijuju, joooli, madawc, blitzballplayer, Tsawanna, sinci, Codename-48, malow, JackKraven, WarriorPrince, benjiiii, M0RPH0, bibi26, SuperBiscuit, [ilanm], Mega_kat, slava, waider, [drazic], vhbggbhg,

Duff360

Niveau 10

08 août 2003 à 01:52:36

re!

Duff360

Niveau 10

08 août 2003 à 01:53:36

mickael900

Niveau 1

08 août 2003 à 01:54:04

==================================================

==============================
Exploitation des flux autorisés par un système de contrôle d´accès réseau pour
un transfert de données arbitraires :
Tunneling et canaux cachés au sein du protocole HTTP.

v1.0 - Juillet 2003

Simon Castro < scastro [at] entreelibre.com>

Traduction Française de :

- ***********************************************

- ***************************

Exploitation of data streams authorized by a network access control system for
arbitrary data transfers :
tunneling and covert channels over the HTTP protocol.

v1.0 - June 2003

Alex Dyatlov < alex [at] gray-world.net>
Simon Castro < scastro [at] entreelibre.com>
http://www.gray-world.net

- ***********************************************

- ***************************

==================================================

==============================

- ***********************************************

- ***************************

Consultez la partie NOTES A LA TRADUCTION FRANCAISE pour la licence associée
à cette traduction.

- ***********************************************

- ***************************

==================================================

==============================
Copyright ( c) 2003, Alex Dyatlov and Simon Castro.
Permission is granted to copy, distribute and/or modify this document under the
terms of the GNU Free Documentation License, Version 1.2 or any later version
published by the Free Software Foundation; with the Invariant Sections being
LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the
Back-Cover Texts being LIST.
You must have received a copy of the license with this document and it should
be present in the fdl.txt file.
If you did not receive this file or if you don´t think this fdl.txt license is
correct, have a look on the official http://www.fsf.org/licenses/fdl.txt
licence file.

==================================================

==============================

======
RESUME
======

Les autorisations de transit de données entre des réseaux inter-connectés sont
définies et implémentées au niveau des Systèmes de contrôle d´accès réseau (
Network Access Control System ( NACS)).

En fonction de la configuration du NACS, il est possible à l´heure actuelle,
via différentes méthodes d´évasion, d´utiliser les flux autorisés pour faire
transiter des données arbitraires dont le trafic est interdit, mettant ainsi en
place un canal de communication qui est fréquemment nommé " canal caché".

Les canaux cachés et le tunneling font désormais l´objet d´un grand nombre
d´articles ou d´implémentations logicielles. Certains sont cachés dans les
couches basses du modèles OSI alors que d´autres s´inscrivent dans les couches
hautes.

Le protocole HTTP étant l´un des protocoles les plus utilisés à l´heure
actuelle, la possibilité de réaliser des implémentations logicielles de
tunneling et de canaux cachés en son sein devrait être un sujet de réflexion
pour les chercheurs et les administrateurs réseau.

La conception d´un outil de type Client/Serveur permettant d´exploiter des
canaux cachés au sein du protocole HTTP peut être basée sur les aspects
suivants : Quel modèle de serveur doit être implémenté ( Httpd, Proxy, CGI) -
Comment l´outil pourra t´il être conçu pour accroître la confusion d´un éventuel
observateur surveillant le trafic ( Chaîne de proxy, Serveurs intermédiaires
distribués, Pseudo serveurs Proxy, utilisation de serveurs tiers) - Quel type de
fonctionnalité sera mis en oeuvre ( Application cliente unique, Application
cliente en mode proxy, Serveur en mode proxy, Application cliente en mode proxy
inversé, protocole d´échange prédéfini et propriétaire).

Une fois l´outil de type Client/Serveur modélisé, les développeurs peuvent
réfléchir au moyen d´appliquer ce modèle à un environnement concret : Quel type
de méthode HTTP peut être utilisé ( Avec ou sans corps de données HTTP, avec ou
sans la méthode CONNECT) - Quel type de serveur HTTP légitime peut être utilisé
pour faire transiter le flux de données arbitraires au travers du NACS ( Proxy
HTTP et Reverse-Proxyies, applications tierces).

La conception d´un outil de communication de ce type implique également de
réfléchir à sa sécurité intrinsèque : authentification et autorisation du client
et du serveur, chiffrement et contrôle d´intégrité du flux de données,
protection contre le rejeu. Une attention spéciale doit également être portée
au développement du code source en évitant, autant que faire se peut,
d´introduire d´éventuelles failles.

Le principe fondamental des méthodes d´établissement de canaux cachés reposant
sur leur furtivité intrinsèque, une attention particulière peut également être
portée sur l´utilisation de techniques de couvertures et de techniques
stéganographiques de façon à accroître la confusion d´un éventuel observateur.

Cacher des données dans les requêtes et réponses HTTP ( entêtes et corps des
données HTTP) avec des techniques stéganographiques, ajouter un trafic réseau
aléatoire ou spécialement contruit, modéliser des comportements de serveurs pour
qu´ils semblent être ce qu´ils ne sont pas.

Toutes ces méthodes augmentent drastiquement la furtivité des canaux cachés.

L´article " Exploitation des flux autorisés par un système de contrôle d´accès
réseau pour un transfert de données arbitraires : Tunneling et canaux cachés au
sein du protocole HTTP." de Gray-World présente ces concepts aux chercheurs et
aux administrateurs NACS afin de leur expliquer qu´à chaque fois qu´un
administrateur croit n´autoriser que l´entrée et la sortie du protocole HTTP en
dehors de son réseau interne, il autorise également des transferts de données
arbitraires au travers de son périmètre sécurisé.

Cet article est publié sous la licence GNU FDL ( Free Documentation Licence),
Version 1.2 et est copyleft Alex Dyatlov et Simon Castro - www.gray-world.net.

==================================================

==============================

========
SOMMAIRE
========

RESUME
SOMMAIRE
INTRODUCTION

1. APPROCHE THEORIQUE DU PROTOCOLE HTTP
1.1. LE PROTOTOCOLE HTTP DANS NOTRE CYBER-MONDE
1.2. SOMMAIREMENT, LE PROTOCOLE HTTP EST
1.3. L´ABSTRACTION CLIENT/SERVEUR DU PROTOCOLE HTTP
1.4. POURQUOI AVONS NOUS CHOISI UNE APPROCHE THEORIQUE DU PROTOCOLE HTTP
2. IMPLEMENTATIONS CLIENT/SERVEUR
2.1. MODELES SERVEUR
2.1.1. Modèle serveur Httpd
2.1.2. Modèle serveur Proxy
2.1.3. Modèle serveur CGI
2.2. MODELES ORIENTES FLUX RESEAUX
2.2.1. Modèle de chaînes de proxy
2.2.2. Modèle de serveurs intermédiaires distribués
2.2.3. Modèle de pseudo-proxy
2.2.4. Modèle de serveurs tiers légitimes
2.3. MODES
2.3.1. Mode application cliente unique
2.3.2. Mode application cliente en mode proxy
2.3.3. Mode serveur en mode proxy
2.3.4. Mode application cliente en mode proxy inversé
2.3.5. Protocole d´échange prédéfini et propriétaire
2.4. APPLIQUER LES MODELES ET MODES DANS UN ENVIRONNEMENT CONCRET
2.4.1. Les proxy HTTP
2.4.2. Les proxy inversés
2.4.3. D´autres applications utilisent des intermédiaires HTTP
3. UTILISER LES METHODES HTTP
3.1. RESTRICTIONS RELATIVES AUX CONTAINERS DE DONNEES
3.1.1. Chaînes URI
3.1.2. Chaînes d´entête
3.1.3. Corps d´un message HTTP
3.2. METHODES SANS CORPS DE DONNEES : GET, HEAD, DELETE
3.2.1. La méthode GET
3.2.2. La méthode HEAD
3.2.3. La méthode DELETE
3.3. METHODES AVEC CORPS DE DONNEES : OPTIONS, POST, PUT, TRACE
3.3.1. La méthode OPTIONS
3.3.2. La méthode POST
3.3.3. La méthode PUT
3.3.4. La méthode TRACE
3.4. LA METHODE CONNECT DES PROXY HTTP
3.5. CONCLUSION
4. ASPECTS SECURITE
4.1. AUTHENTIFICATION
4.2. AUTORISATION
4.3. CHIFFREMENT DU FLUX DE DONNEES
4.4. INTEGRITE DU FLUX DE DONNEES
4.5. PROTECTION CONTRE LE REJEU
5. METHODES DE COUVERTURE ET DE STEGANOGRAPHIE
5.1. CONFUSION SUR LE FLUX HTTP
5.1.1. Cacher des données dans le header HTTP
5.1.2. Cacher des données dans le corps HTTP
5.2. CONFUSION SUR LE FLUX DE DONNEES
5.3. CONFUSION SUR LE COMPORTEMENT DU SERVEUR

CONCLUSION
WEBOGRAPHIE ET OUTILS
REMERCIEMENTS
NOTES A LA TRADUCTION FRANCAISE

==================================================

==============================

============
INTRODUCTION
============

Les autorisations de transit de données entre des réseaux inter-connectés via
un ( des) système(s) de contrôle d´accès sont définies et mises en place
conformément à une politique de sécurité. Une politique de sécurité exemplaire
relative aux contrôles d´accès réseau s´appuie sur le postulat qui consiste à
interdire tous les flux de données qui n´ont pas été strictement prévus.
Autrement dit " Nous interdisons tout, puis nous ouvrons des accès spécifiques et
précis ! "

Les systèmes de contrôle d´accès réseau les plus fréquents reposent sur
l´utilisation, conjointe ou non, d´outils effectuant un filtrage au niveau des
différentes couches du modèle OSI ( équipements réseau : niveau 2 et 3, routeurs:
niveau 3, pare-feu/Firewall : niveaux 3, 4 et pare-feu/Firewall applicatifs :
couches > 4). A ces équipements peuvent être associés d´autres outils dont les
interactions avec les flux réseaux se positionnent au niveau des couches hautes
du modèle OSI : serveurs mandataires ( proxy), anti-virus, systèmes de détection
d´intrusion ( Intrusion Detection System), outils de filtrage de contenu,
systèmes de détection d´anomalie ( Anomaly Detection System), normaliseurs de
flux réseaux etc.

Toutefois, malgré l´emploi de ces systèmes de contrôle d´accès réseau, il est
à l´heure actuelle possible, via différentes méthodes d´ " évasion", d´utiliser
les flux autorisés par la politique de sécurité pour faire transiter des données
arbitraires dont le trafic est imprévu/interdit. Ces possibilités d´évasion
permettent l´ouverture de canaux de communication ( covert channel, canaux
subliminaux) donnant accès à des services externes à partir du réseau interne ou
accès à des ressources internes à partir du réseau externe.

Le principe fondamental de ces " évasions" repose sur l´absence de vérification
de la valeur intrinsèque des données qui transitent. Les diverses
implémentations de systèmes de contrôle d´accès reposent, en effet, sur
l´abstraction protocolaire qui voudrait qu´un transfert de données s´appuyant
sur les diverses couches du modèle OSI ne puisse servir qu´à transporter les
données prévues par le(s) protocole(s) sous-jacent(s).

Bien qu´il soit possible de détecter certains flux anormaux transitant au
travers du système de contrôle d´accès réseau, il peut être tenu pour acquis que
l´utilisation de certains types de canaux de communication est à l´heure
actuelle indétectable.

==================================================

==============================

=======================================
1. APPROCHE THEORIQUE DU PROTOCOLE HTTP
=======================================

1.1. LE PROTOTOCOLE HTTP DANS NOTRE CYBER-MONDE
-----------------------------------------------

Le Protocole de Transfert HyperTexte ( HyperText Transfer Protocol : HTTP)
est vastement utilisé dans le monde entier à l´heure actuelle. Même si
certaines compagnies ou organisations d´Etat ne sont pas directement
connectées à Internet, la majorité d´entre elles offrent un accès à leur
utilisateurs au travers de leur système de contrôle d´accès réseau ( Network
Access Control System : NACS).

Les compagnies commerciales sont convaincues qu´autoriser leurs utilisateurs
à surfer sur le World Wide Web via un NACS ne représente pas un vrai risque de
sécurité. En fait, installer des pare-feux ( firewalls) pour protéger des DMZs
et des reseaux locaux internes, configurer des Antivirus, des IDS, ADS ou
n´importe quoi d´autre protège effectivement les compagnies de la majorité
des attaques Internet connues.

Cependant, il est à l´heure actuelle communément admis, dans la communeauté
de la sécurité, que le protocole HTTP souffre d´un certain nombre de
faiblesses de conception permettant l´établissement de canaux cachés. Mais
ceci est compréhensible car ce protocole n´a pas été conçu pour éviter ce que
les chercheurs présentent à la communeauté depuis une dizaine d´années.

1.2. SOMMAIREMENT, LE PROTOCOLE HTTP EST
----------------------------------------

Le " protocole HTTP est un protocole de niveau applicatif [...]. C´est un
protocole générique, sans état et qui peut être utilisé pour remplir de
nombreuses tâches divergentes de son emploi pour le protocole HyperTexte
[...]." ( " Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616) [1].

tareumenstring

Niveau 1

08 août 2003 à 01:54:28

==================================================

==============================
Exploitation des flux autorisés par un système de contrôle d´accès réseau pour
un transfert de données arbitraires :
Tunneling et canaux cachés au sein du protocole HTTP.

v1.0 - Juillet 2003

Simon Castro < scastro [at] entreelibre.com>

Traduction Française de :

- ***********************************************

- ***************************

Exploitation of data streams authorized by a network access control system for
arbitrary data transfers :
tunneling and covert channels over the HTTP protocol.

v1.0 - June 2003

Alex Dyatlov < alex [at] gray-world.net>
Simon Castro < scastro [at] entreelibre.com>
http://www.gray-world.net

- ***********************************************

- ***************************

==================================================

==============================

- ***********************************************

- ***************************

Consultez la partie NOTES A LA TRADUCTION FRANCAISE pour la licence associée
à cette traduction.

- ***********************************************

- ***************************