Ich mache einen Kurs über AWS. Ich versuche, ein VPC mit zwei Linux-Servern einzurichten. Ich habe das VPC mit zwei Subnetzen eingerichtet. Ich habe in jedes einen Server eingefügt. Die Idee ist, dass ein Subnetz öffentlich und das andere privat ist.
Ich habe zwei Netzwerk-ACLs erstellt und jedem Subnetz eine zugeordnet.
Ich kann von meinem Rechner aus per SSH auf den Server im öffentlichen Subnetz zugreifen. Wenn ich von dort aus per SSH auf den Server in meinem privaten Subnetz versuche, tritt ein Verbindungstimeout auf.
Ich bin nicht sicher, welche Regeln ich in meinen beiden Netzwerk-ACLs festlegen muss, damit SSH funktioniert. Kann mir jemand helfen? Da ich noch lerne, wäre ich für eine Erklärung dankbar, warum die Regeln gelten sollten, und nicht nur, was die Regeln sein sollten.
Ich habe ein VPC namens MyVPC mit CIDR 10.0.0.0/16.
Mein erstes Subnetz heißt MyVPCSub1 CIDR 10.0.1.0/24.
Mein zweites Subnetz heißt MyVPCSub2 CIDR 10.0.2.0/24.
Ich habe eine Routentabelle namens MyInternetRoute, die mit MyVPCSub1 verknüpft ist. Die Routen sind:
|Dest |Targ |
|10.0.0.0/16 |local |
|0.0.0.0/0 |igw |
Ich habe eine Routentabelle namens MyPrivate, die mit MyVPCSub2 verknüpft ist. Die Routen sind:
|Dest |Targ |
|10.0.0.0/16 |local |
Ich habe eine Netzwerk-ACL namens MyWeb, die mit MyVPCSub1 verknüpft ist und die folgenden Regeln enthält:
Eingehende:
| # | Type | Protocol | Ports | Source | A/D
| 99 | HTTP | TCP | 80 | {My IP}/32 | D
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A
| 200 | HTTPS| TCP | 443 | 0.0.0.0/0 | A
| 300 | SSH | TCP | 22 | {My IP}/32 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Hinreise:
| # | Type | Protocol | Ports | Source | A/D
| 50 | ALL | ALL | ALL | 0.0.0.0/0 | A
| 100 | HTTP | TCP | 80 | 0.0.0.0/0 | A
| 200 | HTTPS | TCP | 443 | 0.0.0.0/0 | A
| 300 | Custom | TCP | 1024-65535 | 0.0.0.0/32 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Ich habe eine Netzwerk-ACL namens MyPrivate, die mit MyVPCSub2 verknüpft ist und die folgenden Regeln enthält:
Eingehende:
| # | Type | Protocol | Ports | Source | A/D
| 100 | ALL | ALL | ALL | 0.0.0.0/0 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Hinreise:
| # | Type | Protocol | Ports | Source | A/D
| 100 | ALL | ALL | ALL | 0.0.0.0/0 | A
| * | ALL | ALL | ALL | 0.0.0.0/0 | D
Antwort1
Als Erstes muss die Bedeutung einiger Begriffe definiert werden.
NACLS - Network Access Control Lists, sind eine staatlichewenigerPaketfilter, der auf Subnetzebene angewendet wird. Der „zustandslose“ Aspekt ist wichtig zu beachten. Dies bedeutet, dass Sie für den gesamten Datenverkehr, der in das Subnetz eingeht und es verlässt, explizit sein müssen. Beispielsweise können Sie mit einem „zustandsvollen“ Regelansatz (den die Sicherheitsgruppe in AWS anwendet) einfach den eingehenden Datenverkehr von TCP/22 für SSH angeben und der ausgehende Datenverkehr wird automatisch zugelassen. Bei NACLS ist dies nicht der Fall. Sie müssen in jede Richtung eine Regel angeben, damit der Datenverkehr passieren kann.
Sicherheitsgruppen - das sind Gruppen von staatlichvollRegeln, die auf eine oder mehrere Instanzen in einer VPC angewendet werden können. Beachten Sie, dass sie auf Instanzebene gelten. Die Sicherheitsgruppe kann mit einer herkömmlichen State-Full-Firewall verglichen werden, aber da sie auf der Ebene der einzelnen Instanzen angewendet wird, können Sie Instanzen sogar innerhalb desselben Subnetzes voneinander trennen, was praktisch ist. Und da sie State-Full sind, müssen Sie sich nicht darum kümmern, eine entsprechende Ausgangsregel zu erstellen, wenn Sie Datenverkehr in einen Server zulassen möchten (z. B. TCP/22 für SSH). Die Plattform kümmert sich automatisch darum, sodass sie viel einfacher zu verwalten sind – was auch eine geringere Fehlerwahrscheinlichkeit bedeutet.
Es gibt eine schöne Tabelle, die diese beiden vergleicht:VPC-Sicherheitsvergleich
Auf der Seite gibt es außerdem ein nettes Diagramm, das die Reihenfolge zeigt, in der die Dinge je nach Verkehrsflussrichtung angewendet werden. Schauen Sie sich das also an.
Dann haben wir in Bezug auf Subnetze:
Öffentliches Subnetz - in AWS-Begriffen ist dies einfach ein Subnetz, an das eine Routentabelle angehängt ist, die eine 0.0.0.0/0-Route über ein angeschlossenes Internet-Gateway hat.
Privates Subnetz - das ist das Gegenteil, d.h. esnichthaben Sie eine 0.0.0.0/0-Route über ein angeschlossenes Internet-Gateway. Beachten Sie, dass es in Ihrer Umgebung immer noch eine 0.0.0.0/0-Route über ein NAT-Gateway oder einen ähnlichen Proxy geben kann, nur nicht direkt.
Die Frage ist, welche NACLS und Sicherheitsgruppen Sie verwenden. AWS beschreibt NACLs als „optionale Sicherheitsebene für Ihr VPC“. Und es stimmt, dass Sicherheitsgruppen im Allgemeinen ausreichen, sie sind flexibler und bieten den gleichen Schutz. Meiner Erfahrung nach gibt es jedoch einige typische Fälle, in denen NACLS verwendet wird:
- Schwarze Löcher für bekannte böswillige Akteure – wenn Sie aus einem bestimmten IP-Bereich angegriffen wurden, können Sie ganz einfach eine NACL hinzufügen, die die IP-/Subnetzquelle vollständig blockiert.
- Um die Kontrolle an Teams zu delegieren, wendet das Sicherheitsteam grobe NACL-Konfigurationen an (lässt beispielsweise nur Datenverkehr aus vertrauenswürdigen Unternehmensnetzwerken zu) und erlaubt dann den Betriebs-/Entwicklungsteams, ihre eigenen Sicherheitsgruppenregeln zu konfigurieren. Selbst wenn der Ingenieur dann versucht, die Sicherheitsgruppe auf seiner Instanz zum Testen für das Internet zu öffnen, wird dies von NACL blockiert. Sie können IAM verwenden, um einzuschränken, wer NACLs ändern kann, aber den Teams Zugriff gewähren, um alles andere zu kontrollieren. Dies ist ein hervorragender Schutz gegen Konfigurationsfehler in größeren Umgebungen.
AWS stellt außerdem einige Anleitungen zu einer Reihe von Konfigurationsszenarien bereit, die hier verfügbar sind:Empfohlene Netzwerk-ACL-Regeln für Ihr VPC
Mein Rat ist jedoch, dass Sicherheitsgruppen normalerweise einen angemessenen Schutz bieten, einfacher zu verstehen und zu konfigurieren sind und in ihrer Anwendung flexibler und granularer sind. NACLs bieten Ihnen zwar diesen zusätzlichen Schutz gegen menschliches Versagen oder erweiterte Konfigurationen, werden aber für den Basisgebrauch normalerweise nicht verwendet. Daher nehme ich an, warum AWS sie als „optional“ bezeichnet.
Ich würde NACLs in ihrer Standardkonfiguration belassen (den gesamten eingehenden und ausgehenden Datenverkehr zulassen) und mich stattdessen vorerst auf Sicherheitsgruppen konzentrieren, da die Verwendung von NACLs als zweite Ebene nur eine zusätzliche Komplexitätsebene hinzufügt, die in Ihrem Szenario möglicherweise nicht erforderlich ist. Aus Lernperspektive ist es gut zu wissen, dass sie vorhanden sind, dass sie zustandslos sind, dass sie auf Subnetzebene gelten und dass sie nach der Routing-Entscheidung und vor Sicherheitsgruppen für den in ein Subnetz eingehenden Datenverkehr gelten.
In Bezug auf Ihre spezielle Situation, weil Sie NACLs verwenden, müssen Sie bedenken, dass es sich um staatlicheweniger. Daher müssen alle Verkehrsflüsse in und aus dem Subnetz berücksichtigt werden – der Hauptgrund, warum Sicherheitsgruppen so viel einfacher sind. In Ihrem Fall haben Sie also:
- Datenverkehr in Ihren öffentlichen Server über TCP/22 von Ihrer IP - ja - Regel Nr. 300 eingehend
- Geben Sie den Datenverkehr von Ihrem öffentlichen Server auf einem hohen Port für den zurückgegebenen SSH-Datenverkehr zurück – ja – Regel Nr. 50 ausgehend (aber nicht Regel Nr. 300 – siehe unten)
- Datenverkehr von Ihrem öffentlichen Subnetz ausgehend zu Ihrem privaten Subnetz über TCP/22 - ja - Regel Nr. 50 ausgehend
- Datenverkehr, der vom öffentlichen Subnetz in das private Subnetz eingeht - ja - Regel Nr. 100 eingehend
- Leiten Sie den Verkehr von Ihrem privaten Server an den öffentlichen Server im privaten Subnetz zurück - ja - Regel Nr. 100 ausgehend
- Leiten Sie den Verkehr von Ihrem privaten Server an den öffentlichen Server auf deröffentlichSubnetz – ah – nein, es gibt keine Regel, die den hohen Port (den temporären Port, den der SSH-Client auf dem öffentlichen Server verwendet, um die Verbindung zum privaten Server herzustellen) vom privaten Server wieder zulässt.
Sie müssen eine Regel wie Regel Nr. 300 (aber beachten Sie, dass Sie die Quell-IP leicht falsch formatiert haben – siehe unten) zu Ihrer ausgehenden öffentlichen Subnetz-ACL hinzufügen, aber in Richtung, mit einer Quelle des privaten Subnetzes. Vorausgesetzt, Ihre Sicherheitsgruppen sind gut konfiguriert, sollte alles gut gehen.
Hoffentlich hilft das.
Um hinzuzufügen – wie in der anderen Antwort –, dass Regel Nr. 300 im ausgehenden Regelsatz des öffentlichen Subnetzes falsch formatiert ist. Sie sollte 0.0.0.0/0 und nicht 0.0.0.0/32 sein, aber in Ihrem Fall haben Sie das nicht erreicht, da Regel Nr. 50 zuerst erreicht wird und ohnehin den gesamten Datenverkehr zulässt – obwohl es also nicht funktionieren würde, hat es Ihr Problem nicht wirklich verursacht.
Antwort2
ACLs sind zustandslos.
Ihr „öffentliches“ Subnetz blockiert wahrscheinlich den Rückweg für Ihre SSH-Verbindung vom privaten Subnetz. Sie benötigen für alle Ports auf der eingehenden Seite ebenfalls eine Regel, die Ihrer ausgehenden entspricht. Sie könnten diese jedoch auf den Subnetzbereich 10.0.2.0/24 beschränken.
Bearbeitet, um hinzuzufügen: Außerdem ist die Ausgangsregel für 0.0.0.0/32 einfach falsch. Wenn Ihre IP nicht genau 0.0.0.0 ist, wird es nicht funktionieren.