Se connecter à son serveur debian depuis un point d'accés

Trucs et Astuces
#1

Bonjour,
vous avez un serveur/poste de travail à la maison sous debian, et vous souhaitez pouvoir y accéder depuis n’importe où, y compris depuis un poste win dans un réseau qui restreint fortement l’accès à internet hotspot wifi, réseau d’entreprise)?
Ce truc et astuce est en construction. N’hésitez pas à participer à la discussion.

résumé des astuces proposées:

Je vais détailler l’option tunnel ssh.

astuce à valider par retour d’un utilisateur l’ayant testée
Comme on écrit toujours: ça marche chez moi, à valider chez les autres

[size=150]coté serveur[/size]
il s’agit de votre serveur/poste debian à la maison (ou dédié chez un fournisseur)
on installe le serveur openssh

Il va falloir sécuriser un peu tout ça, même si la config par défaut est déjà bien verrouillée.
On va créer un utilisateur dédié à cette connexion depuis internet, ainsi, si quelqu’un arrive malgré vos précautions à se connecter, il n’ira pas bien loin, et n’aura accès à aucune info que vous ne souhaitez pas rendre publique …

Inutile de vous recommander de choisir un mot de passe béton …
La configuration du serveur se passe dans /etc/ssh/sshd_config
Vous pouvez consultez isalo.org/wiki.debian-fr/Ssh
Il faut limiter la connexion à l’utilisateur spécifique

Concernant le port de connexion, il y a 2 cas:

  • serveur relié directement au net (cas d’un dédié): on fait écouter le serveur sur le port 443 Port 443
  • serveur derrière une “box”: peu importe le port d’écoute du serveur sur votre LAN . Par contre il faut configurer la box pour qu’une connexion coté internet port 443 soit orientée coté LAN sur le port du serveur.
    sécurisation par clef

su client-exterieur mkdir /home/client-exterieur/.ssh chmod 700 .ssh touch /home/client-exterieur/.ssh/authorized_keys2
éditez le fichier, et ajoutez y la clef publique du client (voir chapitre suivant), puis:

[size=150]Coté client[/size]
vous l’aurez compris, l’idée est de se connecter en passant par le port 443, c’est à dire en faisant croire qu’on se connecte à un site en HTTPS
Client linux: je vous laisse configurer votre client ssh …
Clien windows. Là se devient plus intéressant.
Rien de plus à ajouter à ce super tuto: http://michauko.org/blog/tunnels-tcp-via-ssh-putty-etc-181/
Pour générer les clefs et configurer putty : ualberta.ca/CNS/RESEARCH/Lin … putty.html

[size=150]cerise sur le gateau[/size]
Le serveur openssh intégre un prowy SOCKS, alors pourquoi ne pas s’en servir ? Ce proxy vous permet de “rebondir” depuis votre serveur debian vers n’importe quel site internet.
Coté client, il faut configurer putty pour une affectation dynamique de port (voir tuto putty §3.3.1)
Coté firefox, il faut lui dire de passer par le tunnel ssh qu’on vient de créer, et non plus par accès direct.

  • indiquer le nouveau proxy menu Outils > Options > Avancé > Paramètres de Connexion serveur: 127.0.0.1 port:10080 dans la ligne hôte SOCKS(si vous avez suivi le tuto putty). Attention de ne rien mettre sur les autres lignes (proxy http par ex)
  • indiquer aussi le DNS. Dans la barre d’url taper about:config, et passez le paramètre network.proxy.socks_remote_dns à true
    Pour vous faciliter la vie, vous pouvez installer le plugin proxy selector pour passer rapidement d’une configuration à l’autre

[size=150]L’astuce dans l’astuce:[/size]
Récupérer les infos du proxy utilisé sur le réseau du client n’est pas toujours simple (scripts de configuration auto …).
L’astuce qui marche dans tout les cas.

  • fermer le navigateur
  • attendre quelques minutes que toutes les connexions soient bien closes
  • dans une fenêtre de commande DOS (cmd) faire un:
  • ouvrir une seule page web avec un navigateur. Prendre une page la plus dépouillé possible, qui ne fais pas appel à des images stockées sur un serveur externe par ex. Un bon candidat: la page de recherche de google
    refaire la même commande, et chercher les écarts …

[size=150]transfert de fichier:[/size]
Pour utiliser votre tunnel afin de transférer des fichiers, je vous recommande le client WinSCP pour windows. Il s’interface très bien avec putty. A n’installer qu’une fois votre putty configurer et valider. L’installeur de WinSCP va récupérer automatiquement vos profils de connexion putty

#2

Si le DSI n’est pas ignorant ou feignant, je pense qu’il a fortement limité les ports accessibles vers l’extérieur, grosso modo il a dû laisser le port 80 (http) et 443 (https). Le tout géré par un domaine Windows et donc une authentification NTLM, non ?
Une solution que je met rapidement et facilement en place est de “cacher” un serveur SSH derrière le port 443 sur une machine que j’héberge. Une fois la liaison SSH établi tu peux faire ce que tu veux (IRC, Web, FTP, etc.).
Voilà le tuto qui m’a grandement aidé a cette mise en place:
michauko.org/blog/tunnels-tcp-vi … y-etc-181/

#3

Merci mimoza pour ce lien , tuto très bien fait.
Je pense effectivement que seul les ports 80 et 443 sont ouverts.
J’ai d’ailleurs bien du mal à obtenir de infos sur le proxy de la boite (adresse:port)
Cette solution est justement celle que je voudrais éviter, car je ne pense pas qu’elle fonctionne sur un mutualisé (ma connexion adsl est bien pourrie).
Je voyais plutôt un une connexion sur une adresse de proxi en https, qui semblerait légitime au proxy de la boite. Et à partir de là, rebondir sur les sites qui m’intéressent.

#4

Pourquoi est-ce posté dans T&A ?

#5

[quote=“Mimoza”]Si le DSI n’est pas ignorant ou feignant, je pense qu’il a fortement limité les ports accessibles vers l’extérieur, grosso modo il a dû laisser le port 80 (http) et 443 (https). Le tout géré par un domaine Windows et donc une authentification NTLM, non ?
Une solution que je met rapidement et facilement en place est de “cacher” un serveur SSH derrière le port 443 sur une machine que j’héberge. Une fois la liaison SSH établi tu peux faire ce que tu veux (IRC, Web, FTP, etc.).
Voilà le tuto qui m’a grandement aidé a cette mise en place:
michauko.org/blog/tunnels-tcp-vi … y-etc-181/[/quote]
C’est à peu près ce que je fais, mis à part que j’utilise un proxy socks. J’aimerais bien un jour passer à OpenVPN ce qui me permettrait d’outre passer les proxy de manière transparentes pour mon système et d’avoir sur mon serveur des services disponibles uniquement depuis le réseau privé (et ça c’est cool).

#6

Ricardo,
je l’ai mis dans T&A car rien n’indique pour le moment que ça se terminera sur une debian (si choix du serveur mutualisé).
c’est plus la recherche d’une astuce pour contourner des restrictions devenues trop contraignantes, à la limite du ridicule.
J’ai modifié le titre en conséquence.

#7

Salut piratebab !

Je vois que tu es nouveau sur ce forum, ce qui explique ton erreur : la section T&A sert à donner des trucs et astuces, pas à en demander.
Pour les demandes d’aide, d’astuces ou de conseils, les sections Support Debian et Pause Café sont à ta disposition :wink:

Un de nos courageux modérateurs va sûrement déplacer cette discussion dans la section appropriée :mrgreen:

#8

En effet il parait difficile de mettre ça en place sur un mutualisé.
Sinon une solution simple est de mettre en place un proxyWeb tel que phproxy, ce n’est pas parfait et bien limité mais ça peut dépanner et palier au «petit» manque

#9

J’espère bien que ça va déboucher sur une truc et astuce utile à plein de monde!
En attendant, voici une astuce pour faire ce que je veux me semble t il :
korben.info/creer-un-serveur-proxy.html

#10

Le principe c’est de faire passer le SSH par le port HTTPS (443) vu que le port standard (22) est souvent bloqué, vers ton serveur @home (ou un VPS) sur lequel tu aura configuré un proxy web, genre tinyproxy.

(Y’a des tas de tutos sur le web)

Sinon y’a aussi les proxy web en php comme déjà signalé (genre oranjeproxy, etc…) mais c’est bien moins performant/fiable suivant les sites web visités.

#11

Salut,

Mais dans ce cas vous bernez le proxi de votre boîte mais aussi le responsable du système et votre patron, non ?

#12

En effet. Sans parler des sanctions disciplinaires pouvant aller jusqu’au licenciement pour faute, il y a des boîtes un peu sensibles où ce genre d’acte est passible de poursuites pénales, avec lourdes amendes et prison à la clé.

#13

c’est le jeux ma pov’ lucette je dirais.
Mais par moment, je n’y comprends pas grand chose aux règles de filtrage:
ex, on a accès depuis nos postes à “le monde”, “l’équipe”, mais pas “le figaro”,ni “le parisien”…
Si on a un besoin particulier (un site avec des infos précises / techniques), on peut demander l’inscription en liste blanche… ce qui prend au mini 24h. Inscription réalisé par un admin parmis des centaines, qui ne connait rien à notre taf et donc à nos besoins et la réponse (si elle arrive 24h aprés) oblige à refaire une autre demande, et blablbla… bilan, 2 mois plus tard, tu n’as toujours pas accès à tes données.
Donc, qu’est ce que tu fais:
tu bidouilles pour passer outre: tu utilises ton smartphone en partage de connexion, tu passes par un proxyphp, tu importes tes fichiers via clé usb etc…
bref, au lieu d’arriver à une politique de sécurité on en arrive à créer une passoire.
Certains admin ont été plus malins:
carte blanche sur le net (hormis les xxx et associés), accès au webmail… MAIS à la moindre chose louche l’employé en prend pour son grade (c’est clair et net). Donc au final, tout le monde fait gaffe et s’autolimite. Sans compter que le débit vers les sites “non reconnus” est réduit (pas du 56k non plus).
D’autres limites les accès sur des plages horaires et autorisent un accès libre sur certaines plages (entre midi et 14h par ex).

Pour ma part, c’est du ssh en 443…

#14

Justement, où placer la limite ?
Pourquoi interdire le porno et pas Facebook ?
Pourquoi j’ai accès à GMail mais pas à mon serveur auto-hebergé ?

C’est le boulot de l’admin de la boîte de poser ces limites, et ça me paraît une bien meilleure idée de le contacter en cas de problème plutôt que de tenter de passer outre le pare-feu de la boîte.

#15

C’est de la théorie plus que de la pratique comme tout le droit qui touche de près ou de loin à ça.
Ces règles sont souvent idiotes car elles sont créée pour tenter de bloquer des choses tout à fait inutiles c’est à dire soit des choses qui sont de toutes manière illégales, soit des choses que si les employés ne font pas avec leur ordinateur de travail, ils le font avec leur smartphone de manière intraçable et tout à fait légal.

Dans les faits si tu ne fait pas n’importe quoi avec ce genre de connexion (usage pour des choses légales et utilisation raisonné du débit) tu ne risque rien.

Je ne pense même pas qu’une entreprise puisse réellement licencier pour ça. Elle a un éventail d’action possible avant et il lui sera reprocher de ne pas l’avoir utilisé. Il faudrait vraiment que ce soit une faute grave (partage de secret de l’entreprise, activité illégale,…) pour que ce soit aussi direct.

Pour donner une anecdote, je viens de quitter une entreprise qui soustraite la gestion de son réseau et la mise en place d’un proxy filtrant. Ce proxy est évidement trop limitant. Je l’ai outre passé pendant 3 ans (ils ne bloque pas les connexions SSH sur le port 22), résultat j’avais des débits drastiquement supérieurs à ceux de mes collègues. Pour télécharger des logiciels dont ils avaient besoin pour leur boulot je mettais 10minutes là où ça leur prenait plusieurs heures (je n’exagère pas). Dans ce genre de condition, j’avais aucun problème pour aller devant les prud’hommes expliquer pourquoi j’ai mis en place ce contournement (on est proche du sabotage de la part du sous-traitant…). A coté de ça le sous-traitant facture le whitelistage de domaine. Très franchement je l’attendais celui qui viendrait me voir pour me parler de ça.

#16

Je respecte depuis des années les régles de filtrage, même si elles sont de plus en plus contraignantes, et pénalisante parfois.
Mais le coup du spam et de spamhaus, c’est la goutte d’eau qui a fait débordé la carafe. J’ai commencer par remonter le problème du spam via le service info, avec tout les détails du virus incriminé. Mais au bout de plusieurs mois, leur IP publique est toujours considérée comme un ip spamante.
trop c’est trop.
Qu’ils fassent leur boulot et traquent les spammeur interne, et qu’ils me laisse réguler mon accés au web.
J’ai de toute façon refusé de signer la charte informatique qui est complètement débile, et impossible à respecter si on veut bosser efficacement.

#17

Contourner les mesures de sécurité mises en place, c’est déjà faire n’importe quoi.
Les conséquences même involontaires peuvent être désastreuses. Cf. Stuxnet en Iran.

#18

Aucun des proxy que j’ai rencontré n’auraient pu faire grand chose à ce sujet (blocage de mots clef, ça ne sert à rien contre une attaque spécifique). Aucune mais alors vraiment aucune entreprise que j’ai pu rencontré ou dont on m’a parlé n’avait la moindre politique de sécurité (mise en place de règles pour les supports amovibles (parce Stuxnet c’est ça, c’est une clef usb infecté rien à voir avec un quelconque proxy idiot) ? informations des employés quant à la sécurité ? Organisation et hiérarchisation des documents en fonction d’un niveau de sécurité (mise en place de chiffrement/signature par exemple) ? Cloisonnement des données/réseau ? Gestion des courriels ? RIEN, il n’y a absolument RIEN même au CEA par exemple). Au contraire, bien souvent, c’est aux employés d’expliquer à leur supérieur que non tel ou tel données fait partie de la valeur ajouté de l’entreprise et qu’il ne faut pas la transmettre (en fait si les grandes entreprises savent très bien cacher une donnée hyper-importante : les organigrames. Généralement ils cachent ça tellement bien que les employés y ont difficilement accès). Tu peux trouver un tas de rapports qui parle de la pauvreté du domaine en France. Ce n’est absolument pas le fait d’interdire n’importe quoi ou le débit des utilisateurs qui va changer quoi que ce soit. Au contraire les proxy TLS qui déchiffrent les connexions et les rechiffre à la volé (en ayant configuré les clients pour accepter une autorité de l’entreprise) peuvent être plus dangereux qu’autre chose. Certains proxies, largement sous-dimensionnés, sont carrément à la limite du DOS lors de l’utilisation normal par les employés !

En réalité si quelqu’un veut s’attaquer à une entreprise (du moins en France), ce n’est pas le proxy de l’entreprise qui y ferra grand chose

Parler de sécurité comme ça, c’est se moquer de la gueule du monde et plus particulièrement de ses employés.

#19

avec kali en changeant simplement votre adresse mac ,

en second avec le smartphone transformer en point wifi

#20

je n’ai qu’un abonnement minimum sur mon smartphone, pas possible d’en faire un point wifi.
L’utilisation de kali n’est pas des plus pratique sur un poste de travail (reboot …)