Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Save the Children

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Networking

· Firewalls
· Securing the Server
· Securing the Internal Network

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 56 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

Linux Tutorial - Networking - Firewalls - Securing the Server
  Firewalls ---- Securing the Internal Network  

Securing the Server

A key aspect of a firewall is the security of the firewall itself. If it is not secure, it is comparable to locking all the doors to your house, but leaving the key under the mat. Therefore, taking the key with you, or for that matter throwing it away is a much safer alternative.

So what do I mean when I say "throwing away the key"? Well, what I mean is that you eliminate all potential routes that an intruder can use to get through the firewall or from the firewall to the internal network. Granted, your security should be sufficient enough that the intruder cannot get into the firewall in the first place. However, you need to plan for that possibility.

The question is not whether I am too paranoid, but rather whether I am paranoid enough. To me, not making the firewall machine secure is comparable to locking all the doors and writing your safe combination on the wall next to it. Okay, the house is secure, but should someone break in, they have free run of all your valuables.

So, let's first talk about locking the doors.

The purpose of your Internet gateway is to provide a gateway to the Internet. Sounds simple enough, but what that means is not always clear. The question you need to answer is "What is the purpose of the Internet connection?" The answer to which will define what steps you take to secure the firewall.

For example, let's assume that you have a Internet connection so that your employees can connect to the Internet, but do not provide any services yourself. In this case, you do not need to enable services on the firewall such as FTP or HTTP. All that happens is packets are routed through the firewall. Therefore, you can remove the daemons themselves (i.e. telnetd, ftpd, httpd, etc) and the programs (telnet, ftp, etc.). To simply disable them, place a pound sign in front of the appropriate entry in /etc/services.

This is where a lot of controversy occurs. In a article I wrote for a number of years ago, I describe the procedures as "throwing away the key", in that the programs and daemons were physically removed from the machine. Some people disagree and say to move them to a place that the normal user would not have access to. The reason being the difficultly in administering the system should these programs be needed.

Despite the respect I have for their technical capabilities, I have to disagree with him on this point. Although he is correct that it does make the administration more difficult, there are two important security issues involved. First it makes hacking more difficult. If these programs are not on the machine, they cannot be compromised. You have, in essence, thrown away the key.

The other issue is that hackers are not normal users. They are sneaky, plodding and patient. Maybe you have hidden the file on the system, but a good hacker isn't thwarted by such simple tricks. I wouldn't be and I am not even a good one. If a program was not in it's original location, the first thing I would do is to see it was anywhere on the system. I have seen administrators simple rename the file to something like telnet.orig so simply starting telnet, does nothing.

My attitude is that it is better to err on the side of inconvenience than on security. If you discover that access is too inconvenient, you can always change it. However, if you discover that the security is too lack, it's too late.

I apply this same attitude when it comes to the services that I make available. If you remember for the networking chapter, the available services are defined in /etc/services. My suggestion is to first comment out every service. Then, one-by-one, uncomment those that you want. Yes, you may forget one and cause a certain amount of inconvenience. However, doing it this way you know exactly what services you are enabling. If your forget to enable one, you have inconvenienced someone. If you do it the other way, by disabling the ones you do not want, if forget to disable one, you may have let the would-be hacker into your system.

Another means of securing your system is to limit access to the machine. There is, of course, the issue of the physical security of the machine. If someone has physical access to your firewall all the network security in the world is of little value.

What you turn on depends on what your needs are. For example, if you ware providing FTP and HTTP services these two entries should be uncommented. (Note this assumes that httpd is running from inetd and is not stand-alone). I would definitely say that on the firewall, you should not uncomment netstat, systat, tftp, bootp, finger, and ntp. There is no reason that I have ever heard of to make these services available across the Internet. Personally, I think you should also leave out telnet and login (for rlogin). The key is to only give what you have to.

To set this all up there needs to be a couple of changes in the kernel. Obviously, the basic networking functionality needs to be turned on, but there are two other options that you will find useful. The first is IP_FORWARDING. This needs to be turned off so that packets are not passed through the firewall.

The next is IP_FIREWALLING. This is necessary for the basic firewall functionality. If you want to keep track of the IP packets, then you need to turn on IP accounting. I recommend doing this because it allows you to keep track of from where the packets are coming and where they are going.

Another concept is the idea of IP masquerading. With this enabled, the internal network is "invisible" to the rest of the world. What happens is the firewall server converts the IP addresses so that machines on the Internet think they are communicating with the firewall and not an Internal machine. You can then assign IP address to your internal network that reside with the private ranges as defined by RFC 1918. IP_FIREWALLING must be enabled for this to work.

If you plan to use your firewall as springboard, then the configuration is basically complete. However, if you are planning to go from your workstations through the firewall, then there is more that you need to do do. This is where the concept of a proxy comes in.

There are currently two well known proxy packages available for Linux. The first is "socks", which operates as a full proxy and can work with any program. There is a single configuration file and a single daemon that need to be configured.

The other is the TIS firewall toolkit, which requires a new version of each daemon that will be going through the firewall. If you do not want users to have access to a particular service, then you just don't provide them with the necessary programs. However, with socks, it is easier to unintentionally allow access.

Although not really a firewall, the TCP Wrapper program can be used to control access to and from a specific machine. That is, it must be installed on each machine individually. In contrast, a firewall works for all machines that are trying to get passed it to the Internet.

The socks proxy server is available on many of the newer distributions. If you don't have it you can get as a gzipped tar archive from ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz.

It is here that we have come to the point where we have locked the door and put "The Club" into our steering wheel. The Firewall HOWTO goes into details of the actual configuration of the proxy server and the associated files.

 Previous Page
  Back to Top
Table of Contents
Next Page 
Securing the Internal Network


Test Your Knowledge

User Comments:

You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
You can help in many different ways.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.17 Seconds