☰

프라이빗 서브넷에 대한 SSH용 AWS 네트워크 액세스 제어 목록을 설정하는 방법

tag-icon • tag-icon ssh amazon-web-services access-control-list amazon-vpc
프라이빗 서브넷에 대한 SSH용 AWS 네트워크 액세스 제어 목록을 설정하는 방법

저는 AWS에서 강좌를 진행하고 있습니다. 제가 하려는 작업은 두 개의 Linux 서버로 VPC를 설정하는 것입니다. 두 개의 서브넷으로 VPC를 설정했습니다. 각 서버마다 하나씩 배치했습니다. 아이디어는 하나의 서브넷이 공개이고 다른 하나가 비공개라는 것입니다.

두 개의 네트워크 ACL을 생성하고 각 서브넷에 하나씩 연결했습니다.

내 컴퓨터에서 퍼블릭 서브넷의 서버로 SSH를 통해 연결할 수 있습니다. 여기에서 개인 서브넷의 서버로 SSH를 시도하면 연결 시간 초과가 발생합니다.

SSH가 작동하려면 두 개의 네트워크 ACL에 어떤 규칙을 설정해야 하는지 잘 모르겠습니다. 누구든지 도와줄 수 있나요? 제가 배우고 있다는 점을 감안할 때 규칙이 무엇이어야 하는지뿐만 아니라 규칙이 왜 있어야 하는지에 대한 설명을 고맙게 생각합니다.

CIDR 10.0.0.0/16이 포함된 MyVPC라는 VPC가 있습니다.
첫 번째 서브넷은 MyVPCSub1 CIDR 10.0.1.0/24입니다.
두 번째 서브넷은 MyVPCSub2 CIDR 10.0.2.0/24입니다.
MyVPCSub1 경로와 연결된 MyInternetRoute라는 경로 테이블이 있습니다.

|Dest        |Targ  |  
|10.0.0.0/16 |local |
|0.0.0.0/0   |igw   |

MyVPCSub2 경로와 연결된 MyPrivate라는 경로 테이블이 있습니다.

|Dest        |Targ  |
|10.0.0.0/16 |local |

규칙을 사용하여 MyVPCSub1과 연결된 MyWeb이라는 네트워크 ACL이 있습니다.

인바운드:

| #   | 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

배 밖으로:

| #   | 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

규칙을 사용하여 MyVPCSub2와 연결된 MyPrivate라는 네트워크 ACL이 있습니다.

인바운드:

| #   | 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

배 밖으로:

| #   | 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

답변1

첫 번째는 일부 용어의 의미를 정의하는 것입니다.

NACLS - 네트워크 액세스 제어 목록은 국가-더 적은서브넷 수준에서 적용되는 패킷 필터입니다. '상태 비저장' 측면을 염두에 두는 것이 중요합니다. 이는 서브넷에 들어오고 나가는 모든 트래픽에 대해 명시적이어야 함을 의미합니다. 예를 들어, '상태 전체' 규칙 접근 방식(AWS의 보안 그룹이 적용되는 방식)을 사용하면 SSH용 TCP/22의 인바운드 트래픽을 지정하기만 하면 아웃바운드 트래픽이 자동으로 허용됩니다. NACLS의 경우에는 그렇지 않습니다. 트래픽 통과를 허용하려면 각 방향에서 규칙을 지정해야 합니다.

보안 그룹 - 이는 국가 그룹입니다.가득한VPC에 있는 하나 이상의 인스턴스에 적용할 수 있는 규칙입니다. 인스턴스 수준에서 적용됩니다. 보안 그룹은 기존의 상태 전체 방화벽과 비교할 수 있지만 개별 인스턴스 수준에서 적용되므로 동일한 서브넷 내에서도 인스턴스를 서로 분리할 수 있다는 점이 좋습니다. 그리고 상태가 완전하기 때문에 서버(예: SSH의 경우 TCP/22)로의 트래픽을 허용하려는 경우 해당 아웃바운드 규칙을 만드는 것에 대해 걱정할 필요가 없습니다. 플랫폼이 이를 자동으로 처리하므로 관리하기가 훨씬 쉽습니다. 즉, 오류가 발생할 가능성도 적습니다.

이 두 가지를 비교하는 멋진 테이블이 있습니다.VPC 보안 비교

해당 페이지에는 흐름 방향에 따라 트래픽에 적용되는 순서를 보여주는 멋진 다이어그램도 있으므로 확인해 보세요.

그런 다음 서브넷 측면에서 다음과 같은 결과를 얻습니다.

퍼블릭 서브넷 - AWS 용어로 이는 연결된 인터넷 게이트웨이를 통해 0.0.0.0/0 경로가 있는 연결된 라우팅 테이블이 있는 단순한 서브넷입니다.

프라이빗 서브넷 - 이는 반대입니다.그렇지 않다연결된 인터넷 게이트웨이를 통해 0.0.0.0/0 경로가 있어야 합니다. 사용자 환경에서 NAT 게이트웨이 또는 유사한 프록시를 통해 0.0.0.0/0 경로를 가질 수 있지만 직접 경로는 있을 수 없습니다.

문제는 NACLS와 보안 그룹이 있을 때 어느 것을 사용하느냐는 것입니다. AWS는 NACL을 "VPC에 대한 선택적 보안 계층"으로 설명합니다. 그리고 일반적으로 보안 그룹이면 충분하며, 더 유연하고 동일한 보호를 제공한다는 것은 사실입니다. 내 경험에 따르면 NACLS가 사용되는 몇 가지 일반적인 경우가 있습니다.

  1. 알려진 악의적 행위자를 위한 블랙홀 - 특정 IP 범위에서 공격을 받은 경우 IP/서브넷 소스를 완전히 차단하는 NACL을 추가하는 쉬운 접근 방식입니다.
  2. 팀에 제어를 위임하는 방법으로 보안 팀은 광범위한 브러시 NACL 구성(예: 신뢰할 수 있는 기업 네트워크의 트래픽만 허용)을 적용한 다음 운영/개발 팀이 자체 보안 그룹 규칙을 구성할 수 있도록 허용합니다. 이렇게 하면 엔지니어가 테스트를 위해 인스턴스의 보안 그룹을 인터넷에 공개하려고 시도하더라도 NACL이 이를 차단합니다. IAM을 사용하면 NACL을 수정할 수 있는 사람을 제한할 수 있지만 팀에 다른 모든 것을 제어할 수 있는 액세스 권한을 부여할 수 있습니다. 이는 대규모 환경에서 구성 오류 오류에 대한 훌륭한 백업 역할을 합니다.

AWS는 또한 여기에서 사용할 수 있는 다양한 구성 시나리오에 대한 몇 가지 지침을 제공합니다.VPC에 권장되는 네트워크 ACL 규칙

하지만 제 지침은 일반적으로 보안 그룹이 적절한 보호를 제공하고, 이해 및 구성이 더 쉽고, 애플리케이션이 더 유연하고 세부적이라는 것입니다. NACL은 사람의 실수나 고급 구성에 대한 추가 백스톱을 제공하지만 기본 용도로는 일반적으로 사용되지 않습니다. 따라서 AWS가 이를 "선택 사항"이라고 부르는 이유를 가정합니다.

NACL을 기본 구성(모든 트래픽 들어오고 나가는 허용)으로 두고 대신 보안 그룹에 집중하겠습니다. NACL을 두 번째 레이어로 사용하면 시나리오에 필요하지 않은 추가 복잡성 레이어만 추가되기 때문입니다. 학습 관점에서 볼 때, 존재하고, 상태가 없으며, 서브넷 수준에서 적용되고, 라우팅 결정 후와 트래픽의 보안 그룹이 서브넷에 진입하기 전에 적용된다는 것을 아는 것이 좋습니다.

특정 상황과 관련하여 NACL을 사용하고 있으므로 해당 상태가 다음과 같다는 점을 기억해야 합니다.더 적은. 따라서 서브넷 안팎으로의 모든 트래픽 흐름을 고려해야 합니다. 이는 보안 그룹이 훨씬 더 쉬운 주된 이유입니다. 따라서 귀하의 경우에는 다음이 있습니다.

  • IP에서 TCP/22의 공용 서버로 트래픽이 발생합니다. - 예 - 규칙 #300 인바운드
  • 반환 SSH 트래픽에 대한 높은 포트의 공용 서버에서 반환 트래픽 - 예 - 규칙 #50 아웃바운드(그러나 규칙 #300은 아님 - 아래 참조)
  • 퍼블릭 서브넷에서 TCP/22의 프라이빗 서브넷으로 아웃바운드되는 트래픽 - 예 - 규칙 #50 아웃바운드
  • 퍼블릭 서브넷에서 프라이빗 서브넷으로 인바운드되는 트래픽 - 예 - 규칙 #100 인바운드
  • 개인 서버에서 개인 서브넷의 공용 서버로 트래픽을 반환합니다. - 예 - 규칙 #100 아웃바운드
  • 개인 서버에서 공용 서버로 트래픽을 반환합니다.공공의서브넷 - 아 - 아니요, 높은 포트(ssh 클라이언트가 개인 서버에 대한 연결을 시작하기 위해 공용 서버에서 사용하는 임시 포트)를 개인 서버에서 다시 허용하는 규칙은 없습니다.

아웃바운드 퍼블릭 서브넷 ACL에 규칙 #300과 같은 규칙을 추가해야 합니다(단, 소스 IP 형식이 약간 잘못되었습니다. 아래 참조). 그러나 인바운드에는 프라이빗 서브넷의 소스가 있습니다. 그런 다음 보안 그룹이 잘 구성되어 있다고 가정하면 계속 진행하는 것이 좋습니다.

도움이 되길 바랍니다.

다른 답변에 따라 퍼블릭 서브넷의 아웃바운드 규칙 세트에 규칙 #300을 추가하려면 형식이 잘못되었습니다. 0.0.0.0/32가 아니라 0.0.0.0/0이어야 합니다. 그러나 귀하의 경우에는 규칙 #50이 먼저 적중되고 어쨌든 모든 트래픽을 허용하므로 해당 사항을 적용하지 않았습니다. 따라서 작동하지 않지만 실제로 문제를 일으키는 것은 아닙니다.

답변2

ACL은 상태 비저장입니다.

"퍼블릭" 서브넷이 프라이빗 서브넷에서 SSH 연결을 위한 반환 경로를 차단하고 있을 수 있습니다. 인바운드 측의 모든 포트에 대해서도 아웃바운드와 동일한 규칙이 필요하지만 이를 서브넷 범위 10.0.2.0/24로 제한할 수 있습니다.

추가하도록 편집됨: 또한 0.0.0.0/32에 대한 아웃바운드 규칙이 잘못되었습니다. IP가 정확히 0.0.0.0이 아니면 작동하지 않습니다.

관련 정보