With the increasing usage of the Internet and wireless networks security is getting more important every day. It is impossible to cover this subject in a single chapter of an introduction to GNU/Linux. This chapter covers some basic security techniques that provide a good start for desktop and server security.
Before we go on to specific subjects, it is a good idea to make some remarks about passwords. Computer authorization largely relies on passwords. Be sure to use good passwords in all situations. Avoid using words, names, birth dates and short passwords. These passwords can easily be cracked with dictionary attacks or brute force attacks against hosts or password hashes. Use long passwords, ideally eight characters or longer, consisting of random letters (including capitals) and numbers.
GNU/Linux supports two major of securing e-mails, but before we will look into these specifically we are going to look what e-mail security provides. There are two ways in which you can secure e-mails: signing e-mail and encrypting e-mail. Signing e-mail means that a special digital signature is added to the e-mail by the mail user agent. The recipient can use the signature to check whether an e-mail is really from the sender it claims to be from or not, and that the message is not in any way changed during the transmission. E-Mail encryption codes the e-mail in a way that only the intended recipient can decode it.
This system relies on two keys: the private and the public key. Public keys are used to encrypt messages, and messages can only be decrypted with the private key. This means that one can sent his public key out to people. People can use this key to send encrypted e-mails, that only the person with the private key can decode. Of course, this means that the security of this system depends on how well the private is kept secret.
One might wonder why he or she should use one of these techniques. While most people do not feel the need to encrypt most of their e-mails, it generally is a good idea to sign your e-mails. There are, for example, a lot of viruses these days that use other people's e-mail addresses in the From: field of viruses. If the people who you are communicating with know that you sign your e-mails, they will not open fake e-mail from viruses. Besides that it looks much more professional if people can check your identity, especially in business transactions. For example, who would you rather trust, vampire_boy93853@hotmail.com, or someone using a professional e-mail address with digitally signed e-mails?
At the moment there two major standards that are supported by GNU/Linux, the OpenPGP standard, by the GnuPG tool, and S/MIME. Both are about equally good concerning the strength of the used encryption algorithms. The big difference is that S/MIME relies on a certificate authority (CA), GnuPG does not. A certificate authority is an organization that is authorized to hand out keys. This means that the certificate authority validates that the e-mail address and/or name in the certificate is authentic. This means that either:
The certificate (aka private and public key) belongs to the owner of the e-mail address. E-Mail verification is used by the certificate authority to check this.
The certificate belongs to the owner of the e-mail address, and to the name in the certificate. This involves an extra step than e-mail verification. To have a certificate with a name, your identity has to be checked by the certificate authority.
As you can see this system is quite bullet-proof, and you can reasonably expect that a certificate is authentically representing the e-mail address and/or person. GnuPG does not use a certificate authority. This means that anybody can make a key with your name and e-mail address. Trust is established by signing keys. For example, person A verifies that person B's key really belongs to person B, by meeting him in real life, and he signs his key. The authenticity of a key is more certain if it is signed by people who you trust. As you can guess this system is not completely bullet proof, and it can take some time to get your key trusted by other people. Besides, if you use another e-mail address, ant want to use a new key you will have to start all over again. The advantage of this approach is that your private key is not known to a certificate authority.
GnuPG used to be supported a lot better on GNU/Linux, but more and more e-mail clients support S/MIME these days. On Windows S/MIME is better supported, because Outlook Express and Mozilla Mail (two commonly used e-mail clients) both have S/MIME support. If you are communicating with many people that use Windows, it is a good choice to go for S/MIME, because it is worthless to use signed e-mails if the recipient can not verify them by default.
This section gives a short introduction on how to configure and use GnuPG. Make sure you have GnuPG installed. If you have not, you can install it with APT:
# apt-get install gnupg
Generating public and private keys is a bit complicated, because GnuPG uses DSA keys by default. DSA is an encryption algorithm, the problem is that the maximum key length of DSA is 1024 bits, this is considered too short for the longer term. That is why it is a good idea to use 2048 bit RSA keys. This section describers how this can be done.
Note: 1024-bit keys were believed to be secure for a long time. But Bernstein's paper "Circuits for Integer Factorization: a Proposal" contests this, the bottom line is that it is quite feasible for national security agencies to produce hardware that can break keys in a relatively short amount of time. Besides that it has be shown that 512-bit RSA keys can be broken in a relatively short time using common hardware. More information about these issues can by found in this e-mail to the cypherpunks list: http://lists.saigon.com/vault/security/encryption/rsa1024.html
We can generate a key by executing:
$ gpg --gen-key
The first question is what kind of key you would like to make. We will choose (4) RSA (sign only):
Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) RSA (sign only) Your selection? 4
You will then be asked what the size of the key you want to generate has to be. Type in 2048 to generate a 2048 bit key, and press enter to continue.
What keysize do you want? (1024) 2048
The next question is simple to answer, just choose what you like. Generally speaking it is not a bad idea to let the key be valid infinitely. You can always deactivate the key with a special revocation certificate.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
GnuPG will then ask for confirmation. After confirming your name and e-mail address will be requested. GnuPG will also ask for a comment, you can leave this blank, or you could fill in something like "Work" or "Private", to indicate what the key is used for. For example:
Real name: John Doe
Email address: john@doe.com
Comment: Work
You selected this USER-ID:
"John Doe (Work) <john@doe.com>"
GnuPG will the ask you to confirm your user ID. After confirming it GnuPG will ask you to enter a password. Be sure to use a good password:
You need a Passphrase to protect your secret key. Enter passphrase:
After entering the password twice GnuPG will generate the keys. But we are not done yet. GnuPG has only generated a key for signing information, not for encryption of information. To continue, have a look at the output, and look for the key ID. In the information about the key you will see pub 2048R/. The key ID is printed after this fragment. In this example:
public and secret key created and signed.
key marked as ultimately trusted.
pub 2048R/8D080768 2004-07-16 John Doe (Work) <john@doe.com>
Key fingerprint = 625A 269A 16B9 C652 B953 8B64 389A E0C9 8D08 0768
the key ID is 8D080768. If you lost the output of the key generation you can still find the key ID in the output of the gpg --list-keys command. Use the key ID to tell GnuPG that you want to edit your key:
$ gpg --edit-key <Key ID>
With the example key above the command would be:
$ gpg --edit-key 8D080768
GnuPG will now display a command prompt. Execute the addkey command on this command prompt:
Command> addkey
GnuPG will now ask the password you used for your key:
Key is protected. You need a passphrase to unlock the secret key for user: "John Doe (Work) <john@doe.com>" 2048-bit RSA key, ID 8D080768, created 2004-07-16 Enter passphrase:
After entering the password GnuPG will ask you what kind of key you would like to create. Choose RSA (encrypt only), and fill in the information like you did earlier (be sure to use a 2048 bit key). For example:
Please select what kind of key you want:
(2) DSA (sign only)
(3) ElGamal (encrypt only)
(4) RSA (sign only)
(5) RSA (encrypt only)
Your selection? 5
What keysize do you want? (1024) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
And confirm that the information is correct. After the key is generated you can leave the GnuPG command prompt, and save the new key with the save command:
Command> save
Congratulations! You have now generated the necessary keys to encrypt and decrypt e-mails and files. You can now configure your e-mail client to use GnuPG. It is a good idea to store the contents of the .gnupg directory on some reliable medium, and store that in a safe place! If your private key is lost you can't decrypt files and messages that were encrypted with your public key. If the private key, and your password are stolen, the security of this system is completely compromised.
To make GnuPG useful, you have to give your public key to people who send you files or e-mails. They can use your public key to encrypt files, or use it to verify whether a file has a correct signature or not. The key can be exported using the --export parameter. It is also a good idea to specify the --output parameter, this will save the key in a file. The following command would save the public key of John Doe, used in earlier examples, to the file key.gpg:
$ gpg --output key.gpg --export john@doe.com
This saves the key in binary format. Often it is more convenient to use the so-called "ASCII armored output", which fits better for adding the key to e-mails, or websites. You export an ASCII armored version of the key by adding the --armor parameter:
$ gpg --armor --output key.gpg --export john@doe.com
If you look at the key.gpg file you will notice that the ASCII armored key is a much more comfortable format.
With GPG you can make a signature for a file. This signature is unique, because your signature can only be made with your private key. This means that other people can check whether the file was really sent by you, and whether it was in any way altered or not. Files can be signed with the --detach-sign parameter. Let us look at an example. This command will make a signature for the memo.txt file. The signature will be stored in memo.txt.sig.
$ gpg --output memo.txt.sig --detach-sign memo.txt You need a passphrase to unlock the secret key for user: "John Doe (Work) <john@doe.com>" 2048-bit RSA key, ID 8D080768, created 2004-07-16 Enter passphrase:
As you can see, GnuPG will ask you to enter the password for your private key. After you have entered the right key the signature file (memo.txt.sig) will be created.
You can verify a file with its signature using the --verify parameter. Specify the signature file as a parameter to the --verify parameter. The file that needs to be verified can be specified as the final parameter:
$ gpg --verify memo.txt.sig memo.txt gpg: Signature made Tue Jul 20 23:47:45 2004 CEST using RSA key ID 8D080768 gpg: Good signature from "John Doe (Work) <john@doe.com>"
This will confirm that the file was indeed signed by John Doe (Work) <john@doe.com>, with the key 8D080768, and that the file is unchanged. Suppose the file was changed, GnuPG would have complained about it loudly:
$ gpg --verify memo.txt.sig memo.txt gpg: Signature made Tue Jul 20 23:47:45 2004 CEST using RSA key ID 8D080768 gpg: BAD signature from "John Doe (Work) <john@doe.com>"
Many GNU/Linux run some services that are open to a local network or the Internet. Other hosts can connect to these services by connecting to specific ports. For example, port 80 is used for WWW traffic. The /etc/services file contains a table with all commonly used services, and the port numbers that are used for these services.
A secure system should only run the services that are necessary. So, suppose that a host is acting as a web server, it should not have ports open (thus servicing) FTP or SMTP. With more open ports security risks increase very fast, because there is a bigger chance that the software servicing a port has a vulnerability, or is badly configured. The following few sections will help you tracking down which ports are open, and closing them.
Open ports can be found using a port scanner. Probably the most famous port scanner for GNU/Linux is nmap. nmap is available through the Debian package repositories. You can install nmap through you favorite package manager, or using APT:
# apt-get install nmap
The basic nmap syntax is: nmap host. The host parameter can either be a hostname or IP address. Suppose that we would like to scan the host that nmap is installed on. In this case we could specify the localhost IP address, 127.0.0.1:
$ nmap 127.0.0.1 Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost (127.0.0.1): (The 1596 ports scanned but not shown below are in state: closed) Port State Service 21/tcp open ftp 22/tcp open ssh 23/tcp open telnet 80/tcp open http 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds
In this example you can see that the host has five open ports that are being serviced; ftp, ssh, telnet, http and X11.
There are two ways to offer TCP/IP services: by running server applications stand-alone as a daemon or by using the internet super server, inetd(8). inetd is a daemon which monitors a range of ports. If a client attempts to connect to a port inetd handles the connection and forwards the connection to the server software which handles that kind of connection. The advantage of this approach is that it adds an extra layer of security and it makes it easier to log incoming connections. The disadvantage is that it is somewhat slower than using a stand-alone daemon. It is thus a good idea to run a stand-alone daemon on, for example, a heavily loaded FTP server.
You can check whether inetd is running on a host or not with ps, for example:
$ ps ax | grep inetd 2845 ? S 0:00 /usr/sbin/inetd
In this example inetd is running with PID (process ID) 2845. inetd can be configured using the /etc/inetd.conf file. Let's have a look at an example line from inetd.conf:
# File Transfer Protocol (FTP) server: ftp stream tcp nowait root /usr/sbin/tcpd proftpd
This line specifies that inetd should accept FTP connections and pass them to tcpd. This may seem a bit odd, because proftpd normally handles FTP connections. You can also specify to use proftpd directly in inetd.conf, but it is a good idea to give the connection to tcpd. This program passes the connection to proftpd in turn, as specified. tcpd is used to monitor services and to provide host based access control.
Services can be disabled by adding the comment character (#) at the beginning of the line. It is a good idea to disable all services and enable services you need one at a time. After changing /etc/inetd.conf inetd needs to be restarted to activate the changes. This can be done by sending the HUP signal to the inetd process:
# ps ax | grep 'inetd' 2845 ? S 0:00 /usr/sbin/inetd # kill -HUP 2845
If you do not need inetd at all, it is a good idea to remove it. If you want to keep it installed, but do not want Slackware to load it at the booting process, execute the following command as root:
# chmod a-x /etc/rc.d/rc.inetd