Suivi des connexions du groupe de EC2 sécurité Amazon

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).

Supposons par exemple que vous initiez une commande telle que netcat ou similaire pour vos instances depuis votre ordinateur personnel et que les règles de votre groupe de sécurité entrant autorisent ICMP le trafic. Les informations sur la connexion (y compris sur le port) sont suivies. Le trafic de réponse provenant de l'instance pour la commande n'est pas suivi en tant que nouvelle demande, mais plutôt en tant que connexion établie, et est autorisé à sortir de l'instance, même si les règles de votre groupe de sécurité sortant limitent le trafic sortantICMP.

Pour les protocoles autres que TCPUDP, ouICMP, 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 l'ensemble du trafic est soumis à des règles de pare-feu quel que soit l'état du suivi, vous pouvez utiliser un réseau ACL pour votre sous-réseau. ACLsLes réseaux sont apatrides et n'autorisent donc pas automatiquement le trafic de réponse. L'ajout d'un réseau ACL bloquant le trafic dans les deux sens interrompt les connexions existantes. Pour plus d'informations, consultez la section Réseau ACLs dans le guide de VPC l'utilisateur Amazon.

Note

Les groupes de sécurité n'ont aucun effet sur le DNS trafic à 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'DHCPoptions dans le guide de l'utilisateur d'Amazon Virtual Private Cloud). Si vous souhaitez filtrer les DNS demandes via le résolveur Route 53, vous pouvez activer le DNS pare-feu Route 53 Resolver (voir Route 53 Resolver DNS Firewall dans le 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 TCP ou UDP circule pour tout le trafic (0.0.0.0/0 ou : :/0) et qu'il existe une règle correspondante dans l'autre sens qui 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 avez une règle sortante ouverte (0.0.0.0/0) et que vous supprimez une règle qui autorise tout le trafic entrant (0.0.0.0/0) (TCPport 22) à destination de l'instance SSH (ou si vous la modifiez pour que la connexion ne soit plus autorisée), vos connexions existantes SSH à l'instance sont immédiatement supprimées. La connexion n’était pas suivie auparavant, de sorte que la modification rompt la connexion. En revanche, si vous avez une règle entrante plus étroite qui autorise initialement une SSH connexion (c'est-à-dire 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 SSH client actuel, la SSH connexion existante n'est 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

• NATpasserelles

• Points de terminaison de pare-feu Network Firewall

• Network Load Balancers

• AWS PrivateLink (VPCpoints de terminaison de l'interface)

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

Allocations de suivi des connexions

Amazon EC2 définit le nombre maximum de connexions pouvant ê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 Surveillez les performances du réseau pour ENA les paramètres de votre EC2 instance.

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 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 le réseauACLs.

• 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 :

• TCPdélai établi : délai d'expiration (en secondes) pour les TCP connexions 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.

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

• UDPdélai d'expiration du flux : délai d'expiration (en secondes) pour les UDP flux inactifs classés comme des flux ayant fait l'objet de plusieurs transactions 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 indicateurs de performance du EC2 réseau Amazon, les indicateurs conntrack_allowance_exceeded et conntrack_allowance_available vous permettent de surveiller les paquets abandonnés et de suivre l'utilisation des connexions afin de gérer de manière proactive la capacité des EC2 instances grâce à des actions d'extension ou de réduction afin de répondre à la demande de connexions réseau avant de supprimer des paquets. Si vous observez des baisses de conntrack_allowance_exceeded sur vos EC2 instances, il peut être avantageux de définir un délai d'expiration plus court pour tenir compte TCP des UDP sessions périmées résultant de clients ou de boîtiers TCP réseau inappropriés.

• Généralement, les équilibreurs de charge ou les pare-feux ont un délai d'inactivité TCP établi 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 (supérieures à 100 000) à partir d'appareils tels que des pare-feux réseau, il est conseillé de configurer un délai d'expiration similaire sur une interface EC2 réseau.

• 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é TCP établi de 60 secondes.

• Si vous exécutez des charges de travail comportant un nombre élevé de connexionsDNS, tels que Syslog SIPSNMP, Radius et d'autres services principalement utilisés UDP pour répondre aux demandes, le fait de définir le délai d'expiration « UDP -stream » sur 60 permet d'améliorer l'évolutivité et les performances de la capacité existante et d'éviter les défaillances grises.

• Pour les UDP connexionsTCP/via les équilibreurs de charge réseau (NLBs) et les équilibreurs de charge élastiques (ELB), toutes les connexions sont suivies. La valeur du délai d'inactivité pour les TCP flux est de 350 secondes et les UDP flux de 120 secondes. Elle varie en fonction des valeurs de délai d'inactivité au niveau de l'interface. Vous souhaiterez peut-être configurer les délais d'expiration au niveau de l'interface réseau afin de permettre 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 EC2 instance

• Création d'un modèle de lancement d'EC2instance

Exemple

Dans l'exemple suivant, le groupe de sécurité possède des règles entrantes qui autorisent le ICMP trafic TCP et des 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 TCP trafic entrant et sortant sur le port 22 (SSH) est suivi, car la règle de trafic entrant n'autorise que le trafic provenant de 203.0.113.1/32, et non de toutes les adresses IP (0.0.0.0/0).

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

• ICMPle trafic est toujours suivi.

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