A Sysadmin's Security Basics

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:

Passwords

Email attachments and client settings

Firewalls and demilitarized zones

Securing insecure protocols

Wireless

Staying informed

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

Passwords

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.

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.

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.

Wireless

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.

Conclusion

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:

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.