Proxy

De Justine's wiki
Aller à la navigation Aller à la recherche

Introduction aux proxies

Proxy signifie, de façon littérale en anglais, "on behalf of", soit "par procuration" : un serveur proxy est simplement un serveur qui effectue des requêtes pour quelqu'un d'autre. On traduit parfois le terme en français par "Serveur Mandataire". Ils servent en général d'intermédiaire entre le réseau interne et l'extérieur; il pourra être placé dans la DMZ.

Utilité

Le rôle premier d'un proxy est de partager l'accès aux réseaux internes (le plus souvent, il s'agit d'Internet). Les proxies sont des intermédiaires entre les utilisateurs du réseau interne et l'extérieur. Pour les serveurs externes, toutes les requêtes sembleront émaner d'une seule et même machine, le proxy. À première vue, cela ressemble beaucoup à un routeur ! Mais un proxy a d'autres vocations :

  • Rationnaliser la bande passante : c'est la fonction de cache
  • Contrôler les accès
  • Compresser les données
  • Anonymiser les données
  • Pour les particuliers, il peut servir à contourner certains filtrages d'état (en Chine, par exemple).

Principe de fonctionnement

Le fonctionnement de base est simple, c'est un serveur qui relaie les requêtes et renvoie les réponses aux clients. Ainsi, pour une application donnée qui utilise le proxy, le client ne s'adresse qu'au proxy, celui-ci relayant les requêtes et les réponses.

La fonction Cache

Un des avantages du proxy est de fournir un cache de données : il garde en mémoire les pages visitées et les ressert aux clients. Ce mécanisme sert à limiter les besoins en bande passante. Dans ce cas, aucune connexion vers l'extérieur n'est établie.

La fonction de contrôle d'accès

Les proxies sont capables d'appliquer des règles de contrôle d'accès, généralement appellées ACL (Access Control Lists), permettant de bloquer l'accès à certaines ressources. Le filtrage peut être appliqué en fonction de la source, de la destination, ou bien du protocole; les proxies peuvent aussi identifier les utilisateurs ou les machines sources, afin de contrôler qui accède à quoi. Ils peuvent interroger des services d'annuaire afin d'appliquer des règles de filtrage basées sur des groupes d'utilisateurs / de machines. En cas d'interdiction d'accès, on peut renvoyer un message d'erreur avec une explication, ou bien même une autre ressource.

Quels protocoles utilisent des proxies?

Les proxies peuvent être utilisés par différentes applications, mais il en existe différentes sortes :

  • HTTP/HTTPS
  • IMAP
  • SSH
  • FTP
  • SIP
  • ARP
  • etc...

Il existe également des proxies utilisant le protocole SOCKS, qui permet d'encapsuler à peu près n'importe quoi.

<pdf>Fichier:ProtocoleSocks.pdf</pdf>

Présentation des proxies web

Les proxies web sont les plus répandus. De base, ils servent à relayer les requêtes HTTP et HTTPS des applications clientes configurées pour le proxy. Mais ils peuvent cependant servir aussi à :

  • Faire de la mise en cache
  • Contrôler les accès
  • Authentifier les clients
  • Compresser les données
  • Gérer l'anonymat
  • Loguer les connexions

La durée de mise en cache des données est définie dans la configuration du proxy.

Authentification des clients

Si l'authentification des clients est requise, les utilisateurs devront se connecter avant de pouvoir accéder aux ressources web. Cela peut se faire selon différentes méthodes :

  • NTLM/SMB : Authentification transparente pour les postes Windows du domaine (Windows NT ou Samba3). Les informations de session sont utilisées pour l'authentification auprès du proxy; les comptes sont stockés sur le contrôleur de domaine.
  • Kerberos / NTLM : Autre type d'authentification transparente pour les poste Windows du domaine Active Directory ou Samba4. Les comptes sont stockés là aussi sur le contrôleur de domaine.
  • Authentification LDAP : Les comptes sont stockés dans un annuaire LDAP/OpenLDAP.
  • Authentification MySQL : Les comptes utilisateurs sont stockés dans une base de données MySQL.
  • Authentification Locale : Les comptes utilisateur sont stockés dans un fichier local ou dans la base d'utilisateurs locaux.

Les informations de connexion seront demandées à l'utilisateur si celles-ci ne peuvent pas être récupérées; le proxy renverra une erreur HTTP 407 (Proxy Authentication Required) si l'utilisateur n'est pas authentifié.

Types de proxies pour le web

Il existe différents types de proxies pour HTTP/HTTPS :

  • Les proxies classiques, avec lesquels les clients doivent être configurés pour utiliser le proxy
  • Les proxies transparents : Pas de configuration côté client, mais il nécessite un peu de configuration de la part des administrateurs réseaux. La passerelle ne doit pas accepter les paquets sur les ports 80/443 mais rediriger vers le proxy.
  • Les reverse-proxies : Ces proxies permettent d'accéder à des serveurs du réseau local depuis Internet : ils agissent dans le sens inverse des proxies classiques.

À partir d'ici, on parlera de proxies classiques.

Configuration des clients

En mode classique, les applications clientes doivent être configurées pour utiliser le proxy. Le port généralement utilisé pour HTTP/HTTPS est TCP 8080, bien qu'on puisse prendre n'importe quel port > 1023 (Squid utilise par défaut TCP 3128). On a plusieurs méthodes pour configurer les clients :

  • Configuration manuelle : Le nom d'hôte ou l'adresse IP et le port doivent être renseignés dans l'application cliente. Les IP ou domaines à exclure sont à préciser manuellement, et on ne pas utiliser plusieurs proxies de façon native.
  • Configuration automatique : l'url du fichier .PAC (Proxy Auto Config) doit être renseignée. Les clients récupèreront les paramètres de configuration automatiquement. Si le fichier est introuvable, la plupart des clients fonctionnent en mode DIRECT, c'est-à-dire sans proxy.
  • Détection Automatique : il s'agit du WPAD, soit Web Proxy Auto Discovery. Pour cette méthode, il faudra :
    • Un serveur http nommé wpad.<mon_domaine.tld>, en mesure de fournir un fichier proxy.pac ou wpad.dat.
    • Pour que le client trouve ce fichier, plusieurs choix :
      • Une option spécifique envoyée au client DHCP
      • Une résolution DNS.

Lorsque les clients sont configurés pour utiliser le proxy, ils n'effectuent plus les requêtes DNS pour les sites visités (c'est le proxy qui s'en charge).

Les fichiers de configuration automatique

On peut créer un fichier de configuration du proxy pour les clients afin de centraliser la gestion des clients. Ce fichier est hébergé sur un serveur web et les logiciels client doivent être configurés pour utiliser l'url du fichier .pac pour la configuration automatique. L'url est sous la forme protocole://monsite.mondomaine/ (par exemple : http://proxy.config.mondomaine/proxy.pac).

Le fichier .PAC permet de définir plus en détails le comportement du client : on peut ainsi choisir d'utiliser tel ou tel proxy en fonction du site web, voire même indiquer un proxy de secours. Le fichier .PAC est écrit en JavaScript, mais seules quelques fonctions sont disponibles. La plupart des navigateurs ira chercherpar défaut la fonction FindProxyForUrl(). L'inconvénient majeur des fichier .PAC est l'absence de confiance en l'adresse IP source de l'expéditeur.

Exemple pour firefox v47

Pour Firefox, la configuration se fait par le menu Options > Avancé > Réseau. Il faut ensuite modifier les paramètres de connexion puis spécifier l'adresse de configuration automatique du proxy avec le port.

Exemple de fichier .PAC

/**

 * Exemple extrait du site http://findproxyforurl.com/example-pac-file/

 **/

function FindProxyForURL(url, host) {
    // If the hostname matches, send direct.
    // Si le domaine est intranet.domain.com OU
    // Si le domaine est abcdomain.com
    // On renvoie DIRECT (= connexion directe sans proxy)
    if (dnsDomainIs(host, "intranet.domain.com") ||
        shExpMatch(host, "(*.abcdomain.com|abcdomain.com)"))
        return "DIRECT";
   
    // If the protocol or URL matches, send direct.
    // Si protocole = FTP OU url commence par http://abcdomain.com/folder/
    // On renvoie DIRECT
    if (url.substring(0, 4)=="ftp:" ||
        shExpMatch(url, "http://abcdomain.com/folder/*"))
        return "DIRECT";

    // If the requested website is hosted within the internal network, send direct.
    // Si le site demande est heberge sur le reseau local, on renvoie DIRECT
    if (isPlainHostName(host) ||
        shExpMatch(host, "*.local") ||
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
        isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0") ||
        isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0") ||
        isInNet(dnsResolve(host), "127.0.0.0", "255.255.255.0"))
        return "DIRECT";

    // If the IP address of the local machine is within a defined
    // subnet, send to a specific proxy.
    // Pour les clients du reseau 10.10.5.0/24,
    // On renvoie le proxy specifique a utiliser d'IP:PORT 1.2.3.4:8080
    if (isInNet(myIpAddress(), "10.10.5.0", "255.255.255.0"))
        return "PROXY 1.2.3.4:8080";

    // DEFAULT RULE: All other traffic, use below proxies, in fail-over order.
    // Sinon regle par defaut, on renvoie 2 proxys a utiliser
    // 1- Proxy avec l'IP:PORT 4.5.6.7:8080
    // 2- Proxy avec l'IP:PORT 7.8.9.10:8080
    return "PROXY 4.5.6.7:8080; PROXY 7.8.9.10:8080";
}

 

Toutes les fonctions des fichiers .PAC sont disponibles ici : http://findproxyforurl.com/pac-functions/

Plus d'informations sur les proxies et les trames qu'ils utilisent : http://www.forensicswiki.org/wiki/Proxy_server

 

Présentation de Squid, un proxy HTTP open-source

Squid supporte les protocoles HTTP, HTTPS, FTP et Gopher.

Il propose des fonctions de cache : si la ressource demandée par le client est déjà dans le cache et qu'elle est à jour, il la renvoie directement au client. Sinon, il effectue la requête, mets la réponse dans son cache en plus de la transférer au client, et transmet la réponse au client. Squid permet aussi d'appliquer des ACL, des règles d'authentification des utilisateurs et de filtrage (limitation horaire, limitation en bande passante...). Il fonctionne par défaut en mode classique, mais peut travailler de façon transparente si il est bien configuré.

Installation

Squid s'installe via les repos : 

sudo apt install squid3

On peut ensuite le piloter avec service squid {reload|start|stop|status}.

Quelques commandes

squid3                  # démarre le daemon squid3
squid3 -N               # démarre Squid3 mais pas en mode daemon
squid3 -k check         # vérifie si le fichier de configuration est correct. Seules les erreurs sont affichées, si rien ne s'affiche c'est que tout est OK
squid3 -k reconfigure   # relance Squid en rechargeant la configuration (pas de coupure de service)
squid3 -z               # (re)construit le cache
squid3 -d 99            # démarre Squid en mode debug, utile pour chercher les erreurs (squid3 -X permet aussi un mode debug complet, mais presque trop verbeux)

Configuration de Squid

La configuration se fait via /etc/squid3/squid.conf.

Un exemple de configuration générale, à adapter : 

http_port 3128                                     # port d'ecoute, ici TCP 3128 (c'est le port standard de squid)
coredump_dir /var/spool/squid3
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern -i (/cgi-bin/|\?) 0     0%      0
refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern .               0       20%     4320
cache_dir ufs /var/spool/squid3 100 16 256          # chemin, type et taille du cache
cache_effective_user proxy                          # utilisateur gestionnaire du cache
cache_effective_group proxy                         # groupe gestionnaire du cache
redirect_program /usr/bin/squidGuard                # redirige la transaction a un tiers, ici squidguard

 SquidGard sera vu un peu plus tard dans ce cours.

ACL

Les notions de filtrage seront vues dans un autre chapitre; je détaille ici les règles de filtrage appliquées aux sources, destinations (plages IP, domaines, ports). Le filtrage des URL se fera avec SquidGard.

Les ACL sont les règles que le serveur applique et qui permettent d'autoriser ou non certaines transactions. À noter : les groupes all, manager, localhost, et to_localhost sont prédéfinis.

La syntaxe est la suivante : 

acl aclname acltype paramètre

Exemple à adapter : 

acl reseau_etudiant src 192.168.20.0/255.255.255.0                # plage reseau source nommee 'resau_etudiant'
acl postes_vip src 192.168.100.10-192.168.100.25/255.255.255.0    # plage source nommee 'postes_vip'
acl domaine_upec dstdomain .u-pec.fr                              # domaine de destination .u-pec.fr
acl SSL_ports port 443                                            # https
acl Safe_ports port 70                                            # gopher
acl Safe_ports port 80                                            # http
acl Safe_ports port 210                                           # wais
acl Safe_ports port 1025-65535                                    # ports non-enregistres
acl CONNECT method CONNECT                                        # requete HTTP de type CONNECT

On peut retrouver tous les types d'ACLs ici : http://www.squid-cache.org/Doc/config/acl/

Une fois qu'on créé nos ACL, il faut définir si on les autorise ou non. Il ne faut pas tout autoriser, seulement autoriser ce que l'on souhaite et bloquer tout le reste. La syntaxe est la suivante : 

http_access allow|deny [!]aclname
http_access allow reseau_etudiant        # autorise le groupe 'reseau_etudiant'
http_access allow postes_vip             # autorise le groupe 'postes_vip'
http_access deny !Safe_ports             # interdit tous les ports qui ne font pas partis du groupe Safe_ports
http_access deny CONNECT !SSL_ports      # interdit la methode CONNECT sur les ports qui ne font pas partis du groupe SSL_ports
http_access allow localhost manager      # autorise localhost a gerer le cache
http_access deny manager                 # interdit la gestion du cache pour tous les autres
http_access deny all                     # interdit tout

Le ! signifie "différent de" (équivalent de !=).

Authentification des clients

Squid peut gérer l'authentification des clients de plusieurs façons :

  • AD
  • LDAP
  • Samba
  • Local

Les clients devront alors s'authentifier via une pop-up avant d'utiliser le proxy.

Voir cette page : https://wiki.squid-cache.org/Features/Authentication

Récupérée de « https://wiki.squi.fr/index.php?title=Proxy&oldid=548 »