C o m m u n i t y E x p e r i e n c e D i s t i l l e d

Unleash the power of Proxmox VE by setting up a dedicated virtual environment to serve both containers and virtual machines

Learning Proxmox VE

Rik G

oldman

Learning Proxmox VE

Proxmox VE 4.1 provides an open source, enterprise virtualization platform on which to host virtual servers as either virtual machines or containers.

This book will support your practice of the requisite skills to successfully create, tailor, and deploy virtual machines and containers with Proxmox VE 4.1.

Following a survey of PVE's features and characteristics, this book will contrast containers with virtual machines and establish cases for both. It walks through the installation of Proxmox VE, explores the creation of containers and virtual machines, and suggests best practices for virtual disk creation, network confi guration, and Proxmox VE host and guest security.

Throughout the book, you will navigate the Proxmox VE 4.1 web interface and explore options for command-line management.

Who this book is written forThis book is intended for server and system administrators and engineers who are eager to take advantage of the potential of virtual machines and containers to manage servers more effi ciently and make the best use of resources, from energy consumption to hardware utilization and physical real estate.

$ 44.99 US£ 28.99 UK

Prices do not include local sales tax or VAT where applicable

Rik Goldman

What you will learn from this book

Install and confi gure Proxmox VE 4.1

Download container templates and virtual appliances

Create and host containers based on templates

Create and host virtual machines

Optimize virtual machine performance for common use cases

Apply the latest security patches to a Proxmox VE host

Contrast PVE virtual machines and containers in order to recognize their respective use cases

Secure Proxmox VE hosts as well as virtual machines and containers

Assess the benefi ts of virtualization with regard to budgets, server real estate, maintenance, and management time

Learning Proxmox VE

P U B L I S H I N GP U B L I S H I N G

community experience dist i l led

Visit www.PacktPub.com for books, eBooks, code, downloads, and PacktLib.

Free Sample

In this package, you will find: The author biography

A preview chapter from the book, Chapter 7 'Securing Proxmox VE'

A synopsis of the book’s content

More information on Learning Proxmox VE

About the AuthorRik Goldman had 18 years of professional IT experience and 17 years of teachingexperience when he became the director of technology and a teacher of advancedcomputing at Chelsea School in 2012.

Throughout his 10 years at the university, he concentrated on literary computing, newmedia, humanities computing, and virtuality. At first, Rik supported his studies bydeveloping institutional websites and database applications; eventually, however, hebecame the administrator of Solaris and Irix servers for West Virginia University's Centerfor Literary Computing, a lab committed to the study of electronic texts, virtuality, anddigital composition and rhetoric.

In the classroom, Rik's commitment to authentic teaching and learning as well as hisadvocacy of social justice and equity have placed him at the vanguard of technologyeducation. Working with and learning from his students, he has overseen projects that haveprovided real solutions for school infrastructure, data management, and programming. Hismany accomplishments reveal an educator who strives to provide authentic opportunitiesfor learning and engagement, but his true legacy lies in what he has engendered in hisstudents: a desire for knowledge, a critical urge, and an analyst's zeal for complexabstractions. Through this work with students and his responsibilities as a systemsadministrator, Rik has enjoyed a productive preoccupation with virtualization technologiesand their impact on popular culture.

Since his full-time adoption of Red Hat 5 at home, he has been committed to GNU/Linuxand the underlying philosophies that have made it so successful. Consequently, he is apassionate advocate of open source and free software. Together with his students, he hascontributed to the success of a myriad open source endeavors by developingdocumentation, writing code, and mentoring communities of young developers fromaround the world.

In his free time, Rik enjoys reading literature, exploring critical theory, listening to records,and traveling to concerts with his family.

Preface"There is a double spooking the world, the double of abstraction. The fortunes of states andarmies, companies and communities depend on it. All contending classes - the landlordsand farmers, the workers and capitalists - revere yet fear the relentless abstraction of theworld on which their fortunes yet depend. All the classes but one. The hacker class."

"The virtual is the true domain of the hacker. It is from the virtual that the hacker producesever-new expressions of the actual. To the hacker, what is represented as being real isalways partial, limited, perhaps even false. To the hacker there is always a surplus ofpossibility expressed in what is actual, the surplus of the virtual. This is the inexhaustibledomain of what is real without being actual, what is not but which may be. To hack is torelease the virtual into the actual, to express the difference of the real."

– McKenzie Wark, A Hacker ManifestoNot so many years ago, it would've taken three computers to author this book efficiently onthe go. Virtualization, however, has made it possible to write without the obscene hassle ofdragging about so much baggage. Virtualization has reduced labor and energy expenditureand maximized productivity and discretionary time during the writing and production ofthis book.

Abstraction liberates us from material constraints, leaving in their place the privilege ofnostalgia—tractor-fed edge strips, darkroom chemicals, printing presses and type-set trays,overflowing money bags with dollar signs, and of course, cramped server rooms.

Through server virtualization, the abstraction of computing resources from physicalsystems has overturned data centers and radically upset the traditional and repetitiveroutines of system engineers and administrators in favor of efficiency, conservation,lowered expenditure, secure systems, and the simple deployment of automation tocomplete repetitive tasks.

Proxmox VE has been a pioneering agent in this rapid revolution since the 2008 release ofversion 1.0—the first hypervisor to support both virtual machines and containers.

Preface

With version 4.2 in the works, and the industry's fascination finally fixed on the realizationof a container revolution, Proxmox VE still provides an open source, enterprisevirtualization solution with premium support that enjoys tremendous internationalpopularity—even as competing brands have scrambled to roll out container solutions just intime.

This book is packed with introductory concepts and best practice techniques forexperienced Linux users eager to take advantage of bleeding edge virtualization strategiesand practices with Proxmox VE.

This book explores the benefits of two of these complementary virtualization technologies,containers and virtual machines, so you'll be forearmed to make informed and deliberatedchoices regarding the best paths for virtualizing your data center.

What this book coversChapter 1, Proxmox VE Fundamentals, outlines Proxmox VE's features and distinguishingcharacteristics and briefly compares and contrasts virtual machines and containers.

Chapter 2, Installing Proxmox VE, goes through the Proxmox VE installation process aftercovering Proxmox VE's hardware requirements and discussing minimal and optimalhardware specifications.

Chapter 3, Creating Containers, starts with a primer on containers and their uses beforeproviding a walkthrough of the container creation processes, including choosing anddownloading an OS or virtual appliance template.

Chapter 4, Creating Virtual Machines, first elaborates on the functional differences betweenvirtual machines and suggests prospective use cases and the inherent benefits anddrawbacks of full virtualization. It then walks through the process of creating andconfiguring virtual machines intended for Microsoft Windows Server and Fedora Server.

Chapter 5, Working with Virtual Disks, compares and contrasts virtual hard disk options,including disk image types, virtual bus/interfaces, and cache types.

Chapter 6, Networking with Proxmox VE, contrasts common virtual Ethernet adaptoroptions provided by Proxmox VE and works to articulate use cases for each.

Chapter 7, Securing Proxmox VE, enumerates strategies for mitigating security threats tovirtualized datacenters in general, and Proxmox VE hosts and guests in particular.

7Securing Proxmox VE

“Abstraction may be discovered or produced, may be material or immaterial, butabstraction is what every hack produces and affirms….To hack is to produce or apply theabstract to information and the possibility of new worlds”

– A Hacker Manifesto, McKenzie Wark

“Putting it bluntly, virtualization is deception.”

– Data Center Virtualization Essentials, Gustavo Alessandro Andrade Santana

“The enemy knows the system being used…”

– Shannon's Maxim

“Security through obscurity is not an answer.”

– Information Security: Principles and Practices, Merkow and Breithaupt

“Containers have quickly become a popular cloud-optimization strategy for enterprises,however, what do we really know about the security implications?”

– Kowsik Guruswamy

The end goal of this chapter is to support you in mitigating threats to the security of your Proxmox VE infrastructure.

We start by enumerating and articulating the potential benefits of virtualization oninfrastructure security.

However, these benefits must not be relied on unconditionally or discussed uncritically; wemust qualify them here.

Securing Proxmox VE

[ 164 ]

Moreover, we must expose the potential security risks virtualization can inject into theinfrastructure.

Ultimately, this chapter commits to providing strategies for mitigating security threats toour Proxmox VE hosts and guests.

Security assurance is, of course, a sprawling field, and often includes not only threatmitigation, but also policy making, monitoring, incident response, and forensics. Our focushere is exclusively on mitigating vulnerabilities specific to Proxmox VE hosts.

Towards that end, then, the goals of security are defined here in accordance with tradition:

Maintaining the confidentiality of a systemAssuring its integrityProviding consistent availability of services

Security triad

Chapter 7

[ 165 ]

The preceding illustration suggests that these three points are not isolated: the wholepicture consists of three mutual relationships: one between confidentiality and integrity;one between confidentiality and availability; and, finally, one between integrity andavailability. Too much or too little emphasis on one point distorts our Platonic triangle, asymbolic representation of our impossible ideal.

Given our end goal—mitigating threats—this chapter proceeds along the following vector:

Examining the potential security rewards of virtualizationInterrogating those rewards and exploring the potential vulnerabilitiesvirtualization introducesActing directly to mitigate threats

Security benefits of virtualizationIntroducing well-planned, deliberate, and well-executed virtualization into aninfrastructure delivers some very compelling security benefits.

“The abstraction of IT resources that masks the physical nature and boundaries ofthose resources…”– Virtualization as defined by Gartner's IT Glossary (h t t p : / / w w w . g a r t n er . c o m / i t - g l o s s a r y / v i r t u a l i z a t i o n).Let's be clear about one thing with regard to this common troperepresenting virtualization as a deceptive masquerade: security throughobscurity does not work. The use of secrecy for the design orimplementation of a system to provide security is a failing proposition.In enumerating the security benefits of virtualization, this sectionpurposefully avoids suggesting that abstraction and the obfuscation itpermits are an effective security strategy.

We'll see as the chapter develops that none of the security rewards promised byvirtualization advocates can be realized without a good understanding of networking,systems administration, type 2 hypervisors, VMs, and containers. The following is alsorequired:

Rigorous planning based in part on defense in depthFlawless realization of those plansExcellent management throughout the lifecycle of all guests.

Securing Proxmox VE

[ 166 ]

Given all of the preceding, there are very clear security benefits to virtualization withProxmox VE:

Reduction of the physical attack surfaceVM isolationAbility to restore to prior statesHardware abstractionNetwork segmentation supportEncapsulation and portabilityPhysical securityFine privilege controlIntegrated firewalls

Attack surface reductionMoving to a virtual infrastructure reduces your physical attack surface in accordance withyour virtual machine density. The more physical servers we convert to Proxmox VE guests,in conjunction with how densely we pack guests onto our Proxmox VE hosts, the fewerservers there are to ensure protection from potentially devastating physical attacks, forexample.

Virtualization has an inherent potential to reduce the attack surface of an infrastructure inseveral ways; we'll focus here on how it reduces the number of physical hosts providingservices.

Chapter 7

[ 167 ]

Visualizing attack vectors and the attack surface

Where we were once protecting, say, 15 machines from physical attack, there might be oneor two physical Proxmox VE hosts to protect, for example.

We have to be critical here and realize this can open up new vulnerabilities and frustratingproblems to resolve.

Securing Proxmox VE

[ 168 ]

The Proxmox VE host becomes monolithic, so:

If there's an unpatched vulnerability in Debian 8, PVE, or KVM and QEMU, theconfidentiality, integrity, and availability of all the virtual machines hosted bythat instance are also threatened.If an attacker gains physical access to the PVE host or hosts, the security andsanctity of all guests, both containers and virtual machines, are most certainly indoubt. If that's troubling, consider too that your snapshots and backups may havedisappeared.

There's no doubt virtualization reduces the overall attack surface of your infrastructure, andin several ways; however, as articulated previously, this does not relieve us of any burdens,it just gives those burdens higher stakes while making them less complex to address.

IsolationVirtualization encourages isolation. One VM doesn't naturally affect another VM, even if itis on the same host.

This tendency toward isolation suggests that destructive malware infecting a virtual serverwon't necessarily escape and spread to other virtual servers, even when they share a host.

If there's an oversight however, such as naively sharing data between two guests, or (worse)sharing data between a guest and the host, attacks can be devastating. Therefore, resist thetemptation to create file shares among VMs on PVE; for the sake of security, do not sharefiles between a Proxmox VE host and any of its guests.

Here the importance of documenting your infrastructure and writing a well-deliberated andwell-enforced security policy is clear.

Availability of prior statesIn the event an attack against a Proxmox VE guest succeeds, the guest can be rolled back toa prior state via backups or snapshots, effectively minimizing the time it takes to recoverfrom an attack. (Note, however, that any data or information that changed between the timeof the selected backup and the moment it is restored will be lost during a rollback.)

Chapter 7

[ 169 ]

Rolling back involves applying a former version of a guest's storage file to the virtual machine or container

So, it's logical that the ability to restore to a prior state isn't an unconditional advantage ofvirtualization, even if it's an integrated feature of Proxmox VE; snapshots and backups mustbe integral to the well-thought out and executed lifecycle of the PVE guests and part of awell-defined and enforced policy.

Hardware abstractionA fundamentally compelling characteristic of full virtualization is the abstraction of acomputer from the physical hardware.

Imagine that a Proxmox VE guest with a well-organized trove of information collected overmonths is compromised and its hard drive destroyed in an attack that would have renderedphysical storage unsalvageable—destruction of storage on a virtual disk does no damage tothe physical storage that hosted it. When prior states are available to restore from, asnapshot or a backup can be restored onto the same hardware.

Without condition, damage dealt to virtual components has no effect on the physical host.This is an inherent reward for abstraction.

Securing Proxmox VE

[ 170 ]

SegmentationIf an infrastructure is to be virtualized with Proxmox VE, take advantage of the networksegmentation technologies it supports, such as VLAN tags, bridges, IPs masquerading withNAT, and per-guest firewalls. Use these technologies to make VMs or containers availableto a limited population of users with legitimate business needs that call for a limited level ofaccess.

Visualizing segmentation and trust zones with Proxmox VE

Chapter 7

[ 171 ]

To make the most of this valuable potential, think rigorously about sufficient trust zones asyou plan your infrastructure.

A trust zone is a network segment within which data flows relativelyunrestricted, while data flowing in and out of the trust zone is subject tostronger restrictions.

Open vSwitchAs an alternative to the bridges, bonds, and VLAN interfaces native toLinux, Proxmox VE supports Open vSwitch.Open vSwitch is an open source, software implementation of a distributed,multilayer switch. It's production-ready and designed with virtualizationspecifically in mind.To learn more about Open vSwitch, including features and potentialdrawbacks, visit its website at h t t p : / / o p e n v s w i t c h . o r g. To learn moreabout Proxmox VE's support of Open vSwitch, visit the Proxmox wiki at ht t p s : / / p v e . p r o x m o x . c o m / w i k i / O p e n _ v S w i t c h.

Encapsulation and portabilityAs described in Chapter 5, Working with Virtual Disks, with full virtualization allinformation on virtual servers, including boot disks, is saved as a file; this is an example ofencapsulation.

Invaluably, encapsulation serves the portability of the VM; even as an attacker works tocompromise a PVE host, its guests can be moved, without halting, to another host in acluster. Live migration—migrating an active guest from one PVE host to another in thesame cluster—helps assure availability even in the case of an ongoing attack against a host.

On Clustering and High AvailabilityFor more on these topics, see Mastering Proxmox, Proxmox High Availability,and Proxmox Cookbook from Packt Publishing.

Securing Proxmox VE

[ 172 ]

Physical securityWhen an attacker gains access to a physical server, the availability, confidentiality, andintegrity it should demonstrate are absolutely in doubt.

To put it bluntly (and to appropriate a phrase from Scott Culp), if an attacker has physicalaccess to your Proxmox VE host, it's not your host anymore.

As described previously, a very powerful benefit of virtualization is that the number ofphysical hosts decreases as the services they provided move to VMs or containers,effectively reducing the attack vectors, since the fewer machines there are to find physicalspace for, the fewer there are to gain illegitimate access to.

Nevertheless, include in your policy the procedures by which the PVE hosts, the storage,and the intermediate distribution frame (that is, the wiring closet) are to be physicallysecured against illegitimate access, and enforce the policy consistently and withoutexception; this means you've mitigated a potentially devastating threat.

Fine privilege controlWith defense in depth and the principle of least-privilege in mind, consider the fine controlof user access and restrictions that's realized when each service is moved to a discrete VMor container—in contrast to keeping multiple services running on a single physical server.

Chapter 7

[ 173 ]

In a virtual infrastructure, a user privileged to access one service is not explicitly privilegedto another as we can imagine they would be if the services were shared on a singlehardware server. We can restrict access to Debian, finely define a user's role in relation toeach VM and container via the PVE web interface, and further refine privileges on the guestOS level and the application level.

Some layers to consider in the practice of “defense in depth”

By default, the Proxmox VE management interface is authorized through GNU/Linux'sdefault authentication system (PAM), and root is the only user. However, theauthentication system for the web interface can be changed from PAM to PVE's system, toActive Directory, or to LDAP.

Whatever the authentication mechanism, specific users can be assigned different roles, orprivileges, for each individual VM or container.

Securing Proxmox VE

[ 174 ]

PVE User ManagementTo learn more about PVE's user management features, see the usermanagement page of the Proxmox wiki: h t t p s : / / p v e . p r o x m o x . c o m / w ik i / U s e r _ M a n a g e m e n t.

There are a host of predefined roles for users or groups that ship with PVE; and we cancreate new roles with different privileges and restrictions as necessary.

PVE firewall featuresProxmox VE provides flexible firewall features based on iptables.

These features can be configured via the administration interface or the command line toprovide several layers of protection, as this allows rulesets to accept and reject traffic perguest server, per PVE host, and for an entire cluster.

To learn more about the Proxmox VE firewall, visit the officialdocumentation at h t t p s : / / p v e . p r o x m o x . c o m / w i k i / P r o x m o x _ V E _ F i re w a l l, where detailed configuration examples are available.

It's rather critical that PVE be protected by a firewall.

Proxmox VE 3.4 relies on the following ports:

8006 (web interface)85 (pvedaemon—configured to listen only on 127.0.0.1)5900-5999 (VNC web console)22 (sshd; used for cluster actions as well as a means to access a remote shell)5404, 5405 UDP (CMAN multicast—if you run a cluster)

Proxmox VE 4.0 saw some changes to Proxmox VE's port usage:

8006 (web interface)85 (pvedaemon-configured to listen only on 127.0.0.1)5900-5999 (VNC web console)3128 (SPICE console)22 (SSH access-now optional)111 (rpcbind)5404, 5405 UDP (corosync multicast if you run a cluster)

Chapter 7

[ 175 ]

Use your firewall experience to restrict access to these ports from subnets and IP ranges thatdon't have a legitimate need to access them.

Aggravated vulnerabilitiesVirtualization's potential security benefits are certainly compelling, but many are quiteconditional and altogether they are certainly no panacea.

Moreover, virtualization introduces new threats to an infrastructure—threats that otherwiseeither wouldn't be a concern at all or are exacerbated by virtualization.

This section calls attention to vulnerabilities that are historically problematic for virtualinfrastructures:

Denial of service attacksVM escape and hyper jumpingServer sprawlGrowing complexity

Denial of service attacksDenial of service (DoS) attacks come in a wide variety of flavors. However, the immediateintent is the same: overwhelming a network, and its administrators, by generating largeamounts of illegitimate traffic.

Distributed denial of service (DDoS) and DoS attacks are cheap, effective, and increasinglycommon. On the surface, they seem to be most effective at rendering services unavailable orunusable. More insidious, perhaps, is that, by keeping administrators' hands full as theycope with illegitimate traffic, other attacks can be launched without attracting theirimmediate attention.

Securing Proxmox VE

[ 176 ]

Unfortunately, DoS attacks are particularly powerful against virtual infrastructures,wherein overwhelmed virtual hosts will certainly threaten the availability of virtual guestsand the services they provide.

Visualizing a DDoS attack

In addition, research published in 2013 found that DoS attacks are significantly more potentwhere virtual machines are involved:

“[Under] DoS attack, the performance of a web server hosted in a VM can degrade by up to23%, while that of a nonvirtualized server hosted on the same hardware degrades by only8%. Even with relatively light attacks, the file system and memory access performance ofhypervisor-based virtualization degrades at a much higher rate than their nonvirtualizedcounterparts.”

– Performance of Virtual Machines Under Networked Denial of Service Attacks: Experimentsand Analysis, Shea and Liu, h t t p : / / w w w . c s . s f u . c a / ~ j c l i u / P a p e r s / P e r f o r m a n c eo f V i r t u a l M a c h i n e s . p d f

Clearly, in some areas, we may take solace in some security benefits of virtualization;however, DoS and DDoS attacks are one threat we cannot turn away from.

When migrating services from physical machines to Proxmox VE guests, work to define anddeploy not only preventative measures, but also rapid response protocols. This calls for theimplementation of monitoring and alert systems, as well as a firewall configuration thatdeliberately takes such attacks into consideration.

Chapter 7

[ 177 ]

Each type of DoS attack has its own array of detection and mitigation strategies. To mitigateagainst SYN flooding attacks, for example, see section three of h t t p : / / t o o l s . i e t f . o r g /h t m l / r f c 4 9 8 7.

VM escape and hyper jumpingVirtual machine escape occurs when an attacker successfully “breaks out” of a virtualmachine and interacts with the host operating system.

In a similar vein, VM jumping, or hyper jumping as it is sometimes referred to, is theprocess of gaining illegitimate access to a virtual machine via another virtual machine.

Presumably encapsulated and isolated environments, virtual machines run operatingsystems that shouldn't know that they are virtualized; there should be no way to break outof the virtual machine to interact directly with the parent hypervisor. For the same reasons,it should be impossible to illegitimately access a virtual machine through another virtualmachine.

VM escape exploits are particularly devastating since the hypervisor controls the executionof all of the virtual machines and containers on the host. Consequently, an attacker that cangain access to the hypervisor can then win control over every guest running on the PVEhost; since the hypervisor is between the physical hardware and the guest operating system,a successful VM escape will enable attackers to simply circumvent security controlsimplemented on the virtual machine.

VM escapes and hyper jumping should be an intellectual exercise, a fascinating theoreticalproblem. Unfortunately, that's simply not the case.

During the production of this book, for example, several VM escape vulnerabilities haveemerged. Perhaps the vulnerability that captured the most attention was the one dubbed VENOM by researchers (h t t p : / / v e n o m . c r o w d s t r i k e . c o m /):

“VENOM, CVE-2015-3456, is a security vulnerability in the virtual floppy drive codeused by many computer virtualization platforms. This vulnerability may allow an attackerto escape from the confines of an affected virtual machine (VM) guest and potentiallyobtain code-execution access to the host. Absent mitigation, this VM escape could openaccess to the host system and all other VMs running on that host, potentially givingadversaries significant elevated access to the host's local network and adjacent systems.

Securing Proxmox VE

[ 178 ]

“Exploitation of the VENOM vulnerability can expose access to corporate intellectualproperty (IP), in addition to sensitive and personally identifiable information (PII),potentially impacting the thousands of organizations and millions of end users that rely onaffected VMs for the allocation of shared computing resources, as well as connectivity,storage, security, and privacy.”

Venom attack scenario

Unfortunately, the many “computer virtualization platforms” invoked by the disclosureincluded all QEMU-based platforms; this includes Proxmox VE.

Chapter 7

[ 179 ]

In the case of VENOM, a patch was available from Debian the same day the vulnerabilitywas disclosed. A PVE administrator simply had to upgrade, in Debian fashion, and thenrestart guest virtual machines:

apt-get clean apt-get update

After a shutdown and restart of all VMs on the Proxmox VE host, the vulnerability wasgone. There was no need to even reboot the PVE host.

The bug was introduced unknowingly in the QEMU source when theQEMU Floppy Drive Controller was introduced in 2004.

So it seems virtualization's celebrated isolation is not absolute.

From VENOM, we can learn some direct preventative actions that can be taken to mitigateemerging VM escape vulnerabilities:

Keep Proxmox VE and Debian routinely patched. There are a variety of ways toautomate the patching process; we'll walk through one method in the nextsection. Since Proxmox VE is patched through the same mechanism as Debian,patches to both are applied simultaneously.Patch operating systems and applications running on virtual machines andcontainers. On Debian and Ubuntu guests, use the apt tool; on MicrosoftWindows and Server guests, set a reasonable Windows Update policy to ensureurgent updates are applied.Don't install virtual machine features you do not need. Doing so increases yourattack surface unnecessarily. Be particularly attentive to what virtual devices areattached to your VM; if you don't need a virtual optical drive or floppy disk driveon the VM, either deliberately avoid installing them or remove them from the VMwhen you no longer need them.Avoid running software and services that are not essential to your guests'primary roles.However, weigh the benefits of running endpoint security software on a virtualmachine; in his September 2015 article, “The Curious Case of the Escaping VirtualMachine,” Bunmi Sowandi suggests that such software will detect malicious codetrying to run in a VM before it has a chance to “escape“. (h t t p : / / v m t u r b o . c o m /a b o u t - v i r t u a l i z a t i o n / t h e - c u r i o u s - c a s e - o f - t h e - e s c a p i n g - v i r t u a l - m

a c h i n e /)

Securing Proxmox VE

[ 180 ]

As we learned from VENOM, the best protection against VM escape and hyper jumpingexploits is routine and well-thought out patch management.

Virtualization sprawlIn the context of virtual infrastructure, sprawl refers to the tendency of virtual servers toproliferate faster than administrators can properly manage. Sprawl encourages poormanagement decisions, hasty undeliberated action, sloppy configuration mistakes, andmissed opportunities to mitigate threats.

From a security perspective, therefore, virtualization sprawl presents dire problems asadministrators miss security patches, fail to harden services, and perhaps expose thenetwork, the hypervisors, and storage nodes unnecessarily.

A helpful article on the Hewlett Packard site suggests some best practices to reduce theimpact of sprawl effectively. Like many security issues explored in this chapter, thesuggested solution is excellent planning, deliberated deployment, and writing andenforcing a security policy that includes VM lifecycle management. The article (h t t p : / / h 30 4 9 9 . w w w 3 . h p . c o m / t 5 / G r o u n d e d - i n - t h e - C l o u d / 5 - w a y s - t o - g e t - c o n t r o l - o f - v i r t

u a l i z a t i o n - s p r a w l / b a - p / 6 1 7 0 9 5 9) puts particular emphasis on the following:

Whenever possible, create VMs and containers from “golden images” thatinclude patches, patch policy, audit policies, software, and software policies

End-to-end lifecycle and policy management for VMs and VM template

Chapter 7

[ 181 ]

Proactively update policy-based enforcement on VMs as well as VM templates(and containers and container templates)

Systematically manage the lifecycle and compliance of virtual servers from end toend (including, for example, routine snapshots or backups, and applying patchesand upgrades)

The article is insistent on conveying two messages successfully:

A well-thought-out security policy, which administrators can realistically complywith, is absolutely essential for keeping sprawl in checkTasks that can be automated must be automated

Virtualization sprawl encourages disorder; tame it with automation driven by a well-thought-out policy that's followed in the practice of daily administration.

Securing Proxmox VE

[ 182 ]

At war with complexity“A network architecture should be as clean and simple to understand as it can be. It shouldbe possible to briefly…draw a few simple pictures to illustrate that design….”

“Having a clear understanding of the traffic flow on your network puts you in control of it.Not understanding the network puts you at the mercy of its vagaries.”

– The Practice of System and Network Administration, 2E 2007

Given that virtualization encourages sprawl and given that secure virtual infrastructuresdemand segmentation, it's not entirely surprising that virtualization encouragesproblematic network complexity.

As network complexity goes up, so too does the pain that administrators suffer, since theymust keep accurate documentation, troubleshoot connectivity problems on the fly, andsometimes provide actionable information for third-party support providers.

The “chaos approach” encouraged by infrastructure virtualization is not a reliable model touse in a network where the availability of every component matters (The Practice of Systemand Network Administration).

To limit network complexity, consider that the campus' network architects, engineers, andadministrators should all be able to sketch, without aids, the key features and basicstructure of the network topology.

According to Limoncelli, Hogan, and Chalup, the network architecture is neither cleanenough, comprehensible enough, nor simple enough if this network map can't be relativelyeasily rendered. Maps of the physical and logical networks should absolutely be part of thesystem documentation and revised to reflect any modifications from the previous topology.

Taking the risk of sounding redundant squarely in the face, the best way to tame networkcomplexity is to ensure the network can be explained and diagrammed, logically andphysically, without the support of additional resources. If that's not the case, re-evaluate thearchitecture and see where it can be simplified without sacrificing security.

Chapter 7

[ 183 ]

Taking actionIf you're not yet virtualizing infrastructure, or you're not otherwise in a position to developa strategic security policy, there're tactics you can take in the meantime to mitigate somethreats to your Proxmox virtual environment:

Secure the bootloaderIf possible, lock down the BIOS/UEFIAbsolutely prohibit remote access to Proxmox VE's user interfacesDisable root access via SSH; consider prohibiting sudo access as wellUse Fail2ban to prevent brute-force attacksRely on key-based SSH authenticationMaintain security patches for Proxmox VE and its guestsConsider an enterprise support subscription

The practical procedures that follow are a strong (and immediate) complement to the lessconcrete strategies articulated previously.

This concluding section thus walks through these immediate tactical mitigation objectivesto provide immediate support as you come to terms with Proxmox VE.

Protecting the boot processIn this section, we work to assure that OS and application-level authentication isn'trendered useless by an attacker with physical access who can thoroughly bypass thesemechanisms.

Securing Proxmox VE

[ 184 ]

We can think of booting as a four-stage process:

A generic boot process

During this process, the system can be vulnerable:

An unsecured BIOS can be directed to boot from an attacker's storage device,allowing them to compromise the confidentiality and integrity of data stored onthe Proxmox VE host and interfere with the availability of the services and virtualservers the host has intended to provide.By manipulating an unsecured bootloader, attackers can gain root access to amachine and compromise its confidentiality, integrity, and availability.

Using either method, the attacker effectively owns the machine. Let's do our best to lockdown the BIOS/UEFI on our hosts and GRUB 2.0, the bootloader for Proxmox VE 3.4 and4.1.

To learn more about the Debian bootstrap process, visit h t t p s : / / w w w . d eb i a n . o r g / d o c / m a n u a l s / d e b i a n - r e f e r e n c e / c h 0 3 . e n . h t m l # _ a n _ o v

e r v i e w _ o f _ t h e _ b o o t _ s t r a p _ p r o c e s s.

Chapter 7

[ 185 ]

Locking down the bootloaderOS-level authentication restrictions can be very simply defeated on an otherwise secureProxmox VE machine by manipulating GRUB 2, Proxmox VE's bootloader. See, forexample, h t t p : / / l i n u x c o n f i g . o r g / u b u n t u - 1 4 - 0 4 - l o s t - p a s s w o r d - r e c o v e r y,wherein the process is fully articulated. The gist of an attack looks like this:

Reboot and enter the GRUB 2 menu immediately after startup.1.Modify the boot options.2.Boot the system based on your modifications.3.Change the root password of the system.4.Shutdown and restart.5.Login with the new password.6.

For an experienced GNU/Linux administrator, it's likely a familiar process; it's identical tohow we reset a lost root password.

GRUB 2 offers extensive customization, and with it, the power to disable access to GRUB 2options generally, as well as to specific menu options.

We will walk through the universal protection of GRUB 2 menu entries to enable access bya single superuser with an unencrypted password. This will prohibit attackers as well assloppy or disgruntled colleagues from editing a GRUB entry or accessing a GRUBcommand line.

To follow this procedure, you must:

Have root privilegesDetermine a superuser name and password to be used (we will use thename admin and the password pve)Edit GRUB configuration files from the command lineUpdate the GRUB 2 configuration with the update-grub command

Let's get started:

Log into a shell on your Proxmox VE host; if PVE is configured with an IP1.address of 192.168.1.200, access a shell via SSH from a workstation on the samenetwork:

ssh root@192.168.1.200

Securing Proxmox VE

[ 186 ]

Open /etc/grub.d/00_header using a plaintext editor; this example uses nano2.as the editor:

nano /etc/grub.d/00_header

Append the following lines to the bottom of the text:3.

cat << EOF set superusers="admin" password admin pve EOF

Save the document and exit the editor; in nano, use Ctrl +X, then Y, and4.then Enter to return to a shell prompt.Open /etc/grub.d/10_linux in nano:5.

nano /etc/grub.d/10_linux

Seek the following group of lines in /etc/grub.d/10_linux:6.

echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS}\$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' {" | sed"s/^/$submenu_indentation/"

else echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS}\$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed"s/^/$submenu_indentation/"

In the last line, insert --unrestricted between ${CLASS} and \$menuentry;7.the resultant line appears as follows:

echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} --unrestricted\$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed"s/^/$submenu_indentation/"

Save the revised document and exit the editor; in nano, use Ctrl + X to exit,8.press Y to confirm, and then press Enter to return to a shell prompt.Finally, prompt GRUB 2 to reconfigure itself based on the changes:9.

update-grub

When you reboot, you should find that PVE will start normally if left uninterrupted.However, if you try to edit a menu entry, boot from a submenu, or access a GRUBcommand line, you should find that you're required to authenticate.

Chapter 7

[ 187 ]

For more on GRUB security, visit the following links:h t t p s : / / h e l p . u b u n t u . c o m / c o m m u n i t y / G r u b 2 / P a s s w o r d sh t t p : / / w w w . g n u . o r g / s o f t w a r e / g r u b / m a n u a l / g r u b . h t m l # S e c u r i ty

As the article at h t t p : / / o p e n s o u r c e f o r u . e f y t i m e s . c o m / 2 0 1 3 / 0 3 / p l a y i n g - h i d e - a nd - s e e k - w i t h - p a s s w o r d s / points out, this password can still be bypassed by configuringBIOS/UEFI to boot from the attacker's boot device. If your hardware allows, you probablywant to secure this first stage of the boot process so would-be malefactors won't be able tofinagle the Proxmox VE host to boot from their own devices.

Locking down BIOS/UEFIBy securing the bootloader, GRUB 2, we can prevent a user from bypassing OS security andgaining root privileges on the Proxmox VE host.

However, attackers can still simply bypass even the bootloader's security by booting insteadfrom their own media. From there, they can mount the machine's secondary storage andmake immediate decisions for you about its confidentiality and integrity. If an attacker isparticularly deliberate, he/she can install a cunning means to access the machine remotelyat a later date.

To mitigate this threat, we can, depending on our firmware, password protect the bootdevice settings in either the BIOS or UEFI.

Since there's an unwieldy array of BIOS and UEFI firmware vendors, we'll articulate avision for what we'd like to do, and then hope our systems will cooperate.

The objective is to manipulate the BIOS/UEFI so it operates as follows:

Allows the system to cold-boot without any interruptionRequires authentication to change the boot deviceProhibits entering the setup manager without authentication

This configuration can be tricky and is largely contingent on the BIOS/UEFI vendor.

Securing Proxmox VE

[ 188 ]

Ideally, a machine with BIOS will allow you to do the following:

Enter the BIOS configuration when starting your PC. After power on, press the1.prompted key to enter BIOS Setup Utility; sometimes, it's the F key, Delete,or ESC. On some Lenovo machines, it's Enter. In the case of VMWare'sPhoenixBIOS, F2 is used to access the setup utility (access to this interface is whatwe want to make impossible or frustrating for an attacker):

PhoenixBIOS, included with VMware Workstation, uses F2 to enter setup, F12 for network boot, and ESC for the boot menu.

Once you enter SETUP, navigate to a security tab. On the machines I've accessed,2.setting the administrator password will require the same credentials of anyonetrying to enter the setup utility. On the PhoenixBios for VMware Workstationvirtual machines, I can still boot without authenticating. So far so good.

Chapter 7

[ 189 ]

However, when the preceding screenshot invites users to press F12 for network3.boot or Esc for the boot menu, they'll find these are unrestricted. In this case, anyattempt to lock down BIOS for security is really quite devastated.If available, navigate to the boot settings in the SETUP utility. If the option is4.available in the Boot menu, disable devices that aren't used and that you don'twant to use, such as network boot and boot from optical drives or USB devices.Again, depending on availability, navigate to boot priority and set the boot5.priority of the remaining devices. Some systems allow you to use the D key todisable devices.

Ideally, your BIOS setup tool allows you to disable boot devices or password protect theboot device menu as well as the SETUP tool itself. Furthermore, it'll hopefully let you set asupervisor password without prompting you to authenticate to boot. If the boot process isinterrupted to ask for authentication, there's the potential for a lot of unnecessary, andperhaps unplanned, down-time for the services users are relying on.

The settings recommended previously were possible in about half of the physical machinesI surveyed for the chapter.

If your machine does provide for this ideal scenario, realize that, at best, losing the BIOSpasswords means you've lost your license to reconfigure or troubleshoot the physicalmachine. In case of a lost password, you'll need to research how to bypass the security thatyou once felt was keeping bad guys out. The reset process is awkward, inconsistent, a timesink, and may not work.

It's essential, therefore, to keep a safe copy of any credentials you use to restrict access toBIOS or UEFI.

To learn more about securing the specific BIOS/UEFI system for your Proxmox VE host,look for the documentation from the computer or BIOS manufacturers or from communityusers on the Web.

If protecting the boot process to your satisfaction is not possible with the BIOS or UEFIyou're stuck with, compensate by making sure access to the physical host is absolutelysecure with alarmed door locks, key passes that log ingress and egress, and so on.

Secure Boot and Proxmox

Proxmox VE does not support the Secure Boot feature of UEFI.

Securing Proxmox VE

[ 190 ]

Hardening the OS and hypervisorThe objective here is to ensure the security of both Proxmox VE (3.4 and 4.0) and Debian, itsunderlying operating system. Because Proxmox VE and Debian are inextricably bound, it'sappropriate to address them together.

Prohibit remote access to the hypervisorPundits specifically committed to secure virtual infrastructures are insistent on this point:remote access to the hypervisor must be forbidden.

This directive must be qualified: it's absolutely appropriate it's absolutely appropriate torun a Proxmox VE host heedlessly (sans display) and to access it from another workstationon the same LAN via both SSH and the web-based administration interface.

What you want to avoid at all costs is making PVE ports, particularly 22 and 8006, public-facing and accessible to the Internet. Unless VPN is configured, Proxmox VE absolutelyshould not be available from outside the LAN.

OpenVPN is an open-source package for providing VPN services; if you'reconsidering a VPN solution, read more about OpenVPN at h t t p s : / / / w i ki . d e b i a n . o r g / O p e n V P N.

Harden SSHProxmox VE is designed to have two access alternatives:

Access to a command line interface via SSHAccess via the Web-based administrative interface

SSH must be an available option so administrators can make configuration changes to theunderlying operating system. Moreover, as we saw in Chapter 3, Creating Containersand Chapter 4, Creating Virtual Machines, we may choose to take care of a significantamount of Proxmox VE administrative tasks via the command line.

So SSH can't be disabled outright in the name of security. However, in the name of securityassurance, we must fine-tune the configuration of SSH to mitigate threats, whether fromdisgruntled or sloppy colleagues or outside attacks.

Chapter 7

[ 191 ]

Our objectives here are as follows:

Disabling direct root account access via SSHMitigating brute-force password attacks against SSHLimiting access by IPUsing encrypted keys rather than passwords to authenticate over SSH

Disabling root account access via SSHThis procedure is critical and absolutely necessary. First, let's create our own accounts withwhich to log in. We'll then use the new account to log in, escalate privileges using the su -command, and then follow a simple procedure to disable the root from logging in throughSSH.

Once this procedure is complete, we'll log in using the new account for the foreseeablefuture; to perform a procedure that requires root's privileges, we'll simply use the su -command to temporarily escalate the privileges of this user account, by following thesesteps:

Choose a username and password you intend to use to administer Proxmox VE1.via SSH.Via SSH, log in as the root using the credentials you created during the2.installation of Proxmox VE.Use the adduser command, followed by the username you've chosen, to create a3.new account:

adduser rgoldman

Follow the prompts to create and confirm the new account's password.4.Enter the full name you'd like associated with the new account.5.You may choose to ignore the remaining prompts for additional information,6.such as office number, address, and telephone number.

Securing Proxmox VE

[ 192 ]

Press Y and Enter to confirm the creation of the new user.7.

Creating a new user within a command line prompt

Use the exit command to close the SSH session.8.Reconnect to Proxmox VE using the new account name:9.

ssh rgoldman@192.168.1.200

Use the su - command to escalate privileges and enter the root's password to10.continue.Edit /etc/ssh/sshd_config using nano:11.

nano /etc/ssh/sshd_config

Seek the following section using the arrow keys or the PageDown key:12.

#LoginGraceTime 2m #PermitRootLogin no #StrictModes yes #MaxAuthTries 6

Chapter 7

[ 193 ]

In this file, the # symbol signifies that the line is a comment and is not to be13.considered as part of the SSH daemon's configuration. Let's remove the # symbolfrom the second line to enable the directive:

PermitRootLogin no

Save and exit the revised configuration file: Ctrl + X, Y, Enter.14.We can restart the SSH daemon without it affecting our session:15.

/etc/init.d/ssh restart

Now, let's test to ensure root can no longer log in. Start by entering exit to leave15.the su mode, and exit again to close SSH.Start a new SSH session as the root:16.

ssh root@192.168.1.200

Access should be denied, without the opportunity to enter a password.

Preventing brute-force attacks against SSHAs long as SSH daemon is configured to use password authentication, it's vulnerable tobrute-force password attacks. One mitigation strategy is to install and configure Fail2ban, apowerful tool designed to detect attacks on a service and ban the offending IP address fromwhich the attacks originate for a predefined period. Fail2ban effectively increases the cost inresources and the time attackers have to invest to continue a brute force password attack.

To make use of Fail2ban, follow this procedure:

Login via SSH and your new user account.1.Escalate privileges:2.

su -

Install Fail2ban:3.

apt-get update && apt-get install -y fail2ban

Copy the default configuration called jail.conf to a new file4.called jail.local:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jain.local

Securing Proxmox VE

[ 194 ]

Open the new file in an editor such as nano:5.

nano /etc/fail2ban/jail.local

Cofirm Fail2ban's configuration for SSH in the following stanza:6.

[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6

Save the file and exit nano with Ctrl + X, Y, Enter.7.If any changes were necessary, restart Fail2ban:8.

/etc/init.d/fail2ban restart

Fail2ban can also be configured to protect PVE's web-based administrationinterface from brute-force attacks.First, add the following to /etc/fail2ban/jail.local:

[proxmox] enabled = true port = 8006, https filter = proxmox logpath = /var/log/daemon.log maxretry = 3 bantime = 3600 # 1 hour

Then, create the filter by entering nano/etc/fail2ban/filter.d/proxmox.conf at the command line.Enter the following lines:

[Definition] failregex = pvedaemon\[.*authentication failure; rhost= <host> user=.* msg=.* ignoreregex =

Save the file and exit nano with Ctrl +X, Y, Enter.Restart Fail2ban to activate the new configuration:

/etc/init.d/fail2ban restart

Chapter 7

[ 195 ]

With Fail2ban configured as described previously, failure to authenticatesuccessfully three times in a row in the web interface will prohibit the clientfrom connecting again for a full hour:

After three unsuccessful attempts to log in to the PVE web interface

Securing Proxmox VE

[ 196 ]

More on Fail2banTo learn more about Fail2ban and how it works, visit h t t p : / / w w w . f a i l 2b a n . o r g / w i k i / i n d e x . p h p / M a i n _ P a g e.To learn more about Fail2ban and Proxmox VE, visit the Proxmox Wiki ath t t p s : / / p v e . p r o x m o x . c o m / w i k i / F a i l 2 b a n.

Relying on key-based authenticationAnother way to secure SSH access to a Proxmox VE server is to rely on key-basedauthentication instead of password authentication. The advantage to this authenticationmethod is that you can disable password authentication altogether and not have to worryabout the strength of legitimate users' passwords. Another benefit is that you can use thesame key to authenticate to any number of SSH servers.

To make use of this feature, we'll start by generating an SSH key pair. Once you have apublic and private key that can be used to authenticate, we'll place the public key on thePVE host so that we can use SSH key authentication to log in. Once these two proceduresare complete, you'll check to see whether you can log in to your PVE host.

In the examples that follow, rgoldman is used as a placeholder for theusername, while 192.168.1.200 is used as a placeholder for PVE's IPaddress. Please replace each as appropriate.

On a workstation on the same LAN as the PVE host, generate an SSH key pair:1.

ssh-keygen

Confirm the key location at the first prompt by pressing Enter:2.

Generating public/private rsa key pair. Enter file in which to save the key (/home/rgoldman/.ssh/id_rsa):

At the next prompts, you may choose to create and confirm an optional3.passphrase; using a passphrase will prevent an attacker from accessing the PVEhost from your workstation. On the other hand, you'll have to enter thepassphrase every time you wish to authenticate with the key:

Created directory '/home/rgoldman/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again:

Chapter 7

[ 197 ]

Look for confirmation that the key has been created—you should see an output to4.the terminal similar to the following:

Your identification has been saved in /home/rgoldman/.ssh/id_rsa. Your public key has been saved in /home/rgoldman/.ssh/id_rsa.pub. The key fingerprint is: a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host The key's randomart image is: +--[ RSA 2048]----+ | ..o | | E o= . | | o. o | | .. | | ..S | | o o. | | =o.+. | |. =++.. | |o=++. | +-----------------+

An output similar to the preceding example confirms that you have a publicand private key that you can use to authenticate.

Next, let's place the public key on the PVE host so that you can use the SSHkey authentication to login.

Confirm the presence of the keys by listing the contents of ~/.ssh/; ensure that5.both id_rsa and id_rsa.pub are present in the results:

ls ~/.ssh/

Next, push the new public key to the PVE host using the ssh-copy-id tool with6.the following syntax (assuming the username is rgoldman and the PVE host isat 192.168.1.200):

ssh-copy-id rgoldman@192.168.1.200

That's it. Now confirm you can login without a password:7.

ssh rgoldman@192.168.1.200

If you were able to login to your PVE account using SSH without a password, you have

successfully configured SSH key-based authentication for your account.

Securing Proxmox VE

[ 198 ]

The image that follows illustrates the transaction:

SSH key authentication

Note, however, that your password-based authentication mechanism is still active; the SSHserver is still exposed to brute-force or social engineering attacks.

The following steps will disable password-based authentication on your server. Certainly,don't proceed here if you plan to access PVE from other hosts but haven't copied the key yet(or if you are not yet confident with key-based authentication):

Using SSH, log in to the PVE host from a local workstation.1.Escalate privileges:2.

su -

Open the SSH daemon configuration using nano or another plaintext editor:3.

nano /etc/ssh/sshd_config

Browse the contents of the file for the following directive:4.

PasswordAuthentication yes

Change the directive so it is as follows:5.

PasswordAuthentication no

Save the file and close the editor with Ctrl + X, Y, Enter.6.Restart the SSH daemon:7.

/etc/init.d/ssh restart

Chapter 7

[ 199 ]

We can now access Proxmox VE via SSH without worrying about the strength of ourpasswords or being vulnerable to brute force attacks or social engineering attacks.

Note, however, it's imperative when we rely on key-based authentication that we keep ourkeys absolutely secure. This means, in part, remembering consistently to lock ourworkstations and protect our workstation accounts with strong passwords.

Learn more about SSHTo learn more about SSH and authentication, consider visiting thefollowing resources:h t t p s : / / w w w . d e b i a n - a d m i n i s t r a t i o n . o r g / a r t i c l e / 5 3 0 / S S H _ w i th _ a u t h e n t i c a t i o n _ k e y _ i n s t e a d _ o f _ p a s s w o r dh t t p s : / / w w w . d i g i t a l o c e a n . c o m / c o m m u n i t y / t u t o r i a l s / h o w - t o - co n f i g u r e - s s h - k e y - b a s e d - a u t h e n t i c a t i o n - o n - a - l i n u x - s e r v e rh t t p s : / / d e b i a n - h a n d b o o k . i n f o / b r o w s e / s t a b l e / s e c t . r e m o t e - l og i n . h t m l

For additional hardening strategies for SSH, visit h t t p : / / h o w t o . b i a p y .c o m / e n / d e b i a n - g n u - l i n u x / s y s t e m / s e c u r i t y / h a r d e n - t h e - s s h - a c

c e s s - s e c u r i t y - o n - d e b i a n.

Managing patchesAs we discovered, the patch for the VENOM exploit was available for Debian the same daythe exploit was made public; PVE administrators simply had to update and upgrade andrestart PVE guests to eliminate the threat. This should drive home the importance ofapplying security patches not only for the Proxmox VE host, but also for its guests, whetherthey are containers or virtual machines.

However, routinely applying patches for several machines is tedious no matter theassurance it provides.

For the PVE hosts and Ubuntu or Debian guests, there are several tools to relieve thetedium. Finding the sweet spot between fully automated upgrades with minimalinteractivity and doing due diligence to ensure patch candidates won't disrupt operations iswhere the magic happens.

In this section, we'll configure a tool called unattended-upgrades to routinely apply onlysecurity upgrades. We'll leave other patches to our best judgement.

Securing Proxmox VE

[ 200 ]

Use the APT tool to install unattended-upgrades:

su - apt-get update apt-get install -y unattended-upgrades

Then, configure the automated security upgrades:

The default configuration file for the unattended-upgrades package is1.at /etc/apt/apt.conf.d/50unattended-upgrades; let's take a look at it:

nano /etc/apt/apt.conf.d/50unattended-upgrades

Look for the following stanza (the // characters preceding some lines effectively2.comment out directives so they are ignored):

// Automatically upgrade packages from these (origin:archive) pairs Unattended-Upgrade::Allowed-Origins {

"${distro_id}:${distro_codename}-security"; // "${distro_id}:${distro_codename}-updates"; // "${distro_id}:${distro_codename}-proposed"; // "${distro_id}:${distro_codename}-backports"; };

Ensure that the line with “${distro_id}:${distro_codename}-security“;3.is not commented out. This directive signals the utility to allow unattended-upgrades from security repositories, and only from security repositories.Exit the configuration file by pressing Ctrl + X, Y, and Enter to preserve any4.changes you may have made.Next, let's check the configuration of /etc/apt/apt.conf.d/20auto-upgrade5.to ensure that Debian is configured to periodically update package lists and thatunattended-upgrades are enabled:

nano /etc/apt/apt.conf.d/20auto-upgrade

Ensure that the following lines appear in the file as they do here:6.

APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";

With unattended-upgrades configured, de-escalate privileges by entering exit in7.the terminal.

Chapter 7

[ 201 ]

Changes made by the unattended-upgrades utility are logged in/var/log/unattended-upgrades/unattended-upgrades.log.

The same package can be used to automate security patch applications for Proxmox VEguests running Ubuntu, Debian, or LinuxMint.

To learn more about the unattended-upgrades package, see the followingdocumentation:h t t p s : / / w i k i . d e b i a n . o r g / U n a t t e n d e d U p g r a d e sh t t p s : / / d e b i a n - h a n d b o o k . i n f o / b r o w s e / s t a b l e / s e c t . r e g u l a r - up g r a d e s . h t m l

Enterprise subscriptionsThough PVE may be open source, Proxmox Server Solutions (the company behind ProxmoxVE) very strongly encourages users to invest in subscriptions for Proxmox VE (h t t p s : / / w ww . p r o x m o x . c o m / e n / p r o x m o x - v e / s u p p o r t):

“A Proxmox VE subscription is the easy and affordable solution to get access to theProxmox VE Enterprise repository, to stable software updates and security enhancements,as well as to technical support services. A subscription helps you to run Proxmox VE withconfidence in your company.”

“By combining great open source software with quality-assured services and support theProxmox VE Subscription helps you to deploy and maintain the best stable and secureopen source virtualization environment”

Security wise, there is a strong advantage to obtaining a subscription: Proxmox ServerSolutions provides subscribers with access to the enterprise repository, which providesstable and “enhanced” security updates.

In contrast, users of the pve-no-subscription repositories have access to patches that areperhaps more cutting-edge, but also less stable.

Another benefit of a Proxmox subscription is access to dedicated,professional support. This is far from a commentary on communitysupport, which has in all cases been fantastic in my experience. However,subscription support will track a ticket and promise prompt solutions. In aproduction environment, this can certainly make a critical difference.

Securing Proxmox VE

[ 202 ]

There are four subscription plans available: premium, standard, basic, and community (thislast plan does not offer a support plan, but it does offer access to the enterprise repository).Plans are priced per month per CPU socket (h t t p s : / / w w w . p r o x m o x . c o m / e n / p r o x m o x - ve / p r i c i n g).

“Subscriptions are licensed per physical server and CPU socket. In a Proxmox VE Cluster,you need to have the same subscription level for all your servers. Subscription period is oneyear from purchase date.”

Technical support is provided to subscribers via a web and email-based customer portal (inEnglish or German).

Community support, by contrast, is available via the public support forum (h t t p s : / / f o r um . p r o x m o x . c o m) or via IRC (the ##proxmox channel on the Freenode network).

Proxmox community support forum

Chapter 7

[ 203 ]

A video tutorial is available to guide subscribers in uploading a subscription key toProxmox VE and installing new updates at h t t p s : / / w w w . p r o x m o x . c o m / e n / t r a i n i n g / vi d e o - t u t o r i a l s / i t e m / i n s t a l l - u p d a t e s.

From a security perspective then, the pve-no-subscription repository is characterizedon the site as offering patches that are not quite stable enough for production, while theenterprise repository promises enhanced security patches. You'll have to make a deliberatechoice for your use case.

If you're moving services that are not mission-critical to a virtual infrastructure withProxmox VE, perhaps community support and the pve-no-subscription options willwork well for you. Otherwise, give all due consideration to an appropriate subscriptionoption.

SummaryThe security and information that assurance administrators can realistically provide isclearly never as exhaustive as it is exhausting.

In the first section of this chapter, you learned that hardware virtualization has inherentsecurity benefits.

However, you also learned that many promising benefits are undermined if they're notsupported by thorough planning of the virtual infrastructure, explicit policy-making upfront, and a flawless deployment, all followed by unflagging policy enforcement andongoing virtual server lifecycle management.

We then outlined threats that are either unique to virtualized infrastructures or aggravatedin the context of virtualization. Each point was followed by either concrete action tomitigate the threat or links to resources for more details on addressing a potential problem.

We concluded with concrete, step-by-step remedies that could be initiated immediately,even as you continue to explore and assess Proxmox VE.

Where to buy this book You can buy Learning Proxmox VE from the Packt Publishing website.

Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and most internet

book retailers.

Click here for ordering and shipping details.

www.PacktPub.com

Stay Connected:

Get more information Learning Proxmox VE