Getting **** blocked by Cox…

I have had Cox cable as an internet service provider for some time now, and their overall service has impressed me up until this point. Today I was working away on some home lab projects which relied on HTTP/HTTPS for the server authentication required to obtain an HTTPS certificate through Letsencrypt (an organization who continues to be one of my favorites). It turns out the Cox blocks or “filters,” as they so elegantly put it, a long series of standardized ports that are very important to us home-lab aficionados. The blocked ports can be found along with their shallow, poorly based excuses on this Cox KB article, and include:

  1. Port 25: SMTP
  2. Port 80: HTTP
  3. Port 135: NetBIOS
  4. Port 143 IMAP; and
  5. Port 1133/34: SQL Databases.

Some of the excuses Cox uses to justify the blocking of standardized ports is honestly mind-boggling. For example, the rationale they have behind blocking HTTP traffic on port 80 is that they are “protecting bandwidth by preventing customers from running high-traffic web servers” and attempting to “stop many destructive worms that spread through security holes in web server software.” Both of these excuses, however, are falsely based (not to mention filled with logical fallacies, gotta make the English teachers proud). Reason one is that it takes just as much data (if not more) to browse the web as it does to run a server, and, in most cases, web server files are designed to be lightweight and use even less data than your average internet user. If Cox were so concerned about their bandwidth utilization, they would block media and online gaming assets first. Secondly, the argument “stop many destructive worms,” has about as much to stand on as someone who has been eaten from the waist down by actual worms.

In today’s day and age of “fire-and-forget” security solutions which are reasonably effective at managing themselves (such as Windows Defender backed by continually updated virus definitions from Microsoft), it is becoming increasingly difficult for hackers to do their jobs effectively. Meaning it is much more difficult for a hacker to be able to compromise a system by any means, let alone a strictly HTTP based worm. Now that we have covered the reasons behind this excuse being false from a client standpoint, we can easily take out the server-side of things.

It is reasonable to look at web servers as being vulnerable, as most are based on Linux distributions; which require some understanding of both networking and Linux fundamentals to properly harden against threats. That being said, anyone who poses the ability to set up a web server at home, complete with proper networking (such as port forwarding) is bound to have enough background knowledge to perform even the most basic of security practices. The combination of Fail2Ban and a simple, but powerful, SSH key are enough to slow even state-sponsored cyber threats. It is said that if fifty supercomputers that could check a billion billion (1018) AES keys per second (if such a device could ever be made) would, in theory, require about 3×1051  (3,153) years to exhaust the 256-bit key space [2]. So let us say that a person doesn’t know how to set up a web server at home. Then they are very likely to turn to a contractor such as BlueHost or GoDaddy; both are perfect examples of hosting providers with dedicated security teams and practices that are carried out across all client accounts.

Why Bother?

This is our final, and perhaps the most compelling argument against Cox blocking standard ports: why even bother. One of the primary reasons we say why not to bother is because it is incredibly easy to use a proxy and non-standard port to easily circumvent Cox’s efforts (which we will provide an example of below); which is what we are doing right now. The second reason we say why bother is that, as previously stated, web files are incredibly lightweight. After all, HTTP stands for Hyper Text Transfer Protocol. It is built on the concept of transporting nothing but a text document from a server to a client and having client web browsers interpret and present that data. For example, to load a Facebook page, filled with dynamic content, photos, and videos, only takes a 1.6 MB transaction, and the rest of the work is done by the client, not the server. Not to mention there are a wide variety of extensions for the most common web servers that leverage browser caching and compression, further negating the argument of “bandwidth heavy” web servers.

Other reasons why port blocking is malarkey:

To be honest, it would be a genius idea to use port blocking to force residential clients to switch to more expensive business accounts if they wanted to do anything even remotely outside of our definition of “residential” applications. In actuality, that is what Cox does. I called Cox to inquire about port blocking, and the only solution to have Cox remove port blocking is to upgrade to a business account. In fact, the support technician let her documentation slip, stating “do not escalate requests for port blocking to tier two support, removing port blocking is not supported for residential clients” as she read the support documentation out loud. That being said, if you are like me and want port blocking removed, do not call Cox for a solution; you will find when it comes to this matter Cox tier one technical support is about as knowledgeable about computers as any one of their given KB articles.

So what is a home lab user to do?

Well, fortunately, the solution to this is simple if you’re using a web server like NGINX (and if you’re not, we highly recommend you do). Fortunately, NGINX natively supports a variety of proxy configurations, as it was originally designed as both a web server and proxy. A sample configuration can be seen below.

location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Place the above configuration on a server outside the Cox system (such as those that can be created with DigitalOcean for $5/Month), have it refer back to your home server(s), and viola your cooking with gas. So, unless Cox is planning on blocking every port known to man, you will continue to be good to go. Hint, this configuration also helps for cleaning up things like Plex, PHPMyAdmin, etc., and supports HTTPS configuration on the front end as well.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.