Linux:iptables on AWS VPC
우아한형제들 기술 블로그 참조!
by
May 30. 2019
iptables 에 관해서 자세한 정보를 찾던 중,
우아한형제들 기술 블로그에서
AWS VM 네트워크 트래픽 미러링 관련 자료를 찾았다.
사실, 이전 iptables : Network Traffic Mirroring 해외 케이스 관련
참조 사이트와 크게 다르지 않다.
하지만,
Ref: http://woowabros.github.io/security/2018/06/29/aws-network-mirror.html
이 글의 마지막 부분을 내가 직접 구축하고 구현해 보는 시간을 가졌다.
Suricata 를 이용한 네트워크 트래픽 데이터 분석이
나에겐 그렇게 어려운 일이 아니기 때문이다.
분석은 다음 편에서 진행하고,
우선은 개발 환경 구축과 AWS 상에서 트래픽을 VM 간에 Mirroring 하고,
ELK 를 활용해 데이터를 운반, 저장, 시각화를 하는 것 까지
이번 글에 적어보려한다.
먼저 나는 3개의 VM을 준비했다.
Name 순으로 1번은 트래픽을 전달하는 VM,
2번은 1번 VM 에서 발생하는 트래픽을 전달 받는 VM,
3번은 2번에서 해석한 트래픽 정보를 저장하는 VM
늘 간단하게 PING(ICMP) 을 통해서
트래픽이 복제되고, 그 복제된 트래픽이 어떻게 해석되고, 어떻게 저장하는지
확인한다.
VM #01: iptables 설정만 하면 끝!
VM #02: 네트워크 설정, Suricata, Redis or Filebeats : Redis 는 Logstash 도 설치
VM #03: Elasticsearch, Kibana
위의 우아한형제들 기술 블로그에서,
AWS VM 네트워크 성질 중에서,
자신을 Destination 으로 하지 않는 트래픽에 대해서는 차단을 한다고 한다.
이를 해제하기 위한 설정으로,
비활성화가 정답!
나의 노트북에서 VM #01 로 PING 을 날린다.
그림 상으로,
총 4개의 PING 이 날아갔다.
이제 이 핑을 직접 받는 VM #01의 네트워크 크래픽 정보를 보면,
(TCPDUMP 를 이용해서)
61.82.88.244 라는 public IP를 타고 PING이 도착한 것으로 보인다.
대략적으로,
첫 번째 PING Request가 도착한 시간이 05:39:47 UTC 이니까 여기서 9시간 더해서 보면 된다.
즉, 내 Laptop 에서는 2시 49분 쯤에서 PING 을 보냈다.
이제 트래픽을 Mirroring 받는 VM #02 쪽에서의 결과를 확인힌다.
길이가 좀 짧아 보인다. 4개의 요청과 4개의 응답이 보인다.
그렇다면! 왜 위의 VM #01 은 같은 seq 번호가 반복해서 나타났는가?!
Mirroring 해주고 있기 때문이다.
더 정확히는,
트래픽 정보를 Clone 해서 VM #02로 보내주고 있는 모습까지 나타났기 때문이다.
seq 번호, timestamp 모두 일치하고 있음을 알 수 있다.
여기까지 보였다면 성공적으로 트래픽 정보를 확인 한 것이다.
이제 마지막으로 Suricata 를 통해서도 위의 정보가 잘 받아졌는지,
또한 어떤 정보가 PING 안에 존재 하는지 확인한다.
