Se faire piquer par NaCl à nouveau. J'essaie de SSH du réseau sur site, du VPN de site à site connecté, à une instance de la VPC, associée à la passerelle transitway code>. C'est ce que mes autorisations sont pour le faire fonctionner: Source : 10.0.12.0/28 [VPN]
Target : 10.114.1.0/28 [VPC]
------------------------------
Security Group:
inbound => SSH | TCP | 22 | 10.0.12.0/28
outbound => All traffic | All | All | 0.0.0.0/0
Network ACL:
inbound:
101 | SSH (22) | TCP (6) | 22 | 10.0.12.0/28 | ALLOW
111 | Custom TCP | Rule TCP (6) | 32768 - 65535 | 0.0.0.0/0 | ALLOW
outbound:
101 | Custom TCP | Rule TCP (6) | 0 - 65535 | 0.0.0.0/0 | ALLOW
3 Réponses :
en règle générale, il devrait y avoir aucune raison de modifier un réseau ACL (NaCL) . Il permet de tout le trafic, des deux manières, par défaut. Il n'ya que des cas d'utilisation très spécifiques lorsqu'il vaut la peine de modifier une NaCL, telle que la création de DMZ de réseau, bloquant des adresses IP abusives ou verrouillant un sous-réseau pour une sécurité extrême. Groupes de sécurité sont légèrement différent. Les paramètres sortants sont tous ouverts par défaut. Ceci est basé sur l'hypothèse que les systèmes sous votre contrôle "font la bonne chose". S'ils ont besoin d'accéder à une ressource, laissez-les. Cependant, vous voudrez peut-être limiter un groupe de sécurité sortant lorsque vous souhaitez améliorer la sécurité. Mais, vous devriez généralement avoir une raison de le faire. les règles entrantes sur un groupe de sécurité doit toujours être aussi minime que possible. Exécuter un serveur Web? Ensuite, ouvrez 80 et / ou 443, probablement à quiconque sur Internet ( Les groupes de sécurité sont sotculez , ce qui signifie qu'une réponse autorisée dans le groupe de sécurité. Donc, si une connexion sortante est effectuée sur le port 8080 sur certains serveurs, la réponse est autorisée, même si ce port n'est pas répertorié dans la liste entrante des règles. Ainsi, en regardant votre configuration : 0.0.0.0/0 ). Permettre l'accès SSH? Ensuite, ouvrez le port 22, mais uniquement à votre propre adresse IP pour limiter la portée potentielle des attaques.
32768 (en dehors de SSH), cela signifie donc que tout le sous-réseau n'est pas accessible sur des ports tels que 80, 443, 8080, 3306 (mySQL), etc. C'est
Je comprends ce que vous essayez de dire mais je vous préoccupe vraiment lorsque quelqu'un applique une règle générale de "Autoriser tout". C'est un environnement très élevé de sécurité sans connexion générique et in / de sortie contrôlée. Je sais ce que j'ai besoin exactement de permettre, qui est également par sous-réseau. Il n'y a pas de SG ou de NaCl par défaut - Tous configuré sur mesure. Quoi qu'il en soit, ma seule préoccupation consiste à utiliser `0.0.0.0/0 'pour NaCL et pourquoi cela ne fonctionne qu'avec l'ouverture du monde. Si vous savez comment puis-je le limiter au strict minimum, cela aiderait beaucoup. Merci!
Lorsque vous dites "ça ne fonctionne que", quel service vous référenez-vous? Est-ce que c'est purement la connexion SSH? Et fais-vous référence aux règles de la NACL sortantes?
Ouais, je voulais dire SSH, dans ce cas. Et je parle de la connexion entrante et ouverte. La connexion SSH ne fonctionne que si je mettez 0.0.0.0/0 comme source de la connexion Ephemeral-Port Inbound Connexion et aussi pour Outbound Ouverture toute la gamme de ports. Cela ne fonctionne pas non plus même avec une plage de 1024 à 65535 pour la règle hors limite.
Voici les 2 suggestions qui fonctionneront:
Les ports éphémères sont de 1024 à 65535.
Tous ces ports doivent être autorisés, afin d'autoriser le trafic de retour pour SSH.
https: / /docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports
La plage autorisée peut être limitée uniquement à ces sous-réseaux à partir duquel SSH est autorisé.
Supposons que la machine client SSH soit sur le réseau de 192.168.1.0/24, puis
0.0.0.0/0 peut être remplacé par 192.168.1.0/24 dans le NaCL
Cela garantira que seul le client du réseau 192.168.1.0/24 peut faire SSH aux hôtes VPC.
C'était ma compréhension aussi, mais ne fonctionne pas pour moi si j'utilise toute autre chose pour les ports éphémères ( Inbound ou sortant ) autre que 0.0.0.0 / 0 . SSH cesse également de fonctionner si je n'attribuais pas l'ensemble de la gamme de ports en plus de cela. C'est exactement où je suis perdu.
Cela signifie que l'adresse IP source et le port du client se traduisent par un pare-feu / routeur NAT du réseau Enterprise. Par conséquent, l'IP source que la NaCl de AWS voit est différente de la source IP source visible sur l'ordinateur client.
HUMM ........ Pensé à cela aussi, mais si vous regardez dans la règle à venir, le port 22 est uniquement autorisé à partir de 10.0.12.0/28 comme La source et c'est exactement où le client-machine est in.or voulez-vous dire autre chose? J'ai commencé à penser si c'est quelque chose à voir avec la passerelle de transit à la place.
Transit Gateway n'aura que des associations de table de route. Les groupes NaCl et de sécurité ne s'appliquent pas. La cause probable du problème pourrait être avec le NaCl ou le groupe de sécurité ailleurs. Peut-être, une erreur d'essai et d'une erreur en permettant 10.0.0.0/16 ou 10.0.0.0/8 au lieu de 0.0.0.0/0 peut aider à résoudre les problèmes de dépannage. En outre, la vérification des bûches de flux VPC peut aider à la bropille à la broche où le paquet est rejeté.
Je viens de remarquer que si j'ajoute l'ensemble similaire de règles dans le NaCl par défaut, tout ce qui fonctionne sans problème. Le moment où je nie tout dans le par défaut ajoutez ces règles dans le sous-réseau spécifique au sous-réseau NaCl, il cesse de fonctionner. Une idée de ce que je manque toujours?
D'accord, répondez à ma propre question: il était en effet lié à la passerelle transitway code> que j'utilisais. Lorsque la connexion s'écoule à travers le TGW, une autre NaCl est requise (où les règles de NaCL par défaut sont supprimées) associant les sous-réseaux utilisés par le TGW avec ces règles: inbound:
500 | Custom TCP | Rule TCP (6) | 32768 - 61000 | 0.0.0.0/0 | ALLOW
outbound:
500 | Custom TCP | Rule TCP (6) | 0 - 65535 | 0.0.0.0/0 | ALLOW