Bonjour !!
 
Je me posais des questions concernant les tunnels SSH et la protection d'un réseau.
Sachant que la plupart des protocoles supportent SSH, et qu'on peut configurer un serveur SSH pour écouter sur n'importe quel port, comment faire pour  créer des ACL efficaces ?
Supposons, je veux interdire à mes users d'accéder au HTTP, ou SMTP ou POP ou que sais-je. Je crée les régles adéquates au niveau de mon firewall, règles qui peuvent toutes être contournée via tunnel SSH.
Dès lors, que faire    
 
Merci.

autoriser que certains sites/plage d'adresse IP utiles pour tes users, mais bon c'est contraignant...

tu prends le problème à l'envers..
 
si tu crées une règle du genre:
 
source : le lan interne
destination : mon serveur smtp
protocole : SMTP/ pop
alors les gens ne peuvent pas faire grand chose d'autre!
 
si tu écris par contre:
 
source : le lan interne
destination : "internet"
protocole HTTP
 
il ya maintenant plusieurs axes de réflexion, soit ton "firewall" ne fait que du filtrage au niveau 4, il va regarder port source ip source, port destination ip destination, et il ne regarde pas le contenu du protocole, oui ça va passer ...
 
par contre, si tu fais du controle protocolaire, te permettant de vérifier le protocole , tout autre protocole sera refusé ( protocol enforcement).  les plus strict étant les firewall de type "proxy" mais souffre de performances.
 
y a un truc qui marche bien, installe un IDS en coupure ou en mirror de port, tu verras tous les protocoles et aussi les encapuslations de tes users.

Ok donc y a pas d'autres solutions que d'avoir un firewall qui gère spécifiquement ça...
Par contre concernant ma question, je vois pas la différence entre tes deux règles de firewall.

la différence est que j'ai spécfié une "destination" , ce qui implique que si les gens veulent faire autre chose, ça ne sert à rien car tu "maitrise" ou tu "limite" la destination.. alors que pour "internet" tu ne maitrise rien .."
 
l'autre solution "élégante", est d"utiliser un proxy web.
 
tes utilisateur ont en "dur" ou ( en proxy transparent) une configuration qui pointe vers ton proxy et tu fais une règle de filtage qui dit
 
 
[internet)
  ||
 
[firewall] === [serveur proxy web]
   ||
{lan interne)
 
source : lan interne
destination: proxy web
proto; http
 
souce: proxy web
destination: internet
proto : http
pas de connexion directe depuis le lan vers interne
et filtrage total par ton proxy web ( squid par exemple)
 

Ok.
Mais si tu es obligé de mettre un proxy pour chaque protocole autorisé, c'est ingérable.
Suppose que je veuille autoriser en plus du Http, le smtp, le pop, ica.
Comment t'sé t'y ki fo faire ?

Nous on arrive à tout faire via proxy (HTTP / FTP et serveur Exchange pour les mails).
 
Les postes clients de base n'ont même pas de passerelle comme ça c'est reglé
 
Après pour les machines spécifiques: regles de flux avec source/destination/ports comme ca c'est sur.

les firewal dédiées proxy embarquent jusqu'au 100 type de proxxy .
 
apres tu peux mutualiser sur une seule machine plusieurs proxy ( proxy smtp, http, ..)
 
 
par contre, de l'ica avec internet, pas beau tout ça

C'est pas faux
 

pour revenir a la question initiale ... si tu mets un proxy ou que tu mets une ACL qui donne un acces exterieur sur un port N et que quelqu'un installe sur internet un serveur ssh sur ce port N tu ne pourras pas empeche cette personne de faire ce qu'elle veut sur ce tunnel même avec un contrôle de niveau 7 car le contenu est chiffré
 
c'est à la fois la beauté et la grosse prise de tete pour les admins des tunnels ssh

C'était ça ma question à la base.
Donc la seule solution c'est de tout interdire directement vers le net, et de tout proxyzer

nan ... même si tu mets un proxy qui laisse passer l'http (80) et l'https (443) rien n'empeche de faire du tunnel ssh sur ces ports

Donc que faire ?

Faut relativiser, pour faire ça faut quand meme que tes utilisateurs :
 
- aient quand meme des competences un minimum poussées
- aient les droits pour installer un soft de tunnelling sur leur poste du taf (s'ils les ont, commence par corriger ça avant de t'inquieter de ce qu'ils peuvent faire avec ton proxy...)
- ai un PC accessible depuis le net pour faire l'autre bout du tunnel
 
Et meme avec tout ça c'est pas sans trace ce genre de chose, un mec qui s'amuse a ça y'a toutes les chances de vite reperer pour l'user en question un traffic https anormalement important vers toujours le meme serveur dans les logs de ton proxy.

Si il se met derrière une vmware avec un environement en adressage dynamique, il utilise donc une adresse mac pas référencé dans le parc et on peut pas le retrouver... bon ok je sors
 
Mais c'est clair que ça marche nikel de faire passer un tunnel ssh a travers un proxy http. Avec openvpn on fait ça facilement et d'ailleur le tuto qui m'a permit de tester ça je l'ai trouver ici même.. xD je pense que n'importe quel utilisateur s'interessant au réseau (sans en être un professionnel peut faire de même) et d'ailleur ça m'interesserait aussi de savoir comment contrer ça...

dans le cas des tunnel http/https par exemple il est possible en analysant le contenu de la trame de détecter la signature de certaines applis.
Par contre c'est évidemment assez fastidieux à mettre en place.
 
extrait de labo microsoft :

 
Post originelle :
http://www.forum-microsoft.org/pos [...] 3f50e30b02
 
 
A+

Merci pour l'info, mais il doit y avoir d'autre solution que celle d'utiliser ISA ?

 
   
N'importe qui peut installer Putty non ?

 
Je ne pense pas non...
 
Imagine le cas basique que quasiment toute les boites dont la mienne utilise.
 
 
CLIENT ========> Firewall entrée =======>Proxy Squid:3128=========>Firewall sortie=====>INTERNET
 
Avec cette configuration, on edite une regle sur le firewall entrée qui est :
Accept tout le LAN mais uniquement en destination du port 80 et surtout uniquement en utilisant le protocole http.
(bien sur les client ont proxy:3128 configuré dans leur option)
 
Tu aura beau essayer toutes les options de tunneling, le firewall ne laissera pas passer autre chose que du protocole http et non du SSH...

Et comment font les clients pour effectuer des transactions sécurisées vers internet après ? Avec ta méthode plus de https si je comprend bien.

si bien sur, les seuls connexions authorisées sont http et https via 80 et 443
 
le firewall controle les ports mais aussi le protocole utilisé

effectivement j'avais pas pensé au firewall en entrée cela dit ca doit toujours possible de faire du tunneling mais pas avec des outils standards

oui de toute facon tu pourra toujours faire du tunnelling mais en http...
 
Je l'ai dejà fait pour tester les limites de mon système.
 
tu as un serveur externe dédié avec un petit  squid et qui ecoute sur un port particulier. et tu arrive à tunnellé le tout.

 
Je comprends po
Si le firewall en entrée ne laisse passer que en destination du port 80, les clients pourront même pas se connecter au squid si ?

Si, on configure les postes pour utiliser un proxy sur le port 3128, mais par ce port les postes font passer des requetes qui disent "je veux aller sur machin.com sur le port 80".

Bah oui mais si le firewall entrée bloque tout sauf le port 80... les clients pourront pas se connecter sur le port 3128... j'comprends po    

Ce qui est autorisé entre le LAN et le net et le port utilisé par le proxy côté LAN pour ecouter les requetes des postes clients ce sont 2 choses différentes.

Merci de t'acharner
Le proxy est bien entre les deux firewalls non ?
Donc le client pour se connecter au net doit faire le chemin : firewall entrée, squid, firewall sortie, non ?
Donc comment le client pourra-t-il se connecter sur le port 3128 du squid, si le firewall entrée bloque tout sauf ce qui est à destination du port 80 ?
(c'est cette phrase que je comprends pas :
Avec cette configuration, on edite une regle sur le firewall entrée qui est :
Accept tout le LAN mais uniquement en destination du port 80 et surtout uniquement en utilisant le protocole http.
)
 
 

 
Dans le sceniario ideal, oui.
 

 
Bartounet s'est un peu emellé les pinceaux je pense, faut evidemment que le firewall entre le LAN et le proxy autorise le flux par le port 3128.

Parfait.
Donc on efface mes 3 derniers post
 
Donc 2 firewall avec 1 proxy entre, ça marche, plus de tunnel possible.
Mais c'est quand même vachement contraignant car pour chaque application (smtp, ftp, etc.) il va falloir forcément mettre un proxy entre le client et le net pour "couper" le tunnel... ou alors utiliser un proxy qui fait tout...

Meme pas forcement besoin des 2 firewalls, un proxy qui fait du L7 peut suffire si on s'interesse juste a cet aspect la.

Sisi
On peut faire du tunneling en HTTP, a fortiori si tu autorises le HTTPS (et y'a rarement la possibilité de faire autrement), y'a des softs qui existent pour, genre ça : http://www.htthost.com/.
C'est plus compliqué et tu peux faire moins de chose avec, on voit surtout ça par exemple pour du contournement de blacklists de sites interdits.

A part le HTTP et le FTP que tous les proxy digne de ce nom savent tres bien gérer généralement t'as pas a ouvrir autre chose niveau acces clients...

 
Ca marche comment ce genre de proxy ? il détecte qu'il se passe un truc pas très catholique en L7, et du coup il t'envoie bouler ?
 

 
Je viens de lire, j'ai pas compris le principe
 

 
Toutafé, c'était juste une question "pour la science"

En effet, je n'ai pas tout expliqué
 
Le firewall authorise les requette http venant du lan en direction du port 3128 du proxy

 
C'est surtout qu'il te permet de définir ton filtrage non pas uniquement au niveau des ports, mais vraiment du type de traffic : si tu dis que tu autorise le traffic HTTP en direction du net, c'est pas comme sur un truc plus basique tu disais que tu autorise le port 80 en TCP vers le net, si tu essaies de faire passer autre chose que tu HTTP par le port 80 ce sera bloqué. Selon le produit on peut egalement faire du filtrage stateful.
 

 
En tres tres gros, imagine qu'au taf tu bloque sur ton proxy l'acces au forum HFR.
Sur une machine a l'interieur de ton réseau, un mechant user fout la partie client du bazar, et y spécifie le proxy local, et aussi l'adresse d'un serveur ami distant sur le net qui a la partie serveur, qui peut etre betement hebergé sur on PC a la maison, on va dire sur l'adresse serveurdewarlordz.dyndns.com. L'appli client fait proxy local, le gars va donc configurer son navigateur pour utiliser le soft comme proxy. Quand le mec va ensuite tapper forum.harware.fr dans son navigateur, l'appli client va en fait faire partir vers ton proxy a toi la requete pour le site sous une forme genre http://serveurdewarlordz.dyndns.co [...] ardware.fr, ton proxy n'ayant pas de raison de bloquer ça il va laisser passer ça, le serveur serveurdewarlordz.dyndns.com va recevoir ça, aller chercher la page sur le net par sa propre connexion, et renvoyer le resultat a ton proxy, qui voir renvoyer a la partie client du soft du tunnel, qui renverra ça de façon transparente pour le navigateur.

 
spa mal comme nom de dns  

 
Ah oué, pas mal...
 

 
Oh la vache    
Et là, proxy L7 ou pas.... donc on va dire que quoiqu'il arrive, un mec qui veux accéder au net peut y parvenir... c'esst triste  

C'est pas inparable non plus, si dans le reporting de l'utilisation de ton proxy tu vois qu'un mec a des quantités de traffic elevées vers toujours le meme serveur qui ne correspond a un aucun site justifiant d'y passer ses journées, ça peut te mettre la puce a l'oreille.

Tout à fait

de toute façon la sécurité absolue ça n'existe pas on aura bon interdire quelque chose ... y'aura forcement une brèche quelque part où alors faut complètement isoler le réseau d'Internet  

question subsidiaire :
Quelle est la différence entre un VPN et un Tunnel Sécurisé ?
j'ai du mal à comprendre ...