sslh : Couteau suisse contre les PALC


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’In­ter­net, avec des règles haute­ment scien­ti­fiques qui filtrent à peu près tout ce qui serait utile à consul­ter avec un applomb excep­tion­nel.

PALC vrai­ment ALC

Je vous laisse lire les quelques premiers liens sur le web, c’est édifiant. C’est d’au­tant plus crétin que plus c’est filtré, plus ça encou­rage le person­nel à trou­ver des moyens alter­na­tifs. J’ai eu une mission dans un service de l’état où tout le service infor­ma­tique avait un réseau paral­lèle avec un wifi à demi pirate et des postes portables person­nels pour complé­ter le dispo­si­tif.

Là c’était assumé, mais chaque entre­prise a ses bidouilles, ou ses renon­ce­ments. Les PALC empêchent de travailler tout bon infor­ma­ti­cien, et soit on monte ses bidouilles soit on renonce et c’est l’en­tre­prise qui gagne des infor­ma­ti­ciens démo­ti­vés, inca­pables d’exé­cu­ter leur travail sans faire appel à des consul­tants externes, et tota­le­ment dépas­sés par les nouvelles tech­no­lo­gies.

Les PALC sont les terreurs de ces consul­tants et autres pres­ta­taires. On arrive, on se retrouve à devoir résoudre des problèmes sans docu­men­ta­tion, sans aide, et parfois sans même pouvoir accé­der à ses propres mails ou contac­ter le réseau d’ex­pert des collègues. Plus que contre­pro­duc­tif, ça met sérieu­se­ment à risque la capa­cité à exécu­ter le contrat qui nous lie.

La solu­tion

La solu­tion de percer le proxy et outre­pas­ser les règles de sécu­rité de l’en­tre­prise. C’est mal, je ne vous recom­mande pas de le faire. Je vous décon­seille même de le faire. Si vous déclen­chez des problèmes, ça vous retom­bera dessus et vous l’au­rez bien cher­ché.

Quelques règles toute­fois : 1– unique­ment quand c’est néces­saire et 2– unique­ment de l’en­tre­prise vers l’ex­té­rieur, jamais de lien qui permette d’injec­ter du trafic non demandé vers l’in­té­rieur de l’en­tre­prise (si vous faites ça, quelle qu’en soit la raison, vous méri­tez tout ce qui peut vous arri­vez ensuite).

Main­te­nant quasi­ment tous les consul­tants d’ex­per­tise tech­nique que j’ai vu avaient leur solu­tion. 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 situa­tions diffé­rentes très élevé.

Not(l’état de l’art a peut être évolué depuis, je ne donne aucune garan­tie). Si ça ne fonc­tionne pas il y a d’autres méthodes plus complexes, moins détec­tables, mais pas aussi pratiques. Toujours est-il que ça a été indis­pen­sable plus d’une fois.

Simple à mettre en oeuvre si vous avez un serveur qui tourne quelque part sur Inter­net, ça vous permet de faire tran­si­ter à peu près n’im­porte quoi comme trafic : web, messa­ge­rie, contrôle à distance, etc. Pour moi ça allait de consul­ter les sites tech­niques inter­dits par mauvais filtrage au chat avec mes collègues pour poser des ques­tions tech­niques en passant par l’ac­cès à mon webmail pro (et perso) ou par la protec­tion de données que je ne souhai­tais pas lisible par l’en­tre­prise d’ac­cueil.

Le gadget supplé­men­taire

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 souhai­te­rait. 2– Si l’ad­mi­nis­tra­teur repère un gros volume vers votre serveur sur ce port il testera et verra qu’au­cun 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è­te­ment. Ce démon prend la place sur le port 443 et sait repé­rer si on tente d’uti­li­ser du HTTPS, du SSH, de l’OpenVPN, ou du XMPP. Il redi­ri­gera le trafic vers le bon service en fonc­tion des premiers octets de la connexion.

, ,

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.