MAC Flooding

이미지 출처: https://talkroute.com/the-best-way-to-handle-multiple-incoming-calls/

 

OSI의 2번째 계층 Data Link Layer의 대표적인 네트워크 공격으로 “MAC Flooding”이 있습니다. 다른 네트워크 공격과는 달리, MAC Flooding은 서버나 PC, 단말 등을 타겟으로 삼기보다 네트워크 스위치를 직접 공격하는 방법입니다. 물론 그 공격의 최종 타겟은 네트워크 상의 단말 기기들이지만 말이죠.

 

1. MAC table과 보안 허점


이미지 출처: https://community.fs.com/blog/network-switch-router-firewall-why-need-all-three.html

 

네트워크 스위치는 여러 장치(ex., 컴퓨터, 서버, 프린터)를 하나의 LAN으로 묶어줍니다. 스위치에는 랜선을 꼽을 수 있는 물리적 포트가 다수 존재하며, 각각의 장치는 이 물리적 포트를 하나씩 차지하여 본인에게로 도달해야하는 데이터들의 통로로 사용합니다.

 

스위치는 각 물리적 포트의 할당 현황을 관리·모니터링하게 되며 이 기능을 "MAC table(또는, MAC Address table)"을 기반으로 수행하고 있습니다. MAC table스위치의 포트-호스트의 MAC 주소를 일대일로 매핑한 리스트입니다. 스위치에 패킷이 들어오면 이더넷 프레임에 해당하는 영역으로부터 MAC 주소를 추출하고, MAC table에 기록된 주소들과 대조하여 지정된 물리적 포트로 데이터를 이동시킵니다.

 

“MAC Flooding”의 목표는 이 MAC table이 정상적으로 기능하지 못하게 하는 것입니다. MAC table에 기록가능한 용량의 한계가 있다는 점을 악용해서 말이죠.

 

MAC Flooding 공격은 한 번에 대량의 이더넷 프레임을 스위치로 전송합니다. 이때 전송되는 각 프레임에는 임의로 만들어낸 다양한 전송자 주소가 혼재되어 있습니다. MAC table은 찰나의 순간만에 가짜 MAC 주소들로 채워지게 되고 정상 호스트들의 MAC 주소가 등록될 여유 공간이 부족해지는 상황이 옵니다.

 

MAC table 기능이 마비되어 전반적인 통신 장애 문제도 발생하겠지만, MAC Flooding으로 인해 발생하는 가장 큰 보안 이슈는 따로 있습니다. 바로, 네트워크 사용자들의 데이터 노출입니다.

 

MAC table이 가득 차면 스위치는 "Fail-open"이라는 모드로 전환됩니다. 이 Fail-open 모드 동안에는 스위치로 들어온 데이터가 일단 내보낼 수 있는 모든 포트로 전달됩니다. MAC table이 먹통이니 데이터를 어떤 포트로 보내야 하는지 알 수 없고, 그렇다고 호스트들 간의 통신을 아예 중단시킬 수는 없다 보니 스위치에 내리는 극단적인 결단이라고 할 수 있습니다.

 

그러나, 데이터가 모든 포트로 브로드캐스팅되버리면 크나큰 보안 이슈가 발생하게 됩니다. 해당 패킷 데이터를 읽어봐선 안되는 호스트들이 그 내용물을 버젓이 확인할 수 있다는 것인데요. 데이터를 몰래 훔쳐보는 주체에는 당연히 네트워크에 속해있던 공격자도 포함됩니다. 따라서 중요한 정보들이 고스란히 공격자에게 넘어가는 셈입니다.

 

2. MAC Flooding 공격 탐지 방법


MAC Flooding을 진단하는 매우 완벽한 지표는 없지만, 같은 네트워크 상에서의 트래픽 흐름을 모니터링하는 것만으로도 MAC Flooding 공격을 충분히 탐지 가능합니다.

 

예를 들어, 네트워크 트래픽이 갑자기 급증하거나 속도가 급격하게 감소하는 현상이 네트워크 전반에서 발견되면 그 원인 중 하나를 스위치 MAC table의 과부하로 지목해볼 수도 있습니다. MAC Flooding 공격이 성공할 경우 다른 호스트가 받아야 할 데이터 패킷이 관련 없는 단말에게도 전송될테니, 한 호스트 머신에서 이러한 비정상적인 트래픽 흐름을 확인했다면 MAC Flooding 공격이 발생했음을 인지할 수 있습니다.

 

3. MAC Flooding에 대한 방어 조치


피해 발생의 근원은 MAC table의 취약점이며, 이를 보완하는 방법들은 상당히 간단합니다.

 

주기적인 table entry 삭제

대게 MAC table에는 timeout duration이 존재하여 주기적으로 유효 기간이 지난 MAC 주소-포트 번호 매핑을 테이블에서 제거합니다. Cisco사의 switch 제품의 경우 table의 각 entry당 5분 정도만 유지된다고 하네요.

 

Port Security

물리적 포트마다 수용할 수 있는 MAC 주소의 가짓수를 제한합니다. 대게 스위치 내부 터미널에 접속하여 switchport port-security라는 명령어로 해당 수치값을 조정할 수 있습니다.

ESW (config-if)# switchport port-security maximum ?
  <1-4097>  Maximum addresses

 

위에서 설정한 limit가 넘어갈 경우 포트로 들어오는 이더넷 프레임을 폐기시킬지, 또는 아예 포트 하나를 다운시킬지 등의 보안 규칙도 아래와 같이 설정할 수 있습니다.

ESW (config-if)# switchport port-security violation ?
  protect   Security violation protect mode
  restrict  Security violation restrict mode
  shutdown  Security violation shutdown mode

 

MAC 인증

AAA 서버(Authentication, Authorization, Accounting server)에 의해 허가된 네트워크 사용자들의 MAC 주소만을 필터링하는 방법이 존재합니다.

 

4. 시뮬레이션을 통한 MAC Flooding 이해


본 포스트에서 소개한 MAC Flooding에 대한 이해도를 높이기 위해서 간단한 실습을 해보았습니다.

 

목표

공격자 PC 1개정상 호스트 2개가 스위치에 동시에 맞물려 있는 환경을 구축한 뒤, MAC Flooding을 발생시키고 정상 호스트끼리 주고 받은 패킷을 공격자의 PC에서 Sniffing해보고자 합니다.

 

시뮬레이션 도구

네트워크 스위치 기능은 GNS3 인터페이스에서 띄워주었고, 그 외 Attacker/Victim Host 역할을 하게될 PC들을 VMware를 통해 구동시켰습니다.

  • GNS3 Network Emulator
  • Kali Linux VM (Attacker 역할)
  • OWASP VM (Victim 역할1)
  • Metasploitable 2 VM (Victim 역할2)

 

Network Configuration

VMware의 NAT 네트워크 (VMnet2) 상에 준비된 스위치와 VM들을 띄우고 각 노드들을 연결하였습니다.

 

MAC table 동작 확인

스위치가 on된 바로 직후에는 MAC table이 비어있는 상태였다가, 각 호스트끼리 서로 ping을 날리게 해보면 호스트들의 MAC 주소(000c.xxxx.xxxx)와 스위치 포트(FastEthernet1/?)가 한 쌍씩 MAC table에 기록되는 것을 확인할 수 있습니다.

 

제가 구동시킨 스위치에서 가용할 수 있는 MAC 주소의 최대 개수는 8192개로 나오네요.

 

MAC Flooding 수행

공격자 역할을 하는 Kali VM에 접속하여 MAC Flooding을 발생시켜 봅니다. Kali에 내장된 ‘macof’라는 도구를 이용하면, 임의로 이더넷 프레임을 대량 생성해내어 타겟 스위치에 전송합니다. Wireshark에서 확인해보니 초당 몇만~몇십만 개의 패킷을 스위치로 보내는 것을 확인할 수 있었습니다.

스위치 터미널로 돌아와 MAC table의 현황을 체크해보니 각종 무작위의 MAC 주소가 table에 가득차 있는 것을 볼 수 있었습니다.

 

 

정상 호스트들의 통신 엿보기

MAC Flooding을 수행하는 동안에 정상 호스트들끼리 telnet으로 데이터를 주고 받도록 하였는데요. MAC table이 가득찬 시점에서 공격자 PC에서 telnet 패킷을 필터링해보면 놀랍게도 두 정상 호스트가 주고 받은 패킷이 아무렇지도 않게 캡처되는 것을 확인할 수 있습니다.

 

위 이미지를 보시면 분명 Source IP와 Destination IP는 정상 호스트에 해당하는 192.168.59.101 또는 192.168.59.102인데, 제 3자인 공격 PC(192.168.59.100)이 어떻게 저 패킷들을 눈으로 다 파악해볼 수 있는 걸까요?

 

호스트 간의 통신 내역이 전부 브로드캐스팅되면서 telnet, arp와 같이 plaintext 기반의 프로토콜로 전달되는 메시지는 위 스크린샷 이미지와 같이 공격자에게 너무나 손쉽게 들어가고 맙니다. 또 탈취한 정보를 가지고 Spoofing이나 Hijacking과 같은 추가적인 공격으로 이어질수도 있겠죠.

 

MAC Flooding, 단순하면서 참으로 무섭습니다.  •́︿•̀ 。

반응형