exemples

Cctt, "Covert Channel Tunneling Tool" - 顾名思义

    cctt -s 111.222.1.1 -p 443 -f srv_example_3.cf -t socket_encode -L -v &

     Pour lancer le client, nous entrons (sans etre root) la commande :
    cctt -c 111.222.1.1 -d 443 -f cl_example_3.cf -t \
      socket_http_proxy_encode -a &

  Nous  pouvons  desormais  configurer  notre  client  web  pour  qu'il  utilise
  127.0.0.1:4280 comme proxy http. Ainsi, toutes nos requetes a  destination  du
  serveur Web (ou des virtualhosts qu'il gere) transiteront par  le  canal  CCTT
  qui est encode.

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

IV) Beneficier des fonctionnalites de CCTT (chaine  de  proxy)  avec  le  client
     uniquement.

  A] Type d'architecture

  Nous prenons une architecture semblable a celle de l'example I) mais n'importe
  quel type aurait fait l'affaire - C'est l'idee qui nous interesse.
  Nous connaissons l'adresse IP du proxy : 192.168.1.1 et son  port  d'ecoute  :
  8080 de notre reseau local d'entreprise.
  Nous connaissons l'adresse IP de deux autres proxys se trouvant  sur  Internet
  et   supportant   egalement   la   methode   CONNECT   (111.111.1.1:8080    et
  222.222.2.2:8080).
  Nous savons que ces trois proxys possedent une autorisation de sortie vers les
  ports 443 et 8080.

  B] Fonctionnalites desirees

  Nous desirons nous connecter en SSH sur notre station personelle  connectee  a
  Internet et situee sur 111.222.1.1:443.
  Notre serveur SSH personnel est en ecoute sur ce port et nous  voulons  :  'NE
  RIEN INSTALLER SUR NOTRE MACHINE PERSO' :)

  C] Fichiers de configuration

  Le fichier de configuration cl_example_4.cf du client doit etre le suivant :
        PROTOCOL=tcp
        CHANNEL_PROXY_IP=192.168.1.1
        CHANNEL_PROXY_PORT=8080
        CHANNEL_PROXY_PROT=tcp
        CHANNEL_PROXY_DEL=25000
        HTTP_PROXY_CHAIN=111.111.1.1:8080:25000;222.222.2.2:8080:25000
        PROXY_MODE_LOCAL_IP=127.0.0.1
        PROXY_MODE_LOCAL_PORT=4222
        PROXY_MODE_PROT=tcp
        ### Theses one are not used, but without, the client won't start.
        IDENT=basic_ident
        IDENT_KEY=simsim
        PROXY_MODE_REMOTE_IP=127.0.0.1
        PROXY_MODE_REMOTE_PORT=22

  D] Parametres de ligne de commande et execution

     Pour lancer le client, nous entrons (sans etre root) la commande :
    cctt -c 111.222.1.1 -d 443 -f cl_example_4.cf -t \
      client_only_with_http_proxy &

  Nous possedons desormais un client Cctt en ecoute sur localhost:4222. Quand ce
  client recoit une connexion, il se connecte sur le premier proxy, puis sur  le
  deuxieme, puis le troisieme et finalement parvient a notre serveur.
  A ce moment, nous disposons d'un canal TCP standard entre l'application locale
  et l'application distante.

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

V) Demonstration du concept de mode proxy inverse avec CCTT.

  A] Type d'architecture

  Nous prenons une architecture semblable a celle de l'example I) mais n'importe
  quel type aurait fait l'affaire - C'est l'idee qui nous interesse.
  Nous connaissons l'adresse IP du proxy : 192.168.1.1 et son  port  d'ecoute  :
  8080 de notre reseau local d'entreprise.

  B] Fonctionnalites desirees

  Nous desirons acceder au serveur  Web  interne  (192.168.2.1:80)  ainsi  qu'au
  serveur SMTP (192.168.2.2:25) de notre entreprise depuis l'exterieur.
  Nous desirons autoriser deux stations externes (W1 et W2) a acceder au serveur
  Web et une troisieme station (S) a acceder au serveur SMTP via  notre  serveur
  CCTT positionne egalement sur une station externe (C - 111.222.1.1:443).

  C] Fichiers de configuration

  Le fichier  de  configuration  (srv_example_5.cf)  du  serveur  doit  etre  le
  suivant :
        PROTOCOL=tcp
        IDENT=basic_ident
        IDENT_KEY=simsim
        SRV_SHELL_LOC=/usr/local/bin/false
        SRV_SHELL_CMD=false
        PROXY_ONLY=ON
        PERM_USER_GROUP=cctt
        PERM_CHROOT=cage

  Le fichier de configuration (cl_Wint_example_5.cf) du client interne doit etre
  le suivant pour l'acces au serveur Web :
	PROTOCOL=tcp
	IDENT=basic_ident
	IDENT_KEY=simsim
	CHANNEL_PROXY_IP=192.168.1.1
	CHANNEL_PROXY_PORT=8080
	CHANNEL_PROXY_PROT=tcp
	CHANNEL_PROXY_DEL=15000
	PROXY_MODE_PROT=tcp
	PROXY_MODE_REMOTE_IP=192.168.2.1
	PROXY_MODE_REMOTE_PORT=80

  Le fichier de configuration (cl_Sint_example_5.cf) du client interne doit etre
  le suivant pour l'acces au serveur Web :
	PROTOCOL=tcp
	IDENT=basic_ident
	IDENT_KEY=simsim
	CHANNEL_PROXY_IP=192.168.1.1
	CHANNEL_PROXY_PORT=8080
	CHANNEL_PROXY_PROT=tcp
	CHANNEL_PROXY_DEL=15000
	PROXY_MODE_PROT=tcp
	PROXY_MODE_REMOTE_IP=192.168.2.2
	PROXY_MODE_REMOTE_PORT=25

  Le fichier de configuration (cl_Wext_example_5.cf) du client externe doit etre
  le suivant pour l'acces au serveur Web :
	PROTOCOL=tcp
	IDENT=basic_ident
	IDENT_KEY=simsim
	PROXY_MODE_LOCAL_IP=@IP_W1
	PROXY_MODE_LOCAL_PORT=4280
	PROXY_MODE_PROT=tcp
	PROXY_MODE_REMOTE_IP=192.168.2.1
	PROXY_MODE_REMOTE_PORT=80

  Le fichier de configuration (cl_Sext_example_5.cf) du client externe doit etre
  le suivant pour l'acces au serveur Web :
	PROTOCOL=tcp
	IDENT=basic_ident
	IDENT_KEY=simsim
	PROXY_MODE_LOCAL_IP=@IP_S
	PROXY_MODE_LOCAL_PORT=4225
	PROXY_MODE_PROT=tcp
	PROXY_MODE_REMOTE_IP=192.168.2.2
	PROXY_MODE_REMOTE_PORT=25

  D] Parametres de ligne de commande et execution

  Nous commencons par lancer le serveur en entrant (en tant que root) :
    cctt -s 111.222.1.1 -p 443 -f srv_example_5.cf -t socket -L -v &

  Nous lancons ensuite les deux clients presents sur le reseau interne  en  mode
  proxy inverse :
    cctt -c 111.222.1.1 -d 443 -f cl_Wint_example_5.cf -t socket_http_proxy -z &
    cctt -c 111.222.1.1 -d 443 -f cl_Sint_example_5.cf -t socket_http_proxy -z &

  => Ces deux clients s'enregistrent aupres du serveur en lui  indiquant  qu'ils
     sont les points de passages pour  acceder  aux  serveurs  Web  et  SMTP  et
     conservent la connexion ouverte avec le serveur.

  Note : Le serveur ajoute et retire dynamiquement les  clients  en  mode  proxy
  inverse lors des etablissements et ruptures de connexion.

  Nous lancons ensuite les deux clients presents sur le reseau externe  en  mode
  proxy :

    Sur W1, nous lancons : cctt -c 111.222.1.1 -d 443 -f cl_Wext_example_5.cf\
                             -t socket -a &
    Sur S, nous lancons  : cctt -c 111.222.1.1 -d 443 -f cl_Sext_example_5.cf\
                             -t socket -a &
	
       => Ces deux clients se mettent en attente de clients applicatifs.

  Nous possedons maintenant deux services en ecoute  :  Le  service  d'acces  au
  serveur Web est en ecoute sur @IP_W1:4280 et le  service  d'acces  au  serveur
  Smtp est en ecoute sur @IP_S:4225.

     Quand un client veut acceder au serveur SMTP :
      * Il ouvre une connexion vers @IP_S:4225.
   * Le client CCTT present sur S ouvre une connection vers le serveur CCTT C et
     lui demande d'acceder au serveur SMTP.
   * Le serveur CCTT verifie dans  sa  liste  d'autorisation  proxy,  trouve  la
     connexion inverse existante vers le client CCTT interne gerant le  SMTP  et
     fait office de proxy.
   * Le client CCTT interne recoit des donnees,  ouvre  une  connexion  vers  le
     serveur SMTP et fait office de proxy.

  La meme chose est valable pour d'autres clients applicatifs SMTP ou  pour  les
  clients applicatifs Web.

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

VI) Mode HTTP : Confusion par emission/reception de messages HTTP inutiles.

Pour les fichiers de configuration, referez vous a doc/confs/http_post1.
Pour les parametres de ligne de commande, referez vous aux exemples precedents.

  A] Type d'architecture

  N'importe quelle architecture autorisant un utilisateur a envoyer des requetes
  HTTP POST avec ou sans utilisation d'un serveur proxy intermediaire.

  B] Fonctionnalite presentee

  Le mode HTTP de  CCTT  permet  l'envoi  de  requetes  HTTP  POST  inutiles  au
  fonctionnement du canal.
  Ces requetes peuvent etre envoyees par le client CCTT a intervalle regulier ou
  aleatoire au serveur CCTT et ne font pas partie des requetes utilisees pour le
  transport des donnees utiles.
  Si ces requetes sont configurees au niveau du serveur CCTT,  le  serveur  CCTT
  renvoie le contenu des fichiers demandes et ce contenu n'est  tout  simplement
  pas utilise par le client.

  On obtient donc un trafic superflu qui permet d'accroitre  la  confusion  d'un
  eventuel observateur.

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

VII) Mode HTTP : Confusion par une gestion du comportement du serveur.

Pour les fichiers de configuration, referez vous a doc/confs/http_post1.
Pour les parametres de ligne de commande, referez vous aux exemples precedents.

  A] Type d'architecture

  N'importe quelle architecture autorisant un utilisateur a envoyer des requetes
  HTTP POST avec ou sans utilisation d'un serveur proxy intermediaire.

  B] Fonctionnalite presentee

  Si le serveur est configure  comme  dans  l'exemple  VI),  il  est  en  mesure
  d'accepter des requetes qui ne proviendraient pas de clients CCTT.
  Quand ces requetes sont configurees au  niveau  du  serveur  (GET  /index.html
  HTTP/1.0 par exemple), le serveur renvoie le fichier  correspondant  et  quand
  ces requetes ne sont pas configurees, le serveur renvoie une page d'erreur.
  Un exemple de pages qui peuvent etre renvoyees par le serveur est present  sur
  la presentation HTML situee sur le site Web Gray-World.

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

VIII) Mode HTTP : Confusion  par  encapsulation  des  donnees  utiles  dans  des
      donnees inutiles.

Pour les fichiers de configuration, referez vous a doc/confs/http_post2.
Pour les parametres de ligne de commande, referez vous aux exemples precedents.

  A] Type d'architecture

  N'importe quelle architecture autorisant un utilisateur a envoyer des requetes
  HTTP POST avec ou sans utilisation d'un serveur proxy intermediaire.

  B] Fonctionnalite presentee

  Le mode HTTP de CCTT permet d'ajouter des donnees arbitraires au debut ou a la
  fin des donnees utiles au canal de communication.
  Ce "padding" peut etre ajoute tant dans les requetes POST du client  que  dans
  les reponses HTTP du serveur.

  Un exemple de padding des requetes et reponses lors d'un echange en mode  HTTP
  est present dans le fichier doc/confs/http_post2/snort_capture.txt.

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