• LOGIN
  • No products in the cart.

OpenBSD 6.1

The recently released OpenBSD 6.1 includes major update, and this article will cover all of the significant changes and features of the new release. The OpenBSD 6.1 release will be the first to not provide an official CD media set for purchase. Instructions on how to create a bootable install media for OpenBSD 6.1 can be found at https://www.openbsd.org/faq/faq4.html#MkInsMedia

New Platform Architecture Support

The is new release now provides functional support for ARM64 architecture and the following hardware platforms: PINE 64 (Allwinner A64), Raspberry Pi 3 (BCM2837) and the AMD Seattle.  Additionally, another related hardware architecture platform is the armv7. For more details on how to install OpenBSD on the Raspberry PI 3, visit: http://undeadly.org/cgi?action=article&sid=20170409123528

For architecture specific installation details, please refer to the respective supported platform install instructions at: https://www.openbsd.org/plat.html

OpenSSH Changes

It’s important to mention that shipped version of OpenSSH 7.4 server has removed both SSH v1 protocol support and  SSH client support for 3des-cbc. This might cause trouble for legacy ssh clients to connect via OpenSSH.

Binary Patching

The syspatch(8) binary patching is now part of the base operating system and provides a utility to ease fetching, verifying, installing and reverting OpenBSD binary patches on stable release for amd64 and i386 platforms only.

A prerequisite for using syspatch(8) the /etc/installurl configuration file must be populated with a single line with the valid URL from OpenBSD FTP or HTTP mirrors: (https://www.openbsd.org/ftp.html).

# echo "# /etc/installurl" > /etc/installurl

# echo "https://ftp.openbsd.org/pub/OpenBSD" >> /etc/installurl

Please note that /etc/installurl replaces /etc/pkg.conf(5). If you would like to specify more than one repository path, you must set PKG_PATH environment variable (see Table 1).

Syspatch Usage

Command Description

# syspatch Save the original release kernel, create a rollback tarball containing the files it is about to be replaced, apply all missing patches and then installing all files
# syspatch -c List available patches
# syspatch -l List installed patches
# syspatch -r Revert recently installed patches

Table 1. Syspatch usage

After invocation of the syspatch command, a copy of the original binaries will be stored under /var/syspatch/* . Additionally, the original kernel will be backed up and stored /bsd.syspatch${OSrev}

Let’s Encrypt SSL/TLS Certificate Management with the Automatic Certificate Management Environment (ACME)

This feature provides a native support and a  replacement for the deprecated port security/letskencrypt. The acme-client allows for automated deployment and management of Let’s Encrypt certificates for one or more domains. Additionally, the acme-client will refresh the signature for an existing certificate prior to 30 days before expiry.

The full complete certificate file is located at /etc/ssl/acme/fullchain.pem and a related private key file is located at /etc/ssl/acme/private/privkey.pem/

For example, to initially configure and use acme-client for a  domain running under port 80, the following commands must be executed:

  1. Create a new RSA account and domain key if it does not exist: # acme-client -ADv tld.com
  2. Setup the webserver for the challenge response process of the Let’s Encrypt service.

The directory which contains the challenge is /var/www/acme , and can be served by httpd(8) and configuring /etc/httpd.conf

server "tld.com" {

root "/empty"

listen on * port 80

location "/.well-known/acme-challenge/*" { 

root "/acme" 

root strip 2 

}

}

As root under the /.well-known/acme-challenge , type the following commands to generate the certificates:

# acme-client -vD tld.com www.tld.com

The above command is equivalent to the manual process of managing certificate authorities, which is comprised of the following steps:

  1. Generating the webserver private and public keys.
  2. Submitting your public key to the certificate authority.
  3. Providing proof of authorization to the certificate authority that you have the certificate for the domains you are requesting.
  4. Retrieving and installing the signed certificate.

 

Create and submit a new key for a single domain with a configured webserver to use challenge directory # acme-client -vD tld.com
Renew the certificate (or can be added as cron job for automated renewal) # acme-client tld.com www.tld.com

# rcctl reload httpd

 

Native Virtual Machine Support

Furthermore, this release provides a native virtual machine hyper-visor and has support for VMs with memory greater than 2GB of RAM using the vmm(4)/vmctl(8) tools and vmd(8) daemon. The vmd(8) daemon is responsible for the execution, provides VM  provisioning by configuring the VM, virtual CPUs and related device layer configurations and control of the virtual machine, and is executed upon boot when the vmd_flags=”” has been enabled in the /etc/rc.conf.local configuration file.  The management of the vmd(8) and vmctl(8) provides management for the VMs. OpenBSD’s virtual machine fully supports privilege separation using the pledge(2) system call policy interface.

All aspects of VM configuration are defined within the global /etc/vm.conf file. Additional configurations can be loaded and specified by using the include “/etc/vm.tld.com.conf”

To setup and run an OpenBSD requires the following configuration changes to be made:

/etc/hostname.vether0

inter 10.0.1.1 255.255.255.0 NONE

/etc/vm.conf

switch "local" {

add vether0

add tap0

}

vm "vm0.vm" {

memory 1024M

kernel "/bsd.rd"

disk "/vmm/vm0.img"

interface {

switch "local"

lladdr 00:11:22:33:44:55

}

}

 

VM Network Configuration

For example,  we will setup a virtual machine network with the following configuration:

Domain name: tld.com

IP Address: 10.0.1.1    Subnet mask: 255.255.255.0

Name server: 10.0.1.1

Default router: 10.0.1.1

Valid Address Range: 10.0.1.1 – 10.0.1.254

Subnet ID: 10.0.1.0

Broadcast Address: 10.0.1.255

 

/etc/dhcd.conf

shared-network VMM-tld.com {

subnet 10.0.1.0 netmask 255.255.255.0 {

range  10.0.1.1 10.0.1.254;

option subnet-mask 255.255.255.0;

option broadcast-address 10.0.1.255;

option routers 10.0.1.1;

option domain-name-servers: 10.0.1.1

}

}



/etc/sysctl.conf

net.inet.ip.forwarding=1



/etc/pf.conf

set skip on lo



block return    # block stateless traffic

pass            # establish keep-state



# By default, do not permit remote connections to X11

block return in on ! lo0 proto tcp to port 6000:6010



ext_if="em0"

int_if="{ vether0 tap0 }"

set block-policy drop

set loginterface egress

match in all scrub (no-df random-id max-mss 1440)

match out on egress inet from !(egress:network) to any nat-to (egress:0)

pass out quick inet

pass in on $int_if inet

/etc/rc.conf.local

dhcpd_flags=vether0

vmd_flags=

 

To start this example, VMM executes the following commands:

  • This sets up the VMM console output redirection

 

# vmctl console 1

# cu /dev/ttyp0

 

  • This creates the virtual machine disk image and starts the virtual machine

 

# vmctl create /vmm/vm0.img -s 1024M

# vmctl start -c -k /bsd.rd -m 1024M -i 1 -d /vmm/vm0.img

 

VMM Usage Reference

To convert an existing Public Cloud Images *.img to VMM compatiable raw image extension (OpenStack, LXD, etc. ) Must install qemu using ports or packages

# qemu-img convert cloudimg-amd64.img cloudimg-amd64.raw

Start the converted Cloud Image VM using VMM with NAT and starting the console # vmctl start cloudimage -d cloudimg-amd64.raw -n nat -c
Starting the VMM # vmctl start vmlabel
Stopping the VMM # vmctl stop vmlabel
VMM Status # vmctl status
Create a  disk image with specific size # vmctl create disk -s 3.0G
Create a new VM with a specified memory size # vmctl start “vmlabel” –m 4096M -i -d disk.img -k /bsd -c

 

Please refer to the main pages: vmctl(8) http://man.openbsd.org/OpenBSD-6.1/vmctl, vm.conf

(5) http://man.openbsd.org/OpenBSD-6.1/vm.conf.5 , and the OpenBSD FAQ “Networking vmm guests” https://www.openbsd.org/faq/faq6.html#VMMnet for additional commands and configuration details.

 

VM Network Switch Configuration

The OpenBSD VMM allows for the virtual machines (VM) to communicate with other network interfaces on the host system by using the bridge(4) or switch(4). These interfaces for the virtual switch can be configured using the ifconfig(8) command or the hostname.if(5) configuration file option. Upon start up of the VM, all interfaces which have been assigned to the virtual switch will have the tap(4) network interfaces to be automatically created and assigned to the respective bridge(4) or switch(4) mapped virtual switch interfaces.

Software Defined Networking on OpenBSD: switchd(8) and switch(4)

The 6.1 will provide native built-in support for software defined networking (SDN) in implementing the OpenFlow* (*OpenFlow has a Trademark) protocol version 1.3.5.

OpenFlow protocol allows for the direct access to the data/user plane, a component of a network switch or router architecture which determines how forwarding decisions are being made. The ability to administrator, program, manipulate control and modify packet forwarding and routing capabilities at the OSI layer 3. The decoupling of the forwarding and network control functions defines the core functionality of software-defined networking architecture. The OpenFlow protocol operates using TCP and is between the switch and controller.  Switchd(8) functions as a proxy between the OpenFlow controller and  the switch()4 comprised of the following two components:

  • 1. The OpenFlow controller/fowarder or vswitch: switchd(8) and switchctl(8)

The switchd(8) daemon functions like a local controller and operates at the user level.

  • 2. Kernel bridge switch(4) driver and user-kernel interface /dev/switch*

The switch(4) kernel driver is partially based upon OpenBSD’s bridge(4).

This feature is implemented using a client and server model whereas the user level controller, daemon and forwarder switch(8).

Later on,  we will provide a tutorial of how to use the virtual switch:

A mandatory prerequisite for using the virtual switch is to create a virtual Ethernet interface as a permanent host interface as shown previously in VMM usage,

/etc/hostname.vether0

inter 10.0.1.1 255.255.255.0 NONE

A virtual switch interface device for use by switchd(8) or switctl(8) must be created using the following commands:

  • switchd interface:                      # ifconfig switch0 create
  • local mode switch interface:   # ifconfig switch0 addlocal vether0
  • persistent switch interface startup at boot:     
# cat /etc/hostname.switch0

up

!rcctl -f start switchd

!switchctl connect /dev/switch0

!ifconfig switch0 addlocal vether0

!ifconfig vether0 up

or manually started 

# /etc/rc.d/switchd

# switchctl connect /dev/switch0

After creating the switch interface, a corresponding OpenFlow channel of the interface will be created under /dev/switch0. This stream device reads the OpenFlow message headers first then the entire message contents subsequently.

Switchctl(8) is used to control switchd(8) daemon which allows for controlling how the daemon interfaces with an address or switch(4) device.  An alternate method of configuring switchd(8) daemon is to set default global configuration values from /etc/switchd.conf. To configure and set the listener address and port to accept connections from remote OpenFlow switches over a regular OpenFlow protocol or wrapped using tls will require the following options:

/etc/switchd.conf

listen on 0.0.0.0 port 6655

or by accepting a remote switch tls OpenFlow connection

/etc/switchd.conf

listen on 0.0.0.0 tls port 6655

The switchd(8) configuration file can be checked for errors by: /etc/rc.d/switchd -n -v

For additional details please refer to the man pages for additional details:

switchctl(8) http://man.openbsd.org/OpenBSD-6.1/switchctl.8 ,

switchd(8) http://man.openbsd.org/OpenBSD-6.1/switchd.8

switchd.conf(5) http://man.openbsd.org/OpenBSD-6.1/switchd.conf.5

Conclusion

We’ve covered and highlighted several key innovative features in this new 6.1 release of OpenBSD.

About the Author

Albert Hui has been passionate about Unix and other exotic operating systems. He  has also been an OpenBSD enthusiast since 2003. To contact the author: [email protected]

 

August 30, 2017

Leave a Reply

Be the First to Comment!

Notify of
avatar
wpDiscuz
© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013