Editor’s note: Imported from my old personal blog @ TC with minor edits to improve readability where necessary.
For many years I’ve resisted and lobbied against implementing most every middlebox in a network I’ve had administrative influence over. I’ve been especially adamant when the proposed middlebox would reside at large aggregation points, such as the so-called “border” of large organizations. I’ve found these middleboxes to be short term hacks for more fundamental problems that could be better addressed another way. While arguably middleboxes fix otherwise difficult to solve problems and many people like them, they often come at great expense. That expense is not only felt financially, but architecturally in the erosion of hard to quantify, but intuitively useful network properties such as flexibility, simplicity and transparency.
One consequence of a common middlebox function is when a perfectly legitimate packet is prohibited as a result of an unlucky combination of bits in said packet. You may often see this in the form of a rudimentary router packet filter mechanism or a more sophisticated firewall filter rule system. By way of example, here is a situation where an innocuous attempt to resolve www.cisco.com to an IPv4 address will fail because of an unlucky set of bits that are not permitted due to a UDP port filter between Cisco’s network and the rest of the Internet:
dig -b0.0.0.0#1434 @ns1.cisco.com www.cisco.com
Altering the command slightly, the following query will succeed:
dig -b0.0.0.0#1435 @ns1.cisco.com www.cisco.com
In the first query attempt a source port value of 1434 is specified. In the second, 1435 is used. Why does 1434 not work? Many years ago there was a nasty computer worm commonly referred to as Slammer that took advantage of a remotely exploitable Microsoft SQL Server vulnerability over UDP port 1434. Many operators applied port 1434 filters to stem its spread. The worm outbreak began in early 2003 and it was widely reported that virtually all the Internet-accessible vulnerable systems, approximately 75,000 of them, were infected within the first 10 minutes. The artifacts of the 1434 filter persist to this day.
While there are still remnants of Slammer infected hosts, our insight indicates that on average there are only a few hundred unique source addresses per day showing signs of an infection. I recently sampled the extent of the port 1434 filter by issuing UDP DNS queries for all the nameservers for each domain in the .edu zone using a source port of 1434. Approximately 11% of the unique name servers used by .edu’s failed to respond. Moreover, of those that filter UDP port 1434 messages, approximately 37% also filter TCP port 1434 segments.
Do note, while I tested port filters using DNS queries to DNS servers, the likelihood of the filters being applied only to DNS queries and DNS servers is highly improbable. Its reasonable to assume that these filters apply to all applications between the tested networks and the greater Internet indiscriminate of intent. DNS service was simply a convenient application for which I could test. Ephemeral source port selection is a bit of a gamble. Its difficult for endpoints to know when middleboxes are present or to know what unlucky combination of bits will result in a packet being filtered. Certainly there are other applications and ports that share the same fate as 1434. Examining them in detail may be the subject for a future post.
A typical security practitioner might ask what the big deal is. Even if source port selection was uniform, which it isn’t, the chance that an unlucky source port will be selected is low and even then, some applications gracefully recover without user intervention. You can probably guess my feeling toward port filtering as generalized security tool is that it often lacks rigor and imagination, but I don’t expect to change any minds or port filters with this post. Having gotten anyone to read this much about it is enough.