상황은 이렇다.
동아리 연구실내의 컴퓨터들이 도서관 네트워크에 더미허브를 이용해 연결되어 있는데,
컴퓨터 중 서버 역학을 하는 컴퓨터에는 VM위에 리눅스 서버들이 올라가있다.
또, 예전에 그 서버중 하나에서 가상서버 관리를 위해 도커를 올린적이 있었는데, 작업 중간에 멈추고 그대로 냅둔 상태였다.
어느날 연구실 컴퓨터들에 네트워크 장애가 발생해서 점검해보는데, 학교측에서 도서관 네트워크 장비구성을 변경한 이후에 이런 문제가 생겼다고 했다.
명확한 원인이 잡히지가 않아 대체 뭘까.. 하고 있던 와중에, 각 컴퓨터에 설정된 dns가 여타 장비들이랑 다르게 잡혀있어서, dns를 재설정하니 이제 네트워크가 정상작동했다.
근데 여기서부터 진짜 문제가 발생한다. 연구실 컴퓨터들이 도서관 네트워크에 연결되자마자 도서관 전체 네트워크가 뻗어버린 것
당황해서 급하게 더미허브에서 업링크를 분리하고 점검에 들어갔는데, 아무리 찾아도 이상한 부분을 찾을 수 없었다.
그러다 arp 테이블을 보는데, ip 두개의 mac주소가 똑같이 잡히는게 확인되었고 해당 ip는 서버 pc의 vm에 올라간 가상서버의 ip였다.
?? 우리 서버에서 arp 변조가 일어났나? 화들짝 놀라서 체크를 해봤다.
해당 리눅스 서버에 연결해서 네트워크 인터페이스 리스트를 뽑아보는데, 아까 arp 테이블에서 봤던 ip 두개가 여기에 다 보이는거다. 이게 무슨 조화인가, 해서 인터페이스 속성을 집어보니 하나는 원래 vm의 인터페이스고, 나머지 하나는 브릿지 인터페이스였다.
??? 왜 브릿지가 설정되있는거지? arp 변조 공격이 진행된건 아니라 다행이라고 생각하면서, 왜 브릿지가 하나 더 있는가는 의문이었다.
이게 어디서 나온건지 찾아서 올라가보니, 도커를 설치하면서 자동으로 브릿지 인터페이스가 하나 더 설치되었던 것. 여기까진 일반적인 도커의 설치 과정인데, 도커에서 브릿지를 설치할 때 ip 세팅은 현재 서버의 네트워크 기준으로 세팅해준다. 각 사설 네트워크 아이피 대역에서 ~.254로 할당을 해주는 모양.
근데 이 VM이 NAT로 네트워크 세팅된게 아니고, 이미 브릿지 상태로 물리 네트워크, 즉 도서관 네트워크에 연결되어있는 상태이다. 그래서 실제 물리 네트워크에 도커용 브릿지가 생성되서 물려버린 셈.
도서관 네트워크 -> 더미허브 -> 서버pc -> 브릿지 VM -> 도커 VM
으로 연결되어버린 상황이다.
도커가 이렇게 설정된 이후에 학교에서 네트워크 작업을 하면서 구성 변경이 이뤄졌는데, 구성이 변경되면서 이 서버와 도서관에서 실제 ~.254 대역에 할당된 백본장비간 ip 충돌이 발생해버린것. 이러니 도서관에 있는 컴퓨터들이 실제 백본장비가 아닌, 우리 서버에 있는 도커 네트워크를 백본장비로 인식하여 연결해버린거다.
보통은 이런일이 생길일이 없다. 사설 네트워크가 별도로 구성되거나, vm 서버가 nat로 연결되거나 할테니. 근데 우리 서버 구성은 전부 브릿지를 통해 연결을 해놓은 상태였기에 안 생겨야될 문제가 생겨버린 셈이다 아오 ㅋㅋㅋㅋ
그래서 해당 도커 브릿지 인터페이스를 삭제하고 재부팅한 다음 다시 업링크를 연결해보니 , arp 테이블도 정상적으로 잘 잡히고 네트워크 장애도 안생겼다.
혹여나 브릿지로 연결된 서버에 장애가 생긴 경우, arp 테이블을 점검했을때 동일 MAC을 가지는 다른 IP 장비가 둘 있다면 도커 브릿지를 우선적으로 점검해봐야 할듯. 보통 네트워크에서 ~254 ip 를 가진것들이 도메인 서버 역할을 하니까 충돌날 확률이 꽤 높을지도 모른다.
발견부터 조치까지 거의 1주일이 걸렸던 사건.. 학교측에서 우리가 공격한거 아니냐는 의심까지 받았는데, 솔직히 내가봐도 의심해볼만 하긴 했다. 테이블 보고 제일 먼저 든 생각이 그거였으니.
다행히 공격은 아니었는데, 아직도 모르겠는건 vm 상에서 봤던 도커 브릿지의 mac이랑 arp 테이블에 찍힌 mac이 달랐던것. 테이블에 찍힌 mac은 해당 vm 서버의 mac과 똑같은 주소였다.
뭐 결과적으로는 도커 브릿지를 날리니까 실제 서버의 mac을 잘 가져오는걸 보면 그게 원인인건 맞았던거같다.
좀 미심쩍지만 아무튼 해결 완료...