전체보기

AWS에서는 간간히 온/오프라인 세미나, 이벤트 등을 통해 AWS 서비스에서 사용할 수 있는 Credit을 제공한다. 매달 청구된 비용에서 보유한 Credit 만큼 차감 시켜주는 방식이다. AWS에서 제공하는 설문조사에 참여해 처음으로 Credit을 받았다. 이 Credit을 등록하는 방법에 대해 적어둔다. 1. 관리 콘솔 우측 메뉴 > 결제 대시보드 2. 좌측 메뉴 > 크레딧, 크레딧 사용 3. 받은 크레딧 코드, 보안코드 입력 등록이 완료된 경우, 리스트에 등록된 크레딧을 볼 수 있다. 만료기간과 남은 크레딧을 확인 그리고 해당 크레딧을 사용할 수 있는 서비스 목록을 확인해야한다. (모든 서비스에 적용되지 않음) 겉으로 보기에는 모든 서비스에 적용되는 것 같이 보인다. Route53이 적혀있긴 하지만..

인스턴스를 올리고 구성까지 마쳤으니 도메인을 연결해보자 Route53 AWS에서 제공하는 DNS 서비스 (Route53의 의미는 DNS 포트 53에서 유래됐다고 함) Route53를 통해 네임서버 등록, 레코드 관리, 도메인을 구매까지 할 수 있으며, 모니터링도 가능하다 가장 눈에 띄는 특징은 AWS 서비스(EC2, ELB, S3 등)과의 연결이 매우 편리하다는 점이다. 다만, kr 도메인은 구입할 수 없다. (kr도메인은 가비아 등 다른 도메인 등록기관에서 구매) 도메인을 연결하기 전에 도메인을 구입해야한다. Route53/가비아 등에서 도메인을 구입하는 방법도 있지만, 학습/테스트 용도로 무료도메인을 이용하는 방법도 있다. 이 글에서는 Freenom을 통해 무료 도메인을 가져와 진행한다. (유료 도메..

NAT? 외부 인터넷에서 Private Subnet으로의 통신은 막고, Private Subnet에 있는 객체가 외부 인터넷 통신이 필요한 경우 인터넷 게이트웨이와 private subnet과의 연결을 담당하는 객체 보안을 위해 인스턴스를 내부로 놓는 것 까지는 좋았으나, 이 내부 인스턴스에서 인터넷이 필요한 경우가 있다. (ex. apt install, SES 이메일 전송 등) AWS에서는 이러한 상황에 대해 자체적 서비스인 NAT Gateway를 지원한다. (이 서비스가 있기 전에는 NAT instance를 두어 사용했다고 함) 구축 환경도 이전 글과 동일하게 가져간다. VPC > NAT 게이트웨이 > NAT 게이트웨이 생성 생성할 서브넷은 퍼블릭, 연결 유형도 퍼블릭으로 준다 (Private Sub..

이전 글에서 Private Subnet의 접근에 대해 Bastion host를 언급하고 끝맺었다. Bastion Host? Public Subnet에 위치해 직접 접근 불가능한 Private Subnet을 접속할 수 있게하는 게이트 역할의 호스트 -> 침입을 최소화 시키기 위한 목적의 호스트라고 보면된다, 특정 IP만 접근 가능하게 제어 할수 있고, Private 서버로 접근한 로그를 남길 수 있어, 접속자 확인에 편리하다. Private Subnet의 인스턴스로 접근하기 위한 과정은 다음과 같다. 1. Bastion host로 SSH 접속 2. 연결한 Bastion host에서 Private Subnet의 인스턴스로 SSH 접속 이번에 구성할 내용 기본적인 세팅은 이전 글과 동일하게 가져간다. bast..

CVE-2021-41773 [Apache HTTP Server Path Traversal & RCE] 요약 : 경로 탐색 공격에 쓰이는 문자열에 대한 미흡한 정규화 조치로 인한 경로탐색 및 추가적인 잘못된 환경 설정으로 인한 원격 코드 실행 취약한 버전 Apache HTTP Server 2.4.49 선행조건 httpd.conf내의 Directory directive 설정이 Required all denied 되어있지 않음 (Required all granted거나 Require 구문이 없음), RCE의 경우 mod_cgi가 enable되어 있어야함 mod_cgi - Apache HTTP Server Version 2.4 httpd.apache.org 분석 [Path Traversal] path trave..

Docker hub에서 이미지를 pull해와서 컨테이너를 관리하는 부분까지 해봤다. 이제는 Dockerfile로 직접 내 이미지를 만들어보자 Dockerfile Docker 이미지를 생성하기위한 스크립트 파일로, Dockerfile 작성 후 build하면, 파일의 내용대로 한 명령어씩 실행되어 환경을 갖춘 이미지가 생성된다. Dockerfile만 작성해두면 어느 환경에서든 빌드를 통해 같은 이미지를 생성할 수 있고, 이미지 구축에 어떤 명령어가 실행되었는지도 파악하기 편리하다. tomcat, APM, Spring 등 웹서비스를 띄울 때, Dockerfile의 편리성이 드러난다. docker hub에 배포된 설치 이미지를 받아 내가 작성한 App을 바로 Copy하도록 Dockerfile을 작성만 해두면 빠..

VPC 개념을 알아봤으니 이제 직접 구성해보자 만들어볼 네트워크 구성은 아래와 같다 1. VPC 생성 2. Public Subnet / Private Subnet 구성 2-1. 인터넷 게이트웨이 생성 2-2. 라우팅 테이블 설정 3. 인스턴스 생성해서 서브넷에 연결 VPC 생성에 들어가면 VPC를 설정해주는 메뉴가 나온다. 생성할 리소스에서 'VPC 등'을 선택하면 VPC부터 서브넷, 라우팅 테이블을 한번에 생성할 수도 있다. VPC부터 직접 만들어보자 VPC DEMO_vpc : 10.10.0.0/16 서브넷 VPC는 생성해줬던 DEMO_vpc를 선택하면 서브넷을 설정할 수 있다. Public subnet : demo_public_subnet | ap-northeast-2a | 10.10.1.0/24 P..

지난 번 글에서 인스턴스를 생성하고 올려서 접속까지 해보았다. 단순히 인스턴스를 관리하는 것은 정말 쉬웠다. 하지만 인스턴스 갯수가 늘어나게 되면, 인스턴스끼리의 연결은 항상 인터넷을 통해야한다. 그렇게 되면 인스턴스 간의 연결이 굉장히 비효율적이게 된다. 그래서 AWS에도 개인별로 가상으로 네트워크를 만들어서 작업할 수 있는데, 이게 바로 오늘의 주제, AWS의 가상네트워크, VPC이다. VPC는 Virtual Private Cloud로 직역하면 가상 사설 클라우드인데, 사용자가 직접 구성할 수 있는 가상의 네트워크 환경이다. AWS의 리소스들이 존재할 네트워크 망으로 서브넷, 라우팅테이블, 인터넷 게이트웨이 등의 개념이 있다. 이러한 가상의 네트워크 공간이 존재하게 되면 물리적으로는 다른 위치에 존재..