The lack of network documentation…

[This blogpost has also been published as a guest diary on isc.sans.org]

Writing documentation is a pain for most of us but… mandatory! Pentesters and auditors don’t like to write their reports once the funny stuff has been completed. It is the same for the developers. Writing code and developing new products is fun but good documentation is often missing. By documentation, I mean “network” documentation. Why?

When you buy from a key player some software or hardware which will be connected to a corporate environment, the documentation usually contains a clear description of the network requirements. They could be:

• A list of ports to allow in firewalls or any kind of filter to access the device/application
• A list of ports used by the device/application to access online resources and basic services (NTP, DNS, Internet, Proxy, …)
• A list of online resources used (to fetch updates, to send bug reports, to connect to cloud services, …)

But today, more and more devices are connected (think about the IoT-buzz – “Internet of Things“). These devices are manufactured in a way that they automatically use any available network connectivity. Configure a wireless network and they are good to go. Classic home networks are based on xDSL or cable modems which provide basic network services (DHCP, DNS). This is not the best way to protect your data. They lack of egress filters and any connected device will have a full network connectivity and potentially exfiltrate juicy data. That’s why I militate in favour of a documentation template to describe the resources required to operate such “smart” devices smoothly. Here is an good example. I’ve a Nest thermostat installed at home and it constantly connects to the following destinations:

54.227.140.192.9543
23.21.241.75.443
23.23.91.51.80
54.243.35.110:443
87.106.208.187:80

It’s easy to make your home network safer without spending a lot of time and money. When a new device is connected to my network, it receives a temporary IP address from a small DHCP pool (Ex: 192.168.0.200-210). This pool has a very limited network connectivity. It uses a local DNS resolver (to track used domains) and is only allowed to communicate over HTTPS to the Internet. A Snort IDS and a tcpdump are constantly running to capture and inspect all packets generated by the IP addresses from the DHCP pool. This is easy to configure with the following shell script running in the backgound.

#!/bin/bash
while true
do
    TODAY=`/bin/date +"%Y%m%d"`
    /usr/sbin/tcpdump -i eth1 -lenx -X -s 0 -w /data/pcaps/tcpdump-$TODAY.pcap \
        host 192.168.0.200 or \
             192.168.0.201 or \
             192.168.0.202 or \
             192.168.0.203 or \
             192.168.0.204 or \
             192.168.0.206 or \
             192.168.0.207 or \
             192.168.0.208 or \
             192.168.0.209 or \
             192.168.0.210 &
    TCPDUMP_PID=$!
    sleep 86400 # Go to sleep for one day
    kill $TCPDUMP_PID
    gzip -9 /data/pcaps/tcpdump-$TODAY.pcap
done

When a new device is connected, its traffic is automatically captured and can be analyzed later. Once completed, a static DHCP lease is configured with the device MAC address and the firewall policy adapted to permit the required traffic. Not only, it helps to secure your network but it can reveal interesting behaviors.