Comment configurer un proxy sortant de Amazon VPC avec filtrage des domaines et des contenus

Contrôler la communication sortante d’un Amazon VPC (Amazon Virtual Private Cloud) vers Internet est un sujet important dans le cadre de la mise en place de contrôles de sécurité préventifs. Limiter les trafics sortants à certains domaines approuvés est un moyen de protéger vos instances contre le téléchargement de logiciel malveillants, la communication avec les réseaux de robots, etc. Cependant, empêcher tout le trafic sortant n’est pas viable : le but est souvent d’autoriser l’accès à certains domaines bien connus et maîtrisés (par exemple, communiquer avec les partenaires, télécharger les mis à jours logiciels ou communiquer avec l’API d’AWS, etc). Dans cet article, je vais vous montrer une solution à l’aide d’un proxy web qui permet de limiter les trafics sortants de votre VPC avec les listes de domaines autorisés, ou le filtrage de DNS. La solution est évolutive, hautement disponible et se déploie de manière automatisée.

Principes de la solution

Cette solution est basée sur le proxy HTTP open source Squid. Le proxy supporte toutes les charges au sein d’un VPC, y compris Elastic Compute Cloud (EC2) et AWS Fargate. La solution vous offre les avantages suivants :

• Un proxy sortant qui autorise les connexions aux domaines que vous définissez, tout en présentant des messages d’erreur personnalisables lorsque des connexions sont tentées vers des domaines non approuvés,
• Filtrage de contenu de domaine en option basé sur DNS, fourni par des services externes comme OpenDNS, Quad9, CleanBrowsing, Yandex.DNS ou autres. Pour cette option, vous devez être client de ces services externes,
• Gestion transparente du chiffrement, grâce à l’extraction des informations de domaine à partir de l’extension SNI (Server Name Indication) dans TLS. Le chiffrement en transit est préservé et le chiffrement de bout en bout est maintenu,
• Un “Auto-scaling group” avec Elastic Load Balancing (ELB), Network Load Balancer qui s’étend sur l’ensemble de vos sous-réseaux (et zones de disponibilité) existants,
• Une adresse Elastic IP par instance du proxy pour la communication vers Internet. Il vous permet de connaitre de quelle adresse IP vos connexions web proviendront. En effet, les sites web avec lesquels vous communiquez souhaitent parfois connaître votre adresse IP afin d’accepter votre trafic sortant,
• Journaux d’accès de proxy envoyés à Amazon CloudWatch Logs,
• Métriques de proxy, disponible dans Amazon CloudWatch Metrics,
• Déploiement de la solution automatisé via AWS CloudFormation.

Éléments hors du périmètre de la solution

• Cette solution ne couvre pas les applications qui sont incompatibles avec un proxy. De même, la solution n’assure pas l’inspection approfondie des paquets en transit,
• Le chiffrement TLS est conservé de bout en bout et seule l’extension SNI est examinée. Pour le trafic non chiffré (HTTP), seulement les en-têtes sont analysés,
• Le filtrage de DNS doit être fourni par un fournisseur externe; cette solution ne fait que s’y intégrer.

Services utilisés, coût et performance

Cette solution utilise les services suivants :

• AWS Network Load Balancer, voir les tarifs d’Elastic Load Balancing,
• 4 x AWS Elastic IP adresses, facturées si elles ne sont pas utilisées, comme décrit dans la page de tarifs Elastic_IP_Addresses,
• AWS Secrets Manager, pour stocker la liste des domaines. Voir les tarifs d’AWS Secrets Manager,
• Squid, un proxy open source gratuit,
• Instances à la demande Amazon EC2, pour héberger les proxies Squid. Voir les tarifs d’Amazon EC2,
• Amazon Linux 2 et AutoScalingGroup, qui sont tous deux gratuits,
• Cloud Watch Logs, pour stocker le journal d’accès Squid. Voir les tarifs d’Amazon CloudWatch.

Au total, la solution coûte quelques dollars par jour selon la région et l’utilisation de la bande passante. Si vous utilisez un service de filtrage DNS, le fournisseur de services peut également vous facturer son service.

Remarque: Un VPC et une passerelle Internet sont nécessaires pour cette solution et ne sont pas inclus dans les calculs de prix.

Architecture de la solution

Comme l’illustration ci-dessus :

• La solution est déployée automatiquement via un template AWS CloudFormation,
• Amazon CloudWatch Logs stocke le journal d’accès de Squid afin que vous puissiez l’analyser,
• La liste des domaines autorisés est stockée dans AWS Secrets Manager. L’instance Amazon EC2 récupère la liste des domaines toutes les 5 minutes via cronjob et met à jour la configuration du proxy si la liste a changé. Les valeurs dans AWS Secrets Manager sont fournies par AWS CloudFormation et peuvent être lues uniquement par les instances proxy EC2,
• Le client exécuté sur l’instance EC2 doit configurer le proxy pointant vers le Network Load Balancer, il transmettra la demande à la flotte de proxy du groupe cible.

Pré-requis

• Vous avez besoin d’un VPC déployé, avec des sous-réseaux publics et privés répartis sur plusieurs zones de disponibilité (AZ). Vous pouvez trouver une description de la configuration de votre environnement VPC dans Configuration VPC par défaut.
• Vous devez disposer d’une passerelle Internet, avec un routage configuré de sorte que seul le trafic provenant d’un sous-réseau public puisse atteindre Internet.

Vous n’avez pas besoin de passerelle NAT (translation d’adresse réseau) car cette fonction sera fournie par le proxy.

Intégration avec les services filtrage de DNS

Si vous avez besoin du filtrage de DNS d’un fournisseur externe, comme OpenDNS ou Yandex.DNS, vous devez vous inscrire et devenir client de ces services. Beaucoup de fournisseurs ont des services gratuits, en plus des plans payants si vous avez besoin de statistiques avancées et de catégories personnalisées.

Votre fournisseur de DNS vous attribuera une liste d’adresses IP DNS. Vous devrez saisir les adresses IP lors de votre approvisionnement (voir Installation ci-dessous).

Si le fournisseur DNS l’exige, vous pouvez leur donner les adresses IP source des proxies. Il existe quatre adresses IP réservées que vous pouvez trouver dans la sortie du stack CloudFormation (voir Paramètres de sortie ci-dessous).

Installation (à déployer une seule fois)

1. Sélectionnez le bouton Lancer la pile pour lancer AWS CloudFormation template :
   Remarque: Vous devez vous connecter à votre compte AWS pour lancer le stack dans la région requise. Le contenu à jour du stack est également téléchargeable sur GitHub, où vous pouvez également contribuer à l’exemple de code
2. Fournissez les paramètres de proxy suivants, comme illustré dans la figure 2 ci-dessous :
   1. Domaines autorisés : entrez vos domaines que vous autorisez. Utilisez un point («.») pour indiquer les sous-domaines,
   2. Serveurs DNS personnalisés (facultatif) : répertoriez tous les serveurs DNS qui seront utilisés par le proxy. Laissez la valeur par défaut pour utiliser le serveur DNS d’Amazon par défaut,
   3. Port proxy : entrez le port d’écoute du proxy,
   4. Type d’instance : entrez le type d’instance EC2 que vous souhaitez utiliser pour les proxies. Le type d’instance affectera les capacités de proxy et le coût de la solution. Pour plus d’informations, consultez Types d’instances Amazon EC2,
   5. AMI à utiliser : ce champ est pré-rempli avec l’ID Amazon Machine Image (AMI) trouvé dans AWS Systems Manager Parameter Store. Par défaut, il pointera vers la dernière version d’image d’Amazon Linux 2. Vous n’avez pas besoin d’ajuster cette valeur,
   6. Nom de la clé SSH (facultatif) : entrez le nom de la clé SSH pour vos instances proxy EC2. Cela n’est pertinent que pour le débogage ou si vous devez vous connecter sur les serveurs proxy. Envisagez d’utiliser AWS Systems Manager Session Manager au lieu de SSH,
3. Ensuite, fournissez les paramètres réseau suivants, comme le montre la figure 2 :
   1. ID VPC : VPC dans lequel la solution sera déployée,
   2. Sous-réseaux publics : les sous-réseaux où les proxies seront déployés. Sélectionnez entre 2 et 3 sous-réseaux,
   3. Sous-réseaux privés : les sous-réseaux où le Network Load Balancer sera déployé. Sélectionnez entre 2 et 3 sous-réseaux,
   4. CIDR client autorisé : la valeur que vous entrez ici sera ajoutée au groupe de sécurité de proxy. Par défaut, la plage IP privée 172.31.0.0/16 est autorisée. La taille de bloc autorisée est comprise entre un masque de réseau / 32 et un masque de réseau / 8. Cela vous empêche d’utiliser une plage IP ouverte comme 0.0.0.0/0. Si vous deviez définir une plage IP ouverte, vos proxies accepteraient le trafic de n’importe où sur Internet, ce qui est une mauvaise pratique.

Figure 2: Lancer le template de CloudFormation

Lorsque vous avez entré tous vos paramètres de proxy et de réseau, sélectionnez Suivant. Sur les écrans suivants de l’assistant, vous pouvez conserver les valeurs par défaut et sélectionner Suivant et Créer un stack.

Récupération des paramètres dans la sortie de la création de la stack

Une fois que l’état du stack est devenu « déployé », vous devez noter les paramètres dans la sortie pour configurer vos clients. Recherchez les paramètres suivants dans l’onglet Sorties de la stack :

• Le nom de domaine du proxy qui doit être configuré sur le client,
• Le port du proxy qui doit être configuré sur le client,
• 4 Adresses Elastic IP pour les instances de proxy. Elles sont utilisées pour les connexions sortantes à Internet,
• Le CloudWatch Log Group, pour les journaux d’accès,
• Groupe de sécurité attaché aux proxies,
• La commande Linux pour définir le proxy. Vous pouvez copier et coller cela dans votre shell.

Figure 3: Paramètres dans la sortie de la stack

Utilisation du proxy

Les paramètres de configuration du proxy sont spécifiques à chaque application. La plupart des applications Linux utilisent les variables d’environnement http_proxy et https_proxy.

• Connectez-vous à l’instance Linux EC2 autorisée à utiliser le proxy.
• Pour définir temporairement le paramètre shell (uniquement pour la session shell actuelle), exécutez les commandes d’exportation suivantes :

  [ec2-user@ip-10-0-1-18 ~]$ export http_proxy=http://<Proxy-DOMAIN>:<Proxy-Port>
  			 [ec2-user@ip-10-0-1-18 ~]$ export https_proxy=$http_proxy
  			

  • Remplacez <Proxy-DOMAIN> par le domaine de Network Load Balancer, que vous pouvez trouver dans la sortie de la stack
  • Remplacez <Proxy-Port> par le port de votre proxy, qui est également répertorié dans la sortie de la stack.
• Ensuite, vous pouvez utiliser curl (par exemple) pour tester la connexion. Remplacez <URL> par l’une de vos URL sur liste autorisée :

[ec2-user@ip-10-0-1-18 ~]$ curl -k <URL> -k 
<!DOCTYPE html>
…

• Vous pouvez ajouter le paramètre proxy de manière permanente aux shells interactifs et non interactifs. Si vous procédez ainsi, vous n’aurez pas besoin de les reconfigurer après le rechargement. Exécutez les commandes suivantes dans votre shell :

  [ec2-user@ip-10-0-1-18 ~]$ echo 'export http_proxy=http://<Proxy-DOMAIN>:<Proxy-Port>' >> ~/.bashrc
   [ec2-user@ip-10-0-1-18 ~]$ echo 'export https_proxy=$http_proxy' >> ~/.bashrc
   
   [ec2-user@ip-10-0-5-18 ~]$ echo 'export http_proxy=http://<Proxy-DOMAIN>:<Proxy-Port>' >> ~/.bash_profile
   [ec2-user@ip-10-0-5-18 ~]$ echo 'export https_proxy=$http_proxy' >> ~/.bash_profil
  
  

  • Remplacer <Proxy-DOMAIN> par le domaine du Network Load Balancer
  • Remplacer <Proxy-Port> par le port du proxy

Personnalisation la page d’accès refusé

Une page d’erreur s’affiche lorsque l’accès d’un utilisateur est bloqué ou en cas d’erreur interne. Vous pouvez personnaliser cette page (HTML ou styles) en fonction d’error_directory de Squid.

Utilisation du journal d’accès de proxy

Le journal d’accès de proxy est un outil important pour le dépannage. Il contient l’adresse IP du client, le domaine de destination, le port et les erreurs avec les timestamps. Les journaux d’accès de Squid sont envoyés au CloudWatch Logs. Vous pouvez les trouver dans la console Amazon CloudWatch sous Groupes de journaux, avec le préfixe Proxy, comme indiqué dans la figure ci-dessous :

Vous pouvez utiliser Amazon CloudWatch Insight pour analyser et visualiser les journaux. Voir la figure suivante pour un exemple de connexions refusées visualisées sur une chronologie :

Surveillance de vos métriques avec Amazon CloudWatch

Les principales métriques du proxy sont envoyées toutes les cinq minutes aux CloudWatch Metrics dans l’espace de noms du proxy:

• client_http.errors /sec – erreurs dans le traitement des requêtes des clients par seconde,
• client_http.hits /sec – accès au cache par seconde,
• client_http.kbytes_in /sec – données envoyées par client par seconde,
• client_http.kbytes_out /sec – données téléchargées par client par seconde,
• client_http.requests /sec – nombre de requêtes par seconde,
• server.all.errors /sec – Erreurs du proxy par seconde,
• server.all.kbytes_in /sec – données envoyées par le proxy par seconde,
• server.all.kbytes_out /sec – données téléchargées par le proxy par seconde,
• server.all.requests /sec – toutes les requêtes envoyées par le proxy par seconde.

Dans la figure ci-dessous, vous pouvez voir un exemple des métriques. Pour plus d’informations sur l’utilisation des métriques, consultez les informations du projet Squid :

Figure 6: Exemple des métriques Amazon CloudWatch

Gestion de la configuration du proxy

De temps en temps, vous voulez peut-être ajouter ou supprimer des domaines autorisés. Pour les modifier, vous devez mettre à jour les valeurs d’entrée dans le stack CloudFormation. Cela entraînera également la mise à jour des valeurs stockées dans Secrets Manager. Toutes les cinq minutes, les proxies récupèrent la liste de domaines autorisés dans Secrets Manager et la mettront à jour si besoin. La propagation de votre modification peut prendre donc jusqu’à cinq minutes. La modification sera propagée à toutes les instances sans les interrompre ni les redéployer.

Notez que lorsque la liste de domaines autorisés est mise à jour, les processus proxy Squid sont redémarrés, ce qui interrompra TOUTES les connexions à ce moment. Cela peut entrainer une perturbation des applications clientes, alors soyez prudent lorsque vous modifiez la liste de domaines autorisés par rapport aux impacts potentiels.

Si vous souhaitez modifier d’autres paramètres CloudFormation, comme les paramètres DNS ou le groupe de sécurité, vous pouvez à nouveau mettre à jour la stack CloudFormation avec de nouvelles valeurs. CloudFormation lancera une nouvelle instance et mettra fin aux instances précédentes (une mise à jour continue).

Vous pouvez modifier la configuration du proxy Squid en modifiant le template CloudFormation (section AWS :: CloudFormation :: Init) et en mettant à jour le stack. Cependant, cette opération nécessite une expérience avancée d’AWS et de Squid.

Mis à jour des instances

Afin de mettre à jour votre AMI, vous pouvez mettre à jour le stack CloudFormation. Si l’AMI a été mise à jour avec une version plus récente, une mise à jour continue redéployera les instances EC2 et le logiciel Squid. Cela automatise le processus des mises à jour liées à la sécurité et autres pour le système d’exploitation des instances. Si l’AMI n’a pas changé, aucune mise à jour ne sera effectuée.

Vous pouvez également terminer l’instance et l’autoscaling group lancera une nouvelle instance avec les dernières mises à jour pour Squid et le système d’exploitation, à partir de zéro. Cette approche peut entraîner une courte interruption de service pour les clients servis sur l’instance, pendant la période d’interruption, le Load Balancer bascule la charge vers une instance active.

Troubleshooting

Quelques problèmes courants et les solutions correspondantes.

Conclusion

Dans cet article, je vous ai montré comment configurer un proxy sortant pour contrôler la communication Internet à partir d’un VPC. Si vous avez besoin du support Squid, vous pouvez trouver différentes offres sur la page Support Squid et vous avez accès aux forums AWS pour le support d’Amazon Elastic Compute Cloud (EC2).

Article original de Vesselin Tzvetkov, Consultant AWS, et traduit en français par Kun Song, Architecte de Solutions chez AWS France aidant les clients français à adopter le cloud AWS, LinkedIn.