Broadcast ICMP in Linux and How to Initiate and Protect

How can I discover all hosts on my network? How can a hacker discover all hosts on your network ? Two very different questions from the view point of appropriate network use but the same tools can be used. In this blog we look at ICMP Broadcast and how we can initiate this with the Linux ping command. We will see that Linux is protected on the outset against this type of discovery but other hosts may not. Learning techniques will help on the way to certification with the LPI and LPIC-3 exam 303 and Linux Security.

Each objective is available to view online. However if you prefer to have all the content in one place and study from an eBook then the objective ‘LPIC 3 Linux Security 326.1 Host Hardening’ is now available to download for just £0.99.

Download

Managing ICMP Broadcast with Ping

One easy was to discover hosts that are ‘alive’ on a network is to ping the broadcast address for the network. In Linux this is an easy task.

Do take care though that this is a network that you manage as some switches may disable ports where this type of activity is taking place.

For this demonstration I am using a CentOS 6 system connected to my network. The network is 192.168.0.0/24 so the corresponding broadcast for this network will be 192.168.0.255. If I ping to the broadcast address each host can respond. We have already seen that Linux by default protect against this type of discovery with the procfs key net.ipv4.icmp_echo_ignore_broadcasts to to 1. Ignoring any ICMP broadcast.

# ping -c2 -b 192.168.0.255
WARNING: pinging broadcast address
PING 192.168.0.255 (192.168.0.255) 56(84) bytes of data.
64 bytes from 192.168.0.20: icmp_seq=1 ttl=64 time=0.156 ms
64 bytes from 192.168.0.11: icmp_seq=1 ttl=255 time=2.66 ms (DUP!)
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=9.27 ms (DUP!)
64 bytes from 192.168.0.13: icmp_seq=1 ttl=64 time=68.3 ms (DUP!)
64 bytes from 192.168.0.20: icmp_seq=2 ttl=64 time=0.171 ms

We can see that we are getting replies from 192.168.0.1, 192.168.0.11, 192.168.0.13 and 192.168.0.20. The CentOS 6 host has an IP Address of 192.168.0.57 and we see that it does not respond.

If we use Linux security as being like an onion, with many layers, the more protection that we can offer to our servers the better. Although we do not prevent discovery or determinisation of services by this capability we do add steps and tim. For a quick an easy look at this network I would concentrate on these servers that respond to the ICMP broadcast.

To show how we become more visible by inverting this setting so we do respond to ICMP broadcasts we will enable this on my system:

# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.icmp_echo_ignore_broadcasts = 0

When we now ping again to the broadcast address the CentOS 6 host 192.168.0.57 responds:

# ping -c2 -b 192.168.0.255
WARNING: pinging broadcast address
PING 192.168.0.255 (192.168.0.255) 56(84) bytes of data.
64 bytes from 192.168.0.57: icmp_seq=1 ttl=64 time=0.025 ms
64 bytes from 192.168.0.20: icmp_seq=1 ttl=64 time=0.123 ms (DUP!)
64 bytes from 192.168.0.11: icmp_seq=1 ttl=255 time=2.94 ms (DUP!)
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=4.49 ms (DUP!)
64 bytes from 192.168.0.13: icmp_seq=1 ttl=64 time=117 ms (DUP!)
64 bytes from 192.168.0.57: icmp_seq=2 ttl=64 time=0.054 ms

This is not the setting we would want to keep to we can change it back. In any case, a reboot we see the setting return to the original as we have not persisted the key and value in the sysctl.conf.

# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.icmp_echo_ignore_broadcasts = 0

The video follows