WirelessPhreak.com

travel, science, technology, and all other geeky things
Follow Me
A delicious evening at Trader Sam's tasting some secret menu drinks. I will post the recipes as I find them in this post so keep checking back.

1. Krakatoa, this isn't a secret menu item but gets an honorable mention due to its excessive rum content.


(Krakatoa in a souvenir mug)

2. Old Kungaloosh, delicious drink it's vodka, coconut rum, midori and pineapple juice. I wasn't sure about the midori but it ads a subtle layer that balances the drink out perfectly. It was 9 out of 10 Recommend.


(Old Kungaloosh)
Recipe from my friend at SasakiTime.com (check out his blog it is Awesome)
Old Kungaloosh Recipe -- Circa 1997 
1 1/4 ounce vodka
1 1/4 ounce Malibu Rum
3/4 ounce Midori (melon liqueur)
2 tablespoons pineapple juice
1 splash cranberry juice 
Mix well.

3. Adult Dole Whip, holy crap this is so good. I think it taste better then the real thing. You get the familiar Dole Whip taste, but there is an undertone of vanilla that just takes it to the next level. 10 out of 10 must try!

(Adult Dole Whip)
This is the closest i could find courtesy of mirlandraskitchen.com
Adult Dole Whip
1 shot whipped vodka
4 oz pineapple juice
vanilla ice cream optional
strawberry and lemon for garnish if desired
Fill a cocktail shaker half full with ice. 
Add vodka and pineapple juice. Shake.
Pour into chilled glass and serve with ice cream or desired garnish.

4. Finally the coconut cake, again not on the menu but it is a must have at least once every Disney trip. It is the most Moist! Ya I said moist cake you'll ever have. The cake is infused with a coconut custard and the icing is a light whip cream and coconut topping. 11 out of 10 if you like coconut. 

(coconut cake)



Most of the people who have found this post on the internet are already familiar with Palo Alto Firewalls and everything they can do. One of the features I really like is the IPS functionality built into the firewall, but - and its a BIG BUT - if you're terminating SSL after the traffic ingresses your untrusted security zone you're loosing a lot of the PAN's IPS functionality because the traffic is encrypted.

Here is a reference diagram of what I am talking about:

So how do we fix it? PAN has a feature called SSL Inbound Inspection. This feature as of 7.1.x code does not terminate the SSL session or work as a proxy, but at a high-level takes a copy of the traffic and uses your imported certificate and key to inspect the traffic against the policies that have been configured. It's really easy to setup, but there are a couple caveats that I wanted to outline in this post.

SSL and Supported Ciphers: As many of you know the SSL negotiation is determined between the client and the server during the SSL handshake.  Because the firewall does not work as a SSL proxy, or "man in the middle", you have to insure that the client and server negotiate a cipher that the firewall is able to decrypt. This is where we ran into a little confusion.  Much of the documentation on the PAN site is focused around outbound SSL decryption.  This gets confusing when PAN doesn't document what feature they are discussing in an article. For example they have an article of supported decryption ciphers and they did not specify on the document if these were the ciphers used in outbound decryption or inbound inspection.  Then, when I asked for documentation of supported inbound SSL inspection ciphers, they could not point me to a document. FYI if you look at an SSL decryption profile there is a disclaimer in small print that only the listed RSA ciphers are supported for inbound inspection. I was told this was going to fixed.


So to help you out here is what is supported for inbound SSL inspection:

To ensure your firewall can decrypt all inbound SSL traffic it is important you configure your servers or load balancers to only offer ciphers supported by your firewall. If you're using an F5 to terminate SSL here is the string you can define in the cipher list within your SSL client profile.

!DES:!3DES:!SSLv3:!RC4:!EXP:RSA

APP-ID and Application Default Services: Many of you out here have enabled APP-ID on your firewalls and probably leveraged the application default service setting to let the firewall determine the port to allow traffic on.  I have been told application default setting in the services section of a security policy is best practice and, to be honest, I actually like it and use it; but it can break SSL Inbound Inspection. To understand where it breaks we first need to understand how a firewall processes a packet when you have enabled inbound SSL Inspection:

  1. The firewall looks to see if the packet is allowed by the security policy.
  2. The firewall identifies the traffic as SSL
  3. The firewall looks to see if the destination is configured with a SSL decryption policy
  4. If the destination address matches a protected IP address, it is decrypted and processed through the security policies once again as web-browsing still on port 443. 
  5. Bang! Connection is broken.

When you have application default set it is expecting specific ports based on the application that has been identified by APP-ID.  So if you have SSL and web-browsing configured in the APP-ID portion and application default configured in the services portion of your security policy...once the firewall decrypts the packets and runs it back through the security polices as web-browsing traffic on port 443 the firewall drops or resets the connection.

To resolve this issue you can still use APP-ID but you will need to explicitly list the ports the firewall will allow traffic on. This will allow any application, in this case web-browsing traffic on TCP port 443, to be allowed on any of the listed ports.

Configure SSL Inbound Inspection: You can click here to go to the Palo Alto Networks website and they will walk you though the SSL Inbound Inspection configuration.