Objectives
More about using the mailx email client
To install and configure the IMAP server which allows remote email clients to access email on the server
To install and configure Thunderbird for a graphical email client
To use OpenSSL to generate a self-signed ID certificate suitable for testing
To configure Thunderbird to use the self-signed certificate with the STARTTLS authentication protocol
To use network analysis tools like ss and nmap to look for network connections related to email
To use those network tools to look for other ports that should not be open
Introduction
In Chapter 7 of this volume, we created an email server for our virtual domain, example.com. We installed SendMail and the tools needed to modify and recompile the SendMail configuration. We also installed and learned some basic usage for the mailx email client. Mailx is a powerful ASCII plain text email client that has two interfaces. It can be used with Standard I/O (STDIO) as part of a command pipeline to send email from shell scripts or command line programs. It can also be used as an interactive text mode user interface that uses keyboard commands to perform tasks like reading and deleting email, composing and sending new emails, and much more.
In this chapter, we will explore mailx in a bit more detail. We will also look at the GUI email client, Thunderbird. We will install and configure the IMAP email access protocol on the server which will enable Thunderbird to access emails on the server from remote clients. We will also create a self-signed certificate1 and use it to enable IMAP2 over Transport Layer Security (TLS).3 Certificates may also be referred to as certs.
More mailx
Although the mailx client and its predecessor, mail, have been around since the early days of Unix, it still has a place in today’s Linux environment. We have already seen in Chapter 7 how useful the mailx utility can be in testing email servers and mail transfer agents (MTAs).
Much of the utility of the mailx program comes from its flexible interface. We have already used it as part of a pipeline to send output from one utility to an email address. This makes it a powerful tool for the SysAdmin when installing or repairing email systems. Now we want to explore the use of mailx as an ASCII text email client from which we can send and retrieve emails.
As an email client, mailx has some major limitations that make it unsuitable for the average user – it is typically run as a text mode tool on the email server itself. It is not intended to run on a local host to access email on a remote server. The user must use SSH to log in to the email server in order to access their email so that the email users must have a login account on the server and not the safer nologin account. This can be a security issue but we won’t consider that here.
That said, mailx does have extensions that will allow it to connect to an IMAP server. We will get to IMAP later in this chapter but will not use mailx with IMAP.
Experiment 8-1
Start this experiment as the student user on StudentVM1. This experiment is an exploration of mailx as a basic email client.
As we have already discovered, many commands can be invoked with just its first letter. Note that “R” and “r” are different commands. Now enter l (lowercase l – el) to list all of the available commands. You can always view the help and list of commands if you get stuck.
After entering the mailx command, it prompts you for the subject. After entering that, you get an empty line and you can simply start typing your message. When you have finished entering the message, use the Ctrl-D (EOT or End Of Text) to tell mailx to send the message.
Now view the message in the interactive interface.
Although mailx is a powerful and flexible tool for the SysAdmin, it leaves a great deal to be desired with respect to the normal email experience we expect today.
IMAP
Once email has been delivered to the server, you must retrieve it from the mail spool file in order to read it. Email can be retrieved from remote servers using the IMAP protocol. IMAP was designed explicitly to allow users to access all of their emails from multiple devices running an email client. This was originally conceived as multiple computers but in this Internet age encompasses, all types of connected devices.
IMAP is a much better tool to use for multiple devices than the old and much simpler post office protocol (POP ). Clients connecting to an email server using POP download all of the messages to the local host and delete them from the server. Thus, those messages that have already been downloaded cannot be viewed by any of the other devices. For this reason, we will cover only IMAP in this course.
Configuring IMAP on the server
It is necessary to install a program that can deal with remote connections using IMAP. There are several, but in this class, we will install the University of Washington IMAP package. UW IMAP provides both POP and IMAP; it is simple to install and there is little configuration required. It is also necessary to install a wrapper program to control the IMAP program. The Xinetd package provides TCP Wrappers around many programs that do not run as daemons, such as Telnet, IMAP, and POP. You should have already installed Xinetd on StudentVM1 in Chapter 17 in Volume 2 of this course but have not done so yet on StudentVM2.
Experiment 8-2
Note that you must use the “a000x” sequence numbers or your commands will not work. Try the same test from StudentVM1 on the virtual network.
Our IMAP server is now working.
Notice our use of Telnet to connect with the IMAP server for testing. This is only possible because the standard Internet protocols such as SMTP, IMAP, and others use ASCII plain text commands and responses. That makes it easy for us to simulate a connection from a client. We could have done the same thing with SMTP to actually send an email because it, too, uses ASCII plain text protocols.
Thunderbird
Thunderbird is only one of many email clients that are available for Linux. It is freely available for all platforms and is becoming very popular. It is my current GUI email client of choice. The Xfce version of Fedora that we installed contains the Claws GUI email client, but we will install and configure Thunderbird because it is so widespread.
Experiment 8-3
Perform the rest of this experiment as the student user on StudentVM1.
This dialog starts the Email account setup the first time Thunderbird is launched
Email configuration settings for the first page of Thunderbird email account configuration
Thunderbird has queried the email server and obtained the required connection data
Now click the Done button to complete the configuration.
Well, things do not always work as one should be able to expect, do they? I received an error message indicating that the username or password is wrong. Having been through this many times, I already know that the configuration for authentication with the server is the most likely cause of this problem.
The Manual Configuration dialog shows the problem because the configuration utility assumes that we are using Kerberos for authentication when we are not
For now, to prevent getting too sidetracked, we will resolve this problem the easy way so that we can get email up and running. In the SSL (Secure Socket Layer) column, select None for both IMAP (inbound) and SMTP (outbound). In the Authentication column, select Normal password for IMAP and No authentication for SMTP. Press Done. You will receive a red warning dialog. Place a check in the I understand the risks box and click the Done button, and then click Done again.
Thunderbird will connect to the server, authenticate for the IMAP connection, and download any emails that already exist in the inbox. Click the Inbox and look at the emails there, as at least a few should be present. Notice that there is no Sent mail folder.
Thunderbird after initial basic configuration with downloaded email
Adding authentication
Email is insecure – period. No matter what we do on our servers and clients, once an email leaves our network, we must consider it to be readable by everyone on the Internet which amounts to nearly the entire world. Many politicians and white-collar criminals have found this out the hard way. No matter that we have configured TLS to provide some encryption between our SMTP server and other SMTP servers, most SMTP servers have not implemented this security mechanism. As a result, most SMTP servers talk to each other in unencrypted plain text.
Another problem I have encountered when traveling is that I do not have an email account for the local ISPs for outbound SMTP. This is usually an attempt by the ISP to block spam sent directly from infected hosts on their networks. This means that I cannot send email from those networks without some sort of circumvention. I can use my own email server as the outbound SMTP server, but that means it is accessible to spammers as an open relay.
There are a couple things we can do to improve security and help prevent the use of our mail servers as open relays. For example, the use of authentication will allow a laptop to use our own email server as a relay while preventing others from using it the same way.
It is possible to use a number of different forms of authentication so that mobile users can authenticate with their own email server in order to allow relaying. It took me a lot of work to figure this out. Using authentication so that we can connect both SMTP and IMAP to our own email server allows us to send email from anywhere even if we don’t have an email account on the local ISP.
SMTP already uses STARTTLS for authentication and encryption as we found in Chapter 7 of this volume. So we do not need to do anything else for that except to configure it in the Thunderbird client.
Certificates
Certificates are the key, if you will pardon the pun, to enabling authentication and encryption. These certificates provide a verifiable identity for the server and are also used to provide the encryption key for the connections.
ID certificates are sold by a number of recognized certificate authorities (CAs) such as Verisign, Symantec, DigiCert, GeoTrust, RapidSSL, and others. Let’s Encrypt4 provides a free and open certificate authority that is backed by many well-known and respected sponsors and donors. For our purposes, a self-signed certificate is perfect.
IMAP authentication
Adding authentication and encryption to IMAP is easy because we already have most of the necessary parts in place. The IMAP protocol does not include authentication or encryption, but the IMAPS protocol does. TLS is also available just as we used for SMTP in Chapter 7 and is relatively easy to set up so we will use that.
Experiment 8-4
Start this experiment as root on StudentVM2. We will enable IMAPS, restart the Xinetd service, and add a rule to the firewall for IMAPS.
Restart Xinetd.
Copy the imapd.pem file to the /etc/ssl/certs directory. You should also view the content of the certificate with a paging tool like less.
For a real-world server, we would use the openSSL tool to generate a certification signing request and send it to a public certification authority (CA) and receive a signed certificate from them that verifies the identity of our server. A self-signed certificate like we just created is fine for a closed environment like we have in our virtual network, used inside an organization where no outsiders will be accessing the server and in other types of testing environments. Self-signed certificates should never be used on a server that allows public access.
A search on “certificate authorities list” will result in links to a good number of public CAs, many of which charge a fee for certificates. There are also some “open” and free CAs that you can find by searching, “free certificate authority.”
Let’s Encrypt5 is a free certificate authority that is a collaborative project with the Linux Foundation. It is sponsored by Mozilla, Akamai, SiteGround, Cisco, Facebook, and many more organizations. It offers free SSL Certificates.
Change the Thunderbird server settings to STARTTLS for connection security and TLS certificate for the authentication method
Click the OK button to complete this configuration.
Testing is easy. Send yourself an email to [email protected]. You should receive the email within a few moments, but if it does not show up fairly, quickly click the Get Messages button on the Thunderbird icon bar. If you get an error, the configuration is not correct. If you have performed the configuration tasks correctly, you should receive no errors.
Be sure to view the log files and the email headers to familiarize yourself with how they might – or might not – differ from emails sent prior to adding IMAP over TLS.
Now we have IMAPS set up for authentication and encryption which enables us to obtain email from remote locations in a reasonably secure manner. The way we have done this is not completely secure because the password is transmitted as ASCII plain text and is not encrypted. However, the data connection itself is encrypted.
More about ports
We have been talking about network ports quite a bit in this course. A TCP or UDP port is not a physical port like the physical connection port on a network interface card (NIC). These are all logical ports that are defined by a number and which we humans usually refer to by the protocol assigned to that port.
We have seen that port 22 is for SSH, port 23 for Telnet, 25 for SMTP, etc. The standard and commonly recognized port assignments are defined in the file /etc/services. If you ever see a port number or name that you don’t recognize, you can start your research with that file.
Although we could have discussed network ports in several places before this, it makes more sense to do so now that we have more ports open in our firewall and more services listening on various ports. This is more meaningful here and it applies to email-related ports as well.
An open port on a computer is one that some service is listening on for connections. However even an open port can be blocked by the host’s firewall. This is why the services we are adding to our server need to have their respective ports added to the firewall for them to work.
Let’s look at the open ports on our server. As with many things in Linux, there are multiple tools we can apply to this task.
Experiment 8-5
Perform this experiment as the root user on StudentVM2. In it we look at four tools that enable us to explore network connections and the ports they use.
This command with -a shows all network ports that are open and listening, IPV[460], UDP, TCP, as well as all open sockets for applications and services that are communicating with other internal processes and not with other hosts.
It appears from this that the new ss command can be used in place of the netstat command with similar options. The results show the same data although a bit different column and row orders. This might affect existing scripts that parse this data.
Note the peer address port numbers on the established connections which are very high. When any service connects to a remote host, the outbound port number is a high random one. This source port can be different for each connection and usually is. The destination port is the one that is assigned and standardized.
There are three IMAP connections from 192.168.56.21, studentvm1, from three different ports to studentvm2 at 192.168.56.1 on port 143. This also illustrates that multiple connections can be made to the same port. There are two SSH connections in this result, one inbound and one outbound.
Do you remember the many times I have mentioned that “everything is a file?” Good, because network connections are files, too. The lsof (list open files) utility will show us that. Although intended primarily for listing the files in a specific filesystem that are open and thus allowing us to locate and close them in order to unmount a filesystem, it can also work with network connections.
This was a very long list on my VM, and you should have a fairly long list, too. Just being logged in opens a number of files.
The nmap utility is used to scan and map open network ports on a host, local or remote, not just those on which a service is actually listening. Because nmap can scan remote hosts, it is used by security specialists to test the vulnerability of hosts that are network connected. It can also be used by crackers to locate those same vulnerabilities with the intent to force access to the systems. I strongly suggest you not use nmap to scan systems that do not belong to you. Many organizations look for such scanning attacks and will react very aggressively to protect their networks.
I suggest reading the DESCRIPTION section of the nmap man page before continuing.
Note The nmap utility will take a significant amount of time to perform its task of probing both local and remote hosts for open network ports. From 94 minutes in one instance to 19 hours when scanning StudentVM1 from StudentVM2. Your virtual environment will be different so the times you experience will also be different.
Do not terminate or skip these parts of this experiment because there is much to be learned. However, you may continue on with the rest of this chapter and beyond while you allow these tests to run.
Now let’s run this same command from StudentVM2 against StudentVM1.
You will be able to observe a continuous sequence of probes against the network interface of StudentVM1.
Now try these same commands as root on StudentVM1 and compare the results from StudentVM2.
It is fine to let these commands continue to run while you finish this chapter and proceed on with the next chapters in this course.
Experiment 8-5 shows us some diverse tools that we can use to test the network vulnerability of our hosts. Finding open ports that should not be open or that are valid in some situations but which are not needed for a specific environment should trigger some research. Why are these ports open and what happens if I use the firewall to block them and disable the services behind them?
One thing this does tell us is that IMAP and IMAPS are both open. We only need IMAP because we are using TLS so IMAPS could be disabled and the firewall rule that allows external access from IMAPS can be removed from the firewall.
Other considerations
You should be aware that different email clients have some unique configuration requirements that will be different from Thunderbird. For example, some clients do not support certain types of encryption. If you have problems configuring those clients, refer to the web pages and other documentation for those clients and ensure that the server is configured to support their unique requirements.
Chapter summary
This chapter explored the mailx client a bit more. Although it is a powerful tool for the SysAdmin, it leaves a lot to be desired for most users and even for us SysAdmins for daily email use. It does make an excellent tool for testing.
We installed Thunderbird, one of the popular email clients, and used it to test various configurations of our email server. This included with and without authentication using TLS.
We also used some tools that enable us to view open network ports, network connections, and to determine whether some actions should be taken to lock down unused network ports. We used the nmap tool to probe the localhost and a remote host on our virtual network for vulnerabilities.
Exercises
- 1.
What unique capability makes mailx an ideal tool for the SysAdmin who works with and supports email systems?
- 2.
What limitations does mailx have that make it a poor choice for most of today’s email users?
- 3.
Where are the email inboxes for email users located?
- 4.
From StudentVM1, use Telnet and SMTP to send an email from StudentVM2.
- 5.
Where are email folders other than the Inbox stored?
- 6.
What other methods could be used to create an encrypted TLS connection between the local email client such as Thunderbird on StudentVM1 and the remote email server on StudentVM2?
- 7.
Disable IMAPS and remove the firewall rule that allows external access from IMAPS.
- 8.
Based on nmap scans of both StudentVM1 and StudentVM2, did you find unused but open ports that could be closed down?