HTTPS vs ISA Server

Block all IP addresses associated with Facebook as well.

Yes, FB's known public IP address [173.252.110.27] was the first thing I put in the access rule, but didn't work either when users specifically enters "https://www.facebook.com" in the address bar of their browser.  Does HTTPS make the huge difference?  Also, does it represent a different IP address?

Thanks.

Thank you very much, Netman.  Is there any other advice or solution?  Would you think that HTTPS traffic are encrypted and thus are able to bypass the access rule I created?

It's possible the SSL traffic is obfuscated, but the initial site request should have failed.

Maybe a port 443 rule to that domain?

Thanks for the quick advice, Netman.  Here is what really happens.  When I go to either one of these, the rule works (which blocks access to the site):

   - facebook.com
   - www.facebook.com
   - http://facebook.com
   - http://www.facebook.com

However, when I go to "HTTPS://www.facebook.com", then the rule is circumvented and I could enjoy Facebook during working hours.

Thanks for your prompt comments again, Netman.  I really appreciate your time - and all of your comments make sense.  However, I've just found a little note on the dialog box that is used for entering the URLs for the Access Rule.  The note says "URLs included in this set (applicable for HTTP traffic only)".  This could be why HTTPS traffic are not filtered.  This is so darn frustrating!  Is there a way around this?  I just don't know why Microsoft did this.

Ok, remove all the entries from your rule except:

facebook.com


Do not use any wildcards or anything else, just the static domain name.

Restart the ISA services after the change.

Let me know.

Sorry, did all that to no avail.

I've mentioned this already twice, not sure why we haven't heard anything.

FB IPs are constant across globe, so one can deny IP in this case.
Whitelisting 100 https sites for each user is worse than bad by means of time consumed.
e.g. you will not be able to block google+ this way

Agree :) which is why firewall client is preferred to "open up" SSL traffic for filter. You will not see what you dont know.

a domain name (e.g. hello.com) and all its sub-domains (e.g. *.hello.com) can be actually blocked by your internal DNS server if you point all hosts of a domain to a non-existing IP, thus when FB is to be accessed, all related traffic will be forwarded and actually blocked.

Thank you very much, Experts.  I appreciate all your time and professional advice on this.

This line of advice from giltjr could be the culprit:
>>All HTTPS traffic is encrypted and ISA canNOT read encrypted traffic.

breadtan, the Access Rule you suggested has already been tested (as was also suggested by Netman) to no avail.  That's what really frustrated me.

Here is my configuration:

  - Server: ISA 2004 on Windows Server 2003 (all SPs and latest security patches installed)
  - Server is multi-home (2 NICs)
  - Clients: all clients use the Microsoft Firewall Client to communicate with the ISA server
  - Access Rule:
       - Deny "All Outbound Traffic" (I even tried HTTPS alone with no success!!!)
       - To:  173.252.110.27, *.facebook.com, https://www.facebook.com
       - From: Internal Network
       - Users: All users
       - Schedule: "working hours" (every day from 0900 to 1700)

Scenarios:

  - at 0830 hours, user "Tom" logs in to his computer (a PC on the "Internal network")
  - He visits "http://www.facebook.com" and was granted access
  - at 0900 hours Tom is no longer able to surf Facebook anymore (an error page appears)
  - HOWEVER, Tom is is able to circumvent this rule by explicitly typing "S" at the end of HTTP (<b>HTTPS<b>://www.facebook.com) in the address bar of his browser and then press Enter and voila!  He can still enjoy Facebook!

Conclusion:

  - It seems that no matter how I set the rule, it ALWAYS gets circumvented when explicitly visiting Facebook thru its SSL address - HTTPS://www.facebook.com

  - I even re-ordered the rule to be the "first" one on the Order list of the Firewall Policy, but still the same result.

  - Facebook's IP address [173.252.110.27] has the same effect as the hostname *.facebook.com.

Have I missed anything?

Does HTTPS://www.facebook.com represent a different IP address than HTTP://www.facebook.com?

ISA cannot decode host name from SSL connection.

So, you created a NEW rule under URL for Deny https://www.facebook.com from Internal to External and moved it up to the top of your rules?

Deny rules need to be before all other rules.

I believe you are creating a Web Content  filter.  That will not work for SSL'ed traffic.

You need to create a packet filter and use the IP address of Facebook.

You cannot specify a URL set or a domain name set as an IP address.

For HTTPS traffic, URL sets are only processed if the URL does not have a path specified. For example, http://a.com or "a.com". If the URL has a path specified (even "/"), it is ignored for HTTPS traffic. E.g

For URL set entry: "a.com", HTTPS requests will be matched, because no path is specified.
For URL set entry: "b.com/", HTTPS requests will not be matched, because a path ("/") is specified.

@breadtan

We can read the help file too.  Maybe next time you can site your reference rather than making it appear as your own.

@gheist
>> ISA cannot decode host name from SSL connection.

Thank you.  I think this is it.

@Netman
>> Deny rules need to be before all other rules

Yes, I agree 100%.  But ISA still can't process the rule if traffic comes via HTTPS.

@Breadtan
>> You cannot specify a URL set or a domain name set as an IP address.

Yes, absolutely right as per article from Microsoft:
   http://technet.microsoft.com/en-gb/library/cc302531.aspx

Well, experts, after all of your tireless efforts (appreciate 'em so much) along with over 48 hours of research, I think I've come to a conclusion - HTTPS traffic simply cannot be decoded by the ISA as per gheist.

On the other hand, a third-party Firewall called DrayTek says that this can be done by both Web Content Filter, URL Content Filter, and DNS Filter (http://www.draytek.com/index.php?option=com_k2&view=item&id=1492&Itemid=293&lang=en) but then I'm not sure if I want to invest in this yet - would rather want to stay with pure Microsoft stuff.

Your reference to DrayTek doc says that using Web Content Filter and URL content Filter will FAIL when using HTTPS.  Their solution is to use DNS "filter", which what I think bbao was suggesting.
 
Setup your DNS server to respond for the zone/domain facebook.com and return a "bad" address, say like 127.0.0.1.

However ISA can do packet (that is NOT URL) filtering, which means you can filter by IP address:

http://technet.microsoft.com/en-us/library/cc723380.aspx

You just deny all traffic to particular IP address (or start with very first rule to log sunch teaffic)
And make it match any url and any hostname since ISA cannot check those even when it is willing.

Autosigning device to intercept SSL traffic  is used to spy on users, and may land you in hot water or fries oil in the end depending on local laws.

Thank you very much, Experts!  You guys are truly amazing.

@gheist, I tend to dislike the approach to filter/block by "ip address(es)" as the rule will not be scalable in the future if such website change its IP address.  Thanks.

@breadtan, I think the SSL Decoder is definitely the answer.  I'll check this out tomorrow (this is now 8:20 pm in the Marshall Islands) and let you know the result.

Again, thank you all for your generous and tireless support.  Talk to you later :-)

Mine is only that stands chance with present software, and facebook does not change IP (5 years ago they added IPv6 address)

Dear Experts,

Although I'm awarding the best possible points to only 4 experts, I would like to thank ALL of you for your professional advice and comments.  I wish there were more points available so I could share among all.  I wish you all the best.

Moderator, thank you for bringing the best in EE to help me on this.

Thank you very much.

Joe