The first question you have to ask yourself is: How paranoid are you?
It is possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.
The first step actually already starts before you install the system. You should take a minute to consider your partition layout.
Separate partitions for /var, /tmp, /home and any other user data you may have would be a good idea. Keeping /var and /tmp on separate partitions will make sure your system does not stop responding due to /var or /tmp filling up your root partition. Additionally the partitions should be mounted with the option NOEXEC (this ensures that the execute bit is disabled on any binary files on the partition) and NOSUID (this disables the SUID/SGID file-attribute on the entire partition).
Please note that some programs may stop working when NOEXEC is used. If you should indeed need to run a program from a data partition, a workaround could be to use a script to remount the partition with the option EXEC. Then perform the desired task and then remount the partition with the option NOEXEC again. Please see following example:
#!/bin/bash mount -o remount,exec /tmp /tmp/someprogram mount -o remount,noexec /tmp
Data partitions should always be mounted with option NOEXEC and NOSUID, as there should never be the need for a program to run from such a partition. And especially not with root privileges!
If you don't plan to install any programs in your home folder, you can also set NOEXEC on the /home partition. NOSUID should always be set on /home.
Please note that programs like crossover-office and eagle-cad, when installed directly from the downloaded run file, will install in the home directory. Setting the NOEXEC option on the partition would of course keep those programs from running.
After installation make a normal user for daily use. Don't use the root user for daily use!
Pick a secure password. I trust you know not to use a dictionary word or something like your dogs name.
A password should be at least six characters long. Contain a mix of upper and lower case letters. It should include at least one number and/or one special character.
If you, like me, have a good memory for passwords then you can use a program like pwgen to create a bunch of passwords and print them on the screen. Then just pick one to use.
Alternately you can make a password using the first characters from every word in a sentence. Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password.
This is actually mostly necessary on a multiuser system, but is considered good practice security wise.
Restricting the users who can su to root is done by changing the file /etc/pam.d/su.
Find the line that reads
#auth required pam_wheel.so use_uid
and remove the leading #. Of course you need to make sure that your user is a member of the wheel group before you apply this change, else you will not be able to use SU to gain root privileges!
No root login at the console
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only need to guess a password.
Blocking root login at the console is done by changing the file /etc/securetty and commenting out the tty lines.
All you have to do is change
Repeat for any tty you wish to block.
To check the effect of this change, start by commenting out only one line. Then goto that particular console and try to login as root. You will be greeted by the message “Login incorrect”.
Now that we're sure it works, go back and comment out the rest of the tty lines.
Lockout user after three failed login attempts
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.
To lockout a user for ten minutes after three failed login attempts you have to change the file /etc/pam.d/login. Find the line that reads
#auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
and remove the leading #. Then find the line that reads
auth required pam_tally.so onerr=succeed file=/var/log/faillog
and insert a leading # on the line. If you don't do this, then every failed login attempt will be counted twice. That's all there is to it. If you feel adventures, make three failed login attempts. Then you can see for yourself what happens.
To unlock a user manually use the following command as root
If you want to permanently lockout a user after 3 failed login attempts, then just remove the unlock_time part of the line. Then the user can not login until root unlocks the account.
To ensure that no one just walks up to your computer and presses CTRL-ALT-DEL to restart your machine, you can disable the capture of CTRL-ALT-DEL in the file /etc/inittab.
I could see this being used in a production environment, where the operator needs to use the keyboard but the computer itself is locked away.
Open the file /etc/inittab and find the line
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
comment out the line by inserting a leading #.
This change will not take effect until you restart or issue the command
Of course if someone has physical access to your machine he could just press the power button to shutdown the machine!
Use sudo for system commands
To make a user run some system commands as root it is advisable to use sudo to give that user the needed authority. It wouldn't be good to hand out the root password to just anyone.
Even if you are the only user on the system, using sudo is a good idea to keep from using a root console too much. Sometimes you just forget to logout again!
Setting up sudo is quite easy. Just use the visudo command to bring up the configuration file in the editor.
The file already includes some examples you can use. I will show you one command that I always add to my sudoers file.
I want to be able to mount samba shares from my server on my workstation with a regular user, so I add the following using visudo
This allows all users who are members of the group users to run the commands /sbin/mount.cifs and /sbin/umount.cifs from any machine(ALL).
There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it!
Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!
Some resources that might be of interest to you
Securing and Hardening Red Hat Linux Production Systems
Securing Linux, Part 1: Introduction