Do You Know Your Network Neighbors?

As the system administrator for a VOS system you typically could care less about what other hosts are on the local subnet. You care about the gateways that are configured and of course any local hosts that communicate with your system but the other hosts are below your radar. There are, however, 2 very good reasons for knowing who your network neighbors are. First, in the event of a communication problem you can use these other hosts to test your network connection. Second, these are the hosts that are most likely to be the sources of any kind of network based attack.

It is not a bad idea to scan the local subnet every so often (say every Wednesday morning) just to see who is out there. VOS does not have a built in scanner – but it does have the ping command, which when surrounded by a few lines of a command macro can be made into a scanner.

There are 3 issues with using ping to scan for hosts. First, it is not very efficient. The default time out is 15 seconds and the command will try 4 times so it will take a minute to scan for a host that is not there or does not respond to pings. Luckily, the number of tries can be reduced to 1 and the timeout reduced to 1 second. This is still not efficient from the perspective of a dedicated scanning tool but I think good enough for our needs.

The second issue is that not all hosts will respond to pings. That however, is not a significant problem because with just one more line our command macro will report which hosts sent an ARP reply. ARPs are used to map an IP address into an Ethernet MAC address and VOS must know the Ethernet MAC address before it can send the ping. It therefore sends an ARP request to the target host and places the data from the reply into the ARP cache. All hosts will respond to the ARP request with an ARP reply even if they will not respond to the subsequent ping request. The arp command will display the requested entry if one is there.

The above command macro has the ping requests and responses intermixed with ARP data, it is not very readable. The following macro produces a pretty table of neighbors in a file named arp_scan.(date).out. It assumes a class C network, that is the first 3 octets are fixed and scans for hosts 1 thru 254. I suggest you run it as a started process.

The ARP cache timeout is 10 minutes, If there is an entry with a time less than 10 minutes you will know that the module was already communicating with that host before the scan was done.

The third issue is the complaint that you might get from your network administrator for actively scanning the network. If they object to this activity you can passively scan it by using the packet monitor command to capture broadcast packets.

Using this technique relies on the other hosts in the network actively communicating and sending broadcasts while packet_monitor is running. If you use this technique you will have to let packet_monitor run for quite a while, how long will depend on your network. I suggest that you put the above command into a command macro (packet_monitor_scan.cm) and run it as a started process. Don’t forget to run the process as privileged.

Once you have a trace you will then need to convert it into a usable table of addresses. The following macro will do that (it assumes packet_monitor_scan was a started process generating a process_packet_monitor_scan.out file).

which will produce the following table.