Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
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 at 8:36

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.

share|improve this answer
    
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? –  Nikhil Mulley Jan 28 '12 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 '12 at 22:33
    
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 –  Stéphane Chazelas Oct 30 '12 at 22:03

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).

share|improve this answer
    
professional firewall like Checkpoint allow https filtering without deploying a client certificat in the latest version, I don't know how they manage to do it, but it works. –  Kiwy Mar 11 at 9:01

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 127.0.0.1. 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.

share|improve this answer
    
+1 for that. This can be done by inserting these references in the /etc/hosts file. For example: 127.0.0.1 www.facebook.com –  Herman Torjussen Jan 11 '12 at 14:45
1  
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 '12 at 7:26
    
@Alexios: OpenDNS is a great solution for this. –  Kevin M Jan 28 '12 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 '12 at 13:47

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

ip route add blackhole 69.171.224.0/19
ip route add blackhole 74.119.76.0/22 
ip route add blackhole 204.15.20.0/22
ip route add blackhole 66.220.144.0/20
ip route add blackhole 69.63.176.0/20
ip route add blackhole 173.252.64.0/18
share|improve this answer
    
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 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.

share|improve this answer

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 -> 192.168.3.30 any (content:".facebook.com"; msg:"Simplewall Ssl block for User30 : Urls => .facebook.com " sid:26648513;rev:1;)

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

drop ip any 443 -> 192.168.3.30 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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