AWS

· Cloud/IaC
지난 3-tier VPC 구축에 이어서, 이번에는 Application단(EC2, ALB 등)을 설계해보도록 한다. 아키텍쳐 구성도 Terraform 코드 작성 Application 단에서 생성할 리소스는 크게 다음과 같다. 인스턴스 4개 보안그룹 키 페어 ALB 2개 (외부, 내부) 대상그룹 2개 (외부, 내부) 먼저 Application 모듈의 변수들을 구성한다. Application 단에서 사용될 외부 변수들에는 주로 vpc 관련의 것이 있다. 인스턴스를 생성할 때 사용될 vpc_id나 배치될 서브넷의 id 값이 여기에 해당된다. 이외에도 ami의 id값이나 미리 생성해둔 security group의 id 같은 리소스도 변수로 불러와서 사용할 수도 있을 것이다. variable "vpc_id" {}..
· Cloud/AWS
작년 여름 Solutions Architect Associate를 취득한 뒤, 이번에는 Security Specialty에 도전을 해보았다. 원래는 이후 AWS 자격증에 도전할 생각은 딱히 없었다. 그나마 Associate 다음 단계인 아키텍트 Professional을 생각해보는 정도였다. 앞서 Associate 취득에 대한 Benefit으로 다음 Certified 응시 금액 50% 할인권을 줬기에 안쓰기도 뭔가 아깝다는 생각도 들고, 이왕 도전하는 김에 관련 업무를 진행해봤던 Security 쪽으로 해보자라는 생각이 들어서 신청하게 되었다. 결과적으로는 굉장히 널널하게 합격할 수 있었다. 관련 업무를 진행해봐서 그런지, 아니면 AWS 지식이 조금 늘어서 그런 것인지는 몰라도 개인적으로는 SAA보다 쉽게..
· Cloud/AWS
도메인을 리다이렉트해달라는 내용을 요청받았다. 자세히 이야기하자면, www.before.com과 같은 도메인으로 들어온 요청을 www.after.com과 같은 다른 도메인으로 리다이렉트하도록 설정을 해달라는 내용이였다. 이러한 예시는 실제로 종종 볼 수 있다. 예를 들어 어떤 서비스의 도메인이 완전히 바뀌어서, 이전 도메인으로 접속하는 트래픽을 신규 도메인으로 리다이렉션해주는 상황이 있을 수 있다. 이외에도 회사의 브랜드나 서비스 등을 사칭하는 사례의 방지를 위해 관련된 도메인들을 구매하고 정식 서비스로 리다이렉트 시켜버리는 등의 예시도 생각 할 수는 있다. (도메인 사칭방지와 관련된 LG전자의 실제 예시에서 이같은 방법을 고려해볼 수 있을 것이다. 다만, 도메인을 모오두 사들이는 돈은 있어야겠지만.....
· Cloud/IaC
본격적으로 조금 더 복잡한 내용으로 들어가보도록한다. 많이 사용되는 WEB, WAS, DB 구조인 3-tier 아키텍쳐를 Terraform Code로 구성해보도록한다. 아키텍쳐 구성도 구성할 요소가 상당히 많은 것을 볼 수 있다. 이번 글에서는 네트워킹 요소(VPC)부터 구성하고, 그 다음으로 Application(WEB, WAS, DB)를 구축해보도록 한다. Terraform 코드 작성 전체적인 프로젝트는 module화 시켜 최대한 가독성있게 제작했다. (모듈화를 시킴으로써 각 모듈에서 필요한 요소들을 가져오고 내보내는 과정을 익힐 수 있었다. [output / variables]) ├── main.tf ├── module │ ├── application# EC2, ALB 등의 application 요..
시나리오 개요 Starting as an anonymous outsider with no access or privileges, exploit a misconfigured reverse-proxy server to query the EC2 metadata service and acquire instance profile keys. Then, use those keys to discover, access, and exfiltrate sensitive data from an S3 bucket. 시나리오 목표 S3 버킷 내의 confidential 파일 다운로드(탈취) 시나리오 세팅 ./cloudgoat.py create cloud_breach_s3 solutions 디렉토리 내의 cloud_breach_s3..
· Cloud/AWS
GuardDuty AWS 계정 전반의 위협 탐지 서비스(Threat Detection Service) AWS 계정과 워크로드를 보호하기 위해 악의적인 활동들과 비인가적인 행위들을 지속적으로 모니터링한다. GuardDuty는 위협 인텔리전스 피드를 통해 악성IP / 도메인을 판별하고, 이를 바탕으로 머신러닝을 적용시켜 위협 탐지를 수행한다. GuardDuty가 모니터링하는 항목으로는 다음과 같다. VPC flow log CloudTrail 이벤트 로그 CloudTrail 관리 이벤트 DNS 로그 GuardDuty는 기본으로 활성화되지 않고 별도로 활성화를 시켜줘야 모니터링과 탐지를 시작한다. GuardDuty 서비스를 나타내는 객체로 감지기라는 개념이 존재한다. 이 감지기는 리전 단위의 객체로, 이 탐지기..
시나리오 개요 Exploit insecure IAM permissions to escalate your access. Start with a role that manages other users credentials and find a weakness in the setup to access the "admin" role. Using the admin role retrieve the flag from secretsmanager. 시나리오 목표 Admin role을 통해 SecretsManager에 있는 flag 탈취 시나리오 세팅 ./cloudgoat.py create iam_privesc_by_key_rotation solutions 디렉토리 내의 iam_privesc_by_key_rotation 시나..
· Cloud/AWS
이전 글에서 Bastion host를 사용하지 않고 내부 Private 서브넷의 인스턴스에 접근하는 수단인 Session Manager에 대해 알아보았다. Session Manager도 IAM을 이용해 키 페어를 관리할 필요 없이 간편하게 인스턴스 접근할 수 있도록 서비스가 제공되나, 아웃바운드 인터넷 라우팅이 없는 폐쇄망에 접근하는 경우에 엔드포인트 세팅 작업이 필요해 조금은 불편했던 점이 있었다. 추가로, Private 인스턴스로의 연결을 위해 생성하는 3개의 엔드포인트들은 각각 시간당 요금이 부과된다는 점도 마냥 간과할 수는 없는 포인트이다. 비교적 최근 AWS에서는 이러한 폐쇄된 서브넷의 인스턴스에 연결할 수 있는 EC2 Instance Connect Endpoint(이하 EIC 엔드포인트)라는 ..
Omoknooni
'AWS' 태그의 글 목록