The PIX Firewall can inspect a variety of protocols at Layer
3 and above. For example, in discovering ICMP packets, ASA automatically blocks
them, unless ACLs were created to allow that specific ICMP message type.
Two of the most common protocols are the transport layer protocols
TCP and UDP. ASA, such as the PIX IOS CBAC feature, have special processes and
techniques for managing traffic flows for each. The differences between these
two protocols should be familiar from CCNA studies. The implications for
firewall filtering are
Transport Control Protocol
TCP traffic, because of its predictable setup, data
transfer, and tear-down sequence, allows the PIX firewall to add additional
security by substituting a randomized sequence number to make it more difficult
for someone eavesdropping on the traffic to insert or replay traffic. In
addition, monitoring for an excessive number of half-open, or embryonic,
sessions is possible, which could indicate a form of denial of service (DoS)
attack is underway.
Figure 19-8 shows an outgoing packet to host
10.2.2.45 before and after the PIX NAT has translated the source IP address and
the PIX has created a randomized sequence number. Note that the SYN bit, from Figure
19-6, is the only flag bit set, indicating the first packet of a new
session. This information is used by the PIX to create a new xlate table entry,
if necessary, and a new state entry in the state table.
Figure 19-9 shows the first returning packet from
host 10.2.2.45. The state table is checked for an existing session, and the
field details are confirmed as consistent with an expected packet. The PIX
retranslates the destination address to the correct local address using the
xlate table. The acknowledgment number is the original sequence number
incremented, and then is translated before passing into the local network. TCP
uses forward acknowledgment, meaning the acknowledgement
number is the next sequence number expected. The actual acknowledgement number
then reflects the “window” increment used for flow control.
Note that both the SYN and ACK flag bits are on, which indicates
this is the second step in the handshake. If both the SYN and ACK flag bits
aren’t on, the packet will be dropped for not being the next expected step. The
SYN bit is on because host 10.2.2.45 is supplying its synchronization number to
the local host.
The next exchange and all exchanges during data transfer would
have only the ACK bit set because each exchange acknowledges the last
transmission from the other party. The NAT translations would continue as they
are. The sequence and acknowledgement fields would be appropriately
incremented.
Any packet traffic that doesn’t match the key fields of the state
table or appears out of order is dropped. Even if the source and destination
address/port number combinations are correct, if the packet doesn’t fit, the
expected step could mean the packet has been manipulated or replayed by someone
running a “man-in-the-middle” attack.
FIN and RST Bits
If the session is interrupted, a packet with the RST (reset)
bit set turned on could be received or, if either host wants to stop the
session, the FIN (finish) bit would be turned on. In either case, the PIX device
knows the session is ending and removes any related xlate and state table
entries, thereby reducing the vulnerability to unauthorized use.
Unauthorized Return Traffic
If host 10.2.2.45 were to attempt to send additional
packets, even a packet with the SYN bit on and ACK bit off, indicating a new
session, the attempt would be blocked because no existing state table entry
would be available. Because the original translation was done with NAT (or PAT),
there wouldn’t be a static entry allowing the unsolicited data.
Authorized Inbound Traffic
Assuming the inbound traffic is destined to a shared server,
the static address translation is in the xlate table and an enabling access
control list allows the unsolicited inbound packet. The SYN bit is on and the
ACK bit is off. A state table entry is made, and any necessary translation is
performed before the packet passes into the more secure network, typically DMZ,
but it could be inside. This state table entry is an “embryonic” TCP session,
indicating it’s incomplete. The state table entry remains in this state until
the three-way handshake is complete and ACK packets are being exchanged.
The inside host then performs Step 2 in the TCP handshake and
things progress, as described earlier. Each exchange in both directions is
reviewed and the state table is updated as necessary.
SYN Attacks
A common form of DoS attack is some variation of a SYN
attack where large numbers of SYN packets are received by the inside device and
appropriate reply exchanges are prepared and sent. Unfortunately, the sender has
no intention of completing these sessions, so the final step of the handshake is
never completed. If you recall from Chapter 1, this type of attack can be successful by either
overloading the target host or by congesting the link to the target host. Either
way, legitimate traffic and activity can’t get service.
PIX Firewalls can monitor both the number of embryonic
sessions and the time it takes to complete them. This information can be used by
the PIX to trigger discarding embryonic sessions to keep the host from being
buried. Unfortunately, while the PIX can protect the target device from too many
half-open sessions, it might need assistance from an upstream Internet service
provider (ISP) to keep the link from becoming clogged.
User Datagram Protocol
Because UDP doesn’t establish a connection-oriented session,
it’s harder to protect. The PIX creates a state table entry any time a UDP
packet is sent from a secure interface to a less-secure interface. This entry
can only have the basic source, and destination addresses and port numbers. Any
UDP traffic arriving from the less-secure interface that matches the state table
entries is allowed to pass through.
Common UDP datagrams, such as DNS and NFS, are frequent
targets of attacks, so it’s important that UDP connections be restricted. PIX
units have a feature that only allows one DNS server to respond to a DNS query.
Any additional responses are discarded. This reduces the likelihood of an
attacker submitting a bogus response and directing output to a bad destination.
To reduce exposure further, the state table entries created from the outgoing
UDP datagrams have default lives of only two minutes, configurable, to see
returning traffic before they’re removed.
Sections
Comments (0 posted)
Syndication
