My friend Fred Avolio has a great deal to say about what he calls "better practices" for internetworking remote offices. He has several suggestions of how to improve the situation, along with lessons learned from what he did wrong in his last job. Take it away, Fred.
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 Virtual Private Networks (VPNs). We had four 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 various attacks 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 email traffic by encrypting it between the office mail servers, a kind of email-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 really INSIDE. This means that 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 email tops the list. But through the interoffice firewalls we only need to allow email 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 email post office. This would allow visitors from another office to plug in and pull over email 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.
Thanks, Fred. If you like what he has to say about VPNs and want to learn from the master himself, check out his teaching schedule and sign up for one or more of his courses. The next one will be given at the Vegas Interop in a few weeks.
To subscribe, send a blank email to
informant-subscribe@pez.oreillynet.com
To be removed from this list, send a blank email to
informant-unsubscribe@pez.oreillynet.com
David Strom
david@strom.com
+1 (516) 944-3407
back issues
entire contents copyright 2001 by David Strom, Inc.
Web Informant is ® registered trademark with the U.S. Patent and Trademark Office.
ISSN #1524-6353 registered with U.S. Library of Congress.