![](https://secure.gravatar.com/avatar/be89f48869aae3867c355acb0d857483.jpg?s=120&d=mm&r=g)
Several times this year our customers have suffered DDoS' ranging from 30 Mbps to over 1 Gbps, sometimes sustained, sometimes in a several minute spurts. They are targeted at one IP address, and most times our netflow tool identifies that a large percentage of the traffic is "port 0". The one from today had about 89% port 0 and 11% port 53 (DNS). If it happens repeatedly or continuously we just have our upstream provider blackhole the target (victim) IP address. I've been tempted to ask our upstream provider to block all traffic to us that's targeted to tcp or udp port 0 -- is that safe to do? I found two NANOG archives that talk about this http://www.nanog.org/mailinglist/mailarchives/old_archive/2005-04/msg00091.h tml http://www.gossamer-threads.com/lists/nanog/users/18990 and the first suggests that port zero could really be fragmented packets. Unfortunately I don't have packet captures of any of the attacks, so I can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0. Regards, Frank
![](https://secure.gravatar.com/avatar/15d0eda11a0a36ee955d38a6fa114170.jpg?s=120&d=mm&r=g)
Frank Bulk <frnkblk@iname.com> wrote:
Unfortunately I don't have packet captures of any of the attacks, so I can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0.
Yes - don't do it, or you will break the Internet. These are non-initial fragments. You or your customers are on the receiving end of DNS reflection/amplification attacks, and the large unsolicited DNS responses being used to packet you/them are fragmented. Use S/RTBH, flowspec, IDMS, and/or coordination with your peers/upstreams to block these attacks when they occur. Do *not* perform wholesale blocking of non-initial fragments (i.e., src/dst port 0), or you will have many unhappy customers and soon-to-be former customers. ;> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
![](https://secure.gravatar.com/avatar/be89f48869aae3867c355acb0d857483.jpg?s=120&d=mm&r=g)
Thanks for confirming what was discussed in the NANOG archive. I now have warm fuzzies knowing that all my protections are reactive. =) I will be talking with our upstream provider to see if they can enable some better automation (because they run a larger shop). I know they were able to null route in seconds, we just need a faster way to identify targets. Frank -----Original Message----- From: Roland Dobbins [mailto:rdobbins@arbor.net] Sent: Tuesday, July 24, 2012 11:06 PM To: Frank Bulk; nanog@nanog.org Subject: Re: DDoS using port 0 and 53 (DNS) Frank Bulk <frnkblk@iname.com> wrote:
Unfortunately I don't have packet captures of any of the attacks, so I can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0.
Yes - don't do it, or you will break the Internet. These are non-initial fragments. You or your customers are on the receiving end of DNS reflection/amplification attacks, and the large unsolicited DNS responses being used to packet you/them are fragmented. Use S/RTBH, flowspec, IDMS, and/or coordination with your peers/upstreams to block these attacks when they occur. Do *not* perform wholesale blocking of non-initial fragments (i.e., src/dst port 0), or you will have many unhappy customers and soon-to-be former customers. ;> ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
![](https://secure.gravatar.com/avatar/abb6bbc9e4ada2971b6e6cd677b9766e.jpg?s=120&d=mm&r=g)
On 7/24/12, Roland Dobbins <rdobbins@arbor.net> wrote:
Frank Bulk <frnkblk@iname.com> wrote:
can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0. Yes - don't do it, or you will break the Internet. These are non-initial
Without a packet capture to look at, that's really just a blind assumption. A port number of a non-initial fragment does not exist at all, because the Layer 4 info is unavailable in that case, something _might_ lie and say the port number is 0, but it should not -- there is no TCP header with any port numbers, the only fields available to check against on such packets are Layer 3 fields such as protocol, source, destination address. The port number of the Layer 4 connection cannot be determined without executing IP fragment reassembly in that case. Routers normally reassemble fragments they receive, if possible. An access list statement attempting to match against non-present Layer 4 information, should not work; on a stateful firewall, the presence of the rule might trigger a fragment reassembly, on a router, the non-applicable ACL entry referring to a non-existent port number will generally be ignored. A full capture should not be necessary. You determine if a packet is a fragment by examining the MF flag, bit 50, and fragmentation offset of the IPv4 header; bits 51 through 63. You only need to look at the first 8 bytes of the IP header. If the MF bit is set to 0, and the fragmentation offset is also all bits 0, then the packet is not part of a fragment. The packet is a non-initial fragment if and only if, the fragmentation offset is not set to zero. Port number's not a field you look at for that. -- -JH
![](https://secure.gravatar.com/avatar/50d19e846fb128a4f08aa600829ed8d4.jpg?s=120&d=mm&r=g)
The port number of the Layer 4 connection cannot be determined without executing IP fragment reassembly in that case. Routers normally reassemble fragments they receive, if possible.
No, routers normally do *not* reassemble fragments. This is typically done by hosts and firewalls. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
![](https://secure.gravatar.com/avatar/15d0eda11a0a36ee955d38a6fa114170.jpg?s=120&d=mm&r=g)
On Jul 25, 2012, at 1:13 PM, <sthaug@nethelp.no> wrote:
No, routers normally do *not* reassemble fragments.
Absolutely correct. I missed this in the rest of the reply, good catch! ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
![](https://secure.gravatar.com/avatar/15d0eda11a0a36ee955d38a6fa114170.jpg?s=120&d=mm&r=g)
On Jul 25, 2012, at 12:08 PM, Jimmy Hess wrote:
The packet is a non-initial fragment if and only if, the fragmentation offset is not set to zero. Port number's not a field you look at for that.
I understand all that, thanks. NetFlow reports source/dest port 0 for non-initial fragments. That, coupled with the description of the attack, makes it a near-certainty that the observed attack was a DNS reflection/amplification attack. Furthermore, most routers can't perform the type of filtering necessary to check deeply into the packet header in order to determine if a given packet is a well-formed non-initial fragment or not. And finally, many router implementations interpret source/dest port 0 as - yes, you guessed it - non-initial fragments. Hence, it's not a good idea to filter on source/dest port 0. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
![](https://secure.gravatar.com/avatar/be89f48869aae3867c355acb0d857483.jpg?s=120&d=mm&r=g)
Can netflow _properly_ "capture" whether a packet is a fragment or not? If not, does IPFIX address this? Frank -----Original Message----- From: Jimmy Hess [mailto:mysidia@gmail.com] Sent: Wednesday, July 25, 2012 12:08 AM To: Roland Dobbins Cc: Frank Bulk; nanog@nanog.org Subject: Re: DDoS using port 0 and 53 (DNS) On 7/24/12, Roland Dobbins <rdobbins@arbor.net> wrote:
Frank Bulk <frnkblk@iname.com> wrote:
can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0. Yes - don't do it, or you will break the Internet. These are non-initial
Without a packet capture to look at, that's really just a blind assumption. A port number of a non-initial fragment does not exist at all, because the Layer 4 info is unavailable in that case, something _might_ lie and say the port number is 0, but it should not -- there is no TCP header with any port numbers, the only fields available to check against on such packets are Layer 3 fields such as protocol, source, destination address. The port number of the Layer 4 connection cannot be determined without executing IP fragment reassembly in that case. Routers normally reassemble fragments they receive, if possible. An access list statement attempting to match against non-present Layer 4 information, should not work; on a stateful firewall, the presence of the rule might trigger a fragment reassembly, on a router, the non-applicable ACL entry referring to a non-existent port number will generally be ignored. A full capture should not be necessary. You determine if a packet is a fragment by examining the MF flag, bit 50, and fragmentation offset of the IPv4 header; bits 51 through 63. You only need to look at the first 8 bytes of the IP header. If the MF bit is set to 0, and the fragmentation offset is also all bits 0, then the packet is not part of a fragment. The packet is a non-initial fragment if and only if, the fragmentation offset is not set to zero. Port number's not a field you look at for that. -- -JH
![](https://secure.gravatar.com/avatar/15d0eda11a0a36ee955d38a6fa114170.jpg?s=120&d=mm&r=g)
On Jul 25, 2012, at 10:27 PM, Frank Bulk wrote:
Can netflow _properly_ "capture" whether a packet is a fragment or not?
No.
If not, does IPFIX address this?
Yes. But this is all a distraction. We are now down in the weeds. Your customers were victims of a DNS reflection/amplification attack. The issue of fragmentation is moot. The defense methodologies already discussed are how folks typically deal with these attacks. There isn't an ovearching network access policy list you can apply at your edges or ask your peers/upstreams to apply which will mask them - the optimal approach is to deal with them on a case-by-case basis. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
![](https://secure.gravatar.com/avatar/abb6bbc9e4ada2971b6e6cd677b9766e.jpg?s=120&d=mm&r=g)
On 7/24/12, Frank Bulk <frnkblk@iname.com> wrote:
Unfortunately I don't have packet captures of any of the attacks, so I can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0.
It should be relatively safe to drop (non-fragment) packets to/from port 0. If I recall correctly, there are some routers that perform a "helpful" numeric value validation when the human is entering port numbers for access list rules, that _do_ forward port 0 traffic, and through some sort of oversight by the router/firewall vendor actually _prevent_ the administrator from selecting port 0 in a deny rule, eg. "Port to deny must be a number from 1 to 65535". TCP/UDP port 0 is technically a legal port, but it's also a reserved port, and very unusual for it to be used on the network for any legitimate purpose. Various firewalls will discard anything TCP/UDP sent to/from port 0. Many TCP/UDP sockets implementations won't even let an application select port 0. bind() to port 0 is treated as a signal that the application wants the sockets API to pick a high-numbered ephemeral port.
Regards, Frank -- -JH
![](https://secure.gravatar.com/avatar/5d916611288151dacfeb2d844d483358.jpg?s=120&d=mm&r=g)
On Tue, 24 Jul 2012 23:10:52 -0500 Jimmy Hess <mysidia@gmail.com> wrote:
It should be relatively safe to drop (non-fragment) packets to/from port 0. [...]
Some UDP applications will use zero as a source port when they do not expect a response, which is how many one-way UDP-based apps operate, though not all. This behavior is spelled out in the IETF RFC 768: "Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted." John
![](https://secure.gravatar.com/avatar/158e4b3c03c17a15f4dfd12c84e22edd.jpg?s=120&d=mm&r=g)
On Wed, Jul 25, 2012 at 8:43 AM, John Kristoff <jtk@cymru.com> wrote:
Some UDP applications will use zero as a source port when they do not expect a response, which is how many one-way UDP-based apps operate, though not all. This behavior is spelled out in the IETF RFC 768:
That would only be applicable if the box was expecting to receive UDP and not send a response. I'm not sure I can think of anything but specialized, vertical applications that would have that behavior with port zero (syslog and SNMP traps send without expecting a response, but they don't use port zero in any implementation I've seen, and neither is generally allowed to be received from the internet at large). In addition to the fragments, these packets might also be non-TCP/UDP (ICMP, GRE, 6to4 and other IP-IP, etc). If the host doesn't expect to receive large UDP packets, you can block UDP fragments. Note that recursive DNS servers would need UDP fragments (well, if you want to do large DNS packets - if you set the right options, you can turn that off). But if you aren't generally providing UDP services, blocking UDP packets, especially to stop an attack, wouldn't hurt (you can also block anything with the MF bit set). If you block these fragments at your provider's router, and it is a DNS amplification attack, you're problems are probably solved until the hacker figures it out. Just make sure you think of things like recursive DNS and other applications that may be using UDP fragments.
![](https://secure.gravatar.com/avatar/15d0eda11a0a36ee955d38a6fa114170.jpg?s=120&d=mm&r=g)
On Jul 25, 2012, at 9:52 PM, Joel Maslak wrote:
In addition to the fragments, these packets might also be non-TCP/UDP (ICMP, GRE, 6to4 and other IP-IP, etc).
NetFlow will report the correct protocol number. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
![](https://secure.gravatar.com/avatar/97f454d78ab404e82a44a513a2de8aa6.jpg?s=120&d=mm&r=g)
In message <CADb+6TD6EMN7i9G99hPrhBh2ck-NwRqUuoQ1ubmnsHYN=iXAkg@mail.gmail.com>, Joel Maslak writes:
On Wed, Jul 25, 2012 at 8:43 AM, John Kristoff <jtk@cymru.com> wrote:
Some UDP applications will use zero as a source port when they do not expect a response, which is how many one-way UDP-based apps operate, though not all. This behavior is spelled out in the IETF RFC 768:
That would only be applicable if the box was expecting to receive UDP and not send a response. I'm not sure I can think of anything but specialized, vertical applications that would have that behavior with port zero (syslog and SNMP traps send without expecting a response, but they don't use port zero in any implementation I've seen, and neither is generally allowed to be received from the internet at large).
In addition to the fragments, these packets might also be non-TCP/UDP (ICMP, GRE, 6to4 and other IP-IP, etc). If the host doesn't expect to receive large UDP packets, you can block UDP fragments. Note that recursive DNS servers would need UDP fragments (well, if you want to do large DNS packets - if you set the right options, you can turn that off). But if you aren't generally providing UDP services, blocking UDP packets, especially to stop an attack, wouldn't hurt (you can also block anything with the MF bit set). If you block these fragments at your provider's router, and it is a DNS amplification attack, you're problems are probably solved until the hacker figures it out. Just make sure you think of things like recursive DNS and other applications that may be using UDP fragments.
Actually *all* IPv6 node are supposed to support EDNS so *all* IPv6 hosts should be expecting to receive fragmented UDP for DNS. Add to that all hosts that do DNSSEC validation in the stub resolver / application. With DANE this will be any host with a web browser. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
![](https://secure.gravatar.com/avatar/df81f0b6ece72faddfc17a3c920072d0.jpg?s=120&d=mm&r=g)
Another nice "emerging" tool [I say emerging because it's been around forever but nobody implements it] to deal with this is Flowspec, using flowspec you can instruct your Upstream to block traffic with much more granular characteristics. Instead of dropping all traffic to the IP address, you can drop (for example) udp dst 80 traffic to the IP address, or traffic from a particular source to a particular DST. It can also be initiated by your side without interaction from the upstream ISP. Just saying =) -Drew -----Original Message----- From: Frank Bulk [mailto:frnkblk@iname.com] Sent: Tuesday, July 24, 2012 11:41 PM To: nanog@nanog.org Subject: DDoS using port 0 and 53 (DNS) Several times this year our customers have suffered DDoS' ranging from 30 Mbps to over 1 Gbps, sometimes sustained, sometimes in a several minute spurts. They are targeted at one IP address, and most times our netflow tool identifies that a large percentage of the traffic is "port 0". The one from today had about 89% port 0 and 11% port 53 (DNS). If it happens repeatedly or continuously we just have our upstream provider blackhole the target (victim) IP address. I've been tempted to ask our upstream provider to block all traffic to us that's targeted to tcp or udp port 0 -- is that safe to do? I found two NANOG archives that talk about this http://www.nanog.org/mailinglist/mailarchives/old_archive/2005-04/msg00091.h tml http://www.gossamer-threads.com/lists/nanog/users/18990 and the first suggests that port zero could really be fragmented packets. Unfortunately I don't have packet captures of any of the attacks, so I can't exam them for more detail, but wondering if there was some collective wisdom about blocking port 0. Regards, Frank
![](https://secure.gravatar.com/avatar/15d0eda11a0a36ee955d38a6fa114170.jpg?s=120&d=mm&r=g)
On Jul 26, 2012, at 5:13 AM, Drew Weaver wrote:
Another nice "emerging" tool [I say emerging because it's been around forever but nobody implements it] to deal with this is Flowspec, using flowspec you can instruct your Upstream to block traffic with much more granular characteristics.
flowspec is essentially S/RTBH with layer-4 granularity (it can do some other things, as well). I certainly hope that vendors who've not yet implemented it will do so, it's a great tool, as you say. Even customer-triggered S/RTBH is very useful, and some ISPs have implemented it for their customers. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
participants (9)
-
Dobbins, Roland
-
Drew Weaver
-
Frank Bulk
-
Jimmy Hess
-
Joel Maslak
-
John Kristoff
-
Mark Andrews
-
Roland Dobbins
-
sthaugļ¼ nethelp.no