Linux DevCenter    
 Published on Linux DevCenter (
 See this if you're having trouble printing code examples

A Sysadmin's Security Basics

by Mike DeGraw-Bertsch

System administrators are no longer alone in their concern for security. The increase in high-profile virus attacks, and a general sense of heightened security, means that executives are likely to have security on their mind. It may be easier than ever to enlist their support for securing our networks and systems, and they may be more likely to put up with some inconvenience for users if it means tighter security.

This article gives an overview of the basics necessary to secure your network, including:

Consider this a checklist to reenergize your efforts or to get you started.


The first step in securing your network is to teach users to create secure passwords. All the security in the world is easily bypassed if your CFO's password is "fred."

I also recommend requiring users to change passwords monthly, and not allowing them to reuse one within a one-year period. Some people argue that requiring a password change will encourage users to write down their passwords, eliminating the benefits. I argue that in many environments a user's password is more likely to be hacked than to be read off a hidden sheet of paper. Even so, you can take IBM's purported approach: you write down your password, you're fired.

It's harsh, but with today's threats and the damage that can be caused by a compromised account, it may be worthwhile. Will it increase the calls to IT for forgotten passwords? Perhaps. One way to help combat that is to allow only a person's manager to request a password reset. Or, as I used to say when I worked at the Census Bureau, "No problem, done in two hours."

"Why two hours?"

"Don't forget your password."

Also, make sure your users know not to give their password out over the phone, even if the person claims to be from the IT department. Social engineering is the simplest and most effective way to gain access to a company's network. The same is true for physical site security: make sure strangers can't get into your office space. If that's impossible, make sure your users can identify your IT staff; just because someone has long hair and a wrinkled shirt doesn't necessarily mean they're actually on the IT staff.

For a more detailed explanation of good password policy, read this chapter on Password Problems from Managing Windows NT Logons.) In a Unix environment, run a tool like Crack against your password (better still, shadow) file to weed out any easy-to-guess passwords.

One more thing: administrators, too, need to remember to change all default passwords.

Email Attachments and Client Settings

Attachments have proven quite dangerous. Tell your users not to open any attachment they receive from anyone, unless they were already expecting it. If they receive an attachment that might be legitimate, a quick email or a phone call will confirm if it's legit or not.

I also highly recommend blocking all executable, DLL, and scripts at your mailer, or at least renaming the files so they don't execute if clicked. You can defang attachments with a Procmail filter called the Sanitizer.

Users may think they're safer if they have their macros disabled on Microsoft Windows applications, but they're not. SecurityFocus recently announced that malformed Excel and PowerPoint documents can completely bypass all security checks, allowing macros to run even when supposedly disabled.

If your users rely on Outlook, be sure to apply the appropriate patches. Visit Slipstick Systems for more information on Outlook security.

Firewalls and Demilitarized Zones

Moving on from users and passwords, we next look to the network itself. A firewall is a given these days. A DMZ, or a Demilitarized Zone, should be as well. A DMZ is a haven for machines that are exposed to the real world. The machines in a DMZ can be reached from the corporate LAN or from the outside world. But those DMZ machines cannot reach back into the corporate LAN to contact hosts within.

Related Reading

Building Internet Firewalls, 2nd Ed. Building Internet Firewalls, 2nd Ed.
By Elizabeth D. Zwicky, Simon Cooper & D. Brent Chapman
Table of Contents
Sample Chapter
Full Description
Read Online -- Safari

A firewall and a DMZ are not enough, however. What if someone gains access to your LAN, either physically or by compromising a user account or a partially exposed machine on the LAN? You should disable all the network services you don't plan on using on every machine on your LAN. This minimizes the potential exploits available to an attacker; all the more so since these are the very services you're unlikely to update and patch.

To help identify unused services that are running, try a package like SAINT (Security Administrator's Integrated Network Tool), which automatically scans all the machines on your network and reports open ports and other security risks in a simple Web interface.

Speaking of patches, be sure to apply security updates for the operating system and all the offered services of DMZ and internal machines. Keeping relatively current is also worthwhile--for example, BIND version 8 contains a bug that allows root access to the box, while BIND 9 does not have this problem. And while it takes a bit of effort, it's also worthwhile to keep all of your users' machines current as well.

The rest of this article discusses specific steps you can take to further increase LAN security. Remember, though, that without secure passwords and well-informed users, many other security measures are moot.

Securing Insecure Protocols

In the early days of the Internet, when security was not a big concern, insecure protocols such as Telnet and POP were fine, even though they transmit all passwords and data in cleartext. That's not acceptable today, either across the Internet or on a LAN. A wireless LAN, even one with 128-bit WEP security, is an even greater security risk, as anyone within range of your card can pick up all your unsecured data--even from outside your building.

Also on Firewalls

Beyond Firewalls

Proper Paranoia: Educating Your Co-Workers

BSD Firewalls

The SSH protocol provides a drop-in replacement for the Unix r-commands (such as rsh, rexec, and so on). The r-commands are very insecure, and what security they do offer is typically trivial to bypass. Public/private keypairs can be used to replicate the convenience of the r-commands passwordless connectivity. However, that opens another security hole: hack one machine with a passwordless keypair and you have access to all the related machines as well. Deploying SSH is pretty simple; you can even remove the r-commands and replace them with symbolic links to the SSH equivalent.

SSH also serves as a capable Telnet replacement, and as one O'Reilly person pointed out, the heck with the security, it's one of the only decent terminal emulators available for Windows!

Finally, SSH provides the extremely powerful ability to tunnel other protocols. That is, if you absolutely must use the insecure POP to get your email, you can use SSH to tunnel the data, keeping it from any prying eyes. SSH does this by intercepting data sent to a local port, say POP3's 110, and forwarding it to the specified server's port 110. The data actually travels over SSH's port 22 and is completely secured by the SSH protocol. Read how to set up secure SSH tunnels here.

On the subject of tunneling, IPsec (IP security) provides packet-level encryption of any and all protocols. IPsec, which is inherent to IPv6, is also available for IP version 4. It's an excellent way to secure all network traffic. It doesn't make up for flawed programming--such as the potential root exploits mentioned above--but it does allow for transparent security of normally insecure protocols. The setup and configuration is well beyond the scope of this article, however, you can read tutorials for FreeBSD, NetBSD, OpenBSD, Linux, and Windows 2000.

SSH tunneling and IPsec aside, there are other secure equivalents for protocols. APOP, for example, is the secure equivalent of POP. Sendmail now supports SMTP AUTH and SMTPTTLS, which provide authentication and encryption support. BIND 9 and higher supports signed zone and DNS request support, ensuring that hosts get accurate data from the correct name server. If you can't find a secure replacement, you can almost always use IPsec or an SSH tunnel.


Related Reading

Computer Security BasicsComputer Security Basics
By Deborah Russell & G.T. Gangemi, Sr.
1st Ed. July 1991
0-937175-71-4, Order Number: 714
468 pages, $29.95

If you are running a wireless network, be sure to use 40-bit or 128-bit WEP. It's true that it's rather trivial to crack, however, it will keep the casual observer from watching your data or hooking onto your network.

However, since it is trivial to crack, be sure to use secure protocols to carry sensitive information (such as passwords or financial reports) over a wireless connection. You might also consider placing your wireless network in its own DMZ and require users to VPN into the wired network. To prevent unauthorized users from accessing your network, restrict access to cards with registered MAC addresses. This is also pretty simple to defeat but, again, it guards against casual abuse. Stronger authentication can be provided via the NoCatAuth project.

Staying Informed

If you take the steps outlined above, you're running a pretty secure network. Unfortunately, it's not good enough to rest on your laurels and enjoy endless days of peaceful security. You must remain constantly vigilant to new exploits and potential risks. A paranoid security administrator is a great security administrator.

One quick and easy way to keep tabs on your network is to use the SAINT tool mentioned above. Keep it current and you'll stay informed of many new potential exploits. SAINT is also one way to look for compromised machines on your network by identifying odd open ports.

Read O'Reilly's Security Bibliography, a list of the best security books by O'Reilly and other publishers, which should help you find resources to protect your systems and your privacy in these troubled times.

Traffic analysis is an excellent way to watch for both attacks and compromised machines. By mirroring all of your internal network traffic to a machine running Snort you can log most packets that travel over your network. Tools to analyze the logged traffic and identify attacks are available at the Snort site. You might consider running one box outside of your firewall to see what attacks are being made, and another internally to see what's getting through.

You should also regularly analyze your system log files to check for malicious activity. Tools like Logcheck can help by mailing you about suspicious-looking activity. It's important to log to a different machine and configure the logs so they're append-only. Read Chris Boyd's article showing how to do this with syslog. For logging Windows data, utilities such as EventReporter send Windows event logs to a host running syslog. Keeping track of your system files is another good idea, using a tool such as Tripwire. This tool ensures that if a system file is replaced by a cracker, you're aware of it.

Also, as I mentioned above, it's important to apply appropriate security patches to the operating system, services, and programs on all machines on your network. Even with secure passwords and IPsec, your work is for naught if someone can access root on your mailserver because of a Sendmail exploit.


These steps will not guarantee that your network is safe from being hacked, but by following these recommendations you'll keep out most of the script kiddies and casual hackers. Here are three more things you can do to stay on top of things:

Finally, stay on your toes; it's a jungle out there.

Mike DeGraw-Bertsch is a security and Unix system administration consultant in the Boston, Mass. area. When he's not at a job, writing, hacking with Perl, or playing with his wireless network, he can usually be found playing goal in ice hockey.

Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.