Using a VM100 at the perimeter

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Using a VM100 at the perimeter

L1 Bithead

Hi,

We are looking at deploying a VM-100 at the perimeter of our network. We currently have a PA-500 doing that job.  It is incredibly slow on the management side of things and quite frankly, expensive when it comes to support renewals.  Hence the thought of going to a VM-100.  Our supplier has told us that Palo Alto does not recommend a Virtual Firewall (hosted on VMWARE) at the perimeter however I can't find, any documentation to support this. 

Can anyone point me at the documentation supports the statement that PA don't recommend this deployment model?  Or can someone at PA confirm this?

Thanks in advance.

16 REPLIES 16

L6 Presenter

Hi HDC...The VM-100 can be installed on several VMware products (VM workstation, VM Fusion, VM Player) and the VM platform themselves are not designed to be a firewall at the perimeter.  There is a degree of risk when exposing the VM platform to an untrusted segment (the Internet).  You should consult with VMware on how to harden the VM platform if it is even possible.

As for the slow response on the mgmt of the PA-500, may I recommend that you consider upgrading its memory:  PA-500 Management Memory Upgrade Procedure.  Thanks.

Hello i agree with rmovan in that the VM is not great to be put in a the perimeter since you now have exposed your hypervisor to the internet. I know there are VMWare hardening docs, but I think you are asking for trouble since if the hypervisor gets compromised, the firewall is useless. Stay with physical at the perimeter.

L4 Transporter

If you wouldn't trust it enough to secure traffic at the perimeter, why would you trust it enough to secure your internal traffic?

Genuine question - like many people I'm wary of putting VMware at the very edge of the network but given the "on paper" specifications of the VM100 you could buy a dedicated host if you wanted to and it would still seem to give a 2000 or entry 3000 series a run for its money.

Palo Alto SE's say it's intended for east-west inspection but nobody really ever explains why it shouldn't be suitable to use at the perimeter especially when you can do HA using VMware vs. having to buy a pair of appliances.

Not applicable

We have isolated vmware boxes in our DMZ.  They are hardened and management isn't accessible from the internet.  I can't speak to the performance, but the arguments regarding security concerns ring hollow for me.

If you end up pursuing this, please come back and share your results.

I am curious how a hypervisor can be compromised in a situation like this?  Basically your are exposing a virtual port on a virtual switch which is effectively the same as a physical switch.  The port is fully controlled by the VM itself which handles all of the traffic.  I can't fathom how this is more dangerous than a physical link to a physical Palo Alto.  Please feel free to correct me and/or explain.

I am in a similar boat, where the PA-500 may not be able to handle the expansion of our pip to 200 Mbps with all of the options enabled and I am up for renewal.    We routinely hit and exceed 100 Mbps on our PA-500.  I have a spare server with multiple NICs and dual power supplies.  Throw in a couple SSDs in a raid and I am fully redundant.

Thanks,

Bob

You can check on VMware's site for the lists of specific vulnerabilities and their hardening recommendations.  The hypervisor software is subject to the same types of exploits that can hit other linux based systems and specific ones based on the hypervisor software.  The risks are generally low in known issues but of course there is the unknown.  The code base for VMware was stolen and publicly posted back in 2012 so there have been a raft of exploits discovered since then.

The bigger risk than a switch and appliance is that IF you can compromise the hypervisor you now have access to all of the guest VMs behind the firewall on that same hypervisor.

Based on the what is currently known, I think a properly hardened VM host would be low risk for a small or branch office deploy.  But you do need to be sure it is a hardened deploy and all due caution is observed.  Others will disagree citing that the risk of giving an attack surface of the hypervisor to the public internet would be too high because the consequences of the breach are so high.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

Steven,

Thanks for replying, but I am still confused how running it on ESXi makes it less secure.  Assuming it was setup correctly (no ability to manage it from the outside), the exposed side of the firewall will appear as any other firewall to an outsider.  Any ESXi exploits are not valid as you are not exposing ESXi, only the appliance.  I just don't get it....

Publish servers through it, as far as anyone knows they just went through a physical firewall.  If you are in a position where someone gets in and can pivot around you have a lot more trouble than a virtual firewall.

Thanks for your patience,

Bob

BobW wrote:

Steven,

Thanks for replying, but I am still confused how running it on ESXi makes it less secure.  Assuming it was setup correctly (no ability to manage it from the outside), the exposed side of the firewall will appear as any other firewall to an outsider.  Any ESXi exploits are not valid as you are not exposing ESXi, only the appliance.  I just don't get it....

Publish servers through it, as far as anyone knows they just went through a physical firewall.  If you are in a position where someone gets in and can pivot around you have a lot more trouble than a virtual firewall.

Thanks for your patience,

Bob

Bob I'm 99% with you, but I must admit there's part of me that, however irrational, I'm not entirely convinced I'd be comfortable with it.

That said, we run SMTP gateways and VM's on a DMZ virtual switch so I don't really see how this is any different.

There's a heck of a lot of "what if's" needed for something bad to happen I think.

L1 Bithead

Hi folks,

I am glad this has stimulated some discussion.  I must admit that i tend towards same opinion as Bob.  I am having issue with what the real technical reason as to why I shouldn't do this.  I would appreciate someone form Palo Alto commenting, though maybe they don't read these forums.

It seems that Juniper openly support Virtual Appliances at the perimeter with there Firefly product, Firefly Perimeter – Juniper Networks

Help me out here PA, i need some concrete support for this as a solution.

Perhaps I should be posting this to VMware as well to see if they have any comments.

Thanks for commenting people.  It is much appreciated.

L7 Applicator

I think you're right-on there.  Check with VMware.  I believe most of the uncertainty surrounding the wisdom/security/safety of exposing the hypervisor to the Internet really need to be answered by VMware.  If they're cool with it and you've followed their hardening guides, then bring the discussion back here.  We'd all love to hear what you find out!  There are quite a few interesting "reads" on the internet.  Google hypervisor escape, hypervisor breakout, hypervisor security. 

One topic not brought up yet is troubleshooting.  If Palo Alto Networks sells a hardware appliance, they have the ability to really dig deep into the architecture, identify issues, fix code, etc.  When you "roll your own firewall", there are many more moving parts that aren't exposed to Palo Alto Networks' TAC (underlying hypervisor, storage, memory, networking, resource contention, etc.).  The information is there, but you'd be digging around in multiple interfaces and potentially working with multiple vendors to find the source of a particularly troublesome issue.

L1 Bithead

Hi Jared,

I will post to VMware.  I also think though that Palo Alto should be providing some clear guidance around this.  If they support this appliance as a perimeter device or not.  If they do what are other considerations etc etc.  Like mentioned earlier if I cant trust it as a perimeter device why would i trust it as a device to secure zone within my network?  If it isn't supported at the perimeter it is pretty much saying that it isn't actually a security device at all, by my logic anyway.

Having said that, this discussion would be very short if/when PA say yes or no, it is/isn't supported as a perimeter device and if it is then these are the caveats.  Then we, as customers, can present our recommendations to the decisions makers and have them decide on risk verses cost/functionality etc etc etc.

I see that in the VMWare Hardening guide there is a Risk Profiles etc perhaps PA can look at this and say fully supported as long as a Minimum of Risk Profile 2 has been implemented on the host??

HDC

It is definitely supported and secure depending on the manner you deploy it just as any hardware firewall. The one thing I would do as far as ensuring that your Untrust traffic is isolated from the rest of the traffic is to ensure that the Ingress traffic from the internet comes in through it's own Physical NIC within the ESXi infrastructure. From there the untrust traffic will be as secure as the policies you configure within your firewall just as any other hardware device. There is no issue with deploying the virtual firewall as long as you architect the deployment properly but the same applies to a hardware PA Firewall as well. Smiley Happy

L4 Transporter

I contacted a VAR we use and asked them the same.  Their response is as follows.  I am still a bit stumped as I can not fathom how the throughput would be an issue if it was put on a piece of hardware with two Intel CPUs with quad  cores (or whatever) but here's what they said:

Palo Alto states that the VM firewalls are not recommended for edge use.  Can you explain why?  If it is the only VM on an ESXi box, I can’t imagine how that would be less secure than a physical box.:

Architecturally its just not going to deliver what PAN advertises – DoS, throughput are the two largest areas of concern – because everything is just virtualized on a intel CPU – no FPGA or math processor to offload the thinking of the box. – Also security concerns but if it’s the only thing on the box as you said its less of an issue.

Complexity in the configuration is also a concern with uptimes of firewalls normally 5 9’s

Do you have any clients running a PA virtualized?  Are they happy with it?

Yes but all in test/dev environments nothing in production like suggested here


Bob

Yes, it's supported.  The AWS version of the VM-series firewall is deployed in that fashion... you can't deploy a hardware appliance in front of it.  You can't ship hardware to Amazon (at least that's how I understand it).  So from that standpoint, it's not only supported, but also highly recommended - even by Palo Alto Networks!  Smiley Happy 

Additionally, the datasheet specifies some of the use-cases that the VM series can address, and not all of them are "east-west datacenter traffic". 

     • Private or public cloud computing environments where virtualization is a dependency

     • Environments where physical space is at a premium

     • Remote locations where shipping hardware is not practical

DoS and overall performance should definitely be considered, along with all of the other points in this thread.  For example, the higher-end appliances leverage dedicated network processors to handle Zone protection functions.  And while you could easily build a server and throw enough cores at it to out-perform a PA-200 or PA-500, the performance pendulum swings to the hardware appliances when your requirements start getting into the 1Gbps+ range.  The datasheet shows the VM-series capable of about 600Mbps with 4 CPU cores:

- https://www.paloaltonetworks.com/products/platforms/virtualized-firewalls/vm-series/overview.html

It comes down to understanding the considerations involved and making an informed decision.  Yes, the management performance increase will be huge compared to a PA-200 and PA-500, and the on-going subscription costs for a VM-100 will be somewhat less expensive than a PA-500.  You would need to compare that against the cost of the server hardware and hypervisor, your ability to secure that hypervisor, the added complexity of 3rd party moving parts that Palo Alto Networks won't have control over (server/CPU/storage/memory/virtual switches/network cards/etc), your ability to prevent the "server guys" or "storage guys" from messing with the virtual infrastructure and taking the firewall/Internet down, along the # of potential vendors involved in the troubleshooting process.  

That's why you won't see a full, hearty recommendation from Palo Alto Networks to use VM-series instead of hardware appliances.  If you feel that the benefits (ongoing maintenance costs and management performance in the case of the original poster) outweigh the potential risks, I say go for it!

I have one customer who uses it in this manner.  It's not a huge environment... a PA-500 would have been appropriate for their requirements.  They weighed the pros and cons, and went with the virtual firewall.  For them it was a fairly easy choice as they had already been using virtual perimeter firewalls from another vendor and had experienced (first-hand!) the pitfalls involved.  But they're just one customer compared to many, many more who went with hardware appliances. 

-Jared (who may or may not be using a VM-series as a perimeter firewall in his "lab"). 

  • 8782 Views
  • 16 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!