Security implications of increasing UDP timeout

[dhananjay95929]

Hello,

I was wondering if anybody has knowledge on the potential risks of increasing the default UDP timeout from 2 minutes to 90 minutes on a Cisco ASA?

A customer of ours has asked us to implement such a feature and we wanted to make them aware of any security issues that may arise as a result of such a configuration.

Thanks!

[Jouni Forss]

Hi,

I havent had to modify timeouts that often on an ASA but when I have had to change them its usually been applications TCP connections that for a reason or another dont have any builtin keepalive. Actually just ran into such a problem in a last couple of weeks.

When talking about UDP connections I guess most of the command UDP connections like DNS queries and replies will get removed from the firewall as soon as the firewall has seen the reply for the DNS query. To my understanding atleast.

I would imagine with random UDP connections setting the timeout to 90min instead of the global default of 2min might mean that there would be several UDP connections hanging on the firewall useless. I would also imagine that it would take a lot of connections to eventually reach the point where this might hurt your firewall performance. Mainly thinking about the maximum limit of connections on the ASA depending on the model. If the limit was reached, no new connections could be made even if the UDP connections were just idle and not in use.

I would imagine that also depending on the NAT configuration you might be left with a lot on active translations in the xlate table.

I think you should be able to perhaps configure this longer UDP timeout of 90min only apply to certain UDP connections if you specify the source/destination IP addresses/netorks and ports used and only apply this special timeout to those connections while leaving the rest to the global 2min timeout. This would be done using the Modular Policy Framework (if I remember the name correctly.)

In other words you would configure and ACL that defines the connections, attach it to a class map and attach that class map to the policy-map and there under the policy-map/class-map set the idle timeout value to that you want.

- Jouni

[dhananjay95929]

Hello Jouni,

I remember you from a previous discussion that I had created some time ago regarding notification of reset messages to end hosts after the idle timeout value has been reached for a particular connection on a firewall. You had suggested then to use MPF to acheive it.

I have indeed used MPF in this scenario for this particular customer based on the destination IP addresses (using ACLs) and it is working as expected for this customer only. All other UDP connections for other customers and application layer protocols (DNS, DHCP, etc.) are at the default value of 2 minutes.

We have an ASA 5550 model with 6,50,000 concurrent session capacity and its not even being used to half its capacity at present. So its not an immediate no. of connections issue through the firewall at this point of time. The customer has around 500 connections active at any given time but is expected to grow in future.

There is no NAT being performed for these connections and they are being sent as is to the destination through a private VPN interface.

What I wanted to understand was if there is an inherent security hole to keep a connection open through a firewall all the time. Would it be possible for anyone outside our organization to eavesdrop on the connection at some other point on the network and gather confidential data?

Thanks!

[Jouni Forss]

Hi,

Well you mentioned that you were having these UDP connections through a L2L VPN connection?

Then the connection between your VPN device and the peer VPN device is naturally secured. Anything between those devices and the actual servers/hosts communicating might be spots where traffic could be captured but I dont know how likely that is. (Naturally the VPN traffic can be captured also but its already encrypted)

And even then I guess it depends if the actual traffic between the hosts/servers is encrypted in itself.

- Jouni

[malshbou · Accepted solution]

Hi,

The potential security hole of increasing a UDP connection timeout would be giving a relatively higher chance for intruders to hijack the UDP connection and spoof the client's IP and port for injecting malicious packets into the same flow, especially that UDP is not tracked by sequence numbers and is stateless by nature for the endpoints.

Shutting a connection after 2 idle minutes will normally lead to next connections use new ports, hence better security.

Hope this helps

--

Mashal Alshboul

[dhananjay95929]

Thanks for all your valuable responses Jouni Forss and Mashal Alshboul.

Much appreciated!

[Jouni Forss]

Hi Mashal,

Wouldnt the situation you mention only apply if the UDP connections in question were from LAN to WAN?

In this case the timeout for UDP connections has been applied only to LAN to LAN traffic through a VPN connection.

I gather you mean that a connection from LAN to WAN with a high idle timeout value might leave the firewall open for malicious traffic?

- Jouni

[dhananjay95929]

Just to add to this conversation, even when the connection goes over an encrypted logical L2L IPsec VPN, it goes over a physical WAN circuit (over the internet).

[Jouni Forss]

Hi,

Yeah but these connections are through a L2L VPN connections using NAT0, therefore you DONT have a UDP connection hanging in the connection/xlate table for 90min that would be accessible/usable anyone other than the hosts on the remote LAN through the VPN connection.

This wouldnt leave anything open towards the public WAN / Internet

- Jouni