KVM Virtualization

Posted on by Albertus

Kernel-based Virtual Machine (KVM) is a popular virtualization solution supported by modern Linux kernels. It takes advantage of the CPU support for virtualization (Intel VT and AMD-V). You can run unmodified operating systems such as Linux, FreeBSD, and Microsoft Windows using KVM. For more information, see the compatibility list.

For our Ubuntu 16.04 host, we have installed the following packages via apt (see https://help.ubuntu.com/lts/serverguide/libvirt.html):

  • libvirt-bin
  • qemu-kvm
  • virt-manager
  • virtinst
  • virt-viewer

For a CentOS 7 host, install the following packages via yum:

  • libvirt
  • qemu-kvm
  • qemu-img
  • virt-install
  • virt-manager
  • virt-client

For other Linux distributions, refer to their respective manuals.

You can create virtual machines using the command line as long as you have installed the proper packages. For example, the following creates a CentOS 7 guest with 2 virtual CPUs and 4GiB of RAM:

virt-install -n centos-test \
        --ram 4096 \
        --vcpus 2 \
        --metadata description='CentOS – test',title='CentOS - test' \
        --cdrom /usr/local/src/dists/CentOS/7/CentOS-7-x86_64-Everything-1511.iso \
        --os-variant centos7.0 \
        --disk path=/var/lib/libvirt/images/centos-test-storage0.qcow2,size=40,format=qcow2 \
        --network bridge=br0,model=virtio \
        --graphics spice

If you want to have a processor topology of 2 sockets and 2 cores each, you can specify that as:

        ....
        --vcpus sockets=2,cores=2
        ....

Verification of the processor topology can be done using the utility lscpu, part of util-linux.

The --cdrom parameter points to the installation disc image and the --disk parameter points to the final installed OS image. In this example, we also specify the use of a bridge (the network device br0 in this case) to make it appear on the local host’s network as a regular host. The parameter --graphics specifies Spice as the means of connecting to the VM console.

Naturally, you can also use a GUI (virt-manager) to create the VM, but the command line is more fun, isn’t it? 😉 The man page for virt-install has the requisite information on how to use it. More examples are also available in the man page.

 

Posted in Linux, Linux Distributions, Systems Administration, Virtualization Tagged with: , , , , , ,

Mounting Raw and qcow2 Images

Posted on by Albertus

Mounting Raw and qcow2 images in order to inspect and use them doesn’t have to be difficult. After searching the internet, we found a couple of recommendations on how to do it. Here is what we did ourselves on an Ubuntu 16.04 Linux host.

Mounting The Raw Image

Associate the raw image with a loop device:

losetup /dev/loop0 image.raw

Map the partitions to loop devices:

kpartx -a /dev/loop0

You should be able to mount the partitions now:

mount /dev/mapper/loop0p1 /mnt/t01

where /mnt/t01 is a previously-existing mount point or directory.

For LVM partitions, determine the volume group name and activate it:

vgscan
vgchange -ay vg_volgroupname

Mount the desired logical volume:

mount /dev/mapper/vg_volgroupname-lg_logicalgroupname /mnt/t02

where /mnt/t02 is another pre-existing mount point or directory.

Unmounting The Raw Image

Unmount the previously mounted partitions:

umount /dev/t02
umount /dev/t01

Deactivate the volume group:

vgchange -an vg_volgroupname

Undo the mapping of the partitions to the loop devices:

kpartx -d /dev/loop0

Destroy the loop:

losetup -d /dev/loop0

Mounting The qcow2 Image

Here, we shall use the QEMU Network Block Device Driver for the purposes of mounting the qcow2 image.

First, load the nbd driver.

modprobe nbd max_part=63

Connect nbd to the image using qemu-nbd:

qemu-nbd -c /dev/nbd0 disk1.qcow2

Using fdisk, check the existing partitions. Mount the regular Linux partitions as is:

mount /dev/nbd0p1 /mnt/t01

For LVM partitions, associate a loopback device to the LVM partition:

losetup /dev/loop0 /dev/nbd0p2

See the LVM partitions under /dev/mapper:

ls -l /dev/mapper

You should also be able to display the logical partitions using lvdisplay and the volume groups with vgdisplay. Use vgchange as above to activate the volume group.

Mount the regular LVM partitions as usual:

mount /dev/mapper/vg_volgroupname-lv_logicalgroupname /mnt/t02

Unmounting the qcow2 Image

Unmount the partitions from the qcow2 image:

umount /mnt/t02
umount /mnt/t01

Deactivate the volume group:

vgchange -an vg_volgroupname

Remove the loopback device:

losetup -d /dev/loop0

Disconnect the nbd device:

qemu-nbd -d /dev/nbd0

Finally, remove the nbd kernel module:

rmmod nbd

We have successfully used the above procedures in mounting and unmounting raw and qcow2 images used in Linux KVM.

The procedures described above have been adapted for this article from these URLs:

Posted in Linux, Linux Distributions, Systems Administration Tagged with: , , , ,

Digital Certificate Generation and OpenSSL

Posted on by Albertus

Digital certificates are used to help secure communications across networks, including the Internet. Web servers that are accessed via the HTTPS protocol involve the use of digital certificates on the server side and, in some circumstances, on the client side as well. Signing and encrypting email with the use of S/MIME also involves the use of client and server-side digital certificates. Certain VPN software might also use digital certificates on both sides of the communication line.

The question one might ask is how to get these digital certificates and install them for use by applications on the client and server sides. Usually, organizations and individuals acquire their digital certificates from vendors that participate in an ecosystem of providers officially recognized by applications requiring digital certificates to enable secure communications. These providers are called certificate authorities (CAs).

Organizations can also become CAs within their own domain involving themselves and other parties that communicate with them. Software is readily available to give organizations the ability to become CAs. Platforms such as Linux, Microsoft Windows (Server), and Apple Mac OS have the necessary software to generate digital certificates. OpenSSL is one such software available on most platforms. Note that OpenSSL is not the only software available for this purpose.

Creating A Certificate Authority Digital Certificate

It is possible to become a certificate authority (CA) by generating your own CA digital certificate and private key. The CA digital certificate and private key are used to sign and generate digital certificates for servers and clients for the purpose of encrypting communications and digitally signing digital assets such as software, computer documents and email. The one caveat is that, unless you become one of globally-accepted certificate authorities, your CA is limited to your use within your own organization and with trusted third-parties.

The steps below assume you are using CentOS Linux 6 or 7.

In OpenSSL, one can generate what is called a self-signed CA certificate using this command:

openssl req -new -x509 -key privkey.pem -out cacert.pem -days 3650

The above command, however, is not the recommended way of generating a self-signed CA certificate.

Below is the sequence one must use in generating a CA self-signed certificate:

  1. Generate a private key.
  2. Create a certificate signing request (CSR).
  3. Sign the request and generate the certificate.

This can be illustrated by the OpenSSL commands below:

openssl genrsa -aes256 -out CA.key 2048
openssl req -new -key CA.key -text -out CA.csr
openssl ca -in CA.csr -out CA.crt -keyfile CA.key -selfsign -extensions v3_ca

The above commands assume that CA.key, CA.csr, and CA.crt are the private key, certificate signing request, and the CA certificate, respectively. The extension v3_ca refers to a section in the OpenSSL configuration file openssl.cnf that tags the generated certificate as a CA certificate. In CentOS, the configuration file is in /etc/pki/tls.  A sample openssl.cnf file is shown at the end of this article.

If an error is encountered about a couple of missing files in /etc/pki/CA, there may be a need to create these files in /etc/pki/CA before generating the certificate:

touch index.txt
echo 00 > serial

Note: Some would generate a subordinate CA using the above root CA certificate. The subordinate CA certificate and private key are then used to generate other certificates while the root CA certificate and private key are kept securely offline unless needed. It is of utmost importance to protect the root CA and private key.

Creating Other Certificates

Once the CA certificate and private key exist, creating other certificates should be reasonably easy:

  1. Generate a private key for the new certificate: openssl genrsa -aes256 -out somename.key 2048
  2. Generate a CSR: openssl req -new -key somename.key -text -out somename.csr
  3. As a CA, sign the CSR to generate certificate: openssl ca -in somename.csr -out somename.crt [-extensions server_cert|usr_cert]

server_cert tells OpenSSL to create a server certificate while usr_cert tells OpenSSL to generate a client certificate. These two are defined in /etc/pki/tls/openssl.cnf.

 Sample OpenSSL Configuration

Below is a sample configuration based on the default CentOS OpenSSL configuration file:

#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME            = .
RANDFILE        = $ENV::HOME/.rnd

# Extra OBJECT IDENTIFIER info:
#oid_file        = $ENV::HOME/.oid
oid_section        = new_oids

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions        = 
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7

####################################################################
[ ca ]
default_ca    = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir        = /etc/pki/CA        # Where everything is kept
certs        = $dir/certs        # Where the issued certs are kept
crl_dir        = $dir/crl        # Where the issued crl are kept
database    = $dir/index.txt    # database index file.
#unique_subject    = no            # Set to 'no' to allow creation of
                    # several ctificates with same subject.
new_certs_dir    = $dir/newcerts        # default place for new certs.

certificate    = $certs/CA.crt     # The CA certificate
serial        = $dir/serial         # The current serial number
crlnumber    = $dir/crlnumber    # the current crl number
                    # must be commented out to leave a V1 CRL
crl        = $dir/crl.pem         # The current CRL
private_key    = $dir/private/CA.key  # The private key
RANDFILE    = $dir/private/.rand    # private random number file

x509_extensions    = usr_cert        # The extentions to add to the cert

# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt     = ca_default        # Subject Name options
cert_opt     = ca_default        # Certificate field options

# Extension copying option: use with caution.
# copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions    = crl_ext

default_days    = 3650            # how long to certify for
default_crl_days= 30            # how long before next CRL
default_md    = default        # use public key default MD
preserve    = no            # keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy        = policy_match

# For the CA policy
[ policy_match ]
countryName        = match
stateOrProvinceName    = match
organizationName    = match
organizationalUnitName    = optional
commonName        = supplied
emailAddress        = optional

# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName        = optional
stateOrProvinceName    = optional
localityName        = optional
organizationName    = optional
organizationalUnitName    = optional
commonName        = supplied
emailAddress        = optional

####################################################################
[ req ]
default_bits        = 2048
default_md        = sha1
default_keyfile     = privkey.pem
distinguished_name    = req_distinguished_name
attributes        = req_attributes
x509_extensions    = v3_ca    # The extentions to add to the self signed cert

# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret

# This sets a mask for permitted string types. There are several options. 
# default: PrintableString, T61String, BMPString.
# pkix     : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only

# req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName            = Country Name (2 letter code)
countryName_default        = XX
countryName_min            = 2
countryName_max            = 2

stateOrProvinceName        = State or Province Name (full name)
#stateOrProvinceName_default    = Default Province

localityName            = Locality Name (eg, city)
localityName_default    = Default City

0.organizationName        = Organization Name (eg, company)
0.organizationName_default    = My Organization

# we can do this but it is not needed normally :-)
#1.organizationName        = Second Organization Name (eg, company)
#1.organizationName_default    = World Wide Web Pty Ltd

organizationalUnitName        = Organizational Unit Name (eg, section)
organizationalUnitName_default    = IT

commonName            = Common Name (eg, your name or your server\'s hostname)
commonName_max            = 64

emailAddress            = Email Address
emailAddress_max        = 64

# SET-ex3            = SET extension number 3

[ req_attributes ]
challengePassword        = A challenge password
challengePassword_min        = 4
challengePassword_max        = 20

unstructuredName        = An optional company name

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# and for everything including object signing:
nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment            = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl        = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping

[ server_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
nsCertType            = server

# This will be displayed in Netscape's comment listbox.
nsComment            = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl        = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]


# Extensions for a typical CA


# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true

# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign

# Some might want this also
# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always

[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType            = server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape's comment listbox.
nsComment            = "OpenSSL Generated Certificate"

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl        = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

####################################################################
[ tsa ]

default_tsa = tsa_config1    # the default TSA section

[ tsa_config1 ]

# These are used by the TSA reply generation only.
dir        = ./demoCA        # TSA root directory
serial        = $dir/tsaserial    # The current serial number (mandatory)
crypto_device    = builtin        # OpenSSL engine to use for signing
signer_cert    = $dir/tsacert.pem     # The TSA signing certificate
                    # (optional)
certs        = $dir/cacert.pem    # Certificate chain to include in reply
                    # (optional)
signer_key    = $dir/private/tsakey.pem # The TSA private key (optional)

default_policy    = tsa_policy1        # Policy if request did not specify it
                    # (optional)
other_policies    = tsa_policy2, tsa_policy3    # acceptable policies (optional)
digests        = md5, sha1        # Acceptable message digests (mandatory)
accuracy    = secs:1, millisecs:500, microsecs:100    # (optional)
clock_precision_digits  = 0    # number of digits after dot. (optional)
ordering        = yes    # Is ordering defined for timestamps?
                # (optional, default: no)
tsa_name        = yes    # Must the TSA name be included in the reply?
                # (optional, default: no)
ess_cert_id_chain    = no    # Must the ESS cert id chain be included?
                # (optional, default: no)
Posted in Linux, Linux Distributions, Security and Encryption Tagged with: , , , , , , , , , ,

Ads

Twitter

NameCheap