Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are currently doing port whitelisting on our firewalls which is working well but this of course does not prevent the implementation of side channels or the misuse of these ports for other purposes. For example, an attacker could still initialize a netcat backconnect session when the outside listener is listening on port 80.

Is there a way to analyze the payload of every packet to ensure that it is using the protocol that is usually assigned to the destination port?

This is of course only an example and I'm aware of the possibility to hide the payload in a seemingly correctly designed payload. It's all about making it harder for the bad guys.

share|improve this question
up vote 20 down vote accepted

IDSs and several deep inspection firewalls (sometimes called NGFW or UTM) can usually detect whether the traffic is HTTP or not. Also a reverse HTTP proxy in front would simply block anything which is not proper HTTP.

But be aware that it is possible to build a reverse shell where the traffic will look like HTTP, so this filtering will only help a bit.

share|improve this answer
Indeed it's possible to build a remote shell where the traffic is HTTP. – immibis Feb 18 at 1:32
This is particularly easy using WebSockets, which you arguably don't want to be blocking in most cases. – Kevin Feb 18 at 4:38

The attacker can easily mimic HTTP traffic, so I will doubt any IDS/IPS would prevent a well developed shell from mimicking HTTP requests to exfiltrate data. It's very easy to create a fake HTML page, embed the images with <img src="data:image/png;base64,iVBORw0KG…8bg5CYII="> and put the traffic inside.

A lossless compression (like PNG) will allow the sending of whatever data is needed to the client inside, and data can be sent outside using <form action="" method="post" enctype="multipart/form-data">.

share|improve this answer

Advanced IPS/IDS can help you. but there are some kinds of firewalls that are completely customized for web (HTTP/HTTPS).

They are called WAFs, Web Application Firewalls.

A good WAF with a proper configuration can prevent many attacks, like the one which you're speaking about.

share|improve this answer

This is of course only an example and I'm aware of the possibility to hide the payload in a seemingly correctly designed payload. It's all about making it harder for the bad guys.

It's not merely "possible." It's easy. In fact, under HTML5, it is downright trivial.

With WebSockets, an HTTP-like connection can tunnel arbitrary content between client-side Javascript and a server-side web application. This is an explicit design goal of the standard, not a happy accident. While you may be able to block WebSockets, this is likely to break real-world webapps. Worse, if the attacker's site is served over HTTPS (which is also easy), you basically cannot block WSS since this would require you to conduct an active MitM attack of precisely the sort that TLS is designed to prevent.

You could issue your own root certs, install them on all your client machines, and MitM that way. But now you're playing walls and ladders with your users. By breaking WebSockets, you are giving them an incentive to find a way around your system.

The problem is that HTTP is not a "safe" or restricted protocol. It was designed to facilitate the sharing of HTML documents. It was not designed to impede uses unrelated to the sharing of documents. So, in practice, it can be used and abused in numerous ways, and avoiding this is pathologically hard.

So what can you do? Well, it depends on what you are trying to do in the first place.

If you're (say) a college, and you are trying to prevent students from consuming massive amounts of bandwidth playing online games, illegally torrenting things, etc., then track their bandwidth usage and block the top N% (for realistic N based on your network capacity).

If you're a business, and you're trying to prevent certain kinds of malware from phoning home, you should probably focus on educating your users about malware, in addition to whatever kind of non-HTTP blocking you are doing.

If you're just blocking non-HTTP because you can't think of a good reason to allow it, you should ask yourself what your threat model is. What attacks will be mitigated by this kind of blocking? What legitimate uses will stop working? Is the policy likely to annoy your users to the point that they try to circumvent it?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.