Networks Placed At Risk – By Their Broadband Providers

Some network security incidents are so obviously preventable that it is mind boggling. Such was the case with a recent Wi-Fi-based network security breach at a client. It was eminently preventable. It was even more upsetting when I found out that the source of the incident was a carrier-supplied device that had been configured by the broadband provider's technician.

The other week, I was called to one of my clients because of problems with their computers. Certain network applications were not functioning correctly. When I arrived at the site, a possible explanation for the problem became apparent: there was an active virus infection. However, what was more interesting than the virus infection itself was one of the possible infection vectors I identified: their provider-supplied broadband router/firewall.

Several months ago, this client had changed broadband providers. The new provider was a heavily promoted high bandwidth network.^[1] As is common, the new provider-supplied gateway appliance supported both wired and wireless connections. The device was configured with a well-documented password and was configured with its wireless support enabled, even though no one at the customer used a Wi-Fi device. In fact, my client expressed surprise that Wi-Fi access was even turned on.

Worse, the Wi-Fi was encrypted using WEP, the weakest of the Wi-Fi supported encryption standards. Their offices were also located in a busy area on a main street with clear signal paths to many buildings. A check of their network activity using a variety of tools showed that there were active connections whose addresses did not correspond to machines legitimately on the network.

My first reaction was to cut off access by strangling the Wi-Fi. I also immediately changed the management passwords on the gateway appliance to something other than the standard documented default provided by the carrier.^[2] I then had to perform the laborious task of having each of their machines re-scanned for malware.

The shame of this situation is how preventable and unneeded this security breach was. The customer had no need for Wi-Fi, nor even knowledge that it had been enabled. There was simply no need for the Wi-Fi to be enabled at this customer. Worse, it was not only enabled, but it was configured in a security posture that almost invited an intrusion.

A few simple steps can make this type of security incident far less likely.

Do not allow carrier provided appliances directly on your network. Instead, use the approach I first described in the Computer Security Handbook, 3rd Edition: connect your own firewall router between your local network and the interface appliance supplied by your provider. Think of the zone between your provider-supplied router/firewall and your router/firewall not so much as a DMZ (De-Militarized Zone), but as a "No-Mans Land" between opposing border control posts.

From “Protecting Internet-Visible Systems”, Computer Security Handbook, 4th Edition. 2005
If you are using Wi-Fi, use the highest encryption level supported by your access point and your Wi-Fi equipped clients.
Do not place a public Wi-Fi access arrangement in a location where your organization's traffic can be monitored by a device connected to the Wi-Fi. Wi-Fi access does not belong in the network DMZ, but in a cul-de-sac separate from the DMZ. In Safe Computing in the Age of Ubiquitous Connectivity (also available as a paper presented at LISAT 2007), I detailed how to create a public Wi-Fi access cul-de-sac providing visitors and customers with cyber-hospitality while preserving the integrity and security.

Wi-Fi is not inherently dangerous, but maintaining security is aided by properly compartmented networks, as I described at the 11th Annual New York State Cyber Security Conference (June 2008) in Compartmented Networks: A Corporate Solution for Privacy, Integrity, and Security.

Fortunately, my client's network problems were resolved after I cleaned out some modest malware infections. The outcome could have been far worse. Such an intrusion, if it was linked to criminal activity could have implicated my client, the victim of the attack, as a spammer or worse.

Notes

^[1]	I have omitted the name of the provider as it is not material. Reported security problems of various types have been reported involving many different providers.
^[2]	The password for which was well published on the web.

References

Robert Gezelter, “Security on the Internet” Chapter 23 in Hutt, Bosworth, and Hoyt, 1995.
ibid, “Protecting Internet-Visible Systems” Chapter 21 in Bosworth and Kabay, 2005.
ibid, “E-Commerce and Web Server Safeguards” Chapter 30 in Bosworth, Kabay, and Whyne. 2009.
ibid, “Internet Dial Tones & Firewalls: One Size Does Not Fit All” Presented to the IEEE Computer Society, Coastal South Carolina Chapter, June 10, 2003.
Retrieved from http://www.rlgsc.com/ieee/charleston/2004-6/internetdial.html on December 6, 2009
Ibid., “Compartmented Networks: A Corporate Solution for Privacy, Security, and Integrity” Presented at the 11th Annual New York State Cyber Security Conference, Albany, New York, June 5 2008.
Retrieved from http://www.rlgsc.com/nyscybersecurity/2008/compartmented.html on December 6, 2009
ibid. “Safe Computing in the Age of Ubiquitous Connectivity” Presented at 2007 Long Island Systems Applications and Technology Conference, May 4 2007. Presentation slides and paper reprint.
Retrieved from http://www.rlgsc.com/ieee/longisland/2007/ubiquitous.html on December 6, 2009
Sy Bosworth, Mich Kabay, and Eric Whyne. Computer Security Handbook, 5th Edition. John Wiley & Son, New York, New York 2009
Sy Bosworth, Mich Kabay Computer Security Handbook, 4th Edition John Wiley & Son, New York, New York 2005
Arthur Hutt, Seymour Bosworth, and Douglas Hoyt The Computer Security Handbook, Third Edition 1995, John Wiley & Sons, 1995

URLs for referencing this entry

Long:	http://www.rlgsc.com/blog/ruminations/networks-placed-at-risk.html
Short:	http://rlgsc.com/r/20091207.html