TYPES OF
FIREWALLS
A firewall may act as a packet filter. It can operate as a
positive filter, allowing to pass only packets that meet specific criteria, or
as a negative filter, rejecting any packet that meets certain
criteria. Depending on the type of firewall, it may examine one or more protocol
headers in each packet, the payload of each packet,
or the pat- tern generated by a sequence of packets. In this section,
we look at the principal types of firewalls.
Packet Filtering Firewall
A packet filtering firewall applies a set of
rules to each incoming and outgoing IP packet
and then forwards
or discards the packet (Figure
22.1b). The firewall is typi-
cally configured to filter packets going in both directions (from and to the internal network). Filtering rules are
based on information contained in a network packet:
•
Source IP address: The IP address
of the system that originated the IP packet (e.g., 192.178.1.1)
•
Destination IP address: The IP address
of the system
the IP packet
is trying to reach
(e.g., 192.168.1.2)
•
Source and destination transport-level address: The transport-level (e.g., TCP or UDP) port number,
which defines applications such as SNMP or TELNET
•
IP protocol field: Defines the transport protocol
•
Interface: For a firewall
with three or more ports,
which interface of the fire- wall the packet came from or which interface of the firewall
the packet is des-
tined for
The packet filter
is typically set up as a list of rules
based on matches
to fields in the IP or TCP
header. If there is a match to one of the rules, that rule is invoked to determine whether to forward
or discard the packet. If there is no match to any rule, then a default
action is taken.
Two default policies are possible:
•
Default = discard: That which is not
expressly permitted is prohibited.
•
Default = forward: That
which is not expressly prohibited is permitted.
The default discard policy is more conservative.
Initially, everything is blocked, and services must be added on a case-by-case
basis. This policy is more visible to users, who are more likely to see the
firewall as a hindrance. However, this is the policy likely to be preferred by
businesses and government organiza- tions. Further, visibility to users
diminishes as rules are created. The default for- ward policy increases ease of
use for end users but provides reduced security; the security administrator
must, in essence, react to each new security threat as it becomes known. This
policy may be used by generally more open organizations, such as universities.
Table 22.1, from
[BELL94b], gives some examples of packet filtering rulesets. In each set, the
rules are applied top to bottom. The
“*” in a field is a wildcard
designator that matches everything. We
assume that the default = discard policy is in force.
A.
Inbound mail is
allowed (port 25 is for SMTP incoming), but only to a gateway host. However,
packets from a particular external host, SPIGOT,
are blocked because that host has a history of sending massive files in
e-mail messages.
B.
This is an explicit statement
of the default policy.
All rulesets include
this rule implicitly as the last rule.
C.
This ruleset is intended to specify
that any inside
host can send mail to the out- side. A TCP packet with a destination port of 25 is routed
to the SMTP server on the destination machine. The problem with this rule is that the use of port 25 for SMTP
receipt is only a default; an outside
machine could be configured to have some
other application linked to port 25. As this rule is written, an attacker
could gain access to internal
machines by sending
packets with a TCP source port num- ber of 25.
This ruleset achieves
the intended result that was not achieved
in C. The rules
take advantage of a feature of TCP connections. Once a connection is set up, the ACK flag of a TCP segment is set to acknowledge segments sent from the other side. Thus, this ruleset states that it allows
IP packets where the source IP address is one of a list of designated internal hosts and the destination TCP port number is
25. It also allows incoming packets with a source
port number of 25 that include
the ACK flag in the TCP segment. Note that we explicitly designate source and
destination systems
to define these rules explicitly.
D.
This ruleset
is one approach to handling FTP
connections. With FTP, two TCP
connections are used: a control connection to set up the file transfer and a data connection for the actual file transfer. The data connection uses a different port number that is dynamically assigned for the transfer. Most servers,
and hence most attack targets, use low-numbered
ports; most outgoing calls tend to use a higher-numbered port,
typically above 1023. Thus, this ruleset allows
—
Packets that originate internally
—
Reply packets to a connection initiated by an internal machine
—
Packets destined for a high-numbered port on an internal machine
This scheme requires that the systems be configured so that only the appropriate
port numbers are in use.
Rule set E points out the difficulty in dealing with applications at the packet- filtering level. Another way to deal with FTP and similar
applications is either state-
ful packet filters or an application-level gateway, both
described subsequently in this
section.
One advantage of a packet filtering firewall
is its simplicity. Also, packet filters typically are transparent to users and
are very fast. [WACK02] lists the following weaknesses of packet filter
firewalls:
•
Because packet
filter firewalls do not examine upper-layer data, they cannot prevent attacks
that employ application-specific vulnerabilities or functions. For example,
a packet filter firewall cannot block
specific application commands;
if a packet filter firewall allows a given application, all functions available
within that application will be permitted.
•
Because of the limited
information available to the firewall,
the logging func- tionality present in packet filter firewalls
is limited. Packet
filter logs normally contain the same information used
to make access control decisions (source address, destination address, and traffic type).
•
Most
packet filter firewalls do not support
advanced user authentication schemes.
Once again, this limitation is mostly due to the lack of upper-layer
functionality by the firewall.
•
Packet filter
firewalls are generally vulnerable to attacks and exploits that take advantage of problems within the TCP/IP specification and protocol
stack, such as network layer
address spoofing. Many packet filter firewalls cannot detect a network packet in which the OSI Layer 3 addressing informa- tion has been altered.
Spoofing attacks are generally employed
by intruders to bypass
the security controls
implemented in a firewall platform.
Finally, due to the small
number of variables used in access
control decisions, packet filter
firewalls are susceptible to security breaches
caused by improper configurations. In other words,
it is easy to accidentally configure a packet
filter firewall to allow traffic types, sources, and destinations that
should be denied based on an organization’s information security policy.
Some of the attacks that can be made on
packet filtering firewalls and the appropriate countermeasures are the
following:
•
IP address spoofing: The intruder transmits
packets from the outside with a source IP address
field containing an address of an internal
host. The attacker
hopes that the use of a spoofed
address will allow penetration of systems that employ simple source address
security, in which packets
from specific trusted internal hosts are accepted. The countermeasure
is to discard packets with an inside source address
if the packet arrives on an external
interface. In fact,
this countermeasure is often
implemented at the router external
to the firewall.
•
Source routing attacks: The source station
specifies the route that a packet should take as it crosses
the Internet, in the hopes
that this will bypass security measures that do not analyze the
source routing information. The counter- measure is to discard
all packets that use this option.
•
Tiny fragment attacks: The intruder uses the IP fragmentation option
to create extremely small fragments and force the TCP header information into a sepa- rate packet fragment. This
attack is designed
to circumvent filtering rules that depend on
TCP header information. Typically, a
packet filter will make a fil- tering decision on the first fragment of a packet.
All subsequent fragments
of that packet are filtered out solely on the basis that they are part
of the packet whose first fragment
was rejected. The attacker
hopes that the filtering firewall examines only the first
fragment and that the remaining fragments are passed through. A tiny fragment attack
can be defeated by enforcing a rule that the first
fragment of a packet must contain a
predefined minimum amount of the transport header. If the first
fragment is rejected, the filter can remember the packet and discard
all subsequent fragments.
Stateful Inspection Firewalls
A traditional packet filter makes filtering
decisions on an individual packet basis and
does not take into consideration any higher layer
context. To understand what is
meant by context and why a
traditional packet filter is limited with regard to con- text, a little background is needed. Most
standardized applications that run on top of TCP follow a client/server
model. For example, for the Simple Mail Transfer Protocol (SMTP),
e-mail is transmitted from a client system to a server system. The client system generates new e-mail messages,
typically from user input. The server system accepts incoming e-mail messages
and places them in the appropriate user mailboxes.
SMTP operates by setting up a TCP connection between client and server, in which the TCP server port number,
which identifies the SMTP server
application, is 25. The TCP
port number for the SMTP client is a number
between 1024 and 65535 that is generated by the SMTP client.
In general, when an application that uses TCP creates a session with a remote host, it creates a TCP connection
in which the TCP port number for the remote (server) application is a number
less than 1024 and the TCP port number for the local (client) application is a number between
1024 and 65535.
The numbers less than 1024
are the “well-known” port numbers and
are assigned permanently to particular applications (e.g., 25 for server
SMTP). The numbers between
1024 and 65535
are generated dynamically and have temporary significance only for the
lifetime of a TCP connection.
A simple packet filtering firewall must
permit inbound network traffic on all
these high-numbered ports
for TCP-based traffic
to occur. This creates a vulnerabil-
ity that can be exploited by unauthorized users.
A stateful inspection packet firewall
tightens up the rules for TCP traffic by creating a directory of outbound TCP connections, as shown in Table 22.2. There
is an entry for each currently established connection. The packet
filter will now allow
incoming traffic to high-numbered ports only for those packets
that fit the profile of one
of the entries in this directory.
A stateful packet inspection firewall
reviews the same packet information as a packet filtering firewall, but also
records information about TCP connections (Figure 22.1c). Some stateful
firewalls also keep track of TCP sequence
numbers to prevent attacks
that depend on the sequence number, such
as session hijacking. Some even inspect limited amounts
of application data for some well-known protocols like FTP, IM and SIPS commands,
in order to identify and track related
connections.
Application-Level Gateway
An application-level gateway, also called an
application proxy, acts as a relay of application-level
traffic (Figure 22.1d). The user contacts the gateway using a TCP/IP application, such as
Telnet or FTP, and the gateway asks the user for the name of the remote
host to be accessed. When the user responds and provides a valid user ID 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
Table 22.2 Example Stateful Firewall Connection State Table [WACK02]
an application that the network
administrator considers acceptable while denying all 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 to be 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.
Circuit-Level
Gateway
A fourth type of firewall is the
circuit-level gateway or circuit-level proxy (Figure 22.1e). This can be a stand-alone system or it can
be a specialized func- tion performed by an application-level gateway for
certain applications. As with an application gateway, 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 admin- istrator trusts the internal
users. The gateway can be configured to support applica- tion-level or proxy service on
inbound connections and circuit-level functions for outbound connections. In this
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.
An example of a circuit-level gateway implementation is the SOCKS package
[KOBL92]; version 5 of SOCKS
is specified in RFC 1928.
The RFC defines SOCKS in the following fashion:
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.
SOCKS consists of the following components:
•
The SOCKS server,
which often runs on a UNIX-based firewall. SOCKS is also implemented on Windows
systems.
•
The SOCKS client library, which runs on internal hosts protected by the
firewall.
•
SOCKS-ified versions
of several standard client programs such as FTP and TELNET. The implementation of the SOCKS protocol typically involves either the recompilation or
relinking of TCP-based client applications, or
the use of alternate dynamically loaded libraries, to use the
appropriate encapsu- lation routines
in the SOCKS library.
When a TCP-based client wishes to establish a connection to an object that is reachable
only via a firewall (such
determination is left up to the
implementa- tion), it must open a TCP connection to the appropriate SOCKS port on the SOCKS
server system. The SOCKS service
is located on TCP port 1080. If the con- nection
request succeeds, the client enters a negotiation for the authentication method to be used,
authenticates with the chosen method, and then sends a relay request. The SOCKS server evaluates the request
and either establishes the appropriate
connection or denies it. UDP exchanges are handled in a similar fash- ion. In essence, a TCP connection is opened to authenticate a user to send
and receive UDP segments, and
the UDP segments are forwarded as long as the TCP
connection is open.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.