Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
It appears that Dropbox uses Amazon AWS for it's storage, so I am not able to just block or trottle traffic to dropbox.com
Since there are a lot of web services that rely on AmazonAWS, I cannot just block that domain.
Do you have any suggestions on how to handle dropbox traffic?
I am working from a cisco ASA, but I suspect this applies to all firewall managers
Update your firewall to one that knows applications (commonly called "Next Generation Firewalls" these days). Palo Alto Networks is a good example. Instead of opening your firewall to IP-based destinations, you allow the application "Dropbox" and don't care about the destination. You are also able to put some QoS on top of Dropbox. For example, you could create a QoS policy that gives Dropbox a maximum of 5 mbps bandwidth.
A lot of other Firewall vendors have come up with similar solutions to the one of Palo Alto Networks. I know that Juniper SRX and Checkpoint do it now, not sure about Cisco though. The important thing is that your firewall understands applications (on layer 7) versus just layer3/4.
Even though dropbox uses AWS, they can be blocked...
I use an address-based approach for stuff like this, just lookup the address blocks that said company owns and filter it...
Using Robtex information for AS19679 (Dropbox) to block dropbox...
object-group network DROPBOX_AS19679
network-object 108.160.160.0 255.255.240.0
network-object 199.47.216.0 255.255.252.0
!
! I assume you don't care whether you also block web / email traffic to dropbox.com...
! The following ACL should be applied inbound on your Inside interface
access-list <your-acl-name> extended deny ip any object-group DROPBOX_AS19679 log
FYI, Dropbox supports connecting via http proxy so if your proxy is not in the path of the ACL above, be sure you block dropbox on your proxy too.
I did some research after I got home from work... when I tested, Dropbox uses a combination of their own native address space and AWS address space for connections.
Dropbox used SSL so it was hard to tell exactly what they were doing, but if I look at sequencing it looks like when you move a file in or out of your local Dropbox/ folder, first they talk to their own address blocks, then they use AWS for a bulk transfer as-required.
Since they used AWS for most of the bytes I saw, I'm not confident you can easily throttle them using address blocks alone; however, at least today they can be blocked with ACLs.
The following is a summary, see below for all Supporting Syslog Information...
Time Action Connection No. Destination ASA Bytes
-------- ------------------- -------------- ------------ ---------
22:26:51 Delete-dropbox-file 591637 Dropbox 6965
22:26:51 " 591638 Dropbox 11590
22:28:46 Paste-into-dropbox 591738 Dropbox 7317
22:28:46 " 591741 AWS 2422218
22:28:46 " 591788 Dropbox 7674
Since Dropbox dynamically uses AWS address space, they can't be effectively throttled, but I will give an example of what you would do for other non-AWS sites / applications, using Dropbox's address space as an example... you would also need to define an object-group for your "Inside" address blocks (FYI, I'm using ASA 8.2)...
access-list ACL_Dropbox extended permit ip object-group Inside object-group DROPBOX_AS19679
access-list ACL_Dropbox extended permit ip object-group DROPBOX_AS19679 object-group Inside
!
class-map Class_Dropbox
match access-list ACL_Dropbox
!
policy-map Policy_Police
class Class_Dropbox
police input 384000
police output 384000
class class-default
!
service-policy Policy_Police interface INSIDE
I use this technique to throttle bandwidth to a number of social networking sites (such as Facebook), and it's quite effective. I automated periodic checks for address block changes and add anything else the targets start announcing... automation, of course, is not required.
Supporting Syslog Information
Jun 27 22:26:51 10.100.1.1 %ASA-6-302013: Built outbound TCP connection 591637 for OUTSIDE:108.160.160.177/443 (108.160.160.177/443) to INSIDE:mpenning_Vista/56957 (11.40.219.148/28663)
Jun 27 22:26:51 10.100.1.1 %ASA-6-302013: Built outbound TCP connection 591638 for OUTSIDE:108.160.160.177/443 (108.160.160.177/443) to INSIDE:mpenning_Vista/56958 (11.40.219.148/54828)
Jun 27 22:28:12 10.100.1.1 %ASA-6-302014: Teardown TCP connection 591637 for OUTSIDE:108.160.160.177/443 to INSIDE:mpenning_Vista/56957 duration 0:01:21 bytes 6965 TCP FINs
Jun 27 22:28:12 10.100.1.1 %ASA-6-302014: Teardown TCP connection 591638 for OUTSIDE:108.160.160.177/443 to INSIDE:mpenning_Vista/56958 duration 0:01:20 bytes 11590 TCP FINs
Jun 27 22:28:46 10.100.1.1 %ASA-6-302013: Built outbound TCP connection 591738 for OUTSIDE:108.160.160.177/443 (108.160.160.177/443) to INSIDE:mpenning_Vista/56959 (11.40.219.148/17163)
Jun 27 22:28:46 10.100.1.1 %ASA-6-302013: Built outbound TCP connection 591741 for OUTSIDE:174.129.221.92/443 (174.129.221.92/443) to INSIDE:mpenning_Vista/56960 (11.40.219.148/15739)
Jun 27 22:29:05 10.100.1.1 %ASA-6-302013: Built outbound TCP connection 591788 for OUTSIDE:108.160.160.177/443 (108.160.160.177/443) to INSIDE:mpenning_Vista/56961 (11.40.219.148/36777)
Jun 27 22:29:05 10.100.1.1 %ASA-6-302014: Teardown TCP connection 591738 for OUTSIDE:108.160.160.177/443 to INSIDE:mpenning_Vista/56959 duration 0:00:19 bytes 7317 TCP FINs
Jun 27 22:30:12 10.100.1.1 %ASA-6-302014: Teardown TCP connection 591741 for OUTSIDE:174.129.221.92/443 to INSIDE:mpenning_Vista/56960 duration 0:01:25 bytes 2422218 TCP FINs
Jun 27 22:30:12 10.100.1.1 %ASA-6-302014: Teardown TCP connection 591788 for OUTSIDE:108.160.160.177/443 to INSIDE:mpenning_Vista/56961 duration 0:01:07 bytes 7674 TCP FINs
