iptables: verify traffic on port to check if it is legitimate for that port.
 

Hello,

Is there any way to verify if packets being trafficked over a certain port are valid for the service you want to use this port for?

One obvious example that probably clarifies my question:
When I open port 443 (outgoing or incoming) for https/ssl traffic, I don't want this port to be used for say openvpn traffic.
Thus: when someone wants to surf to a website with https, it should be ok but if someone wants to connect to his home openvpn server over that same port, it should be blocked.

I can't seem to find the correct description for this kind of technique to give me any good results on the google.

thanks for any advice,

Lieven

FOr things like this you need some form of proxy, it's nothing to do with iptables at all. In your OpenVPN example the traffic would be valid though, as it's a proxy capable SSL VPN, so would go to a proxy and ask to CONNECT to a remote point with SSL, which is exactly the same as a normal web connection. There is nothing to descriminate between. You can look at terminating SSL on the proxy and reencrypting, using, for example, squid3, but that's no fun really.

proxy port check service
 

Thanks for the tip,

I was hoping that iptables had an extension for this but in fact the proxyserver seems to be the more appropriate place to do this. (as you state correctly)
I was already using the openvpn 2.1 function --port-share, it can differentiate between traffic for itself and real https traffic.
But the openvpn example is just an example.

thanks for your help.

iptables can do string matching and the likes, but it's not really something suitable to iptables. the port sharing is, in itself, a proxy, so is not distinguishing real https traffic, but real http traffic, i.e. the stuff inside the tunnel, which iptables has no business seeing.

https
 

that is a good point indeed. In the frequent case of openvpn/https, how can iptables even look in the ssl stream? It should probably play man-in-the-middle but the certificates would probably be wrong/unsecure.

Is there a header or something that distinguishes openvpn? That would be encrypted too, no? So openvpn first has to decrypt the ssl which it can only do if the data was signed with the correct key? (I'm wondering how this --port-share function works)

String matching would not work, anyway, I really want to avoid iptables string-matching feature as it seems to be error-prone due to the fact that packets don't really care about strings, right?

I will look in the direction of transparent proxy, maybe squid, and/or snort to check if the data going through the port in question is actually ok for the service listening on that port. I don't want bad packets and don't want anybody from inside using the open port for anything except for the service it was meant to serve. (http, https, ssh, smtp, ...)


If you have any more tips, they are always welcome but the question were to look for a solution seems answered. :-) Much stuff to research! :-))

thanks!

well the ssl tunnel will be established between the client and the openvpn server as I understand it, and a conventional tunnel is established. Note that the http CONNECT method is only relevant to proxying (AFAIK) and a normal direct HTTPS connection uses no HTTP methods at all until after the connection is established (which leads to awkward issues like not being able to server multiple certs on a single port) so the client can connect to anything that talks SSL in the first instance. The OpenVPN server can then look at what is asked off it by the client. If it sees "GET / HTTP/1.1\r\nHost: www.server.com\r\n\r\n" then it can take that request and spit it at a real web server, and similar things are possible for SSH, where the client explictly identifies itself with a similar string, and could point that traffic at a real SSH server, and of course, whatever identifies a VPN request (which could well actually be a specific HTTP request) for itself and acts accordingly.