0

Scenario: I wrote iptables rules for a host where a DPI engine is watching Netfilter queues: firewall rules enqueue traffic incoming to this host into different Netfilter queues depending on whether traffic is coming from a certain ipset of mine.

In the FORWARD chain, all connections are enqueued in different NFQUEUES: DPI engine is watching in userspace queues the packets sent by iptables, if a forbidden connection is observed it marks the packet with a special value; DPI engine reinsert forbidden packets in the stack; in the POSTROUTING chain I check if connections are marked with that special value, if so I DROP them.

It is all working fine, but...

Problem: the DPI engine is fine, but not perfect: sometimes,

  1. traffic that should be identified as forbidden is not identified as such and therefore it is not blocked;
  2. forbidden traffic is blocked but not immediately, and a forbidden connection in the meanwhile may open another connection (RELATED, according to the conntrack machine) that is not marked as forbidden, but I'd like to block the related connection as well.

The second case is the one where I want to take action: as an example for case 2, imagine that DPI engine wants to block YouTube but he's not managing to do it rapidly; it lets YouTube connection to open another connection which is labeled as SSL from DPI engine; DPI engine finally blocks YouTube, but the SSL connection is wild and free to go; I can't tell the DPI engine to block SSL connections, regardless of what connections did open them.

Considerations: as explained in Scenario, packets coming in POSTROUTING chain may be marked with 0 (which is the default value, so DPI engine took no action) or with that special value (DPI engine saw a forbidden connection and marked it): a simple

iptables -t mangle -A POSTROUTING -m mark --mark DROPVALUE -j DROP

is almost always enough, but in Problem section I wrote that connections RELATED to the forbidden ones but are not seen as such by DPI engine, because even if they were created by a forbidden connection, its protocol is not blacklisted and because of this they are not seen as forbidden. This is right because I can't blacklist SSL and HTTPS.

I need to block connections RELATED to forbidden ones: RELATED and ESTABLISHED (if I understood well) do not refer to particular connections but I need to refer to forbidden connections.

Question: is it possible to drop connections RELATED to connections to drop (or already dropped) in iptables? Or some hack with conntrack is necessary?

Thanks in advance for any suggestion.

elmazzun
  • 133
  • 1
  • 1
  • 7

1 Answers1

0

You misunderstand RELATED. This is not used for every connection that a single address might make. It is used only for actually related data, such as the FTP data stream associated with an FTP control connection, or ICMP error messages associated with an open connection. There are very few such connections that will actually match RELATED.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Not for every connection of course. DPI engine starts blocking from the first steps of a connection like the DNS request from client, but if it fails then a connection is established and more than one connection is necessary to get a working video in YouTube: if DPI fails to block DNS, then the client connects to download HTML page of YouTube (with other connections opened and closed bere) and other connections are needed to stream the video. Are the connections opened to download HTML and video still not RELATED? – elmazzun Mar 12 '18 at 16:39
  • @elmazzun In the context of iptables, none of those connections are RELATED. – Michael Hampton Mar 12 '18 at 16:41
  • I don't see how a connection to `googlevideo.com` where the actual video is downloaded is not RELATED to the connection to `youtube.com` that started it all other connections in order to achieve the full page with all its contents, but if this is the answer guess I'll tinker with conntrack. – elmazzun Mar 13 '18 at 08:32
  • @elmazzun It is a completely separate and unrelated connection as far as iptables is concerned. I already explained this, or I thought I did. Perhaps I didn't do a very good job. – Michael Hampton Mar 13 '18 at 17:07
  • It may sound strange to me but if this is the concept of a related connection in iptables context, I am fine with this. So I misunderstood RELATED, and your answer is rather a correction to my wrong assumptions. Should I delete this question? – elmazzun Mar 13 '18 at 17:23