[SOLVED] iptables: verify traffic on port to check if it is legitimate for that port.
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
iptables: verify traffic on port to check if it is legitimate for that port.
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.
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.
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.
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.
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! :-))
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.