여기서 다루는 내용

· 들어가며
· 기능 개요
· 환경 설정
· 결과 확인
· 마치며

들어가며

안녕하십니까. GS네오텍 최준승입니다.

제가 가끔 AWS 교육을 하러 가서 자주하는말 중에 “Trade-off” 라는 단어가 있습니다.
뭐든 좋은게 있으면 나쁜게 있고. 다른 말로 좋은것을 강화하려면 나쁜것도 생기기 마련이라는 말인데.
이게 클라우드의 서비스를 설명할때 들어맞는 경우가 꽤 많습니다.

일례로 클라우드 환경에서는 관리-편의성과 제어권을 맞바꾸는 경우가 많습니다.
RDS같은 매니지드 서비스를 생각해보시면 됩니다. 관리포인트를 줄이는 대신에 위탁한만큼 일부 가시성이나 제어권을 잃습니다.
이건 필연적인 것입니다. 제어권도 확보하면서 센스있게 알아서 다 해주는걸 원하신다면 직원을 뽑아야 합니다. 월급을 줘야죠.

일단 직원은 다음에 뽑기로 하고.. 그래도 RDS야. DB엔진을 EC2 위에 올리는 대안이 있습니다만.
딱히 클라우드 서비스에서 대안이 없고 가시성도 낮으며 기존 On-Premise의 시각에서 보면 답답한 분야가 있다면 어떤게 있을까요?

바로 네트웍. 가상 네트웍. AWS로 치면 VPC가 되겠습니다.
일단 가상화 환경이라 낮은 레이어를 컨트롤하지 못하기 때문에. 여기에서 오는 번뇌와 불편함이 여럿 있게 되죠.

오해하시면 안되는게. AWS의 VPC는 정말 끝내주게 잘 만들어진 서비스입니다.
그리고 오늘 소개드릴 Traffic Mirroring 기능도 가상 네트웍의 단점을 일부 상쇄하는 아주 괜찮은 기능입니다.

그럼 정말 쓸만한 기능인지 같이 한번 살펴보시죠.

기능 개요

제 설명 이전에 공식-문서를 보고싶으신 분들은 아래 링크를 참고하세요.
AWS Documentation – VPC – Traffic Mirroring

요약 해드립니다.

• 무슨 기능? VPC 환경에서 패킷을 복제해드림
• 어디로부터 복제? 특정 ENI에서
• 어디로 복제? 다른 ENI 또는 NLB로
• 어떻게? 별도의 agent나 내부 설정없이 AWS가 구현해놓은 방식으로

On Premise 환경에서야 TAP 장비를 쓰든 아님 다른 네트웍 장비를 쓰든 샤바샤바해서 오가는 트래픽을 열어보는것이 가능하지만
가상화된 네트워크 위에서는 그런 (자원-소모적인) 로직이 따로 구현되어 있지 않는한 트래픽을 볼 방법이 없습니다.

물론 EC2 환경에서도 종단에서 agent를 설치하거나 iptable을 활용하면 일부 가시성을 얻을수 있지만 좀 부자연스럽고
아시는것처럼 AWS에서 VPC Flow logs라는 것을 선택적으로 내려주긴 하는데 제공하는 정보가 너무 적어요. 아래처럼요.
2 123456789010 eni-abc123de 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

이번에 새로 나온 VPC Traffic Mirroring 기능은 아주 간단한 설정을 거치고 나면
다른 ENI에서 미러링된 패킷정보를 받아 원하는 용도로 가공하여 활용할 수 있습니다.

쓰임새는 천천히 생각해보기로 하고 이번에는 기능을 활성화하는 과정을 살펴보도록 하겠습니다.

환경 설정

설정 방식은 아주 단순합니다.

• 미러링 타겟을 지정합니다 – #1. Mirror Target
• 미러링 규칙을 지정합니다 – #2. Mirror Filter
• 미러링 세션을 만듭니다. 이때 미러링 Source를 지정하고, #1 객체를 타겟으로 #2 객체를 규칙으로 참조합니다

정말 간단하죠?
너무 간단한 나머지 용기를 내어 그림을 그려봤습니다.

※ 아무래도 괜히 그렸나 봅니다..

제가 친절하게 그림까지 그렸으니 이해가 쏙쏙 되실것으로 생각하고 AWS 관리 콘솔 ▷ [VPC] 로 가봅시다.

※ 왼쪽 탭 가장 아래에 Traffic Mirroring 관련 메뉴가 모여있습니다

Mirror Target 객체부터 만들겠습니다.
참고로 해당 ENI가 붙은 인스턴스는 윈도우 AMI 기반으로 wireshark를 설치해 놓았습니다.

※ 객체 이름과 특정 ENI를 타겟으로 지정하면 끝

이번엔 Mirror Filter 객체를 만들겠습니다.
미러링시에 어떤 필터링 규칙을 거쳐 그 중 일부만 복제할지를 정의하는 부분입니다.
인바운드와 아웃바운드를 대상으로 프로토콜/포트/IP대역 등을 한정할 수 있습니다.

※ Inbound로 들어오는 TCP 패킷을 모두 복제하는것으로 설정하겠습니다

마지막으로 Mirror Session을 만들어 보겠습니다.
복제 원본이 되는 ENI를 지정하고. 위에서 만든 Mirror Target / Mirror Filter를 지정해주면 완성입니다.
참고로 복제 원본인 ENI가 붙은 인스턴스는 Amazon Linux 2 AMI로 만들어 놓았습니다.

※ Mirror source와 Mirror target을 지정합니다. 이때 Target 객체는 ENI가 아닌 앞단계에서 만든 객체의 ID입니다

※ 몇가지 부가적인 설정과 앞에서 만든 Filter 객체를 지정합니다

설정이 심플하게 완료되었습니다.
참고로 미러링하는 과정에서 객체간의 Security Group 정책을 적절히 넣어줘야 하는데 자세한 설명은 생략합니다.

결과 확인

이제 잘 돌아가는지 확인해보겠습니다.

• Mirror Target으로 지정된 ENI가 붙은 인스턴스에는 Wireshark를 띄워놓고 필터링을 걸어놓았습니다
• 그리고 외부(IP주소는 10.0.0.6)로부터 Mirror Source의 ENI 주소로 SSH 접속을 하면
• Wireshark에 미러링된 트래픽이 보이는지 확인하면 되겠지요

복제 원본으로 지정된 주소로 SSH 접속을 이렇게 하면
(참고로 10.0.0.48 주소가 source ENI로 지정된 객체의 주소입니다)

$ ssh -i ./jschoi-sp.pem 10.0.0.48
Last login: Wed Jul 17 06:25:37 2019 from ip-10-0-0-6.ap-southeast-1.compute.internal

https://aws.amazon.com/amazon-linux-2/
[ec2-user@ip-10-0-0-48 ~]$


그럼 미러링 타겟쪽에서는 이런식으로 트래픽 정보를 확인할 수 있습니다

※ 오.. 정보가 아주 풍부하네요

전체 그림이 이해가 가시나요?

마치며

이 기능은 다른 AWS 서비스와 마찬가지로 몇가지 제약사항이 있습니다.
AWS Documentation – VPC – Traffic Mirroring – Traffic Mirroring Limits and Considerations

Nitro 계열 인스턴스에서만 해당 기능을 사용할 수 있다는 점 외에는 크리티컬한 부분은 없어 보이는데요.
오히려 타 VPC나 타 계정의 VPC로 복제하는 부분은 기존 VPC 기능을 잘 활용하면 쉽게 구현이 가능하도록 만들어 놓았습니다.

그렇다면 다시 원점으로 돌아와서 이 기능은 어디다 쓸 수 있을까요?
AWS 블로그에서는 이런것들을 얘기합니다.

• Detect Network & Security Anomalies
• Gain Operational Insights
• Implement Compliance & Security Controls
• Troubleshoot Issues

공통점을 요약하면 이 기능을 통해 트래픽에 대한 가시성을 확보하고
이를 통해 네트워크 레벨의 트러블슈팅을 하거나 보안 솔루션과 연계해 모니터링하는 용도로 쓸 수 있다고 이해하면 되겠네요.

과금은 크게 비싸보이진 않는데 한번 개별적으로 확인해 보시구요.
이런 기능이 사용자 입장에서는 크게 와닿지 않을 수 있는데.
벤더 입장에서 이런 기능을 빼준다는건 나름 대단한 정성이라고 생각합니다.

미러링한 데이터를 어떻게 활용할지는 어디까지나 사용자의 영역이므로
여러분 환경에 필요한지 한번 검토해보시고 필요하다면 활용해 보시기를 바래요.

그럼 마칩니다. 끝!