2

I need to filter (send to BANRULES set) incoming http/https packets with a certain string (matchword). I do it easy when ssl is not in use (port 80):

iptables -A INPUT -p tcp -m tcp --dport 80 -m string --string "matchword" --algo bm --to 65535 -j BANRULES

But it does not work (because of packet encryption) when ssl is in use (port 443):

iptables -A INPUT -p tcp -m tcp --dport 443 -m string --string "matchword" --algo bm --to 65535 -j BANRULES

How can I do this? Thank you.

fukawi2
  • 5,396
  • 3
  • 32
  • 51
Carlinhos
  • 21
  • 2

2 Answers2

3

@DanFarrell is partly correct in as much as you need the secret key to decrypt it - however if you have the secret key (ie you own the webserver thats being banned - which is implied as you say the packets are incoming) it can be decrypted - but probably not by iptables.

You may be able to set up a reverse proxy (or depending on your network even offload the SSL handling to your iptables based firewall) - it may require running something like Squid (or a webserver with mod_proxy or equivalent). Here is an example of how to do this with squid.

davidgo
  • 6,222
  • 3
  • 23
  • 41
  • This might be possible, unless PFS is being used, in which case even that isn't enough. "As of December 2014, 20.0% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to web browsers" (http://en.wikipedia.org/wiki/Forward_secrecy) – erik258 Dec 16 '14 at 00:11
  • I don't see how PFS does anything if you are, in effect, performing a man in the middle attack in realtime, so I don't think this is correct. PFS is, I believe, used to ensure that if the private key of a session is compromised at some point after the communication it can't be used to decrypt the communication. Certainly PFS does not prevent MITM attacks. see the section at "Limits of forward Secrecy" at http://randomoracle.wordpress.com/2013/10/14/forward-secrecy-and-tls-limits-of-pfs-ciphersuites-part-i/ also the second post at http://sla.ckers.org/forum/read.php?6,7024 – davidgo Dec 16 '14 at 00:20
  • "there is not a single secret value which can lead to the compromise of multiple messages." I rather thought keypairs were generated on the fly to accomplish this, but I don't see any mention of that on the wikipedia, so perhaps each secret key could actually be pulled from the negotiation, but I am not sure it's ever transmitted. – erik258 Dec 16 '14 at 00:25
  • If you have the private key for the SSL certificate (which as the owner of it, you would) then you can encrypt and decrypt data with it at will, this includes on a reverse proxy server. PFS may cause issues decrypting existing connections, however as all connections would likely be severed while setting up the reverse proxy, this should not be an issue. – Foxocube Dec 16 '14 at 00:26
1

Can't be done. You can't decrypt just HTTPS traffic; you need the secret key to decrypt it. That's the whole point of HTTPS - the TLS layer protects against snooping at points in the path between server and client.

erik258
  • 766
  • 5
  • 9