1

Why does a LAN-side UDP flood take up the target's CPU resources and make it sluggish? i.e: the mouse doesn't respond properly, opening an application is slow...

Note: The computers are both connected to a switch which connects to the router. Also, the target noticeable becomes sluggish when opening a web-page, and even after closing the browser the slow performance remains at that same level.

Just in case I didn't clarify, the poor performance happens on the computer that is being flooded, not the computer performing the flood. As soon as the denial-of-service is stopped, the target returns to it's normal performance.

0

Why does a LAN-side UDP flood take up the target's CPU resources and make it sluggish?

This depends on a number of factors, one of the primary being what action is taking place on the system receiving the UDP flood. Let's take a look at the basics of the process.

To begin, the host receives the UDP traffic. All received traffic must be processed to some degree. At the very least, the destination port of the UDP traffic needs to be determined. This means the Ethernet and IP headers are removed as it moves through the network stack and is handed off to be processed as a UDP segment. There may also be firewall rules to process as well.

The destination port is checked to see if there is an application listening on that UDP port (either a service bound to the port or a port used by outbound traffic that may be expecting reply traffic).

If there is an application listening on the UDP port, the UDP headers are removed and passed to the application. The application then needs to process the data in whichever way it is configured to do so.

If there isn't, the host can respond in one of two ways: silently drop the data or to reject the data. Rejecting the data is generally considered more "friendly" and makes things like debugging easiers as a notice that the traffic is rejected is sent back to the source of the traffic using ICMP. This is good when traffic is accidentally sent to the wrong host or port and can cause the unwanted traffic to stop (if the sending host/application recognizes the traffic is unwanted).

So, we have a process. Now, in that process, most of the above can be done in hardware if the network adapter (and the driver, OS, etc) support it. What isn't done in hardware is done in software by running on the CPU.

Where can the use of the CPU come from? Largely from the following four possibilities:

  • Processing the received traffic (Ethernet -> IP -> UDP), including any firewall rules
  • Checking for applications listening on the UDP port
  • Application processing data received on a listening port
  • Generating return traffic (ICMP error messages)

Why a specific host becomes sluggish would be the result of it performing one or more of the above in software (i.e. CPU).

If a host processes the traffic (including firewall rules) and drops unwanted traffic (or processes the reject) all in hardware, there should be no impact on the CPU as a result of a UDP flood to UDP ports to which it has no application listening.

How a specific application is affected by receiving unwanted traffic to a port it is listening on would be entirely up to the application.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.