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 nsrc@nsrc.org.
Information Index
1. Outline and Basic Steps [Return to Top]
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 ServerThere 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.
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.
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:
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:
2. Physical Security[Return to Top]
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]
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:
http://www.kernel.org/pub/linux/libs/pam/In summary, you should have, at least, the following three things in place on your system for password creation:
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:
locate cracklibthe output from this command might look something like this:
Notice that the file "pam_cracklib.so" is located in /lib/security/ on this system./lib/security/pam_cracklib.so /usr/share/doc/packages/cracklib-2.7 /usr/share/doc/packages/cracklib-2.7/HISTORY /usr/share/doc/packages/cracklib-2.7/LICENCE /usr/share/doc/packages/cracklib-2.7/MANIFEST /usr/share/doc/packages/cracklib-2.7/POSTER /usr/share/doc/packages/cracklib-2.7/README /usr/share/doc/packages/pam-0.75/modules/README.pam_cracklib /usr/share/doc/packages/pam-0.75/modules/pam_cracklib.sgml /usr/share/dict/cracklib_dict.hwm /usr/share/dict/cracklib_dict.pwd /usr/share/dict/cracklib_dict.pwi /usr/libexec/webmin/pam/pam_cracklib.so.pl
which means that any password used must go through the pam_cracklib.so library to be approved. In addition, the user is allowed three attempts before their account is locked for some random period of time if they do not enter in a valid password.password requisite /lib/security/pam_cracklib.so retry=3
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]
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:
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:K08autofs@ K12mysqld@ K14alsasound@ K14khttpd@ K15httpd@ K15proftpd@ K40ldap@ K44rawdevices@ K50iplog@ K50xinetd@ K60atd@ K75netfs@ K84ypserv@ K89dhclient@ K89portmap@ K98kparam@ S10network@ S16apmd@ S20random@ S30syslog@ S35murasaki@ S45pcmcia@ S50medusa@ S55sshd@ S75keytable@ S85gpm@ S90crond@ S99cupsd@ S99local@ S99webmin@
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 | moreBe 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 www.sendmail.org). 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 -auxIn 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 inetOn some machines you need to use:
netstat -f inetYou 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]
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.
/sbin/chkconfig --add /etc/rc.d/init.d/pfilterBe 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 iptablesIf your output looks like this:
iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:offthen 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:
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).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
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 -nto 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]
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:
subscribe cert-advisory
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]
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 NetworkMagazine.com 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:
8. System Logging [Return to Top]
An excellent discussion of system logging for Linux and Unix can be found in the O'Reilly book, "Practical Unix & Internet Security, 3rd Edition" (http://www.oreilly.com/catalog/puis3/). Chapter 21 discusses auditing, logging, and forensics under Linux and Unix. Additional resources that discuss system logging include:
syslogd -f /mnt/cdrom1/etc/syslogd.confThis 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:
9. System Integrity Checking [Return to Top]
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:
Tripwire
From the Tripwire FAQ locate at www.tripwire.org 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."
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.Here are some links to help you get started creating a usable AIDE configuration file for your server:"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."
Snort: Open Source Network Intrusion Detection System
You can get Snort at www.snort.org. 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:
Some items in this list are commercial products. Parts of this list taken from www.openbeer.it/security.php.
10. Backups [Return to Top]
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:
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:
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:
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:
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]
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 www.mailscanner.info, and you can download the program at www.sng.ecs.soton.ac.uk/mailscanner/downloads.shtml.
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
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]
Critical Steps to Securing a Network ServerNow we present this same list, but with the most commonly used or recommended systems used to for each item:
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.
Critical Steps to Securing a Network ServerThese 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.
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.
13. Firewalls and Routing [Return to Top]
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 ftp://ftp-eng.cisco.com/cons/isp/security/ (mostly in PDF format). Here a few sample items included at this location:
14. Wireless Security [Return to Top]
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]
subscribe cert-advisory
Arkeia
Cisco Security for ISPs: Sample Items
Securing Network Services and Infrastructure
