I picked up some cheap P400 controllers for some experimenting in the Home Lab. They had really old firmware ~v4.x. I was having difficulty entering the ROM-based ACU, so I figured they needed a firmware update.
Long story short... you can upgrade the firmware on these things even in non-HP hardware. Download the HP Smart Update Manager from HP's website here. Burn the DVD (trust me, I spent 30 minutes trying to get it USB bootable), use the auto-update option, and off you go! Controller updated.
Blocking a specific app in Apple's App Store
Thursday, October 24, 2013
at
9:55 AM
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
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
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:
- Map traffic flows into classes using a "QoS Policy"
- Define how classes are serviced in a "QoS Profile"
- 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:
- VoIP Traffic (defined by the applications sip/sccp/h.323/skype) is mapped to class 2
- Apple Applications are mapped to class 8 (only between the hours of 6am-11pm)
- 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.
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
Application,
Firewall,
network,
Palo Alto Networks,
policy,
QoS,
rate-limiting,
security
|
4
comments
|
Installing VMware ESXi 5.5 from USB
Wednesday, September 25, 2013
at
2:42 PM
Quick note to say that unetbootin can take the "VMware-VMvisor-Installer-5.5.0-1331820.x86_64.iso" image file and write directly to a USB key/memory stick. That memory stick, in turn, is bootable and can be used to install the ESXi hypervisor on a compatible system.
I used it to install from a USB memory stick to a different USB memory stick, which frees up the local SSD and HDD for use with the VSAN beta.
This wasn't always the case with previous versions of ESXi. Glad to see it's straight-forward now. Time to go play!
I used it to install from a USB memory stick to a different USB memory stick, which frees up the local SSD and HDD for use with the VSAN beta.
This wasn't always the case with previous versions of ESXi. Glad to see it's straight-forward now. Time to go play!
Posted In
usb,
vmware
|
0
comments
|
Installing VMware vSphere Client in Windows 8.1 Preview / Windows Blue
Friday, July 5, 2013
at
4:22 PM
I've been playing with the Microsoft Windows 8.1 Preview (aka Windows Blue) and had problems installing VMware's vSphere Client. After clicking "I agree", the install window disappeared, providing no helpful information as to why it failed. I hate the vSphere web client, and would much rather use the thick client to manage my home lab ESXi 5.1 environment.
The cause of issue is that the .NET framework v3.5 is not installed in Windows 8 by default, and is a required component for the vSphere client. I assume that the redistributable is packaged with the vSphere client installer, but it doesn't work in Windows 8.1.
The .NET Framework v3.5 is easy to install, just issue the following command from an elevated/administrator command prompt:
Dism /online /enable-feature /featurename:NetFx3 /All /Source:F:\sources\sxs /LimitAccess
(replace F:\ with the DVD drive where your Windows 8.1 is located. If your DVD drive is as slow as mine, just copy the ISO to your hard drive, mount it with daemon-tools, and use that location instead.)
After that, the vSphere client happily installed and I'm off to play with Windows 8.1 now.
The cause of issue is that the .NET framework v3.5 is not installed in Windows 8 by default, and is a required component for the vSphere client. I assume that the redistributable is packaged with the vSphere client installer, but it doesn't work in Windows 8.1.
The .NET Framework v3.5 is easy to install, just issue the following command from an elevated/administrator command prompt:
Dism /online /enable-feature /featurename:NetFx3 /All /Source:F:\sources\sxs /LimitAccess
(replace F:\ with the DVD drive where your Windows 8.1 is located. If your DVD drive is as slow as mine, just copy the ISO to your hard drive, mount it with daemon-tools, and use that location instead.)
After that, the vSphere client happily installed and I'm off to play with Windows 8.1 now.
Posted In
vmware,
Windows 8.1
|
1 comments
|
Configure vCenter to use Wake-On-LAN for DPM
Tuesday, June 4, 2013
at
5:31 PM
I'm labbing-up VMware's DPM (Dynamic Power Management) technology this week. This is a self-funded home lab, and I'm too cheap to use enterprise-grade hardware. That means technologies like IPMI/iLO are out of the question. The good news is that both of my lab hosts support Wake-on-LAN (WOL).
I went into the BIOS of each of the ESXi hosts and enabled Wake-On-LAN. I placed both of them into a cluster and enabled DPM. I then attempted to place one of the hosts into standby mode. The vCenter client complained with the following message:
That last line really bugs me because there is no WOL-specific configuration options in vCenter. After a little digging around (RTFM) I read that vCenter must be able to send the WOL "magic packet" to a physical NIC where vMotion is enabled. I had not yet enabled vMotion on these two lab hosts!
After enabling vMotion on my hosts, I was able to successfully place them into standby mode. Even more importantly was the fact that vCenter could wake them back up again.
I observed one other quirky behavior with DPM. When attempting to manually power-on the sleeping host, vCenter's "please wait" message reads:
This comes AFTER I get confirmation that the "Host is in Standby Mode". It could be that vCenter still isn't sure if the machine is fully powered-off just yet, so it's waiting an arbitrary amount of time before sending the WOL packets to my host. I'll have to play with it a little more and see if vCenter gives the same misleading "please wait" message when powering-on a host that has been sleeping for a while.
I went into the BIOS of each of the ESXi hosts and enabled Wake-On-LAN. I placed both of them into a cluster and enabled DPM. I then attempted to place one of the hosts into standby mode. The vCenter client complained with the following message:
vCenter has determined that it cannot resume host lab1.example.com from standby; therefore, the enter standby task was stopped. Confirm that IPMI/iLO is correctly configured for host lab1.example.com. Or, configure vCenter to use Wake-On-LAN, ensuring there are at least two or more hosts in the cluster, and try the task again.
That last line really bugs me because there is no WOL-specific configuration options in vCenter. After a little digging around (RTFM) I read that vCenter must be able to send the WOL "magic packet" to a physical NIC where vMotion is enabled. I had not yet enabled vMotion on these two lab hosts!
After enabling vMotion on my hosts, I was able to successfully place them into standby mode. Even more importantly was the fact that vCenter could wake them back up again.
I observed one other quirky behavior with DPM. When attempting to manually power-on the sleeping host, vCenter's "please wait" message reads:
Waiting for host to power off before trying to power it on
This comes AFTER I get confirmation that the "Host is in Standby Mode". It could be that vCenter still isn't sure if the machine is fully powered-off just yet, so it's waiting an arbitrary amount of time before sending the WOL packets to my host. I'll have to play with it a little more and see if vCenter gives the same misleading "please wait" message when powering-on a host that has been sleeping for a while.
Posted In
vmware
|
0
comments
|
Subscribe to:
Posts (Atom)