Fred Avolio
Avolio Consulting, Inc.
http://www.avolio.com/
This month I will look at what we might call “best practices” for internetworking remote offices. It is arguably an old topic–we’ve been connecting remote offices over Virtual Private Networks (VPNs) for a few years now. It is one of the main purposes for VPNs, second only to secure dial-in connections. And yet, I think most of us do it wrong. I want to suggest a way to do it better. (So maybe I’m addressing better practices.) I will do this by referring to how we did it wrong in my last job, and in retrospect, how we should have done it.
We started, as most small organizations do, with remote offices connected to the Internet. This was back at the beginning of firewall use, but before people were even asking for VPNs. We had 4 offices, each connected behind a router with filtering rules–the common, if not best, practice. The Internet was our backbone, so to speak, and we allowed any kind of IP connectivity between the offices.
As the Internet became a more dangerous place, the risks from TCP splicing attacks, IP spoofing attacks, and eavesdropping (listening in on IP traffic) increased. So, we added a more robust firewall, and decided to disallow the more dangerous IP services, such as file sharing. We protected the interoffice e-mail traffic by encrypting it between the office mail servers, a kind of e-mail-only VPN.
The firewall became the access control point for remote users. A person dialing in from home or a hotel had to talk to the firewall and authenticate himself before getting access for a terminal session.
Of course, all of those connections that traversed the firewall were vulnerable to eavesdropping and other attacks. Someone connecting across the Internet from, say, a computer room at a local university was liable to have his session “sniffed,” but the business requirements outweighed the risks. And we required employees to use security tokens or one-time password programs to eliminate the risk from password sniffing or guessing.
A few years later, firewalls with integrated VPNs became available. We made use of this new technology and connected the offices. Over this VPN we allowed any kind of IP traffic. To a user logged in to any internal network in any of the offices, once logged in it looked and felt–aside from the slower connection across the Internet–like one flat wide area network (WAN). To a user it was as if the firewall were not there. And therein lies the problem. Worse, this is still the most common way of creating an intranet today.
There are possibly numerous vulnerabilities, but generally and obviously we can see with virtually no firewall between the offices, there is no protection from insider attacks. A bad guy working in the Los Angeles office, for example, was free to connect to, and attack, any computer in any other office. There was an additional, and perhaps worse, scenario. If an outside attacker gained access to one office–say by sniffing the password of a negligent employee who circumvented the firewall by installing a desktop modem, the attacker now had access to every office for every defined IP service and protocol. Once inside, the attacker was INSIDE.
Fast-forward to today, with today’s threats in mind. Every office, every computer is vulnerable to a Trojan horse program that gains a foothold in any office. And such an attack would succeed because of our one, flat virtual WAN.
In fairness, what we did back then was considered good practice. With the current level and types of threats on the Internet, it is much too open. Many of us are running much too wide open today.
Instead of starting by eliminating some services, we should first eliminate all, and then add back in only the services required. I bet everyone reading this has heard “Whatever is not expressly permitted is prohibited,” but then does not think of carrying it to interoffice connections.
So, we start by asking, “What interoffice network services are required by most if not all people in the company?” We’d find that e-mail tops the list. But through the interoffice firewalls we only need to allow e-mail between the company e-mail servers. Perhaps we allow the *pulling* of mail–via POP for example–by any internal host from any other internal e-mail post office. This would allow visitors from another office to “plug in” and pull over e-mail from the home office.
Next, we might require web access from any inside user to any inside web server. Maybe we also have some internal databases that users must access. There are probably no other network services required by all. You configure the interoffice firewalls to allow these limited services to these limited servers.
Maybe there are some services required by a few. Remote software developers may need to run X11 or TELNET services. Perhaps a few need NetMeeting. After you have this list, you can add these services through the firewalls, but only for the particular individuals who require (not desire) them.
As alluded to earlier, then you turn off all services between the firewalls, and enable only the required ones, only for the users who require them, to the servers they are required to access.
“But,” you protest, “we’ve already set up our VPN, and we already allow everything. How do I proceed?”
Carefully, methodically, slowly.
First, find out what the requirements are by using a network traffic sniffer to catalogue the types of packets already flowing. Who is using what? Next try to make sense of it. Some protocols or services are probably not business-required even if used by many people (Napster comes to mind).
After a few days or weeks you should have a good sense of what needs to be permitted. Turn off everything and allow only those you discovered. What if you make a mistake and turn off a critical service? It is not a question of “if.” You will. So beforehand you do some research. But remember something I have said before: “It is better to be too restrictive than too promiscuous.” Words to live by in much of life, but also in our particular case of access between offices. If your configurations are too restrictive, you will hear about it. You will know that you turned off a service that was required. You rarely hear that you are allowing too much between your offices… unless you discover a network break-in.
A reprint of a recent column I wrote for WatchGuard’s Live Security service entitled “Corporate E-mail: What’s Your Policy” can be found at http://www.avolio.com/columns/email-sec-pol.html
Dave Piscitello ( http://www.corecom.com/), Joel Snyder ( http://www.opus1.com/), and I are presenting two VPN workshops at Networld+Interop in Las Vegas in May. Introduction to VPNs is on May 7 and VPN Design and Deployment is on May 8. See http://www.avolio.com/calendar.html for pointers and descriptions. Dave Piscitello and I have a feature article on e-mail security alternatives coming out in InfoSecurity Magazine. Look for it in the May edition (and a pointer to it here next month).