Sécurité internet : un "cas d'école"

Réseaux & telecom
1

Bonjour à tous,

Je suis gestionnaire d’un réseau en Haute Ecole (parc d’environ 200 machines pour les étudiants et le personnel) et qu’il faut encadrer un minimum pour éviter les dérives possibles que vous imaginez (accès aux réseaux sociaux pendant les cours, tentatives de téléchargements, etc …). L’OS du parc est « tout Windows » pour les serveurs et clients (comme je suis seul à tout gérer, je ne dispose pas vraiment de temps pour m’investir sur du Linux). Jusqu’ici, les routeurs utilisés (nous sommes en sites multiples) étaient gérés par le FAI, qui appliquait un filtrage global plus ou moins abouti. Nos lignes Internet vont cependant évoluer assez grandement en 2015, en terme de bande passante, et je dois gérer désormais directement l’accès à ces ressources (définir des règles, filtrer des contenus, etc … ce qui est une “première” complète pour moi).

Après pas mal de recherches, Squid s’est imposé comme un choix intéressant à retenir (version Windows, bien sûr).
Après pas mal de lectures, il m’a semblé plus judicieux de faire transiter tout le trafic Internet par un serveur réservé à cela (Squid proxy sur Windows Server 2012). J’ai donc effectué mon câblage de la sorte (serveur proxy à deux cartes réseau) :

http://img4.hostingpics.net/thumbs/mini_671111ProxyServerv01.jpg

De cette manière, je suis certain que toutes les requêtes vers l’extérieur doivent être validées avant d’atteindre la passerelle (qu’elles proviennent d’ordinateurs “Haute Ecole”, d’appareils connectés au Wifi, ou encore de clients qui tentent de se ponter directement sur la câblage réseau de l’établissement)
Squid fonctionne parfaitement pour l’HTTP et l’HTTPS, mais je suis confronté au souci des autres types de trafic, principalement la messagerie (POP3, IMAP, SMTP) qui échoue systématiquement à établir une connexion à travers Squid (en envoi ou réception). J’ai bien compris que ce soit normal : Squid n’est pas prévu pour gérer les paquets autres que http, HTTPS ou FTP. Néanmoins il me faut trouver une solution… Mes recherches ne m’en donnent apparemment que deux :

SOLUTION 1 : je maintiens mon architecture tel quelle, et il me faut trouver un moyen de dériver le traffic Internet “hors HTTP/HTTPS”, adressé sur l’interface entrante du serveur (192.168.100.1), vers son interface sortante (192.168.1.2, afin de passer par la passerelle sans que Squid le gère). Le problème est comment ? On trouve plein de solutions sur Squid Linux, au départ d’IPTABLES (qui n’existe pas sur Windows, et je trouve difficilement le soft/commande correspondant)

SOLUTION 2 : je modifie le positionnement du serveur sur le réseau (il ne dispose alors plus que d’une carte réseau) et devient un client comme les autres sur le LAN, qui ne gère que les paquets provenant des navigateurs de l’ensemble des ordinateurs (configurés pour surfer au départ d’un proxy). Tout le reste du trafic continue à sortir directement sur la passerelle, et ça marche. Le souci, c’est comment restreindre le trafic non souhaité (peer2peer principalement), et aussi empêcher les navigateurs des machines non gérées (portables étudiant, conférenciers,…) d’outrepasser le proxy en se dirigeant directement sur la passerelle ?

Merci pour vos conseils !
Edité le 09/12/2014 à 09:51

2

Bonjour,

Déjà merci d’avoir fait l’effort de tout bien détailler ça aide à la compréhension.

Tu pourrais rester en solution1 et imposer l’utilisation des webmails pour relever les mails.
Ca peut être une contrainte pour les utilisateurs mais cela résout ton problème sans avoir à changer quoi que ce soit et puis en terme de sécurité + entretient de ton parc ça peut être un plus (machines plus résilientes aux virus si elles n’utilisent pas de client lourd de messagerie + pas de stockage de mail pas de consommation d’espace disque).

En solution2 tu peux faire comme tu l 'indiques mais du coup il manque effectivement un firewall (de préférence matériel) en amont de ton réseau pour bloquer le trafic non souhaité.

En espérant t’avoir éclairé.

Tchuss

3

Bonjour Seb,

Merci pour tes réponses.
Concernant la partie mail, j’ai déployé Thunderbird pour essayer d’alléger les applis de messagerie (au lieu d’Outlook Office), et j’ai placé mes clients en IMAP pour limiter la consommation d’espace, comme tu le suggères. J’avais pensé à ta solution webmail : pourquoi ne pas profiter que le trafic HTTP passe correctement sur le proxy pour tout solutionner en un coup. Il y a cependant des outils qui nous sont nécessaires et dont disponsent un “vrai” client mail, ce qui n’est pas toujours le cas des interfaces web (je pense à l’archivage et ses options, la possibilité de disposer d’une copie locale synchronisée, les règles d’insertion automatique “évoluées”…).

Après quelques recherches supplémentaires, je pense me diriger vers la solution 1 (LAN câblé directement sur proxy server, passerelle non détectable derrière) et configurer les deux cartes du proxy (LAN et WAN) pour qu’elles transitent le trafic entre elles au départ de la commande ROUTE pour tout ce qui est non-HTTP (la messagerie passe donc en dehors du proxy Squid). Les navigateurs en local sont réglés sur le proxy (donc le filtrage Internet est assuré), et définir enfin sur la passerelle des règles de firewall pour empêcher toute tentative directe de trafic sortant sur le port 80/8080 et sur les ports traditionnellement utilisés pour le peer2peer.

Je vous tiens au courant (ça pourra peut-être être utile à quelqu’un, car il y a peu de solutions complètes de proxy au départ de Squid utilisé sur un réseau Windows) …

4

Hello,

Alors où en es tu ?

5

Salut Seb,

Eh bien …, je continue encore les recherches (!).

Tout ce que j’ai lu dernièrement me conforte dans l’idée que la solution finale passera bien par un routage direct de carte réseau à carte réseau sur le proxy, afin de laisser transiter au travers du proxy, et de façon transparente, le trafic “accepté” (la messagerie essentiellement) et bloquant le reste (sauf l’HTTP/HTTPS qui sera filtré par Squid sur le proxy). Pour cela, j’ai passé du temps à tenter ce routage au départ de la commande ROUTE, mais c’est pour découvrir que cette procédure nécessite aussi une configuration équivalente sur chaque client (ce que je ne cherche pas à obtenir, vu que je dois gérer aussi le trafic de machines personnelles qui n’appartiennent à l’étabissement, mais utilisent néanmoins son réseau).

Je suis pour le moment en train d’essayer de résoudre ce problème de routage au départ de RRAS (qui est un rôle à activer sur le serveur, permettant la gestion des accès à distances et routage des paquets au départ d’une config à doubles cartes réseau). Je vous tiens au courant (après les deux semaines de fermeture de Noël) …

6

Bonjour,
Squid peut autoriser ou refuser les protocoles de messagerie. Peut-être êtes vous passé à côté de l’option ?

7

Bonjour Spunamo,

Je ne me souviens pas d’avoir vu cette option quelque part, en effet.

Es-tu sûr de cette information ? (je me permets de te poser la question car j’ai remarqué dans tous les forums que j’ai parcourus qu’on insistait bien sur le fait que Squid n’était qu’un proxy HTTP, et qu’il était inutile de chercher à faire transiter/filtrer par cette application des paquets non HTTP/HTTPS (sauf bien sûr de la messagerie connectée sur une webmail, mais ce n’est pas ce je recherche, puisque les clients de mon parc se connectent à leur mail par un programme dédié (Outlook Office, Mozilla Thunderbird))

8

Bonjour,

Tu m’as l’air de faire compliqué, si tu ne peux pas mettre en place un firewall matériel configure un pc qui fera office de passerelle dessus tu configures des règles firewall pour interdire tout les trafic excepté http/https/pop3/IMAP/MAPI et tu devrais etre bon nan ?

9

Bonsoir,

En indiquant à Squid que les ports de messagerie sont des ports dits “safe” comme ceci :
acl Safe_ports port 25 # smtp
acl Safe_ports port 110 # POP

Ces commandes sont à placer dans le fichier de conf. de Squid. Sous Linux ça se passe comme ça en tout cas et ces lignes sont valables. Mais sous Windows, difficile de trouver de la doc pour Squid …

(Je ne suis sûr de rien !)
Edité le 05/01/2015 à 18:44