2

I know this have been a very asked question here at serverfault, nevertheless i haven't got a consise answer (or havent read enough :D) i also know that some of you may think that it is an antimanager practice (it probably is) but the point it has to be done...

currently i was applying a iptables blocking policy combine with squid but that did not work because we need access to certain google sites or skype service and those are access by https and also interchange their ipaddress is really hard to keep the track...

A friend of mine recommend me Astaro i haven't see it yet, can you advice a tool that does a filtering/domain by port site?

Edit The question

Is there a way to block HTTPS sites by domain or the best approach to do it? Astaro seemed like an alternative but it pretty much look like a plain old web proxy

3
  • 2
    ... what's the question? Are you wanting to know about iptables, blocking :443 or experiences on the Astaro appliance, or....? Feb 9, 2011 at 3:42
  • what's your budget? Feb 9, 2011 at 3:46
  • @SpacemanSpiff 'none but if astaro worked then it would be a good for sure geting it
    – Necronet
    Feb 9, 2011 at 5:02

2 Answers 2

1

The trick is to use Squid with authenticated users. SSL traffic can't be proxied if you are running a transparent proxy. Squid can run both ways at the same time (on different ports):

http_port <ip>:3128 transparent
http_port <ip>:8080

You would obviously have to add some rules to allow and deny authenticated users to navigate where it is allowed or forbiden. Still, users who are accessing the web transparently, will be forbiden access to HTTPS if it is blocked on your firewall.

The other way (more dirty one), would be to get the sites allowed from a file, get their DNS records, and update/remove rules, something like:

Set a rule like this:

iptables -N SSL_FORWARD
iptables -A FORWARD -s <NET> -p tcp --dport 443 -j SSL_FORWARD
iptables -A FORWARD -s <NET> -p tcp --dport -j DROP

This would create a new chain SSL_FORWARD, and send packets coming from your net destined to port 443 to be evaluated on this new chain. If the packet doesn't match any rule inside this chain, then it will be dropped.

Then, regularly execute this little script:

# Flush SSL_FORWARD chain
iptables -F SSL_FORWARD

# Iterate through each line of this file, and then get
# it DNS records
for domain in `cat /path/to/allowed.domains`; do

  for line in `dig ${domain} +short` ; do
    [ -z "`echo ${line} | grep '^[0-9.]*$'`" ] && continue
    iptables -A SSL_FORWARD -s <NET> -d ${line} -p tcp --dport 443 -j ACCEPT
  done

done
1
  • +1 for a great, thorough answer.
    – nedm
    Feb 9, 2011 at 4:24
0

Similar situation with me. I use a bash script to convert a list of domain names, e.g.:

www.youtube.com
www.vimeo.com
www.facebook.com

Into a list of IP addresses. Then, I fed the list of IP addresses into ipset:

ipset -N Blacklist iphash
for ip in ${iplist[@]}; do
    ipset -A Blacklist $ip
done

Finally, I apply the IPset to iptables:

iptables -A FORWARD -p tcp --dport 443 -m set --match-set Blacklist dst -j DROP

The benefit: Every morning a cron job re-resolves the domain list into an IP list and updates the Blacklist set, and I don't have to touch the iptables rule at all. The update script uses -F instead of -N for its first line.

2
  • nevertheless there is a problem with sites like youtube 'cuz you don't quite sure when they change their ips.... also what happen when it comes the time to give access to skype application that use it a dsitributed authentication mode... is kind of messy i am thinking of something like WebSense to secure my network but haven't test it yet....
    – Necronet
    Mar 7, 2011 at 17:04
  • Well, you can always shorten the cron period to 1 hour. But it's your call, anyways.
    – pepoluan
    Mar 8, 2011 at 4:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .