VMWare NAT tidak mengisi ARP dengan IP / MAC dari host VMWare saja?

Saya mengalami masalah saat pengujian penetrasi dengan Netdiscover pada pengaturan virtual menggunakan VMPlayer, versi gratis. Mesin serangan ada di antarmuka jaringan VMWare NAT, dan mesin target hanya pada host VMWare. Saya menemukan bahwa Netdiscover tidak berfungsi karena antarmuka VMWare NAT belum mengisi tabel ARP-nya dengan IP / MAC dari mesin target (Netdiscover menggunakan ARP). Semua protokol yang diuji dari NAT ke host-only (http, ping) berfungsi tanpa masalah. Masalah asli ada di https://security.stackexchange.com/q/105263/91684 .

Saya melihat dokumentasi VMWare dan tidak menemukan yang jelas tentang bagaimana ARP diisi.

Apakah ini perilaku VMWare yang normal, atau apakah saya melakukan sesuatu yang salah?

virtual-machine vmware-player arp

— Batu Benar
sumber

AFAIK netdiscover tidak bergantung pada cache ARP, tetapi akan mengirim permintaan ARP untuk secara aktif memetakan node. Apa yang terjadi ketika menggunakan netdiscover -r rangerentang yang mencakup mesin target?

— harrymc

@harrymc Silakan merujuk ke tautan dalam pertanyaan untuk latar belakang dan penelitian lengkap.

— Stone True

Kalau dipikir-pikir, permintaan ARP mungkin tidak dapat menyeberang dari satu VMnet? adaptor ke yang lain, karena VMware tidak menentukan Default Gateway untuk adaptornya. Anda mungkin perlu menggunakan perintah rute untuk menentukan rute yang diperlukan, atau membuat Proxy ARP, atau menambahkan Gateway Default (jika mungkin di lingkungan Anda).

— harrymc

Netdiscover berfungsi ...

dengan secara aktif mengirim permintaan arp

Permintaan arp tidak melewati gateway. Untuk satu hal, pada mesin Linux kami mengaktifkan IPv4penerusan, tetapi paket IPv4 adalah objek OSI-Layer 3, sedangkan permintaan ARP adalah objek OSI-Layer 2, sehingga di mana pun di kernel Linux tidak ada instruksi untuk meneruskan permintaan ARP ke antarmuka lain.

Ini persis seperti kasus Anda: sekali permintaan ARP mencapai antarmuka host, itu akan dibuang karena IP yang diperlukan MAC tidak cocok dengan antarmuka. Permintaan juga tidak akan diteruskan ke antarmuka lain karena alasan di atas. Oleh karena itu host Anda (dengan benar) menjatuhkan permintaan ARP, yang tidak akan dijawab. Ini menjelaskan kegagalan Netdiscover dalam pengaturan Anda.

Kegagalan di atas bukan karena kenyataan bahwa di VMWare tidak ada gateway yang tepat antara jaringan yang berbeda. Bahkan dengan mengabaikan ketidakmungkinan server Linux untuk meneruskan apa pun kecuali objek IPv4 ( yaitu , dengan anggapan Anda memiliki gateway / router non-Linux), perilaku paling umum untuk gateway adalah untuk menanggapi permintaan ARP dari host jarak jauh dengan alamat MAC mereka sendiri , lihat untuk contoh di sini di bawah operasi ARP untuk host jarak jauh . Dengan kata lain, tidak ada rantai upstream permintaan ARP sampai alamat MAC dari host jarak jauh dicocokkan dengan IP yang disediakan. Perilaku minimum yang dijelaskan di atas (mengembalikan alamat MAC gateway lokal) juga tidak umum.

Semua ini dapat dengan mudah diuji: pada mesin Debian

  sudo apt-get install iputils-arping 
  sudo arping -f -c 1 -w 5 -I eth0 8.8.8.8

dan sesuatu yang mirip dengan ini di semua OS lainnya. Anda akan melihat Anda tidak mendapat balasan. Anda juga dapat menggunakan tracerouteuntuk menemukan alamat IP dari beberapa gateway hulu Anda sendiri; perintah

  sudo arping -f -c 1 -w 5 -I eth0 IP_of_Upstream_Gateway

juga tidak akan dijawab.

Untuk menguji Netdiscoverpada pengaturan Anda, Anda harus menempatkan semua VM, penyerang dan penyerang Anda, pada subnet yang sama . Maka ARP akan bekerja.

— MariusMatutiae
sumber