Si vous êtes en entreprise vous avez probablement un serveur proxy pour surfer sur Internet (parfois transparent), qui bloque un peu trop de choses. Mais sans ce proxy, internet ne fonctionne pas car les connections directes sont bloquées.

Voyons comment passer outre ce serveur proxy pour établir une connexion SSH pour surfer sans restriction via un proxy SOCKS 5 dans un tunnel SSH.

C'est une alternative qui permet d'atteindre un réseau distant (et internet) sans VPN.

Quelques explications techniques

Pour des questions de sécurité (logs, filtrage) mais aussi de performance (cache, QoS), on utilise un serveur mandataire (proxy) dans la plupart des entreprises. Il permet de contrôler et d'enregistrer tous les flux sortants de façon centralisée pour être en conformité juridique (hadopi, loi n° 2006-64 du 23 janvier 2006).

Parce que les serveurs proxy sont parfois configurés de manière trop restrictive, voici comment passer à travers avec une connexion SSH pour surfer comme à la maison.

Les serveurs proxy ne peuvent pas vraiment "proxifier" les requêtes chiffrées en SSL,c'est le cas des sites sécurisés (HTTPS). Du coup ils se contentent de renvoyer directement ces flux via la méthode connect. Seule la première URL/IP de destination est loguée, mais tout le reste étant chiffré le proxy ne voit rien d'autre... En fait l'établissement de la connexion est quasi-directe.

Nous allons profiter du chiffrement HTTPS pour établir une connexion SSH. Pour y parvenir notre serveur SSH est en écoute sur le port 443, afin que le proxy laisse passer cette connexion en pensant qu'il s'agit d'un site en HTTPS (comme Gmail par exemple).

De mon côté j'utilise un routeur Netgear WNR3500L avec le firmware libre Tomato, sur lequel j'ai configuré une redirection entrante (NAT) du port 443 vers le port 22 de ce même routeur. Vous pouvez également modifier le port d'écoute du démon SSH en 443, mais je préfère laisser le port 22 en écoute sur mon réseau interne.

Mon routeur Netgear incorpore un serveur SSH. Si vous n'en avez pas une machine sous Linux dans votre réseau fera aussi l'affaire (ainsi qu'un NAS Synology si vous activez SSH). Pensez simplement à renvoyer le port 443 entrant vers l'IP (fixe ou dhcp statique) du serveur/NAS Linux. Pour Windows il faut utiliser CopSSH ou Cygwin.

Vous n'avez rien à installer pour le proxy SOCKS, cela se fait de façon transparente du côté du serveur SSH (port dynamique).

Sous Windows avec Bitvise SSH Client

Un tunnel peut tout à fait s'établir via PuTTY qui supporte la configuration d'un proxy (attention cela bug avec KiTTY pour une raison inconnue). Mais PuTTY n'est pas très agréable à utiliser et la configuration des tunnels l'est encore moins.

C'est alors que j'ai découvert Bitvise SSH Client, un client SSH gratuit pour les particuliers et particulièrement facile à utiliser :

Il permet de configurer un maximum de choses en un minimum de clic grâce à une interface intuitive et efficace :

1. client SSH avec proxy socks
2. Sauvegarde de profils
3. client SFTP
4. FTP to SFTP Bridge
5. client SSH (ligne de commande)
6. translation de port (bidirectionnel)
7. gestionnaire de clé SSH
8. ouverture de port dynamique pour le bureau à distance Windows (RDP)
9. et bien d'autres...

Le bureau à distance Windows (il mappe automatiquement un port aléatoire vers le 3389 de la machine distante) :

Client SSH intégré (ne demande de login) :

Ou encore le forward de port qui me permet d'atteindre mon routeur Tomato depuis le port 9999 sur ma machine locale :

Configuration

Il faut préciser le nom (ou ip) du proxy d'entreprise, celui qui est précisé dans votre navigateur (ouvrir le .pac si vous en avez un car l'adresse est dedans). Choisir proxy HTTP et ne PAS cocher "resolve DNS names locally" :

Dans l'onglet Services, complétez de la façon suivante :

Listen Interface: IP d'écoute du proxy socks (votre machine locale)
Liste Port: port d'écoute sur votre machine locale

Pour utiliser le tunnel il faudra préciser dans votre navigateur le proxy socks sur 127.0.0.1 avec le port 5000.

Voici la configuration pour surfer via le tunnel pour Firefox :

Et pour Internet Explorer et Google Chrome :

Attention : c'est la bande montante (upload) de votre connexion distante qui sera sollicitée lorsque vous surfez via le proxy socks. Si vous êtes en ADSL le débit sera donc de maximum 1 mbps (environ 100 ko/sec). Si vous êtes fibrés à 5, 10 ou 50 mbps ça ira donc nettement plus vite.

A contrario, si votre entreprise a un gros débit montant (upload) vous pourrez envoyer des fichiers chez vous à vitesse grand V puisque c'est votre bande descendante qui sera sollicitée (download).

Conclusion

Grâce à ce tutoriel vous savez maintenant comment sortir d'un réseau filtré ("proxifié" et "firewallisé") pour atteindre un second réseau plus ouvert (chez vous, chez un ami, en datacenter, etc).

Cependant vous devez gardez en tête que vous respectez la charte informatique que vous avez probablement signée... car, même si tout passe dans un tunnel, la première connexion sur le port 443 restera active ("established") et apparaîtra dans les journaux des firewalls/proxys. Il ne faudra pas longtemps à un admin réseau pour blacklister cette IP qui apparaît un peu trop souvent dans les logs, il peut même vous questionner à ce sujet. Plutôt que d'utiliser un nom de domaine, je vous invite à utiliser votre IP directe, nettement plus discret (sans parler du faire que les dyndns like peuvent être bloqués).

Gardez deux choses en tête :

• les résolutions DNS se feront sur votre réseau distant, ce qui permet de bypasser le filtrage DNS s'il y a dans l'entreprise
• vous pouvez établir des connexions sur toutes les IP de votre réseau sans avoir à forwarder un port à chaque fois car tout passera par le socks. Néanmoins tous les services ne passent pas correctement via socks, à vous de voir.

Dans le cas d'un hotspot (hôtel, restaurant, gare) n'autorisant que le surf web cela peut s'avérer très pratique pour se connecter à d'autres machines en SSH (rebond). Ou encore au travers d'une connexion mobile (3G) si votre FAI n'autorise que le surf, mais il faudra peut-être utiliser un user-agent mobile en cas de contrôle de paquets. Chez Free Mobile il n'y a aucun filtrage mais c'est souvent le cas chez les MVNO.

Enfin, si votre entreprise utilise un système d'inspection des paquets (le fameux DPI, c'est à dire que le firewall scrute la couche logicielle 7 du modèle OSI) alors il se peut que cette technique ne fonctionne pas. En effet le début de la trame ne contient pas de flux web mais l'établissement d'une connexion SSH, souvent bloquée.

A vous le surf non filtré !

Si vous utilisez Linux vous pouvez passer par le package connect-proxy qui fera l'objet d'un futur billet si vous êtes intéressés ?

Article original écrit par Mr Xhark publié sur Blogmotion le 26/11/2012 | 6 commentaires |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons

Original post of Blogmotion.Votez pour ce billet sur Planet Libre.

Je suis devenu un vrai fan du gestionnaire de fenêtres i3wm et pour cause, il est ultra simple à scripter :)

Jusqu'à aujourd'hui une fonctionnalité majeure me manquait : pouvoir naviguer vers le workspace qui précède ou qui suit celui courant. On peut switcher entre les deux derniers workspaces qui ont été focused ou se déplacer directement vers un workspace (pour autant qu'un mapping soit prévu).

Pour arriver à combler ce manque, j'ai utilisé i3-msg qui permet de récupérer des informations sur i3wm et de lui donner des instructions. Je script en php car il faut lire du json...et en shell c'est compliqué !

L'algo est simple :

• je récupère les workspaces avec : i3-msg -t get_workspaces
• je les ordonne par ordre alphabétique (c'est comme ça que i3 les affiche)
• je récupère le workspace courant
• suivant ce qu'on demande, je retourne le workspace qui précède ou suit le workspace courant
• je demande à i3 de switcher vers le workspace via : i3-msg 'workspace "le nom du workspace cible"'

Le script est disponible ici. Placez-le où vous voulez et renseignez un mapping tel que celui-ci (dans ~/.i3/config) :

bindsym $mod+p exec ~/bin/i3_switch_workspace.php previous
bindsym $mod+n exec ~/bin/i3_switch_workspace.php next

Note : dans ce mapping, mes raccourcis sont window+P pour aller au workspace précédant et window+N pour aller au suivant. Mon script se trouve dans ~/bin/ et le fichier est nommé i3_switch_workspace.php.

N'oubliez pas de rendre le script exécutable (chmod +x).

Original post of Simon Vieille.Votez pour ce billet sur Planet Libre.

Nautilus était le dernier programme de Gnome auquel j'étais resté fidèle. Sa gestion des onglets et la possibilité de diviser sa fenêtre en 2 me le faisait préférer à Thunar et à PCManFm qui en étaient dépourvus. Quant à Dolphin et Konqueror, si les fonctionnalités sont au rendez-vous , ils s'intègrent mal dans mon environnement Openbox/gtk.

Oui mais voilà... Gnome poursuivant avec la constance qu'on lui connaît dans la voix de la régression, la si pratique division de fenêtre disparaissait avec la récente version 3.6 . Aussi j'étais impatient de voir arriver Thunar 1.5 (et ses onglets) dans les dépôts d'ArchLinux. Et ceux-ci se faisant prier, je me suis résolus à jeter un coup d'œil à AUR (Arch User Repository), pour y trouver un Thunar-extended en version 1.5.2 avec quelques goodies supplémentaire (gestion de la poubelle, aperçu audio...).

2 petites difficultés vite résolues - installer préalablement exo-devel (lui aussi dans AUR), la compilation réclamant une version ⩾ 0.9 - revalider toutes les actions personnalisées (pas besoin de les modifier, seulement les valider).

Bye-bye Nautilus

Original post of Vincent Gay.Votez pour ce billet sur Planet Libre.

C’est de la folie pure que de faire confiance aux compagnies de télécoms pour déployer Internet. Ces boîtes ont tout intérêt à retarder et empêcher toute amélioration de la bande passante ou de la neutralité, puisqu’une bande-passante omniprésente, ample et bon marché menacerait leurs investissements.

• L’aventure du Net
• Brisée par les télécoms
• L’alternative ? Les compagnies d’électricité

L’aventure du Net

Au tournant du siècle, les gens en Suède riaient grassement en écoutant les discussions des américains qui se demandaient s’il valait mieux utiliser le câble ou l’ADSL. En Suède, la plupart des maisons avaient été fibrées depuis des années. Moi, Falkvinge, j’avais la fibre dans mon appartement et un débit symétrique à 100 mégas avec une IP statique depuis 1999. Mon serveur était hébergé chez moi.

Je devrais ajouter qu’il n’y avait aucune limitation de rapidité ou de quantité de données échangées, et que c’était bidirectionnel. Ça aurait dû rester comme ça, mais ça ne l’a pas été, comme je vais l’expliquer.

À l’époque, passer un coup de téléphone paraissait déjà anachronique. Pourquoi payer un demi euro la minute pour une connexion 56k quand vous pouviez en passer 10 000 à la place pour un prix fixe bien inférieur ? Les industries de télécom allaient bientôt mourir ou se réduire à peau de chagrin. Nous n’utilisions les services des opérateurs téléphoniques qu’en attendant de passer à autre chose.

Puis, la bande passante de notre foyer fut restreinte. Alors que les capacités de stockage et de calcul des ordinateurs croissaient exponentiellement, la bande passante disponible se réduisit. Tous les petits fournisseurs d’accès à Internet furent rachetés par des gros de l’ancien monde de la téléphonie : Orange, SFR ou Bouygues par exemple en France.

Aventure brisée par les télécoms

C’était aussi prévisible que l’horloge de votre grand-père.

Ça fait sens, après tout : Tous ces commerciaux allaient mourir, donc il firent une manœuvre à la Red Flag, en prétendant qu’ils adoraient Internet, tout en essayant d’empêcher sa croissance et son utilité publique. Si Internet gagne, il désintégrera les entreprises du câble et les opérateurs téléphoniques. Ce qu’ils savent.

Plus que les diverses restrictions mises en place pour empêcher Internet d’être utile, c’est leur manque d’investissement dans des infrastructures qui rendraient Internet omniprésent et très bon marché qui est le principal problème. Regardez par exemple la longue décennie de stagnation de capacité des infrastructures que nous venons de passer.

En 1999, la Suède était n°3 pour la rapidité moyenne de téléchargement montant, après seulement le Japon et la Corée du Sud. À présent, la Suède est en place 18 derrière Hong Kong, Singapour, Taïwan, mais aussi l’Ukraine, la Lettonie, la Lituanie, la Moldavie, et la Roumanie ! À présent en Europe, les pays de l’Est dépassent largement les pays de l’Ouest.

Les politiques qui sont justifiées par l’idée que les opérateurs de télécommunication investiront dans le développement de la bande passante sont folles. Dans la même idée, au début de l’automobile, vous auriez pu subventionner les rares vendeurs de carrosse restant pour investir dans la recherche automobile. Ce qui se passe est au contraire que cette industrie chargée de la recherche des meilleures solutions pour la dépasser acceptera volontiers l’argent public et n’en fera rien, pour en demander plus.

Par exemple, le WiMax est un fiasco. Le WiMax était le «Wifi à l’échelle de la ville». C’était un réseau wifi à longue distance dont les performances dépassaient celles de la 3G et qui ne coûtait pas cher à déployer. Les compagnies de télécoms ont réussi à placer les fréquences officielles du Wifi dans le spectre qu’ils contrôlent. Et le WiMax en est aussitôt mort, aussi sûrement que les pierres tombent. Nous aurions pu avoir des couvertures réseaux urbaines sans identifiant, sans restriction de rapidité ou de taille de données échangées, et… rien. C’est pourtant dans l’intérêt de tous sauf des télécoms.

Techdirt a récemment souligné dans un article que le lobby des télécoms demande de plus en plus le contrôle d’Internet, dans un article titré : «Télécoms de l’UE: donnez leur plus de taxes, et Internet reste sauf».

L’alternative ? Les compagnies d’électricité

Quelle est donc l’alternative, si ce n’est pas de faire confiance aux télécoms ?

Je dirais que les compagnies d’énergie sont de bien meilleurs partenaires publics pour développer Internet. Leurs réseaux sont décentralisés et résilients, comme Internet. Ce sont des investissements de long-terme pour un courant de qualité. Et surtout, ils n’ont aucune vache à lait qui sera tuée par Internet. En Islande, la construction des réseaux énergétiques se discute d’ailleurs en même temps que le déploiement du très haut débit.

De fait, ma connexion actuelle à Internet, avec de nouveau 100 Mb/seconde en débit montant, soit 13 Mo/seconde, est délivrée par ma compagnie locale d’énergie. Vous connaissez beaucoup de gens qui font tourner leur serveur chez eux grâce à leur opérateur téléphonique ?

Je me demande souvent combien d’entreprises en Europe n’ont pas démarré parce qu’elles ne pouvaient pas démarrer à petite échelle à partir de chez soi, et donc quelle est l’ampleur des dommages que les fournisseurs d’accès à Internet ont déjà fait à l’Europe ?

Article original de Falkvinge, en anglais.

Si cet article vous a intéressé, vous pouvez aimer la page Facebook du blog, suivre ses rédacteurs Paul Neitse et Loïc Grobol sur Twitter ou s'abonner à son flux RSS.

Mais surtout, n'hésitez pas à participer aux traductions ou à faire un don pour remercier celles déjà faites ! Toute aide est la bienvenue :)

Original post of Politique du Netz.Votez pour ce billet sur Planet Libre.

Ça y est, Firefox 17 est sorti officiellement la semaine dernière et la déclinaison Nightly du panda roux devient donc la version 19 pour les six semaines à venir, une version dont on commence à voir les nouvelles fonctionnalités. Actuellement, Firefox possède déjà quelques pages un peu spéciales accessibles en tapant dans la barre d’adresse about:mot-clé. Ainsi si vous tapez about:config, vous aurez accès à toutes les options de Firefox, tout ce qui vous permettra de paramétrer comme bon vous semble votre navigateur, tandis que about:mozilla vous affichera un message qui peut différer selon les versions.

La version 19 de Firefox intégrera donc une nouvelle page spéciale : about:telemetry qui, comme son nom l’indique, affichera quelques données télémétriques concernant Firefox. Avant toute chose, précisons bien que ces données ne serviront probablement à rien pour l’utilisateur lambda, à part peut-être pour donner un début d’explications si jamais le navigateur se met à ramer… Car cette page sera avant tout là pour les testeurs du navigateur, des testeurs qui, via Telemetry, enverront anonymement des données à Mozilla, des données qui peuvent s’avérer précieuses pour aider au développement de Firefox.

Ces données concernent en effet les performances de Firefox et, plus particulièrement, les mauvaises performances. Par exemple, la première rubrique affichera les requêtes SQL qui ont mis un temps anormalement long à être exécutées tandis que la seconde rubrique quant à elle listera les moments où Firefox a eu une grosse baisse de régime, des faiblesses qui peuvent avoir un début d’explication grâce à la pile de fonctions qui ont conduit à ce ralentissement.

Enfin, about:telemetry contiendra également des graphiques sous forme d’histogrammes qui contiennent eux aussi un certain nombre d’informations (la liste est longue) qui peuvent là encore s’avérer précieuses pour l’amélioration du navigateur. Et bien entendu, comme d’habitude, on trouvera un moyen de désactiver Telemetry, un moyen bien mis en évidence tout en haut de la page par l’intermédiaire d’un bouton.

Via

Original post of Tasse de Café.Votez pour ce billet sur Planet Libre.