Solved

HTTPS vs ISA Server

Posted on 2014-01-12
31
1,904 Views
Last Modified: 2014-01-22
Hello experts!

I have created a [Filewal Policy] access rule in ISA Server 2004 to deny access to Facebook during working hours (9:00-11:00 and 13:00-17:00).  The rule works, except when users specifically enter "https://www.facebook.com" in the address bar of their browser.  This address exists in the firewall access rule, but somehow the ISA is not able to detect it.  The following are the URLs that are scheduled to be blocked at certain hours:

  1) *.facebook.com
  2) facebook.com
  3) www.facebook.com
  4) http://facebook.com
  5) http://www.facebook.com
  6) https://facebook.com
  7) https://www.facebook.com  <-- users are able to circumvent the rule by this.

I know that *.facebook.com would be enough, but for some reason the ISA doesn't always work as expected, which is why I had to explicitly enter all the other variances of Facebook.com.

Any expert advice?  Thanks in advance.
0
Comment
Question by:jkaios
  • 9
  • 7
  • 5
  • +3
31 Comments
 
LVL 51

Expert Comment

by:Netman66
ID: 39775625
Block all IP addresses associated with Facebook as well.
0
 
LVL 12

Author Comment

by:jkaios
ID: 39775646
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.
0
 
LVL 12

Author Comment

by:jkaios
ID: 39780525
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?
0
 
LVL 51

Expert Comment

by:Netman66
ID: 39780589
It's possible the SSL traffic is obfuscated, but the initial site request should have failed.

Maybe a port 443 rule to that domain?
0
 
LVL 12

Author Comment

by:jkaios
ID: 39780641
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.
0
 
LVL 51

Assisted Solution

by:Netman66
Netman66 earned 100 total points
ID: 39780754
Understood.  Try either the IP address to block or do a port block of 443 to Facebook.  Or protocol (ssl) rule to facebook.
0
 
LVL 12

Author Comment

by:jkaios
ID: 39787011
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.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 39787100
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.
0
 
LVL 12

Author Comment

by:jkaios
ID: 39787700
Sorry, did all that to no avail.
0
 
LVL 61

Assisted Solution

by:gheist
gheist earned 100 total points
ID: 39793902
You need to block IP
https: is encrypted SSL connection, so ISA gets no idea anything facebook.com gets sent over that connection.
0
 
LVL 57

Assisted Solution

by:giltjr
giltjr earned 100 total points
ID: 39793977
I second gheist' post.

The way you have it setup ISA is not blocking IP addresses, it is interpreting a URL and blocking access to that URL.  

All HTTP traffic is in clear text and ISA can read it to block or allow what you want.

All HTTPS traffic is encrypted and ISA canNOT read encrypted traffic.

You have to create a rule that blocks traffic based on an IP address or addresses.  Not sure if FB has a single IP address or multiple addresses.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 39794006
I've mentioned this already twice, not sure why we haven't heard anything.
0
 
LVL 61

Assisted Solution

by:btan
btan earned 200 total points
ID: 39794070
The experts has shared. The HTTPS protocols ISA Server only knows the IP address of the destination which can be confirmed by creating another Rule:

From: Internal Network
To: IP (for example IP of facebook.com)
Action: Deny
Protocol: All Outbound Traffic

This above rule should works just fine, wonder if you tried. You may want to check the SecureNAT clients (firewall client)  which rely on name resolution from your internal DNS infrastructure. http://technet.microsoft.com/en-us/library/cc302531.aspx

But in summary, if you are not using the firewall client then the user establishes a session with the WebSite independent of the ISA (not really independent, but ISA cannot filter the traffic). If it is on port 80 the traffic can be read by ISA and the firewall rules apply. If they connect on 443 the traffic is encrypted for server to client and the ISA only sees the IP address of the server, not the hostname. In this scenario you will have to block the IP addresses of those sites (which will also probably break many other sites as well).

If you use the firewall client on the user computers then the encrypted session is between the ISA server and the Web server. ISA then passes the traffic to the client. Since ISA initiates the session it will decrypt the traffic read the host header and deny access by your rule.

Also note http tunneling from MS website that can bypass. Whitelisting is recommended instead of purely blacklisting (denying websites)

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

HTTP Policy and SSL Connections

If you allow HTTPS traffic to any destination, HTTP policy can be bypassed. Some applications establish a Secure Sockets Layer (SSL) tunnel between an internal client and an Internet server, and then allow the client application to communicate with the server over that tunnel, thus overriding your HTTP policy. To prevent this, either create an access rule allowing HTTPS access only to specific, trusted sites, or a deny access rule, denying access to sites which are known to provide a tunneling service. These access rules will be from the client network, typically the Internal network, to a specific URL set (the set of URLs that are allowed or denied, depending on the approach you take). For more information about access rules and URL sets, see the ISA Server product documentation.

You could try to block access to the HTTP tunneling site using the signature for the site. However, these signatures may be frequently changed by the tunneling sites to defeat HTTP filtering. For this reason, limiting HTTPS access using access rules is a more reliable approach to blocking HTTPS tunneling, and will require less maintenance.
0
 
LVL 61

Expert Comment

by:gheist
ID: 39794198
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
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 
LVL 61

Expert Comment

by:btan
ID: 39794332
Agree :) which is why firewall client is preferred to "open up" SSL traffic for filter. You will not see what you dont know.
0
 
LVL 37

Expert Comment

by:Bing CISM / CISSP
ID: 39794345
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.
0
 
LVL 12

Author Comment

by:jkaios
ID: 39795439
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?
0
 
LVL 61

Expert Comment

by:gheist
ID: 39795444
ISA cannot decode host name from SSL connection.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 39795673
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.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 39795730
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.
0
 
LVL 61

Expert Comment

by:btan
ID: 39795775
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.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 39795816
@breadtan

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

Author Comment

by:jkaios
ID: 39795921
@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.
0
 
LVL 57

Expert Comment

by:giltjr
ID: 39795937
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
0
 
LVL 61

Accepted Solution

by:
btan earned 200 total points
ID: 39795982
@Netman, thanks for the note.

@jkaios, There is mention of "SSL Decoder" to act as an SSL Proxy. You can catch the section on "Configuring Microsoft ISA Server (Forefront TMG) to work with SSL Decoder together" and the "compatibility of SSL Decoder ..."
@ http://www.redline-software.com/eng/products/tk/components/ssl_decoder.php

Another is Cleartunnel @ http://www.collectivesoftware.com/solutions/cleartunnel
0
 
LVL 61

Expert Comment

by:gheist
ID: 39796198
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.
0
 
LVL 12

Author Comment

by:jkaios
ID: 39796262
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 :-)
0
 
LVL 61

Expert Comment

by:gheist
ID: 39796309
Mine is only that stands chance with present software, and facebook does not change IP (5 years ago they added IPv6 address)
0
 
LVL 12

Author Closing Comment

by:jkaios
ID: 39801905
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
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

The use of stolen credentials is a hot commodity this year allowing threat actors to move laterally within the network in order to avoid breach detection.
Cybersecurity has become the buzzword of recent years and years to come. The inventions of cloud infrastructure and the Internet of Things has made us question our online safety. Let us explore how cloud- enabled cybersecurity can help us with our b…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now