Home Lab – a lie I tell myself

Since March of 2020 I’ve been working on building out a homelab. Something about being inside a little more drove me to want to work with the computers at home. Normally that free time would be spent at community events or with presentations. Something had to fill the void and a homelab was it.

At first, the goal was simple; learn about different server technologies and edge computing by building a “data center” in a closet. The “data center” part of it is where most at home sysadmins fall into a bottomless pit of self-hosted technologies and I am no different. First it is a home media server, then a dashboard, then a database, then a data system, then a clustered set of systems, then there is suddenly a need for documentation for a lab you built yourself as it becomes too much to handle at once.

This will, hopefully, be the first of many posts about home labs that is written from personal and professional experience. Throughout the series there should be a showcase of how to use home labs for:

Home Media
Automation
Edge Computing
Archiving
Game Servers
Development Servers
Access and Control
Dynamic Public Cloud Integration
Redundancy and Disaster Recovery
and… more

The first and foremost discussion to have is price control. Enterprise server contracts can start at seven figures. If this is what you are looking for, then this is not the blog you seek. What this blog will focus on is how to keep a relatively low budget. Lets see how far we can make the homelab budget go!

At this point, you may be wondering why the title is “Home Lab – a lie I tell myself”. When this journey started, this was a 1-2 tower server adventure. Over time this has exploded, both in scope and in price. At this point, the name “homelab” no longer describes the system I’ve built. Not just in size but also due to the fact that it is no longer at my home. Hopefully, this series can serve as both enablement and deterrent to an ever expanding homelab.

Some helpful resources I used when I got started:

Securing SSH in Azure

On a recent project I inherited an Azure IaaS setup that managed Linux VMs by connecting via SSH from public IPs. I figured while we did a vNet migration we might as well secure the SSH pipeline.

Disable SSH Arcfour and CBC Ciphers

Arcfour is compatible with RC4 encryption and has issues with weak keys, which should be avoided. See RFC 4353 for more information here.

The SSH server located on the remote host also allows cipher block chaining (CBC) ciphers to be used to establish a Secure Shell (SSH) connection, leaving encrypted content vulnerable to a plaintext recovery attack. SSH is a cryptographic network protocol that allows encrypted connections between machines to be established. These connections can be used for remote login by an end user, or to encrypt network services. SSH leverages various encryption algorithms to make these connections, including ciphers that employ cipher block chaining.

The plaintext recovery attack can return up to thirty two bits of plaintext with a probability of 2-18 or fourteen bits of plain text with a probability of 2-14. This exposure is caused by the way CBC ciphers verify the message authentication code (MAC) for a block. Each block’s MAC is created by a combination of an unencrypted sequence number and an encrypted section containing the packet length, padding length, payload, and padding. With the length of the message encrypted the receiver of the packet needs to decrypt the first block of the message in order to obtain the length of the message to know how much data to read. As the location of the message length is static among all messages, the first four bytes will always be decrypted by a recipient. An attacker can take advantage of this by submitting an encrypted block, one byte at a time, directly to a waiting recipient. The recipient will automatically decrypt the first four bytes received as it the length is required to process the message’s MAC. Bytes controlled by an attacker can then be submitted until a MAC error is encountered, which will close the connection. Note as this attack will lead to the SSH connection to be closed, iterative attacks of this nature will be difficult to carry out against a target system.

Establishing an SSH connection using CBC mode ciphers can result in the exposure of plaintext messages, which are derived from an encrypted SSH connection. Depending on the data being transmitted, an attacker may be able to recover session identifiers, passwords, and any other data passed between the client and server.

Disable Arcfour ciphers in the SSH configuration. These ciphers are now disabled by default in some OpenSSH installations. All CBC mode ciphers should also be disabled on the target SSH server. In the place of CBC, SSH connections should be created using ciphers that utilize CTR (Counter) mode or GCM (Galois/Counter Mode), which are resistant to the plaintext recovery attack.

Disable SSH Weak MAC Algorithms

The SSH server is configured to allow cipher suites that include weak message authentication code (“MAC”) algorithms. Examples of weak MAC algorithms include MD5 and other known-weak hashes, and/or the use of 96-bit or shorter keys. The SSH protocol uses a MAC to ensure message integrity by hashing the encrypted message, and then sending both the message and the output of the MAC hash function to the recipient. The recipient then generates their hash of the message and related content and compares it to the received hash value. If the values match, there is a reasonable guarantee that the message is received “as is” and has not been tampered with in transit.

If the SSH server is configured to accept weak or otherwise vulnerable MAC algorithms, an attacker may be able to crack them in a reasonable timeframe. This has two potential effects:

The attacker may figure out the shared secret between the client and the server thereby allowing them to read sensitive data being exchanged.
The attacker may be able to tamper with the data in-transit by injecting their own packets or modifying existing packet data sent within the SSH stream.

Disable all 96-bit HMAC algorithms, MD5-based HMAC algorithms, and all CBC mode ciphers configured for SSH on the server. The sshd_config file should only contain the following options as far as supported MAC algorithms are concerned:

hmac-sha2-512
hmac-sha2-512-etm@openssh.com
hmac-sha2-256
hmac-sha2-256-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-128-etm@openssh.com
umac-128-etm@openssh.com
hmac-ripemd160
umac-128@openssh.com
umac-128@openssh.com

In addition, all CBC mode ciphers should be replaced with their CTR mode counterparts.

Testing

To test, run the following command:

nmap -sS -sV -p 22 –script ssh2-enum-algos [TARGET IP]

South Florida Code Camp – Azure IoT Overview

March 2nd 2019, I will be presenting Azure IoT Overview at the South Florida Code Camp in Davie, FL. You can register here – and its FREE. Here is the synopsis of the presentation:

Abstract

Keeping up to date on all the new services and features for an entire cloud portfolio could be a full-time job. In this presentation, we will look at the state of IoT in Microsoft Azure and discuss how the different services work together to implement an enterprise solution. Use this presentation to get an overview of architecture and products so that the next time you are presented with an IoT problem in Azure you know the solution.

Azure IoT Edge – docker.sock connect: permission denied

The Azure IoT Edge getting started guide currently utilizes VS Code and Docker to create modules. If you receive “docker.sock connect: permission denied” after trying to build, run the following two commands in the terminal:

```
sudo usermod -aG docker $USER
```
```
newgrp docker
```

If you still have the error, restart your machine and try again.

Creating an ASP.NET Core application for Raspberry Pi

As a part of the Wren Hyperion solution, an ASP.NET Core application will run on an ARM based Linux OS (we are building a POC for the Raspberry Pi and Raspian). Here are the steps on how you can get started with ASP.NET Core on Raspian:

Setup a Raspberry Pi with Raspian
Install .NET Core
Create your ASP.NET Core solution
Publish to the Raspberry Pi
Install .NET Core to the Raspberry Pi
Run your application on the Raspberry Pi

Setup a Raspberry Pi with Raspian

Follow the guides on the Raspberry Pi website to install Raspian on your Pi.

Install .NET Core

Download and Install

To start building .NET apps you just need to download and install the .NET SDK (Software Development Kit) for Windows.

Download .NET SDK

Video: Creating a Simple .NET Application on Windows
Get an editor

Visual Studio is a fully-featured integrated development environment (IDE) for developing .NET apps on Windows.

Download Visual Studio

Select the .NET Core cross-platform development workload during installation:
More info

While you wait for Visual Studio to install, you can keep learning with the .NET Quick Starts. In the first Quick Start you’ll learn about collections.

Quick start: Collections

Once Visual Studio is installed, come back and build your first .NET app using Visual Studio.

Create your ASP.NET Core Solution

Create a new .NET Core project.

On macOS and Linux, open a terminal window. On Windows, open a command prompt.
```
dotnet new razor -o aspnetcoreapp
```
Run the app.Use the following commands to run the app:
```
cd aspnetcoreapp
dotnet run
```
Browse to http://localhost:5000

Open Pages/About.cshtml and modify the page to display the message “Hello, world! The time on the server is @DateTime.Now “:

@page
@model AboutModel
@{
    ViewData["Title"] = "About";
}
<h2>@ViewData["Title"]</h2>
<h3>@Model.Message</h3>

<p>Hello, world! The time on the server is @DateTime.Now</p>

Browse to http://localhost:5000/About and verify the changes.

Publish to the Raspberry Pi

On macOS and Linux, open a terminal window. On Windows, open a command prompt and run:

dotnet clean .

dotnet restore .

dotnet build .

This will rebuild the solution. Once that is complete run the following command:

dotnet publish . -r linux-arm

This will generate all the files needed for running the solution on the Raspberry Pi. After this command completes generating the needed files, the files need to be deployed to the Pi. Run the following command in Powershell from the publish folder:

& pscp.exe -r .\bin\Debug\netcoreapp2.0\ubuntu.16.04-arm\publish\* ${username}@${ip}:${destination}

Where username is the username for the Pi (default “pi”), ip is the ip address of the Pi, and destination is the folder the files will be published to.

Install .NET Core to the Raspberry Pi

This section is sourced from Dave the Engineer’s post on the Microsoft blog website.

The following commands need to be run on the Raspberry Pi whilst connected over an SSH session or via a terminal in the PIXEL desktop environment.

Run sudo apt-get install curl libunwind8 gettext. This will use the apt-get package manager to install three prerequiste packages.
Run curl -sSL -o dotnet.tar.gz https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/2.0.0/dotnet-runtime-latest-linux-arm.tar.gz to download the latest .NET Core Runtime for ARM32. This is refereed to as armhf on the Daily Builds page.
Run sudo mkdir -p /opt/dotnet && sudo tar zxf dotnet.tar.gz -C /opt/dotnet to create a destination folder and extract the downloaded package into it.
Run sudo ln -s /opt/dotnet/dotnet /usr/local/bin` to set up a symbolic link…a shortcut to you Windows folks 😉 to the dotnet executable.
Test the installation by typing dotnet –help.

Try to create a new .NET Core project by typing dotnet new console. Note this will prompt you to install the .NET Core SDK however this link won’t work for Raspian on ARM32. This is expected behaviour.

Run your application on the Raspberry Pi

Finally to run your application on the Raspberry Pi, navigate to the folder where the application was published and run the following command:

dotnet run
You can then navigate to the website hosted by the Raspberry Pi by navigating to http://{your IP address here}:5000.