Procédure

1. Installez le paquetage httpd:

   # dnf install httpd

2. Si vous utilisez firewalld, ouvrez le port TCP 80 dans le pare-feu local :

   # firewall-cmd --permanent --add-port=80/tcp
   # firewall-cmd --reload

3. Activez et démarrez le service httpd:

   # systemctl enable --now httpd

4. Facultatif : Ajoutez des fichiers HTML au répertoire /var/www/html/.

   Note

   Lors de l'ajout de contenu à /var/www/html/, les fichiers et les répertoires doivent être lisibles par l'utilisateur sous lequel httpd s'exécute par défaut. Le propriétaire du contenu peut être soit l'utilisateur root et le groupe d'utilisateurs root, soit un autre utilisateur ou groupe au choix de l'administrateur. Si le propriétaire du contenu est l'utilisateur root et le groupe d'utilisateurs root, les fichiers doivent pouvoir être lus par d'autres utilisateurs. Le contexte SELinux pour tous les fichiers et répertoires doit être httpd_sys_content_t, qui est appliqué par défaut à tout le contenu du répertoire /var/www.

Procédure

1. Installez le paquetage httpd:

   # dnf install httpd

2. Modifiez le fichier /etc/httpd/conf/httpd.conf:

   1. Ajoutez la configuration d'hôte virtuel suivante pour le domaine example.com:

      <VirtualHost *:80>
          DocumentRoot "/var/www/example.com/"
          ServerName example.com
          CustomLog /var/log/httpd/example.com_access.log combined
          ErrorLog /var/log/httpd/example.com_error.log
      </VirtualHost>

      Ces paramètres permettent de configurer les éléments suivants :

      • Tous les paramètres de la directive <VirtualHost *:80> sont spécifiques à cet hôte virtuel.
      • DocumentRoot définit le chemin d'accès au contenu web de l'hôte virtuel.

      • ServerName définit les domaines pour lesquels cet hôte virtuel sert du contenu.

        Pour définir plusieurs domaines, ajoutez le paramètre ServerAlias à la configuration et indiquez les domaines supplémentaires en les séparant par un espace dans ce paramètre.

      • CustomLog définit le chemin d'accès au journal d'accès de l'hôte virtuel.

      • ErrorLog définit le chemin d'accès au journal des erreurs de l'hôte virtuel.

        Note

        Apache utilise le premier hôte virtuel trouvé dans la configuration également pour les requêtes qui ne correspondent à aucun domaine défini dans les paramètres ServerName et ServerAlias. Cela inclut également les requêtes envoyées à l'adresse IP du serveur.

3. Ajoutez une configuration d'hôte virtuel similaire pour le domaine example.net:

   <VirtualHost *:80>
       DocumentRoot "/var/www/example.net/"
       ServerName example.net
       CustomLog /var/log/httpd/example.net_access.log combined
       ErrorLog /var/log/httpd/example.net_error.log
   </VirtualHost>

4. Créez les racines des documents pour les deux hôtes virtuels :

   # mkdir /var/www/example.com/
   # mkdir /var/www/example.net/

5. Si vous définissez des chemins dans les paramètres DocumentRoot qui ne se trouvent pas dans /var/www/, définissez le contexte httpd_sys_content_t sur les deux racines du document :

   # semanage fcontext -a -t httpd_sys_content_t "/srv/example.com(/.*)?"
   # restorecon -Rv /srv/example.com/
   # semanage fcontext -a -t httpd_sys_content_t "/srv/example.net(/.\*)?"
   # restorecon -Rv /srv/example.net/

   Ces commandes définissent le contexte httpd_sys_content_t sur les répertoires /srv/example.com/ et /srv/example.net/.

   Notez que vous devez installer le paquetage policycoreutils-python-utils pour exécuter la commande restorecon.

6. Si vous utilisez firewalld, ouvrez le port 80 dans le pare-feu local :

   # firewall-cmd --permanent --add-port=80/tcp
   # firewall-cmd --reload

7. Activez et démarrez le service httpd:

   # systemctl enable --now httpd

Verification steps

1. Créez un fichier d'exemple différent dans la racine du document de chaque hôte virtuel :

   # echo "vHost example.com" > /var/www/example.com/index.html
   # echo "vHost example.net" > /var/www/example.net/index.html

2. Utilisez un navigateur et connectez-vous à http://example.com. Le serveur web affiche le fichier d'exemple de l'hôte virtuel example.com.
3. Utilisez un navigateur et connectez-vous à http://example.net. Le serveur web affiche le fichier d'exemple de l'hôte virtuel example.net.

Procédure

1. Modifiez le fichier /etc/httpd/conf/httpd.conf et ajoutez les paramètres suivants à la directive <VirtualHost> pour laquelle vous souhaitez configurer l'authentification du client :

   <Directory "/var/www/html/Example/">
     SSLVerifyClient require
   </Directory>

   Le paramètre SSLVerifyClient require définit que le serveur doit valider avec succès le certificat du client avant que ce dernier puisse accéder au contenu du répertoire /var/www/html/Example/.

2. Redémarrez le service httpd:

   # systemctl restart httpd

Verification steps

1. Utilisez l'utilitaire curl pour accéder à l'URL https://example.com/Example/ sans authentification du client :

   $ curl https://example.com/Example/
   curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 **alert certificate required**, errno 0

   L'erreur indique que le serveur web nécessite une authentification par certificat client.

2. Transmettez la clé privée et le certificat du client, ainsi que le certificat de l'autorité de certification à curl pour accéder à la même URL avec l'authentification du client :

   $ curl --cacert ca.crt --key client.key --cert client.crt https://example.com/Example/

   Si la demande aboutit, curl affiche le fichier index.html stocké dans le répertoire /var/www/html/Example/.

Procédure

1. Installez le paquetage httpd-manual:

   # dnf install httpd-manual

2. Facultatif : Par défaut, tous les clients se connectant au serveur HTTP Apache peuvent afficher le manuel. Pour restreindre l'accès à une plage IP spécifique, telle que le sous-réseau 192.0.2.0/24, modifiez le fichier /etc/httpd/conf.d/manual.conf et ajoutez le paramètre Require ip 192.0.2.0/24 à la directive <Directory "/usr/share/httpd/manual">:

   <Directory "/usr/share/httpd/manual">
   ...
       **Require ip 192.0.2.0/24**
   ...
   </Directory>

3. Redémarrez le service httpd:

   # systemctl restart httpd

Verification steps

1. Pour afficher le manuel du serveur Apache HTTP, connectez-vous à l'aide d'un navigateur web à l'adresse suivante http://host_name_or_IP_address/manual/

Procédure

1. Installez le paquetage nginx:

   • Pour installer NGINX 1.20 en tant que version initiale de ce flux d'application à partir d'un paquetage RPM :

     # dnf install nginx

     Note

     Si vous avez précédemment activé un flux de modules NGINX, cette commande installe la version de NGINX à partir du flux activé.

   • Pour installer une version ultérieure de NGINX à partir d'un flux de modules :

     1. Affiche les flux de modules NGINX disponibles :

        # dnf module list nginx
        ...
        rhel-AppStream
        Name        Stream        Profiles        Summary
        nginx       1.22          common [d]      nginx webserver
        ...
        Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

     2. Activer le flux sélectionné :

        # dnf module enable nginx:stream_version

     3. Installez le paquetage nginx :

        # dnf install nginx

2. Ouvrez les ports sur lesquels NGINX doit fournir son service dans le pare-feu. Par exemple, pour ouvrir les ports par défaut pour HTTP (port 80) et HTTPS (port 443) dans firewalld, entrez :

   # firewall-cmd --permanent --add-port={80/tcp,443/tcp}
   # firewall-cmd --reload

3. Activez le service nginx pour qu'il démarre automatiquement lorsque le système démarre :

   # systemctl enable nginx

4. Si nécessaire, démarrez le service nginx:

   # systemctl start nginx

   Si vous ne souhaitez pas utiliser la configuration par défaut, ignorez cette étape et configurez NGINX en conséquence avant de démarrer le service.

Verification steps

1. Utilisez l'utilitaire dnf pour vérifier que le paquet nginx est installé.

   • Dans le cas du paquetage RPM NGINX 1.20 :

     # dnf list installed nginx
     Installed Packages
     nginx.x86_64    1:1.20.1-4.el9       @rhel-AppStream

   • Dans le cas d'un flux de modules NGINX sélectionné :

     # dnf list installed nginx
     Installed Packages
     nginx.x86_64    1:1.22.1-3.module+el9.2.0+17617+2f289c6c    @rhel-AppStream

2. Assurez-vous que les ports sur lesquels NGINX doit fournir son service sont ouverts dans le firewalld :

   # firewall-cmd --list-ports
   80/tcp 443/tcp

3. Vérifiez que le service nginx est activé :

   # systemctl is-enabled nginx
   enabled

Procédure

1. Modifiez le fichier /etc/nginx/nginx.conf:

   1. Par défaut, le fichier /etc/nginx/nginx.conf contient déjà une configuration "catch-all". Si vous avez supprimé cette partie de la configuration, ajoutez à nouveau le bloc server au bloc http dans le fichier /etc/nginx/nginx.conf:

      server {
          listen       80 default_server;
          listen       [::]:80 default_server;
          server_name  _;
          root         /usr/share/nginx/html;
      }

      Ces paramètres permettent de configurer les éléments suivants :

      • La directive listen définit l'adresse IP et les ports que le service écoute. Dans ce cas, NGINX écoute sur le port 80 sur toutes les adresses IPv4 et IPv6. Le paramètre default_server indique que NGINX utilise ce bloc server par défaut pour les requêtes correspondant aux adresses IP et aux ports.
      • Le paramètre server_name définit les noms d'hôtes dont ce bloc server est responsable. La configuration de server_name à _ permet à NGINX d'accepter n'importe quel nom d'hôte pour ce bloc server.
      • La directive root définit le chemin d'accès au contenu web pour ce bloc server.

   2. Ajoutez au bloc http un bloc server similaire pour le domaine example.com:

      server {
          server_name  example.com;
          root         /var/www/example.com/;
          access_log   /var/log/nginx/example.com/access.log;
          error_log    /var/log/nginx/example.com/error.log;
      }

      • La directive access_log définit un fichier journal d'accès distinct pour ce domaine.
      • La directive error_log définit un fichier journal des erreurs distinct pour ce domaine.

   3. Ajoutez au bloc http un bloc server similaire pour le domaine example.net:

      server {
          server_name  example.net;
          root         /var/www/example.net/;
          access_log   /var/log/nginx/example.net/access.log;
          error_log    /var/log/nginx/example.net/error.log;
      }

2. Créez les répertoires racine pour les deux domaines :

   # mkdir -p /var/www/example.com/
   # mkdir -p /var/www/example.net/

3. Définir le contexte httpd_sys_content_t sur les deux répertoires racine :

   # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"
   # restorecon -Rv /var/www/example.com/
   # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.net(/.\*)?"
   # restorecon -Rv /var/www/example.net/

   Ces commandes définissent le contexte httpd_sys_content_t sur les répertoires /var/www/example.com/ et /var/www/example.net/.

   Notez que vous devez installer le paquetage policycoreutils-python-utils pour exécuter les commandes restorecon.

4. Créez les répertoires de journaux pour les deux domaines :

   # mkdir /var/log/nginx/example.com/
   # mkdir /var/log/nginx/example.net/

5. Redémarrez le service nginx:

   # systemctl restart nginx

Verification steps

1. Créez un fichier d'exemple différent dans la racine du document de chaque hôte virtuel :

   # echo "Content for example.com" > /var/www/example.com/index.html
   # echo "Content for example.net" > /var/www/example.net/index.html
   # echo "Catch All content" > /usr/share/nginx/html/index.html

2. Utilisez un navigateur et connectez-vous à http://example.com. Le serveur web affiche l'exemple de contenu du fichier /var/www/example.com/index.html.
3. Utilisez un navigateur et connectez-vous à http://example.net. Le serveur web affiche l'exemple de contenu du fichier /var/www/example.net/index.html.
4. Utilisez un navigateur et connectez-vous à http://IP_address_of_the_server. Le serveur web affiche l'exemple de contenu du fichier /usr/share/nginx/html/index.html.

Procédure

1. Modifiez le fichier /etc/nginx/nginx.conf et ajoutez le bloc server suivant au bloc http dans la configuration :

   server {
       listen              443 ssl;
       server_name         example.com;
       root                /usr/share/nginx/html;
       ssl_certificate     /etc/pki/tls/certs/example.com.crt;
       ssl_certificate_key /etc/pki/tls/private/example.com.key;
   }

2. Pour des raisons de sécurité, configurez l'accès au fichier de la clé privée uniquement pour l'utilisateur root:

   # chown root:root /etc/pki/tls/private/example.com.key
   # chmod 600 /etc/pki/tls/private/example.com.key

   Avertissement

   Si des utilisateurs non autorisés ont eu accès à la clé privée, révoquez le certificat, créez une nouvelle clé privée et demandez un nouveau certificat. Sinon, la connexion TLS n'est plus sécurisée.

3. Redémarrez le service nginx:

   # systemctl restart nginx

Procédure

1. Modifiez le fichier /etc/nginx/nginx.conf et ajoutez les paramètres suivants au bloc server qui doit fournir le proxy inverse :

   location /example {
       proxy_pass https://example.com;
   }

   Le bloc location définit que NGINX transmet toutes les demandes dans le répertoire /example à https://example.com.

2. Définissez le paramètre booléen SELinux httpd_can_network_connect sur 1 pour configurer SELinux de manière à ce qu'il autorise NGINX à transmettre le trafic :

   # setsebool -P httpd_can_network_connect 1

3. Redémarrez le service nginx:

   # systemctl restart nginx

Procédure

1. Modifiez le fichier /etc/nginx/nginx.conf et ajoutez les paramètres suivants :

   http {
       upstream backend {
           least_conn;
           server server1.example.com;
           server server2.example.com;
           server server3.example.com backup;
       }
   
       server {
           location / {
               proxy_pass http://backend;
           }
       }
   }

   La directive least_conn dans le groupe d'hôtes nommé backend définit que NGINX envoie des requêtes à server1.example.com ou server2.example.com, selon l'hôte qui a le moins de connexions actives. NGINX utilise server3.example.com uniquement comme solution de secours au cas où les deux autres hôtes ne seraient pas disponibles.

   Avec la directive proxy_pass définie sur http://backend, NGINX agit comme un proxy inverse et utilise le groupe d'hôtes backend pour distribuer les requêtes en fonction des paramètres de ce groupe.

   Au lieu de la méthode d'équilibrage de charge least_conn, vous pouvez spécifier :

   • Pas de méthode permettant d'utiliser la méthode round robin et de répartir les demandes de manière égale entre les serveurs.
   • ip_hash pour envoyer des requêtes d'une adresse client au même serveur sur la base d'un hachage calculé à partir des trois premiers octets de l'adresse IPv4 ou de l'adresse IPv6 complète du client.
   • hash pour déterminer le serveur en fonction d'une clé définie par l'utilisateur, qui peut être une chaîne, une variable ou une combinaison des deux. Le paramètre consistent configure la distribution des requêtes par NGINX sur tous les serveurs en fonction de la valeur de la clé hachée définie par l'utilisateur.
   • random pour envoyer des requêtes à un serveur choisi au hasard.

2. Redémarrez le service nginx:

   # systemctl restart nginx

Procédure

1. Installez le paquetage squid:

   # dnf install squid

2. Modifiez le fichier /etc/squid/squid.conf:

   1. Adaptez les listes de contrôle d'accès (ACL) de localnet pour qu'elles correspondent aux plages d'adresses IP qui doivent être autorisées à utiliser le proxy :

      acl localnet src 192.0.2.0/24
      acl localnet 2001:db8:1::/64

      Par défaut, le fichier /etc/squid/squid.conf contient la règle http_access allow localnet qui autorise l'utilisation du proxy à partir de toutes les plages d'adresses IP spécifiées dans les ACL localnet. Notez que vous devez spécifier toutes les ACL localnet avant la règle http_access allow localnet.

      Important

      Supprimez toutes les entrées de acl localnet qui ne correspondent pas à votre environnement.

   2. L'ACL suivante existe dans la configuration par défaut et définit 443 comme un port qui utilise le protocole HTTPS :

      acl SSL_ports port 443

      Si les utilisateurs doivent pouvoir utiliser le protocole HTTPS également sur d'autres ports, ajoutez une ACL pour chacun de ces ports :

      acl SSL_ports port port_number

   3. Mettez à jour la liste des règles acl Safe_ports pour configurer les ports sur lesquels Squid peut établir une connexion. Par exemple, pour configurer que les clients utilisant le proxy ne peuvent accéder aux ressources que sur les ports 21 (FTP), 80 (HTTP) et 443 (HTTPS), ne conservez que les déclarations acl Safe_ports suivantes dans la configuration :

      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443

      Par défaut, la configuration contient la règle http_access deny !Safe_ports qui définit le refus d'accès aux ports qui ne sont pas définis dans les ACL Safe_ports.

   4. Configurez le type de cache, le chemin d'accès au répertoire du cache, la taille du cache et d'autres paramètres spécifiques au type de cache dans le paramètre cache_dir:

      cache_dir ufs /var/spool/squid 10000 16 256

      Avec ces paramètres :

      • Squid utilise le type de cache ufs.
      • Squid stocke son cache dans le répertoire /var/spool/squid/.
      • La mémoire cache peut atteindre 10000 MB.
      • Squid crée des sous-répertoires de niveau 1 16 dans le répertoire /var/spool/squid/.

      • Squid crée des sous-répertoires 256 dans chaque répertoire de niveau 1.

        Si vous ne définissez pas de directive cache_dir, Squid stocke le cache en mémoire.

3. Si vous définissez un répertoire de cache différent de /var/spool/squid/ dans le paramètre cache_dir:

   1. Créer le répertoire du cache :

      # mkdir -p path_to_cache_directory

   2. Configurez les permissions pour le répertoire du cache :

      # chown squid:squid path_to_cache_directory

   3. Si vous utilisez SELinux en mode enforcing, définissez le contexte squid_cache_t pour le répertoire de cache :

      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory

      Si l'utilitaire semanage n'est pas disponible sur votre système, installez le paquet policycoreutils-python-utils.

4. Ouvrez le port 3128 dans le pare-feu :

   # firewall-cmd --permanent --add-port=3128/tcp
   # firewall-cmd --reload

5. Activez et démarrez le service squid:

   # systemctl enable --now squid

Procédure

1. Installez le paquetage squid:

   # dnf install squid

2. Modifiez le fichier /etc/squid/squid.conf:

   1. Pour configurer l'utilitaire d'aide basic_ldap_auth, ajoutez l'entrée de configuration suivante au début de /etc/squid/squid.conf:

      auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389

      Les paramètres transmis à l'utilitaire basic_ldap_auth dans l'exemple ci-dessus sont décrits ci-dessous :

      • -b base_DN définit la base de recherche LDAP.
      • -D proxy_service_user_DN définit le nom distinctif (DN) du compte que Squid utilise pour rechercher l'utilisateur qui s'authentifie dans l'annuaire.
      • -W path_to_password_file définit le chemin d'accès au fichier contenant le mot de passe de l'utilisateur du service proxy. L'utilisation d'un fichier de mot de passe permet d'éviter que le mot de passe soit visible dans la liste des processus du système d'exploitation.

      • -f LDAP_filter spécifie le filtre de recherche LDAP. Squid remplace la variable %s par le nom d'utilisateur fourni par l'utilisateur qui s'authentifie.

        Le filtre (&(objectClass=person)(uid=%s)) de l'exemple définit que le nom de l'utilisateur doit correspondre à la valeur définie dans l'attribut uid et que l'entrée du répertoire contient la classe d'objets person.

      • -ZZ impose une connexion cryptée TLS sur le protocole LDAP à l'aide de la commande STARTTLS. Omettre le -ZZ dans les situations suivantes :

        • Le serveur LDAP ne prend pas en charge les connexions cryptées.
        • Le port spécifié dans l'URL utilise le protocole LDAPS.
      • Le paramètre -H LDAP_URL spécifie le protocole, le nom d'hôte ou l'adresse IP et le port du serveur LDAP au format URL.

   2. Ajoutez l'ACL et la règle suivantes pour configurer Squid de manière à ce que seuls les utilisateurs authentifiés puissent utiliser le proxy :

      acl ldap-auth proxy_auth REQUIRED
      http_access allow ldap-auth

      Important

      Spécifiez ces paramètres avant la règle http_access deny all.

   3. Supprimez la règle suivante pour désactiver le contournement de l'authentification par proxy à partir des plages d'adresses IP spécifiées dans les ACL localnet:

      http_access allow localnet

   4. L'ACL suivante existe dans la configuration par défaut et définit 443 comme un port qui utilise le protocole HTTPS :

      acl SSL_ports port 443

      Si les utilisateurs doivent pouvoir utiliser le protocole HTTPS également sur d'autres ports, ajoutez une ACL pour chacun de ces ports :

      acl SSL_ports port port_number

   5. Mettez à jour la liste des règles acl Safe_ports pour configurer les ports sur lesquels Squid peut établir une connexion. Par exemple, pour configurer que les clients utilisant le proxy ne peuvent accéder aux ressources que sur les ports 21 (FTP), 80 (HTTP) et 443 (HTTPS), ne conservez que les déclarations acl Safe_ports suivantes dans la configuration :

      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443

      Par défaut, la configuration contient la règle http_access deny !Safe_ports qui définit le refus d'accès aux ports qui ne sont pas définis dans Safe_ports ACLs.

   6. Configurez le type de cache, le chemin d'accès au répertoire du cache, la taille du cache et d'autres paramètres spécifiques au type de cache dans le paramètre cache_dir:

      cache_dir ufs /var/spool/squid 10000 16 256

      Avec ces paramètres :

      • Squid utilise le type de cache ufs.
      • Squid stocke son cache dans le répertoire /var/spool/squid/.
      • La mémoire cache peut atteindre 10000 MB.
      • Squid crée des sous-répertoires de niveau 1 16 dans le répertoire /var/spool/squid/.

      • Squid crée des sous-répertoires 256 dans chaque répertoire de niveau 1.

        Si vous ne définissez pas de directive cache_dir, Squid stocke le cache en mémoire.

3. Si vous définissez un répertoire de cache différent de /var/spool/squid/ dans le paramètre cache_dir:

   1. Créer le répertoire du cache :

      # mkdir -p path_to_cache_directory

   2. Configurez les permissions pour le répertoire du cache :

      # chown squid:squid path_to_cache_directory

   3. Si vous utilisez SELinux en mode enforcing, définissez le contexte squid_cache_t pour le répertoire de cache :

      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory

      Si l'utilitaire semanage n'est pas disponible sur votre système, installez le paquet policycoreutils-python-utils.

4. Stockez le mot de passe de l'utilisateur du service LDAP dans le fichier /etc/squid/ldap_password et définissez les autorisations appropriées pour le fichier :

   # echo "password" > /etc/squid/ldap_password
   # chown root:squid /etc/squid/ldap_password
   # chmod 640 /etc/squid/ldap_password

5. Ouvrez le port 3128 dans le pare-feu :

   # firewall-cmd --permanent --add-port=3128/tcp
   # firewall-cmd --reload

6. Activez et démarrez le service squid:

   # systemctl enable --now squid

1. Démarrez manuellement l'utilitaire d'assistance avec les mêmes paramètres que ceux utilisés dans le paramètre auth_param:

   # /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389

2. Saisissez un nom d'utilisateur et un mot de passe valides, puis appuyez sur Entrée:

   user_name password

   Si l'utilitaire d'aide renvoie OK, l'authentification a réussi.

Procédure

1. Install the following packages:

   # dnf install squid krb5-workstation

2. S'authentifier en tant qu'administrateur du domaine AD :

   # kinit administrator@AD.EXAMPLE.COM

3. Créer un keytab pour Squid et le stocker dans le fichier /etc/squid/HTTP.keytab:

   # export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
   # net ads keytab CREATE -U administrator

4. Ajouter le principal du service HTTP à la base de données de clés :

   # net ads keytab ADD HTTP -U administrator

5. Définir le propriétaire du fichier keytab à l'utilisateur squid:

   # chown squid /etc/squid/HTTP.keytab

6. En option, vérifiez que le fichier keytab contient le principal de service HTTP pour le nom de domaine complet (FQDN) du serveur proxy :

     klist -k /etc/squid/HTTP.keytab
   Keytab name: FILE:/etc/squid/HTTP.keytab
   KVNO Principal
   ---- ---------------------------------------------------
   ...
      2 HTTP/proxy.ad.example.com@AD.EXAMPLE.COM
   ...

7. Modifiez le fichier /etc/squid/squid.conf:

   1. Pour configurer l'utilitaire d'aide negotiate_kerberos_auth, ajoutez l'entrée de configuration suivante au début de /etc/squid/squid.conf:

      auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/HTTP.keytab -s HTTP/proxy.ad.example.com@AD.EXAMPLE.COM

      Les paramètres transmis à l'utilitaire negotiate_kerberos_auth dans l'exemple ci-dessus sont décrits ci-dessous :

      • -k file définit le chemin d'accès au fichier key tab. L'utilisateur Squid doit avoir les droits de lecture sur ce fichier.

      • -s HTTP/host_name@kerberos_realm définit le principal Kerberos utilisé par Squid.

        En option, vous pouvez activer la journalisation en passant l'un ou les deux paramètres suivants à l'utilitaire d'aide :

      • -i enregistre les messages d'information, tels que l'authentification de l'utilisateur.

      • -d active la journalisation de débogage.

        Squid enregistre les informations de débogage de l'utilitaire d'aide dans le fichier /var/log/squid/cache.log.

   2. Ajoutez l'ACL et la règle suivantes pour configurer Squid de manière à ce que seuls les utilisateurs authentifiés puissent utiliser le proxy :

      acl kerb-auth proxy_auth REQUIRED
      http_access allow kerb-auth

      Important

      Spécifiez ces paramètres avant la règle http_access deny all.

   3. Supprimez la règle suivante pour désactiver le contournement de l'authentification par proxy à partir des plages d'adresses IP spécifiées dans les ACL localnet:

      http_access allow localnet

   4. L'ACL suivante existe dans la configuration par défaut et définit 443 comme un port qui utilise le protocole HTTPS :

      acl SSL_ports port 443

      Si les utilisateurs doivent pouvoir utiliser le protocole HTTPS également sur d'autres ports, ajoutez une ACL pour chacun de ces ports :

      acl SSL_ports port port_number

   5. Mettez à jour la liste des règles acl Safe_ports pour configurer les ports sur lesquels Squid peut établir une connexion. Par exemple, pour configurer que les clients utilisant le proxy ne peuvent accéder aux ressources que sur les ports 21 (FTP), 80 (HTTP) et 443 (HTTPS), ne conservez que les déclarations acl Safe_ports suivantes dans la configuration :

      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443

      Par défaut, la configuration contient la règle http_access deny !Safe_ports qui définit le refus d'accès aux ports qui ne sont pas définis dans les ACL Safe_ports.

   6. Configurez le type de cache, le chemin d'accès au répertoire du cache, la taille du cache et d'autres paramètres spécifiques au type de cache dans le paramètre cache_dir:

      cache_dir ufs /var/spool/squid 10000 16 256

      Avec ces paramètres :

      • Squid utilise le type de cache ufs.
      • Squid stocke son cache dans le répertoire /var/spool/squid/.
      • La mémoire cache peut atteindre 10000 MB.
      • Squid crée des sous-répertoires de niveau 1 16 dans le répertoire /var/spool/squid/.

      • Squid crée des sous-répertoires 256 dans chaque répertoire de niveau 1.

        Si vous ne définissez pas de directive cache_dir, Squid stocke le cache en mémoire.

8. Si vous définissez un répertoire de cache différent de /var/spool/squid/ dans le paramètre cache_dir:

   1. Créer le répertoire du cache :

      # mkdir -p path_to_cache_directory

   2. Configurez les permissions pour le répertoire du cache :

      # chown squid:squid path_to_cache_directory

   3. Si vous utilisez SELinux en mode enforcing, définissez le contexte squid_cache_t pour le répertoire de cache :

      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory

      Si l'utilitaire semanage n'est pas disponible sur votre système, installez le paquet policycoreutils-python-utils.

9. Ouvrez le port 3128 dans le pare-feu :

   # firewall-cmd --permanent --add-port=3128/tcp
   # firewall-cmd --reload

10. Activez et démarrez le service squid:

    # systemctl enable --now squid

1. Obtenir un ticket Kerberos pour le compte AD :

   # kinit user@AD.EXAMPLE.COM

2. Il est possible d'afficher le ticket :

   # klist

3. Utilisez l'utilitaire negotiate_kerberos_auth_test pour tester l'authentification :

   # /usr/lib64/squid/negotiate_kerberos_auth_test proxy.ad.example.com

   Si l'utilitaire d'aide renvoie un jeton, l'authentification a réussi :

   Token : YIIFtAYGKwYBBQUCoIIFqDC...

Procédure

1. Modifiez le fichier /etc/squid/squid.conf et ajoutez les paramètres suivants :

   acl domain_deny_list dstdomain "/etc/squid/domain_deny_list.txt"
   http_access deny all domain_deny_list

   Important

   Ajoutez ces entrées avant la première déclaration http_access allow qui autorise l'accès aux utilisateurs ou aux clients.

2. Créez le fichier /etc/squid/domain_deny_list.txt et ajoutez les domaines que vous souhaitez bloquer. Par exemple, pour bloquer l'accès à example.com, y compris les sous-domaines, et pour bloquer example.net, ajoutez :

   .example.com
   example.net

   Important

   Si vous avez fait référence au fichier /etc/squid/domain_deny_list.txt dans la configuration de Squid, ce fichier ne doit pas être vide. Si le fichier est vide, Squid ne démarre pas.

3. Redémarrez le service squid:

   # systemctl restart squid

Procédure

1. Modifiez le fichier /etc/squid/squid.conf:

   • Pour définir le port sur lequel le service Squid écoute, définissez le numéro de port dans le paramètre http_port. Par exemple, pour définir le port sur 8080, définissez :

     http_port 8080

   • Pour configurer l'adresse IP sur laquelle le service Squid écoute, définissez l'adresse IP et le numéro de port dans le paramètre http_port. Par exemple, pour configurer l'écoute de Squid uniquement sur l'adresse IP 192.0.2.1 et le port 3128, définissez :

     http_port 192.0.2.1:3128

     Ajoutez plusieurs paramètres http_port au fichier de configuration pour configurer l'écoute de Squid sur plusieurs ports et adresses IP :

     http_port 192.0.2.1:3128
     http_port 192.0.2.1:8080

2. Si vous avez configuré Squid pour qu'il utilise un port différent de celui par défaut (3128) :

   1. Ouvrez le port dans le pare-feu :

      # firewall-cmd --permanent --add-port=port_number/tcp
      # firewall-cmd --reload

   2. Si vous exécutez SELinux en mode "enforcing", affectez le port à la définition du type de port squid_port_t:

      # semanage port -a -t squid_port_t -p tcp port_number

      Si l'utilitaire semanage n'est pas disponible sur votre système, installez le paquet policycoreutils-python-utils.

3. Redémarrez le service squid:

   # systemctl restart squid