뚜기의 S 톨이

Create Customer Gateways set

    - BGP 연동을 위한 게이트웨이를 설정한다. 

• VPC -> Customer Gateways -> Create Customer Gateways

• Routing : Dynamic
• BGP ASN : 65000 (default)
  
• IP : F50B Firewall Public IP (wan1에 설정한 IP입력)

Virtual Private Gateways set

    - AWS의 Virtual Private Gateway를 생성한다.
            ※ 이미 같은 VPC로 생성되어 있으면 추가 작업 없이 VPN Connections 설정으로 간다.

1. VPC -> Virtual Private Gateways -> Create Virtual Private Gateway
2. VPC -> Virtual Private Gateways -> Attach to VPC
   

VPN Connections set  

    - AWS와 F50B 장비간의 VPN 접속을 위한 세팅을 한다.

• VPC -> VPN Connections ->Create VPN Connection
• BGP를 통한 접속이므로 Use dynamic routing 으로 선택하여야 한다.
  
  

• BGP 및 IPsec 설정을 위한 confiruration을 제공하며 사용자 벤더에 맞는 항목을 선택하여 다운받으면 된다. (기본적으로 Generic을 선택하면 됨)
  

F50B Firewall set

    - AWS와 F50B 장비간의 VPN 접속을 위한 세팅을 하며, 다운받은 Configuration 파일을 참조하여 설정한다.
    일반적인 셋팅 순서는 다음과 같으며 Tunnel 1, Tunnel 2 두 개의 Connection 을 설정하면 된다.

1. Router -> Dynamic -> BGP Setting
2. VPN -> IPsec -> Auto Key(IKE) Setting
3. System -> Network -> Interface -> IP Setting
4. Policy Setting
   

• Router -> Dynamic -> BGP Setting

#1

#2

• VPN -> IPsec -> Auto Key(IKE) Setting (Phase1과 Phase2는 1세트로 구성)
  
• Create Phase1 (2set)
  
• Create Phase2 (2set)
  

    - Create Phase1

#1

#2

    - Name : Nickname
    - IP Address : Virtual Private Gateway (Outside AWS IP)
    - Local Interface : wan1 (F50B External Interface)
    - Mode : Main
    - Authentication Method : Preshared Key
    - Pre-shared Key : (refer to BGP configuration)
    - Advanced Setting : (refer to Image)

    - Create Phase2

    - Name : Nickname

    - Phase 1 : choose Phase1

    - Advanced Setting : (refer to Image)

• System -> Network -> Interface -> IP Setting

• Policy Setting
• Inbound / Outbound : any all

    - 여기까지가 BPG 및 IPsec 설정이 다 끝났으며 AWS에서 VPN Connection이 정상적으로 되었는지 확인한다.

• Check the VPN Connection (AWS)

AWS를 처음 접할 때 많이 헷갈려 하는 부분이 바로 Network ACL과 Security Group일겁니다.

일반적으로 생각하는 방화벽과는 조금 다른 기능이라 그런 것 같습니다.

그리하여 오늘은 두 개의 보안 설정에 대한 개념정리를 해보겠습니다.

참고로 Network ACL은 VPC가 구성 되어야만 사용이 가능합니다.

VPC를 잠깐 설명드리자면 클라우드 환경에서 실제 IDC환경과 동일한 가상의 IDC환경을

구축 할 수 있도록 제공하는 기능입니다.

Network ACL은 외부간 통신을 담당하는 보안기능으로 서브넷 단위로 설정이 가능하며, Security Group는 내부간 통신을 담당하며 서버 단위로 정책을 설정할 수 있습니다.

Network ACL과 Security Group의 전체적인 그림을 설명드리겠습니다.

경우1. 외부에서 접근

외부에서 서버로 접근하기 위해서는 Network ACL의 보안정책과 하위의 Security Group 보안정책에 적용됩니다.

경우2. 내부통신

동일 서브넷의 내부통신은 Security Group 보안정책만 적용됩니다.

여기까지만 보면 일반적인 보안이랑 크게 차이가 나지 않습니다.

하지만, Network ACL은 특정 포트와 통신 하기 위해서는 인바운드/아웃바운드 두 개의 정책을 다 써야한다고

명시되어 있습니다.

Network ACL은 기본적으로 인/아웃이 차단되어 있습니다.

예를 들어 80포트를 허용하였을 경우 방화벽의 경우는 아웃바운드가 차단이 되어도 외부에서 80포트로 접속하는데

문제가 되지 않지만, ACL의 경우는 아웃바운드가 차단이 되어 있으면 통신이 되지 않습니다.

위 이미지의 마지막 줄을 보시면 아웃바운드에 1024-65535 포트를 허용하라고 되어있습니다.

웹 서비스를 하기 위해서는 Network ACL의 인바운드/아웃바운드 정책이 하기 이미지와 같아야 합니다.

즉, 응답하는 서버의 sport도 허용 해주어야 통신이 됩니다.

여기에서 왜 1024-65535 포트를 허용하여야 하는지 궁금하신 분들도 계실겁니다.

위에서 언급한 것처럼 Stateless는 세션을 기억하지 않기 때문에 요청에 대한 응답을 할 경우 응답하는 대상의 Source Port 범위인 1024-65535를 추가 해주어야 한다는 말입니다.

그럼 Network ACL과 Security Group이 어떻게 동작하는 지 Case By Case로 알아보겠습니다.

위의 경우는 일반적인 사용자가 서버에 접근할 때 적용되는 정책입니다.

외부에서 요청이 오면 Network ACL 정책을 먼저 거친 후 Security Group 정책을 거치게 되며,

서버측 응답은 Security Group의 아웃바운드 정책은 거치지 않고 Network ACL정책만 거친 후 사용자에게 응답합니다.

여기서 주의 해야할 점은 Network ACL의 아웃바운드 정책에 1024-65535 정책이 없으면 응답을 할 수 없게 되는 것이죠..

위의 경우는 같은 서브넷에 서버가 존재할 경우는 Security Group정책만 따르게 됩니다.

위의 경우는 통신할 서버가 다른 서브넷에 존재할 경우 Case1 번과 같은 조건이기 때문에 1번과 동일하게 동작합니다.

내부에서 외부로 나가는 경우는 위 3개의 Case와 반대로 생각하시면 됩니다.

위의 경우는 서버에서 외부로 접속을 시도할 때 Security Group의 아웃바운드 정책을 먼저 거친 후 Network ACL의 정책을 거치게 됩니다. 그리고 응답을 받을 때엔 Network ACL의 인바운드 정책만 적용이 됩니다.

여기서 주의해야 할 점은 Network ACL의 인바운드 정책에 1024-65535 정책이 있어야만 통신이 됩니다.

Case 2번과 동일합니다.

Case 4번과 동일합니다.

1. 서브넷이 다를 경우

: Network ACL 정책이 적용 됨

2. 서브넷이 같을 경우

: Security Group 정책만 적용 됨

3. Network ACL

: Stateless 기반으로 인바운드 / 아웃바운드 정책에 1024-65535 포트에 대하여 허용하여야 통신이 가능하다.

4. Security Group

: 방화벽 이라고 생각하시면 됨

AWS를 사용하시다 보면 Management Console로만 사용하기에는 기능적으로 부족한 부분들이 있습니다.

그래서 AWS를 보다 완벽하게 사용하실려면 CLI를 통해서 작업을 하셔야 합니다.

기본적으로 CLI를 사용하기 위해서 AWS는 2가지 환경을 제공하고 있습니다.

1. 로컬PC를 통한 CLI환경 구성 (Windows, Linux, MAC)

2. AWS에서 제공하는 Instance를 이용한 환경 구성

위 두 가지 차이점은 비용이겠죠..

1번의 경우는 각 OS환경에 맞게 설정을 해야하는 번거러움이 있으며,

2번의 경우는 AWS에서 CLI기능이 들어간 Instance를 제공하므로 추가적인 설정이 필요없습니다.

두 가지 다 장단점은 있기 때문에 사용자 입맛에 맞는 걸 쓰시면 되고,

저는 1번을 기준으로 설명 드리겠습니다. (방법은 1번과 2번 차이는 없습니다.)

Windows, Linux 두 가지 OS에 대하여 설정하는 방법을 설명 드리겠습니다.

설치가 완료 되었으면, openssl 을 이용하여 키를 생성하여야 합니다.

이제 2 개의 키가 생성되었으며, 추가적인 환경설정을 합니다. (폴더명이 다를 수 있으므로 환경에 맞게 수정)

생성 된 키 중에서 cert.pem 키를 IAM 사용자에게 등록하여야 사용할 수 있습니다.

메모장으로 cert.pem 파일의 내용을 복사 한 후 키를 등록 합니다.

Permissions이 PowerUserAccess 권한 이상되어야만 명령어가 정상동작합니다.

이제 모든 설정이 완료 되었으며, 명령어가 정상적으로 동작하는지 확인 해 봅니다.

하기 이미지와 같다면 지금부터 CLI 를 사용하실 수 있습니다.

설치가 완료 되었으면, openssl 을 이용하여 키를 생성하여야 합니다.

환경설정 (사용자에 맞게 설정하시면 됩니다.)

여기까지 설정 되었으면 위의 [AWS IAM 설정 방법 및 권한]과 동일하게 설정하시면 됩니다.

AWS의 모든 CLI 명령어는 하기 주소에서 확인 하시면 됩니다.

http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/command-reference.html