Blocking packets from suspicious ports

Christian Huitema <huitema@huitema.net> Mon, 02 May 2022 20:29 UTC

Message-ID: <6830cf87-e1b6-14bb-7b10-9341fdb6d941@huitema.net>
Date: Mon, 02 May 2022 13:29:28 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Content-Language: en-US
To: IETF QUIC WG <quic@ietf.org>
From: Christian Huitema <huitema@huitema.net>
Subject: Blocking packets from suspicious ports
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Uvg1BgKi9pvLjPDI0vMD_nZJlgU>
Precedence: list

Services based on UDP have to be worried about two variants of DDOS 
attacks: being an unwitting amplifier of a DDOS attack, and being on the 
receiving end of a DDOS attack. The first concern is addressed in the 
spec, with amplification limits and the Retry packet. The second concern 
is often mitigated by silently discarding traffic from ports often used 
in amplification of UDP DDOS attacks, e.g., DNS, or NTP. After reviewing 
discussions like 
https://lists.w3.org/Archives/Public/ietf-http-wg/2021JulSep/0053.html I 
implemented this port blocking feature in Picoquic, but I have a couple 
of uneasy feelings when doing that.

The list of ports appear a tiny bit arbitrary. It mostly derives from 
reports on recent DDOS attacks, some of which are publicly available 
(e.g., https://blog.cloudflare.com/reflections-on-reflections/) while 
others appear to be propagated through private channels. The resulting 
lists may be a bit arbitrary. For example, some lists include port 11211 
(memcache daemon), but Cloudflare does not, maybe because we don't see 
much attacks on that port anymore. Many lists include blocking of port 
137 (NetBios name service), but only a few include port 138 (NetBios 
datagram service).

If I dig a little bit further, I think that differences in the blocked 
lists come from different priorities. We may want to protect QUIC 
servers from amplified UDP DDOS attacks, but we may also want to protect 
local services from Request Forgery Attacks. In the second case, the 
list of blocked ports gets bigger. But that too is arbitrary. For 
example, some lists include port 5353 (mDNS) and port 1900 (SSDP), but 
it seems that nobody bothers with port 5354 (LLMNR) or port 3702 
(WS-Discovery).

Then, there is the way in which blocking is applied. One could just do 
it for all incoming packets, silently dropping whatever comes from a 
blocked port. Clean, simple, but some per packet overhead. Is it enough 
to apply the checks when receiving Initial packets and deciding whether 
to create a connection or not? What about packets that would trigger a 
VN response, or a stateless retry? What about probes for new paths?

-- Christian Huitema

Blocking packets from suspicious ports Christian Huitema
Re: Blocking packets from suspicious ports Paul Vixie
Re: Blocking packets from suspicious ports Willy Tarreau
Re: Blocking packets from suspicious ports Christian Huitema
Re: Blocking packets from suspicious ports Willy Tarreau
Re: Blocking packets from suspicious ports Willy Tarreau
Re: Blocking packets from suspicious ports Christian Huitema
Re: Blocking packets from suspicious ports Carsten Bormann
Re: Blocking packets from suspicious ports Willy Tarreau
Re: Blocking packets from suspicious ports Carsten Bormann
Re: Blocking packets from suspicious ports Willy Tarreau
Re: Blocking packets from suspicious ports Carsten Bormann
Re: Blocking packets from suspicious ports Willy Tarreau
Re: Blocking packets from suspicious ports Christian Huitema
Re: Blocking packets from suspicious ports Mirja Kuehlewind
Re: Blocking packets from suspicious ports Christian Huitema