플로우 로그 유형에는 세 가지가 존재 1) VPC 레벨 2) 서브넷 레벨 3) ENI(Elastic Network Interface) 레벨
VPC에서 발생하는 연결 문제를 추적하고 해결하기에 유용
플로우 로그의 목적지는 S3와 CloudWatch Logs 두 곳
AWS가 관리하는 ELB, RDS, ElastiCache, Redshift, WorkSpaces, NAT Gateway, Transit Gateway 등에서 인퍼페이스에 사용할 정보를 얻어올 수 있음
플로우 로그는 VPC 레벨이나 서브넷 혹은 ENI 레벨이 있고 CloudWatch와 S3로 전송
VPC Flow Logs Syntax
연관된 형식이 존재 버전, 계정 ID, 인터페이스 ID, 소스 주소, 목적지 주소, 소스 포트, 목적지 포트, 프로토콜, 패킷, 바이트, 시작, 작업 로그 상태 포함 이들은 VPC로 들어오는 네트워크 패킷 관련 메타데이터
플로우 로그에서 어떤 정보를 얻을 수 있을까
srcaddr, dstaddr (소스 주소와 목적지 주소) 잘못된 IP 식별에 도움, IP가 반복적으로 거부되는지 확인 가능, IP 자체에 문제가 있는지, 특정 IP로부터 공격받고 있는지 등
srcport, dstport (소스 포트와 목적지 포트) 예방 포트 식별에 도움
action (작업) 허용 혹은 거절 둘 중 하나이며 SG(보안 그룹)나 NACL 레벨에서 성공인지 실패인지를 알려줌
VPC 플로우 로그는 사용량 패턴 분석, 행동 감지, 관리 포트 스캔 등에 사용됨
플로우 로그 쿼리에는 두 가지 방법이 존재 1) S3에서 Athena 사용 2) 스트리밍을 분석할 때는 CloudWatch Logs Insight도 괜찮음
VPC Flow Logs –Troubleshoot SG & NACL issues
어떻게 플로우 로그로 보안 그룹 및 NACL 문제를 해결할까
서브넷 상 NACL로 들어오는 요청의 경우 NACL은 무상태이며 보안 그룹은 상태 유지이므로 인바운드가 거절됐다면 인바운드 요청이 바깥에서 EC2 인스턴스로 들어왔는데 거절한 것이며 NACL 혹은 보안 그룹이 요청을 거절한 상황인 것 인바운드는 허용되고 아웃바운드는 거절했다면 보안 그룹은 상태 유지이므로 작업 수락으로 인바운드가 허용됐다면 아웃바운드도 자동으로 허용되어야 하므로 NACL에만 문제가 있는 것을 알 수 있음
요청을 바깥으로 보낼 때 아웃바운드가 거절됐다면 NACL이나 보안 그룹에 문제가 있는 것이지만 아웃바운드는 허용하고 인바운드는 거절했다면 NACL에 문제가 있는 것을 알 수 있음
<VPC Flow 로그 기록 + Athena 실습>
VPC Flow 로그 생성 플로우 로그 유형에는 여럿이 있는데 이름을 DemoS3FlowLog라고 한 후 필터에서 허용과 거절, 모든 트래픽을 선택할 수 있음 예를 들어 만약 일부 트래픽이 못 지나가는 원인을 밝혀내서 해결하고 싶다면 거절 유형이 적합함
그 다음으로 최대 집계 간격은 집계까지 걸리는 시간을 뜻하며 시간이 갈수록 레코드가 더 많이 생성되게 됨
목적지는 S3나 CloudWatch Logs에 기록되며 이에 따라 각각 버킷 ARN과 로그 그룹을 지정해야 함 S3를 선택할 경우 VPC가 있는 리전에 demo-stephane-vpc-flow-logs-v2라는 이름의 버킷을 생성한 후 버킷 ARN이 필요하므로 속성에서 복사하여 리소스 기반 정책이 생성되며 대상 버킷에 연결하도록 설정함 이럴 경우 버킷 정책이 자동으로 생성되어 VPC 서비스가 데이터를 S3 버킷으로 보낼 수 있게 됨 로그의 형식은 아래와 같음을 확인할 수 있으며 이를 통해 첫 번째 로그를 생성
두 번째 플로우 로그로는 이름은 DemoFlowLogCWLogs로 이름을 붙이고 모든 트래픽으로 한 후 간격을 1분으로 하고 목적지를 CloudWatch Logs를 선택하고 로그 그룹과 IAM 역할을 생성하도록 함 Set up permissions을 클릭하고 IAM 역할에 flowlogsRole을 만들도록 허용하고 역할을 생성함 다음으로 CloudWatch의 로그 그룹에서 VPCFlowLogs라는 이름의 로그 그룹을 생성하고 유지 기간은 하루로 정하여 생성
그리고 BastionHost의 ENI ID를 찾아보면 eni-0835~으로 시작하는데 방금 생성한 로그 그룹에서 이를 확인해보면 이 EC2 인스턴스에서 발생하는 트래픽을 볼 수 있으며 누군가 EC2 인스턴스에 액세스를 시도하는데 거절당한 것도 볼 수 있음 이는 공격자가 인스턴스를 공격하려고 웹에서 허점을 스캔한 것이며 이러한 것을 방어하기 위해서는 NACL 레벨에서 차단하여 이러한 트래픽을 막을 수 있음
이렇게 CloudWatch Logs를 사용할 때 지표 필터를 마련해 실시간으로 분석하고 공격에 대비하여 트래픽을 거절할 수 있음
S3의 Athena S3의 경우 CloudWatch Logs보다 더 광범위한 분석을 위해 Athena를 이용해 S3 버킷으로 데이터 쿼리를 실행할 수 있기 때문에 Athena를 활용할 수 있음
Athena를 사용하기 위해서는 먼저 S3 내 쿼리 결과 저장 위치를 지정해야 함 이를 위해 demo-athena-stephane-v2라는 이름의 버킷을 생성한 후 Athena에서 이를 사용하도록 함
aws vpc logs athena를 검색하여 사용 설명서를 보며 코드를 사용하여 데이터베이스를 생성하고 데이터를 만들도록 함 먼저 테이블을 생성하기 위해 데이터가 어디에 있는지 로그 버킷, 접두부 로그, 계정 ID, VPC 플로우 로그, 리전 코드 등을 작성 다음은 파티션을 생성하고 데이터를 읽기 위해 사용 설명서에서 ALTER TABLE을 찾고 S3의 Properties를 찾아 사용하도록 함
이제 플로우 로그를 요청할 수 있으므로 거절된 트래픽을 모두 확인하기 위해 쿼리를 작성하면 결과가 46개가 뜨게 되고 날짜와 인터페이스 ID, 소스 주소, 작업 거절 내역 등이 보이게 됨 즉, Athena에서 많은 정보를 얻고 복잡한 쿼리를 실행해 그룹으로 묶을 수도 있어 누가 가장 많이 공격했고 어디서 공격을 당했는지 볼 수 있어 배치 분석에 유용함
