7. General Tips

This section will quickly address some general concepts for maintaining a more secure and reliable system or network. Let's emphasize "maintaining" here since computer systems change daily, as does the environment around them. As mentioned before, there isn't any one thing that makes a system secure. There are too many variables. Security is an approach and an attitude more than it is a reliance on any particular product, application or specific policy.

• Do not allow remote root logins. This may be controlled by a configuration file such as /etc/securetty. Remove any lines that begin "pts". This is one big security hole.

• In fact, don't log in as root at all. Period. Log in on your user account and su to root when needed. Whether the login is remote or local. Or use sudo, which can run individual commands with root privileges. (Red hat includes a sudo package. ) This takes some getting used to, but it is the "right" way to do things. And the safest. And will become more a more natural way of doing this as time goes on.

  I know someone is saying right now "but that is so much trouble, I am root, and it is my system". True, but root is a specialized account that was not ever meant to be used as a regular user account. Root has access to everything, even hardware devices. The system "trusts" root. It believes that you know what you are doing. If you make a mistook, it assumes that you meant that, and will do it's best to do what you told it to do...even if that destroys the system!

  As an example, let's say you start X as root, open Netscape, and visit a web site. The web page has badly behaved java script. And conceivably now that badly written java script might have access to much more of your system than if you had done it the "right" way.

• Take passwords seriously. Don't give them out to anyone. Don't use the same one for everything. Don't use root's password for anything else -- except root's password! Never sign up or register on line, using any of your system passwords. Passwords should be a combination of mixed case letters, numbers and/or punctuation and a reasonable length (eight characters or longer). Don't use so-called "dictionary" words that are easy to guess like "cat" or "dog". Don't incorporate personal information like names or dates or hostnames. Don't write down system passwords -- memorize them.

  Use the more secure "shadow" passwords. This has been the default on Red Hat for some time now. If the file /etc/shadow exists, then it is enabled already. The commands pwconv and grpconv, can be used to convert password and group files to shadow format if available.

• Avoid using programs that require clear text logins over untrusted networks like the Internet. Telnet is a prime example. ssh is much better. If there is any support for SSL (Secure Socket Layers), use it. For instance, does your ISP offer POP or IMAP mail via SSL? Recent Red Hat releases do include openssl, and many Linux applications can use SSL where support is available.

• Set resource limits. There are various ways to do this. The need for this probably increases with the number of users accessing a given system. Not only does setting limits on such things as disk space prevent intentional mischief, it can also help with unintentionally misbehaved applications or processes. quota (man quota) can be used to set disk space limits. Bash includes the ulimit command (man ulimit or man bash), that can limit various functions on a per user basis.

  Also, not discussed here at any length, but PAM (Pluggable Authentication Modules) has a very sophisticated approach to controlling various system functions and resources. See man pam to get started. PAM is configured via either /etc/pam.conf or /etc/pam.d/*. Also files in /etc/security/*, including /etc/security/limits.conf, where again various sane limits can be imposed. An in depth look at PAM is beyond the scope of this document. The User-Authentication HOWTO (http://tldp.org/HOWTO/User-Authentication-HOWTO/index.html) has more on this.

• Make sure someone with a clue is getting root's mail. This can be done with an "alias". Typically, the mail server will have a file such as /etc/aliases where this can defined. This can conceivably be an account on another machine if need be:

  # Person who should get root's mail. This alias # must exist. # CHANGE THIS LINE to an account of a HUMAN root: hal@bigcat

  Remember to run newaliases (or equivalent) afterward.

• Be careful where you get software. Use trusted sources. How well do you trust complete strangers? Check Red Hat's ftp site (or mirrors) first if looking for a specific package. It will probably be best suited for your system any way. Or, the original package's project site is good as well. Installing from raw source (either tarball or src.rpm) at least gives you the ability to examine the code. Even if you don't understand it ;-) While this does not seem to be a wide spread problem with Linux software sites, it is very trivial for someone to add a very few lines of code, turning that harmless looking binary into a "Trojan horse" that opens a backdoor to your system. Then the jig is up.

• So someone has scanned you, probed you, or otherwise seems to want into your system? Don't retaliate. There is a good chance that the source IP address is a compromised system, and the owner is a victim already. Also, you may be violating someone's Terms of Service, and have trouble with your own ISP. The best you can do is to send your logs to the abuse department of the source IP's ISP, or owner. This is often something like "[email protected]". Just don't expect to hear much back. Generally speaking, such activity is not legally criminal, unless an actual break-in has taken place. Furthermore, even if criminal, it will never be prosecuted unless significant damage (read: big dollars) can be shown.

• Red Hat users can install the "Bastille Hardening System", http://www.bastille-linux.org/. This is a multi-purpose system for "hardening" Red Hat and Mandrake system security. It has a GUI interface which can be used to construct firewall scripts from scratch and configure PAM among many other things. Debian support is new.

• So you have a full-time Internet connection via cable-modem or DSL. But do you always use it, or always need it? There's an old saying that "the only truly secure system, is a disconnected system". Well, that's certainly one option. So take that interface down, or stop the controlling daemon (dhcpcd, pppoed, etc). Or possibly even set up cron jobs to bring your connection up and down according to your normal schedule and usage.

• What about cable and DSL routers that are often promoted as "firewalls"? The lower priced units are mostly equating NAT (Network Address Translation), together with the ability to open holes for ports through it, as a firewall. While NAT itself does provide a fair degree of security for the systems behind the NAT gateway, this does not constitute anything but a very rudimentary firewall. And if holes are opened, there is still exposure. Also, you are relying on the router's firmware and implementation not to be flawed. It is wise to have some kind of additional protection behind such routers.

• What about wireless network cards and hubs? Insecure, despite what the manufacturers may claim. Treat these connections just as you would an Internet connection. Use secure protocols like ssh only! Even if it is just one LAN box to another.

• If you find you need to run a particular service, and it is for just you, or maybe a relatively small number of people, use a non-standard port. Most server daemons support this. For instance, sshd runs on port 22 by default. All worms and script kiddies will expect it there, and look for it there. So, run it on another port! See the sshd man page.

• What about firewalls that block Internet connections according to the application (like ZoneAlarm from Windowsdom)? These were designed with this feature primarily because of the plethora of virii and trojans that are so common with MS operating systems. This is really not a problem on Linux. So, really no such application exists on Linux at this time. And there does not seem to be enough demand for it that someone has taken the time to implement it. A better firewall can be had on Linux, by following the other suggestions in this document.

• Lastly, know your system! Let's face it, if you are new to Linux, you can't already know something you have never used. Understood. But in the process of learning, learn how to do things the right way, not the easiest way. There is several decades of history behind "the right way" of doing things. This has stood the test of time. What may seem unnecessary or burdensome now, will make sense in due time.

  Be familiar with whatever services you are running, and the implications these services might have to the overall health of your system if something does go wrong. Read what you can, and ask questions. Don't run something as a service "just because I can", or because the installer put it there. You can't start out being an experienced System Administrator clearly. But you can work to learn enough about your own system, that you are in control. This is one thing that separates *nix from MS systems: we can never be in complete control with MS, but we can with *nix. Conversely, if something bad happens, we often have no one else to blame.