...

Monday, July 19, 2010

CCNA Security 24

In UDP, the state of the connection is more difficult to track. This is because unlike TCP, UDP doesn't have handshakes, sequencing and acknowledgments. Due to this, UDP is known to be connectionless. Therefore, the state of the UDP session is more difficult to maintain.
ASA is able to derive the status of a session by observing the TCP bits found in the flow. For example, when an INSIDE host first initiates a SYN outwards, the OUTSIDE interface listens for a SYN-ACK.

Now we'll go through the full process of the creation of an connection object. The first SYN packet coming in from the INSIDE host would create a connection slot. This connection slot is not complete, so it is marked as EMBRYONIC.

The ASA then modifies the TCP header parameters before forwarding it to the OUTSIDE host. These modifications include randomizing the SEQuence number and adding the delta (the amount of change from the original SEQuence number).

The appliance then waits to hear a SYN-ACK from the OUTSIDE host and it is matched to the EMBRYONIC connection slot. If it matches, it would compute the SEQuence numbers before forwarding it to the INSIDE host.

At this point, the ASA would listen for an ACK from the INSIDE host and would once again compute a new SEQuence number before forwarding it to the OUTSIDE host. At this point, the connection slot would become an ACTIVE,ESTABLISHED or CONNECTED connection object.

Tracking UDP services come in the form of timeouts. A return path is opened once an INSIDE host sends something out, and would remain open until it is idle for a specified time.

Now I'll go into NAT. NAT stands for Network Address Translation from our studies and it provides a generic form of security and is also a solution for the lacking address space. Suppose that we have this topology:



Before any host in the INSIDE or the DMZ network can successfully transmit out to the internet, you would need to translate it to the OUTSIDE interface address (PAT) or any publicly routable address (NAT). RFC1918 addresses are explicitly denied by ISPs.

To enforce that packets traversing from an higher security to lower security interface match a NAT rule, we'll need to type:
nat-control

(Thanks Eddie for the correction: Lastly, "nat-control" does not _enable_ NAT, it restricts un-natted traffic from passing through two interfaces. (even if an ACL allows the traffic). This was standard/always "enabled" in PIX and 6.x code, but ASA 7.x code gives you the option to enforce "nat-control".)

All packets traversing the ASA must have a translation rule before they are allowed go to anywhere. NAT is then configured using two commands. The first command is to specify what devices should be NATted. This is typically put inside an inner interface:
nat (INSIDE) 1 0 0

Next, the global command is used to specify the global pool which should be used when a NATted packet exits the interface. This is typically entered at the outside interface:
global (OUTSIDE) 1 interface

The "1" specified in the commands stand for the NAT identifier. The NAT identifier allows the packet to choose the correct global pool. At this point, the INSIDE host would be able to properly communicate with anything OUTSIDE, but any connection relating to DMZ would not work.

The simplest thing we can do now is to allow the DMZ host to communicate with OUTSIDE hosts. We'll simply use the same settings as the INSIDE interface:
nat (DMZ) 1 0 0

We'll now want to allow INSIDE to DMZ, so we'll use:
global (DMZ) 1 interface

Notice that I've been using 0 0 right after the NAT identifier. This 0 0 stands for 0 address and 0 mask. This simply means any traffic originating from that interface would be NATted.

If we would not want a packet to be NATted, we can use identity NAT. Identity NAT actually creates a transparent mapping that allows replies directly back to the originating IP. Since all traffic now needs a NAT rule, what this does is that it actually creates a return entry for the originating IP of the identity NATted device. We can create an identity NAT for, an example, a host 10.10.10.150, we use:
nat (INSIDE) 0 10.10.10.150 255.255.255.255

If we have a range of addresses to use for the outside interface instead of just the interface IP itself, we can use DNAT through:
global (OUTSIDE) 0 152.226.152.10-152.226.152.254 netmask 255.255.255.0

DNAT only translates from INSIDE to OUTSIDE. Now, how about if someone wants to communicate with a DMZ device. For example, if we have a web server at 20.20.20.150, we would want to allow an outside translation by turning on static NAT. This type of NAT is also known as SPAT (or Port Forwarding). To do this, we'll type:
static (DMZ,OUTSIDE) interface 80 20.20.20.150 80
static (DMZ,OUTSIDE) interface 443 20.20.20.150 443


Now anyone accessing 152.226.152.1 would be redirected to 20.20.20.150.

You can also translate entire networks. For example, if we want to translate the entire DMZ network to the OUTSIDE network, we'll use:
static (DMZ,OUTSIDE) 152.226.152.0 20.20.20.0 netmask 255.255.255.0

We can actually set connection limits for our NATs. This is to protect the firewall from DoS attacks. The connection limits we can change are:
-TCP Embryonic
-TCP Max
-UDP Max

To modify this, we'll append to the back of the NAT command as follows:
nat (inside) 1 0 0 tcp 0 25 udp 0

What this does is that after 25 embryonic connections from inside, the ASA will activate the TCP SYN Cookies feature. What this does is that it would instead proxy the request, complete the connection, and attempt to open a connection to the inside host before bridging both.

This is typically done to static NAT so that an inside host would not receive the barrage of SYN packets, but would instead get only 1 SYN from the ASA once the connection is complete.

2 comments :

  1. Idenity NAT is NAT'ing to itself. For instance:

    static (inside,outside) 72.10.10.25 72.10.10.25

    This is different from NAT Exemption, which is in the following format:

    nat (inside) 0 192.168.0.0 255.255.255.0

    NAT exemption allows traffic to proceed without being translated, yet still satisfy "nat-control".

    The two are slightly different.

    Lastly, "nat-control" does not _enable_ NAT, it restricts un-natted traffic from passing through two interfaces. (even if an ACL allows the traffic). This was standard/always "enabled" in PIX and 6.x code, but ASA 7.x code gives you the option to enforce "nat-control".

    ReplyDelete
  2. Thanks a lot for the corrections Eddie! I fixed the "nat-control" part! Much appreciated for pointing out.

    As for the identity NAT part, I'll have to check again as I'm in a rush right now. The format written in the article actually still does create a return entry like an identity NAT would.

    I'll get back to this in a while =p

    ReplyDelete

<