The Spectre and Meltdown situation

170px-SPECTRE_Logo

Many blog posts have been written about the two biggest security vulnerabilities discovered so far in 2018. In fact, we are talking about three different vulnerabilities:

  • CVE-2017-5715 (branch target injection)
  • CVE-2017-5753 (bounds check bypass)
  • CVE-2017-5754 (rogue data cache load)

CVE-2017-5715 and CVE-2017-5753 are known as “Spectre”, CVE-2017-5754 is known as “Meltdown”. If you want to read more about these vulnerabilities, please visit spectreattack.com & meltdownattack.com

Multiple steps are necessary to be protected, and all necessary information are often repeated, but were distributed over several websites, vendor websites, articles, blog posts or security announcements.

How to protect yourself against these attacks

Two (apparent simple) steps are necessary to be protected against these vulnerabilities:

  1. Apply operating system updates
  2. Update the microcode (BIOS) of your server/ workstation/ laptop

If you use a hypervisor to virtualize guest operating systems, then you have to update your hypervisor as well. Just treat it like an ordinary operating system. Also if your using vendor created software appliances that may be based on OS distributions like CentOS then those need to be protected also.

Sounds pretty simple, but it’s not. I will focus on three vendors in this blog post:

  • Microsoft
  • Linux
  • VMware

Let’s start with Microsoft. Microsoft has published the security advisory ADV180002  on 01/03/2018.

Microsoft Windows (Client)

The necessary security updates are available for Windows 7 (SP1), Windows 8.1, and Windows 10. The January 2018 security updates are ONLY offered in one of theses cases (Source: Microsoft):

  • An supported anti-virus application is installed
  • Windows Defender Antivirus, System Center Endpoint Protection, or Microsoft Security Essentials is installed
  • A registry key was added manually

 

Update
Windows 10 (1709) KB4056892
Windows 10 (1703) KB4056891
Windows 10 (1607) KB4056890
Windows 10 (1511) KB4056888
Windows 10 (initial) KB4056893
Windows 8.1 KB4056898
Windows 7 SP1 KB4056897

Please note, that you also need a microcode update! Reach out to your vendor.

Windows Server

The necessary security updates are available for Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2016 and Windows Server Core (1709). The security updates are NOT available for Windows Server 2008 and Server 2012!. The January 2018 security updates are ONLY offered in one of theses cases (Source: Microsoft):

  • An supported anti-virus application is installed
  • Windows Defender Antivirus, System Center Endpoint Protection, or Microsoft Security Essentials is installed
  • A registry key was added manually

 

OS Update
Windows Server, version 1709 (Server Core Installation) KB4056892
Windows Server 2016 KB4056890
Windows Server 2012 R2 KB4056898
Windows Server 2008 R2 KB4056897

After applying the security update, you have to enable the protection mechanism. This is different to Windows Windows 7, 8.1 or 10! To enable the protection mechanism, you have to add three registry keys:

VMware has published two VMware Security Advisories (VMSA):

VMware Workstation Pro, Player, Fusion, Fusion Pro, and ESXi are affected by CVE-2017-5753 and CVE-2017-5715. VMware products seems to be not affected by CVE-2017-5754. On 09/01/2017, VMware has published VMSA-2018-0004, which also addresses CVE-2017-5715. Just to make this clear:

  • Hypervisor-Specific Remediation (documented in VMSA-2018-0002)
  • Hypervisor-Assisted Guest Remediation (documented in VMSA-2018-0004)

Before you apply any security updates, please make sure that you :

  • Deploy the updated version of vCenter listed in the table (only if vCenter is used).
  • Deploy the ESXi security updates listed in the table.
  • Ensure that your VMs are using Hardware Version 9 or higher. For best performance, Hardware Version 11 or higher is recommended.

For more information about Hardware versions, read VMware KB article 1010675.

VMSA-2018-0002

OS Update
ESXi 6.5 ESXi650-201712101-SG
ESXi 6.0 ESXi600-201711101-SG
ESXi 5.5 ESXi550-201709101-SG

VMSA-2018-0004

OS Update
ESXi 6.5 ESXi650-201801401-BG, and
ESXi650-201801402-BG
ESXi 6.0 ESXi600-201801401-BG, and
ESXi600-201801402-BG
ESXi 5.5 ESXi550-201801401-BG
vCenter 6.5 6.5 U1e
vCenter 6.0 6.0 U3d
vCenter 5.5 5.5 U3g

All you have to do is:

  • Update your vCenter to the latest update release, then
  • Update your ESXi hosts with all available security updates
  • Apply the necessary guest OS security updates and enable the protection (Windows Server)

Make sure that you also apply microcode updates from your server vendor!

 

Posted in Microsoft, VMware | Leave a comment

QNAP TS-431X NAS with 10G SFP+

QNAP today announced the new TS-431X NAS with a built-in 10GbE SFP+ port. It is powered by a dual-core AnnapurnaLabs, an Amazon company Alpine AL-212 1.7 GHz processor and 2GB/8GB DDR3 RAM (upgradable to 8GB). The TS-431X delivers up to 956 MB/s read speed with 10GbE.

266_1

Along with its application-aware design and abundant productive features including containerized virtualization, centralized email management, a private-cloud-based note-taking tool, and Virtual JBOD, the 10GbE-ready TS-431X is a perfect NAS for small and midsize businesses looking for backup, restoration, private cloud, and higher bandwidth for rigorous data processing.

The integrated 10GbE SFP+ port enables exceptional throughput for intensive data transfer, and fast backup and restoration for an ever-growing amount of data.

“Designed to solve more complex and demanding applications in today’s IT environments, the TS-431X is well suited for organizations that have budget constraints but require high bandwidth to tackle inefficiencies.” said Dan Lin, Product Manager of QNAP.

The TS-431X features Container Station that integrates LXC and Docker® lightweight virtualization technologies, enabling unlimited containerized applications. It offers the innovative QIoT Containers to store Internet of Things (IoT) data, and helps organizations boost IoT-based microservices and modernize legacy applications to drive more business opportunities.

The TS-431X is an all-in-one NAS supporting not only essential cross-platform file sharing, backup, restoration, and security, but also exclusive productivity apps. QmailAgent allows users to centrally manage multiple email accounts from popular email services and IMAP servers; Notes Station provides an online note-taking tool enabling collaborative writing; Qsync enables cross-devices file synchronization and team folders sync; and the powerful Qsirch full-text search engine helps quickly find files on the NAS. The TS-431X also supports VPN server and VPN client, IP surveillance system, and VJBOD (Virtual JBOD) to expand the storage capacity of other QNAP NAS.

Key specifications

    • TS-431X-2G: 2GB DDR3 RAM (2GB x1)
    • TS-431X-8G: 8GB DDR3 RAM (8GB x1)

4-bay tower model; AnnapurnaLabs, an Amazon company Alpine AL-212 1.7 GHz dual-core processor, hardware-accelerated encryption engine; hot-swappable 2.5″/3.5″ SATA 6Gbps HDD or SSD; 1 x 10 Gigabit SFP+ port, 2 x Gigabit RJ45 ports; 3 x USB 3.0 port, Kensington security slot

Posted in Uncategorized | Leave a comment

Openstack – Configuring for LVM Storage Backend

The volume service is able to make use of a volume group attached directly to the server on which the service runs. This volume group must be created exclusively for use by the block storage service and the configuration updated to point to the name of the volume group.
The following steps must be performed while logged into the system hosting the volume service as the root user:
  1. Use the pvcreate command to create a physical volume.
    # pvcreate DEVICE
      Physical volume "DEVICE" successfully created
    Replace DEVICE with the path to a valid, unused, device. For example:

    # pvcreate /dev/sdX
  2. Use the vgcreate command to create a volume group.
    # vgcreate cinder-volumes DEVICE
      Volume group "cinder-volumes" successfully created
    Replace DEVICE with the path to the device used when creating the physical volume. Optionally replace cinder-volumes with an alternative name for the new volume group.
  3. Set the volume_group configuration key to the name of the newly created volume group.
    # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT volume_group cinder-volumes
    The name provided must match the name of the volume group created in the previous step.
  4. Ensure that the correct volume driver for accessing LVM storage is in use by setting the volume_driverconfiguration key to cinder.volume.drivers.lvm.LVMISCSIDriver.
    # openstack-config --set /etc/cinder/cinder.conf \
    DEFAULT volume_driver cinder.volume.drivers.lvm.LVMISCSIDriver
The volume service has been configured to use LVM storage.
Posted in KVM, Openstack | Leave a comment

Openstack Liberty Error: Unable to retrieve volume limit information.

After an Openstack Liberty deployment  you may encounter the following error: Error: Unable to retrieve volume limit information. OR Danger: There was an error submitting the form. Please try again.

unable to retreive size limit

These errors are a result of a miss-configuration within CINDER, to resolve this all you need to do is edit the ‘/etc/cinder/cinder.conf‘ file and make sure the following two lines exist

[keystone_authtoken]
auth_uri = http://keystone_ip:5000
auth_url = http://keystone_ip:35357
auth_plugin = password
project_domain_id = default
user_domain_id = default
project_name = services
username = cinder
password = [ccinder password] <- find from answer file. password is stored in CONFIG_CINDER_KS_PW

After you had verified or added the lines you will need to restart the cinder services by running:

# service openstack-cinder-api restart
# service openstack-cinder-backup restart
# service openstack-cinder-scheduler restart
# service openstack-cinder-volume restart

Posted in Uncategorized | Leave a comment

Using multiple external networks in OpenStack Neutron

I haven’t found a lot of documentation about it, but basically, here’s how to do it. Lets assume the following:

  • you start from a single external network, which is connected to ‘br-ex’
  • you want to attach the new external network to ‘eth1’.

In the network node (were neutron-l3-agent, neutron-dhcp-agent, etc.. run):

  • Create a second OVS bridge, which will provide connectivity to the new external network:
ovs-vsctl add-br br-eth1

ovs-vsctl add-port br-eth1 eth1

ip link set eth1 up
  • (Optionally) If you want to plug a virtual interface into this bridge and add a local IP on the node to this network for testing:
ovs-vsctl add-port br-eth1 vi1 – set Interface vi1 type=internal

ip addr add 192.168.1.253/24 dev vi1 # you may adjust your network CIDR, or set your system configuration to setup this at boot.
  • Edit your /etc/neutron/l3_agent.ini , and set/change:
gateway_external_network_id =

external_network_bridge =

This change tells the l3 agent that it must relay on the physnet<->bridge mappings at /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini it will automatically patch those bridges and router interfaces around. For example, in tunneling mode, it will patch br-int to the external bridges, and set the external ‘q’router interfaces on br-int.

  • Edit your /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini to map ‘logical physical nets’ to ‘external bridges’
bridge_mappings = physnet1:br-ex,physnet2:br-eth1
  • Restart your neutron-l3-agent and your neutron-openvswitch-agent
service neutron-l3-agent restart

service neutron-openvswitch-agent restart

At this point, you can create two external networks (please note, if you don’t make the l3_agent.ini changes, the l3 agent will start complaining and will refuse to work)

neutron net-create ext_net –provider:network_type flat –provider:physical_network physnet1 –router:external=True

neutron net-create ext_net2 –provider:network_type flat –provider:physical_network physnet2 –router:external=True

And for example create a couple of internal subnets and routers:

# for the first external net

neutron subnet-create ext_net –gateway 172.16.0.1 172.16.0.0/24 – –enable_dhcp=False # here the allocation pool goes explicit…. all the IPs available..

neutron router-create router1

neutron router-gateway-set router1 ext_net

neutron net-create privnet

neutron subnet-create privnet –gateway 192.168.123.1 192.168.123.0/24 –name privnet_subnet

neutron router-interface-add router1 privnet_subnet
# for the second external net

neutron subnet-create ext_net2 –allocation-pool start=192.168.1.200,end=192.168.1.222 –gateway=192.168.1.1 –enable_dhcp=False 192.168.1.0/24

neutron router-create router2

neutron router-gateway-set router2 ext_net2

neutron net-create privnet2

neutron subnet-create privnet2 –gateway 192.168.125.1 192.168.125.0/24 –name privnet2_subnet
 neutron router-interface-add router2 privnet2_subnet
Posted in Openstack | Leave a comment

Setting Up a Flat Network with Openstack Neutron

This setup will allow the VMs to use an existing network. In this example, eth2 is connected to this pre-existing network (192.168.1.0/24) that we want to use for the OpenStack VMs.

All the configuration is done in the node dedicated to Nova Networking.

1. Set up the Open vSwitch bridge:

# ovs-vsctl add-br br-eth2
# ovs-vsctl add-port br-eth2 eth2

2. Set up /etc/network/interfaces (node’s IP is 192.168.1.7):

auto eth2
iface eth2 inet manual
up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down

auto br-eth2
iface br-eth2 inet static
address 192.168.1.7
netmask 255.255.255.0

3. Tell Open vSwitch to use the bridge connected to eth2 (br-eth2) and map physnet1 to it /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini:

[ovs]
network_vlan_ranges = physnet1
bridge_mappings = physnet1:br-eth2

4. Tell Neutron to not to use the metadata proxy in /etc/nova/nova.conf (otherwise you get a HTTP 400 when querying the metadata service):

service_neutron_metadata_proxy=false

Note that the metadata service is managed by Neutron as usual via the neutron-metadata-agent service anyway.

5. Create the network telling to use the physnet1 mapped above to br-eth2:

# neutron net-create flat-provider-network --shared  --provider:network_type flat --provider:physical_network physnet1

6. Create the subnet:

# neutron subnet-create --name flat-provider-subnet --gateway 192.168.1.5 --dns-nameserver 192.168.1.254  --allocation-pool start=192.168.2.100,end=192.168.2.150  flat-provider-network 192.168.2.0/24

That’s it. Now VMs will get an IP of the specified range and will be directly connected to our network via Open vSwitch.

Posted in Openstack | Leave a comment

Fixing Openstack Kilo Horizon Re-login issue

Fixing Horizon Re-login issue

There is an issue in OpenStack Kilo with re-login because of a bad cookie session. Here is how to fix the issue.

#vi /etc/openstack-dashboard/local_settings
AUTH_USER_MODEL = 'openstack_auth.User'
Posted in Openstack | Leave a comment