Firewalls

  

The purpose of a firewall is to provide a single choke point to block out unwanted packets from possible attackers of an organization's system. A choke point is where many packets must enter to get routed into the organization's LANs. In most cases, a firewall is an addition to the gateway, or entry router, into an organization's network systems. The best way to understand an organization's network topology is to understand that there may be many choke points into a system. An organization's topology with three routers might look like the one in Figure 21-11.

click to expand
Figure 21-11: A organization's LAN example

Notice in Figure 21-11 that there are three routers and there is no single choke point. In this example, there is nothing to prevent rogue packets from getting routed to the appropriate machines if the port and address matches for the services running the protocols.

In this scenario, the only way to prevent hackers from accessing the services is the security of the services themselves . For instance, the authentication in FTP prevents the hacker from logging in.

However, one issue with the FTP service is that if the "anonymous" user is accessible and the security is relaxed on the files on that machine, then those files are easily attainable. In addition, the operating system running on each individual box is also susceptible to intrusion for any security that is not tightly managed.

To avoid this security issue, establish a single choke point that all packets must enter. Figure 21-12 illustrates a firewall as a single point of contact that all packets must enter and exit into the untrusted Internet. All the packets that now work with the routers are assumed to be trusted and not a threat to attack the machines in the organization's domain.

click to expand
Figure 21-12: Firewall

The firewall that communicates directly with the outside Internet is normally termed a Bastion Host . Because the Bastion Host is exposed to the Internet, its security must be kept high. Many Bastion Hosts are administered remotely by telneting into them and configuring the internal files. The operating system and any administration tools must be accessible only by the administrators in the organization or the Bastion Host becomes a security concern. The firewall can protect the internal domain by filtering and blocking packets that may be questionable. There are three ways in which a firewall can filter out unwanted attacks: by acting as a circuit-level gateway, by acting as an application-level gateway, and through packet filtering. These concepts are discussed in the following sections.

Circuit-level gateway

The purpose of circuit-level gateways is to relay TCP connections, and they act as a proxy at the Transport Layer. The sender connects to a TCP port on the gateway, which connects to some destination on the other side of the gateway. During the operation, the circuit-level gateway program moves the data bytes back and forth between endpoints. The gateway is called circuit based because it behaves as a circuit, relaying bytes back and forth as if it was hardware.

A circuit-level gateway can be a standalone system or it can be a function performed by an application-level gateway for certain applications. A circuit-level gateway does not permit an end-to-end TCP connection; rather, the gateway sets up two TCP connections, one between itself and a TCP user on an inner host, and one between itself and a TCP user on an outside host. Once the two connections are established, the gateway typically relays TCP segments from one connection to the other without examining the contents. The security function consists of determining which connections will be allowed.

A typical use of circuit-level gateways is a situation in which the system administrator trusts the internal users. The gateway can be configured to support application-level or proxy service on inbound connections and circuit-level functions for outbound connections. In the configuration, the gateway can incur the processing overhead of examining incoming application data for forbidden functions but does not incur that overhead on outgoing data.

The protocol described here is designed to provide a framework for client-server applications in both the TCP and UDP domains to conveniently and securely use the services of a network firewall. The protocol is conceptually a "shim-layer" between the Application Layer and the Transport Layer, and as such does not provide network-layer gateway services, such as forwarding of ICMP messages.

Circuit gateways operate at the Network Transport Layer. Again, connections are authorized based on addresses. Like filtering gateways, they (usually) cannot look at data traffic flowing between one network and another, but they do prevent direct connections between one network and another.

Application-level gateway

Another type of firewall is having special-purpose code for each application. This handles traffic at the Application Layer. An application gateway, also called a proxy server, acts as a relay for application-level traffic. The user contacts the gateway using a TCP/IP application, such as Telnet or FTP, and the gateway asks the user of the remote host to be accessed. When the user responds and provides valid user and authentication information, the gateway contacts the application on the remote host and relays TCP segments containing the application data between the two endpoints. If the gateway does not implement the proxy code for a specific application, the service is not supported and cannot be forwarded across the firewall. Further, the gateway can be configured to support only specific features of an application that the network administrator considers acceptable while denying other features.

Application-level gateways tend to be more secure than packet filters. Rather than trying to deal with the numerous possible combinations that are allowed and forbidden at the TCP and IP level, the application-level gateway need only scrutinize a few allowable applications. In addition, it is easy to log and audit all incoming traffic at the application level.

A prime disadvantage of this type of gateway is the additional processing overhead on each connection. In effect, there are two spliced connections between the end users, with the gateway at the splice point; and the gateway must examine and forward all traffic in both directions.

Packet filtering

Packet filtering can normally be encompassed as part of a router. The purpose of packet filtering is simply to block questionable packets. The router can sniff these by the IP header, TCP header, UDP header, ICMP header, and more. Packet sniffing is the process of examining the packet to see what it contains. The formats of the IP header and the rest of the headers are well known. The data can also be read if it is not encrypted, and what the packet is trying to accomplish can be understood .

Since the packet has to get routed to the organization's domain, it can be intercepted through a program and examined. Installing a Bastion Host centralizes where the interception can be done before entering the organization's domain. Some of the fields that can be easily examined are ports and addresses, and any data that is plaintext can also be examined to try to understand the protocol. Common parenting software works this way by examining the data and ensuring that anything containing "XXX" will be blocked.

Organizations can easily sniff the data to learn what their employees are surfing the Web for, and many people might consider this an invasion of privacy. However, packets that are being transported across the Internet could be sniffed at any point during transport. For example, by looking at the data and the SYN flag of the TCP packet, a firewall can examine the "GET /index.html" and assume that the protocol is HTTP; next the firewall verifies that the destination port is port 80. If the destination address is any address except the domain's HTTP server, the firewall can deny that packet.

The sender of the packet receives a "destination unreachable" or a "Communication with destination host is administratively forbidden" message in a formatted ICMP reply packet depending on the configuration and the firewall. The same rules apply for the organization's internal domain. A user in the domain could try to reach a host that the organization deems untrustworthy. The firewall can deny a connection by sniffing the destination address for outgoing packets and returning a deny to the user. Most firewalls should be configured to log discrepancies to know whether an attacker is trying to access the system.

The users of the domain can also get logged at the firewall; using this strategy, a person within the organization accessing a competitor's system or sending them e- mails could be logged. To understand how a packet filter might be set up to deny service for an HTTP service, look at the configuration shown in Figure 21-13. In this example, any inbound TCP packets originating outside the firewall above port 1023 directed to a machine in the domain using port 80 as an initial SYN, meaning no ACK, will be denied. Also, any originating TCP packets from the domain on port 80 going out the firewall to a port above 1023 with an ACK, meaning a reply, will be denied .

click to expand
Figure 21-13: Firewall configurations

These configurations are just some ways, without even examining the data, to deny access to any HTTP server from the domain to the Internet that works on port 80. The configuration denies any service that meets the rules specified for the configuration. If you want a single machine to have an HTTP server, you could specify to allow packets specific to that destination address within the domain.

This situation does resolve a lot of issues, however in enterprise computing the concept exists that enterprise data must go through the appropriate services to initiate requests . This concept chains a request through more than one firewall and is commonly known as a de-militarized zone (DMZ).

  


Java Security Solutions
Java Security Solutions
ISBN: 0764549286
EAN: 2147483647
Year: 2001
Pages: 222

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net