Blocking a specific app in Apple's App Store

Thursday, October 24, 2013 at 9:55 AM | Posted by Jared Valentine
I received a question in reference to yesterday's blog about rate-limiting Apple's App Store.  This individual was interested in blocking a specific application within the App Store, specifically OS X Mavericks.  (They hadn't finished testing their enterprise applications with Mavericks).

Yes, it is possible to block a specific application within the Apple App Store.  Based on what I found, there are a few considerations & multiple ways to do this:

The Apple App Store application itself is a mix of unencrypted traffic running over TCP/80, along with SSL over TCP/443.  Luckily for us, the App Store transports the actual file over tcp/80, which makes it easy to detect and block!

The Apple App Store application calls the following URL when you click on the Download link for OS X Mavericks:

a545.phobos.apple.com/us/r1000/049/Purple4/v4/83/ab/68/83ab6813-eddc-e4c5-70a5-bc1ef921030b/mzps3704126155036248224.pkg

From here, it's a simple matter of disrupting traffic that matches that URL.

I found the URL by doing a quick search in my URL Filtering logs:



Now that we know the specific package name of this download, we can create a custom vulnerability (IPS) signature that matches this string.  I'm sure that apple has hundreds or thousands of servers/IP addresses out there - so matching on the hostname and/or URI path isn't recommended.  The best way to control this will be to focus on the package filename itself.   

My vulnerability signature is very simplistic.  It performs a pattern match for "mzps3704126155036248224\.pkg" in the http-req-uri-path context.  (We have to escape the period "." in the filename as it can also be used as a regex function)

You can download the custom signature in Palo Alto Networks IPS format here: vulnerability_41022-osx-mavericks-dl-2.xml

Import that signature under Objects / Custom Objects / Vulnerability (assuming you don't have a signature # 41022...  if you do, change the entry name in the XML file before importing).  This signature is configured with Severity=Informational and Default Action=Alert.

Import this into your firewall and test.  It should fire off an alert each time you download OS X Mavericks.  Once you've had a chance to test it, you can change the action of that signature to Reset-Both and re-test.


And here's the user experience when a user clicks "Download" in the App Store:


This seems pretty straight-forward and I'm guessing you can do this in a URL filter, secure web gateway, IPS system, etc.

3/9/2014 - added a 2nd pattern to the XML for the 10.9.2 package filename:  mzps4135638417199433253.pkg

| 0 comments |

Rate-Limiting Apple AppStore with Palo Alto Networks

Tuesday, October 22, 2013 at 1:51 PM | Posted by Jared Valentine
Guess what I'm doing in the home lab!  Yes, I'm upgrading an Apple MacBook Pro to OS X Mavericks using the App Store application.

I was going to to guess that the download took 30 minutes, but then I remembered I don't have to guess.  Those details are logged in the firewall's traffic log.  1859 seconds comes in just shy of 31 minutes.  For those 31 minutes, while my Internet was pegged (in a good way), I went and ate some lunch.  

That got me thinking.  What about all of those environments where there are hundreds, or thousands of Macs? Their Internet connections must be getting crushed!  What is the user experience for everyone else on that network while their WAN links are getting pegged (in a bad way)?

Palo Alto Networks is known for their application-level visibility and control.  The terminal action for identifying an application is not limited to "permit" or "deny".  You can also use that intelligence to rate-limit an application.

The process of rate-limiting an application can be a little daunting - thus the purpose of today's blog posting.  Application-based rate limiting is a 3-step process:
  1. Map traffic flows into classes using a "QoS Policy"
  2. Define how classes are serviced in a "QoS Profile"
  3. Attach a QoS Profile to a firewall interface

So let's dig into each step in a little more detail:


STEP 1:  QoS Policy

Navigate to Policies / QoS.  This is where you map traffic into classes.  


This particular firewall has 3 simple QoS Policies:
  1. VoIP Traffic (defined by the applications sip/sccp/h.323/skype) is mapped to class 2
  2. Apple Applications are mapped to class 8 (only between the hours of 6am-11pm)
  3. All other traffic is mapped to class 4
(Note: rule #3 is technically redundant, as traffic not explicitly defined in this policy will be placed into class 4).

You can get more granular with your mapping of traffic into classes.  You can use src/dst zones, src/dst IP addresses, specific users (as pulled from Active Directory / Exchange / API), and service/destination port.  This specific policy is very simple, relying mainly on the application.  


STEP 2:  QoS Profiles

Navigate to Network / Network Profiles / QoS Profile.  This is where you define how to service each of the classes.  


In order to keep things simple, call your new QoS Profile "Inbound Traffic QoS Profile".  Trust me, proper naming here will help you later in the process.  Next, add each of the classes and select a priority for each class.  Finally, add your rate-limit value to the Egress Max for class 8.  (My example here shows 22.5Mbps).  There's quite a bit more you can do with QoS, but that will have to wait for another blog post.  


STEP 3: Attach the QoS Profile to a Firewall Interface

Navigate to Network / QoS.  This is where you will "Add" a mapping between the previously-created QoS Profile and one of the firewall's physical interfaces.  

The QoS engine in PAN-OS acts on traffic as it egresses the firewall.  This means that your "Inbound Traffic QoS Profile" must be attached to the inside interface of the firewall.  In this example, I am attaching our QoS profile to ethernet1/2.


Be sure to select the newly-created QoS profile for both Clear Text & Tunnel Interface.  

As always, you'll need to "Commit" your changes.  Finally, in order to validate that the application in question is being rate-limited, navigate to Network / QoS and click on "statistics" to see pretty graphs and charts relating to your QoS policy.

What if you want to rate-limit outbound/upload traffic too?  If your goal is symmetric rate-limiting, then just repeat step #3 and attach the same QoS profile to your outside/wan/untrust interface.  If you want different limits for upload vs. download, then repeat step #2 and create an "Outbound Traffic QoS Profile", populated with different rate limits, and then repeat step #3 by attaching this profile to your outside interface.  

The next time your wan pipe gets pegged by an OS X or iOS update, or when March Madness rolls around again next year, or when your employees/students/users discover bittorrent/netflix/youtube/$excitingnewapp, you'll be prepared to handle it.  

Posted In , , , , , , , | 4 comments |

Subscribe to: Posts (Atom)

Line Rate | Powered by Blogger | Entries (RSS) | Comments (RSS) | Designed by MB Web Design | XML Coded By Cahayabiru.com