Internet2 Network Security SIG

[Jesse Bowling <>]

This prompted me to look into my own network for “port 0” traffic. I found 
quite a bit that Argus labeled as “port 0”, particularly from one host. In 
the end, this host was running an open DNS resolver configuration, and was 
being lightly abused as part of a reflected DDOS. 

Interesting things of note for me: the use of requests for usadf.gov to get 
their multiplier, the fact that the software chose to fragment the reply even 
though (I thought) typical process would be to force use of TCP since the 
answer wouldn’t fit in a standard sized packet (although this option seen in 
the attacks gives a clue: OPT UDPsize=9000). 

Another interesting note was how argus and tcpdump treated the traffic…Argus 
accepts the filter “port 0” and reports on the flows with fragments. TCPdump 
does NOT seem to treat the fragmented UDP traffic as “port 0” which is 
interesting (and likely just as correct, if a bit misleading to the admin I 
asked to check for port 0 traffic initially). 

Thank you all for this discussion! I love this idea around the 1918 space, as 
well as the other reserved space. I suspect that the additional reserved 
space has some holes (in terms of local ACL’s allowing in/out traffic) and a 
“one pager” on these addresses, how to check for valid/invalid traffic using 
them locally, etc. might be well received.

Cheers,

Jesse 

> On Jan 8, 2019, at 11:08 AM, Spurling, Shannon 
> <>
>  wrote:
> 
> We have run into many fragmentation scenarios for VoIP and Micro Cell 
> setups, where port 0 traffic is part of the fragments being detected by 
> access list and Netflow. Most of those use UDP as transport. 
>  
> Shannon Spurling
>  
> 
>  
> From: 
> 
>  
> <>
>  On Behalf Of David Farmer
> Sent: Tuesday, January 8, 2019 10:02 AM
> To: 
> 
> Cc: gcbrowni 
> <>
> Subject: Re: [Security-WG] Security group highlights - December 2018
>  
> Also, I think packet fragments, other than the first fragment, are recorded 
> as port 0 in NetFlow data since there is no TCP or UDP header in subsequent 
> fragments. 
>  
> On Tue, Jan 8, 2019 at 9:10 AM John Kristoff 
> <>
>  wrote:
> On Tue, 8 Jan 2019 14:09:34 +0000
> gcbrowni 
> <>
>  wrote:
> 
> > Not to pile on too much, but we’re even being UDP port 0 attacks in
> > the analysis we’re doing in Deepfield Defender.  Much like 1918, etc,
> > UDP port 0 is something that we should never see since its invalid.
> 
> It might usually be, but strictly speaking this is not necessarily so,
> at least not when it is a source port value.
> 
> From 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.
> 
> In my experience, I seem to only recall seeing source port zero used in
> some IP multicast app a long time, I think most apps just set a
> non-zero value even if they don't expect a response.
> 
> Here is a template I have been using at our borders if it helps any:
> 
>   <https://github.com/jtkristoff/junos/blob/master/firewall.conf>
> 
> There is very little I can throw away outright, but you'll see the
> bogon prefixes I use.  There are some bogus bit combinations that should
> be safe to drop for many environments (e.g. deprecated ICMP types and
> internetwork IGMP), but there may be corner cases for some networks
> where these might be desirable.
> 
> John
> 
>  
> -- 
> ===============================================
> David Farmer               
> Email:
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota   
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================

--
Jesse Bowling
ITSO::Security Architect & CSIRT Program Manager
jesse.bowling[AT]duke.edu::919-660-1073
334 Blackwell St::Durham, NC::27701

Attachment: smime.p7s
Description: S/MIME cryptographic signature