Les PALC (proxy à la con) sont ces horreurs qu’on trouve parfois dans les grandes sociétés. Ils filtrent, sans trop qu’on sache pourquoi, des pans entiers d’Internet, avec des règles hautement scientifiques qui filtrent à peu près tout ce qui serait utile à consulter avec un applomb exceptionnel.
PALC vraiment ALC
Je vous laisse lire les quelques premiers liens sur le web, c’est édifiant. C’est d’autant plus crétin que plus c’est filtré, plus ça encourage le personnel à trouver des moyens alternatifs. J’ai eu une mission dans un service de l’état où tout le service informatique avait un réseau parallèle avec un wifi à demi pirate et des postes portables personnels pour compléter le dispositif.
Là c’était assumé, mais chaque entreprise a ses bidouilles, ou ses renoncements. Les PALC empêchent de travailler tout bon informaticien, et soit on monte ses bidouilles soit on renonce et c’est l’entreprise qui gagne des informaticiens démotivés, incapables d’exécuter leur travail sans faire appel à des consultants externes, et totalement dépassés par les nouvelles technologies.
Les PALC sont les terreurs de ces consultants et autres prestataires. On arrive, on se retrouve à devoir résoudre des problèmes sans documentation, sans aide, et parfois sans même pouvoir accéder à ses propres mails ou contacter le réseau d’expert des collègues. Plus que contreproductif, ça met sérieusement à risque la capacité à exécuter le contrat qui nous lie.
La solution
La solution de percer le proxy et outrepasser les règles de sécurité de l’entreprise. C’est mal, je ne vous recommande pas de le faire. Je vous déconseille même de le faire. Si vous déclenchez des problèmes, ça vous retombera dessus et vous l’aurez bien cherché.
Quelques règles toutefois : 1– uniquement quand c’est nécessaire et 2– uniquement de l’entreprise vers l’extérieur, jamais de lien qui permette d’injecter du trafic non demandé vers l’intérieur de l’entreprise (si vous faites ça, quelle qu’en soit la raison, vous méritez tout ce qui peut vous arrivez ensuite).
Maintenant quasiment tous les consultants d’expertise technique que j’ai vu avaient leur solution. La mienne c’était le tunnel SSH sur port 443. On me dit que certains proxy savent le bloquer ou le repérer mais en pratique ça ne m’est jamais arrivé malgré un nombre de situations différentes très élevé.
Not(l’état de l’art a peut être évolué depuis, je ne donne aucune garantie). Si ça ne fonctionne pas il y a d’autres méthodes plus complexes, moins détectables, mais pas aussi pratiques. Toujours est-il que ça a été indispensable plus d’une fois.
Simple à mettre en oeuvre si vous avez un serveur qui tourne quelque part sur Internet, ça vous permet de faire transiter à peu près n’importe quoi comme trafic : web, messagerie, contrôle à distance, etc. Pour moi ça allait de consulter les sites techniques interdits par mauvais filtrage au chat avec mes collègues pour poser des questions techniques en passant par l’accès à mon webmail pro (et perso) ou par la protection de données que je ne souhaitais pas lisible par l’entreprise d’accueil.
Le gadget supplémentaire
Il y a deux défauts au tunnel SSH sur le port 443 : 1– Le dit port est utilisé avec SSH et ne peut plus renvoyer du HTTPS comme on le souhaiterait. 2– Si l’administrateur repère un gros volume vers votre serveur sur ce port il testera et verra qu’aucun site HTTPS ne répond (ça ne m’est jamais arrivé, mais prévoyons).
Le gadget magique c’est sslh. J’avais un mauvais code source en C qui faisait ça avant mais sslh fera ça bien mieux et plus complètement. Ce démon prend la place sur le port 443 et sait repérer si on tente d’utiliser du HTTPS, du SSH, de l’OpenVPN, ou du XMPP. Il redirigera le trafic vers le bon service en fonction des premiers octets de la connexion.