I wish to block a few websites that also run upon https, like facebook, twitter, and gmail, in my organization. Squid is not supposed to be used here as per the orders from higher management. We can use Untangle Lite Package and iptables.

Is there any option other than Squid to do this? Also some iptables rule to block this kind of traffic would be really helpful.

I found this

iptables -t filter -I INPUT -m string --string facebook.com -j LOG --algo bm
iptables -t filter -I INPUT -m string --string facebook.com -j REJECT --algo bm

but https still works on machines except the local machine.

  • 2
    you should explain your company that avoiding https for personnal account is not a good idea as it could lead to steals of identity inside the company,deploying a certificate on all machines and act as a man in middle would be a much better way to check who's connecting to facebook. also i'm not sure, but I think it's not possible anymore to connect gmail without https.
    – Kiwy
    Mar 11, 2014 at 8:36
  • May i know how you got all those IP addresses pls
    – Jagadeesh
    Feb 19, 2015 at 12:22

6 Answers 6


Instead of matching based on the URL, try matching based on contents of the certificate.

iptables -t nat -I INPUT --sport 443 -m string \
                 --string www.facebook.com --algo bm -j REJECT

You can also match on the fingerprint but if the destination changes or updates their certificate, it will invalidate your rule.

  • can this block anything that matches www.facebook.com even in the html body, but that is legitimate like this on the comment box. It can be blocked at the url level, but what about the ipaddress? Jan 28, 2012 at 11:06
  • @NikhilMulley: No, it will only match the SSL certificate served by Facebook. Everything else is encrypted and can't be seen.
    – bahamat
    Jul 23, 2012 at 22:33
  • 3
    Only the first packet of a connection enter the nat table (and there's no INPUT chain in the nat table), I think you meant filter there. Also, there's a (very) remote chance that it matches packets where 443 is the client port Oct 30, 2012 at 22:03
  • Have anyone used this solution? Apart of the lacking of -p tcp for the rule, this doesn't seem to be something useful..
    – ivanleoncz
    Sep 27, 2017 at 18:53

The firewall cannot control which HTTPS URLs the client is trying to access, because the URL is encrypted. The firewall can only control which sites the client is connecting to, using IP addresses, but this doesn't help if the HTTP and HTTPS versions of the site are at the same URL (and even if they aren't, you'd have to maintain a huge list of IP addresses).

The only realistic way to block HTTPS is to block it altogether. Insist that all connections must be valid HTTP (i.e. the client starts by sending an HTTP line, and so on). This can't be done with just IPtables, you need an actual protocol-aware proxy such as Squid. (I don't know what Untangle Lite is capable of.)

You can block most HTTPS traffic by blocking outgoing traffic to port 443, since almost all HTTPS servers are on that port. Or, following a whitelist approach, only allow outgoing traffic to port 80 (the normal HTTP port).

A different approach would be to proxy all HTTP and HTTPS connections. Then you can match by URLs. This require conducting a man-in-the-middle attack on the clients. You can do that if you deploy your own certification authority to all client machines and register it there as a root of trust. This may be considered unethical.

No matter what you do, determined users will set up a proxy outside your environment and run IP over HTTP or something like that.

You appear to be either trying to fix a social problem with technical means, which hardly ever works, or to be doing your best to implement a silly requirement from management (in which case, I'd go with blocking port 443, perhaps only for certain IPs, which would allow you to report that you've done your job, no matter how useless).


I know of one option.

If you have internal DNS servers for use, then put some static references in your TLD zone data that resolve the domains (that you do not wish to establish the outside connections) to just This way, all the hosts using the central DNS within your network will resolve ( facebook.com/twitter.com per se) domains into loopback address, which will lead nowhere.

This will work if you have total authoritative control on your network's client machines resolver configuration. If the workstations/clients have permissions to change/edit either /etc/hosts, or /etc/resolv.conf then they may circumvent this option.

  • +1 for that. This can be done by inserting these references in the /etc/hosts file. For example: www.facebook.com
    – user13742
    Jan 11, 2012 at 14:45
  • 2
    Or, for a more civilised solution, set the DNS A records (or hosts/hosts.txt entries) to refer to an intranet host with a webserver which explains exactly why the user was not sent to Facebook, etc. Please note that this breaks HTTPS because the intended hostname (e.g. www.facebook.com) won't match the certificate CN.
    – Alexios
    Jan 12, 2012 at 7:26
  • @Alexios: OpenDNS is a great solution for this.
    – Kevin M
    Jan 28, 2012 at 13:27
  • @KevinM: thanks, that's useful to know. I'll keep it in mind (though we have our own little DNS farm at work)
    – Alexios
    Jan 28, 2012 at 13:47

An option is to blackhole routes to network blocks: (Listed are for FB)

ip route add blackhole
ip route add blackhole 
ip route add blackhole
ip route add blackhole
ip route add blackhole
ip route add blackhole
  • 1
    no it's not, it way to complicated to maintain a list of ip for facebook twitter or even google who do not communicate it's own ip range ranges anymore.
    – Kiwy
    Mar 11, 2014 at 9:05

You should put this on FORWARD chain, e.g.

iptables -I FORWARD  -m string --string "facebook.com" \
                     --algo bm --from 1 --to 600 -j REJECT

It will affect other systems on the network, except firewall.

  • This is actually better than @pr0f3550r command since (1) it's in the filter table and (2) it uses the FORWARD chain which means it affects my LAN, but not my server. Nov 8, 2020 at 20:07

Plain content filter can not block ssl site.

Use intrusion protection tools like snort/suricata.

Sample IPS rule : For blocking ssl URLS for specific IP address.

drop ip any 443 -> any (content:".facebook.com"; msg:"Simplewall Ssl block for User30 : Urls => .facebook.com " sid:26648513;rev:1;)

drop ip any 443 -> any (content:".fbcdn.net"; msg:"Simplewall Ssl block for User30 : Urls => .fbcdn.net " ;sid:11469443;rev:1;)

drop ip any 443 -> any (content:".youtube.com"; msg:"Simplewall Ssl block for User30 : Urls => .youtube.com " ;sid:13989722;rev:1;)

Download Simplewall : In simplewall policy rules shared by Squid + Suricata IPS.

Not the answer you're looking for? Browse other questions tagged or ask your own question.