CISCO
PIX: TCP, UDP, NAT, PAT, AND PORT REDIRECTION
4: TCP, UDP, NAT and PAT as the PIX
see’s it.
In part four I will cover how the
PIX handles TCP and UDP protocols, how static and dynamic translations
work, how TCP interception features work and how to configure Dynamic
NAT’s, Static NAT’s across one interface and multiple interfaces.
Almost the entire world uses
Internet Protocol (IP) to communicate between computers, networks etc.
An IP connection between two devices is known as a session. A session
predominately uses one of two protocols, TCP or UDP.
From a PIX point of view TCP is
very easy to inspect as a TCP ‘packet’ follows a very strict and well
defined set of rules and has a very obvious start point and end point,
and also makes it very clear what protocol the payload consists of.
UDP on the other hand is a very
difficult protocol to inspect for the PIX as it has no clear beginning,
flow state, payload information or end.
*The definition of Outbound and
Inbound traffic differs from the normal definition as far as the PIX is
concerned. When dealing with a PIX Inbound traffic is deemed to be
traffic coming from a less secure interface to a more secure one (one
with a lower security level to one with a higher level) and Outbound
traffic is deemed to be traffic flowing from a more trusted interface
to a less trusted one. Usually this will be INSDIE to OUTSIDE but this
may not always be the case*
Transmission Control Protocol
TCP is a connection-orientated,
reliable and high performance protocol that works at the transport
layer (see here for a definition of the various layers). It is reliable
due to the fact each packet has a sequence number that is incremented
each time a packet is sent or received and the packets are acknowledged
once they are received to indicate to the sending device the packet has
reached its destination satisfactorily. Due to the nature of TCP the
PIX (or anything else) can see what state a current TCP connection is
in at any given time as each header has various ‘flags’ is can set to
indicate what type of packet it is and what is going on in the
connection.
When a TCP Session from a host on
a more secure interface (for the duration of this paper we will use the
INSIDE interface) is started, the PIX creates an entry in the session
state filter table. As its name suggests the session state table is
used for the PIX to keep tabs on the state of any given session.
The PIX can monitor a TCP session
in real time and is constantly aware of what packets are going where
and (if configured to do so) what is in the payload of each packet.
When the session is initiated the
PIX allows the packet out, but adds the Source Address, Source Port,
Destination Address, Destination Port, and a random TCP sequence
number, Flag (SYN, SYN-ACK etc) in to the session table. When a packet
is returned to the sending IP address, the PIX is aware of what stage
the connection is at and what is expected to be returned, so a valid
packet would now be addressed to the sending hosts, IP address and
correct source port, is from the correct IP address and Source Port,
has the correct sequence number and the correct flag (in this case a
SYN-ACK).
If any one of the above details
are incorrect the packet is dropped.
SO to put it in easy terms with a
very simplified header:
Code:
Source
IP Source
Port Dest
IP Dest Port
Flag Seq Number Ack Seq
10.10.10.20
32452
67.1.1.1
139
SYN 12345
This is the essential information
that would be in the header. The PIX would then enter this information
in its State Table.
Code:
Inside Network
10.10.10.20
32452
67.1.1.1
139
SYN
12345
When the return packet came back
it would expect to see this:
Code:
Sce
IP Sce
Port Dest
IP Dest
Port
Flag Seq
Number Ack Seq No
67.1.1.1
139
10.10.10.20 32452
SYN_ACK
54321 12346
So the PIX checks the source IP
and Port of this return packet to see if it has previously been sent
any data, it looks to the session table and sees that something has
indeed been sent to 67.1.1.1 to port 139 – it sees that this was sent
by 10.10.10.20 from Port 34252 and then checks the destination IP of
the return packet, 10.10.10.20 going to Port 32452 – so far so good –
now it looks at the Flag, sees it is a SYN-ACK, due to the rules of TCP
a SYN-ACK follows a SYN so when it looks at the session table for the
connection it will expect to see a SYN flag – yep, all is good so far –
now it looks at the Sequence number, the return packets Acknowledgment
Sequence number should be the sending hosts sequence number incremented
by one, 12346 – the PIX checks the state table entry and expects to see
12345 – yes all is good.
This packet meets all the
requirements to be allowed through and will be sent on its journey.
*There is more to take into
consideration, such as Access Rules, Fix-up protocols, Deep packet
inspection etc but that is for later on, for now we will ignore them
and just look at it from a Stateful Inspection point of view.*
As this session has not completed
the ‘Three-way handshake’ that governs how TCP will connect two hosts
together, the connection is known as an embryonic connection or a ‘half
open’ connection.
No data will be sent between the
two hosts until the connection is properly established. The PIX can be
configured to terminate embryonic connections after a set period of
time and to limit the amount any one host can have open. Once the
entire three-way handshake has been completed the embryonic counter is
reset for that particular connection.
There is a lot more to TCP but
this paper is about how the PIX looks at and handles TCP sessions, not
how TCP works. You can read this for more information on how TCP works.
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on September 20th, 2006 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.