POP is a client/server protocol for handling user electronic mailboxes. With POP, a user's mail spool (the actual file where that user's incoming email is held for later access) is kept on a server, rather than on the user's personal machine. The server is probably available to accept incoming mail more consistently than the user's personal machine is (particularly if the user's "personal machine" is a portable that is only sometimes connected to the network). Clients like Eudora, Z-Mail, or Netscape use POP to transfer the mail to the personal machine when the user wants it.
Two major security issues are involved in using POP across the Internet. First, be aware that standard POP clients and servers send the user's POP password over the Internet in the clear, so that anyone snooping on the connection can capture and reuse it later. In most cases, the POP password is the same as the user's login password, so that someone who snoops on it can get all of the user's privileges -- not just the user's electronic mail. More secure variants of POP support Kerberos (called KPOP) and a challenge-response system for authentication (called APOP), but these secure variants are not widely available or widely supported. You may have trouble finding a combination of clients and servers that supports these variants and that works for your site.
Second, regardless of the authentication issues, be sure to also consider the sensitivity of the email your users will be accessing over the Internet via POP. Whatever email your users access will be visible to anyone snooping on their POP sessions; you need to think about how sensitive email might be in your own environment. Many sites decide that, regardless of the authentication issues, their users' internal email is often too sensitive to risk being snooped on by someone monitoring their POP sessions. These sites decide to provide alternative access methods, such as dial-ups, that aren't as susceptible to snooping. If you provide your users with the ability to reach your network on the inside of the firewall (for example, using a VPN or with modems and PPP), you can give them POP access while they're traveling without allowing it to be snooped on the Internet.
Two different processes are being used to provide protection for POP. Currently, some servers and clients support the use of POP over SSL, encrypting the entire connection (this is sometimes called SecurePOP). This is an effective stopgap measure, but it requires the use of another port for POP over SSL. (SSL and TLS are discussed in Chapter 14, "Intermediary Protocols".)
There is also a standard in progress that extends the POP protocol to allow clients and servers to negotiate the use of TLS on a normal POP connection. This is the preferred method for providing encryption for services, since it doesn't require a new port, and the supply of port numbers is limited. Unfortunately, the standard is not yet complete and support for it is not widespread.
Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
---|---|---|---|---|---|---|---|
In | Ext | Int | TCP | >1023 |
110, 109[63]
|
[64]
|
Incoming POP connection, client to server |
Out | Int | Ext | TCP | 110, 109[63] | >1023 | Yes | Incoming POP connection, server to client |
In | Ext | Int | TCP | >1023 | 995 | [64] | Incoming POP over SSL connection, client to server |
Out | Int | Ext | TCP | 995 | >1023 | Yes | Incoming POP over SSL connection, server to client |
Out | Int | Ext | TCP | >1023 | 110, 109[63] | [64] | Outgoing POP connection, client to server |
In | Ext | Int | TCP | 110, 109[63] | >1023 | Yes | Outgoing POP connection, server to client |
Out | Int | Ext | TCP | >1023 | 995 | [64] | Outgoing POP over SSL connection, client to server |
In | Ext | Int | TCP | 995 | >1023 | Yes | Outgoing POP over SSL connection, server to client |
[63]Modern POP (POP3) servers use port 110; older POP2 servers use port 109.
[64]ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.An outgoing POP connection would allow your users to download their mail from other sites. This is no more dangerous than allowing outgoing Telnet, and you will probably want to allow such a POP connection if there is any demand.
Incoming POP connections are those that allow people at other sites to read mail delivered for them at your site. As discussed in the previous section, you probably don't want to allow incoming POP. If you do, you should certainly limit POP connections to a POP server running on a single host. There have been several problems with buffer overflows in POP servers, and if any new ones are found, you would like to be able to patch them on just one host, without worrying about all your internal hosts. This is easiest if you run POP on a dedicated bastion host.
You will also want to be sure that POP servers that serve incoming connections are configured so that POP does not use user accounts for authentication. Some POP servers use normal user accounts to authenticate connections. Since the POP server is a bastion host, you don't want users to be able to log in to it, particularly from the Internet. You should either use a POP server that supports an alternate source of authentication, or disable logins on the accounts that POP uses.
Two POP proxies are available as add-ons to the TIS-FWTK. pop-gw is an inbound proxy for POP3. pop3-gw will do inbound or outbound proxying. For inbound proxying, you can configure it to run as a pass-through, passing all connections to a specific internal server. For outbound use, it uses modified procedures; the user specifies user@server[:port] as his or her username and connects to the proxy server. The proxy server will use APOP to speak to the real server if it is available and may be configured to refuse connections if APOP is not available; this will keep you from passing reusable passwords around via the proxy. Note that all data will still be transmitted unencrypted and will be interceptable.