The scenario for this post is that you’re connected to the local LAN of the systems you’re pentesting – possibly in a DMZ or multi-tiered architecture. If you’re on an externally-facing LAN, you may find that there aren’t many network services to explore.
As your pentest starts to look more like a vulnerability assessment, you might start thinking about the following:
- How many of these systems are multihomed?
- What network services are accessible on the other interfaces?
In modern network architectures, systems often have a mangement LAN interface, or a backup LAN interface and potentially other interfaces that are more interesting than the one you’re looking at.
If you can find the IP addresses of these other interfaces, you might be able to pentest a few more interesting network services from your vantage point on the external network segment.
Finding IP Addresses of Remote Network Interfaces
If you’re lucky you’ll be able to use SNMP (generic) or a “special NetBOIS query” (Windows only) to list all the IP address of a system.
If this doesn’t work, you might be able to bruteforce the IP addresses using ARP queries.
Linux hosts will respond to ARP requests for all of their IP addresses on all of their Interfaces. i.e. a multi-homed host might respond to both of these probes from the LAN you’re on:
arp-scan 10.0.0.99 arp-scan 192.168.0.99
This is counter-intuitive. If you’re like me, you’d probably expect the target system to only answer ARP requests for IPs on the same LAN as the client. Indeed Solaris, Windows and AIX behave as expected.
When ARP scanning, your source IP address might be important (so also try 0.0.0.0). Reasoning for this is discussed further here and here.
Using arp-scan, a Class B can be scanned in 36 secs on my test system, using 3% CPU and 1 MB/s bandwidth:
arp-scan --bandwidth=1M --retry=1 --arpspa=1.1.1.1 172.16.1.0/16
So it’s just about practical to scan 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. It should take less than 3 hours and would cover all hosts on the local subnet if you used broadcast ARP requests. To do this for 4 source addresses would take 12 hours, which is a more significant amount of time.
If for some reason you don’t want to use broadcast ARP requests (maybe you’re not authorised to test the whole LAN), you can unicast requests by specifying the destination MAC address:
arp-scan --bandwidth=1M --retry=1 --arpspa=1.1.1.1 --destaddr=00:11:22:33:44:55 172.16.1.0/16
How to Fix
Changing the arp_ignore option in /proc from 0 (default) to 1 will remedy the above behavior.
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore