Suivi de connexion de groupe de sécurité

Vos groupes de sécurité utilisent le suivi de connexion pour suivre les informations sur le trafic en provenance ou à destination de l’instance. Les règles s’appliquent en fonction de l’état de connexion du trafic pour déterminer si le trafic est autorisé ou refusé. Avec cette approche, les groupes de sécurité sont avec état. Les groupes de sécurité peuvent ainsi être avec état. Les réponses au trafic entrant sont autorisées à transiter en dehors de l’instance, indépendamment des règles sortantes des groupes de sécurité (et inversement).

À titre d’exemple, supposons que vous lanciez une commande telle que netcat ou similaire à vos instances depuis votre ordinateur personnel, et que vos règles de groupe de sécurité entrantes autorisent le trafic ICMP. Les informations sur la connexion (y compris sur le port) sont suivies. Le trafic de réponse à partir de l’instance pour la commande n’est pas suivi comme une nouvelle demande, mais plutôt comme une connexion établie, et est autorisé à circuler hors de l’instance, même si les règles de votre groupe de sécurité pour le trafic sortant limitent le trafic ICMP sortant.

Pour les protocoles autre que TCP, UDP ou ICMP, seuls l’adresse IP et le numéro de protocole sont suivis. Si votre instance envoie le trafic vers un autre hôte et que l’hôte envoie le même type de trafic vers votre instance dans un délai de 600 secondes, le groupe de sécurité de votre instance l’accepte indépendamment des règles de groupe de sécurité entrantes. Le groupe de sécurité l’accepte, car il est considéré comme un trafic de réponse pour le trafic d’origine.

Lorsque vous modifiez une règle de groupe de sécurité, ses connexions suivies ne sont pas immédiatement interrompues. Le groupe de sécurité continue d’autoriser les paquets jusqu’à l’expiration des connexions existantes. Pour vous assurer que le trafic est immédiatement interrompu ou que tout le trafic est soumis à des règles de pare-feu quel que soit l’état de suivi, vous pouvez utiliser une liste ACL réseau pour votre sous-réseau. Les ACL réseau sont sans état et n’autorisent donc pas automatiquement le trafic de réponse. L’ajout d’une liste ACL réseau qui bloque le trafic dans les deux sens interrompt les connexions existantes. Pour plus d’informations, consultez ACL réseau dans le Amazon VPC Guide de l’utilisateur.

Note

Les groupes de sécurité n'ont aucun effet sur le trafic DNS à destination ou en provenance du résolveur Route 53, parfois appelé « adresse IP VPC+2 » (voir Qu'est-ce qu'Amazon Route 53 Resolver ? dans le guide du développeur Amazon Route 53), ou le « AmazonProvided DNS » (voir Travailler avec des ensembles d'options DHCP dans le guide de l'utilisateur d'Amazon Virtual Private Cloud). Si vous souhaitez filtrer les demandes DNS via Route 53 Resolver, vous pouvez activer Route 53 Resolver DNS Firewall (veuillez consulter la section Route 53 Resolver DNS Firewall du Guide du développeur Amazon Route 53).

Connexions non suivies

Certains flux de trafic ne sont pas suivis. Si une règle de groupe de sécurité autorise les flux TCP ou UDP pour tout le trafic (0.0.0.0/0 ou : :/0) et qu'une règle correspondante autorise tout le trafic de réponse (0.0.0.0/0 ou : :/0) pour n'importe quel port (0-65535), ce flux de trafic n'est pas suivi, sauf s'il fait partie d'une connexion suivie automatiquement. Le trafic de la réponse d’un flux non suivi est autorisé en fonction de la règle entrante ou sortante qui autorise le trafic de la réponse, et non des informations de suivi.

Un flux de trafic non suivi est immédiatement interrompu si la règle qui active le flux est supprimée ou modifiée. Par exemple, si vous disposez d’une règle sortante ouverte (0.0.0.0/0) et que vous supprimez une règle qui autorise tout le trafic SSH (port TCP 22) entrant (0.0.0.0/0) vers l’instance (ou que vous la modifiez de telle sorte que la connexion ne soit plus autorisée), vos connexions SSH existantes à l’instance sont immédiatement supprimées. La connexion n’était pas suivie auparavant, de sorte que la modification rompt la connexion. D’autre part, si vous avez une règle entrante plus étroite qui autorise initialement une connexion SSH (ce qui signifie que la connexion a été suivie), mais que vous modifiez cette règle pour ne plus autoriser de nouvelles connexions à partir de l’adresse du client SSH actuel, la connexion SSH existante ne sera pas interrompue, car elle est suivie.

Connexions suivies automatiquement

Les connexions établies via les méthodes suivantes sont automatiquement suivies, même si la configuration du groupe de sécurité ne nécessite pas de suivi par ailleurs :

• Passerelles Internet de sortie uniquement

• Accélérateurs Global Accelerator

• Passerelles NAT

• Points de terminaison de pare-feu Network Firewall

• Network Load Balancers

• AWS PrivateLink (points de terminaison VPC d'interface)

• AWS Lambda (Interfaces réseau élastiques Hyperplane)

Allocations de suivi des connexions

Amazon EC2 définit le nombre maximal de connexions qui peuvent être suivies par instance. Une fois le maximum atteint, tous les paquets envoyés ou reçus sont abandonnées, car une nouvelle connexion ne peut pas être établie. Lorsque cela se produit, les applications qui envoient et reçoivent des paquets ne peuvent pas communiquer correctement. Utilisez la métrique de performance réseau conntrack_allowance_available pour déterminer le nombre de connexions suivies encore disponibles pour ce type d’instance.

Pour déterminer si des paquets ont été abandonnés parce que le trafic réseau de votre instance a dépassé le nombre maximal de connexions pouvant être suivies, utilisez la métrique de performance réseau conntrack_allowance_exceeded. Pour plus d’informations, consultez Contrôlez les performances réseau de votre instance EC2.

Avec Elastic Load Balancing, si vous dépassez le nombre maximal de connexions pouvant être suivies par instance, nous vous recommandons de mettre à l’échelle soit le nombre d’instances enregistrées auprès de l’équilibreur de charge, soit la taille des instances enregistrées auprès de l’équilibreur de charge.

Considérations relatives aux performances du suivi des connexions

Le routage asymétrique, selon lequel le trafic entre dans une instance via une interface réseau et en sort par une interface réseau différente, peut réduire les performances maximales qu'une instance peut atteindre si les flux sont suivis.

Pour maintenir des performances optimales lorsque le suivi des connexions est activé pour vos groupes de sécurité, nous recommandons la configuration suivante :

• Évitez les topologies de routage asymétriques, si possible.

• Au lieu d'utiliser des groupes de sécurité pour le filtrage, utilisez des ACL réseau.

• Si vous devez utiliser des groupes de sécurité avec suivi des connexions, configurez le délai d'expiration de connexion le plus court possible.

Pour plus d'informations sur le réglage des performances du système Nitro, consultezConsidérations relatives au système Nitro pour le réglage des performances.

Délai de suivi d’inactivité de la connexion

Le groupe de sécurité assure le suivi de chaque connexion établie pour que les paquets de retour soient livrés comme prévu. Il existe un nombre maximal de connexions qui peuvent être suivies par instance. Les connexions qui restent inactives peuvent entraîner l’épuisement du suivi des connexions, empêcher le suivi des connexions et entraîner la perte de paquets. Vous pouvez définir le délai pour le suivi d’inactivité de la connexion sur une interface réseau Elastic.

Note

Cette fonctionnalité n'est disponible que pour les instances créées sur le système AWS Nitro.

Il existe trois délais configurables :

• Délai TCP établi : délai d’expiration (en secondes) pour les connexions TCP inactives dans un état établi. Min. : 60 secondes. Max. : 432 000 secondes (5 jours). Par défaut : 432 000 secondes. Recommandé : moins de 432 000 secondes.

• Délai UDP : délai d’expiration (en secondes) pour les flux UDP inactifs qui n’ont vu du trafic que dans une seule direction ou une seule transaction requête-réponse. Min. : 30 secondes. Max. : 60 secondes. Par défaut : 30 secondes.

• Délai d’expiration des flux UDP : délai d’expiration (en secondes) des flux UDP inactifs classés comme des flux ayant reçu plus d’une transaction requête-réponse. Min. : 60 secondes. Max. : 180 secondes (3 minutes). Par défaut : 180 secondes.

Vous pouvez modifier les délais par défaut dans les cas suivants :

• Si vous surveillez les connexions suivies à l’aide des métriques de performance réseau Amazon EC2, les métriques conntrack_allowance_exceeded et conntrack_allowance_available vous permettent de surveiller les paquets perdus et les connexions suivies afin de gérer de manière proactive la capacité des instances EC2 avec des actions d’augmentation ou de montée en puissance pour répondre à la demande de connexions réseau avant de perdre des paquets. Si vous observez des pertes de conntrack_allowance_exceeded sur vos instances EC2, il peut être avantageux de définir un délai TCP plus faible pour tenir compte des sessions TCP/UDP obsolètes dues à des clients ou à des middle box réseau inappropriés.

• Généralement, les équilibreurs de charge ou les pare-feu ont un délai d’inactivité établi de TCP compris entre 60 et 90 minutes. Si vous exécutez des charges de travail censées gérer un très grand nombre de connexions (plus de 100 000) à partir d’appareils tels que des pare-feu réseau, il est conseillé de configurer un délai similaire sur une interface réseau EC2.

• Si vous exécutez une charge de travail qui utilise une topologie de routage asymétrique, nous vous recommandons de configurer un délai d'inactivité établi par TCP de 60 secondes.

• Si vous exécutez des charges de travail comportant un grand nombre de connexions telles que DNS, SIP, SNMP, Syslog, Radius et d’autres services qui utilisent principalement le protocole UDP pour traiter les requêtes, définir le délai « flux UDP » sur 60 s permet d’augmenter la mise à l’échelle et les performances de la capacité existante et d’éviter les pannes grises.

• Pour les connexions TCP/UDP via des Network Load Balancers (NLB) et des Elastic Load Balancers (ELB), toutes les connexions sont suivies. La valeur du délai d’inactivité est de 350 secondes pour les flux TCP et de 120 secondes pour les flux UDP, et varie en fonction des valeurs de délai au niveau de l’interface. Vous souhaiterez peut-être configurer les délais au niveau de l’interface réseau afin de garantir une plus grande flexibilité que les délais par défaut pour ELB/NLB.

Vous avez la possibilité de configurer les délais du suivi des connexions lorsque vous effectuez les actions suivantes :

• Créer une interface réseau

• Modifier les attributs d’interface réseau

• Lancer une instance EC2

• Créer un modèle de lancement d’instance EC2

Exemple

Dans l’exemple suivant, le groupe de sécurité dispose de règles entrantes qui autorisent le trafic TCP et ICMP, et de règles sortantes qui autorisent tout le trafic sortant.

Entrant
Type de protocole	Numéro de port	Source
TCP	22 (SSH)	203.0.113.1/32
TCP	80 (HTTP)	0.0.0.0/0
TCP	80 (HTTP)	::/0
ICMP	Tous	0.0.0.0/0

Sortant
Type de protocole	Numéro de port	Destination
Tous	Tous	0.0.0.0/0
Tous	Tous	::/0

Avec une connexion réseau directe à l’instance ou à l’interface réseau, le suivi se comporte comme suit :

• Le trafic TCP entrant et sortant sur le port 22 (SSH) est suivi, car la règle de trafic entrant autorise uniquement le trafic en provenance de 203.0.113.1/32, et pas de toutes les adresses IP (0.0.0.0/0).

• Le trafic TCP entrant et sortant sur le port 80 (HTTP) n’est pas suivi, car les règles entrantes et sortantes autorisent le trafic de toutes les adresses IP.

• Le trafic ICMP est toujours suivi.

Si vous supprimez la règle sortante pour le trafic IPv4, tout le trafic IPv4 entrant et sortant est suivi, y compris le trafic sur le port 80 (HTTP). Il en va de même pour le trafic IPv6 si vous supprimez la règle sortante pour le trafic IPv6.