AWS - Security (1): Security Group, ACL, VPC Flow Log

in DEV on DevOps, Aws, Security-group,, Acl,, Vpc-flow-log


이 포스트는 Security Group 과 Network ACL, 그리고 VPC Flow Log 에 대해 알아본 후 직접 구성하여 동작을 확인해본다.

아래는 이번 포스트에서 다뤄볼 범위 도식화이다.

이번 포스트 범위 도식화

1. Security Group 과 Network ACL

1.1. Access Control (접근 제어)

Access Control 은 식별(Identity) → 인증(Authentication) → 권한(Authorization) 의 절차로 수행된다.
여기서 대상을 식별하는 기준은 일반적으로 IP 주소나 프로토콜/포트 번호를 통해 서비스를 식별한다.

1.2. Security Group 과 Network ACL

AWS 에서 네트워크 인프라 보호를 위한 트래픽 제어 정책으로 Security Group 과 Network ACL 기능을 사용한다.
둘 다 IP 주소와 프로토콜/포트 번호를 통해 대상을 식별하고 제어 정책에 따라 대상의 허용 여부를 판단하며, 트래픽의 방향에 따라 Inbound rule 과 Outbound rule 로 나뉘어진다.

일반적으로 접근 제어 보안은 Security Group 을 통해 대부분 필터링한다.
하지만 IP 대역 레벨에서 차단이 필요할 경우엔 Network ACL 을 사용한다.
아무래도 Network ACL 은 Stateless 이기 때문에 Inbound/Outbound rule 설정에 민감하여 잘 사용하지 않는 편이다.

1.2.1. Security Group 과 Network ACL 차이

1) 트래픽 제어 대상

  • Security Group
    • Instance 레벨의 접근 제어
    • EC2 Instance 나 ALB 등과 같은 특정 대상에 대한 접근 제어 정책
  • Network ACL
    • Subnet 레벨의 접근 제어
    • VPC 내부에 생성한 Subnet Network 에 대한 접근 제어 정책

2) Stateful vs Stateless

Stateful
이전 상태 정보를 기억하고 있다가 다음 단계에서 그 상태 정보 활용

Stateless
이전 상태 정보를 기억하고 있지 않아 다음 단계에 관여하지 않음

  • Security Group
    • Stateful 접근 제어 동작
    • Inbound 로 들어오는 트래픽에 대해 Inbound rule 에 따라 대상이 허용되면 그 상태 정보를 기억해서 Outbound 로 되돌아갈 때(=리턴 트래픽) Outbound rule 에 상관없이 허용
  • Network ACL
    • Stateless 접근 제어 동작
    • Inbound 로 들어오는 트래픽에 대해 Inbound rule 에 따라 대상이 허용되어도 Outbound 로 되돌아갈 때 Outbound rule 에 따라 허용/거부가 결정됨

3) 허용/거부 규칙

  • Security Group
    • 허용 규칙만 존재하며 그 대상이 아닌 것은 자동으로 거부됨
  • Network ACL
    • 허용 규칙과 거부 규칙이 둘 다 존재
    • 규칙을 순차적으로 확인하기 때문에 순서를 확인하기 위한 시퀀스 넘버가 존재하며 가장 작은 숫자부터 순차적으로 확인
    • 각 규칙별로 대상의 허용/거부를 저장할 수 있으며, 매칭되는 대상이 있으면 하위 규칙은 더 이상 확인하지 않음
    • 마지막 규칙은 모든 트래픽에 대해 거부하는 규칙을 자동으로 가짐
      (규칙 번호: *, 모든 트래픽/모든 프로토콜/모든 포트번호/모든 소스 IP 는 DENY)

Security Group 규칙 리스트 Network ACL 규칙 리스트

2. VPC Flow Log

VPC Flow Log 는 VPC 에 속한 ENI (네트워크 인터페이스, Elastic Network Interface) 에서 송수신되는 트래픽에 대한 정보를 수집하는 기능이다.
VPC Flow Log 를 통해 네트워크 연결 문제, 보안 문제, 네트워크 접근 제어 정책의 정상 동작 여부 등을 확인할 수 있으며, 특정 유형의 트래픽을 감지하여 알람을 만들거나 트래픽의 변화와 패턴을 파악하기 위한 통계 지표도 만들 수 있다.

VPC Flow Log 도식화

위 그림처럼 Subnet A 의 Instance 하나만 대상으로 Flow Logs-A 그룹으로 생성하고, 발생한 Flow Log Record 를 S3 버킷에 쌓아둘 수 있다.
또는 Subnet B 의 Instance 2개를 Flow Logs-B 그룹으로 생성하고, 발생한 Flow Log Record 를 CloudWatch Logs 를 통해 게시할 수 있다.

VPC Flow Log 생성 후 데이터를 수집하여 Flow Log Record 를 제기하는데 1분 혹은 10분의 집계 기간에 따라 대기 시간이 소요될 수 있다. (=로그 정보를 실시간으로 게시하지 않음)

VPC 에서 Flow Log 를 활성화하면 대상 네트워크 인터페이스로 송수신되는 정보를 수집하는데 이 때의 정보 형태를 Flow Log Record 라 한다.

Flow Log Record 의 기본 형식은 아래와 같다.

<ver> <acco-id> <inf-id> <srcaddr> <dstaddr> <srcport> <estport> <prot> <pkts> <bytes> <start> <end> <act> <log-stat>

Record 
ver VersionVPC Flow Log 버전, 기본 형식은 Version 2
acco-id Account-ID소스 네트워크 인터페이스 소유자의 AWS 계정 ID
inf-id Interface-ID기록하는 네트워크 인터페이스 ID
srcaddr출발지 IP 주소
destaddr목적지 IP 주소
srcport출발지 포트 번호
destport목적지 포트 번호
prot Protocol대상 프로토콜 정보
pkts Packets전송된 패킷 수
bytes전송된 바이트 크기
start첫 번째 패킷이 집계된 시간
end마지막 패킷이 집계된 시간
act Action패킷에 대한 Accept(허용) 과 Reject(거부) 를 구분
log-statFlow Log 상태 (OK, NODATA, SKIPDATA)

VPC Flow Log Record 의 버전을 2가 아닌 3 or 4 로 지정하면 VPC-ID, Subnet-ID, Instance-ID, TCP-Flag, Region, AZ-ID 등 추가적인 필드 사용 가능

VPC Flow Log Record 예시

2.1. VPC Flow Log 사용 권한

VPC Flow Log 를 통해 VPC 로그 정보를 수집하려면 IAM (Identity & Access Management) 정책과 역할을 생성해야 한다.
3. Security Group 과 Network ACL 차이와 VPC Flow Log 테스트 를 진행하기 전에 VPC Flow Log 에 대한 권한을 생성하는 작업을 해야 한다.

VPC Flow Log 에 대한 권한 생성의 좀 더 자세한 내용은 VPC Flow Log IAM 권한 설정 을 참고하세요.

2.1.1 IAM Policy 생성

[IAM] - [Policies] - [Create policy] - [JSON tab 진입]

아래 내용으로 policy 생성

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

IAM Policy 생성

2.1.2. IAM Role 생성

[IAM] - [Roles] - [Create role] IAM Role 생성(1) - 사용 사례 선택 IAM Role 생성(2) - 권한 정책 연결 IAM Role 생성(3) - 역할 이름 생성

2.1.3. IAM Role 에서 신뢰 관계 설정

[IAM] - [Roles] - [위에서 생성한 role 선택] - [Trust relationships tab 진입] - [Edit trust policy]

아래 내용으로 policy update

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

2.1.4. CloudWatch Log Group 생성

[CloudWatch] - [Logs] - [Log groups] - [Create log group] CloudWatch Log Group 생성

3. Security Group 과 Network ACL 차이와 VPC Flow Log 테스트

Security Group 과 Network ACL 을 생성하여 동작을 차이를 이해하고, VPC Flow Log 를 통해 Record 를 수집 후 접속 허용과 거부를 확인해본다.

  • 기본 환경 구성
    • CloudFormation 적용
    • CloudFormation 을 통해 생성된 자원 확인
  • Security Group 을 통한 Access Control
    • Security Group - Inbound Stateful 검증
    • Security Group - Outbound Stateful 검증
    • VPC Flow Log 확인
  • Network ACL 을 통한 Access Control
    • Network ACL - Inbound Stateless 검증
    • Network ACL - Outbound Stateless 검증
  • Resource 삭제

목표 구성도

3.1. 기본 환경 구성

  • CloudFormation 적용
  • CloudFormation 을 통해 생성된 자원 확인

3.1.1. CloudFormation 적용

[CloudFormation] - [Stacks]

CloudFormation Template Download

CloudFormation Template (펼쳐보기)
Parameters:
  KeyName:
    Description: Name of an existing EC2 KeyPair to enable SSH access to the instances. Linked to AWS Parameter
    Type: AWS::EC2::KeyPair::KeyName
    ConstraintDescription: must be the name of an existing EC2 KeyPair.
  LatestAmiId:
    Description: (DO NOT CHANGE)
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'
    AllowedValues:
      - /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 20.0.0.0/16
      Tags:
        - Key: Name
          Value: jhMy-VPC

  MyIGW:
    Type: AWS::EC2::InternetGateway
    Properties:
      Tags:
        - Key: Name
          Value: jhMy-IGW

  MyIGWAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId: !Ref MyIGW
      VpcId: !Ref MyVPC

  MyPublicRT:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: jhMy-Public-RT

  DefaultPublicRoute:
    Type: AWS::EC2::Route
    DependsOn: MyIGWAttachment
    Properties:
      RouteTableId: !Ref MyPublicRT
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref MyIGW

  MyPublicSN:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      AvailabilityZone: !Select [0, !GetAZs '']
      CidrBlock: 20.0.0.0/24
      Tags:
        - Key: Name
          Value: jhMy-Public-SN

  MyPublicSNRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref MyPublicRT
      SubnetId: !Ref MyPublicSN

  ServerSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Server1 Security Group
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: jhServer-SG
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '22'
          ToPort: '22'
          CidrIp: 0.0.0.0/0

  ServerSG2:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Server2 Security Group
      VpcId: !Ref MyVPC
      Tags:
        - Key: Name
          Value: jhServer-SG-2
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '22'
          ToPort: '22'
          CidrIp: 0.0.0.0/0

  ServerEC2:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: !Ref LatestAmiId
      KeyName: !Ref KeyName
      Tags:
        - Key: Name
          Value: jhServer-EC2
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref MyPublicSN
          GroupSet:
            - !Ref ServerSG
          AssociatePublicIpAddress: true
          PrivateIpAddress: 20.0.0.10
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash
          hostname Server-EC2
          yum install httpd -y
          service httpd start
          chkconfig httpd on
          echo "<h1>Security Group & Network ACL TEST 1</h1>" > /var/www/html/index.html

  ServerEC22:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: !Ref LatestAmiId
      KeyName: !Ref KeyName
      Tags:
        - Key: Name
          Value: jhServer-EC2-2
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref MyPublicSN
          GroupSet:
            - !Ref ServerSG2
          AssociatePublicIpAddress: true
          PrivateIpAddress: 20.0.0.20
      UserData:
        Fn::Base64: !Sub |
          #!/bin/bash
          hostname Server-EC2-2
          yum install httpd -y
          service httpd start
          chkconfig httpd on
          echo "<h1>Security Group & Network ACL TEST 2</h1>" > /var/www/html/index.html

key pair 생성은 AWS - Infra 의 3. 사전 준비 를 참고하세요.

3.1.2. CloudFormation 을 통해 생성된 자원 확인

  • VPC
    • jhMy-VPC
      • IP CIDR: 20.0.0.0/16
  • Public Subnet
    • jhMy-Public-SN
      • IP CIDR: 20.0.0.0/24
      • AZ: ap-northeast-2a
  • Public Routing Table
    • jhMy-Public-RT
      • 연결: jhMy-Public-SN
      • 라우팅 정보: 대상: 0.0.0.0/0, 타깃: jhMy-IGW
  • IGW
    • jhMy-IGW
      • 연결: jhMy-VPC
  • Public EC2 Instance
    • jhServer-EC2
      • 연결: jhMy-Public-SN
      • Private IP: 20.0.0.10 (Public IP 사용)
      • 데몬: HTTP 구성
    • jhServer-EC2-2
      • 연결: jhMy-Public-SN
      • Private IP: 20.0.0.20 (Public IP 사용)
      • 데몬: HTTP 구성
  • Security Group
    • jhServer-SG
      • 연결: jhServer-EC2
      • inbound rule
        • SSH(Source) - 0.0.0.0/0
    • jhServer-SG-2
      • 연결: jhServer-EC2-2
      • inbound rule
        • SSH(Source) - 0.0.0.0/0

3.2. Security Group 을 통한 Access Control

  • Security Group - Inbound Stateful 검증
  • Security Group - Outbound Stateful 검증
  • VPC Flow Log 확인

Security Group 은 Stateful 한 접근 제어 동작을 한다. 이 기능을 확인하기 위해 jhServer-SG 의 Security Group 에서 Outbound rule 를 먼저 삭제한다.

Outbound rule 삭제

3.2.1. Security Group - Inbound Stateful 검증

jhServer-EC2 로 SSH 접속한다.

$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx
[ec2-user@Server-EC2 ~]$

왜 위처럼 정상 접근이 되는지 Security Group 의 Inbound rule 과 Outbound rule 을 대입해서 확인해보자. jhServer-SG Security Group 의 Inbound 동작 (SSH)

① jhServer-EC2 로 SSH 접근 시도 시 Security Group 의 Inbound rule 을 확인한다.
rule 에 매칭되는 대상이기 때문에 접근이 허용되고 jhServer-EC2 에 도달한다.
② 응답을 줄 때 Security Group 은 Stateful 하게 동작하므로 Inbound rule 에 허용된 대상은 Outbound rule 을 무시하고 전달한다.

3.2.2. Security Group - Outbound Stateful 검증

이제 jhServer-EC2 에서 외부 인터넷 구간의 HTTP 접근을 해본다.

$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx

[ec2-user@Server-EC2 ~]$ curl ifconfig.me --connect-timeout 3
curl: (28) Connection timeout after 3001 ms

외부 인터넷 구간으로 HTTP 접근 시도 시 실패하게 되는데 이는 Outbound rule 에 매핑되는 rule 이 없기 때문이다.

이제 Outbound rule 에 HTTP rule 을 추가해보자.

[EC2] - [Security Groups] - [jhServer-SG 선택] - [Outbound rules] - [Edit outbound rules] - [Add rule]

Outbound rule 에 HTTP 추가

이제 jhServer-EC2 에서 다시 외부 인터넷으로 HTTP 접근을 하면 정상적으로 접근되는 것을 확인할 수 있다.

[ec2-user@Server-EC2 ~]$ curl ifconfig.me --connect-timeout 3
43.201.46.149

ifconfig.me URL 은 접근한 사용자의 공인 IP 를 출력해주는 외부 웹 서버 주소

jhServer-SG Security Group 의 Outbound 동작 (HTTP)

① jhServer-EC2 로 SSH 접근 시도 시 Security Group 의 Outbound rule 을 확인한다.
rule 에 매칭되는 대상이기 때문에 접근이 허용되고 외부 웹 서버에 도달한다.
② 외부 웹 서버는 jhServer-EC2 로 응답을 주는데 Security Group 은 Stateful 하게 동작하므로 Outbound rule 에 허용된 대상은 Inbound rule 을 무시하고 전달한다.

즉, Security Group 는 최초 허용된 rule 의 대상이라면 반대 방향의 rule 은 상관없이 허용된다.

3.2.3. VPC Flow Log 확인

VPC Flow Log 를 활성화하여 Security Group 에 의해 허용/거부된 로그 정보들을 확인해본다.

3.2.3.1. VPC Flow Log 생성

[VPC] - [Virtual private cloud] - [jhMy-VPC 선택] - [Action] - [Create flow log]
VPC Flow Log 생성

[VPC] - [Virtual private cloud] - [jhMy-VPC 선택] - [Flow logs tab 진입]
위 메뉴에서 Destination name 을 클릭하면 CloudWatch 로 넘어가 생성된 로그 정보를 확인할 수 있다.

3.2.3.2. VPC Flow Log 확인 (거부 로그 레코드)

아직은 쌓인 로그가 없으므로 jhServer-EC2 로 HTTP 접근을 시도해본다.
현재 Inbound rule 에 SSH 규칙만 있고 HTTP 규칙은 없는 상태이므로 Security Group 에 의해 HTTP 접속은 불가하다.

접속이 거부된 것을 확인했으면 HTTP 접속 실패에 대한 Flow Log 를 확인해보자.
VPC Flow Log 는 VPC 내 Network Interface 별로 로그 정보를 수집한다. 확인할 대상은 jhServer-EC2 의 Network Interface 에 대한 정보이다.

[EC2] - [jhServer-EC2] - [Networking tab 진입] - [Network Interface ID 확인]

CloudWatch Log 에서 위에서 생성한 jh-Log-Group 에 들어가보면 바로 위에서 확인한 Network Interface ID 로 로그 스트림이 생성된 것을 확인할 수 있다. jhServer-EC2 에 대한 로그 스트림 확인

로그 스트림을 들어가보면 많은 로그가 나올텐데 본인의 공인 IP 로 필터링해서 보면 원하는 로그 레코드만 확인할 수 있다.

jhServer-EC2 에 대한 로그 이벤트 확인

아이피를 통해 사용자 PC 에서 jhServer-EC2 로 접근하는 것을 알 수 있고, 443 6 에서 443 은 포트 번호, 6 은 프로토콜 번호인데 TCP 를 의미한다.
REJECT 를 통해 해당 트래픽이 거부된 것을 확인할 수 있다.

3.2.3.3. VPC Flow Log 확인 (허용 로그 레코드)

이제 본인 PC 에서 jhServer-EC2 로 HTTP 접근을 허용하기 위해 Inbound rule 에 새로운 규칙을 추가한다.

[EC2] - [jhServer-EC2 선택] - [Security tab 진입] - [Inbound rules 의 Security Group 클릭] - [Inbound rules tab 진입]

  • Type: HTTP
  • Source: Anywhere IPv4

이제 jhServer-EC2 의 공인 IP 로 접속이 정상적으로 되는 것을 확인할 수 있다.

CloudWatch Log 에서 위에서 생성한 jh-Log-Group 에 들어간 후 jhServer-EC2 의 Network Interface ID 로 로그 스트림에서 본인 공인 IP 로 필터링해보자.

jhServer-EC2 에 대한 로그 이벤트 확인

3.3. Network ACL 을 통한 Access Control

  • Network ACL - Inbound Stateless 검증
  • Network ACL - Outbound Stateless 검증

Network ACL 테스트에 앞서 Security Group 이 Network ACL 기능 확인에 영향을 미치지 않도록 Security Group 의 Inbound/Outbound rule 모두 모든 트래픽 허용으로 변경한다.

[VPC] - [Security] - [Security groups] - [jhServer-SG, jhServer-SG-2]

Security Group 이 모든 트래픽 모든 대상 허용하도록 수정

위의 Inbound rule 을 수정한 것처럼 Outbound 도 수정한다.

현재의 Network ACL 은 Subnet 마다 기본 Network ACL 로 매핑되어 있고, 기본 Network ACL 은 Inbound/Outbound rule 모두 모든 트래픽을 허용하고 있다. 기본 Network ACL 확인

3.3.1. Network ACL - Inbound Stateless 검증

  • 신규 Network ACL 생성 (jhMy-NACL)
  • Inbound rule 에 SSH 정책 추가
  • Outbound rule 에 임시 포트 정책 추가

3.3.1.1. 신규 Network ACL 생성 (jhMy-NACL)

신규 Network ACL 을 생성하여 jhMy-VPC 의 Public Subnet 에 매핑한다.

[VPC] - [Security] - [Network ACLs] - [Create network ACL]

Network ACL 생성 후 클릭하여 들어간 후 Subnet associations 탭에 진입하여 jhMy-VPC 의 Public Subnet 을 추가한다.

생성한 Network ACL 의 Inbound/Outbound rules 를 보면 현재 모든 트래픽이 거부로 되어있다. jhMy-NACL 의 Inbound rule 확인

3.3.1.2. Inbound rule 에 SSH 정책 추가

사용자 PC 에서 내부 인스턴스로 SSH 접속을 하기 위해 Inbound rule 에 SSH 접근을 허용하는 규칙을 추가한다. jhMy-NACL 의 Inbound rule 에 SSH 추가

규칙 추가 후 사용자 PC 에서 jhServer-EC2 로 SSH 접속을 시도하면 접속이 되지 않는다.

jhMy-NACL 의 Inbound 트래픽 동작 확인 (거부)

① jhServer-EC2 로 SSH 접근 시도 시 Network ACL 의 Inbound rule 을 확인한다.
허용 규칙에 매칭되는 대상이므로 접근 허용이 되고 jhServer-EC2 에 도달한다.
② jhServer-EC2 는 사용자 PC 로 응답을 주는데 Network ACL 은 Stateless 하게 동작하므로 Outbound rule 을 확인한다.
거부 규칙에 매칭되는 대상이므로 해당 트래픽은 차단된다.

Network ACL Inbound rule 확인 후 Security Group Inbound rule 도 확인하며,
Security Group Outbound rule 확인 후 Network ACL Outbound rule 도 확인하는 절차를 따른다.

3.3.1.3. Outbound rule 에 임시 포트 정책 추가

사용자가 전달하는 타킷인 목적지 포트는 SSH 접근을 하기 위해 22번을 사용한다.
그럼 출발지 포트는 어떻게 될까? 출발지 포트는 임시 포트(Ephemeral port) 를 사용한다. 사용자의 OS 별로 사용하는 임시 포트 범위가 다르며 그 범위 내에서 랜덤하게 사용된다.

결국 Outbound rule 에서 허용한 포트 대상은 사용자의 출발지 포트 범위인 임시 포트 구간을 지정해야 하는데, 편의를 위해 Well-Known 포트 번호를 제외한 1024~65535 로 범위를 잡아보자.

jhMy-NACL 의 Outbound rule 에 규칙 추가

이제 사용자 PC 에서 jhServer-EC2 로 SSH 접속 시도 시 정상적으로 접속이 된다.

$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx
[ec2-user@Server-EC2 ~]$

jhServer-EC2-2 도 SSH 접속이 되는데 Network ACL 은 Subnet 레벨에서 접근 제어를 수행하므로 동일 Subnet 에 속한 jhServer-EC2, jhServer-EC2-2 모두 동일한 영향을 받는다.

jhMy-NACL 의 Inbound 트래픽 동작 확인 (허용)

3.3.2. Network ACL - Outbound Stateless 검증

  • Outbound rule 에 HTTP 규칙 추가
  • Inbound rule 에 임시 포트 정책 추가

jhServer-EC2 에서 외부 인터넷 구간으로 통신하는 Outbound 트래픽을 확인해본다.

jhServer-EC2 에 SSH 접근 후 외부 인터넷 구간의 HTTP 로 접근을 시도하면 접근이 되지 않는다.

$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx

[ec2-user@Server-EC2-2 ~]$ curl ifconfig.me --connect-timeout 3
curl: (28) Connection timeout after 3001 ms

jhMy-NACL 의 Outbound 트래픽 동작 확인 (거부)

목적지 포트가 80 이므로 거부 규칙에 해당하여 통신이 거부된다.

3.3.2.1. Outbound rule 에 HTTP 규칙 추가

jhServer-EC2 에서 외부 웹 서버로 HTTP 접근을 하기 위해 Network ACL 의 Outbound rule 에 HTTP 규칙을 추가한다.

[VPC] - [Security] - [Network ACLs] - [jhMy-NACL 선택] - [Outbound rules tab 진입]

jhMy-NACL 의 Outbound 에 HTTP 추가

아직 jhServer-EC2 에서 외부 인터넷 구간의 HTTP 접근은 되지 않는다.

jhMy-NACL 의 Outbound 트래픽 동작 확인 (거부)

① jhServer-EC2 에서 외부 웹 서버로 HTTP 접근 시도 시 Network ACL 의 Outbound rule 을 확인한다.
허용 규칙에 매칭되는 대상이므로 접근 허용이 되고 외부 웹 서버에 도달한다.
② 외부 웹 서버는 jhServer-EC2 로 응답을 주는데 이 때 목적지 포트 번호는 jhServer-EC2 가 보낸 출발지 포트인 임시 포트 번호로 전달한다.
Network ACL 은 Stateless 하게 동작하므로 Inbound rule 을 확인한다.
거부 규칙에 매칭되는 대상이므로 해당 트래픽은 차단된다.

3.3.2.2. Inbound rule 에 임시 포트 정책 추가

jhMy-NACL 의 Inbound 에 임시 포트 허용 규칙 추가

이제 jhServer-EC2 에서 외부 웹 서버로 HTTP 접근이 정상적으로 되는 것을 확인할 수 잇다.

$ ssh -i "sandbox-jh.pem" ec2-user@43.201.xx.xx

[ec2-user@Server-EC2-2 ~]$ curl ifconfig.me --connect-timeout 3
43.201.33.1

jhMy-NACL 의 Outbound 트래픽 동작 확인 (허용)

3.4. Resource 삭제

  • Network ACL 삭제 ([VPC] - [Security] - [Network ACLs])
    • Subnet associations tab 에서 연결된 subnet 삭제 후 Network ACLs 삭제
  • CloudWatch Logs Group 삭제 ([CloudWatch] - [Logs] - [Log groups])
  • IAM Role 삭제 ([IAM] - [Access management] - [Roles])
  • IAM Policy 삭제 ([IAM] - [Access management] - [Policies])
  • CloudFormation Stack 삭제 ([CloudFormation] - [Stacks] - [Delete])

CloudFormation Stack 이 삭제되면 위의 3.1.2. CloudFormation 을 통해 생성된 자원 확인 의 자원이 모두 삭제되었는지 확인한다.

참고 사이트 & 함께 보면 좋은 사이트

본 포스트는 김원일, 서종호 저자의 따라하며 배우는 AWS 네트워크 입문를 기반으로 스터디하며 정리한 내용들입니다.




© 2020.08. by assu10

Powered by assu10