VMPlayer 무료 버전을 사용하여 가상 설정에서 Netdiscover로 침투 테스트하는 동안 문제가 발생했습니다. 공격 머신은 VMWare NAT 네트워크 인터페이스에 있고 대상 머신은 VMWare 호스트 전용입니다. VMWare NAT 인터페이스가 대상 컴퓨터의 IP / MAC로 ARP 테이블을 채우지 않았기 때문에 Netdiscover가 작동하지 않는다는 것을 발견했습니다 (Netdiscover는 ARP를 사용함). NAT에서 호스트 전용 (http, ping)까지 테스트 된 다른 모든 프로토콜은 문제없이 작동했습니다. 원래 문제는 https://security.stackexchange.com/q/105263/91684 입니다.
VMWare 문서를 살펴본 결과 ARP가 어떻게 채워지는지에 대한 명확한 정보가 없습니다.
이것이 정상적인 VMWare 동작입니까, 아니면 내가 뭔가 잘못하고 있습니까?
Netdiscover 작동 ...
arp 요청을 적극적으로 전송하여
Arp 요청은 게이트웨이를 통과하지 않습니다. 우선, Linux 시스템 IPv4에서는 전달 을 활성화 하지만 IPv4 패킷은 OSI-Layer 3 개체 인 반면 ARP 요청은 OSI-Layer 2 개체이므로 Linux 커널의 어디에도 ARP 요청을 다른 인터페이스로 전달하라는 명령이 없습니다.
이것이 바로 귀하의 경우입니다. ARP 요청이 호스트의 인터페이스에 도달하면 MAC이 필요한 IP가 인터페이스의 IP와 일치하지 않기 때문에 폐기됩니다. 위의 이유 때문에 요청이 다른 인터페이스로 전달되지도 않습니다. 따라서 호스트는 (올바르게) ARP 요청을 삭제하고 응답하지 않습니다. 이것은 설정에서 Netdiscover의 실패를 설명합니다.
위의 실패는 VMWare에 다른 네트워크 사이에 적절한 게이트웨이가 없다는 사실 때문이 아닙니다. Linux 서버가 IPv4 개체 이외의 항목을 전달할 수 없다는 것을 무시하더라도 ( 예 : Linux가 아닌 게이트웨이 / 라우터가 있다고 가정) 게이트웨이의 가장 일반적인 동작은 자체 MAC 주소 로 원격 호스트의 ARP 요청에 응답하는 것 입니다. 여기에 원격 호스트에 대한 ARP 작업의 인스턴스가 있습니다 . 즉, 원격 호스트의 MAC 주소가 제공된 IP와 일치 할 때까지 ARP 요청의 업스트림 체인이 없습니다. 위에서 설명한 최소 동작 (로컬 게이트웨이의 MAC 주소 반환)도 일반적이지 않습니다.
이 모든 것은 쉽게 테스트 할 수 있습니다 : 데비안 머신에서
sudo apt-get install iputils-arping
sudo arping -f -c 1 -w 5 -I eth0 8.8.8.8
그리고 다른 모든 OS에서 이와 비슷한 것입니다. 응답이없는 것을 볼 수 있습니다. traceroute자신의 업스트림 게이트웨이 중 일부의 IP 주소를 찾는 데 사용할 수도 있습니다 . 명령
sudo arping -f -c 1 -w 5 -I eth0 IP_of_Upstream_Gateway
또한 응답하지 않을 것입니다.
Netdiscover설정 을 테스트하려면 모든 VM, 공격자 및 공격자를 동일한 서브넷에 배치해야 합니다. 그러면 ARP가 작동합니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다