Skip to content ↓ | Skip to navigation ↓

My first few blog entries were written at a time when I had had a couple of prowler incidents at my house, and I wrote about how I installed security counter measures. After all this time, I was out maintaining the motion sensors, and it occurred to me I hadn’t taken a look at my network security around the house lately and should put in some maintenance time on that system, as well.

I put aside some time to do just that last weekend and discovered some interesting things as I scanned and monitored the network. First, it is amazing how dense the Wi-Fi coverage is in my neighborhood and presumably across the urban areas of the U.S. (I counted no less than 25 APs with good quality signals, one as far away as four blocks) and second was the 2 “free” Wi-Fi access points that Xfinity has on my neighbors APs – ugh, but that is fodder for a different conversation.

The first step in managing a network is just knowing what devices are on your network and which ones are supposed to be, for you need to understand what it is you are trying to protect with your security mechanisms.

I used Zenmap multiple times to identify all of the hosts on the network at different times of day (devices come and go) and get an asset list and even a nice diagram of my network topology. I also used etherape to capture packets and visually monitor network traffic for a day to verify the results of my scan and to identify any hosts that might not respond to a scan.

It’s amazing how much my home network “drifted” in the short time since I last updated the router and some other components. In that time, we had upgraded our satellite TV system, a kid had added a new iPod, and an old desktop machine had died. Minor changes to be sure, but it hadn’t been that long since I had done an asset inventory on my network.

Second, and what I am going to discuss for the rest of this post and possibly others (it could get quite long), is that allowing a third party into your system can have some interesting consequences. I will elaborate in a just a sentence or two after this brief interruption:

Disclaimer: In what follows, I am not going to name the vendor or any of the system components intentionally. I have nothing bad to say about the vendor and am not dissatisfied with their service in any way. If you can deduce which TV provider it is, I won’t be surprised, but it is not my intention to out this vendor. It is simply the fact that their equipment landed in my home network, so I looked at it. As it stands, I have not violated my agreement with the vendor, and I do not intend to cross that line intentionally.

There, legal issues out of the way. (I hope.)

What I got was a system that provided TV/DVR service to all the TVs in the house … wirelessly. In comes a wireless router to my network. Needless to say, I knew this when the technician installed the system and when I input my network password. Actually, it’s pretty obvious from the description of the system (wireless TV in all rooms) that a wireless network is coming in some way shape or form, therefore, I was not surprised to see these components on my network.

However, I was surprised to see so many. I counted three new systems on my network. In a future post, I will talk about what I discovered about the network, but here I just want to note the impact of my signing up for a service without considering the impact. It is so easy to let something like that happen without realizing it, but my network had two more hosts and six more open, listening ports than I had expected when I entered the network passphrase during the install.

I had thought that the router would NAT all the devices behind one IP address, but instead it appears to add IPs for each TV on the local area network so that internet access could be direct to each device. (I am sure this is a common thing or something I should know more about, but I am a programmer with networking knowledge and not the other way around.) The open ports were surprising, too, and I will address the inspection of them in my next post (coming very soon!).

Having said that, I am now going to bring this home to programming and security.

This all reminds me of working with an XML parsing library several years ago. In the process of vetting the library, we missed something important about the protocol of parsing XML – the schemas can be remote, and the parser is supposed to GET them. The surprise was discovering that when a schema was not in our local cache, our software would open a port and download the missing schema.

This was completely unacceptable behavior for our product, and we were able to build the product without that problem. But the point is this: even though we vetted the library for security issues when we chose it, we hadn’t considered the behavior of the protocol in our environment. Consequently, bringing in the third party library brought in a potential chink in our defenses.

The same is true of any third party system. We don’t always understand the scope of what we are accepting until we have had a chance to work with it. Bringing in third parties requires a lot of diligence in order to get it right and a consideration that added risks might not be where you think they are.

Title image courtesy of ShutterStock