CISCO
PIX: TCP, UDP, NAT, PAT, AND PORT REDIRECTION CONT...
User Datagram Protocol (UDP)
UDP is considered to be an efficient but connectionless protocol as
unlike TCP there is no three-way handshake, session monitoring, error
checking etc. Some people call it a fire and forget protocol as once
the data has been sent the sending station has no way to check if it
ever reached it destination or not. There are no sequence numbers
either.
For these reasons the PIX has a difficult job to try and secure a
network against UDP packets. t has no sequence number to verify, no
SYN, SYN-ACK etc Flags to check the PIX has no way of knowing what
state a UDP session is in, if it has ended etc so must take other
measures to secure UDP traffic.
The PIX creates a UDP Slot whenever a UDP session is initiated from a
more secure interface to a less secure interface, any subsequent UDP
packets that match the details in the UDP Slot are allowed through, ACL
permitting.
As the PIX can't tell when a UDP exchange has ended it starts a counter
when a packet leaves, the default is 2 minutes. If a return UDP packet
has not been received that fits the parameters in the UDP Slot then the
slot is closed.
All UDP packets have to meet the same Stateful Source IP & Port,
Destination IP & Port prerequisites that the TCP packet do, but as
there is no sequencing it is relatively easy to spoof a UDP packet and
maybe even get it through the firewall.
The main defence against UDP is the session timeout.
TCP Intercept and Connection Limits
Denial of Service (DoS) attacks are relatively easy to conduct due the
amount of scripted software available for download today. For this
reason it is in our interest to set connection limits for all incoming
connections and all embryonic connections.
There are four common limits we can set:
1. TCP Maximum Connection limit this limits the amount of connections
a real IP host can have open concurrently
2. Embryonic limit an embryonic connection is a TCP connection that
has not completed a three-way handshake between the source and
destination hosts.
3. UDP Maximum Connections limits the maximum amount of concurrent
UDP connections a real IP host can have open
4. Connection Timeout : The amount of time before an idle/embryonic
connection is closed
SYN Flooding
As mentioned earlier, when a host uses TCP to communicate with another
host it initiates a three-way handshake. Amongst other things, included
in the three-way handshake are various flags that indicate the state of
a connection.
When a host first makes contact with another host it sets the SYN flag
in the TCP header, the receiving host the sets the SYN and ACK flags in
the return packet, the first host sets the ACK packet in the subsequent
packet.
A SYN flood is where we send a packet from a spoofed IP address to a
host with the SYN flag set. The receiving host will send a SYN ACK
packet back as expected but as the initiating IP is spoofed, there is
nothing to receive the packet, hence the ACK flag that our server is
waiting for to complete the third part of the handshake never comes
back to it, if we flood the server with these SYN packets we will soon
fill its buffer up as it will be keeping all connections open awaiting
the ACK packets that will never arrive. This is what we call an
embryonic connection and why we should limit the amount of them!
There is a very clever defence mechanism in the PIX to stop SYN
Flooding should we reach our embryonic connection limit. If we set an
embryonic limit that gets reached during a DoS attack, it would be
pointless if the PIX drops all incoming SYN packets as then the DoS
attack would still be successful, likewise the PIX is not about to let
all SYN packets through!
To prevent the DoS attack from working the PIX uses what is know as TCP
Intercept.
TCP intercept is a feature whereby if the embryonic connection limit is
reached the PIX will assume responsibility for all incoming SYN packets
on behalf of the server whose limit has been reached.
When a SYN packet comes in the PIX will log all pertinent state
information as normal (Sequence number etc), respond with an empty SYN
ACK packet and then drop the original SYN packet.
If the relevant ACK packet comes back from the server and all the state
table information checks out the clients SYN segment is sent to the
server and the three-way handshake takes place with the PIX and
internal server instead.
Once this three-way handshake has been completed the connection will be
allowed as normal.
TCP Intercept proved to be a very CPU intensive procedure and could
still potentially result in a DoS state. To avoid this issue Cisco came
up with a feature called SYN Cookies.
SYN Cookies
SYN cookies is a procedure PIX version 6.2 and later will use in
place of TCP intercept.
When a SYN packet comes in and after the embryonic connection has been
reached the PIX will still take over the three-way handshake on behalf
of the server only instead of keeping stateful information like it does
with TCP intercept, it will make a mathematical HASH or the destination
IP, destination port, source IP, source port, sequence number and a
secret key. This is then placed in the packets header in the form of a
cookie and sent back to the initiation host with the relevant SYN ACK
packet.
As the PIX is the only thing that knows the secret key, only the PIX
will be able to decipher the return cookie
No state information is kept by the PIX thereby keeping its state table
free and taking up no memory space.
When the initiating host responds with the expected ACK packet the
cookie will still be in the packet header. The PIX extracts this
cookie, deciphers it and calculates if it is a response to a previous
SYN ACK sent out by the PIX, if so the PIX will attempt to open a
connection to the server.
SYN cookies is by far a more manageable method of handling embryonic
connection overflows.
The commands for all of the above are very very simple and are used
with our NAT and Static commands.
Code:
London(config)# static (inside, outside) 80.80.80.100 10.10.10.10
netmask 255.255.255.255 0 25
Notice the 0 and 25 at the end of the above command. The 0 sets the
maximum TCP connection limit to Unlimited (this can be substituted for
a number of your choice) and 25 sets the maximum embryonic connections
for to 25.
*If you do not specify any limits when you use the NAT and Static
commands the PIX default both to unlimited*
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.