Network Computingwww.networkcomputing.com

The Internet Cookbook

 Recipe 3: Security with Firewall

Ingredients

A cup of security policy
One ripe architecture
One peck of internet services
One firewall
Several protection schemes

Introduction - What's my motivation?

When getting connected to the Internet, securing your IP-capable hosts will probably be necessary. Depending on the nature of your business, you will have to judge the sensitivity of the data on your networks and the relative security risk of the operating system on your network. If you have determined that you want to implement some security, we will help you lay out your defenses.

Keeping your data secure is probably one of the most involving and engaging tasks related to Internet connectivity. Everyone is aware of the insecurity of the IP-related suite of application level services. That means that everyone on the Internet is a potential threat to your network once you are connected. There are a lot of Internet users out there with too much time on their hands.

To start your security plans, you will need to decide on a security policy. Before implementing anything, it is necessary to decide what your goals are for protecting your network without impinging on your users' productivity. You will have to decide on the actual tradeoffs based on the level of security desired. Once your security policy is decided, then you may move forward with a firewall strategy.

Some of the things to consider:

• Do you really need firewall protection?
  
• Do you want some unprotected hosts for Internet service, such as web servers?
  
• Will you need to pass e-mail through the firewall?
  
• Do all machines behind the firewall need their own unique addresses?
  
• Will you use VPN technology to connect other sites to your home site?
  

Planning

Architecture of exposed and hidden devices

The most effective architecture hides all sensitive devices behind the firewall and keeps an exposed area in front of the firewall for devices such as external web servers. In this figure, we illustrate a simple design for keeping your internal network safe while keeping your external resources unconfined.

In our scenario, you will only need legal Internet addresses for the devices on the external network. You can use address translation to give internal hosts access to the Internet as a whole. In addition, you can expose internal hosts at your own whim. We will discuss this later. For most organizations, a simple class C address space will cover all the machines they want to be exposed to the Internet.

Application support

DNS servers

Using our example scenario, you should definately think about using two separate DNS servers for your organization. Because you will be using an arbitrary IP address space internally, you don't want that data replicated to the Internet as a whole. That means your external DNS server should only contain entries that associate with the external hosts that have legal IP addresses.

For your internal DNS server, you can enter all of your internal hosts and their illegal IP addresses. In addition, you can point that server to your external server in order to look up host names on the Internet.

Web Servers, etc.

To give examples on how to arrange your machines with relation to your firewall, we will look at the external web server. It should sit outside the firewall with very little protection from the world. As such, you will not want to keep sensitive data on this server.

Once your external web server is up and running, you may want to allow it to make inquiries to machines that are within your organization (behind the firewall). Those holes can be opened one at a time. If you intend on letting your external web server query internal resources, you will probably want make certain that the web host is completely secure. If possible, you will want to restrict your web server to read-only queries as well.

Mail hosts

With mail servers, you can try to make things a bit more complex to prevent break-ins. We recommend a mail host on the outside of the firewall that can relay mail to an inside server. With your firewall configured properly, the internal server will only be able to send and receive e-mail from the external host.

Secure the firewall host!

From our desirable architecture, we see that the firewall sits between the external and internal networks. It implements the packet filters and all other security that we will discuss in this section. First and foremost, SECURE THE FIREWALL. If you are using a traditionally insecure operating system for a firewall, such as UNIX, you need to make sure to lock down all unnecessary services.

A firewall should be ju st that--a firewall. No other services should be running on the same box. Even though you may use a UNIX or NT box for the firewall platform, resist the urge to "just add one simple service." Though it may not load your machine very much, adding services to the firewall may expose vulnerabilities in the OS.

Actual protection schemes

Packet filtering

Packet filters are the basics for firewall protection. They reside on the firewall host or router and decide which data passes and which does not. Filters will be your first line of defense against unwanted traffic. A carefully thought out ruleset for packet filtering should keep your network very secure.

For every case, you should start by denying all services through the firewall and build up from there. When using a GUI tool, start with a rule that drops all packets. From there, insert new rules above the deny-all rule. This strategy will allow you maximum security to start and allow you to poke (known) holes as you need.

A starting ruleset (similar to one found in Checkpoint Firewall-1) for our configuration would look like this:

If we decide that we want internal users to be able to browse the web, we might add a rule between 2 and 3 that looks like this:

That will allow users to initiate web connections from inside, but connections cannot be initiated from the outside.

IP translation

Translating IP addresses is a great way to allocate a small number of legal Internet IP addresses while still connecting your whole network to the Internet. It also allows you to assign whatever addressing scheme you like behind the firewall (RFC 1918 for example). Most importantly, you can protect your network better by using address translation.

Say that you have a network consisting of 500 machines that you want to access the Internet. You can either get two class C block (256 * 2 addresses) or get a CIDR block of 512 (if your ISP supports that). That would cover your whole network. The other option is to calculate how many machines will need to be directly addressible from the Internet and get that many (class C or CIDR block of exact amount).

Using the example architecture that we have included above, you only need addresses for the router, firewall, and machines on the external network. The bulk of machines behind the firewall will be translated by the firewall--to the outside world, the internal machines will be using the firewall's address.

Let's say that you have a class C address for your external network, 206.215.108.x and you have used RFC 1918 class B addresses internally, 172.30.x.x (of which, you have used part of 172.30.12.x subnet so far). The IP address of your firewall is 206.215.108.4. For Checkpoint Firewall-1, we would have a translation table that looks like this:

Essentially, we have told the firewall to use it's own IP address to talk the world in lieu of the 245 IP addresses that are behind the firewall.

Now, say we have a machine (172.30.12.62) behind the firewall that the Internet in general needs to get at. We need to add two address tranlations so that the traffic can flow bi-directionally. As part of the solution, we would add a couple of lines like these to the translation table:

To the outside world, the new address of the machine is 206.215.108.10 and it appears to be located on the external network. The firewall will do the IP address substitutions and forward the packets to the proper host.

Virtual Private Networks

Dedicated WAN conections between offices can be very costly. When each site already has an Internet connection, you can use the Internet as your WAN. However, be forewarned that you should not count on the Internet for extremely time-sensitive data. Using encryption with VPNs will guarantee that nothing is intercepted, but does not guarantee delivery.

Configuring VLANS is fairly simple with firewalls that are already in place. It is often simply a matter of enabling the VPN features by paying for an enabler key. Once that is done you can configure encrypted paths through the Internet. In our example we will use shorthand for the various networks: main-internal - 172.30.12.x network, firewall - firewall at main site, and remote - 192.155.15.

Since we are using IP address translation, all traffic destined for internal machines at the main site will appear to be headed for the firewall. That is why the destination field in rule number 5 is "firewall." Note that because the internal hosts at the main site do not have unique IP addresses to the outside world, sessions cannot be initiated from outside.

Using the step-by-step approach here, we have built a very complex security system using simple VPN-capable firewalls. From here, you can add hosts and change allowed traffic in the same fashion that we have started here. Just remember that every time you allow one more service, you open another small window of opportunity to hackers. Be sure of the security risks of the windows that you open.

Print This Page

E-mail this URL