 Information Resource Guide |
| Information Resource Guide |
Perhaps it is best to describe first what a firewall is not: A firewall is not simply a router, host system, or collection of systems that provides security to a network. Rather, a firewall is an approach to security; it helps implement a larger security policy that defines the services and access to be permitted, and it is an implementation of that policy in terms of a network configuration, one or more host systems and routers, and other security measures such as advanced authentication in place of static passwords. The main purpose of a firewall system is to control access to or from a protected network (i.e., a site). It implements a network access policy by forcing connections to pass through the firewall, where they can be examined and evaluated. A firewall system can be a router, a personal computer, a host, or a collection of hosts, set up specifically to shield a site or subnet from protocols and services that can be abused from hosts outside the subnet. A firewall system is usually located at a higher level gateway, such as a site's connection to the Internet, however firewall systems can be located at lower-level gateways to provide protection for some smaller collection of hosts or subnets.
The main function of a firewall is to centralize access control. A firewall serves as the gatekeeper between the untrusted Internet and the more trusted internal networks. If outsiders or remote users can access the internal networks without going through the firewall, its effectiveness is diluted. For example, if a traveling manager has a modem connected to his office PC that he or she can dial into while traveling, and that PC is also on the protected internal network, an attacker who can dial into that PC has circumvented the firewall. Similarly, if a user has a dial-up Internet account with a commercial ISP, and sometimes connects to the Internet from their office PC via modem, he or she is opening an unsecured connection to the Internet that circumvents the firewall.
What is being protected by firewalls?
Integrity - what others should not change
Availability - your ability to use your own systems
Your site can be used as a launching point for crime
You may be used as a distribution site for unwanted data
You may be used by impostors to cause serious problems
Firewalls provide several types of protection:
5.2 Firewall Security and Concepts
The primary components (or aspects) of a firewall are:
There are two levels of network policy that directly influence the design, installation and use of a firewall system. The higher-level policy is an issue-specific, network access policy that defines those services that will be allowed or explicitly denied from the restricted network, how these services will be used, and the conditions for exceptions to this policy. The lower-level policy describes how the firewall will actually go about restricting the access and filtering the services that were defined in the higher level policy. The following sections describe these policies in brief.
The service access policy should focus on Internet-specific use issues as defined above, and perhaps all outside network access (i.e., dial-in policy, and SLIP and PPP connections) as well. This policy should be an extension of an overall organizational policy regarding the protection of information resources in the organization. For a firewall to be successful, the service access policy must be realistic and sound and should be drafted before implementing a firewall. A realistic policy is one that provides a balance between protecting the network from known risks, while still providing users access to network resources. If a firewall system denies or restricts services, it usually requires the strength of the service access policy to prevent the firewall's access controls from being modified on an ad hoc basis. Only a management-backed, sound policy can provide this.
A firewall can implement a number of service access policies, however a typical policy may be to allow no access to a site from the Internet, but allow access from the site to the Internet. Another typical policy would be to allow some access from the Internet, but perhaps only to selected systems such as information servers and e-mail servers. Firewalls often implement service access policies that allow some user access from the Internet to selected internal hosts, but this access would be granted only if necessary and only if it could be combined with advanced authentication.
5.2.0.2 Firewall Design Policy
The firewall design policy is specific to the firewall. It defines the rules used to implement the service access policy. One cannot design this policy in a vacuum isolated from understanding issues such as firewall capabilities and limitations, and threats and vulnerabilities associated with TCP/IP. Firewalls generally implement one of two basic design policies:
The first policy is less desirable, since it offers more avenues for getting around the firewall, e.g., users could access new services currently not denied by the policy (or even addressed by the policy) or run denied services at non-standard TCP/UDP ports that aren't denied by the policy. Certain services such as X Windows, FTP, Archie, and RPC cannot be filtered easily [Chap92], [Ches94], and are better accommodated by a firewall that implements the first policy. The second policy is stronger and safer, but it is more difficult to implement and may impact users more in that certain services such as those just mentioned may have to be blocked or restricted more heavily.
The relationship between the high level service access policy and its lower level counterpart is reflected in the discussion above. This relationship exists because the implementation of the service access policy is so heavily dependent upon the capabilities and limitations of the firewall system, as well as the inherent security problems associated with the wanted Internet services. For example, wanted services defined in the service access policy may have to be denied if the inherent security problems in these services cannot be effectively controlled by the lower level policy and if the security of the network takes precedence over other factors. On the other hand, an organization that is heavily dependent on these services to meet its mission may have to accept higher risk and allow access to these services. This relationship between the service access policy and its lower level counterpart allows for an iterative process in defining both, thus producing the realistic and sound policy initially described.
The service access policy is the most significant component of the four described here. The other three components are used to implement and enforce the policy. (And as noted above, the service access policy should be a reflection of a strong overall organization security policy.) The effectiveness of the firewall system in protecting the network depends on the type of firewall implementation used, the use of proper firewall procedures, and the service access policy.
Sections 1.3,1.3.1, and 1.3.2 describe incidents on the Internet that have occurred in part due to the weaknesses associated with traditional passwords. For years, users have been advised to choose passwords that would be difficult to guess and to not reveal their passwords. However, even if users follow this advice (and many do not), the fact that intruders can and do monitor the Internet for passwords that are transmitted in the clear has rendered traditional passwords obsolete.
Advanced authentication measures such as smartcards, authentication tokens, biometrics, and software-based mechanisms are designed to counter the weaknesses of traditional passwords. While the authentication techniques vary, they are similar in that the passwords generated by advanced authentication devices cannot be reused by an attacker who has monitored a connection. Given the inherent problems with passwords on the Internet, an Internet-accessible firewall that does not use or does not contain the hooks to use advanced authentication makes little sense.
Some of the more popular advanced authentication devices in use today are called one-time password systems. A smartcard or authentication token, for example, generates a response that the host system can use in place of a traditional password. Because the token or card works in conjunction with software or hardware on the host, the generated response is unique for every login. The result is a one-time password that, if monitored, cannot be reused by an intruder to gain access to an account. [NIST94a] and [NIST91a] contain more detail on advanced authentication devices and measures.
Since firewalls can centralize and control site access, the firewall is the logical place for the advanced authentication software or hardware to be located. Although advanced authentication measures could be used at each host, it is more practical and manageable to centralize the measures at the firewall. Figure above illustrates that a site without a firewall using advanced authentication permits unauthenticated application traffic such as TELNET or FTP directly to site systems. If the hosts do not use advanced authentication, then intruders could attempt to crack passwords or could monitor the network for login sessions that would include the passwords. Figure above also shows a site with a firewall using advanced authentication, such that TELNET or FTP sessions originating from the Internet to site systems must pass the advanced authentication before being permitted to the site systems. The site systems may still require static passwords before permitting access, however these passwords would be immune from exploitation, even if the passwords are monitored, as long as the advanced authentication measures and other firewall components prevent intruders from penetrating or bypassing the firewall.
IP packet filtering is done usually using a packet filtering router designed for filtering packets as they pass between the router's interfaces. A packet filtering router usually can filter IP packets based on some or all of the following fields:
Filtering can be used in a variety of ways to block connections from or to specific hosts or networks, and to block connections to specific ports. A site might wish to block connections from certain addresses, such as from hosts or sites that it considers to be hostile or untrustworthy. Alternatively, a site may wish to block connections from all addresses external to the site (with certain exceptions, such as with SMTP for receiving e-mail).
Adding TCP or UDP port filtering to IP address filtering results in a great deal of flexibility. Recall from Chapter 1 that servers such as the TELNET daemon reside usually at specific ports, such as port 23 for TELNET. If a firewall can block TCP or UDP connections to or from specific ports, then one can implement policies that call for certain types of connections to be made to specific hosts, but not other hosts. For example, a site may wish to block all incoming connections to all hosts except for several firewalls-related systems. At those systems, the site may wish to allow only specific services, such as SMTP for one system and TELNET or FTP connections to another system. With filtering on TCP or UDP ports, this policy can be implemented in a straightforward fashion by a packet filtering router or by a host with packet filtering capability.
As an example of packet filtering, consider a policy to allow only certain connections to a network of address 123.4.*.*. TELNET connections will be allowed to only one host, 123.4.5.6, which may be the site's TELNET application gateway, and SMTP connections will be allowed to two hosts, 123.4.5.7 and 123.4.5.8, which may be the site's two electronic mail gateways. NNTP (Network News Transfer Protocol) is allowed only from the site's NNTP feed system, 129.6.48.254, and only to the site's NNTP server, 123.4.5.9, and NTP (Network Time Protocol) is allowed to all hosts. All other services and packets are to be blocked. An example of the rule set would be as follows:
he first rule allows TCP packets from any source address and port greater than 1023 on the Internet to the destination address of 123.4.5.6 and port of 23 at the site. Port 23 is the port associated with the TELNET server, and all TELNET clients should have unprivileged source ports of 1024 or higher. The second and third rules work in a similar fashion, except packets to destination addresses 123.4.5.7 and 123.4.5.8, and port 25 for SMTP, are permitted. The fourth rule permits packets to the site's NNTP server, but only from source address 129.6.48.254 to destination address 123.4.5.9 and port 119 (129.6.48.254 is the only NNTP server that the site should receive news from, thus access to the site for NNTP is restricted to only that system). The fifth rule permits NTP traffic, which uses UDP as opposed to TCP, from any source to any destination address at the site. Finally, the sixth rule denies all other packets - if this rule weren't present, the router may or may not deny all subsequent packets. This is a very basic example of packet filtering. Actual rules permit more complex filtering and greater flexibility.
5.3.0 Which Protocols to Filter
The decision to filter certain protocols and fields depends on the network access policy, i.e., which systems should have Internet access and the type of access to permit. The following services are inherently vulnerable to abuse and are usually blocked at a firewall from entering or leaving the site [Chap92], [Garf92]:
5.3.1 Problems with Packet Filtering Routers
Packet filtering routers suffer from a number of weaknesses, as described in [Chap92]. Packet filtering rules are complex to specify and usually no testing facility exists for verifying the correctness of the rules (other than by exhaustive testing by hand). Some routers do not provide any logging capability, so that if a router's rules still let dangerous packets through, the packets may not be detected until a break-in has occurred.
Often times, exceptions to rules need to be made to allow certain types of access that normally would be blocked. But, exceptions to packet filtering rules sometimes can make the filtering rules so complex as to be unmanageable. For example, it is relatively straightforward to specify a rule to block all inbound connections to port 23 (the TELNET server). If exceptions are made, i.e., if certain site systems need to accept TELNET connections directly, then a rule for each system must be added. Sometimes the addition of certain rules may complicate the entire filtering scheme. As noted previously, testing a complex set of rules for correctness may be so difficult as to be impractical.
Some packet filtering routers do not filter on the TCP/UDP source port, which can make the filtering rule set more complex and can open up ``holes'' in the filtering scheme. [Chap92] describes such a problem with sites that wish to allow inbound and outbound SMTP connections. As described in section , TCP connections include a source and destination port. In the case of a system initiating an SMTP connection to a server, the source port would be a randomly chosen port at or above 1024 and the destination port would be 25, the port that the SMTP server "listens" at. The server would return packets with source port of 25 and destination port equal to the randomly-chosen port at the client. If a site permits both inbound and outbound SMTP connections, the router must allow destination ports and source ports > 1023 in both directions. If the router can filter on source port, it can block all packets coming into the site that have a destination port > 1023 and a source port other than 25. Without the ability to filter on source port, the router must permit connections that use source and destination ports > 1024.
Users could conceivably run servers at ports > 1023 and thus get "around" the filtering policy (i.e., a site system's telnet server that normally listens at port 23 could be told to listen at port 9876 instead; users on the Internet could then telnet to this server even if the router blocks destination port 23).
Another problem is that a number of RPC (Remote Procedure Call) services are very difficult to filter effectively because the associated servers listen at ports that are assigned randomly at system startup. A service known as portmapper maps initial calls to RPC services to the assigned service numbers, but there is no such equivalent for a packet filtering router. Since the router cannot be told which ports the services reside at, it isn't possible to block completely these services unless one blocks all UDP packets (RPC services mostly use UDP). Blocking all UDP would block potentially necessary services such as DNS. Thus, blocking RPC results in a dilemma.
Packet filtering routers with more than two interfaces sometimes do not have the capability to filter packets according to which interface the packets arrived at and which interface the packet is bound for. Filtering inbound and outbound packets simplifies the packet filtering rules and permits the router to more easily determine whether an IP address is valid or being spoofed. Routers without this capability offer more impediments to implementing filtering strategies.
Related to this, packet filtering routers can implement both of the design policies discussed in section 2.4.1. A rule set that is less flexible, i.e., that does not filter on source port or on inbound and outbound interfaces, reduces the ability of the router to implement the second and more stringent policy, deny all services except those expressly permitted, without having to curtail the
types of services permitted through the router. For example, problematic services such as those that are RPC-based become even more difficult to filter with a less-flexible rule set; no filtering on source port forces one to permit connections between ports > 1023. With a less-flexible rule set, the router is less able to express a stringent policy, and the first policy, permit all services except those expressly permitted, is usually followed.
Readers are advised to consult [Chap92], which provides a concise overview of packet filtering and associated problems. While packet filtering is a vital and important tool, it is very important to understand the problems and how they can be addressed.
To counter some of the weaknesses associated with packet filtering routers, firewalls need to use software applications to forward and filter connections for services such as TELNET and FTP. Such an application is referred to as a proxy service, while the host running the proxy service is referred to as an application gateway. Application gateways and packet filtering routers can be combined to provide higher levels of security and flexibility than if either were used alone.
As an example, consider a site that blocks all incoming TELNET and FTP connections using a packet filtering router. The router allows TELNET and FTP packets to go to one host only, the TELNET/FTP application gateway. A user who wishes to connect inbound to a site system would have to connect first to the application gateway, and then to the destination host, as follows:
of security is important, as it guarantees that only those services that are deemed ``trustworthy'' are allowed through the firewall. It also prevents other untrusted services from being implemented behind the backs of the firewall administrators.
Another benefit to using proxy services is that the protocol can be filtered. Some firewalls, for example, can filter FTP connections and deny use of the FTP put command, which is useful if one wants to guarantee that users cannot write to, say, an anonymous FTP server.
Application gateways have a number of general advantages over the default mode of permitting application traffic directly to internal hosts. These include:
In addition to TELNET, application gateways are used generally for FTP and e-mail, as well as for X Windows and some other services. Some FTP application gateways include the capability to deny put and get command to specific hosts. For example, an outside user who has established an FTP session (via the FTP application gateway) to an internal system such as an anonymous FTP server might try to upload files to the server. The application gateway can filter the FTP protocol and deny all puts to the anonymous FTP server; this would ensure that nothing can be uploaded to the server and would provide a higher degree of assurance than relying only on file permissions at the anonymous FTP server to be set correctly.
An e-mail application gateway serves to centralize e-mail collection and distribution to internal hosts and users. To outside users, all internal users would have e-mail addresses of the form:
user@emailhost
where emailhost is the name of the e-mail gateway. The gateway would accept mail from outside users and then forward mail along to other internal systems as necessary. Users sending e-mail from internal systems could send it directly from their hosts, or in the case where internal system names are not known outside the protected subnet, the mail would be sent to the application gateway, which could then forward the mail to the destination host. Some e-mail gateways use a more secure version of the sendmail program to accept e-mail.
5.3.1.1 Circuit-Level Gateways
[Ches94] defines another firewall component that other authors sometimes include under the category of application gateway. A circuit-level gateway relays TCP connections but does no extra processing or filtering of the protocol. For example, the TELNET application gateway example provided here would be an example of a circuit-level gateway, since once the connection between the source and destination is established, the firewall simply passes bytes between the systems. Another example of a circuit-level gateway would be for NNTP, in which the NNTP server would connect to the firewall, and then internal systems' NNTP clients would connect to the firewall. The firewall would, again, simply pass bytes.
Firewalls can be configured in a number of different architectures, provided various levels of security at different costs of installation and operation. Organizations should match their risk profile to the type of firewall architecture selected. The following sections describe typical firewall architectures and sample policy statements.
A multi-homed host is a host (a firewall in this case) that has more than one network interface, with each interface connected to logically and physically separate network segments. A dual-homed host (host with two interfaces) is the most common instance of a multi-homed host.
A dual-homed firewall is a firewall with two network interfaces cards (NICs) with each interface connected to a different network. For instance, one network interface is typically connected to the external or untrusted network, while the other interface is connected to the internal or trusted network. In this configuration, an important security tenet is not to allow traffic coming in from the untrusted network to be directly routed to the trusted network - the firewall must always act as an intermediary.
Routing by the firewall shall be disabled for a dual-homed firewall so that IP packets from one network are not directly routed from one network to the other.
A screened host firewall architecture uses a host (called a bastion host) to which all outside hosts connect, rather than allow direct connection to other, less secure internal hosts. To achieve this, a filtering router is configured so that all connections to the internal network from the outside network are directed towards the bastion host.
If a packet-filtering gateway is to be deployed, then a bastion host should be set up so that all connections from the outside network go through the bastion host to prevent direct Internet connection between the ORGANIZATION network and the outside world.
The screened subnet architecture is essentially the same as the screened host architecture, but adds an extra strata of security by creating a network which the bastion host resides (often called a perimeter network) which is separated from the internal network.
A screened subnet will be deployed by adding a perimeter network in order to separate the internal network from the external. This assures that if there is a successful attack on the bastion host, the attacker is restricted to the perimeter network by the screening router that is connected between the internal and perimeter network.
There are different implementations of firewalls, which can be arranged in different ways. The various firewall implementations are discussed below.
5.5.0 Packet Filtering Gateways
Packet filtering firewalls use routers with packet filtering rules to grant or deny access based on source address, destination address and port. They offer minimum security but at a very low cost, and can be an appropriate choice for a low risk environment. They are fast, flexible, and transparent. Filtering rules are not often easily maintained on a router, but there are tools available to simplify the tasks of creating and maintaining the rules.
Filtering gateways do have inherent risks including:
An application gateway uses server programs (called proxies) that run on the firewall. These proxies take external requests, examine them, and forward legitimate requests to the internal host that provides the appropriate service. Application gateways can support functions such as user authentication and logging.
Because an application gateway is considered as the most secure type of firewall, this configuration provides a number of advantages to the medium-high risk site:
Applications gateways require a proxy for each service, such as FTP, HTTP, etc., to be supported through the firewall. When a service is required that is not supported by a proxy, an organization has three choices:
Deny the service until the firewall vendor has developed a secure proxy - This is the preferred approach, as many newly introduced Internet services have unacceptable vulnerabilities.
Develop a custom proxy - This is a difficult task and should be undertaken only by very sophisticated technical organizations.
Pass the service through the firewall - Using what are typically called "plugs," most application gateway firewalls allow services to be passed directly through the firewall with only a minimum of packet filtering. This can limit some of the vulnerability but can result in compromising the security of systems behind the firewall.
When an in-bound Internet service not supported by a proxy is required to pass through the firewall, the firewall administrator shall define the configuration or plug that will allow the required service. When a proxy is available from the firewall vendor, the plug must be disabled and the proxy made operative.
Medium-high Risk
All in-bound Internet services must be processed by proxy software on the firewall. If a new service is requested, that service will not be made available until a proxy is available from the firewall vendor and tested by the firewall administrator. A custom proxy can be developed in-house or by other vendors only when approved by the CIO.
Hybrid gateways combine two or more of the above firewall types and implement them in series rather than in parallel. If they are connected in series, then the overall security is enhanced; on the other hand, if they are connected in parallel, then the network security perimeter will be only as secure as the least secure of all methods used. In medium to high-risk environments, a hybrid gateway may be the ideal firewall implementation.
Firewall Security Risk
| 4 | recommended choice |
| 3 | effective option |
| 2 | acceptable |
| 1 | minimal security |
| 0 | unacceptable |
| Firewall
Architecture
(if any one of these is being implemented) |
High
Risk Environment
e.g. Hospital |
Medium
Risk Environment
e.g. University |
Low
Risk Environment
e.g. florist shop |
| Packet filtering | 0 | 1 | 4 |
| Application Gateways | 3 | 4 | 2 |
| Hybrid Gateways | 4 | 3 | 2 |
Router-based firewalls don’t provide user authentication. Host-based firewalls can provide these kinds of authentication:
Username/password: This provides the lowest level of protection, because the information can be sniffed off the network or shoulder-surfed.
One-time passwords: One-time passwords using software or hardware tokens, generate a new password for each session. This means that old passwords cannot be reused if they are sniffed or otherwise borrowed or stolen.
Digital Certificates: Digital certificates use a certificate generated using public key encryption.
5.5.3.1 Routing Versus Forwarding
A clearly defined policy has to be written as to whether or not the firewall will act as a router or a forwarder of Internet packets. This is trivial in the case of a router that acts as a packet filtering gateway: the firewall (router in this case) has no option but to route packets. Applications gateway firewalls should generally not be configured to route any traffic between the external interface and the internal network interface, since this could bypass security controls. All external to internal connections should go through the application proxies.
Source routing is a routing mechanism whereby the path to a target machine is determined by the source, rather than by intermediate routers. Source routing is mostly used for debugging network problems but could also be used to attack a host. If an attacker has knowledge of some trust relationship between your hosts, source routing can be used to make it appear that the malicious packets are coming from a trusted host. Therefore, because of this security threat, a packet filtering router can easily be configured to reject packets containing source route option. Thus, a site that wishes to avoid the problem of source routing entirely would write a policy similar to the following:
IP spoofing is when an attacker masquerades his machine as a host on the target’s network (i.e. fooling a target machine that packets are coming from a trusted machine on the target’s internal network). Policy regarding packet routing has to be clearly written so that they will be handled accordingly if there is a security problem. It is necessary that authentication based on source address be combined with other security scheme to protect against IP spoofing attacks.
Password sniffing can be very simple and done with considerable ease. Encryption of passwords is a system-to-system capability IF the operating systems are a matched pair (same OS, usually same version) then the passwords are usually encrypted in a session. Perhaps the biggest problem is that users tend to use the same user ID and password on all systems they may use in a network. If one system is compromised then this leads to a compromise of all systems.
There are many public domain password "grabbers" available on the Internet. These programs are free and readily available.
DOS-based TCP-specific password grabber and filter software
Download, unpack, load drivers, grab passwords off internal nets
Flags: 0x00
Status: 0x00
Packet Length:85
Timestamp: 15:35:27.247
Filter: IP
Ethernet Header
Destination: 00:00:0c:19:99:49
Source: 00:05:a8:00:84:3b
Protocol Type:0x0800 IP
IP Header - Internet Protocol Datagram
Version: 4
Header Length: 5
Precedence: 0
Type of Service: %000
Unused: %00
Total Length: 67
Identifier: 19528
Fragmentation Flags: %010 Do Not Fragment
Fragment Offset: 0
Time To Live: 255
IP Type: 0x06 TCP
Header Checksum: 0xdde2
Source IP Address: 192.246.254.153
Dest. IP Address: 129.170.16.79
No Internet Datagram Options
TCP - Transport Control Protocol
Source Port: 2050
Destination Port: 21 FTP - File Transfer Protocol
Sequence Number: 1241405969
Ack Number: 1629760546
Offset: 5
Reserved: %000000
Code: %011000
Ack is valid
Push Request
Window: 17688
Checksum: 0xf86c
Urgent Pointer: 0
No TCP Options
FTP Control - File Transfer Protocol
FTP Command: 0x50415353 (PASS) Password
Password:
rmasey@network-1 72 6d 61 73 65 79 40 6e 65 74 77 6f 72 6b 2d 31
.com 2e 63 6f 6d
Newline Sequence: 0x0d0a
Frame Check Sequence: 0x06c1fd4a
5.5.3.5 DNS and Mail Resolution
On the Internet, the Domain Name Service provides the mapping and translation of domain names to IP addresses, such as mapping server1.acme.com to 123.45.67.8. Some firewalls can be configured to run as a primary, secondary, or caching DNS server.
Deciding how to manage DNS services is generally not a security decision. Many organizations use a third party, such as an Internet Service Provider, to manage their DNS. In this case, the firewall can be used as a DNS caching server, improving performance but not requiring your organization to maintain its own DNS database.
If the organization decides to manage its own DNS database, the firewall can (but doesn’t have to) act as the DNS server. If the firewall is to be configured as a DNS server (primary, secondary, or caching), it is necessary that other security precautions be in place. One advantage of implementing the firewall as a DNS server is that it can be configured to hide the internal host information of a site. In other words, with the firewall acting as a DNS server, internal hosts get an unrestricted view of both internal and external DNS data. External hosts, on the other hand, do not have access to information about internal host machines. To the outside world, all connections to any host in the internal network will appear to have originated from the firewall. With the host information hidden from the outside, an attacker will not know the host names and addresses of internal hosts that offer service to the Internet.
A security policy for DNS hiding might state:
If the firewall is to run as a DNS server, then the firewall must be configured to hide information about the network so that internal host data are not advertised to the outside world.
The best type of a network security setup is one that is multi tiered or layered. This type of a setup allows for built in redundancy.
A firewall, like any other network device, has to be managed by someone. Security policy should state who is responsible for managing the firewall.
Two firewall administrators (one primary and secondary) shall be designated by the Chief Information Security Officer (or other manager,) and shall be responsible for the upkeep of the firewall. The primary administrator shall make changes to the firewall and the secondary shall only do so in the absence of the former so that there is no simultaneous or contradictory access to the firewall.
5.5.4.0 Qualification of the Firewall Administrator
Two experienced people are generally recommended for the day to day administration of the firewall. In this manner availability of the firewall administrative function is largely insured. It should be required that information about each firewall administrator be written down so that he may contacting is possible in case of a problem.
Security of a site is crucial to the day to day business activity of an organization. It is therefore required that the administrator of the firewall have a sound understanding of network concepts and implementation. For instance, since most firewalls are TCP/IP based, a thorough understanding of this protocol is compulsory.
An individual that is assigned the task of firewall administration must have a good hands-on experience with networking concepts, design, and implementation so that the firewall is configured correctly and administered properly. Firewall administrators should receive periodic training on the firewalls in use and in network security principals and practices.
5.5.4.1 Remote Firewall Administration
Firewalls are the first line of defense visible to an attacker. By design, firewalls are generally difficult to attack directly, causing attackers to often target the administrative accounts on a firewall. The username/password of administrative accounts must be strongly protected.
The most secure method of protecting against this form of attack is to have strong physical security around the firewall host and to only allow firewall administration from an attached terminal. However, operational concerns often dictate that some form of remote access for firewall administration be supported. In no case should remote access to the firewall be supported over untrusted networks without some form of strong authentication. In addition, to prevent eavesdropping, session encryption should be used for remote firewall connections.
Low
Any remote access over untrusted networks to the firewall for administration must use strong authentication, such as one time passwords and/or hardware tokens.
Medium
The preferred method for firewall administration is directly from the attached terminal. Physical access to the firewall terminal is limited to the firewall administrator and backup administrator.
Where remote access for firewall administration must be allowed, it should be limited to access from other hosts on the ORGANIZATION internal network. Such internal remote access requires the use of strong authentication, such as one time passwords and/or hardware tokens. Remote access over untrusted networks such as the Internet requires end to end encryption and strong authentication to be employed.
High
All firewall administration must be performed from the local terminal - no access to the firewall operating software is permitted via remote access. Physical access to the firewall terminal is limited to the firewall administrator and backup administrator.
Firewalls should never be used as general purpose servers. The only user accounts on the firewall should be those of the firewall administrator and any backup administrators. In addition, only these administrators should have privileges for updating system executables or other system software.
To support recovery after failure or natural disaster, a firewall like any other network host has to have some policy defining system backup. Data files as well as system configuration files need to be have some backup plan in case of firewall failure.
The firewall (system software, configuration data, database files, etc. ) must be backed up daily, weekly, and monthly so that in case of system failure, data and configuration files can be recovered. Backup files should be stored securely on a read-only media so that data in storage is not over-written inadvertently and locked up so that the media is only accessible to the appropriate personnel.
Another backup alternative would be to have another firewall configured as one already deployed and kept safely so that in case there is a failure of the current one, this backup firewall would simply be turned on and used as the firewall while the previous is undergoing a repair.
To prevent unauthorized modifications of the firewall configuration, some form of integrity assurance process should be used. Typically, checksums, cyclic redundancy checks, or cryptographic hashes are made from the runtime image and saved on protected media. Each time the firewall configuration has been modified by an authorized individual (usually the firewall administrator), it is necessary that the system integrity online database be updated and saved onto a file system on the network or removable media. If the system integrity check shows that the firewall configuration files have been modified, it will be known that the system has been compromised.
It is important that the operational procedures for a firewall and its configurable parameters be well documented, updated, and kept in a safe and secure place. This assures that if a firewall administrator resigns or is otherwise unavailable, an experienced individual can read the documentation and rapidly pick up the administration of the firewall. In the event of a break-in such documentation also supports trying to recreate the events that caused the security incident.
5.5.4.6 Physical Firewall Security
Physical access to the firewall must be tightly controlled to preclude any authorized changes to the firewall configuration or operational status, and to eliminate any potential for monitoring firewall activity. In addition, precautions should be taken to assure that proper environment alarms and backup systems are available to assure the firewall remains online.
5.5.4.7 Firewall Incident Handling
Incident reporting is the process whereby certain anomalies are reported or logged on the firewall. A policy is required to determine what type of report to log and what to do with the generated log report. This should be consistent with Incident Handling policies. The following policies are appropriate to all risk environments.
Firewall logs should be examined on a weekly basis to determine if attacks have been detected.
The firewall administrator shall be notified at anytime of any security alarm by email, pager, or other means so that he may immediately respond to such alarm.
The firewall shall reject any kind of probing or scanning tool that is directed to it so that information being protected is not leaked out by the firewall. In a similar fashion, the firewall shall block all software types that are known to present security threats to a network (such as Active X and Java) to better tighten the security of the network.
Once an incident has been detected, the firewall may need to be brought down and reconfigured. If it is necessary to bring down the firewall, Internet service should be disabled or a secondary firewall should be made operational - internal systems should not be connected to the Internet without a firewall. After being reconfigured, the firewall must be brought back into an operational and reliable state. Policies for restoring the firewall to a working state when a break-in occurs are needed.
5.5.4.9 Upgrading the firewall
It is often necessary that the firewall software and hardware components be upgraded with the necessary modules to assure optimal firewall performance. The firewall administrator should be aware of any hardware and software bugs, as well as firewall software upgrades that may be issued by the vendor. If an upgrade of any sort is necessary, certain precautions must be taken to continue to maintain a high level of operational security. Sample policies that should be written for upgrades may include:
To optimize the performance of the firewall, all vendor recommendations for processor and memory capacities shall be followed.
The firewall administrator(s) shall monitor the vendor’s firewall mailing list or maintain some other form of contact with the vendor to be aware of all required upgrades. Before an upgrade of any of the firewall component, the firewall administrator must verify with the vendor that an upgrade is required. After any upgrade the firewall shall be tested to verify proper operation prior to going operational.
5.5.4.10 Logs and Audit Trails
Most firewalls provide a wide range of capabilities for logging traffic and network events. Some security-relevant event that should be recorded on the firewall’s audit trail logs are: hardware and disk media errors, login/logout activity, connect time, use of system administrator privileges, inbound and outbound e-mail traffic, TCP network connect attempts, in-bound and out-bound proxy traffic type.
5.5.4.11 Revision/Update of Firewall Policy
Given the rapid introduction of new technologies, and the tendency for organizations to continually introduce new services, firewall security policies should be reviewed on a regular basis. As network requirements changes, so should security policy.
5.5.4.12 Example General Policies
The following policy statements are only examples. They do not constitute a complete firewall policy, and even if they did, they would not necessarily apply to your organization's environment. The statements are grouped into those applicable to Low-, Medium- and High-Risk environments. Within each category, they are divided into statements targeted toward users, managers and technicians. In general, all organizations would employ at least the Low-Risk policies.
5.5.4.12.0 Low-Risk Environment Policies
All users who require access to Internet services must do so by using ORGANIZATION-approved software and Internet gateways.
A firewall has been placed between our private networks and the Internet to protect our systems. Employees must not circumvent the firewall by using modems or network tunneling software to connect to the Internet.
Some protocols have been blocked or redirected. If you have a business need for a particular protocol, you must raise the issue with your manager and the Internet security officer.
A firewall shall be placed between the ORGANIZATION’s network and the Internet to prevent untrusted networks from accessing the ORGANIZATION network. The firewall will be selected by and maintained by the Network Services Manager.
All other forms of Internet access (such as via dial-out modems) from sites connected to the ORGANIZATION wide-area network are prohibited.
All users who require access to Internet services must do so by using ORGANIZATION-approved software and Internet gateways.
All firewalls should fail to a configuration that denies all services, and require a firewall administrator to re-enable services after a failure.
Source routing shall be disabled on all firewalls and external routers (see section 0).
The firewall shall not accept traffic on its external interfaces that appear to be coming from internal network addresses (see section 0).
The firewall shall provide detailed audit logs of all sessions so that these logs can be reviewed for any anomalies.
Secure media shall be used to store log reports such that access to this media is restricted to only authorized personnel.
Firewalls shall be tested off-line and the proper configuration verified.
The firewall shall be configured to implement transparency for all outbound services. Unless approved by the Network Services manager, all in-bound services shall be intercepted and processed by the firewall.
Appropriate firewall documentation will be maintained on off-line storage at all times. Such information shall include but not be limited to the network diagram, including all IP addresses of all network devices, the IP addresses of relevant hosts of the Internet Service Provider (ISP) such as external news server, router, DNS server, etc. and all other configuration parameters such as packet filter rules, etc. Such documentation shall be updated any time the firewall configuration is changed.
When you are off-site, you may only access internal systems by using ORGANIZATION-approved one-time passwords and hardware tokens to authenticate yourself to the firewall. Any other means of accessing internal systems is prohibited.
Manager
Strong authentication using ORGANIZATION-approved one-time passwords and hardware tokens is required all remote access to internal systems through the firewall.
The network security policy shall be reviewed on a regular basis (every three months minimum) by the firewall administrator(s) and other top information (security) managers. Where requirements for network connections and services have changed, the security policy shall be updated and approved. If a change is to be made, the firewall administrator shall ensure that the change is implemented and the policy modified.
The details of the ORGANIZATION internal trusted network should not be visible from outside the firewall.
The firewall will be configured to deny all services not expressly permitted and will be regularly audited and monitored to detect intrusions or misuse.
The firewall shall notify the system administrator in near-real-time of any item that may need immediate attention such as a break-in into the network, little disk space available, or other related messages so that an immediate action could be taken.
The firewall software will run on a dedicated computer - all non-firewall related software, such as compilers, editors, communications software, etc., will be deleted or disabled.
The firewall will be configured to deny all services not expressly permitted and will be regularly audited and monitored to detect intrusions or misuse.
All non-business use of the Internet from ORGANIZATION systems is forbidden. All access to Internet services is logged. Employees who violate this policy are subject to disciplinary action.
Your browser has been configured with a list of forbidden sites. Any attempts to access those sites will be reported to your manager.
All non-business use of the Internet from ORGANIZATION systems is forbidden. All access to Internet services is logged. Employees who violate this policy are subject to disciplinary action.
All access to Internet services is logged. Summary and exception reports will be prepared for the network and security managers.
| Purpose | Protocols | What | Why |
| Users have a single external email address | Does not reveal business info. | ||
| SMTP | A single server or cluster of servers provides email service for organization | Centralized
email is easier to maintain.
SMTP servers are difficult to configure securely. |
|
| POP3 | POP users must use AUTH identification. | Prevents password sniffing. | |
| IMAP | Groups are encouraged to transition to IMAP. | Better support for travel, encryption. | |
| USENET news | NTTP | blocked at firewall | no business need |
| WWW | HTTP | directed to www.my.org | Centralized
WWW is easier to maintain.
WWW servers are difficult to configure securely. |
| * | all others | routed |
5.5.4.14
Service Policies Examples
|
|
|||||
|
|
|
|
|
||
| Status |
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
An organization may wish to support some services without using strong authentication. For example, an anonymous FTP server may be used to allow all external users to download open information. In this case, such services should be hosted outside the firewall or on a service network not connected to corporate
networks that contain sensitive
data. The table that follows summarizes a method of describing such policy
for a service such as FTP.
Table 1 - Summarized Security Policy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5.5.5 Client and Server Security in Enterprise Networks
5.5.5.0 Historical Configuration of Dedicated Firewall Products
In today’s network security firewall marketplace, the most common firewall configuration is the use of a dedicated firewall system between an "untrusted" network and the corporate network, usually referred to as the "trusted" side of the firewall.
5.5.5.1 Advantages and Disadvantages of Dedicated Firewall Systems
A dedicated firewall has distinct performance and security advantages. First off, you gain total performance of the system dedicated to the function of firewall services (if nothing else is on the system, there is nothing else for the firewall software to compete with for CPU access). Second, a dedicated firewall system helps increase security of the firewall itself as the number of privileged users who have access to the firewall system are much less than other systems and are usually carefully screened so that those individuals who do have access to the firewall are in positions of trust within the company. Finally, any other software which runs on a firewall that is NOT the firewall software or the operating environment puts the firewall at risk simply due to failures of the software "killing" the firewall, other software creating system security holes, software bugs and errors in non-firewall software "opening" up the system in some manner or other such problems. The less amount of software on a firewall, the better for performance and firewall security.
Dedicated firewalls have their disadvantages as well. Many are based on the UNIX operating system or its variants which are not known for their "user friendliness." While many vendors have strived to put a graphical interface on their firewall products when running under the UNIX environments, most still rely on UNIX properties to help make the firewall work and this requires anywhere from minimal UNIX skills to expert-level UNIX skills to configure and manage the firewall system.
Another problem with UNIX systems as firewalls is the availability of source code for the UNIX environment. While there are valid arguments for such availability, there are as many arguments against as if a "good" consumer can read the source code and discover how something works, so can an "evil" attacker who wants to attack a UNIX-based firewall system or systems being protected in the UNIX environments.
Some of the problems associated with a UNIX firewall have to do with the availability of in-house expertise and the logistics of getting a UNIX system set-up properly to be a firewall system. It is no coincidence that most UNIX-based firewalls require a customized version of the UNIX environment being used to patch and control system security "holes" that may be used by an attacker to gain access. Then there is the definition and management of the UNIX system for firewall operations which usually require UNIX-specific management commands and facilities as well as the "tightening up" of the UNIX environment to close commonly used network and system interfaces. In many UNIX-based firewalls, firewall rule bases require the writing of either UNIX shell scripts or scripts in the perl language to provide firewall functionality. While companies who make such products will argue towards their approach, and there is nothing wrong with that, there is a certain amount of UNIX-based work that must happen on any UNIX-based firewall to make it work correctly and to manage the computational environment properly.
Even in the case of non-UNIX dedicated firewall systems, such as FireWall/Plus™ for MS-DOS, there is the non-flexibility of using the system for other system functions. This is a double-edged sword as there is the conflict between the "don’t put anything on the firewall but firewall software" crowd and the "we have to use all equipment to its fullest potential as this is a small site and we can’t afford a dedicated firewall box" crowd. Both have valid points, but true firewall functionality means security first - not last.
Dedicated firewalls which are, in
fact, router systems with filters in them have many of the same concerns
as a dedicated firewall running other applications at the same time. Firewall
functions are different than routing functions. By putting both functions
in the same hardware processor system, either function could "kill" the
other function at a maximum or cause problems and security holes at a minimum
- just like a firewall which runs other applications at the same time.
There are plenty of CERT and CIAC alerts issued over the last few years
on router vendors for their firewall filtering failures which were due
to bugs or problems in the routing facilities which allowed the firewall
function in the router to either be bypassed or breached. Having a dedicated
router with screening functions is ONE layer in a properly defined network
security set up. Network security means multiple layers of protection and
putting all the protection facilities in a singular router/firewall combination
means that if the unit is breached, there is an entire trusted network
to attack with no other warning or security mechanism.
5.5.5.2 Are Dedicated Firewalls A Good Idea?
Security wise, an emphatic yes - for the reasons previously mentioned and plenty more. But, to satisfy tight budgets and management who do not understand the true requirements for security systems, it is more and more common to use a firewall system as a multi-function computer where firewall functionality is one component of the system. But even dedicated security firewalls are not a total network solution - they remain a single level in security management of network environments. True, functional network security must be a layered approach and use different types of security technologies to ensure proper control over data as it moves around any network between systems.
5.5.5.3 Layered Approach to Network Security - How To Do It
As an example, system vulnerability to attack is greater when only a firewall is used with no router filters on an Internet connection (the padlock symbol indicates a security layer function).:
In the above configuration, if an attacker were to get "around" the firewall system, the server is vulnerable to attack from the network.
Adding screening filters for incoming packets into a router adds another layer to the network security architecture:
At this point, the security manager would be wise to insert some duplicate security rules into the router filter rule base and the firewall security rule base for some of the more important security functions. This would allow detection of a first-layer breach of the router by security facilities in the firewall. For instance, if a TELNET filter were placed in the router that denied all TELNET access, this would supposedly stop TELNET functions from arriving to the firewall system. If the firewall also had filters in it denying a TELNET connection from the untrusted Internet side of its connections, then if a TELNET connection should arrive, the security manager knows immediately that something very ugly has happened in the router for the TELNET attempt to even reach the firewall and it’s time to find out what is going on in the router.
Putting filters in a screening router has the following effects to the security hierarchy:
There are situations where using network security firewall software on an active client or server system acts as another security layer in the implementation of a layered network security architecture. This concept, while functionally similar in implementation to the shared system-firewall concepts previously explored, is not the same from a security rule base situation and from a performance situation. Further, this concept is different in that the security threat is lesser in this configuration as it is predisposed that there is a real firewall in the network path BEFORE the system being accessed (running network security firewall software) that has pre-screened connection facilities coming towards the client or server. Adding server-based network security firewall software allows a final layer of network security prior to reaching the server operating environment:
By putting network security into the corporate environment as a layered methodology, different levels of security (depending on the criticality of a component to the company) are possible throughout the network. Further, while external security is indeed needed and essential, the bulk of network attacks actually happen from internal entities (over 80% in some studies) that actually are a part of the corporate resource list.
In the above configuration, there are at least four layers of network security before the server’s operating assets are accessed. This is far superior to a singular network layer solution as is usually implemented via a singular dedicated firewall or through the use of a screening router as the firewall. Additional network security layers may be added via authentication facilities, encryption, digital signatures and other security methods that are used in the various layers of network protocols (including applications). Oddly enough, properly implemented many network security methods may be added in such a manner as to be transparent to the user’s activities as long as the user is attempting to access authorized systems and facilities.
With a layered network defense environment
the chances of actual network attacks getting to sensitive data are greatly
minimized and the opportunities to detect inappropriate security behavior
before it reaches a significant asset are greatly improved.
5.5.5.4 Improving Network Security in Layers - From Inside to Outside
Another improvement in the layered network security approach is that of keeping sensitive assets "in" instead of just keeping attackers "out" of asset collections (such as file or database servers). Firewalls and security filtering facilities work not only with incoming requests, but also with outgoing requests. A typical "trusted" attack on a server might be to set up a program which initiates a file transfer from the server to an untrusted entity during off-hours. In this case, many companies might not think anything of the activity as a) they probably are not monitoring for it and b) not many companies think of their systems as voluntarily moving data from the trusted side unassisted by a connection from the untrusted side of a network connection hierarchy. Proper network security is a bi-directional effort - not just from outside to inside, but inside to outside as well.
5.5.5.5 Operating Systems and Network Software - Implementing Client and Server Security
System security on a client or server system is the function of the following general items:
5.5.5.6 Operating System Attacks From the Network Resource(s) - More Protocols Are The Norm - and They Are Not Just IP
Network security firewalls provide a "bottleneck" facility at strategic points on the network to prevent wholesale attacks of systems on a network. It’s pretty common practice to put a firewall facility between known troublesome networks such as Internet. Oddly enough, most companies do not implement firewall facilities between different company divisions, "sister" company network connections, customer network connections and other 3rd party or vendor supplied network connections. The funny part is that most of the documented network break-ins are from the non-Internet connections (although the Internet break-ins are accelerating). The other problem is that on practically all corporate networks, the protocol environment is multi-protocol; IP is not all that is used by any stretch of reality. In most established networks, the predominant protocols are Novell’s IPX, LAN Manager/LAN Server/Pathworks NetBEUI and Apple Computer’s AppleTalk. In mainframe environments there is a predominance of SNA-related protocols and in the mid-range environment other protocols such as DECnet, LAT, various hardware-specific protocols and many non-IP protocols. In short, the standard company environment most operating environments must function within are not just IP - they’re a lot of every type of protocol you can find. Most corporate networks operate between 6-8 protocol suites in addition to an IP environment.
Preventing a network attack to an operating system resource, especially with the fact that most attacks are inside jobs, requires security for ALL protocols, not just IP. In a trusted network environment on most non-UNIX servers, IPX and NetBEUI reign supreme as do other non-IP protocols and any of these may be used to gain access to a server and thusly attack the server.
5.5.5.7 Client Attacks - A New Threat
For a while, network security defenses have concentrated on keeping attackers at bay from servers of various shapes and sorts. The problem, especially in the last three years, has shifted towards client-side connections as well.
With Apple Computer’s MacOS V7.1 and later versions, AppleTalk protocol was included in all versions of the operating system with functionality to not only access servers, but also to allow the client to publish itself as a disk service in a network and allow other clients to access the disk services. This is called peer-to-peer access as there is no intermediary system required for the connection to be made and maintained. Other vendors, noticeably Microsoft, have followed suit and included peer-to-peer services in their operating systems when shipped for consumption.
In Windows-95 and Windows-NT, protocol stacks for NetBEUI (a connection-less protocol which was originally used in LAN Manager), IPX (for accessing Novell NetWare servers) and IP (for use with TCP/IP savvy applications) are included at no extra charge as are various popular applications, such as web browsers and file sharing software, to make use of the various protocols. It is, therefore, very common and normal to find many protocols active on a trusted intranet. Now, however, many of the disk services or printer sharing services may well be based on a client system and not a dedicated server.
In the very near future (beginning in late 1996), high-speed residential connections will be more and more popular. The author has been directly involved in using a 7mbps connection from his home to the Internet for $19.95 per month via the local cable television network. This connection "looks" like a standard Ethernet connection (it even provides a standard RJ45 UTP connection on the set-top box connection to the cable broadband network) and even works like one with the client software. It also means that it was a trivial matter for the author to load up protocol analysis software on his workstation client and see, quite literally, activity on the cable television network by other persons in the neighborhood including Internet Service Provider (ISP) passwords by other users, files being transferred and popular locations that other neighbors access on the network. Therefore, there is basically NO security when all traffic can be seen in the clear on the network by nodes using the network.
5.5.5.8 Telecommuting Client Security Problems - Coming to Your Company Soon
Obviously, this is a considerable security problem brewing considering that telecommuting is rapidly becoming the norm and high-speed network connections via cable television networks, Asymmetric High Speed Links (ADSL) and other technologies will be the normal mode of connection in the future. Some studies suggest that over 60% of information-related jobs will telecommute over 40% of the week by the year 2000, so this is a problem that will accelerate - rather quickly. A typical dial-in or ISDN telecommuter connection path is as follows:
For telecommuters, the need to support more than IP will also be the norm. Companies are adding IP generously to their internal systems, but they are also keeping protocols they have invested in for some time such as IPX, AppleTalk and NetBEUI. Therefore, for some considerable timeframe, the need to support IP and other protocols for telecommuting will be required in most corporate environments.
As telecommuting becomes more prevalent, telecommuters will keep more sensitive corporate information at their residences. This increases the overall security threat to the company as information deemed sensitive can now be accessed outside the physical perimeter of the corporate campus and the handful of allowed remote access facilities currently in place. Since client computers hooked to networks, like cable television, become "information appliances" due to their being continually network connected, they will be subjected to systematic network attacks no differently than corporate networks connected to any untrusted network. A typical cable TV connection methodology would appear as:
Since most client computers do not include the ability to provide a firewall facility in the client remote or residential computer, the chances of being attacked when connected to public high-speed networks is extremely good as well as having a high potential for success. A 1996 U.S. General Accounting Office report showed over 240,000 attempts at attacking the U.S. Department of Defense (DoD) unclassified networks and they suggested that over 64% of the attacks were successful. It is well known that the DoD takes security very seriously. So, what is going to happen to the potential millions of telecommuters who connect to their office facilities with no network security facilities and who leave their home-based systems on all day while at the office and also while connected to the high-speed network provided by the cable television vendor? Free-lance attacks will be the norm and easily accomplished.
5.5.5.9 Compromising Network Traffic - On LANs and Cable Television It’s Easy
To simplify the matter, the chances of collecting data on in-path transactions on the Internet via a dial-up connection requires some specific levels of expertise. In the case of connections to cable television, very inexpensive or "free" network analysis software is available for PC and Macintosh systems and can allow the connection’s data to be viewed in ASCII and sensitive information freely seen.
It should be noted that on intranets, most other protocols do not have encryption as well and those who do usually only use the encryption function for session establishment or, in the case of Novell Netware, for password security. The problem is that for some devices, such as Netware-aware printers, encryption is not always supported for passwords so it is commonly disabled to allow users access to printers. Just because a security feature exists does not mean that it is used properly or at all.
On corporate enterprise networks,
it is the norm for the users to have a common format for user ID’s and
passwords to keep them from being too confused when accessing many different
systems and servers. Therefore securing one protocol is not good enough.
If the user accesses another network system using the same user ID and
password as is used on an encrypted protocol session and the second protocol
is unencrypted, then the password is compromised even for the encrypted
session. To properly protect network connectivity, all protocols must be
encrypted for all transactions and then all packets must be controlled
(firewalled) when they arrive at the destination to keep users from accessing
sensitive information and to protect the user’s client system integrity.
5.5.5.10 Encryption is Not Enough - Firewall Services Are Needed As Well
Even in those situations where encryption capabilities have been introduced into client systems via encryption MODEMs or via software facilities in a specific protocol, this does not solve the end-to-end network security problem. Encryption is very good for authentication of a specific remote entity and is also very good for "hiding" any transaction over the network from observers of the traffic being transferred. The problem is that encryption is very much like giving someone you trust the keys to your house in such a manner that no one can see your friend accessing your house and no one can see what your friend is doing between his/her house and your house. This is good. What is not so good is that encryption does not stop a trusted user from still attacking the destination system’s services that are offered. For instance, encryption may ensure that only corporate users get access to a system but encryption does not restrict, to a very fine degree, what a trusted user may be allowed to access and extract from the server. It’s very much like letting someone you trust in the front door and not placing any restrictions on where someone is allowed to go in the house and what they are not allowed to deliver or remove from the house.
Firewall facilities, at the destination or the source of a network session, when used with encryption facilities add the additional filtering and security controls that are needed for network security on a client or a server. Encryption ensures that the connection is allowed and protected from observation. Firewall facilities on the client or server restrict where incoming or outgoing connections can access data on entities on the client or server. By setting up specific firewall rule bases on the client and server in addition to encryption software, the security manager can properly protect system resources from systematic and asymmetric network attacks.
5.5.5.11 Multiprotocol Security Requirements are the Norm - Not the Exception. Even for Singular Protocol Suites...
On corporate intranets, IP is not the only protocol used. Therefore, any network security solution that is used must include support for any corporate protocol. Further, any remote solutions must provide support for whatever protocol is required to access the corporate facilities plus supply facilities for any cooperative protocol to be passed over the connection link (this is typically called "tunneling").
Even if IP is decided to be the main corporate protocol now and in the future, it is a known fact that IP will get periodic lobotomies to support additional network types, addressing types, applications and other technological changes. This means that the need to run the "old" version of IP and the "new" version of IP at the same time on the same systems is highly likely while conversions are in progress on any network. Any network manager can tell you horror stories about converting from one version to another version of practically any protocol. And, practically without exception, most companies want to run the new version and the old version at the same time during testing before going to the new version due to potential problems and outages that happen with any new protocol environment. Therefore, any protocol security solution must be multiple protocol capable - even if it is only for the same protocol suite and is required to run multiple versions of the same protocol suite.
5.5.5.12 Protecting Clients and Servers on Multiprotocol Networks - How to Do It
So, how do you protect a server or client from network attack on the trusted, multiprotocol network? How do you protect remote clients that are used by telecommuters from localized attack or asymmetric attacks from other sources on a public-accessible network?
With the proper network security architecture, there are some basic, major elements required on each and every system to make such a feat work:
5.5.5.13 New Firewall Concepts - Firewalls with One Network Connection
Historically, firewall systems filter data from an untrusted network to/from a trusted network. With the need for end-to-end security, there is a need to provide the functionality of a firewall with VPNs at the workstation and singly-connected server level. In this scenario, the firewall software treats the singular network connection on a node as the untrusted side of the network and the node itself as the trusted side of the network. Any connection going out of the client or server is considered to be a trusted connection. A general hardware connection diagram would be as follows:
Architecturally, the connection path for applications utilizing a singular network interface firewall system would appear as follows:
In the above architecture, both the client and the server treat all incoming connections through their internal firewall facilities as "untrusted." All outgoing connections are considered as sourced from the "trusted" side.
Section References
5.0 Wack, John P. and Carnahan Lisa J., Keeping Your Site Comfortably Secure: An Introduction to Internet Firewalls. NIST Special Publication 800-10, U.S. Dept of Commerce.
5.5.4 Guttman, Barbara and Bagwill, Robert. Implementing Internet Firewall Security policy. Nist Special Publication 800-XX. U.S Dept of Commerce. April 1998.
5.5.5 Hancock, William M. Intranet
Firewalls (Presentation). Network-1 Software and Technology, Inc.1997-8.