woody

실습 목표 : 웹 애플리케이션의 취약점이 노출된 웹 서버를 배포 후 모의 해킹을 수행하고, AWS WAF에 의해 웹 취약점 공격을 점검하고 차단하는 실습을 진행한다. 실습 목표 구성도는 아래와 같다. WAF을 제외한 기본 환경은 CloudFormation을 통해 구성한다. 기본 환경에서 웹 취약점 검증 현재 기본 환경은 웹 서비스에 대한 보안 대책이 없이 아무나 연결이 가능한 무방비 상태이다. 해당 환경에서 웹 취약점 공격자가 되어 모의 해킹을 수행해 보겠다. 우선 DVWA 인스턴스에 접근하여, 보안 레벨을 낮춰 실습에 용이하게 설정하자. ALB의 퍼블릭 DNS 주소를 확인하고 웹 브라우저로 HTTP 접근을 해보자. * DVWA는 보안에 취약한 무방비 상태의 웹 애플리케이션이다. DVWA 웹 서버를 통해..

실습 목표 : VPC에서 보안 그룹과 네트워크 ACL을 생성하여 동작의 차이를 이해하고, VPC 플로우 로그를 통해 레코드를 수집하여 접속 허용과 거부를 확인한다. 기본 실습 환경은 CloudFormation을 통해 구성한다. VPC 플로우 로그와 CloudWatch는 아직 생성하지 않았다. 보안 그룹을 통한 접근 제어 먼저, 보안 그룹을 통해 접근 제어를 해보자. 보안그룹은 Stateful 한 동작 제어를 한다. 이해를 돕기 위해 먼저 Server-SG의 보안 그룹에서 아웃바운드 규칙을 삭제 한 후 실습을 진행하겠다. 다음으로 사용자 PC에서 Server-EC2로 SSH 접근을 시도해보자. 아래와 같이 정상접속되는 것을 확인할 수 있다. 아주 당연한 결과처럼 보이지만, 현재 적용중인 Server-SG ..

실습 목표 : AWS 내부망과 기업 내부망 간에 하이브리드 클라우드 환경을 구성하여 서로 간의 프라이빗 도메인 주소로 통신하는 구성을 알아보자. 기본 환경은 CloudFormation을 통해 구성한다. 해당 환경은 현재 AWS 내부망에서는 Route 53을 통해 DNS 질의가 이루어지고 기업망 내에서는 별도의 DNS 서버를 통해 질의가 이루어지고 있다. AWS -> IDC 혹은 그 반대의 경우에서 DNS 질의를 하기위한 실습을 진행한다. 기본 환경 검증 1) AWS-VPC에서의 기본 환경 검증 (웹서버 1 SSH 접근) 1. EC2에 설정된 DNS서버 확인 2. awsneta.internal 프라이빗 도메인에 대한 DNS 질의 3. 프라이빗 도메인 주소로 웹 접속 확인 4. VPC 피어링으로 연결된 ID..

AWS와 온프레미스 IDC간 VPN 통신을 해보자. 구축되어있는 CloudFormation 환경은 아래와 같다. VPN 환경을 설정 하기 전, 기본 환경에 대해서 SSH 접근을 시도해보자. 우선 IDC-CGW 인스턴스에 접근을 수행하고, 인스턴스에 생성된 VPN 설정 파일을 확인한다. 현재 IDC-VPC 내의 퍼블릭 서브넷에 있는 IDC-CGW 인스턴스에 접속해 있기 때문에 같은 VPC 내의 프라이빗 서브넷 속 인스턴스에 접속할 수 있다. 접근해보자. 이후 프라이빗 서브넷의 인스턴스가 외부 인터넷과 통신이 되는지 확인해보자. 프라이빗 서브넷 속 인스턴스이기 때문에 별도의 설정 없이 통신이 불가한 모습을 볼 수 있다. 마찬가지로, 생성한 AWS 인스턴스에 대해서도 같은 결과를 보여준다. 이후 AWS 인스턴..

아래는 기본 CloudFormation 환경이다. 위와 같은 환경에서는 아직 피어링 연결이 안됐기 때문에, 두 VPC는 기본적으로 서로 통신이 불가능하다. SSH 접근을 통해 각 EC2의 퍼블릭 IP로 접속 후 프라이빗 IP로 통신이 되는지 확인해보자. 위와 같이 통신 불가임을 알 수 있다.(반대도 마찬가지) 피어링을 생성해보자. ​ 이후 수락자에서 수락을 해야 피어링 생성이 완료된다. 현재까지 진행된 내용은 다음과 같다. 이제 각 VPC에서 반대편 VPC의 서브넷과 프라이빗 통신을 하기위한 라우팅 테이블을 작성하자. ​ 위처럼 상대 대역을 설정하고, 대상으로 VPC 피어링을 지정해준다. 마찬가지로 VPC2에서도 동일하게 라우팅 테이블을 추가해준다. ​ 그럼 위와같이 연결이 완료된다. 마지막으로, 인스턴..

시드니와 상파울루에 구성된 웹 서버에 대해 Global Accelerator를 통해 연결하고 다양한 검증을 한다. ​ 기본 CloudFormation 환경이다. ​ 서울 리전에 기본 인스턴스 하나를 생성하고 SSH 접근하여 시드니와 상파울루에 생성한 리소스와 통신해본다. ​ 여기까지는, Global Accelerator가 아닌 여러 ISP 네트워크를 거쳐서 통신 되고있다. ​ Global Accelerator의 서비스 관리는 오레곤 리전(us-east-2)에서 수행한다. 따라서 서비스에 접근하면 자동으로 오레곤 리전으로 설정된다. ​ Global Accelerator를 생성해보자 이름설정 ​ 2. 리스너 설정 ​ 3. 엔드포인트 그룹 추가 ​ 4. 엔드포인트 추가 시드니 리전 엔드포인트 추가(ALB) 상..

상파울루 리전에 웹서버 EC2 인스턴스를 구성 후 사용자 PC에서 직접적인 연결과 AWS CloudFront를 통한 CDN 서비스의 연결 차이를 비교해보자. ​ 리전을 상파울루 SA-EAST-1로 이동 후 CloudFormation을 통해 환경을 구성한다. ​ ​ 이후 Routee 53 A 레코드를 생성하여 SA-EC2와 도메인을 연결한다. ​ 구글 크롬에 접속해 F12키를 눌러 개발자 도구를 출력하고, 네트워크 탭을 클릭해 지연시간을 확인해본다. 대용량 이미지에 의해 5.55s의 높은 지연시간을 가지고 있다. ​ 이제 CloudFront를 사용해 CDN 기능을 사용해보자. 먼저 Distribution을 생성한다. CloudFront --> Distribution(배포) --> Create Distrib..

ALB를 통해 부하분산되는 2개의 인스턴스 환경에서 Route 53을 통해 직접 설정한 도메인으로 접속해보자. ​ 기본 CloudFormation 환경은 아래와 같다. ​ 생성된 ALB의 DNS 이름을 확인하고 인터넷 브라우저에서 해당 주소로 접근해보면 라운드 로빈 형태로 번갈아 접근되는 것을 확인할 수 있다. ​ 로드밸런서 DNS 주소와 생성한 도메인 주소와 연결하기 위해 Route 53 -> 호스팅영역 -> 도메인 선택 -> 레코드 생성 -> 단순라우팅, 별칭체크, ALB/CLB에 대한 별칭, 레코드 유형 A선택 후 레코드 생성완료 ​ 레코드 생성 후 해당 도메인 주소로 접근하면 위 사진과 동일하게 접속이 가능해진다. Failover 환경을 구성해보자. 우선 Route 53 -> 상태검사 에 진입해 ..

NLB 로드 밸런서를 생성하여 UDP 프로토콜 중 SNMP 서비스에 대한 부하 분산을 해보자. ​ SNMP는 Simple Network Management Protocol의 약자로 네트워크 관리를 위한 규약이다. OID(Object Identifier)라는 값을 호출하여 시스템에 대한 정보를 파악할 수 있다. SNMP는 UDP 161포트를 사용한다. ​ NLB 생성과정은 다음과 같다. 로드밸런서 생성 -> NLB 선택 -> 이름 지정 및 인터넷 경계 선택 -> 리스너에 UDP선택 및 포트번호 161 지정 -> VPC를 ELB-VPC로 지정하고 가용영역 2개 모두 체크 후 서브넷 지정 -> 새 대상 그룹 생성 -> 이름 지정 및 프로토콜 UDP 지정 후 포트번호 161 설정 -> 상태검사 프로토콜은 HTT..

CloudFormation을 통한 기본 환경이다. ​ ALB 로드 밸런서를 생성해 HTTP 서비스에 대한 부하 분산을 해보자. 로드밸런서 생성을 클릭 -> ALB 선택 -> 리스너에 HTTP(포트80) 선택 -> 가용영역에서 ALB가 포함될 VPC 선택하고, 두개의 가용영역과 각 서브넷을 선택 -> 이후 보안그룹 지정 -> 대상 그룹을 생성하여 라우팅 지정(상태검사 까지 모든 프로토콜을 HTTP로 지정) ​ 다음과 같이 도식화가 완성된다. 검증 ​ 생성한 ALB의 DNS주소를 복사하고, putty를 통해 My-VPC내의 인스턴스로 SSH접근을 시도하고, curl 명령을 통해 ALB로 HTTP 접근을 시도한다. 다음과 같이 로드밸런서를 통해 번갈아 가면서 ELB-VPC 내의 인스턴스에 접근하는 것을 확인할..