Fortigate Application Control "Dropbox" excludes web-based access?

[AlexFeren]

Dropbox service can be accessed using a web browser or a host-based app.

Does Application Control "Dropbox" apply to traffic from web browser, host-based app or both?

[AlexFeren]

Hi HoMing, is there a way for me to determine the set of destination IP addresses that constitute traffic for FortiGuard's Dropbox application control? (This isn't to reverse engineer, but rather to compare against other UTMs we have in our network.) R's, Alex

[hmtay_FTNT]

Hello Alex,

You can do a filter on the logs by filtering the Application "Dropbox" and then extracting the "Destination Address" value to get all the IPs that we label as Dropbox. 

HoMing

[AlexFeren]

Hi HoMing,

> .. do a filter on the logs by filtering the Application "Dropbox" and then extracting the "Destination Address" value to get all the IPs that we label as Dropbox.

well, that's what I've done above. However, that's not good enough. I want to know the whole set, not just those addresses that have seen traffic. The reason is that in comparison to another UTM vendor, FortiGuard's set (for Dropbox) seems incomplete; and, as proven above, (sometimes) FortiGuard also gets it wrong.

> Dropbox does not require deep-inspection. Dropbox_Login, Dropbox_File.Upload and Dropbox_File.Download require deep-inspection.

those three, requiring Deep-inspection for more specific Dropbox traffic, would their traffic statistics be included or excluded for more general "domain=Dropbox*" and "app=Dropbox" qualifier?

R's, Alex

[hmtay_FTNT]

>>well, that's what I've done above. However, that's not good enough. I want to know the whole set, not just those addresses that have seen traffic. The reason is that in comparison to another UTM vendor, FortiGuard's set (for Dropbox) seems incomplete; and, as proven above, (sometimes) FortiGuard also gets it wrong.

We do not identify Dropbox by the IPs. They can change anytime and will cause False Positive. The reason for the missed sessions earlier was we do not have coverage for the other Dropbox domains like .dropboxstatic, etc. 

>>those three, requiring Deep-inspection for more specific Dropbox traffic, would their traffic statistics be included or excluded for more general "domain=Dropbox*" and "app=Dropbox" qualifier?

If you do a filter for "Dropbox", the Dropbox_* signatures will be included in the filtered list.

[AlexFeren]

> We do not identify Dropbox by the IPs.

This is the source of our problem - another vendor is showing Dropbox-associated traffic for address range outside of the set we see on FortiAnalyzer (and reverse-DNS query is not showing a Dropbox-related domain name). The difference in traffic statistics is so significant it cannot be ignored.

[hmtay_FTNT]

Do you have a couple of those IPs? I will reverse engineer those IPs to see what I can find and if we can do something about them. 

[AlexFeren]

> to see what I can find and if we can do something about them.

Ticket Number: 2170890. We have another issue (Ticket Number: 2159670, to do with number of reported entries versus duration), so, don't conflate.

[hmtay_FTNT]

Thanks. I looked into the ticket. I understand your question better now. Let me explain.

The difference you see in the 7 days vs 1 day Analyzer is because of the new signatures we released on the 27th. I believe the 1 day report was generated after your signature has updated to the new definitions and received the new Dropbox signatures. 

As for the IP range of 54.192.0.0/16, can you do a filter on some of the IP identified by PAN on the Fortigate and send me the Application Control logs? The Client side hostname of the IPs will be in the logs. 

Once I have the logs, I will be able to verify if PAN detected correctly or if we missed the detection. One other possibility is that the IPs have changed since the report on April 21st. With cloud servers like Cloudfront and AWS, they should not be identified by the IPs. Those servers can be used by other services. Since these are HTTPS sessions, the detections should be done by the SNI. We obtained our reference from the Dropbox's official site.

https://www.dropbox.com/help/security/official-domains

Thanks!

HoMing

[AlexFeren]

hmtay wrote:
The difference you see in the 7 days vs 1 day Analyzer is because of the new signatures we released on the 27th. I believe the 1 day report was generated after your signature has updated to the new definitions and received the new Dropbox signatures.

I've attached 3 new screenshots to Ticket #2159670 for the last 3 days - that's well after 27th April - the one for last 3 days shows less than one for last 1 day.

hmtay wrote:
As for the IP range of 54.192.0.0/16, can you do a filter on some of the IP identified by PAN on the Fortigate and send me the Application Control logs? The Client side hostname of the IPs will be in the logs.

As per attachment, I can see traffic to 54.192.118.0/24 having "hostname" set to "clientupdates.dropboxstatic.com" and application as "Dropbox". So, as you imply, since about "date=2017-04-27 time=07:06:43" Fortigate has correctly identified it as "Dropbox" instead of "SSL_TLSv1.0" and to the suspect subnet. I've attached more to Ticket #2170890.

hmtay wrote:
Since these are HTTPS sessions, the detections should be done by the SNI.

If SNI was not included would "hostname" field be equal to "destination name" (ie. DNS reverse resolve)? R's, Alex PS. our Fortigate has disk logging disabled, no I need to use FortiAnalyzer.

[hmtay_FTNT]

Hello Alex,

Thanks for the files. I looked at the spreadsheet and everything looks right to me.  >>If SNI was not included would "hostname" field be equal to "destination name" (ie. DNS reverse resolve)?

If SNI was not included in the Client Hello packet, we would log the "hostname" field as the id-at-commonName of the SSL Certificate. It would not be as granular as the SNI from the Client Hello packet, but it provides better information than the "DNS reverse resolve".

HoMing