The first step is to go into /etc/inetd.conf and lock down the services run from there. RedHat by default enables a lot of servers in here. Most of them are not needed by most people, and some of them can be major headaches to secure. Lines in inetd.conf take this form:
<service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
The service_name field is the service name from the /etc/services file, and basically gives the general name of the service and identifies the port on which that service will run. proto indicates whether this service uses TCP or UDP. The server_path and args fields indicate the program that will be run when someone connects to the service's port and the arguments this program will get. Under normal circumstances the server_path field should always be /usr/sbin/tcpd. This is a small program that checks /etc/hosts.allow, allows or disallows the connection based on the rules there and, if allowed, runs the program specified in it's arguments ( the args field from inetd.conf ). By using tcpd, individual servers don't need to worry about knowing how to check the hosts.allow rules. Unless you have a good reason to do otherwise, it is advisable to always use this wrapper program so unvalidated connections don't slip through.
Locate the following services and comment them out if they are not
commented out already:
These services are dangerous to have running unless you know exactly what
you're doing, and they almost certainly won't be needed by a casual user.
The following services should probably be commented out. You probably won't need
them:
The following services you may want to leave in or comment out, depending on personal preference:
One service you should have enabled is the auth service. This is the identd server and is used to check identity. It's also the one exception to the tcpd rule: you never wrap this in tcpd. That's because tcpd uses identd to check some things, and if you wrap identd in tcpd you risk setting up a nasty infinite loop/recursion.
In case you hadn't figured it out from my comments above, the general rule for security is that if you don't need something, you disable it. Makes sense, if it's disabled it can't become a security problem. OTOH, you can't use disabled services yourself. Personally I prefer an adaptive approach. Start by disabling anything there's a question about. Then, if you find yourself wishing it was active, enable it. Every so often, go back and ask yourself when was the last time you used a service. If you can't remember, maybe it's time to disable it.
If you made any changes to inetd.conf, save it and send the inetd process the SIGHUP signal. You can do this two ways. One is to do a "ps ax", find the PID of the process running inetd and then do a "kill -HUP pid". The other is via "killall -HUP inetd".
Now that we've taken care of inetd, we can turn our attention to the servers that run on their own. Your primary tool to deal with these will be the run-level editor that RedHat provides. You'll need to have X-windows running to use this. From an xterm, do an "su root" and give the root password. Then run "/usr/bin/control-panel". The first icon at the top of it should be what looks like two traffic lights. That's the run-level editor. Click on it.
The left-hand side lists the available servers on your system. There is a list of servers and descriptions I've made up. You may not have everything here, but it should give you a good idea of what you've got. The right-hand side is a set of panels showing services started and stopped in each run level.
To disable a server, you highlight it's entry ( if any ) under the start section for the run level in question and hit the Remove button. Then you select it's name from the Available panel and hit the Add button, mark the Stop checkbox and the run level you want to stop it in on the next dialog box and hit Done, then just hit Add on the final dialog and let RedHat supply a default order number for it. Any servers you want disabled should be stopped in all 4 of the available run levels.
Enabling a server is the opposite procedure. You highlight and remove it's entry under the stop section of the run level, then add it but check the Start checkbox.
The run levels actually do have canonical uses. Runlevel 3 is the basic initial run level for the system. It starts all the servers that your system normally runs, and leaves you with a text console login. Runlevel 5 is the same as runlevel 3, but it also starts up XDM to give you a graphical login screen. Runlevel 2 is canonically for use when you don't want to depend on the network. Typically the network itself is started, but no remote filesystems are started and neither are many of the network servers. Runlevel 4 has no pre-assigned use. Normally you'll be mostly concerned with run levels 3 and 5.
Normally you should have the following servers started in runlevels 3 and 5:
You normally want these stopped,unless you have a reason for running that particular
server:
Other servers such as sshd, squid and postgresql may be started depending on whether you want their services. Remember that the general rule is that if a server is running you need to worry about it's proper configuration and security implications. If the server is not running, none of that matters.
The /etc/hosts.allow and /etc/hosts.deny files contain the rules used to decide whether a particular machine and user can access a service on your machine. In the old days you listed allowed and denied machines in the appropriate file, but with the newer extended syntax in use today you use only hosts.allow for everything and leave hosts.deny empty. Be sure it's really empty, though. You can find details of the syntax via "man 5 hosts_access" and "man 5 hosts_options".
I use this file as the basis for my configuration. Simply locate myusername in the file, replace it with your XMission username, and place into /etc/hosts.allow. This file is fairly staightforward. It allows localhost ( 127.0.0.1 ) to access everything, allows your account on XMission to access everything, and locks everyone else out. It also logs all connections, successful or denied, to your security log file so that you have a record of what's happening.
Make sure that the last entry in the file is the "ALL : ALL@ALL" one and that it ends in DENY. This is what denies access to anything that you haven't explicitly dealt with earlier. You can put this in hosts.deny, but I prefer having all the rules in a single file.
It mentions sendmail seperately. That's because normally not even your account on XMission would directly connect to sendmail on your machine. Also, if you have an XMission account that gives you the option of having your mail delivered by SMTP, you may need to expand access to allow XMission's mail servers to connect to your sendmail but you don't want to allow access to anything else. Simply add "ALL@machine" before the backslash on the first line of the first sendmail entry ( the one that ends in ALLOW ). This won't have any effect unless you've also installed the modified sendmail that honors tcp_wrappers. I strongly recommend this. If you have a business setup where you run your own mail server and people send mail directly to it rather than through XMission's mail servers you may need to open it up to all outside access. RedHat by default disallows relaying, so there's usually not a problem with spammers making use of it.
If you have a static IP address, you can also add "ALL@myusername.users.xmission.com" to the ALLOW entries. That will cover you when you use your machine's permanent XMission-assigned name instead of localhost. If you have a small home network and are using a private IP network as I described in the gateway configuration document, you can also add "ALL@192.168.1." ( substituting whatever private network number you selected for the IP address, of course ) to the various ALLOW lines to allow all machines on your private network to access your Linux box. The partial IP address format ( leading portion of the IP address common to all machines and a trailing period ) is fairly common. The CIDR form ( for example, for a class C network it would look like "192.168.1.0/24" ) is also allowed.
Let's face it, nobody likes secure passwords. By definition a secure password is one that's close to a random string, and those are hard to remember. However, bear in mind that crackers have tools that can literally try every variation on every word in the dictionary and see if one encrypts to the same thing as your password. Varying capitalization, adding digits and all the other easy tricks don't work well, since their tools already account for them. As an example, I turned a program called Crack ( a common cracker's tool ) loose on a password file containing a dozen dictionary-word-based passwords. Even though all but 2 of them included such obfuscations as non-standard capitalization, embedded digits and using more than one word, it took a Pentium 133 only a couple of days to nail down every single one. Your only real defense is to pick a password that's out of their search space, ie. one that's not based on a dictionary word, name, acronym or anything else memorable. I tend to pick them based on typing patterns, sequences of keys that make a physical pattern to the movements of your hands as you type them. These are still theoretically guessable, but they're a lot harder to pin down than dictionary-word-based passwords. RedHat will give you some help here. They included the pam_cracklib module in their default configuration for setting passwords. This module checks the password you set against a standard set of Crack dictionaries and rules and will not let you set a password that Crack is likely to be able to guess.
There's a few things you can do to hinder the crackers, though. The first is to make sure that you don't have any unpassworded accounts laying around. The second field of /etc/passwd ( or /etc/shadow if you're using shadow passwords, more on that in a moment ) is the encrypted password. On a typical system only root and your regular username should have anything legal here, the rest should have a star ('*') in them indicating that they do not accept interactive logins. If you are using shadow passwords, make sure that the /etc/passwd file contains an 'x' in the second field for all entries.
A note about the following two sections: RedHat 6.2 from a clean install defaults to shadow passwords and allows you to select MD5 passwords from the very beginning. I would do this if you are doing an initial install. If you are upgrading, you may need to follow these procedures to enable shadow and MD5 passwords.
The second thing you can do is to enable shadow passwords. The regular /etc/passwd file needs to be readable by the world for various reasons, which means that anyone who can get at that file can get the encrypted version of every password around. Given that, they can eventually crack them by the simple expedient of encrypting every possible password and seeing if the encrypted form matches what's in the file. The shadow password package removes the passwords only from the regular file and stores them in /etc/shadow, which is readable only by it's owner ( which happens to be root ). By keeping even the encrypted form of the passwords inaccessible by anyone but root, you make it extremely hard for a cracker to try guessing passwords. There are two steps to this process: converting your existing files over, and modifying the PAM configuration to use shadow passwords.
Be certain you have a root login active the whole time you're doing this. As long as you have a root login you can recover from the worst that can happen, but without a root login you can end up in a situation where you can't get access as root to repair things if something goes wrong before you're entirely finished.
Make certain that the permissions on /etc/shadow and /etc/gshadow are set to not allow any group or other access. "chmod 400 /etc/shadow /etc/gshadow" will set the permissions properly.
The third thing you can do is switch to using MD5 passwords. By default, RedHat uses the traditional DES encryption for passwords. 56-bit DES encryption is fairly easy to crack. It also limits passwords to 8 characters, additional characters are silently ignored. MD5 is a much more complex algorithm that takes longer to crack, and it allows passwords of any length. This conversion is also a 2-step process, and you should run it as root and insure you have a root login available until after you've verified that the conversion was successful:
MD5 encryption is, as I said, more complex than DES encryption. Where a computer could easily try a hundred or more passwords a second using DES encryption, it can only make 5-6 attempts a second using MD5 encryption. This obviously slows down the crackers drastically. Removing the 8 character limit also expands the set of possible passwords, making their search harder. Finally, although every cracker knows DES encryption and has the routines available, fewer will know about MD5 or have the proper routines available to plug into their software. Security through obscurity may not stop a cracker, but anything that makes their job harder can't be all bad.
Note that, if you modify one of the files in /etc/pam.d, you need to remember that the next time you upgrade the piece of software that owns the file. The upgrade will save off your modified file and put a standard one in it's place, and that standard file may not contain the shadow and/or md5 keywords. Similarly, any new pieces of software that add a /etc/pam.d configuration file probably won't have those keywords in place. If you have done shadow or MD5 conversion, software won't work properly until those keywords are in place in it's PAM configuration file in /etc/pam.d.
Even if you aren't doing a gateway for other machines, some of the filter rules used for the gateway I described elsewhere can come in handy. All one would need to do is comment out the lines that refer to the eth0 or other LAN network interface, and the forwarding and masquerading rules that refer to the lannet variable.
tknarr@silverglass.org