👮🏻 Security Group & Network ACL

작성자 : gasida.cloudnet@

AWS Document

AWS Security Group (보안 그룹)
AWS Network Access Control List (네트워크 ACL)
보안 그룹과 네트워크 ACL 비교
VPC 보안 모범 사례
VPC 보안 예시

0. AWS Network Security

VPC 의 보안을 강화하고 모니터링 하기 위한 여러 기능이 제공
- Security Group
- Network ACL
- Network Security Check (Source Destination Check , Uncheck)
- VPC Flow Logs
- Traffic Mirroring

1. Security Group

1.1 Security Group (=보안 그룹) 소개

인스턴스(Instance) 에 대한 인바운드(Inbound) 및 아웃바운드(Outbound) 트래픽을 제어하는 가상 방화벽 역할
인바운드(Inbound) 트래픽을 제어하는 규칙과 아웃바운드(Outbound) 트래픽을 제어하는 규칙은 각각 동작
- 아웃바운드(Outbound) 는 별로 쓸모 없다
  
  → 🙅🏻‍♀️ 외부 접속 제한 이나 Security Group ID를 통하여 특정 EC2 만 접속 제한 활용 가능
🙋🏻‍♀️ 상태를 저장(Stateful) ← 매우 중요한 개념 ⇒ 아래 1.4 에서 확인
- 인스턴스에서 요청을 시작하면 해당 요청의 응답 트래픽은 인바운드 보안 그룹 규칙에 매칭되지 않아도 인바운드가 허용됨 (Allow Return Traffic)
  - Stateful 기능이 없을 경우 Stateless 라고 부르며 Network ACL이 대표적이다.
    - Network ACL 규칙은 요청 트래픽을 인바운드 규칙에 허용과 리턴 트래픽을 아웃바운드 규칙에 반드시 지정 필요.
허용(Allow) 규칙을 지정할 수 있지만 거부(Deny, Block) 규칙은 지정할 수 없음
구성 요소
- Inbound Rule : source address + destination port (range)
- Outbound Rule : destination address + destination port (range)
- IP Protocol : TCP, UDP…
- ICMP types and codes
🙋🏻‍♀️ EC2 의 Linux OS 에서 동작하는 iptables 와는 전혀 별개이다. ⇒ 아래 1.4.5) 에서 확인
- Security Group는 보통 Hypervisor 단에서 제공되어 지는 기능이다. → 아래 그림 1-1-1 확인
인스턴스에 최대 5개의 Security Group(=보안 그룹)을 할당할 수 있음
VPC는 자동으로 기본 보안 그룹을 제공. 기본 보안 그룹은 삭제할 수 없음

그림 1-1-1 보안그룹은 하이버바이저레벨에서 제공됨

1.2 Network ACL 소개

서브넷(Subnet) 기반의 인바운드(Inbound) 및 아웃바운드(Outbound) 트래픽을 제어하는 Second Level 보안 기능을 제공
인바운드(Inbound) 트래픽을 제어하는 규칙과 아웃바운드(Outbound) 트래픽을 제어하는 규칙은 각각 동작하나 밀접한 연관이 있음
보안 그룹(Security Group)과는 다르게 상태를 저장 하지 않음(Stateless)
- Network ACL 규칙은 요청 트래픽을 인바운드 규칙에 허용과 리턴 트래픽을 아웃바운드 규칙에 반드시 지정 필요
- 리턴 트래픽에 대한 제어를 위해서 휘발성 포트(Ephemeral port)에 대한 이해가 필요함 → 휘발성 포트 범위로 허용 필요
- 휘발성 포트(Ephemeral port, 혹은 ‘임시 포트’)
  - 예를 들면 웹클라이언트가 웹서버에 접속 시 웹서버는 TCP 80을 통하여 연결되고 웹클라이언트가 열게되는 임시 포트(예. TCP 52345) 를 Ephemeral port ‘잠시살아있는 포트’ 다.
  - 클라이언트에서 사용되는 임시 포트는 OS 별 범위가 다르다
  - 일반적으로 IANA권고 및 맥과 윈도우(49152~65535), Linux(32768~61000) → 아래 Code 창 확인
  - 임시 포트 관련 참고 링크
    - https://en.wikipedia.org/wiki/Ephemeral_port
    - https://www.cymru.com/jtk/misc/ephemeralports.html
    - https://www.cyberciti.biz/tips/linux-increase-outgoing-network-sockets-range.html
    1
    2
    3
    # 리눅스에서 사용되는 임시 포트(Ephemeral port) 범위 확인
    $ cat /proc/sys/net/ipv4/ip_local_port_range
    32768 60999
보안 그룹(Security Group)과는 다르게 허용 및 거부(차단) 규칙을 지정 가능
보안 그룹(Security Group)과는 다르게 Network ACL이 적용된 모든 서브넷 내부에 인스턴스(EC2)에 영향을 미침
- Network ACL은 여러 개의 서브넷에 연결될 수 있음
구성요소
- source (inbound) or destination (outbound) addresses (CIDR block)
- IP protocols (TCP, UDP…)
- destination port numbers
트래픽 허용 여부 판단 시 번호순번 대로의 규칙으로 처리함

그림 1-2 네트워크ACL은 서브넷(Subnet) 기반에서 동작

보안 그룹(Security Group) 과 네트워크 ACL 간 차이

1.3 실습을 위한 구성

1.3.1) Lab Topology

서울 Region 에 신규 VPC에 신규 EC2 Instance (웹 서버) 가 배치되어 있고 각자 자신의 집PC(HomePC)에서 EC2(웹 서버)를 접속한다

1.3.2) 구성을 위한 기본 설정

본 실습에서 활용할 AWS Region은 서울 입니다. 해당 Region에 대한 EC2-Key Pair를 생성
서울 Region 에 리소스는 CloudFormation에 의해 인프라를 자동 구축 (1.3.3항에서 진행)

1.3.3) CloudFormation

서울 Region에서 CloudFormation 스택을 생성한다.

1단계 템플릿 지정
- 템플릿 준비 : 준비된 템플릿
- 템플릿 소스 : Amazon S3 URL
- Amazon S3 URL : https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/NetworkSecurity/Network-Security_SecurityGroup.yaml
  - 우측 하단 다음 클릭
2단계 스택 세부 정보 지정
- 스택 이름 : SG
- KeyName : 자신의 EC2-Key Pair 를 지정
3단계 스택 옵션 구성
- 우측 하단 다음 클릭
4단계 검토
- 우측 하단 스택 생성 클릭

서울 CloudFormation 생성 인프라

- VPC, 1 Subnet, 1 IGW, 1 Route table
- Amazon Linux 2 EC2 Instance(Public IP, User data 사용)

1.3.4) 검증

사용자 PC에서 서울 EC2 Instance Public IP 주소로 SSH 접근한다. 접속 계정 root / qwe123
1
2
$ ssh root@13.209.10.34
root@13.209.10.34's password: qwe123

1.3.5) 실습 전 사전 설정

보안 그룹 '아웃바운드 규칙' 에서 기본 규칙을 삭제한다

보안 그룹 중 설명 ‘EC2-Instance-SG’ 클릭하여 선택 후 ‘아웃바운드 규칙’ 선택 후 ‘아웃바운드 규칙 편집’ 선택
- 기본 규칙을 삭제 - 유형(모든 트래픽) 대상(0.0.0.0) ⇒ 하단 규칙 저장

~~(옵션) VPC Flow Logs 를 설정한다 ← 이 부분은 IAM , CloudWatch 기본 지식이 필요함으로 필자만 설정하게되니 Skip 하면 된다~~

정보 숨김

EC2 ENI 에 VPC Flow Logs 설정
- Filter: Reject
- Interval : 1분
- Format : Custom format
- ${srcaddr} ${srcport} ${dstaddr} ${dstport} ${tcp-flags} ${protocol} ${action}
  - tcp-flags 참고
    - SYN : 2
    - SYN-ACK : 18
    - FIN : 1
    - RST : 4
- EC2 ENI 로그 발생 → 차단 발생 후 1분30초 후에 로그에 쌓임
CloudWatch Log 필터 참고
- “220.117.X.X” “10.40.1.100” ← 2개의 IP가 동시 일치 필터(AND)
- ?”220.117.X.X” ?”10.40.1.100” ← 2개의 IP중 하나만 일치 필터(OR)
- ?”80 2 6” ?”22 2 6” ← TCP 80 SYN 혹은 TCP 22 SYN 의 OR 필터
- “80 2 6” -“443” -“805” -“808” -“809” -“123” ← TCP 80 SYN 필터
- “22 2 6” -“443” -“805” -“808” -“809” -“123” ← TCP 22 SYN 필터
- “10.40.1.100” “80 2 6” -“443” -“805” -“808” -“809” -“123” ← EC2로 Web 시도 필터
- “10.40.1.100” “22 2 6” -“443” -“805” -“808” -“809” -“123” ← EC2로 SSH 시도 필터

1.4 Security Group 설정 및 확인

1.4.1) 현재 EC2 에 적용된 Security Group 확인

인바운드 규칙 : 해당 EC2에 SSH로 어느 사용자(0.0.0.0/0)든 접속 가능
아웃바운드 규칙 : 아무 정책이 없으므로 모든 트래픽을 차단

1.4.2) 외부에서 EC2로 SSH 접속 및 확인

(1) 외부(HomePC)에서 목적지IP를 EC2의 EIP(13.209.10.34)로 접속을 하면, 아래 그림 처럼 NAT 기능에 의해서 EC2 Private IP(10.40.1.100)으로 변환하게 됨
(2) 인바운드 규칙에 목적지Port 22와 출발지IP는 0.0.0.0/0 으로 허용이므로 EC2 내부로 전달함
(3) EC2 내부 어플리케이션(SSH)에서 처리 후 리턴 트래픽(Return Traffic)는 IP와 Port를 출발지와 목적지를 바꾼 후 되돌아간다
(4) 아웃바운드 규칙에 아무 규칙이 없으므로 원칙적으로는 모든 트래픽이 EC2에서 외부로 빠저나가지 못해야 하지만 빠져나간다 🤷🏻‍♀️
- 이유는 Stateful 동작에 의해 EC2로 인입 시 상태를 기억하고, 해당 트래픽이 리턴(Return) 시 해당 트래픽은 아웃바운드 규칙과 상관없이 허용됨

리턴 트래픽(Return Traffic)는 IP와 Port를 출발지와 목적지를 바꾼 후 되돌아간다

$ ssh root@13.209.10.34
root@13.209.10.34's password:
[root@SGLAB-EC2 ~]# netstat -nap | grep ESTABLISHED
tcp        0      0 10.40.1.100:22          220.117.X.X:54812   ESTABLISHED 338/sshd: root@pts/

Security%20Group%20Network%20ACL%20ea8e94b888d349f1bed19bff39f8cd54/Untitled%202.png

1.4.3) 내부 EC2에서 외부로 HTTP 접속 및 확인

내부 EC2에서 외부로 접속 시 아웃바운드 규칙에 의해서 차단됨

# curl ifconfig.me
curl: (7) Failed to connect to ifconfig.me port 80: Connection timed out

# netstat -nap |grep curl
tcp        0      1 10.40.1.100:34972       216.239.36.21:80        SYN_SENT    418/curl

현재 아웃바운드 규칙은 아무 규칙도 없음
(옵션) VPC Flow-logs 에도 내부EC2(10.40.1.100)이 외부(216.239.36.21)로 TCP 80 으로 접속 시도에서 차단(REJECT) 됨을 확인
위를 통하여 인바운드와 아웃바운드 규칙이 각기 개별로 동작하는 것을 알 수 있고, Stateful 동작을 알 수 있다

1.4.4) 내부 EC2에서 외부로 HTTP 접속 설정을 위한 아웃바운드 규칙 추가 및 확인

아웃바운드 규칙에 HTTP 접속을 추가한다

다시 내부에서 외부로 HTTP 접속을 시도한다 → 아래 처럼 정상적으로 응답이 돌아온다

1
2
3

# ifconfig.me 로 curl 시 자신의 PC가 인터넷 접속 시 자신의 공인IP를 알려줌
# curl ifconfig.me
13.209.10.34

아래 처럼 아웃바운드로 트래픽이 외부로 나갔다가 되돌아오는(Return) 트래픽은 인바운드 규칙에 없지만, Stateful 동작에 의해서 허용됨

💡 일반적으로 아웃바운드에 규칙을 잘 사용하지는 않지만, 보안 강화가 필요 시(예, 민감한 정보가 전달 등) 실제 해당 EC2에서 외부에 접속을 시도하는 TCP UDP 서비스 포트 혹은 외부 접속 지 IP 정보만 접속 할 수 있게 제한을 할 수 있다.

1.4.5) 외부에서 내부 EC2로 HTTP 접속을 위한 설정 및 확인

현재 상태에서 확인

내부 EC2 에서 웹서비스 상태 확인 → 정상 접속 되며, iptables 에 아무런 정책이 없음(즉 모두 허용)

# curl localhost
<html><h1>Hello from Security Group Test Web Server</h1></html>

# netstat -anp |grep http
tcp6       0      0 :::80                   :::*                    LISTEN      3563/httpd

# iptables -L -n -v
Chain INPUT (policy ACCEPT 208 packets, 14524 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 122 packets, 12192 bytes)
 pkts bytes target     prot opt in     out     source               destination

외부에서 EC2로 웹 접속 → 인바운드 규칙에 현재 TCP 22(SSH)만 허용되므로 차단됨

⇒ 즉, 현재 차단은 Linux OS의 iptables 와는 상관 없다는 것이다! , 물론 iptables 설정으로 차단할 수 있으나 운영 관리의 복잡성으로 비권장한다
1
2
$ curl 13.209.10.34
curl: (7) Failed to connect to 13.209.10.34 port 80: Operation timed out
(옵션) VPC Flow-logs 에도 차단(REJECT) 됨을 확인

인바운드 규칙에 HTTP 추가

외부에서 EC2로 웹 접속 → 성공!

1 2	$ curl 13.209.10.34 <html><h1>Hello from Security Group Test Web Server</h1></html>

아래 그림 처럼 (1) 외부에서 EIP로 HTTP로 접속되고 NAT 후 (2) 인바운드 규칙(TCP 80)에 허용되어 (3) EC2 내부로 인입되어 어플리케이션에서 처리 후 (4) 트래픽이 리턴 된다.

1.5 생성한 자원 삭제

서울 Region에서 CloudFormation 스택을 삭제한다

2. Network Access Control List

2.1 실습을 위한 구성

2.1.1) Lab Topology

서울 Region 에 신규 VPC에 신규 EC2 Instance (웹 서버) 2대가 배치되어 있고 각자 자신의 집PC(HomePC)에서 EC2(웹 서버)를 접속한다

2.1.2) 구성을 위한 기본 설정

본 실습에서 활용할 AWS Region은 서울 입니다. 해당 Region에 대한 EC2-Key Pair를 생성
서울 Region 에 리소스는 CloudFormation에 의해 인프라를 자동 구축 (2.1.3항에서 진행)

2.1.3) CloudFormation

서울 Region에서 CloudFormation 스택을 생성한다.

1단계 템플릿 지정
- 템플릿 준비 : 준비된 템플릿
- 템플릿 소스 : Amazon S3 URL
- Amazon S3 URL : https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/NetworkSecurity/Network-NetworkACL.yaml
  - 우측 하단 다음 클릭
2단계 스택 세부 정보 지정
- 스택 이름 : NACL
- KeyName : 자신의 EC2-Key Pair 를 지정
3단계 스택 옵션 구성
- 우측 하단 다음 클릭
4단계 검토
- 우측 하단 스택 생성 클릭

서울 CloudFormation 생성 인프라

- VPC, 1 Subnet, 1 IGW, 1 Route table
- Amazon Linux 2 EC2 Instance(User data 사용) - 2대

2.1.4) 검증

사용자 PC에서 서울 EC2(2대)의 Public IP 주소로 각각 SSH 접근한다. 접속 계정 root / qwe123
1
2
$ ssh root@*'EC2 Public IP'*
root@*'EC2 Public IP'*s password: qwe123

2.1.5) 실습 전 사전 설정

보안 그룹 '인바운드 규칙' 과 '아웃바운드 규칙' 은 '모두 허용' 되고 있음을 확인 → Network ACL 실습에 영향도를 제거하기 위함

Security%20Group%20Network%20ACL%20ea8e94b888d349f1bed19bff39f8cd54/Untitled%207.png

Security%20Group%20Network%20ACL%20ea8e94b888d349f1bed19bff39f8cd54/Untitled%208.png

~~(옵션) VPC Flow Logs 를 설정한다 ← 이 부분은 IAM , CloudWatch 기본 지식이 필요함으로 필자만 설정하게되니 Skip 하시면 된다~~

정보 숨김

Subnet(SGLAB2-Subnet0101) 에 VPC Flow Logs 설정
- Filter: Reject
- Interval : 1분
- Format : Custom format
- ${srcaddr} ${srcport} ${dstaddr} ${dstport} ${tcp-flags} ${protocol} ${action}
  - tcp-flags 참고
    - SYN : 2
    - SYN-ACK : 18
    - FIN : 1
    - RST : 4
- EC2 ENI 로그 발생 → 차단 발생 후 1분30초 후에 로그에 쌓임
CloudWatch Log 필터 참고
- “220.117.X.X” “10.40.1.100” ← 2개의 IP가 동시 일치 필터(AND)
- ?”220.117.X.X” ?”10.40.1.100” ← 2개의 IP중 하나만 일치 필터(OR)
- ?”80 2 6” ?”22 2 6” ← TCP 80 SYN 혹은 TCP 22 SYN 의 OR 필터
- “80 2 6” -“443” -“805” -“808” -“809” -“123” ← TCP 80 SYN 필터
- “22 2 6” -“443” -“805” -“808” -“809” -“123” ← TCP 22 SYN 필터
- “10.40.1.100” “80 2 6” -“443” -“805” -“808” -“809” -“123” ← EC2로 Web 시도 필터
- “10.40.1.100” “22 2 6” -“443” -“805” -“808” -“809” -“123” ← EC2로 SSH 시도 필터

2.2 Network ACL 설정 및 확인

2.2.1) 현재 Subnet(SGLAB2-Subnet0101) 에 적용된 Network ACL 확인

(default) Network ACL 인바운드 규칙 : 기본적으로 ‘rule #100 모든 트래픽을 허용’ 함, 맨 하단은 모두 차단으로 우선 순서가 낮아서 현재 적용되지 않음
(default) Network ACL 아웃바운드 규칙 : 위 인바운드 규칙과 동일, 모든 트래픽을 허용

2.2.2) 신규 Network ACL 생성 적용 및 확인

[VPC - 보안 - 네트워크 ACL] 상단 네트워크 ACL 생성 클릭
- 이름 태그 : NACL1
- VPC : (SGLAB2) 선택
  - 하단 생성 클릭
[VPC - 보안 - 네트워크 ACL] 생성된 NACL1 선택 → 상단 작업 선택 → 서브넷 연결 편집 클릭
- 아래 처럼 10.41.0.0/24 서브넷은 연결 해주기 위해서 선택 후 하단 편집 클릭
[VPC - 보안 - 네트워크 ACL] 생성된 NACL1 선택 후 default 규칙 확인
- 신규 생성된 Network ACL 인바운드 규칙 : 인입되는 모든 트래픽을 차단
- 신규 생성된 Network ACL 아웃바운드 규칙 : 인입되는 모든 트래픽을 차단

2.2.3) NACL1 Network ACL 규칙 편집 1

목적 : 외부에서 EC2대역에 대한 SSH 접속을 허용 (Network ACL inbound outbound rule)
NACL Name: NACL1 선택 후 Inbound Rule (인바운드 규칙) 편집
- 규칙(10), 유형(SSH) - 프로토콜(TCP), 포트범위(22), 소스(0.0.0.0/0), 허용/거부(ALLOW)
  - 포트범위는 트래픽 인입 시 목적지 포트 범위이다
  - 소스IP는 트래픽 인입 시 출발지IP 범위이다
    - 이후 저장 시 최하단에 모든 트래픽을 거부 DENY Rule 이 존재한다
- 아웃바운드 규칙도 기본(디폴트)로 모든 트래픽을 거부 DENY Rule 이 존재한다
외부에서 EC2 로 SSH 접속 확인
- 외부에서 EC2 SSH 접속이 불가능하다
  1
  2
  3
  4
  5
  HomePC$ ssh root@13.125.132.54
  ssh: connect to host 13.125.132.54 port 22: Operation timed out
  
  HomePC$ ssh root@52.78.166.174
  ssh: connect to host 52.78.166.174 port 22: Operation timed out
  - (옵션) Cloudwatch 에도 EC2로 인입되었지만 리턴 트래픽(TCP-SYN 은 18로 표현)이 outbound rule 에 의해서 REJECT 됨을 확인
  - 이유 : inbound rule 허용되지만 이후 응답 트래픽이 outbound rule 에 의해 차단
    
    ⇒ 보안 규칙(Security group)과는 다르게 Stateful 하지 않고, Stateless 하기 때문에 리턴 트래픽에 대한 허용을 아웃바운드 규칙에 추가해야 한다
트래픽 흐름에 따른 설명
- (1) 외부(HomePC)에서 EC2의 PublicIP(13.125.132.54)로 SSH 접속을 시도한다
- (2) NAT 기능에 의해서 목적지 PublicIP(13.125.132.54) 를 PrivateIP(10.40.1.100)으로 변경한다
- (3) Network ACL에 의해서 출발지IP가 0.0.0.0/0 이고 목적지 포트 SSH 22 이므로 허용(ALLOW) 된다
- (4) EC2 내부의 SSH 어플리케이션이 처리 한다
- (5) 리턴 트래픽이므로 출발지와 목적지의 IP와 Port 가 뒤바뀌어 전달된다
- (6) 리턴 트래픽이 Network ACL 아웃바운드에 규칙에 의해서 차단 된다

2.2.4) NACL1 Network ACL 규칙 편집 2 - Stateless 이므로 리턴 트래픽(Return)에 대한 허용 추가

NACL Name: NACL1 선택 후 Outbound Rule (아웃바운드 규칙) 편집
- 규칙(110), 유형(사용자지정TCP규칙) - 프로토콜(TCP), 포트범위(32768-65535), 대상(0.0.0.0/0), 허용/거부(ALLOW)
  - 포트범위는 돌아가는 트래픽의 목적지 포트 범위이다 → 맥 윈도우 리눅스의 모든 임시 포트 범위를 포함한 범위
    - 외부에서 SSH 로 접속 시 클라이언트의 소스 포트는 임시 포트(Ephemeral port 잠시살아있는 포트) 이다
      - 클라이언트에서 사용되는 임시 포트는 OS별 범위가 다르다
      - 일반적으로 IANA권고 및 맥과 윈도우(49152~~65535), Linux(32768~~61000)
  - 대상는 돌아가는 트래픽의 목적지IP 범위이다
    - 이후 저장 시 최하단에 모든 트래픽을 거부 DENY Rule 이 존재한다
아웃바운드 규칙에 아래와 같이 설정이 된다

외부에서 내부의 EC2 2대 모두로 SSH 접속 확인

외부에서 EC2 SSH 접속이 가능하다 → HomePC의 소스포트를 보면 임시포트 중 랜덤하게 할당해서 접속한 것을 알 수 있다

HomePC$ ssh root@13.125.132.54
[root@SGLAB2-EC2-1 ~]# netstat -anp |grep 220.117
tcp        0      0 10.41.1.100:22          220.117.X.X:55260   ESTABLISHED 3775/sshd: root@pts

HomePC$ ssh root@52.78.166.174
[root@SGLAB2-EC2-2 ~]# netstat -anp |grep 220.117
tcp        0      0 10.41.1.200:22          220.117.X.X:52255   ESTABLISHED 3815/sshd: root@pts

트래픽 흐름에 따른 설명
- (1) 외부(HomePC)에서 EC2의 PublicIP(13.125.132.54)로 SSH 접속을 시도한다. HomePC 자신의 소스포트는 임시포트 범위 중 랜덤 선택한다
- (2) NAT 기능에 의해서 목적지 PublicIP(13.125.132.54) 를 PrivateIP(10.40.1.100)으로 변경한다
- (3) Network ACL에 의해서 출발지IP가 0.0.0.0/0 이고 목적지 포트 SSH 22 이므로 허용(ALLOW) 된다
- (4) EC2 내부의 SSH 어플리케이션이 처리 한다
- (5) 리턴 트래픽이므로 출발지와 목적지의 IP와 Port 가 뒤바뀌어 전달된다
- (6) 리턴 트래픽이 Network ACL 아웃바운드에 규칙에 허용되어 통과한다 → 목적지 포트 55260 이 32768~65535 범위에 속함
- (7) 소스IP가 PublicIP로 NAT(변경)되어 HomePC로 도착하여 처리가 된다

💡 위 상황에서도 EC2 간에는 모든 트래픽 통신이 가능하다. 현재 보안그룹(Security group)는 ‘All Traffic 허용’ 상태이고 Network ACL은 10.41.0.0/24(Subnet)에서 다른 대역과 통신 시에만 적용이 되기 때문이다. 예) [root@SGLAB2-EC2-1 ~]# ping 10.41.1.200 → ping ok

2.2.5) NACL1 Network ACL 규칙 편집 3

목적 : 외부에서 EC2대역에 대한 HTTP 접속을 허용

현재는 외부(HomePC) 에서 EC2(웹서버)로 HTTP 접속이 차단됨

HomePC$ curl 13.209.84.198
curl: (7) Failed to connect to 13.209.84.198 port 80: Operation timed out

HomePC$ curl 52.79.50.197
curl: (7) Failed to connect to 52.79.50.197 port 80: Operation timed out

NACL Name: NACL1 선택 후 Inbound Rule (인바운드 규칙) 편집
- 규칙(20), 유형(HTTP) - 프로토콜(TCP), 포트범위(80), 소스(0.0.0.0/0), 허용/거부(ALLOW)
  - 이후 저장 시 최하단에 모든 트래픽을 거부 DENY Rule 이 존재한다
NACL Name: NACL1 선택 후 Outbound Rule (아웃바운드 규칙)
- 이미 위에서 임시포트에 대한 허용이 있으므로 추가 설정 필요 없음

확인

외부에서 EC2 HTTP 접속이 가능하다

HomePC$ curl 13.209.84.198
<html><h1>Hello from Network ACL Test Web Server 1 - IP 10.41.1.100</h1></html>

HomePC$ curl 52.79.50.197
<html><h1>Hello from Network ACL Test Web Server 2 - IP 10.41.1.200</h1></html>

하지만 아직도 내부인 EC2에서 외부로 인터넷도 차단됨
- ec2$ curl www.google.com

2.2.6) NACL1 Network ACL 규칙 편집 4

목적 : 내부 EC2 에서 외부로 인터넷 접속 및 다운로드 가능 (패치 작업 등 필요)

현재는 내부인 EC2에서 외부로 인터넷 접속이 차단됨

[root@SGLAB2-EC2-1 ~]# curl ifconfig.me
curl: (7) Failed to connect to ifconfig.me port 80: Connection timed out

[root@SGLAB2-EC2-2 ~]# curl ifconfig.me
curl: (7) Failed to connect to ifconfig.me port 80: Connection timed out

NACL Name: NACL1 선택 후 Outbound Rule (인바운드 규칙) 편집
- 규칙(120), 유형(HTTP) - 프로토콜(TCP), 포트범위(80), 소스(0.0.0.0/0), 허용/거부(ALLOW)
- 규칙(130), 유형(HTTPS) - 프로토콜(TCP), 포트범위(443), 소스(0.0.0.0/0), 허용/거부(ALLOW)
  - EC2 입장에서 자신이 클라이언트가 되어서 외부에 인터넷 웹서버에 접속을 시도 시에 대한 허용
  - 이후 저장 시 최하단에 모든 트래픽을 거부 DENY Rule 이 존재한다
NACL Name: NACL1 선택 후 Inbound Rule (인바운드 규칙) 편집
- 규칙(30), 유형(사용자지정TCP규칙) - 프로토콜(TCP), 포트범위(32768-61000), 소스(0.0.0.0/0), 허용/거부(ALLOW)
  - 리턴트래픽을 인바운드규칙에 허용되게 Amazon Linux 사용하는 임시 포트(Ephemeral port) 범위를 지정한다
    1
    2
    [root@SGLAB2-EC2-1 ~]# cat /proc/sys/net/ipv4/ip_local_port_range
    32768 60999
  - 이후 저장 시 최하단에 모든 트래픽을 거부 DENY Rule 이 존재한다

확인

내부 EC2 에서 외부로 HTTP 접속이 가능하다

[root@SGLAB2-EC2-1 ~]# curl ifconfig.me
13.209.84.198
[root@SGLAB2-EC2-1 ~]# curl https://checkip.amazonaws.com/
13.209.84.198

[root@SGLAB2-EC2-2 ~]# curl ifconfig.me
52.79.50.197
[root@SGLAB2-EC2-2 ~]# curl https://checkip.amazonaws.com/
52.79.50.197

최종 Network ACL 규칙 확인

인바운드 규칙

아웃바운드 규칙

2.3 생성한 자원 삭제

신규 생성한 NACL1 Network ACL 을 삭제한다
서울 Region에서 CloudFormation 스택을 삭제한다

3. Security Group ID 를 활용한 보안 규칙

3.1 Security Group ID 를 활용한 보안 규칙 소개

보안그룹 인바운드 규칙의 소스와 아웃바운드 규칙의 대상에 IP 대신 보안그룹ID(=Security Group ID)를 사용 할 수 있다
통제하려는 IP 대상이 유동적일 경우에 활용 할 수 있다. 예) EC2 오토스케일 환경
- (오토 스케일 그룹 : 웹서버1-10.1.1.1 웹서버2-10.1.1.2 웹서버3-10.1.1.3 …) ⇒ DB서버 10.2.1.11
- 기존에 DB서버의 인바운드 규칙에 10.1.1.1~3 현재 3개의 IP만 접속이 되게 설정되어 있다
- 하지만 사용자 트래픽의 증가에 따라서 웹서버4(10.1.1.4)가 신규 배치가 되면 DB서버 인바운드 규칙에 10.1.1.4/32 를 추가해줘야 한다
- 위 와 같이 IP대상이 유동적일 경우에는 DB서버의 인바운드 규칙에 IP List 대신 웹서버가 사용하는 Security Group ID를 사용하면 된다.
- 즉, DB서버의 경우 인입되는 소스IP를 웹서버에 연결된 Security Group ID를 사용하는 모든 웹서버를 허용해주게 된다.
- 그럼 신규 웹서버4번이 생성되더라도 기존 웹서버와 동일한 Security Group ID 를 사용하니 DB서버 입장에서 허용하게 된다.
아래는 DB서버에 인바운드 규칙에 소스를 IP기반으로 설정 시

아래는 DB서버에 인바운드 규칙에 소스를 Security Group 기반으로 설정 시

3.2 실습을 위한 구성 - 웹과 DB간 보안 설정 예시

3.2.1) Lab Topology

서울 Region 에 신규 VPC에 신규 EC2 Instances (웹 서버 2대, DB 1대) 가 배치되어 있고 각자 자신의 집PC(HomePC)에서 EC2(웹 서버)를 접속한다.

3.2.2) 구성을 위한 기본 설정

본 실습에서 활용할 AWS Region은 서울 입니다. 해당 Region에 대한 EC2-Key Pair를 생성
서울 Region 에 리소스는 CloudFormation에 의해 인프라를 자동 구축 (3.2.3항에서 진행)

3.2.3) CloudFormation

서울 Region에서 CloudFormation 스택을 생성한다.

1단계 템플릿 지정
- 템플릿 준비 : 준비된 템플릿
- 템플릿 소스 : Amazon S3 URL
- Amazon S3 URL : https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/NetworkSecurity/Network-SGID.yaml
  - 우측 하단 다음 클릭
2단계 스택 세부 정보 지정
- 스택 이름 : SGID
- KeyName : 자신의 EC2-Key Pair 를 지정
3단계 스택 옵션 구성
- 우측 하단 다음 클릭
4단계 검토
- 우측 하단 스택 생성 클릭

서울 CloudFormation 생성 인프라

- VPC, 1 Subnet, 1 IGW, 1 Route table
- Amazon Linux 2 EC2 Instance 3대 (Public IP, User data 사용 - 웹서버2대, DB서버1대

3.2.4) 검증

사용자 PC에서 서울 EC2(3대) Instances Public IP 주소로 SSH 접근한다. 접속 계정 root / qwe123
1
2
$ ssh root@13.209.10.34
root@13.209.10.34's password: qwe123

Web1 과 Web2 EC2에서 DB EC2(10.42.1.200) 로 mysql 접속. DB 접속 계정 gasida / qwe123

[root@WEB1 ~]# mysql -h 10.42.1.200 -P 3306 -ugasida -pqwe123
Welcome to the MariaDB monitor.  Commands end with ; or \g.
..
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sample             |
+--------------------+
4 rows in set (0.00 sec)

Web1 과 Web2 의 PublicIP 로 웹 접속 시 index.php 페이지에서 mysql DB로 연결된 화면 출력 확인 → 참고 링크

Web - DB 간 연결이 정상일 경우 아래와 같은 화면이 출력된다
Name 과 ADDRESS 에 값을 추가 후 왼쪽에 Add Data 클릭 시 실제 DB에 table 에 반영된다

DB 테이블 확인

[root@WEB1 ~]# mysql -h 10.42.1.200 -P 3306 -ugasida -pqwe123
Welcome to the MariaDB monitor.  Commands end with ; or \g.
..
MariaDB [(none)]> SHOW DATABASES;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sample             |
+--------------------+
4 rows in set (0.00 sec)

MariaDB [(none)]> USE sample;

MariaDB [sample]> SHOW tables;
+------------------+
| Tables_in_sample |
+------------------+
| EMPLOYEES        |
+------------------+
1 row in set (0.00 sec)

MariaDB [sample]> SELECT * FROM EMPLOYEES;
+----+--------+------------------+
| ID | NAME   | ADDRESS          |
+----+--------+------------------+
|  1 | gasida | samsung-dong 123 |
|  2 | ongja  | suwon 111        |
+----+--------+------------------+
2 rows in set (0.00 sec)

3.2.5) 실습 전 사전 설정

현재 적용된 보안 그룹 과 Network ACL 을 확인한다

3.3 Security Group ID 를 활용한 보안 규칙 설정 - 웹과 DB간 보안 설정 예시

3.3.1) 보안 요구 조건

외부 → 웹서버
- 외부의 인터넷 사용자는 웹브라우저로 웹서버로 접속이 가능해야함 - TCP 80(HTTP)
- 외부에 있는 관리자는 웹서버 관리를 위해서 SSH로 접속이 가능해야함 - TCP 22(SSH)
웹서버 → 외부
- 웹서버는 보안 패치 등 필요로 인해 외부에서 업데이트 및 다운로드가 가능해야함 - TCP 80(HTTP) 443(HTTPS)
웹서버 → DB서버
- 웹서버들만 DB서버에 mysql 접속이 가능해야함 - TCP 3306(MYSQL) ⇒ Security Group ID 를 활용할 예정
DB서버 → 외부
- DB서버는 보안 패치 등 필요로 인해 외부에서 업데이트 및 다운로드가 가능해야함 - TCP 80(HTTP) 443(HTTPS)
외부 → DB서버
- 일반적인 환경에서는 DB서버에 외부에서 직접 접속을 하지 않는다. 다만 실습의 편의를 위해서 외부에서 SSH접속을 허용함

3.3.2) ‘외부 → 웹서버’ 보안 요구 조건 관련 보안그룹 설정 및 확인

이미 Cloudformation 배포 시 웹서버에 인바운드 보안규칙에 HTTP, SSH 에 대한 접속이 가능하게 설정되어 있다
트래픽 흐름에 따른 설명
- (1) 외부(HomePC)에서 EC2의 PublicIP로 HTTP 혹은 SSH 접속을 시도한다. HomePC 자신의 소스포트는 임시포트 범위 중 랜덤 선택한다. NAT 기능에 의해서 목적지 IP는 PublicIP 를 PrivateIP(10.42.1.100 혹은 10.42.1.101)로 변경된다. Web 보안그룹 인바운드 규칙에 허용되어 EC2 내부에서 처리한다
- (2) 리턴 트래픽은 출발지와 목적지의 IP와 Port 가 뒤바뀌어 전달된다. 보안그룹으로 리턴 트래픽은 자동으로 허용되어 사용자에게 도달한다

3.3.3) ‘웹서버 → 외부’ 보안 요구 조건 관련 보안그룹 설정 및 확인

보안 요구 조건 : 웹서버는 보안 패치 등 필요로 인해 외부에서 업데이트 및 다운로드가 가능해야함 - TCP 80(HTTP) 443(HTTPS)
Web 보안그룹 아웃바운드 규칙 변경 → TCP 80(HTTP) 443(HTTPS) 제외한 나머지 트래픽은 차단
- 기존의 ‘모든 트래픽 허용’ 규칙은 삭제한다
- HTTP 와 HTTPS 를 허용하는 규칙을 추가한다

‘웹서버 → 외부’ 로 HTTP or HTTPS 통신 허용을 확인한다

# 아래 처럼 HTTP HTTPS는 외부 통신이 허용된다
[root@WEB1 ~]# curl -O http://example.com/foo.txt --silent
[root@WEB1 ~]# curl -O https://example.com/bar.txt --silent
[root@WEB1 ~]# ls *.txt
bar.txt  foo.txt

# 아래 처럼 HTTP HTTPS 이외에 다른 트래픽은 외부로 통신이 차단된다
[root@WEB1 ~]# ping -c 1 -W 1 www.google.com
PING www.google.com (172.217.25.68) 56(84) bytes of data.
--- www.google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

[root@WEB1 ~]# ssh root@10.42.1.101
ssh: connect to host 10.42.1.101 port 22: Connection timed out

트래픽 흐름에 따른 설명
- (1) 웹서버(EC2)에서 인터넷(HTTP HTTPS)에 접속을 시도한다. Web보안그룹 아웃바운드 규칙에 의해서 허용되어
- (2) 리턴 트래픽은 출발지와 목적지의 IP와 Port 가 뒤바뀌어 전달된다. 보안그룹으로 리턴 트래픽은 자동으로 허용되어 사용자에게 도달한다

3.3.4) ‘웹서버 → DB서버’ 보안 요구 조건 관련 보안그룹 설정 및 확인

보안 요구 조건 : 웹서버들만 DB서버에 mysql 접속이 가능해야함 - TCP 3306(MYSQL) ⇒ Security Group ID 를 활용할 예정
Web 보안그룹 아웃바운드 규칙 변경 → TCP 3306(MYSQL) 대상(DB서버) 허용
- 유형(MYSQL) , 대상(DB서버에 적용되어 있는 보안그룹 ID) 를 지정하여 규칙을 추가한다
DB 보안그룹 인바운드 규칙 변경 → TCP 3306(MYSQL) 소스(웹서버) 허용
- 유형(MYSQL), 소스(웹서버에 적용되어 있는 보안그룹 ID) 를 지정하여 규칙을 변경한다

‘웹서버 → DB서버’ 로 MYSQL 접속을 확인한다

[root@WEB1 ~]# mysql -h 10.42.1.200 -P 3306 -ugasida -pqwe123
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 19
Server version: 5.5.64-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>

트래픽 흐름에 따른 설명
- (1) 웹서버에서 DB서버로 접속을 시도한다. (목적지) 대상이 보안그룹(DB서버)로 향하기 때문에 허용된다
- (2) DB서버로 인입되는 트래픽의 소스가 보안그룹 (웹서버)를 사용함으로 허용된다.
- (3) DB서버 내부에서 처리 후 리턴 트래픽은 아웃바운드 규칙과 상관없이 빠져나간다
- (4) DB서버에서 돌아오는 트래픽은 웹서버 역시 리턴트래픽으로 인바운드 규칙과 성관없이 허용되어 최종적으로 웹서버에 돌아온다

3.3.5) ‘DB서버 → 외부’ 보안 요구 조건 관련 보안그룹 설정 및 확인 ⇒ 3.3.3) 항목과 동일한 설정

보안 요구 조건 : DB서버는 보안 패치 등 필요로 인해 외부에서 업데이트 및 다운로드가 가능해야함 - TCP 80(HTTP) 443(HTTPS)
DB 보안그룹 아웃바운드 규칙 변경 → TCP 80(HTTP) 443(HTTPS) 제외한 나머지 트래픽은 차단
- 기존의 ‘모든 트래픽 허용’ 규칙은 삭제한다
- HTTP 와 HTTPS 를 허용하는 규칙을 추가한다
‘DB서버 → 외부’ 로 HTTP or HTTPS 통신 허용을 확인한다

3.3.6) 최종 설정된 보안그룹 확인

웹서버 보안그룹 인바운드 규칙
웹서버 보안그룹 아웃바운드 규칙
DB서버 보안그룹 인바운드 규칙
DB서버 보안그룹 아웃바운드 규칙

3.4 생성한 자원 삭제

서울 Region에서 CloudFormation 스택을 삭제한다

CloudNet@

👮🏻 Security Group & Network ACL

0. AWS Network Security

1. Security Group

1.1 Security Group (=보안 그룹) 소개

1.2 Network ACL 소개

1.3 실습을 위한 구성

1.4 Security Group 설정 및 확인

1.5 생성한 자원 삭제

2. Network Access Control List

2.1 실습을 위한 구성

2.2 Network ACL 설정 및 확인

2.3 생성한 자원 삭제

3. Security Group ID 를 활용한 보안 규칙

3.1 Security Group ID 를 활용한 보안 규칙 소개

3.2 실습을 위한 구성 - 웹과 DB간 보안 설정 예시

3.3 Security Group ID 를 활용한 보안 규칙 설정 - 웹과 DB간 보안 설정 예시

3.4 생성한 자원 삭제

4. Network Security Check (Source Destination Check , Uncheck) - 향후 내용 추가 예정