I have put some basic information here to help you keep your system safe. As you will soon see, the information below is written in a non-technical way.

Read the Security HOW-TO
What can I say, someone made a good one for Linux! Check it out. Oh ya, finish reading my page first.

Read those F*CKING LOGS!!!!!
Logs are the only way to know what's going on your Linux system. Of course, this assumes that an attacker has not corrupted your logs, but that aside. Full logging of all connections, can reveil so much about an attacker, and their attempts. If you have problems understanding the logs and what they are saying then get help to understand them. There is nothing wrong with someone helping you with something you don't understand. I get information every-now-and-then on something that I have made a mistake on and that I am told to clairify or fix something. To be arrogant is one thing to be stupid is another.

Don't make games SUID ROOT!!!
SUID root games are just a root shell waiting to happen. Games are great, fun and a time killer, but they have tons of buffer overflows bugs and they will follow any symlink to anywhere and not check ownership at the end of the symlink. If you have to have users and games, the do not make the games SUID root and have them executable by any user you do not trust with your system. Make a group and put all of the users you want to access the game in that group, and then make the game SUID root and make the game only executable by that special group. You will also want to do this with the svga libraries and MesaGL (They all tend to have a bad history of security).
The other thing to consider is do you really trust the people running the games? Think about it!

Limit the number of SUID root programs on your system.
SUID root programs are programs when ran, run at the level of root (God in the UNIX world). Sometimes this is needed but many times not. Since SUID root programs can do anything that root can they bear a high level of responsibility in following the golden rules of security programming. Sometimes they do, sometimes they don't and when they don't, users can sometimes get them to do things their not suppose to do. This is where exploits and come in. An exploit is a program or script that will get a SUID root program to do very bad stuff (Give root shells, grab password files, read other people's mail, delete files).

Run programs at Least Privilege Access.
As stated before, many programs don't need to be run as root, but still need some level of higher access than the average user. This is where the Least Privilege Access idea comes into being. For example, the LP (Line Printer) commands need access higher that the average user (To access to the printer), but only small amount of code needs to be ran root. So the smart thing to do is to make a user lp (/bin/true as the shell) and a group called lp and make it so any user can run any of lp commands and make all of the lp commands owned by the lp group and user, execpt that code that needs to be root. Most likely the lp daemon (lpd), which most likely started when the system boots. Then make sure that lp can still do its job (Managing the printers, the queues, and able to still send reports to the person in charge of the printers). So if the lp user becomes compromised the attacker really has not taken a step forward in gaining root on your system. Now most/many programs that are SUID root, ask that you create a user and group for the program. However, many people screw up by putting most if not all of their SUID programs in the SAME user and group. This is bad! Really Bad!. What you need to do is put every program that start as root then forks off as lower privlage user in their own group and have their own user account. You can make the shell /bin/true in the gecos field int the /etc/passwd, and the thome directory where the programs are (In this case you should/would have to put the tools in their own direrectories).

Disable services you don't need or use.
If you don't use rpc.mountd, rpc.nfsd or other like daemons then don't run them. Simply kill -9 them and then go to the /etc/rc.d scripts and comment them out. They take up memory, CPU time, provide a way for attackers to gain information about your system, and even a way for them to get in.

Make sure to have the latest /lib's.
The files in /lib's are shared code, when a program needs a certain piece of code, it simply goes gets that code (Assuming that its not already compiled in). The advantages are quite clear; Programs compile smaller, if a piece of the lib code is busted, you simply upgrade it, since many programs us the same code the programmer can focus on functionality of their program instead of writing code that has already been written. Disadvantages; Busted code in the /lib will effect many programs (See resolv+ bug) and if an attacker gets their hands on the lib's then your really in trouble.
The best thing to do is to keep up on the upgrades for the lib's and make sure to check there size and dates often for changes.

Encrypt that connection.
Packet Sniffing is simply the best way to get passwords. Period. A packet sniffer sitting on a hijacked machine on an unencrypted subnet will yield, possiably, hundreds of paswords. Not only for the local computers, but also for other computer networks! Now, you may say to yourself, "But I have my network behind a Firewall, and thus I am safe". Bullshit!. A recent study showed that half of sniffing attacks occured behind the Firewall (The "Good Side"). Encryption also lets you use unsecure networks (IE: The Internet) to transport critcal or sensitive information. See Keep Safe Programs for the list of Encyrption packages out there.

Keep your Kernel current to the latest and stable.
This rule really only applies to persons who have users on their systems. Early kernels tend have many well known holes (See ldt-exploit.c for an example) in them and beta kernels, sometimes, are very unstable. Also, the 2.0.X kernels tend to be faster that the 1.2.X kernels and more stable that the 1.3.X kernels.

When Configuring your kernel only compile in code you need and use.
Four main reason come into mind; the Kernel will be faster (Less code to run), you will have more memory (Kernel parts are NEVER swapped to the virtual memory), more stable (Ever probed for a non-existent card?), unnecessary parts can be used by an attacker gain access to the machine or other machines.

Let outsiders know as little as possible about your system.
A simple finger to a victims system can reveal much about a system; How many users, when the admin is in, when do they work, who THEY are, who uses the system and personal information that might help an attacker guess a users password. You can use a powerful finger daemon and/or tcpd to limit who can connect to your system and how much they will know about your system.

Enforce good passwords.
Simply put, bad passwords is the key to getting into your system. If you install Shadow in a Box, then you can use the proactive password feature to filter out bad passwords before they get used. Running Crack to check for bad passwords is also a good idea.
Even if you only a handful of people on your system, and they are friends, a bad password will still let an uninvited guest get in and doing a root 'rm -rf /'.

If you can, limit who can connect to your Linux box.
For example: your at college and your lucky enough to get a dorm that has a 10BaseT connection in the room. The plot thickens, you leave your neato Linux box on all the time, so your roommates and your friends can login. However, they are only connecting from the college's subnet, so why not block all telnet connects from outside the subnet? Tcpd and a little common sense can keep you safe.
Note: A Linux system ran by a beginner hooked up to a 10BaseT would make a juicy target for an outsider looking for an '+o0 kewl /<-rad 31i+3 WaReZ SiTeZ'