Identifying and Blocking Google Drive when Using Chrome-cached Session

Printer Friendly Page

Symptoms

Google Drive access works using Google Chrome browser based on the cached session.

 

Scenario

 

End host has accessed Google Drive or is logged in to the account from home, but when the laptop is enrolled on the office network, the firewall is not able to identify and block the cached session.

 

Diagnosis

When someone is accessing Google Drive via Chrome, we see at least 3 sessions:

 

  • google-base (google.com, client.google.com, gstatic.com, etc) (appid 2075)
    • covers others (main page, navigating, listing, etc).
  • google-drive-web (drive.google.com) (appid 1596)
    • this covers login
  • google-docs-base (docs.google.com) (appid 635)
    • covers downloading and editing functionality

Solution

Even blocking Google Drive based on the URL category will not help, blocking online-personal-storage (drive.google.com, docs.google.com) will not block listing and navigating.

 

For blocking to work successfully, blocking google-drive is not enough.  We also need to block google-docs.

 

We can further customize the requirements of the customer to allow users to access google-drive but block uploads and downloads.

 

The google-docs application is made of other sub-applications listed below. The app names explain their functions:

  • google-docs-base
  • google-docs-editing
  • google-docs-enterprise
  • google-docs-uploading

 

Note: We will need to have decryption in place for the above functions to work. We should especially decrypt the 'search-engine' category along with the following url's drive.google.com, *.google.com, *.googleusercontent.com, and *.gstatic.com

 

 

A screenshot of adding a security policy to allow access to google-drive but deny downloads or editing, and just allow uploading files.

 

uplaod.png

 

 

Dependent Issue

 

Enabling decryption for search-engine might trigger a safe search enforcement from the the url category, which will break the ability to search from the address bar of the Chrome browser.

 

The search made from the address bar does not include the string " safe=active" when searching, this is seen only when using Google as a default search engine.

 

As a workaround, we can use the following custom search engine (make it default ) in the Chrome settings:

 

{google:baseURL}search?q=%s&safe=active

 

The screen shot is attached for reference.

 

 

Google safe search.jpg

 

 

 

 

Comments

We want to blocked google drive when using browser cachce. Tried blocking using the apps and urls posted above. But Still can access download and download on google drive.

I spent an incredible amount of time working to allow download from drive.google.com, but block upload to drive.google.com.  File blocking profiles do not work with drive.google.com, and I hope that Palo Alto might be able to resolve this issue in the near future.

 

Here's what I used to get it working (allow download, block upload)...

 

Src Zone - Trust

Src IP - any

Src User  - any

Dst Zone - Untrust

Dst IP - any

AppID - google-base, google-docs-base, google-docs-downloading, google-drive-web, google-play, ssl, web-browsing

Service - TCP-443, TCP-80

URL Cat - google-drive (www.google.com/intl/en/drive, drive.google.com, *.googleusercontent.com, docs.google.com)

URL Cat - google-drive-blk (play.google.com, clients6.google.com)

URL Filter (cloned Default) - google-drive-filter (selected "block" for URL category "google-drive-blk")

 

****all traffic is decrypted****

 

So the reason I settled on this setting...using Chrome, it called out to play.google.com (app: google-play) to upload.  Using IE, it called out to clients6.google.com (app: google-base) to upload.  By classifying traffic based on the apps, and using URL categories/filters to allow/block, I was able to catch the traffic and enforce allow/block with this single rule without it reclassifying and hitting another rule to allow.

 

****also note, this will block access to play.google.com, so there is a decision to make as to whether or not you'd want to implement this****