A Sysadmin's Security Basics
Pages: 1, 2
Securing Insecure Protocols
In the early days of the Internet, when security was not a big concern,
insecure protocols such as
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
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.
Computer Security Basics
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.
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:
- Subscribe to relevant mailing lists at SecurityFocus
- Visit the CERT Coordination Center to read about security and incident response
- Read Security Alerts for weekly updates on vulnerabilities and patches.
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.