TMS zl Management and Configuration Guide ST.1.2.100916

4-7
Firewall
General Firewall Concepts
Valid but illogical handshakes and packets with invalid IP addresses are often
a sign that an attacker is attempting to infiltrate or gain information about a
private network.
The TMS zl Module automatically recognizes the flags that mark common
attacks and drops packets that contain them. (See “Enable and Disable
Optional Attack Checks” on page 4-111 for instructions.)
Application-Level Gateway
Like a circuit-level gateway, an application-level gateway acts as a proxy
server between a trusted client and an untrusted host. Application-level
proxies filter packets at the OSI Application Layer (Layer 7). That is, they
accept only packets generated by services that they are designed to copy,
forward, and filter. For example, only an FTP proxy can copy, forward, and
filter FTP traffic. The proxy server reads each packet and filters particular
commands or information relating to applicable application protocols.
A proxy application-level gateway (ALGs) can be prohibitively draining on
resources. Each application needs a separate ALG, and the gateway imposes
two separate connections (from the trusted network to the gateway and from
the gateway to the trusted network).
However, a stateful firewall, such as the firewall on the TMS zl Module, can
analyze Application Layer data without acting as a proxy server. Instead, the
firewall monitors sessions between hosts. When it determines that a session
is valid, it allows the session to be established. Then the firewall uses algo-
rithms to process the Application Layer data for packets that are associated
with the session. When new packets that are associated with the session
arrive, the module compares the bit patterns of the new packets to the bit
patterns that were stored for previously authorized packets. The firewall can
then determine whether the new packets are a valid part of the session.
A specific ALG is necessary when you want to run an application that behaves
in ways that might cause the module’s firewall to interfere with the application.
For example, when opening a session, an application might negotiate a
dynamic port on which the session then runs. Without the ALG, the firewall
might permit the packets that initiate the session but block the packets on the
dynamically selected port. To allow the application to run, you would need to
open all of the ports that the application might choose. However, opening such
a large number of ports would create a security risk. An ALG solves this
problem by monitoring each session associated with the application in ques-
tion and opening only the dynamic port selected for that session—and keeping
this port open only for the duration of the session.
Depending on the ALG, it might also perform other functions to help the
application run smoothly and securely through the firewall.