Securing Network Services and Infrastructure

This document presents some tips and suggestions for system administrators and network managers who are responsible for securing their networks. The document begins with an outline and basic steps for those new to server and network security. Each section below goes into more detail and includes links to configuration examples, software, and other helpful informations sources.

Links to external pages will open in a new window.

This document is largely aimed at the new or intermediate Unix/Linux system administrator who is looking to secure a server, or servers, on their network. Some discussion of general network security issues is included as well in the "Network Infrastructure" section of this document.

If you have feedback on the information you see here, or additional suggestions for content, please contact us at

Information Index

    Host/Server Based
  1. Outline and Basic Steps
  2. Physical Security
  3. Secure Passwords
  4. Services
  5. Firewalls and Protecting Services
  6. Updating and Patching Software
  7. Buffer Overflow Attack Prevention
  8. System Logging
  9. System Integrity Checking
  10. Backups
  11. Tools
    1. AntiVirus
    2. Spam Blocking
  12. Summary

  13. Network Infrastructure
  14. Firewalls and Routing
  15. Wireless Security

  16. Appendix:
  17. References

Host/Server Based Security

1. Outline and Basic Steps [Return to Top]

If you are new to security and are considering installing a Unix-based or Linux server there are a few things that you should consider before installation. If you have already installed and setup your server and it is on a publicly accessible network, then we strongly recommend that you take these steps to begin securing your box immediately. The assumption made here is that you have not taken steps to secure your server(s). If you have, then you may wish to use this list to review what you have done.

Ideally, you would install any network server box and secure it before connecting the box to the network. The reason for this is because many default installations of Linux or Unix have known security holes. If you install a network server and place it on a publicly accessible network for any time, then it may be compromised before you manage to secure the box. In addition, if the box is compromised, and then you install System Integrity software you may not notice your system is compromised, which defeats the purpose of using this type of software.

During your initial network server installation you can do this with your machine not connected to the network, or just connected to an internal, and secure network. You can connect your server as needed to update your software for security purposes, and then disconnect once updates are downloaded. Additionally, you can consider downloading any software updates you will need to another network server, and then copy this software to your new network server to avoid placing it on the network before you feel it is properly secured.

Critical Steps to Securing a Network Server

  • Remember physical security.
  • Use strong passwords.
  • Turn off services that you are not going to use.
  • Restrict access to the services you run.
  • Update or patch software for security holes.
  • Install buffer overflow attack protection.
  • Turn on and configure system logging.
  • Install System Integrity checking.
  • Back up your system.
  • There are several other steps and methodologies to securing your network and servers that you can take, but if you are just getting started, then you should make sure to put in place each of the systems listed above.

    It is hard to authoritatively say which of these security measures is the hardest to implement, but from a practical point of view for the first-time installation you will need to pay special attention to:

  • Restricting access to services.
  • Turning on system logging.
  • Installing System Integrity checking.
  • Implementing strong passwords, turning off services, patching software for security holes, backing up your system, and installing buffer overflow protection requires careful consideration, but you can, in many cases, put these in place fairly quickly. One caveat; in order to turn off services you may need to gain an understanding of what each service does and how it interacts with other services. Generally the Unix and Linux operating systems are fairly modular, and turning off a service, and what this affects, is fairly obvious - there are, however, exceptions to this. If you are new to the world of Linux and Unix here are several links with an eye to understanding what services do:

    Linux/Unix System Services

  • Major Services in a Unix System: From the Linux System Administrator's Guide.
  • Which services do we really need? from the Security Quick-Start HOWTO for Red Hat Linux.
  • 2. Physical Security[Return to Top]

    Before we get started with securing your server's operating system, and installed software, it's important that we mention physical security. You can secure your server fully and completely, but if someone gains physical access to the box, then it's likely there is little you can do to protect it. In extreme cases there are some things you could do, such as encrypting data on the drive, but for the most part it is trivial to gain root (administrator) access to a server box once it has been physically compromised.

    Consider the people who have physical access to your server or servers. Can you trust all of them? If not, perhaps you should consider placing your server(s) in a locked room of some type where only trusted individuals have physical access to the box.

    Finally, if you are printing logs to a printer, and you will rely on these logs in case of a security breach, then this printer must be secured, physically, in the same manner as your server or servers.

    3. Secure Passwords [Return to Top]

    The concept of what you need to do to have a secure password is better understood than previously, but what is not understood as well is how you actually implement this. It is fine to tell your users that their passwords must follow a rule set like this (from But, it is much harder to actually enforce this. You will need to install some systems to help ensure that secure passwords are used when they are created, or that they are broken in an automated fashion and the user can be notified and forced to change their password.

    There are several approaches to creating initial accounts with secure passwords. One is to create the account with some randomly generated password that is "secure" in terms of how hard it is to guess. Naturally the problem you must now deal with is how to get the password to the user in a secure manner. In reality, this is difficult. It can be done, but likely the password must be printed somewhere and then handed to the user on a sheet of paper. If you must create many accounts, then you will probably need to use a system such as this, but you should make sure the accounts are pre-expired. This means that the first time the user logs in, they will be prompted to enter in a new password of their own choosing. You might even insist that a user come in person to get their first time password, and then login and change to a new password on the spot.

    There are quite a few ways to go about building accounts on a system, and many tools are available to auto generate accounts and passwords. In general you will want to be sure that you are using Shadow Passwords on your system. Almost all new Linux distributions use Shadow Passwords by default. The use of Shadow Passwords simply means that your passwords and user information go in to the file /etc/shadow instead of /etc/passwd. The file /etc/passwd is world readable and contains user passwords in encrypted format. The problem with this is that it is possible to decrypt these passwords and compromise a system. The /etc/shadow file is only readable by the root user. If Shadow passwords are installed, then the /etc/passwd file simply contains username and group information, while the /etc/shadow file contains username and encrypted password information.

    If your system is not using /etc/shadow, then see the Shadow Password HOWTO file to learn how to install this system.

    Your next step to making sure that secure passwords are required and used on your system is to install the Pluggable Authentication Module system known as PAM. Most modern distributions install PAM and have it preconfigured. PAM is a flexible method by which you can use multiple authentication systems for multiple services (passwords, ftp, ssh, login, pop, imap, shutdown, etc.). The main PAM pages are here:
    In summary, you should have, at least, the following three things in place on your system for password creation:
    1. Shadow Passwords
    2. PAM: Pluggable Authentication Module
    3. A Password Checking Library
    You can configure PAM to require the cracklib password checking library when passwords are created. Cracklib is installed on most modern Linux and Unix distributions. Below are some useful links for implementing each of these steps: PAM and cracklib Example

    If, for instance, you have PAM and the cracklib installed somewhere on your system, you can set up the passwd command via PAM so that cracklib is used to verify that the password is secure. In reality the defaults are probably not secure enough for your system, but here is how you get started:

    Cracking Passwords After they are Created

    Finally, you can run other programs to crack user passwords once they are created. You should only do this if you are the system administrator on your machine. You, or your organization, will have to put in place policies for what should happen to user accounts with passwords that are not strong enough. For example, you could notify the user telling them to change their password, or you could notify them a certain number of times, then disable their account, or just disable their account, or expire their password forcing them to change their password the next time they log in. The choice is yours, and will be dependent on what level of security you need and the number of users you have. One piece of advice, if you have many users, then you may wish to notify the user first, possibly several time, before you expire their current password. Many users will not realize they have an expired password, or how to change it, as many users never actually log in to their own account! Rather, they may access their account indirectly to get email, publish web pages, etc.

    Here are three programs you can use to crack user passwords (list courtesy of Red Hat, Inc.):

    4. Services [Return to Top]

    Services are the heart and soul of a network server machine. Services represent the permanently running programs that listen for requests and respond to them. Understanding what you want to do with your machine will directly lead to deciding what services you need to run. Once you make this decision, then you should do the following: This philosophy is absolutely essential to running a secure network server. If you install your network server, run a bunch of services by default, don't restrict access, and don't update or patch the programs running then it is guaranteed that your machine will be compromised quickly. To see just how quickly check out the HoneyNet Project at, and in particular their Statistics White Paper from July, 2001.

    Steps to Securing Services

    A quick overview of what you should do to protect your services and to turn services on or off looks something like this:

    1. Decide what services you are going to run.
    2. Turn off everything else. That is make sure that services you are not going to use do not start under the /etc/rc.* directory structure (System V systems). There are many tools you can use to see what services are on or off, these include the command line tool chkconfig, the linuxconf graphical interface, YaST for SuSE, etc.
    3. Verify what services are actually running using the ps, and netstat commands.
    4. Understand the /etc/services files.
    5. "Wrap" your running services using facilities such as iptables. You can consider filtering services using methods such as the /etc/hosts.allow and /etc/hosts.deny files, or /etc/xinet.d/ but all of these have known attacks. Using well-written wrapper rules for tcpwrapper services such as iptables is much more effective.
    6. Finally, make sure that the services that you are running are up-to-date and that you know where to look for security alerts for these services.
    If you take this methodical approach to securing services on your server, then your server will be much likely to be compromised by known, or even by new attacks. Keeping your services up-to-date secures them against known attacks (for the most part), and using a tcwrapper service like iptables helps to keep people from compromising your services against new attacks.

    We'll discuss items 1 through 4 here. The next two sections will go over items 5 (wrapping services) and 6 (staying up-to-date) in more detail.

    What Services to Run

    As mentioned above in Linux/Unix System Services you will first need to have some basic understanding of what services are on your system and how they interact. On most Linux/Unix systems you can look in the directory /etc/rc.d/init.d/ to see the startup script files that are called as you enter different initialization levels when starting your server. These scripts are called to start, stop, restart, and query services. If you look through the directory structure under /etc/rc.* you will see a set of directories rc0.d through rc6.d. Exactly how things are setup varies from system to system somewhat, but the general idea is that for reach run level a set of Start and Kill links are defined. Depending on the number of these links this determines the order in which scripts will be run.

    Below is an example of a system (running too many services to be secure) and the Start and Kill scripts defined for runlevel 2. This runlevel is multiuser mode, with network, but without NFS (network file system). The initialization sequence will start with "K08autofs@", and end with "S99webmin@" - This means that in /etc/rc.d/init.d/ the script "autofs" will be run to kill (or stop) the autofs service, and at the end the script /etc/rc.d/init.d/webmin will be run. Note that scripts come in a certain order due to dependencies that services have upon each other.

    The topic or init/run levels, and how they work requires some studying to understand fully. Here are a few links that might help: The init command is a privileged user command, so you need to be an administrator to be able to issue this command.

    Some Linux systems have the chkconfig command available. If you want to see what services are running at what init levels you can issue the command:

    chkconfig --list | more
    Be sure to read the chkconfig man page (i.e. "man chkconfig") for how to use this command. Otherwise, you can use systems such as linuxconf, YaST ("yast" from the command prompt on a SuSE system), etc.

    One piece of advice; after you have installed any new Linux system check to see if Sendmail is running, and how it is configured to run if running. Sendmail has many security holes, and you should be running the latest version (find this at You should either turn Sendmail off, or configure it to start in "send only" by removing the "-bd" flag when it is run ("-bd" - means run Sendmail as a daemon).

    After you have setup your system to run the services you believe you want, then you should use the ps command to verify that they are running and that other services are not running that you do not expect. One note: If you install a graphical interface on your server (not recommended), and you run this service (such as XWindows with KDE or the Gnome desktops), then you will see many, many other services running and your system will be next to impossible to secure. The quick moral is, don't run graphical interfaces on a server box.

    On most Linux systems you can see a comprehensive list of what is running by issuing the ps command like this:

    ps -aux
    In addition, you should understand how the /proc/ filesystem works. For instance, if you see a process running with the process ID of "1000", then you could look at the contents of the file /proc/1000/cmdline using the command cat /proc/1000/cmdline to see how the process was started. You can, also look at the remaining files in /proc/1000/ to see more information about the process. Commands such as ps -aux simply take information from the /proc/ directory structure and present to you in a readable format. Note that you need to use a command such as cat when looking at these files vs. more, or less as they are not standard files.

    In addition, you should see what type of connections are being made to your machine. You can use netstat to do this. To see active connections on IP sockets to your machine use the command:

    netstat -A inet
    On some machines you need to use:
    netstat -f inet
    You should read the netstat man pages as this is a very powerful and useful command to understand who and what is connecting to your machine and services running on your machine. Generally netstat is a privileged command to be run by system administrators.

    There is one caveat to this discussion of running services, verifying what's running, and seeing how your machine is being accessed. If your machine has been compromised, then it is possible that you could either have services running that are hidden (this is if your kernel has been tampered with), or you could have a service running under the correct name, but that is doing something else. This is why it is critical that you install your operating system, choose services to run, and lock them down before you allow your box on the network.

    5. Firewalls and Protecting Services [Return to Top]

    The idea behind tcpwrapper systems is that your system kernel is compiled with support to intercept and act upon tcp/udp packets dependent on rule sets that you define. Almost all modern Linux/Unix distributions support this type of filtering of network packets. Using network packet filtering systems you can decide who can access what services (both incoming and outgoing connections). This is absolutely essential to protecting your system. For instance, you may have certain services that you only want accessed by people on or from your local network - using network filters you can do this. You can using rule set to help protect again SYN attacks, IP spoofing, etc.

    There are several well-known network filter packages. These include ipchains, iptables, and IPFW (for FreeBSD). For our discussion we will focus on iptables and include some examples. Here are some useful links for iptables and IPFW.

    As a general rule of thumb you will enable a service such as iptables in run-levels 2, 3, 4, and 5. The iptables services will start from a script located somewhere like /etc/rc.d/init.d/iptables, and this script may refer to a rule set that you define under /etc/sysconfig/iptables. There are other ways to do this, but this is one typical example. Or, if you use something like pfilter (mentioned above), simply add it in under /etc/rc.d/init.d/ and then use something like chkconfig to make sure the service starts each time you boot your server. Read the pfilter file for more information, but the command to do this would look like:
    /sbin/chkconfig --add /etc/rc.d/init.d/pfilter
    Be sure that if iptables is already in use that you stop this service, turn it off for future reboots, and then add pfilter as your service instead. The command set to do this would like look:
    /sbin/chkconfig --list | grep iptables

    If your output looks like this:

    iptables       	0:off	1:off	2:on	3:on	4:on	5:on	6:off
    then it is running. To turn it off do:

    /sbin/chkconfig --del /etc/rc.d/init.d/iptables

    and now to add pfilter as a service (this is still iptables, just using the rule set built in to the pfilter script) do:

    /sbin/chkconfig --add /etc/rc.d/init.d/pfilter

    You can use other tools for turning services on and off, but this is a common example and method for doing this.

    If you plan on using Samba for NetBIOS access, and your server is accessible to the outside world, then you will need to be sure that you block all TCP/UDP connections to ports 137, 138, and 139 to anyone not on your local network. There are many known security exploits for NetBIOS services.

    The /etc/services File

    This point brings up the /etc/services file. This file lists out TCP and UDP ports and what services are used on the ports listed. In general all ports from 0 to 1023 are considered to be "trusted" ports under Linux/Unix. That is processes that listen to connections on these ports or originate connections to a remote server from one of these ports must have superuser privileges. It's important to realize that you can change these ports by simply changing the assignments in the /etc/services file. This is, generally, not a good idea, except if you have specific reasons for running services on different ports.

    If you look in the /etc/services file you will see the following lines:

    netbios-ns      137/tcp         nbns
    netbios-ns      137/udp         nbns
    netbios-dgm     138/tcp         nbdgm
    netbios-dgm     138/udp         nbdgm
    netbios-ssn     139/tcp         nbssn
    per our discussion above, this is how you can quickly find out what ports have NetBIOS services running on the, and this is why ports 137-139, both TCP and UDP connections should be restricted if you plan on using any services that will listen on these ports (such as Samba).

    It's interesting to note that Windows does not have the concept of "trusted" ports and that services running on ports 0 through 1023 do not need to have superuser privileges under Windows.

    In addition, you can use a command like netstat to see what ports are listening on your machine. You could use:

    netstat -l -n
    to show you the numeric ports that are listening on your server at this moment. If you see anything unexpected, then you can investigate this. If you are looking for services that may have been installed on a compromised box, then you will often find them above port number 1023. Ports can be numbered up to 65535. So, if you suddenly see something listening on, for example, port 54666, you may want to investigate what this is!

    6. Updating and Patching Software [Return to Top]

    We place this section here since many, actually almost all, Linux and Unix distributions are "out-of-date" by the time you install them. What we mean by this is if you plan on running some number of services, then it is very likely that there are already updates and security patches to some of these services even if the Linux or Unix variant you are installing is the latest and greatest release from your favorite vendor.

    Once you have installed your preferred installation of Linux/Unix and decided upon what services you are going to run, then you should methodically go and check on the following:

    *We do not reference FTP or Telnet here as both are insecure. You should use SSH and SCP instead. If you are using FTP, then ProFTPD info is at, WU-FTPD info is at, and the Telnet daemon man page is at

    To summarize, update your distribution once it is installed, then update any services you plan to run, then be sure you sign up for security notices at both your distribution's web site as well as at the general security sites such as CERT, SANS, and SecurityFocus (home of Bugtraq).

    7. Buffer Overflow Attacks and Prevention [Return to Top]

    Some of you may be asking, "What is a 'buffer overflow' attack?" Here is a short description of generally what a buffer overflow is (from ",,sid14_gci549024,00.html"):
    A buffer overflow occurs when a program or process tries to store more data in a buffer (temporary data storage area) than it was intended to hold. Since buffers are created to contain a finite amount of data, the extra information - which has to go somewhere - can overflow into adjacent buffers, corrupting or overwriting the valid data held in them. Although it may occur accidentally through programming error, buffer overflow is an increasingly common type of security attack on data integrity. In buffer overflow attacks, the extra data may contain codes designed to trigger specific actions, in effect sending new instructions to the attacked computer that could, for example, damage the user's files, change data, or disclose confidential information. Buffer overflow attacks are said to have arisen because the C programming language supplied the framework, and poor programming practices supplied the vulnerability.
    If you would like more detail on how buffer overflows actually work and interact with operating system and hardware stacks see article.

    Libsafe Project

    Based on this information it is not surprising that a large number of the attempted attacks against system services involved buffer overflow tricks. Even though vendors patch their programs when they discover code that can result in a buffer overflow, it is almost impossible to solve this problem in this manner. Instead, their are several possible methods to protect against such an attack. One very elegant method is available from Avaya Labs Research and is known as the Libsafe Project.

    We strongly recommend that you download the latest version of Libsafe from the page above and install this on your system. Below is a description taken directly from the Libsafe Project web site about how this product works to prevent buffer overflow attacks:

    "Our solution is based on a middleware software layer that intercepts all function calls made to library functions that are known to be vulnerable. A substitute version of the corresponding function implements the original functionality, but in a manner that ensures that any buffer overflows are contained within the current stack frame, thus, preventing attackers from 'smashing' (overwriting) the return address and hijacking the control flow of a running program. We have implemented our solution on Linux as a dynamically loadable library called libsafe."

    In addition, Read the Libsafe man page before installing! You will need to update some environmental variables in order for Libsafe to work correctly. You can either restart individual services (kill -HUP pid) to have them take advantage of Libsafe, or you can choose to restart your server.

    Notes and Other Buffer Overflow Protection Schemes

    There are a few things to consider as you go forward protecting yourself from this type of attack. These include:

    There are several other buffer overflow protection schemes. These include the following:

    For those who want buffer overflow protection without the complexity of a recompiled secured system such as Stackguard or WireX, should definitely install Libsafe or use the Openwall kernel patches. If either of these methods are used it is important that Libsafe or Openwall be installed before you allow your server to be connected to the network. You should download Libsafe and/or Openwall on a separate machine and install these products first. In the System Integrity Checking section you will see that you need to start with a clean machine before you can trust these systems to protect you. If you install a buffer overflow protection scheme after your machine has been on the network, then there is no way to know for sure that your server has not been compromised, and that compromised software has not been installed on your box.

    8. System Logging [Return to Top]

    What you decide to log, where you decide to log information, and how you decide to do this can go a long ways toward securing your system. Not only can logging help you to detect security breaches, but it can help you to verify that software is running as expected, detect hardware problems, and get a general feel for how your box and it's users work.

    An excellent discussion of system logging for Linux and Unix can be found in the O'Reilly book, "Practical Unix & Internet Security, 3rd Edition" ( Chapter 21 discusses auditing, logging, and forensics under Linux and Unix. Additional resources that discuss system logging include:

    As you consider what you are going to log you should also consider where you are going to log. That is, will messages generated as you log go to the console, a file, another server, a printer, or to a protected file system. In addition, what about the /etc/syslog.conf file. If your system is compromised, it is possible that your /etc/syslog.conf file may be changed to turn off logging of certain activities. This might be the first step taken once someone breaks in to your system. To avoid this, you place your /etc/syslog.conf file on a read-only CD-ROM, or on a disk partition that is mounted read-only (r/o). For example, imagine your server box has several CD-ROM drives. Then, you can start the syslogd daemon like this:
    syslogd -f /mnt/cdrom1/etc/syslogd.conf
    This would start the syslogd daemon using the read-only copy of the syslogd.conf file located on /mnt/cdrom1 in the etc directory on this cd-rom.

    In addition, where are you going to output syslogd messages? You can, for instance, have syslog output messages to a network broadcast address. You could, then, have a receiving box on this network with the syslog daemon started with the "-r" option to receive syslog messages from the network. With this method you could "hide" the identity of your network syslog server, and have this server do nothing but receive syslog messages, and save them to its file system.

    You can, also, log files to multiple locations. Meaning you could log results to your local server and have copies of log files saved to a network server as mentioned above.

    Log file can, also, be printed rather than saved. This is great as once a message is printed, it cannot be changed by someone compromising your system. The downside to this is that you only have one copy of your log messages. You can do this by sending syslog messages to a serial device.

    The most important thing is that you do define what you are going to log, how you are going to log this information, and how you are going to keep track of what is logged. Here we present some tools for reading the various log file created, a small sample log file, and some more informational links to get you started:

    To finish this section we would direct the reader, once again, to the O'Reilly book, "Practical Unix & Internet Security", and chapter 21 in particular. You can read about this book in more detail at:

    9. System Integrity Checking [Return to Top]

    Your first question may be, "What is System Integrity Checking?" The basic concept is that once your system is configured, patched, and secured, then how do you know if something changes that you don't expect? Answering this question is actually harder than you might think, and it's at the heart of system integrity checking. In a nutshell, you should be able to tell a program or service that you expect your system to look like it does, and that certain changes are OK, but anything else is unexpected and should be immediately dealt with. That is, some action should be taken, such as shutting down the box (this might be excessive), warning the administrator, warning users, etc.

    One very simple method to do some basic checking is to generate md5 checksums on each and every file on your system. You can then run a script (using cron, for example) that compares expected md5sums with newly generated md5sums for all files on your system.

    Immediately you should see some problems associated with this:

    These are the types of issues that automated systems, such as Tripwire and AIDE, help you to deal with. Below we discuss two of the more popular intrusion detection systems in more detail:


    From the Tripwire FAQ locate at here is a short explanation of what Tripwire is:

    "Tripwire is a tool that checks to see what has changed on your system. The program monitors key attributes of files that should not change, including binary signature, size, expected change of size, etc. The hard part is doing it the right way, balancing security, maintanence, and functionality."
    Your hardest decision with Tripwire will be to determine the ruleset that you put in place. These links and the Tripwire documentation should help you to create a ruleset that works for your server environment.

    AIDE: Advanced Intrusion Detection Environment

    From the AIDE home page here is a quick description of what AIDE does and how it works:

    AIDE (Advanced Intrusion Detection Environment) is a free replacement for Tripwire. It does the same things as the semi-free Tripwire and more.

    "AIDE creates a database from the regular expression rules that it finds from the config file. Once this database is initialized it can be used to verify the integrity of the files. It has several message digest algorithms (md5, sha1, rmd160, tiger, haval, etc). that are used to check the integrity of the file. More algorithms can be added with relative ease. All of the usual file attributes can also be checked for inconsistencies. It can read databases from older or newer versions. See the manual pages within the distribution for further info. There is also a beginning of a manual."

    Here are some links to help you get started creating a usable AIDE configuration file for your server: Tripwire and AIDE are great tools for detecting change on your system, but what about active attacks, particularly network attacks against your system? There are numerous tools for helping to detect such attacks, and to look for possible vulnerabilities on your server or your network. One of the most commonly used tools for network intrusion detection is Snort.

    Snort: Open Source Network Intrusion Detection System

    You can get Snort at To get a feel for how Snort works take a look at the first chapter of the Snort User's Manual. Look at the main Snort documentation page. Here are a few more Snort links that might be useful:

    Additional Intrusion Detection Tools and Articles

    Some items in this list are commercial products. Parts of this list taken from

    10. Backups [Return to Top]

    Backing up your server once everything is installed and setup just the way you want it is very important.

    You might be asking why we include backup as a topic under security. If your server is compromised, then you will need a good set of backups to recover from the compromise. If you know when the compromise took place, then it may be possible to restore your server and it's data relatively quickly. If you are unsure of when your server was compromised, but you know what the compromise was, then you could decide to rebuild your server, but restore user data. Naturally you are running the risk that you have a compromised user on your system with tools to break in to your system from the inside. Restoring user data in this case is a decision you would have to take. Finally, a system with a backup, including your configuration files, can be much more quickly rebuilt if you have your old configuration files to refer to. You may wish to take a snapshot of your system once you have it running just as you want it for the first time in case you ever need to refer to your original configuration files to rebuild your server.

    Once you make the decision to put a good backup system in place, then your first set of decisions concerning backups include the following:

    This is quite a few questions, but they are really important. If you don't believe us, wait until you lose data or a server, and see what happens if these questions have not been answered ahead of time!

    What follows are some of the more popular backup solutions under Unix/Linux, and some methodologies for answering these questions.

    At the top of our list are three tools you can use to backup your server to the media of your choice. These include:

    There are other backup tools available, but these are very commonly used. Some additional links to other tools and documents follow at the end of this section.

    Backup Methodology

    Let's consider what it is you need to back up. Each server will look a bit different, but let's take a server that looks like this as an example:

    You could consider several approaches to backing up a system like this. Remember, your end goal is to be able to recover your server completely if it fails completely. In addition, if a user, or you - the administrator - loses the occasional file it would be nice to be able to restore that file from a backup.

    The first thing to remember is to never backup your data to the same partition, or same disk. This should be obvious, but we state it just in case... Ideally you should back up your data to a different physical device than your server. At the very least, you should back up your data to media that can be removed from your server. Remember, if you back up to CD, Tape, DVD, another disk drive that can be removed, etc., and your server is completely lost (i.e. - it burns up, is destroyed, etc.), then you will need a device that can read that media in order to restore your files to a new server! This fairly obvious, but a key point that is sometimes forgotten.

    Now you should decide what gets backed up and how. You could just do an entire disk image backup and always be able to restore your entire machine. This might work if you are lucky enough to have something large enough to fit your entire disk, but more likely than not, you will only want to back up what's necessary, when it's necessary. In this case you can consider backing up your system files and configuration files as necessary, maybe weekly. Now you need to backup your user's data and your constantly changing system data. User data and log files should be backed up daily. In practical terms you'll want to consider something like:

    This is still not complete because you need to think about how long you keep your backups. That is, do you keep the weekly backups (where you should do both daily and weekly backups) for a month? Then do monthly backups and keep them for a year? Then do semi-annual backups and keep them permanently?

    The suggestion above is just that, a suggestion. Almost certainly you will do something different, but it's just to give you an idea of how to approach backing up your system. In addition, you may noted that some policies are implied by your backup routines. For instance, if you do not back up files in /tmp or /scratch, then users who have work files in these locations will lose them. This is generally considered to be acceptable practice as anyone using a directory such as /scratch should be able to copy the files they need to their own directory for safekeeping. But, on some systems, particularly heavey research servers, this may not be acceptable. You, as a system administrator, will have to set such policies based on how your server is used.

    You may find that you can back up your system files only when they change if your server is fairly static. But, if you apply patches on a regularl basis, particularly for security reasons, then you will want to back up your system files fairly regularly as well.

    Once you have chosen the media you are going to back up to (CD, DVD, Disk, Tape), and your backup program, then you should be sure to test restoring data from this media. Ideally you would have a spare server on hand and you would do an entire site restore to test if you can bring your server back up, on-line quickly from your backups. If you do not have this available to you, be sure you test restoring files from all your different types of backups and media. Remember, if you lose your server - do you have a way to restore your server's data and bring it back on-line using your backups? This is the question that you should be able to answer once you put your backup system in place.

    Additional Backup Tools and Information

    11. Tools [Return to Top]

    Below are a few tools that you can use when dealing with viruses and Spam. As a system administrator your user's are going to ask you to block incoming email with viruses and to help stop all the spam that they receive. This is easier said than done, but there are some tricks and tools you can use

    11a. Antivirus

    One simple method of "defanging" potential virus attacks arriving to your user's mailboxes as email attachments is to use your MTA (Mail Transfer Agent) to check all incoming email attachments and to add the ".txt" filename extension on any suspicious looking attachments. In general this means that all files with extensions like ".exe", ".pif", ".scr", ".com", ".bat", ".reg", ".asp", "vbs", etc. If you do this, then the user can view harmless code first. If they determine that the file they have received is safe, particularly if they scan it with their own local anti-viral software, then they can simply remove the ".txt" filename extension and use the file.

    In addition you can considering installing a program to scan your incoming mail to your local MTA (Mail Transfer Agent). This way, if a virus is detected in an incoming email to one of your users, then this program can take action before your user is affected by the virus. A popular program for this that works under Linux, BSD, Solaris, etc.) is MailScanner. You can find this at, and you can download the program at

    Otherwise, you can work to make sure that your users have their own local anti-viral software, and/or you can install additional anti-viral software on your machine. Generally anti-viral software that scans incoming email for viruses is both expensive, and can require considerable CPU time if your server receives large amounts of email:

    List of Some Linux/Unix AntiViral Tools

    11b. Spam Blocking

    At the server side you have several methods to attempt to block spam for users. Here is a detailed presentation on how this is done at the University of Oregon on their large Solaris systems in the following formats: PDF | StarOffice | PowerPoint.

    Otherwise, you can consider using some of the commercial and freeware packages presented here. By far, the most popular package running under Unix/Linux is Spamassassin. You will, however, have to decide if you can use this due to possible false positives. This is always an issue when blocking spam - how do you deal with legitimate email that gets taggged as spam. So far, there is no good answer. Be sure to see the presentation referenced above for some discussion of this.

    Anti-Spam Packages

    12. Summary [Return to Top]

    At this point you've read through a rather long document and it may be a bit hazy about what exactly we are suggesting you do to secure your Unix/Linux box. Here is a quick review of what we mentioned at the beginning of this document:
    Critical Steps to Securing a Network Server

  • Remember physical security.
  • Use strong passwords.
  • Turn off services that you are not going to use.
  • Restrict access to the services you run.
  • Update or patch software for security holes.
  • Install buffer overflow attack protection.
  • Turn on and configure system logging.
  • Install System Integrity checking.
  • Back up your system.
  • Now we present this same list, but with the most commonly used or recommended systems used to for each item:
    Critical Steps to Securing a Network Server

  • Remember physical security: You may secure the software and operating system on your box, but if the wrong people have physical access to your server, then all this effort could be in vain.
  • Use strong passwords: Set up your ruleset for strong passwords. Use PAM (Pluggable Authentication Modules) with cracklib to ensure that passwords used are strong. Consider running a cracking program against your user's passwords for additional password security checking.
  • Turn off services that you are not going to use: Use chkconfig, Linuxconf, YaST, or some other tool to figure out what is running and turn on and off services that you do and don't want to run. Use netstat and ps to verify what is running and active on your server.
  • Restrict access to the services you run: Use iptables or IPFW (FreeBSD) to restrict access to each service running on your server.
  • Update or patch software for security holes: Go to the web site of your Unix/Linux distribution and look for updates, security announcements, and security mailing lists. Go the web site for each service you are running and look for updates, security announcments, and security mailing lists. Install updates and patches as needed. Sign up for critical security mailing lists such as CERT, Bugtraq, and SANS newsletters.
  • Install buffer overflow attack protection: At the very least install Libsafe on your system. Consider using more restrictive products such as Openwall kernel patches, or WireX (Stackguard is the free, older version of WireX).
  • Turn on and configure system logging: Use the syslog facility available in Unix/Linux and decide events you are going to log. Consider what events are critical and how you will be warned (email, printouts, messages on screen, beeps, etc.). Consider where your logs go - to a printer, separate network log server, an R/W CD-ROM drive, etc. Be sure that each service you run has some sort of logging associated with it - at the very least logging if there are problems.
  • Install System Integrity checking: Consider using Tripwire or AIDE for system intrusion detection. Consider Snort for network intrusion detection, and consider other network detection products, such as NMAP, to verify the security of your services. Look at the list of scanning tools to help determine if your server really is secure against network attacks.
  • Back up your system: This one is overlooked. If your system is compromised and you have no backup, then you will have to start from scratch. Choose what needs to be backed up, and what can be rebuilt by hand (easily), then choose the backup product that works best for your environment and budget. Plan a backup schedule and implement it. We recommend planning your backup strategy before you install your server.
  • These are not absolute recommendations for all server systems, but if you follow them you should be able to secure your box against most attacks. In addition, as you read this document you can see that you can make each piece of the security puzzle more comprehensive, or you can choose to do the minimum. We recommend that you do something to secure each item mentioned in this list. If you skip any of these items, then you system is not secure, and it can be compromised if it is accessible on the Internet, or by multiple users.

    Network Infrastructure

    In general there are several basic ways to approach this issue. You can attempt to protect your internal client machines entirely through your routers, you can block some known security holes from getting through to your internal network via your routers (such as NetBIOS), or you can assume that your internal network boxes are so well secured that you do not need to protect them in any way. Realistically, you are likely to give some basic protection to your internal network servers at your border routers to your internal network.

    13. Firewalls and Routing [Return to Top]

    Here are a few examples of Cisco router configurations that might be useful: If you look at the two "Border router config" files listed you'll notice they both block incoming udp requests on ports 137-139, and 445, as well as incoming tcp requests on ports 137, 139, and 445. Ports 137-139 have to do with NetBIOS access, while port 445 is used by Windows 2000 for SMB over TCP; see for a discussion of this. Windows client boxes are almost certainly not secured and extremely easy to compromise if you allow outside users access to your internal network ports 137-139, and port 445. There are many other ports that you may or may not want to block. This generally tends to be an internal organizational discussion about the trade offs in security vs. the inconvenience of not allowing outside access to some of the services on your internal network servers. This discussion is different for most every organization. Many groups will decide to block the RPC (Sun Remote Procedure Calls) tcp and udp port 111, as well as the LPR tcp port 515. Note that Samba (the Linux/Unix NetBIOS service) uses port 111.

    Another option on your part is to create what is called a DMZ (Demilitarized Zone). One way to do this is to simply block all incoming services at your border routers. While this may sound reasonable, it very rarely works. Generally the larger your organization, the harder it will be to enforce such rules. For instance, eventually someone (perhaps an important administrator) will insist on external access to some server. You might decide to give them access via SSH, so that at least they are using a secure protocol when accessing your network. While this is a good idea, users can now use SSH to tunnel other services in and out of your network, and, SSH has had various vulnerabilities exposed over the years. If you forget to patch SSH, or if you have many servers running SSH, then it's entirely possible that one of them may eventually run an insecure version of the protocol. And, this is just one service! Imagine what happens if several "holes" are opened in your DMZ. At this point you might as well concentrate on securing your individual servers on your internal network.

    Now that you may be thinking it's time to look at securing your individual servers again, then you will want to understand and implement firewalls well. Please refer to the Firewalls and Protecting Services section of this document for a complete discussion, examples, and references.

    Cisco has provided some very good tools to learn about security as it pertains to routing, particularly from the perspective of an ISP. You can find all of this at (mostly in PDF format). Here a few sample items included at this location:

    14. Wireless Security [Return to Top]

    There are, naturally, several issues surrounding security and wireless networks. The major issue is that most the methods built in to the 802.11a/b networking protocols for security can be broken by a determined hacker. The methods generally available for securing your clients with Access Points are WEP 40/64 bit and 128 bit, required SSID's (Service Set Identifier), MAC (Media Access Control) access authentication, and passwords (if supported by your client). The issue with these methods are the following: In addition, you should change the default SSIDs and passwords that come with your equipment. With that said, you should still use 128 bit WEP encryption, and, if feasible, use a MAC address filtering mechanism. Most access points have MAC address filters. This means that if a machine's MAC address (really the wireless card in that machine) is not registered with the access point, then that machine is not allowed on the network - even if the WEP key, passwords, etc. presented are correct. These steps will make it considerably more difficult for someone to break in to your wireless network - at least at a first attempt. There are users who look for open wireless networks to gain free access to the Internet. Putting basic protection in place will stop many of these types of users.

    Below we will present several resources discussion how to further protect your wireless network, including the possible use of VPN's to add another layer of authentication to your wireless network. With this said, however, it's important to remember that the best protection is to ensure that your users are working with secure services from end-to-end on your wireless network. That is, if you protect someone on your wireless network from having their password guessed this may be great for your part of the network, but what if they are still using insecure POP to get their email. Once their password leaves your protected network, then it will, once again, be out in the clear. The best long-term defense is to work toward migrating all your clients to secure network use with protocols such as POP/IMAP over SSL, SSH instead of Telnet, SCP instead of FTP, and HTTPS instead of HTTP when reading email over the web.

    By MAC authentication we mean that most wireless access points allow you to specify a list of Ethernet hardware addresses and IP numbers. This generally does not scale well, but if your network is small enough, then you can insist that all new members of your network first see you with their wireless card so that you can register its MAC address in your wireless access point, and assign an IP address to that MAC address. This is a 1-to-1 mapping of hardware on your network, which can be very powerful in terms of security - but, once again, can be very hard to scale to a larger number of users.

    Wireless Security Resources


    15. References [Return to Top]

    Below we list out in the order they are presented all the links and references in each section of this document.

    Back to Top

    | NSRC Home | International Networking Developments Database | Networking Technology and Tools |
    | Network Administration | General Computer Networking Info | Networking Tips and FAQs | Workshops |
    Search: Match: Format:

    Network Startup Resource Center
    Last Update
    November 17, 2003