Linux Desktop Security Guide

Docs that have proven to be a staple in understanding computer/network security. This is not an inclusive forum and nothing ipublished will tell you how to 0wn someone, these docs will help you understand how you got 0wnd.
User avatar
Corporate Drunkard
Posts: 1911
Joined: Tue Jul 29, 2003 11:47 pm
Location: Guam

Linux Desktop Security Guide

Post by Life » Tue Jun 29, 2004 5:41 pm

This document was written by Life and is property of and its administration, you are free to distribute this how you please as long as the contents stay intact and proper credit is given. (A link would be nice :) )


The following is designed to give you a good start to securing your Linux system. There seems to be a large belief among some users on the internet that installing a Linux distribution on your box will automatically make your system secure, of course this is not true. While (in my opinion) Linux out of the box is alot more secure than your standard Windows Operating System, any system that is not properly administered will have problems.

There is also the issue of security vs usability, the more you configure your box towards security, the more problems you may encounter whilst trying to use certain services. Some network administrators may want an almost total lockdown on their system, whereas the average home user just wants some peace of mind. This document is aimed more towards helping the home user on a standalone desktop setup, as network admins worth their salt should already know how to configure Linux security.

General Security Tips

Often overlooked as a serious security hardening method is your user and root passwords. Its no good having all the extra security if someone manages to find a vulnerability and your root password is something like "password" or "admin", because the likelyhood is that they will guess it straight away. The same is true for mail passwords, forum passwords, and well, any password you are going to use on a system connected to the internet. I'm not going to go into this too deeply, but make sure your password is at least 8 characters, with a combination of numbers and upper/lowercase characters, its also a good idea to change them regularly, even if you just change a few characters around. Also, never write your password down, especially dont save it anywhere on your box / website - it happens all too often when someone stumbles across an imaginatively named: passwords.txt.

Another general rule for Linux/Unix systems is to stay logged in as a normal user, and do not use root unless you have to (editing important config files, installing a compiled package etc). Make sure you don't start up applications (an FTP server for example) that are connected to the internet logged in as root, as if someone exploits a vulnerability on the service, you run the risk of getting rooted pretty fast.

Also, it would be a good idea to deny remote logins by editing the /etc/securetty file. Comment out everything under the remote shell section, usually beginning with pts or ttyp. If you wish to allow users onto your machine later you can setup something like ssh which is alot more secure.

Keeping your system and the programs you run (especially those with contact to the internet) updated is also very important, to be safe use only stable versions of programs where possible. If you hear of a vulnerability in one of your programs and there is no update or patch available, simply rollback to a version that the vulnerability is not compatible with until a patch becomes available.

Disabling Services

This is one of the most important steps in the security process, if you have a shed load of services that you don't need running on your box 24/7, you are opening yourself up to even the lowest levels of the script kiddie world.

Most distributions should give you the option to disable many of the services the average user will not require at installation. Some users seem to see "Services: FTP, HTTP etc" and think that they need to enable these to be able to browse websites and FTP servers, this is not the case. The services described here are only for systems that will host an FTP / HTTP server locally, it doesn't mean you cannot access remote ones. Even if you think you may require these in the future, it is best to disable them until they are needed.

If you have already completed the installation process and are worried because you didn't disable the services then, its not a problem, the beauty of Linux is that everything is configurable, and there is usually more than one way to achieve what you want.

First off, to disable the unwanted services that are running on your system, you will need to identify them. One way of doing this is by using netstat.

For this example, we will use the command "netstat -pat |grep LISTEN", I will break this down quickly for you:

The -p argument tells netstat to list the programs / process ID of the port - this makes it easier to see which programs are causing a port to listen

The -a argument tells netstat to list all active ports

The -t argument tells netstat to show ports dealing with the TCP protocol.

| is known as a "pipe", and "grep LISTEN" tells the terminal to only print lines returned with the word "LISTEN" in them, this is useful for this activity because it only displays the listening ports we are trying to disable.

Ok, now you should have something like this in front of you:

Code: Select all

someone@somewhere $: netstat -pat |grep LISTEN

tcp        0	0 *:4000	  *:*                     LISTEN      1294/mlnet
tcp        0	0 *:ssh		*:*                     LISTEN      989/sshd
tcp        0	0 *:telnet	*:*                     LISTEN      972/inetd
tcp        0	0 *:ftp		*:*                     LISTEN      972/inetd
tcp        0	0 *:x11		*:*                     LISTEN      1383/X

Now, I cant tell you which servers you will and wont need, as needs vary from user to user, and please note that your netstat output may look very different from this one depending on your system configuration.

It may also help you to read through the man pages for netstat (type man netstat in a terminal window), or at least google for some information.

First off, you can see the top line reads "*:4000" and "LISTEN", this means that my local system is listening on port 4000. At the end of the line I am given a process ID (1294) and the name of the process listening on that port (mlnet). Running the command "locate mlnet" gives me the following output:

Code: Select all

From this I can see that mlnet is the MLDonkey P2P client running on my system, I don't want to end this program so we shall skip ahead to the next one....

Ok, next line reads "*:ssh", this is the Secure SHell service, used for secure (well, more so than rshell, telnet etc) remote logins on your system, it can be a very useful service, but its also a security risk, so if you don't need this, you should disable it.

To do this, simply note down the process ID shown at the end of the row, in this case, 989, and type from a terminal: (you may need to use su to get root privileges depending on the file permissions)

Code: Select all

kill 989
This should send the kill signal to the sshd process and will stop it listening on the port. You can repeat this step for any processes that you don't require until hopefully there are only a minimal set of services listening on your ports. Note, you could also use killall -9 processname, ie; killall -9 sshd.

However, although this method will terminate unwanted processes and stop them listening, it probably wont stop them from starting up again next time you reboot your system. One way to stop certain services running at boot, is to remove the package for it totally, now as with most things, this varies from distro to distro, RedHat, Mandrake, SuSE etc should all have GUI tools available for removing their native packages, Debian has the apt-get and dpkg tools and Slackware has pkgtool. Check out the man pages relevant to your distribution, or have a search around on google if you are unsure.

There are also Init services that are started up at boot, on my Slackware system, these are located at /etc/rc.d/rc.inet2, but on most distributions the path is slightly different, try looking around for /etc/init.d or similar.

Another file you might want to take a look at is /etc/inet.conf, this is the configuration file for the inetd daemon (most boxes may now be using the xinetd daemon instead, the same principles apply), which controls some other daemons (as you can see above in the netstat output). If you make changes to this file, you could either reboot your system, or better yet, use the following command:

Code: Select all

kill -HUP pid
Where "pid" is the ID of the "inetd" or "xinetd" process on your box, in the netstat example shown above, this would be 972. It may also be a good idea to change the file permissions of these files so that only root can change the contents, you can do this by issuing the following command:

Code: Select all

chmod 750 /etc/whateverfile
(see: man chmod for more details on the chmod command)

NOTE: Before editing these files, make sure you have a backup, if you want to create one quickly, simply do something like:

Code: Select all

cp /etc/rc.d/rc.inet2  /home/rc.inet2backup
Open these files with a text editor (personally I use pico / nano / VI), and simply comment out the sections referring to services that you don't want to start with the # symbol at the start of each line. For example, to stop the sshd service from starting at boot I would edit the following lines:

Code: Select all


	# Start the OpenSSH SSH daemon:
	if [ -x /etc/rc.d/rc.sshd ]; then
  	echo "Starting OpenSSH SSH daemon:  /usr/sbin/sshd"
  	/etc/rc.d/rc.sshd start
To this instead:

Code: Select all

	# Start the OpenSSH SSH daemon:
	#if [ -x /etc/rc.d/rc.sshd ]; then
	#  echo "Starting OpenSSH SSH daemon:  /usr/sbin/sshd"
	#  /etc/rc.d/rc.sshd start
Note I have added a # at the start of each line in this section, this will tell the system to interpret the lines as comments rather than code, thus stopping the service from being started. If you experience problems or need the use of the service, you can always go back and uncomment the relevant sections, or restore one of your backups.

Securing Services

If there are certain services that you will need to be running on your box, like apache webserver for instance, you should do as much as you can to secure it. One small step you could do is to change the banner information given out by this service.

To do this, you would need to locate the following file:

Code: Select all


Now, you can either use the grep command, or search manually, but somewhere in that file should be something like the following:

Code: Select all

#define SERVER_BASEPRODUCT   "apache"
#define SERVER_BASEREVISION  "x.x.x"  

Simply change these lines to whatever you want the banner to say, for instance:

Code: Select all

#define SERVER_BASEPRODUCT    "h4x0r_jim_duggans_httpserver"
#define SERVER_BASEREVISION   "99.99.99b" 
After you have made your changes, all you have to do is compile the program as normal and voila. Now when someone telnets to your webservers port to grab the banner info, they will recieve "h4x0r_jim_duggans_httpserver/99.99.99b". Whilst this isnt really securing your webserver, it will certainly stop alot of skiddies trying to test out their new Apache sploit on your box.

With pretty much any open source project, you can change these banners before compiling the programs, obviously they are not always in the same place, but if you look around enough, using your friends google and grep, you should be able to find them.

Another thing you may have noticed in my netstat output above, is that the X11 server is listening on a port. Now instead of shutting this one down (which will kill your graphical environment - im assuming you don't want to do that and you are running a graphical environment), you can just edit a config file to stop it listening by default.

On most systems this file is in:


cd to that directory, and type; vi startx

Scroll down the file until you see the following line:

Code: Select all

Now all you have to do is change this to

Code: Select all

serverargs="-nolisten tcp"
Then save the file (in VI - press ESC, then type; :w!)

This should stop the X server from listening on a tcp port next time it is started, reboot X with ctrl+alt+backspace and check your netstat to see if this has worked properly.

There are also other methods you can deploy, one quite effect one is to run any services like FTP/HTTP servers in a chroot jail. Basically this will run your desired service in a different part of your hard drive instead of in the / (root) dir. This can be a bit of a hassle to setup, as you may have to copy across many libraries and files needed by the service to operate correctly, and also setup a new user and group account. The advantage is that any would be attacker that exploits a vulnerability on the chroot jailed program may think s/he has gained root access on your box, when in fact all they have is an emulated root environment, and therefore can do hardly any damage to the rest of your box.

For more information on setting up chroot jails, search around on google, or sites like and see the man / info pages for the chroot command, as there is quite a bit of information to cover and you will have to do some work with adding user groups and copying directory structures over.


A firewall is an important part of any security setup, ideally a hardware firewall, either a standalone hardware firewall, or a system set up with a minimal linux/unix distribution and a good set of rules for filtering packets.

However, most home users do not have the hardware available to set up a hard firewall, so instead you can opt for a software firewall program.

There are a few good ones available for linux, a good starter would be something like Firestarter, its a basic GUI program that allows you to setup a decent software firewall very quickly. This program is available at and is very simple to setup, download the relevant package and start it up, it will run you through a wizard to customize your rules.

A popular software firewall is Shorewall, this program comes precompiled with some distros, such as Mandrake, and may even come with a GUI interface. If you don't fancy the idea of editing configuration files with the command line interface, something like Webmin from is a great program for configuring the shorewall program with a GUI. In fact, I would recommend anyone using Linux or administering servers / networks check out Webmin, its like the swiss army knife of computer software. Just download and compile it, grab the shorewall module for webmin from their site and configure it all with the web browser interface.

Shorewall (at least the latest versions and with the 2.4 and newer kernels) works with IPTABLES to configure NetFilter rulesets to create a firewall program on your box. I suggest you read up about IPTABLES and NetFilter if you don't already know about them, as there is alot of information I don't have the motivation to cover here ;)

Shorewall's homepage is at

They have a great set of documentation there if you require some more complex rulesets, but for the purpose of this document, I will run through the basics.

Shorewall works by adding rulesets, policies and zones...

ZONES: (default: /etc/shorewall/zones)

Zones define the the source and destination areas for incoming and outgoing traffic so you can setup rulesets and policies around them. For instance, you can setup the "net" zone to refer to all traffic on the internet, the "fw" zone to refer to all traffic on your local machine where shorewall resides, and maybe a "local" zone to refer to all traffic on your local network LAN (if applicable).

RULESETS: (default: /etc/shorewall/rules)

Rulesets define how shorewall handles different types of traffic, for instance, a ruleset like:

Code: Select all


ACCEPT		net			fw		  ftp		  TCP
Will accept all TCP traffic coming from the net zone (internet) to your fw zone (shorewall on the local machine) that is trying to connect to your FTP port, so a connection could be made to an FTP server you are hosting on your system.

POLICIES: (default: /etc/shorewall/policy)

Policies are used for a default ruleset, when no other rule in /etc/shorewall/rules applies. For instance, when a connection attempts to establish itself on your system from the net zone, shorewall will first check the rulesets defined in /etc/shorewall/rules, if it does not find a matching ruleset there, it will look in the policy file to see what to do.

A good, simple default policy to have would be something like this:

Code: Select all


net		fw		  DROP
This would mean that unless you had specifically allowed a certain type of traffic from the internet access on a port in the rules file (such as the example rule above allows traffic to the FTP server), the traffic will be dropped, and no connection will be made. If you want to setup a service later on your system, for instance, ssh, you can leave the default policy as it is and just add a rule in the /etc/shorewall/rules file to allow it.

With this basic setup, you will also want to add:

Code: Select all


fw		 net		 ACCEPT
So any outgoing connections you wish to make are accepted, therefore you can browse the internet, connect to servers etc with no problems from the firewall.

Another shorewall file you may want to look at is shorewall.conf, usually found in /etc/shorewall. This is a general configuration file that lets you specify things like logging options which may be useful for you.

Once you have setup your firewall and disabled all the services you don't need, it would be a good idea to download nmap from and run a scan against yourself ( to see what ports are still open. It's also a good idea to get a friend to check this remotely by using nmap against your IP as a local scan will probably pick up some open ports that are not actually open outside of your machine as the firewall drops the traffic from remote hosts.

Ok, by now you should have a basic level of security setup on your linux box, of course there are alot more things you can implement, you could look at getting an Intrusion Detection System, you could go through the system chmodding all the important files so users cannot r/w/exec them, you could write your own scripts to output firewall logs and kernel messages, alter more application configurations, setup TCP wrappers etc etc. Linux security is a massive subject, and due to its open nature, you can change any configurations to suit your needs, so if you require anymore information, search around on google, read through linux user forums, RFC's, keep an eye on security sites and bugtraq's, and make sure your system stays updated. Thats all for now.
It was once suggested that a million monkeys working at a million typewriters would produce the works of Shakespeare. However, a million monkeys working at a million keyboards has only produced 2girls1cup, goatse and MySpace.

User avatar
time traveller
Posts: 2624
Joined: Thu Aug 28, 2003 10:46 pm
Location: /pr0n/fat

Post by NoUse » Tue Jun 29, 2004 5:52 pm

Read this one before and is very nice. :)
And I will strike down upon thee with great vengeance and furious anger
those who would attempt to poison and destroy my brothers.
And you will know my name is the Lord
when I lay my vengeance upon thee.

User avatar
Corporate Drunkard
Posts: 1911
Joined: Tue Jul 29, 2003 11:47 pm
Location: Guam

Post by Life » Tue Jun 29, 2004 6:05 pm

Thanks man :)
It was once suggested that a million monkeys working at a million typewriters would produce the works of Shakespeare. However, a million monkeys working at a million keyboards has only produced 2girls1cup, goatse and MySpace.

User avatar
Your Senior
Posts: 933
Joined: Wed Jun 23, 2004 9:19 am

Post by BattousaiX » Tue Jun 29, 2004 8:22 pm

Great post. Hope you let your keyboard cool down for a while after all that....
Living tomorrow as another day of the past