Skip to content

Finding IP Addresses of Other Network Interfaces on Linux

Objectivity score: 56 out of 100.
Difficulty 46 out of 100 (College)— Read Analysis

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

Facts Only

* The scenario involves pentesting systems connected to a local LAN in DMZ or multi-tiered architectures.
* The goal is to find IP addresses of other network interfaces for further investigation.
* Systems may have management, backup, or other interfaces besides the primary one under examination.
* SNMP or "special NetBOIS queries" can list system IP addresses.
* ARP queries on Linux hosts respond for all interface IP addresses.
* The command `arp-scan` can be used to scan IP ranges like 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
* Unicast ARP requests specify a destination MAC address for scanning.
* The `arpignore` option in `/proc/sys/net/ipv4/conf/all/arpignore` can be set to 1 to change behavior.

Executive Summary

The text discusses methods for finding IP addresses of other network interfaces on Linux systems, particularly relevant in pentesting scenarios involving multi-homed systems or complex network architectures. It suggests that while services like SNMP might reveal IP addresses, brute-forcing via ARP queries can also be employed. The article details how Linux hosts respond to ARP requests for all their interface IP addresses, even those not on the local subnet, which can be exploited by scanning tools like arp-scan. Specific examples are provided demonstrating how to perform both broadcast and unicast ARP scans. A fix is suggested to alter system behavior regarding ARP ignoring options.

Full Take

The process of exploiting network protocol behaviors for reconnaissance reveals a tension between intended system behavior and exploitable side effects. The discovery that Linux hosts respond to ARP requests across all interfaces, contrary to typical expectations in smaller networks, suggests a systemic ambiguity in how network stacks handle broadcast responses when multiple logical interfaces exist. This shifts the focus from simple information disclosure to understanding implementation-specific nuances for reconnaissance. The practical demonstration of using `arp-scan` to survey IP space indicates that seemingly benign protocol interactions can be leveraged for mapping environments. The necessity of modifying configuration settings like `arpignore` points toward a design where security-by-default is either incomplete or requires explicit, often low-level, intervention to enforce desired boundaries. The implication is that the perceived boundaries of network segmentation are often weaker than the implemented controls, meaning reconnaissance techniques can bypass high-level architectural assumptions simply by observing low-level operational responses.

Sentinel — Human

Confidence

The text presents a highly specific, technically dense procedure related to network scanning on Linux systems, strongly suggesting it was written by an individual with direct experience in penetration testing or system administration.

Signals Detected
low severity: Sentence length variance is relatively high; the text shifts between instructional prose and command-line examples.
low severity: The content flows logically from a scenario (pentesting context) to a specific technical problem (finding IPs) and then to concrete solutions, exhibiting clear argumentative structure.
low severity: The use of command-line examples (`arp-scan` commands) is tightly integrated with the theoretical explanation, suggesting an author actively demonstrating a process rather than just aggregating facts.
low severity: The technical details regarding ARP behavior and specific Linux kernel settings appear accurate and grounded in specific operational knowledge, suggesting direct experience or deep research.
Human Indicators
Direct use of authorial voice ('If you’re like me...') and demonstration of hands-on commands with specific flags; the tone is practical and directed toward a technical audience needing immediate action.