Opened 10 months ago

Last modified 9 months ago

#1340 new Bug / Defect

UDP reflection amplification attack

Reported by: mtaggart Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger, tct

Description

I run a server that was subject to a DDoS attack today that appears to be a UDP reflection amplification attack coming from openvpn. I have searched the bug tracker, forums, CVEs, source, etc and could not find any mention of such a vulnerability, so I am asking here. Apologies if this is already solved or not an issue, but I was unable to determine so maybe at least it would help to document things.

What I am seeing is floods of P_CONTROL_HARD_RESET_SERVER_V2 packets coming from port 1194 on hundreds of source IPs. I searched around and found some things that might be related:

I plan to contact the network admins of the IPs used in the attack and I would like to include information on what course of action they should take.

Thanks

Change History (5)

comment:1 Changed 10 months ago by Gert Döring

The server operators need to use tls-auth or tls-crypt.

Both will make the server stop responding to unauthenticated packets.

Last edited 10 months ago by Gert Döring (previous) (diff)

comment:2 Changed 10 months ago by Gert Döring

There are two patches floating around that rate-limit responses to P_CONTROL_HARD_RESET_SERVER_V2 on servers that do not use either, but these have not been merged to the official repos yet, so it's not "patch the server and all is good" easy.

OTOH, tls-auth has other security benefits for the openvpn deployment, so it's a good idea for multiple reasons.

comment:3 Changed 9 months ago by Gert Döring

Cc: Steffan Karger added

comment:4 Changed 9 months ago by tct

Cc: tct added

comment:5 Changed 9 months ago by Steffan Karger

The reflection part is somewhat inherent to UDP, though indeed tls-auth, tls-crypt and tls-crypt-v2 can restrict such attack to attackers actually holding valid key. This helps, but is of limited use for e.g. VPN providers.

We might be able to do something about the amplification though. The OpenVPN three-way handshake consists of a HARD_RESET_CLIENT_V2 (or V3), HARD_RESET_SERVER_V2 and ACK_V1 packet. If a malicious client only sends a HARD_RESET_CLIENT_V2, and doesn't reply to the HARD_RESET_SERVER_V2, the server will retry sending its reply four times. If the server would not retry this specific packet, we would get rid of most of the amplification.

A small amplification remains: a HARD_RESET_CLIENT_V2 packet has 14 bytes UDP payload (58 bytes packet), the HARD_RESET_SERVER_V2 reply has 26 bytes UDP payload (70 bytes packet).

Note: See TracTickets for help on using tickets.