Recherche de site Web

Configuration du serveur proxy Squid avec accès restreint et configuration des clients pour utiliser le proxy - Partie 5

Un ingénieur certifié Linux Foundation est un professionnel qualifié qui possède l'expertise nécessaire pour installer, gérer et dépanner les services réseau dans les systèmes Linux, et est en charge de la conception, de la mise en œuvre et de la maintenance continue du système. une architecture large.

Présentation du programme de certification Linux Foundation.

Dans la Partie 1 de cette série, nous avons montré comment installer Squid, un serveur de mise en cache proxy pour les clients Web. Veuillez vous référer à cet article (lien ci-dessous) avant de continuer si vous n'avez pas encore installé Squid sur votre système.

  1. Partie 1 – Installer les services réseau et configurer le démarrage automatique au démarrage

Dans cet article, nous allons vous montrer comment configurer le serveur proxy Squid afin d'accorder ou de restreindre l'accès à Internet, et comment configurer un client http ou un navigateur Web pour utiliser ce serveur proxy.

Configuration de mon environnement de test

Serveur Squid
Operating System :	Debian Wheezy 7.5
IP Address 	 :	192.168.0.15
Hostname	 :	dev2.gabrielcanepa.com.ar
Ordinateur client 1
Operating System :	Ubuntu 12.04
IP Address 	 :	192.168.0.104 
Hostname	 :	ubuntuOS.gabrielcanepa.com.ar
Ordinateur client 2
Operating System :	CentOS-7.0-1406
IP Address 	 :	192.168.0.17 
Hostname	 :	dev1.gabrielcanepa.com.ar

Rappelons que, en termes simples, un serveur proxy Web est un intermédiaire entre un (ou plusieurs) ordinateurs clients et une certaine ressource réseau, la plus courante étant l'accès à Internet. En d’autres termes, le serveur proxy est connecté d’un côté directement à Internet (ou à un routeur connecté à Internet) et de l’autre côté à un réseau d’ordinateurs clients qui accéderont au World Wide Web via celui-ci.

Vous vous demandez peut-être pourquoi voudrais-je ajouter un autre logiciel à mon infrastructure réseau ?

Voici les 3 principales raisons :

1. Squid stocke les fichiers des requêtes précédentes pour accélérer les transferts futurs. Par exemple, supposons que le client1 télécharge CentOS-7.0-1406-x86_64-DVD.iso depuis Internet. Lorsque le client2 demande l'accès au même fichier, Squid peut transférer le fichier depuis son cache au lieu de le télécharger à nouveau depuis Internet. Comme vous pouvez le deviner, vous pouvez utiliser cette fonctionnalité pour accélérer les transferts de données dans un réseau d'ordinateurs nécessitant des mises à jour fréquentes.

2. Les ACL (Listes de contrôle d'accès) nous permettent de restreindre l'accès aux sites Web et/ou de surveiller l'accès par utilisateur. Vous pouvez restreindre l'accès en fonction du jour de la semaine, de l'heure de la journée ou du domaine, par exemple.

3. Le contournement des filtres Web est rendu possible grâce à l'utilisation d'un proxy Web auquel les requêtes sont adressées et qui renvoie le contenu demandé à un client, au lieu que le client le demande directement sur Internet.

Par exemple, supposons que vous soyez connecté à client1 et que vous souhaitiez accéder à www.facebook.com via le routeur de votre entreprise. Étant donné que le site peut être bloqué par les politiques de votre entreprise, vous pouvez vous connecter à un serveur proxy Web et lui demander d'accéder à www.facebook.com. Le contenu distant vous est ensuite renvoyé via le serveur proxy Web, contournant ainsi les politiques de blocage du routeur de votre entreprise.

Configuration de Squid – Les bases

Le système de contrôle d'accès du serveur proxy Web Squid se compose de deux composants différents :

  1. Les éléments ACL sont des lignes de directive qui commencent par le mot « acl » et représentent les types de tests effectués sur toute transaction de requête.
  2. Les règles de liste d'accès consistent en une action autoriser ou refuser suivie d'un certain nombre d'éléments ACL, et sont utilisées pour indiquer quelle action ou limitation a à appliquer pour une demande donnée. Elles sont vérifiées dans l'ordre et la recherche dans la liste se termine dès qu'une des règles correspond. Si une règle comporte plusieurs éléments ACL, elle est implémentée sous la forme d'une opération booléenne ET (tous les éléments ACL de la règle doivent correspondre pour que la règle soit une correspondance).

Le fichier de configuration principal de Squid est /etc/squid/squid.conf, qui fait ~5 000 lignes car il comprend à la fois des directives de configuration et de la documentation. Pour cette raison, nous allons créer un nouveau fichier squid.conf avec uniquement les lignes qui incluent des directives de configuration pour notre commodité, en laissant de côté les lignes vides ou commentées. Pour ce faire, nous utiliserons les commandes suivantes.

mv /etc/squid/squid.conf /etc/squid/squid.conf.bkp

Et puis,

grep -Eiv '(^#|^$)' /etc/squid/squid.conf.bkp

OR

grep -ve ^# -ve ^$ /etc/squid/squid.conf.bkp > /etc/squid/squid.conf

Maintenant, ouvrez le fichier squid.conf nouvellement créé et recherchez (ou ajoutez) les éléments ACL et les listes d'accès suivants.

acl localhost src 127.0.0.1/32
acl localnet src 192.168.0.0/24

Les deux lignes ci-dessus représentent un exemple basique d'utilisation des éléments ACL.

  1. Le premier mot, acl, indique qu'il s'agit d'une ligne de directive d'élément ACL.
  2. Le deuxième mot, localhost ou localnet, spécifie un nom pour la directive.
  3. Le troisième mot, src dans ce cas, est un type d'élément ACL utilisé pour représenter respectivement une adresse IP client ou une plage d'adresses. Vous pouvez spécifier un seul hôte par IP (ou nom d'hôte, si une sorte de résolution DNS est implémentée) ou par adresse réseau.
  4. Le quatrième paramètre est un argument de filtrage qui est « alimenté » à la directive.

Les deux lignes ci-dessous sont des règles de liste d'accès et représentent une implémentation explicite des directives ACL mentionnées précédemment. En quelques mots, ils indiquent que l'accès http doit être accordé si la requête provient du réseau local (localnet), ou de localhost. Plus précisément, quelles sont les adresses de réseau local ou d'hôte local autorisées ? La réponse est : celles spécifiées dans les directives localhost et localnet.

http_access allow localnet
http_access allow localhost

À ce stade, vous pouvez redémarrer Squid afin d'appliquer les modifications en attente.

service squid restart 		[Upstart / sysvinit-based distributions]
systemctl restart squid.service 	[systemd-based distributions]

puis configurez un navigateur client sur le réseau local (192.168.0.104 dans notre cas) pour accéder à Internet via votre proxy comme suit.

Dans Firefox

1. Accédez au menu Modifier et choisissez l'option Préférences.

2. Cliquez sur Avancé, puis sur l'onglet Réseau, et enfin sur Paramètres…

3. Cochez la Configuration manuelle du proxy et saisissez l'Adresse IP du serveur proxy et le port où il écoute pour les connexions.

Remarque Que par défaut, Squid écoute sur le port 3128, mais vous pouvez remplacer ce comportement en modifiant la liste d'accès règle qui commence par http_port (par défaut, elle lit http_port 3128).

4. Cliquez sur OK pour appliquer les modifications et vous êtes prêt à partir.

Vérifier qu'un client accède à Internet

Vous pouvez maintenant vérifier que votre client de réseau local accède à Internet via votre proxy comme suit.

1. Dans votre client, ouvrez un terminal et tapez :

ip address show eth0 | grep -Ei '(inet.*eth0)'

Cette commande affichera l'adresse IP actuelle de votre client (192.168.0.104 dans l'image suivante).

2. Dans votre client, utilisez un navigateur Web pour ouvrir un site Web donné (linux-console.net dans ce cas).

3. Sur le serveur, exécutez.

tail -f /var/log/squid/access.log

et vous obtiendrez une vue en direct des demandes traitées via Squid.

Restreindre l'accès par client

Supposons maintenant que vous souhaitiez refuser explicitement l'accès à cette adresse IP client particulière, tout en conservant l'accès pour le reste du réseau local.

1. Définissez une nouvelle directive ACL comme suit (je l'ai nommée ubuntuOS mais vous pouvez la nommer comme vous le souhaitez).

acl ubuntuOS src 192.168.0.104

2. Ajoutez la directive ACL à la liste accès localnet déjà en place, mais en la faisant précéder d'un signe d'exclamation. Cela signifie : « Autoriser l'accès à Internet aux clients correspondant à la directive ACL localnet, sauf à celui qui correspond à la directive ubuntuOS ».

http_access allow localnet !ubuntuOS

3. Nous devons maintenant redémarrer Squid afin d'appliquer les modifications. Ensuite, si nous essayons de naviguer sur n’importe quel site, nous constaterons que l’accès est désormais refusé.

Configuration de Squid – Réglage fin

Restreindre l'accès par domaine et/ou par heure de la journée/jour de la semaine

Pour restreindre l'accès à Squid par domaine, nous utiliserons le mot-clé dstdomain dans une directive ACL, comme suit.

acl forbidden dstdomain "/etc/squid/forbidden_domains"

Où forbidden_domains est un fichier texte brut contenant les domaines auxquels nous souhaitons refuser l'accès.

Enfin, nous devons accorder l'accès à Squid pour les requêtes ne correspondant pas à la directive ci-dessus.

http_access allow localnet !forbidden

Ou peut-être voudrons-nous autoriser l'accès à ces sites uniquement à une certaine heure de la journée (10h00 à 11h00) uniquement le lundi (M), Mercredi (W) et Vendredi (F).

acl someDays time MWF 10:00-11:00
http_access allow forbidden someDays
http_access deny forbidden

Sinon, l'accès à ces domaines sera bloqué.

Restreindre l'accès par authentification de l'utilisateur

Squid prend en charge plusieurs mécanismes d'authentification (Basic, NTLM, Digest, SPNEGO et Oauth) et assistants (base de données SQL, LDAP, NIS, NCSA, pour n'en nommer que quelques-uns). Dans ce tutoriel, nous utiliserons l'authentification de base avec NCSA.

Ajoutez les lignes suivantes à votre fichier /etc/squid/squid.conf.

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/passwd
auth_param basic credentialsttl 30 minutes
auth_param basic casesensitive on
auth_param basic realm Squid proxy-caching web server for Tecmint's LFCE series
acl ncsa proxy_auth REQUIRED
http_access allow ncsa

Remarque : Dans CentOS 7, le plugin NCSA pour squid se trouve dans /usr/lib64/squid/basic_nsca_auth, alors changez en conséquence dans la ligne ci-dessus.

Quelques précisions :

  1. Nous devons indiquer à Squid quel programme d'aide à l'authentification utiliser avec la directive auth_param en spécifiant le nom du programme (très probablement, /usr/lib/squid/ncsa_auth ou /usr/lib64/squid/basic_nsca_auth), ainsi que toutes les options de ligne de commande (/etc/squid/passwd dans ce cas) si nécessaire.
  2. Le fichier /etc/squid/passwd est créé via htpasswd, un outil pour gérer l'authentification de base via des fichiers. Cela nous permettra d'ajouter une liste de noms d'utilisateur (et leurs mots de passe correspondants) qui seront autorisés à utiliser Squid.
  3. credentialsttl 30 minutes nécessitera la saisie de votre nom d'utilisateur et de votre mot de passe toutes les 30 minutes (vous pouvez également spécifier cet intervalle de temps en heures).
  4. sensible à la casse activé indique que les noms d'utilisateur et les mots de passe sont sensibles à la casse.
  5. realm représente le texte de la boîte de dialogue d'authentification qui sera utilisée pour s'authentifier auprès de Squid.
  6. Enfin, l'accès n'est accordé que lorsque l'authentification proxy (proxy_auth REQUIRED) réussit.

Exécutez la commande suivante pour créer le fichier et ajouter les informations d'identification de l'utilisateur gacanepa (omettez l'indicateur -c si le fichier existe déjà).

htpasswd -c /etc/squid/passwd gacanepa

Ouvrez un navigateur Web sur la machine client et essayez de naviguer vers n'importe quel site donné.

Si l'authentification réussit, l'accès est accordé à la ressource demandée. Dans le cas contraire, l'accès sera refusé.

Utiliser le cache pour accélérer le transfert de données

L'une des caractéristiques distinctives de Squid est la possibilité de mettre en cache les ressources demandées depuis le Web sur le disque afin d'accélérer les futures demandes de ces objets par le même client ou par d'autres.

Ajoutez les directives suivantes dans votre fichier squid.conf.

cache_dir ufs /var/cache/squid 1000 16 256
maximum_object_size 100 MB
refresh_pattern .*\.(mp4|iso) 2880

Quelques précisions sur les directives ci-dessus.

  1. ufs est le format de stockage Squid.
  2. /var/cache/squid est un répertoire de niveau supérieur dans lequel les fichiers de cache seront stockés. Ce répertoire doit exister et être accessible en écriture par Squid (Squid ne créera PAS ce répertoire pour vous).
  3. 1000 est la quantité (en Mo) à utiliser sous ce répertoire.
  4. 16 est le nombre de sous-répertoires de 1er niveau, tandis que 256 est le nombre de sous-répertoires de 2e niveau dans /var/spool/squid.
  5. La directive maximum_object_size spécifie la taille maximale des objets autorisés dans le cache.
  6. refresh_pattern indique à Squid comment gérer des types de fichiers spécifiques (.mp4 et .iso dans ce cas) et pendant combien de temps il doit stocker le fichier demandé. objets en cache (2880 minutes=2 jours).

Les premier et deuxième 2880 sont respectivement les limites inférieure et supérieure de la durée pendant laquelle les objets sans délai d'expiration explicite seront considérés comme récents et seront donc servis par le cache, tandis que 0 % est le pourcentage de l'âge des objets (temps écoulé depuis la dernière modification) selon lequel chaque objet sans heure d'expiration explicite sera considéré comme récent.

Étude de cas : télécharger un fichier .mp4 depuis 2 clients différents et tester le cache

Le premier client (IP 192.168.0.104) télécharge un fichier 71 Mo .mp4 en 2 minutes et 52 secondes.

Le deuxième client (IP 192.168.0.17) télécharge le même fichier en 1,4 seconde !

En effet, le fichier a été servi à partir du cache Squid (indiqué par TCP_HIT/200) dans le deuxième cas, par opposition à la première instance, lorsqu'il a été téléchargé directement depuis Internet (représenté par TCP_MISS/200).

Les mots clés HIT et MISS, ainsi que le code de réponse 200 http, indiquent que le fichier a été servi avec succès les deux fois, mais que le cache était HIT. et Manqué respectivement. Lorsqu'une requête ne peut pas être traitée par le cache pour une raison quelconque, Squid tente de la traiter depuis Internet.

Conclusion

Dans cet article, nous avons expliqué comment configurer un proxy de mise en cache Web Squid. Vous pouvez utiliser le serveur proxy pour filtrer le contenu en utilisant des critères choisis, et également pour réduire la latence (puisque les requêtes entrantes identiques sont servies à partir du cache, qui est plus proche du client que le serveur Web qui sert réellement le contenu, ce qui entraîne un traitement plus rapide. transferts de données) et le trafic réseau également (réduction de la quantité de bande passante utilisée, ce qui vous permet d'économiser de l'argent si vous payez pour le trafic).

Vous souhaiterez peut-être vous référer au site Web de Squid pour plus de documentation (assurez-vous également de consulter le wiki), mais n'hésitez pas à nous contacter si vous avez des questions ou des commentaires. Nous serons plus qu’heureux d’avoir de vos nouvelles !