![[Level:16]](http://www.gilgil.net/modules/point/icons/default/16.gif "Point:23265point (7%), Level:16/30"){kind=icon}
gilgilARP poisoing 방지책에 대한 논문이 IEEE에 실렸다는 기사가 나왔습니다.
영남대, 학부 졸업논문이 SCI저널 게재
그럼에도 불구하고 학부생 신분인 이들의 졸업논문이 게재될 수 있었던 것은 바로 ‘사용자 간의 협업’이라는 전혀 새로운 접근법을 제시했기 때문.
서로간의 협업이라는 말을 보니 ARP inspection과 같은 Client-Server 방식이 아니라 P2P와 같이 호스트들끼리의 조율하는 방식을 사용했다는 얘기로 들리는군요.
그러나 이들의 지도를 맡은 남승엽 교수(35, 정보통신공학과)의 격려와 실험결과에 대한 조언 덕분에 결국에는 100%에 달하는 성공률을 얻을 수 있었다.
ARP poisoinig을 100% 방지한다라.... 현실적으로 불가능한데... 어떤 방법을 사용하는 걸까요?
논문의 제목이 "Enhanced ARP : Preventing ARP Poisoning-Based Man-in-the Middle Attacks".
참새가 방앗간을 그냥 지나칠 수 없는 노릇이라 구글링을 해 봤습니다. 아래 URL 이 뜨는군요.
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=5403597&arnumber=5403629
ABSTRACT
In this letter, an enhanced version of Address Resolution Protocol (ARP) is proposed to prevent ARP poisoning-based Man-in-the-Middle (MITM) attacks. The proposed mechanism is based on the following concept. When a node knows the correct Media Access Control (MAC) address for a given IP address, if it retains the IP/MAC address mapping while that machine is alive, then MITM attack is impossible for that IP address. In order to prevent MITM attacks even for a new IP address, a voting-based resolution mechanism is proposed. The proposed scheme is backward compatible with existing ARP and incrementally deployable.
Abstract만을 보고 판단을 할 수는 없겠지만, 같은 네트워크 안의 호스트(IP-MAC 정보를 관리해야 하는 이더넷 기반의 IP 단말기)들이 협업을 한다는 얘기같은데, 음... 자세한 내용을 알고 싶은데 Abstract만으로는 좀 부족,ㅋ. 논문의 원본을 보고 싶군요.
교수님한테 직접 메일을 보내었는데, 다행스럽게도 논문을 받아 보았습니다. 논문을 검토해 보았는데, 흥미로운 부분이 많이 있습니다.
1. ARP inspection 과정을 거치는 것은 기존의 방식(올바른 ARP 정보를 가지고 있는 자에게 물어 보고 결정하는 기법)과 같습니다. 다만 C/S 방식이 아닌 호스트들간의 협업으로 결정을 하게 된다는 점입니다.
2. 논문에서는 MITM-Resistant Address Resolution Protocol이라는 것을 제안하고 있습니다. 기존의 ARP 프로토콜과 호황이 되면서 그 뒤 부분에 약간의 필드를 추가된 프로토콜이라고 보시면 됩니다. 이를 "MR-ARP"라고 하구요,
3. MR-ARP 를 지원하기 위해서 기존의 Ketnel Network Stack에서 IP-MAC을 관리하는 모듈에 수정을 가해야 합니다. 교수님 얘기로는 이를 위해서 Linux Kernel 부분을 수정해서 테스트를 했다는 얘기를 들었습니다.
4. MR-ARP 를 가지는 호스트들이 같은 네트워크 대역에 여러대가 있다고 가정을 하고(나 자신도 포함) 나의 IP-MAC 정보가 바뀌어야 할 때(거짓된 ARP request나 ARP reply를 받았을 때), 주위의 MR-ARP 기능을 가지는 다른 호스트들에게 Broadcast방식으로 물어 봅니다. "나 IP-MAC 정보가 새로운 것으로 바뀌었는데, 새로운 정보가 정말 맞는 거야?". 그러면 다른 호스트들(MR-ARP 기능을 가지는)들이 자신에게 응답을 해 주게 됩니다.
5. 다른 호스트들은 나 자신한테 응답을 주게 되고, 응답을 받은 내용을 바탕으로 투표(vote) 방식을 통하여 결론을 내립니다(내가 받은 ARP 패킷이 맞는지 틀리는지).
[결론]
호스트 입장에서 ARP poisoning 방지는 IP-MAC 테이블의 내용이 변경되어야 할 때, 어떻게 그것을 결정하는지가 관건인데, 같은 네트워크 대역의 다른 호스트들한테 물어 보고 결정한다는 것이 본 논문의 가장 핵심으로 보입니다.
ARP poisoning은 victim과 gateway간의 IP 트래픽을 확보하는 것이 일반적입니다. 상기 방식을 사용한다 하더라고 상대방(gateway)이 MR-ARP 방식을 사용하지 않는다면, 반쪽 방어밖에 하지 못한다는 것이고, 이는 기존의 호스트(L3) 기반의 ARP poisoning 방어 방식이 가지는 한계점을 그대로 가지고 있습니다.
gateway가 이중화된 네트워크 환경에서는 잘못된 정보를 서로들에게 확신시켜 줌으로 해서 IP-MAC 테이블의 내용을 새로운 값으로 update하지 못할 수도 있습니다.
협업의 과정이라는 것이 Broadcast 방식으로 물어 보는 것인데, 실제로 gateway의 MAC이 바뀌는 경우(Active - Stand by 환경), 이러현 여러대의 MR-ARP 스택을 보유한 호스트들에 의해서 query 패킷이 한꺼번에 야기될 수도 있다는 단점이 존재합니다. 네트워크 환경이 열악한 무선랜 환경이라면 문제가 될 수도 있을 것입니다(제가 가지고 있는 무선 AP에서는 동시에 100개정도의 Broadcast 패킷을 쏘면(delay없이) 절반 정도는 drop이 됩니다. 물론 무선 신호의 세기는 충분하다는 것을 가정합니다).