Previous | Table of Contents | Next |
Prudent. The second position is called prudent or restrictive. It too is motivated by caution, but also by a recognition of the value of connection to the Internet. It is characterized by the fact that everything which is not explicitly allowed is implicitly forbidden. For example, a private Internet user would have to be explicitly authorized to Telnet to a system on the public Internet.
Permissive The permissive posture is the opposite of the restrictive policy. Under this policy, everything that is not explicitly forbidden is implicitly allowed. Obviously, it is the intent of this policy to forbid the necessary conditions for all known attacks. This policy is intended to provide a level of protection with a minimum of interference with applications. This is the policy most likely to be applied when applying a firewall to an existing connection. It is particularly useful if little is known about the applications and if there is a strong desire not to interfere with or break those applications. It is the policy most likely to be recommended by Internet service providers who are motivated to maximize the value of the connection.
Promiscuous. The promiscuous policy is that anything goes. Under this policy, there are multiple connections and any legitimate packet can flow from any source to any destination.
An interesting questions is why anyone would want to be in postures one or four? Remarkably, position one is the default position for business. Most businesses have not yet connected to the Internet. Position four is the default policy for the Internet; all connections and traffic are tolerated in the name of maximizing the bandwidth and the potential for getting messages through.
If an Internet service provider is asked for guidance on a firewall policy, it will likely recommend that the position should be on the promiscuous side of permissive. The service provider will supply a list of restrictions to address all of the attacks that it knows about. However, this permits exposure to a large set of fundamental vulnerabilities. This is, in part, because the Internet service provider believes in the value of the net and does not wish to deny its clients any benefits without necessity.
This author recommends a position on the paranoid side of prudent or restrictive. In other words, permit only that traffic that is associated with a particular value for which the net is being used. The flow of all other traffic should be resisted.
A conservative firewall policy is intended to position an institution or network on the paranoid side of restrictive. The intent is to protect not only against known and expected attacks, but also against those that have not been invented yet. It is driven by fundamental vulnerabilities, rather than by known threats and attacks. It attempts to take only those risks that are necessary to accommodate the intended applications.
In addition, no information about the private network should be available on the public net. Private net addresses should never appear on the public net; they should be replaced or aliased to an address that the firewall owns. Addresses on packets and messages should be re-encoded at the firewall. Similarly, users internal E-mail addresses should not appear on the public net. These private addresses should be replaced with the name of the site or enterprise at the firewall on the way out and replaced on the way in.
Protocols should not traverse the firewall. Traffic should be decoded and re-encoded at the firewall. For example, a SMTP carrying a message should be decoded into a message and then re-encoded into another SMTP for transmission at the firewall.
Reusable passwords should not traverse the firewall in either direction. Incoming passwords may be replays and are not reliable evidence of the identity of the user. Outgoing passwords may be similar to those used by users on the inside, and their use across the firewall may compromise internal systems. A preference for Secure Telnet or FTP should be made. These protocols provide end-to-encryption for all traffic, including the password. Alternatively, one-time passwords (e.g., SecureID or s-key) could be used. Although these do not protect all traffic, they protect against replays.
Proxies should represent the public net to the private net. For example, when a user of the private net wishes to access a WWW server on the public net, he or she should be transparently routed through the WWW proxy on the firewall. This proxy should hide the users address from the public net, and protects both nets and the user. The user cannot misrepresent his or her address to the public net, and a process on the public net can directly attack only the proxy, not the user.
Only a limited set of limited applications should be permitted. Under this policy, such a limited application as E-mail is permitted, and such a very general application as telnet is discouraged. Telnet is very general, flexible, and its intent is not obvious. It is vulnerable as a target and useful for attack.
Only those public applications that are intended for use on the public net should be placed on the public net. The public should not be permitted to traverse a firewall simply for the purpose of gaining access to public applications.
Application | Encryption |
---|---|
PGP, SecureXchange, PEM, S-MIME | |
File | PGP, RSA Secure, Entrust |
Application | DES, IDEA, stelnet, sftp |
Client/Server | Secure Socket Layer (SSL) |
Gateway-to-gateway | Digital, IBM, TIS |
World Wide Web | s-http |
Secure IP | S/WAN |
See http://www.rsa.com for a list of products and vendors. |
Applications on the public net should be implemented on dedicated and isolated servers. The server should be dedicated to a single use; it should not rely on the operating system to protect the application. Public servers should not know about the private net. Any connection to the private net should be to an application and over a trusted path. Privileged access to such servers should require strong authentication.
Previous | Table of Contents | Next |