topic Re: How does a firewall track Udp in Network Security

How does a firewall track Udp

carl_townshend — Tue, 12 Mar 2019 02:56:38 GMT

Hi all

Can anyone tell me how a firewall tracks the state of a udp connection?

Cheers

Re: How does a firewall track Udp

Jouni Forss — Sat, 26 Oct 2013 16:59:33 GMT

Hi,

Well the UDP connections don't really have a state to track like TCP.

I guess one of the most common things to track with regards UDP on the ASA firewall might be DNS inspection and things related to DNS queries. For example the ASA would allow only one reply to a DNS query with the "dns-guard" global configuration or the one "dns-guard" configuration in the "policy-map" configurations under the "inspect dns"

Otherwise I would imagine the first thing for the ASA to check is whether its rules allow the UDP Connection in question based on its destination/source address/port.

When the connections is allowed to form through the firewall then naturally all traffic related to that connection on the ASA is allowed.

If the connection (by default) is idle for more than 2 minutes the connection will be removed from the firewall because of the "timeout" configurations. Naturally with additional "policy-map" / "class-map" configurations you can change this timeout value for a specific UDP connection you want to something longer or you can even change it globally for all UDP traffic with changing the "timeout" configuration.

I imagine there is more things related to how ASA handles different UDP connections but the above are the things that come to mind at the moment.

Hope this helps

Please do remember to mark a reply as the correct answer if it answered your question.

- Jouni

Re: How does a firewall track Udp

carl_townshend — Sat, 26 Oct 2013 19:14:17 GMT

Hi there

Thanks for the reply, however I feel as I need to know more about how they track udp connections

Re: How does a firewall track Udp

Jouni Forss — Sat, 26 Oct 2013 19:49:59 GMT

Hi,

I am not personally sure what else could be said about tracking UDP connections in general.

UDP compared to TCP doesnt contain much in its header for the ASA to keep track of.

You can check them here for example

http://nmap.org/book/tcpip-ref.html

TCP Header (click to enlarge)

UDP Header (click to enlarge)

If you want a Cisco sourced answer then this is what the CCNP certification material says about the subject

For UDP flows, the ASA tracks source and destination IP addresses and ports and the idle time since the last packet of the flow was seen by the ASA. For certain applications (such as DNS), the ASA also tracks request identifiers, to help it defend against packet-spoofing attacks. A UDP flow is created in the connection table if the ASA security policy permits it. Because UDP flows have no state machine, UDP flows are deleted only when they are idle for longer than the configurable UDP idle timer

So pretty much what I said in the above post.

Hope this helps

- Jouni

Re: How does a firewall track Udp

johnlloyd_13 — Sun, 27 Oct 2013 03:41:35 GMT

hi carl,

the ASA has a connection table (aka session table) that is used to track all connections permitted across the device.

this table maintains information not only connection-oriented/Transmission Control Protocol (TCP) sessions, but also the active communications, whether TCP or User Datagram Protocol (UDP), or based on advanced protocol inspection capabilities.

you could verify using the command show conn or show conn detail.

ciscoasa# show c?

call-home capture checkheaps checksum

chunkstat class clock compression

configuration conn console-output controller

coredump counters cpu crashinfo

crypto csc ctiqbe ctl-file

ctl-provider curpriv

ciscoasa# show conn

39 in use, 1008 most used

ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:00, bytes 5928

UDP outside VPN_Melbourne:500 inside VPN_Brisbane:500, idle 0:01:13, bytes 168, flags -

ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:09, bytes 127300

ESP outside VPN_HK_COLO inside VPN_Brisbane, idle 0:00:19, bytes 4732

UDP outside VPN_SanFrancisco:500 inside VPN_Brisbane:500, idle 0:01:12, bytes 716, flags -

UDP outside VPN_Hongkong:500 inside VPN_Brisbane:500, idle 0:01:19, bytes 504, flags -

UDP outside VPN_Sydney:500 inside VPN_Brisbane:500, idle 0:01:13, bytes 2296, flags -

GRE outside 203.x.x.1:0 inside VPN_Brisbane:0, idle 0:00:00, bytes 6495654, flags E

UDP outside VPN_Adelaide:500 inside VPN_Brisbane:500, idle 0:00:54, bytes 336, flags -

ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:00, bytes 21292

ESP outside VPN_Sydney_COLO inside VPN_Brisbane, idle 0:00:09, bytes 289868

UDP outside VPN_Sydney_COLO:500 inside VPN_Brisbane:500, idle 0:00:09, bytes 51598992, flags -

ESP outside VPN_HK_COLO inside VPN_Brisbane, idle 0:00:06, bytes 4136

UDP outside VPN_HK_COLO:500 inside VPN_Brisbane:500, idle 0:00:19, bytes 1188, flags -

TCP outside 199.x.x.x:80 inside 10.1.50.136:56805, idle 0:00:58, bytes 0, flags UFR

TCP outside 199.x.x.x:80 inside 10.1.50.136:56804, idle 0:00:57, bytes 1321, flags UFRIO

TCP outside 199.x.x.x:80 inside 10.1.50.136:56775, idle 0:02:11, bytes 1254, flags UFRIO

TCP outside 199.x.x.x:80 inside 10.1.50.136:56774, idle 0:02:11, bytes 0, flags UFR

UDP outside VPN_NY_Site2:500 inside VPN_Brisbane:500, idle 0:01:18, bytes 336, flags -

TCP outside DIA_GW:179 inside VPN_Brisbane:33496, idle 0:00:00, bytes 41990954, flags UIO

UDP outside VPN_Perth:500 inside VPN_Brisbane:500, idle 0:00:33, bytes 4704, flags -

UDP outside VPN_Canberra:500 inside VPN_Brisbane:500, idle 0:01:12, bytes 168, flags -

GRE outside 203.x.x.1:0 inside VPN_Brisbane:0, idle 0:00:00, bytes 500076100, flags E

TCP outside 199.x.x.x:80 inside 10.1.50.136:56807, idle 0:01:26, bytes 0, flags U

ciscoasa# show conn detail

42 in use, 1008 most used

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,

B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,

D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,

G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,

i - incomplete, J - GTP, j - GTP data, K - GTP t3-response

k - Skinny media, M - SMTP data, m - SIP media, n - GUP

O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,

q - SQL*Net data, R - outside acknowledged FIN,

R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,

s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,

V - VPN orphan, W - WAAS,

X - inspected by service module

ESP outside:VPN_London/41537 inside:VPN_Brisbane/2409,

idle 4s, uptime 4s, timeout 30s, bytes 76

ESP outside:VPN_Sydney_COLO/54414 inside:VPN_Brisbane/8341,

idle 0s, uptime 26s, timeout 30s, bytes 71524

UDP outside:VPN_Melbourne/500 inside:VPN_Brisbane/500,

flags -, idle 1m31s, uptime 1m31s, timeout 2m0s, bytes 168

ESP outside:VPN_Sydney_COLO/9125 inside:VPN_Brisbane/17362,

idle 27s, uptime 1m43s, timeout 30s, bytes 127300

ESP outside:VPN_HK_COLO/24294 inside:VPN_Brisbane/27579,

idle 12s, uptime 3m29s, timeout 30s, bytes 4936

UDP outside:VPN_SanFrancisco/500 inside:VPN_Brisbane/500,

flags -, idle 1m29s, uptime 4m13s, timeout 2m0s, bytes 716