0

How can I add a firewall rule in iptables such that I allow packets only for a particular SSL connection.

I currently allow/deny ssl packets based on content type, for example, the following rule will block all application data packets for TLS. It allows other type of ssl handshake/alert packets to go through but will block the application data packets.

iptables -I FORWARD 1 -p tcp -m state --state NEW,ESTABLISHED  -m u32 --u32   "0>>22&0x3C@ 12>>26&0x3C@ 0 & 0xFF000000=0x17000000" -j DROP

If at a given point in the future, I want the end points to communicate, How do I allow packets only for a single ssl connection.

As far as I know, the following considerations apply in place -

1.There can be only one ssl session in one tcp connection.

2.There can be multiple tcp connections between two endpoints and hence multiple ssl connections for a src and dst ip address.

3.I can obtain handshake value of the ssl connections as unique identifiers.

4.In case of session re-assumption, a new tcp connection will be used.

I want to allow packet specific to a ssl connection. Is it possible to use the conntrack/state module to allow packets only for a single tcp session. ?

Improve this question
0

TLS session reuse is a process with multiple steps. First there is a full TLS handshake in which the server might give the client a session id and/or session ticket for resuming the session at a later time. In a later TLS handshake (i.e. new TCP connection) the client then might offer this session id or session token in the TLS handshake. If the server agrees and the session actually gets reused can only be seen by analyzing the next messages in the handshake, i.e. if it is a full handshake (no resume) or not (successful resume). To track all this you would need code with a more detailed understanding of TLS messages and which can also keep more than just the TCP state over multiple packets. I doubt that this can be done with the usual iptables, i.e. not without some special (and probably not existing) modules.

In general a layer 3..4 filter (i.e IP, TCP, UDP) like iptables is not an adequate tool to do layer 5..7 (TLS, HTTP...) filtering. While it might seem to work in some cases it can often easily be bypassed by splitting data into multiple packets so that blacklisting packets like in your example will not match any longer the single packet they analyze.

Improve this answer
  • As, I understand this, I ultimately need to keep track of a TCP session. A ssl connection would be encapsulated by a tcp session. I do not need to track ssl sessions as they would require maintaining a ssl state on the firewall. see ibm.com/support/knowledgecenter/SSB23S_1.1.0.9/… . Would you know of any tls filtering firewalls in linux – user647332 Dec 6 '16 at 3:10
  • @AbhimanyuKhanna: The same SSL session can be used within multiple TCP connections and these can also run in parallel. And as I said layer 3..4 tools like iptables are not adequate for layer 5..7 filtering. It is not really clear what you are trying to accomplish with such a filter anyway so maybe you should explain why you want to restrict traffic to a specific SSL session. – Steffen Ullrich Dec 6 '16 at 3:13
  • Sorry, I used the wrong word to describe the question. I want to keep track of ssl connections and not ssl sessions. I am trying to work on a proof of concept ssl filtering firewall. – user647332 Dec 6 '16 at 3:19
  • @AbhimanyuKhanna: Only sender and receiver can keep track of the internal state of the SSL connection. All you can do is check if the connection starts with a TLS handshake and then track the TCP connection. I'm not sure what your SSL filtering firewall should really do (block all SSL traffic?) – Steffen Ullrich Dec 6 '16 at 3:37
  • For now, I am looking to do filtering based on ssl header type and on ssl connections. Yes, I am looking to track tcp connections for now. How can I do that ? Specifically, given a IP address, how can I only allow packets for a single TCP session ? – user647332 Dec 6 '16 at 3:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy