Pourquoi sont "bizarres" TCP ports requis pour que mon application AWS ECS puisse extraire ECR?
J'utilise ECS avec NLB en face. ECS extrait des images d'ECR. Ce que je ne comprends pas, c'est pourquoi ECS exige que je ouvre tous les ports TCP pour pouvoir extraire ECR?
2 621567429603 eni-0f5e97a3c2d51a5db 18.136.60.252 10.0.12.61 443 55584 6 13 6504 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 10.0.12.61 54.255.143.131 44920 443 6 13 5274 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 54.255.143.131 10.0.12.61 443 44952 6 13 6504 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 10.0.12.61 18.136.60.252 55584 443 6 15 5378 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 10.0.12.61 18.136.60.252 55612 443 6 15 5378 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 52.219.36.183 10.0.12.61 443 51892 6 19 11424 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 10.0.12.61 54.255.143.131 44908 443 6 14 1355 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 52.219.36.183 10.0.12.61 443 51912 6 31807 44085790 1537798711 1537798719 ACCEPT OK
2 621567429603 eni-0f5e97a3c2d51a5db 18.136.60.252 10.0.12.61 443 55612 6 12 6452 1537798711 1537798719 ACCEPT OK
Mon flux enregistre ci-dessus. 10.0.0.0/8 est mes adresses privées VPC. Notez que la première fois que SRC: 18.136.60.252:443 accède à 10.0.12.61:55584, pourquoi ce port de destination?
Ensuite, la ligne suivante 2 621567429603 eni-0f5e97a3c2d51a5db 10.0.12.61 54.255.143.131 44920 443 6 13 5274 1537798711 1537798719 ACCEPT OK. Pourquoi mon ECS demande-t-il des données à l'aide du port source 44920? Je demande donc je sais comment ouvrir les bons ports. Actuellement, à cause des ports étant si aléatoires, je dois tout ouvrir
Quand on dit 18.136.60.252:443 is accessing 10.0.12.61:55584, je ne dirais pas que (18.136.60.252} _ "accède" à votre IP VPC local. Je dirais plutôt que "18.136.60.252" envoie une réponse à l'adresse IP de votre VPC local, au port SRC aléatoire attribué par le système d'exploitation pour établir la communication TCP (55584), via une connexion déjà ESTABLISHED TCP connexion (initiée par ecs-agent dans votre instance).
Vous n'avez pas besoin de vous concentrer sur le port source à autoriser. Vous voulez plutôt dire à l'OS (pare-feu) de "laisser les réponses entrer pour les connexions déjà établies". Dans iptables, c'est comme ça:
De l'instance au réseau, pour accéder à un port 443 distant:
iptables -A OUTPUT -o eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
De l'hôte distant à votre instance, pour laisser les réponses revenir:
iptables -A INPUT -i eth0 -p tcp -m multiport --sports 80,443 -m state --state RELATED,ESTABLISHED -j ACCEPT
. ^ source port ^ the rule only applies to already established connections
Ici vous pouvez trouver de meilleures explications:
https://unix.stackexchange.com/q/323546/18256
https://superuser.com/a/1171322/131073
Pourquoi mon ECS demande-t-il des données via le port source 44920?
Le système d'exploitation est celui qui attribue ces ports à l'agent ECS afin qu'il soit utilisé comme port source. Il s'agit simplement d'un port libre, sélectionné de manière aléatoire.
_ {Après les clarifications effectuées par l'OP et l'auto-apprentissage} _
Ainsi, dans le niveau AWS NACL, dois-je autoriser toutes les plages de ports éphémères?
Selon la documentation AWS NACL :
En pratique, vous pouvez ouvrir les ports éphémères 1024-65535 pour couvrir les différents types de clients pouvant initier du trafic vers des instances ouvertes au public dans votre VPC. Toutefois, vous pouvez également ajouter des règles à la liste de contrôle d'accès pour interdire le trafic sur les ports malveillants de cette plage. Veillez à placer les règles DENY plus tôt dans la table que les règles ALLOW qui ouvrent la vaste gamme de ports éphémères.
Mais prenez en compte:
Vous pouvez configurer des listes de contrôle d'accès réseau avec des règles similaires à celles de vos groupes de sécurité afin d'ajouter une couche de sécurité supplémentaire à votre VPC. _ {(c'est moi qui souligne)} _
.
Et au niveau de l'OS faire ça? Si j'utilise docker, dois-je le faire via Dockerfile?
Ma recommandation est de gérer cela via les groupes de sécurité, car ils sont "avec état", ce qui signifie qu'ils suivent chaque connexion établie, autorisant automatiquement des "réponses" aux ports éphémères, sans configurer ces règles. Par exemple, vous pouvez "DENY" tout le trafic entrant et autoriser TCP 443 pour le trafic sortant. Cela signifie not signifie que les réponses ne peuvent pas atteindre le port éphémère, elles peuvent en effet (malgré le trafic DENY all inbout), car le groupe de sécurité se souvient de la connexion. Voir plus d'infos ici :
Groupe de sécurité: contient des états: le trafic de retour est automatiquement autorisé, quelles que soient les règles
ACL réseau: est sans état: le trafic de retour doit être explicitement autorisé par les règles <- ceci répond à la question précédente, à propos des ports éphémères
En ce qui concerne le système d’exploitation et iptables, j’aimerais explorer d’abord les groupes de sécurité, qui sont plus faciles à configurer et à gérer, du moins pour le cas d’utilisation actuel.
J'ajoute simplement mes réflexions ici sur l'expérience de réseau sortant ECS. Ecs-agent est en cours d'exécution sur votre ECS EC2 et interagit en permanence avec les API ECS et CloudWatch. ecs-agent continue à informer sur l'état de l'hôte EC2, les conteneurs dockers en cours d'exécution et l'envoi des journaux d'agent aux API ci-dessus.
Le processus ecs-agent interagit avec des API AWS ci-dessus (443) à des intervalles spécifiques, ce qui explique pourquoi le port source change constamment. Voici la sortie de mon journal netstat du serveur EC2.
commande - netstat -tcp
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 ip-172-31-86-188.:47364 52.46.132.80:https ESTABLISHED 4188/agent
tcp 0 0 ip-172-31-86-188.:57190 52.46.132.44:https ESTABLISHED 4188/agent
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 ip-172-31-86-188.:57190 52.46.132.44:https ESTABLISHED 4188/agent
tcp 0 0 ip-172-31-86-188.:60646 52.46.128.101:https ESTABLISHED 4188/agent
Pour extraire une image à partir d’ECR, votre EC2 n’a besoin que du port 443 du terminal ECR. Tout le reste du trafic est spécifique à ecs-agent concernant la maintenance du cluster. Faites-moi part de vos réflexions sur la base de vos journaux EC2 TCP et du processus qui en est responsable.
Vous devez avoir configuré le Dynamic Port Mapping pour votre ECS. Il a la plage de ports éphémères par défaut de 49153 à 65535 et, en général, les ports inférieurs à 32768 sont en dehors de la plage de ports éphémère, d'où le caractère aléatoire des ports hôtes dans les connexions TCP. Vous avez des valeurs de port inférieures, mais cela doit être dû à la configuration de votre instance (la valeur par défaut de ip_local_port_range est le plus souvent 32768 - 61000)
Veuillez lire les détails sur la façon de le configurer depuis ici et le point exact où le paramétrage du port est défini peut être trouvé ici
Il est possible de configurer ou de configurer un seul port en utilisant soit un Port unique pour toute la connectivité, soit de modifier votre plage de ports via
/proc/sys/net/ipv4/ip_local_port_range, bien qu'il ne soit pas recommandé que Dévie de la plage par défaut.