HiR Information Report

Self-Hosting a BitWarden-Compatible Password Manager Service

noreply@blogger.com (Ax0n) — Mon, 06 Oct 2025 01:55:00 +0000

When you trust third parties with your password vault, there’s always some risk. Most password manager services use zero-knowledge encryption to keep your passwords safe, but they still have enough information about you to identify you, and there may be useful metadata or billing information stored. Furthermore, if the service is offline for maintenance or under a denial-of-service attack, you may have trouble accessing your passwords. All password manager services cost money if you want all the features. The free plans provide only basic functionality for a single user.

Hosting your own password vault comes with plenty of risks, too. You are solely responsible for patches, maintenance, backups, and providing support to family, co-workers or friends using your solution. I cannot overstate the seriousness and responsibility that comes with managing a service like this for other people, or the consequences of doing it poorly.

BitWarden is open-source, and there are several alternative implementations that work well. For ease of use, I’ll focus on deploying VaultWarden in Docker with an nginx front-end. My production environment is running the rust server directly on OpenBSD with relayd.

You’ll need a DNS domain, access to create DNS entries, and a public-facing server that’s accessible via HTTPS. You might be able to run this at home, but a dedicated server, VPS or cloud server might be more reliable. I’ll be using the latest Debian bookworm for this, but Ubuntu Server, Amazon Linux, etc should work fine with minor adjustments.

You should have a DNS entry for your VaultWarden server. The examples use vault.yourdomain.com and you should adjust that accordingly.

Make sure all the packages are up to date

sudo apt update && sudo apt upgrade -y

Install packages:
sudo apt install -y docker.io nginx docker-compose certbot

Add yourself to the docker group

sudo usermod -aG docker ${USER}
newgrp docker

Create a directory for VaultWarden

mkdir vaultwarden
cd vaultwarden

This will download the latest VaultWarden docker image and then run a command inside a temporary container to generate the strong encrypted hash for the administrator login page.

docker run --rm -it vaultwarden/server /vaultwarden hash

Create a strong password.

Create .env file based on the output of the hash generator. There are many special characters in the hash, and it's easiest to just reference this value as a variable rather than trying to get it into the docker-compose.yml file directly. Note the prefix “VAULTWARDEN_” on this line.

VAULTWARDEN_ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4…'

Create docker-compose.yml:

services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
volumes:
- ./vw-data:/data
- /var/log/vaultwarden:/var/log/vaultwarden
environment:
- DOMAIN=https://vault.yourdomain.com
- SIGNUPS_ALLOWED=true # Set to false after creating accounts
- SHOW_PASSWORD_HINT=false
- ROCKET_PORT=80
- LOG_FILE=/var/log/vaultwarden/vaultwarden.log
- LOG_LEVEL=info
- EXTENDED_LOGGING=true
- IP_HEADER=X-Forwarded-For
- ADMIN_TOKEN=${VAULTWARDEN_ADMIN_TOKEN}
ports:
- "127.0.0.1:8080:80"

We have a chicken-and-egg problem now. nginx will be running after installation, but we can't configure it for TLS without the certificates from LetsEncrypt, and we can't run certbot while nginx is running. Let's stop nginx and run certbot manually. Don't forget to use your correct DNS name and email address for the certbot command.

sudo systemctl stop nginx

sudo certbot certonly --standalone -d vault.yourdomain.com --non-interactive --agree-tos --email you@email.com --redirect

Create the nginx config file /etc/nginx/sites-available/vault
# Redirect HTTP to HTTPS
server {
listen 80;
listen [::]:80;
server_name vault.yourdomain.com;
return 301 https://$server_name$request_uri;
}

# HTTPS Server
server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name vault.yourdomain.com;
ssl_certificate /etc/letsencrypt/live/vault.yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/vault.yourdomain.com/privkey.pem;
# Security headers
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "same-origin" always;

# Proxy to Vaultwarden
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

# WebSocket support for live sync
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
}

# Increase file size for vault exports/imports & sends
client_max_body_size 128M;
}

# WebSocket connection upgrade map
map $http_upgrade $connection_upgrade {
default upgrade;
'' "";
}

Enable this site by creating a symlink to it from sites-enabled:

sudo ln -s /etc/nginx/sites-available/vault /etc/nginx/sites-enabled/vault

Use this fun trick to replace all the host names in your docker-compose and nginx files, if you didn't edit them manually already. Obviously, replace "vault.h-i-r.net" with your own host name.

sudo sed -i 's/vault.yourdomain.com/vault.h-i-r.net/g' /etc/nginx/sites-available/vault ~/vaultwarden/docker-compose.yml

Start Vaultwarden and check the logs:

cd ~/vaultwarden
docker-compose up -d
docker-compose logs

Test the nginx configuration first:
sudo nginx -t

If no errors are found, start nginx:
sudo systemctl start nginx

Browse to your vault URL and create an account. Choose a strong master password. I recommend a passphrase. Resist the urge to use your web browser’s built-in password manager to generate a password, and do not allow the web browser to store this password.

You can import passwords, generate new ones, set up multi-factor authentication, set up shared passwords and more.

Visit the VaultWarden admin panel at your URL /admin

Log in using the password you used to generate the admin token. Here, you can tune configuration options, manage user accounts, disable new user signups, set a new admin token, etc. Generally, the default values are safe and most of the premium paid features are enabled by default.

Install the official BitWarden browser plugins, desktop and mobile apps for your platforms. When you first attempt to login, select the “self-hosted” server and enter the URL for your new VaultWarden server. Sign in with the username and master password you created. Once installed, you can also set up biometric and passkey unlock.

To back up your own personal vault, use web or desktop, and export an encrypted, password-protected json backup. This file is resistant to cracking, and is good enough to keep saved on unencrypted backups, an external drive you keep in a safe place, or even cloud storage, so long as the password is very strong.

Raspberry Pi Home-Lab IDS with Suricata and Wazuh

noreply@blogger.com (Ax0n) — Thu, 18 Sep 2025 04:35:00 +0000

I recently set up Suricata IDS in my home lab again as part of a re-build.
You'll need a RaspberryPi 3, 4 or 5 and an inexpensive smart switch that can mirror traffic from your home lab environment.

I opted for the TP-Link TL-SG105e and TL-SG-108e switches for my home lab, with 5 and 8 1GBPS ports, respectively. I've been using these switches for years and they seem to be popular in the homelab community.

I think the 4GB Raspberry Pi 4 is probably a good balance of affordability and resources. This setup was just a little sluggish on the Pi 3, but it worked fine once it was up and running. On 32-bit platforms like the Raspberry Pi 2, only older versions of Suricata seem to be available.

I would avoid buying Raspberry Pi boards from Amazon, as they're usually overpriced, fulfilled by sketchy resellers, or only sold as part of cost-ineffective bundles by companies that deal primarily in hobby electronics accessories. In North America, Adafruit is probably the most reliable place to buy one online, if you don't have a retail storefront that sells them locally.

Flash the latest RasPiOS bookworm lite image to SD Card. Once it's flashed, set it up for remote SSH access. You can do this 100% headless by preparing the SD card. If you're on Linux or MacOS, you can go open the boot partition of the SD Card and run these commands to auto-provision your account and enable SSH on first boot. Obviously, choose a different username and password than this:

echo myusername:$(echo 'mypassword' | openssl passwd -6 -stdin) > userconf.txt

touch ssh

Next, log in to your smart switch and set up port mirroring. I mirrored only the port for my target lab machine on port 1 to mySuricata Raspberry Pi on port 2. Generally, you should only mirror one single port to the pi, and be careful about mirroring the uplink if there's a lot going on in your lab. Under most conditions, you should be able to use the single Ethernet interface on your Raspberry Pi for both management and IDS sniffing.

Make sure the OS is up to date, then install suricata, tcpdump and jq.

sudo apt update && sudo apt -y upgrade

sudo apt -y install suricata tcpdump jq

We need to edit the configuration slightly. You may want to adjust $HOME_NET to focus only on the "target" part of your home lab, and we definitely need to fix the rule path to align with the rule set we're installing, because the default rules won't catch anything useful.

edit /etc/suricata/suricata.yaml and change

default-rule-path: /etc/suricata/rules
to
default-rule-path: /var/lib/suricata/rules

If you plan on using Suricata to detect attacks that happen entirely within your LAN, you should update home-net to a list of your target systems, for example my home lab target is 192.168.1.135, so HOME_NET = "[192.168.1.135/32]"
However, if you're watching all of your NAT targets for attacks involving the public internet, the default list is fine, and covers all RFC1918 addresses.

If you have a substantially large SD card and feel like you will want the option to deeply examine the raw packet data for identified attacks, enable pcap-log in /etc/suricata/suricata.yaml. The default settings will likely eat up many gigabytes of space. Mine looks more like this.

- pcap-log:
enabled: yes
filename: log.pcap
limit: 1000mb
max-files: 10
compression: none
mode: normal

Add the Emerging-All rule source and run suricata-update to install them.

sudo suricata-update add-source et-all https://rules.emergingthreats.net/open/suricata-6.0/emerging-all.rules.tar.gz

sudo suricata-update -v

I had to stop and start suricata to get the new rules to load. A simple "restart" didn't work for some reason.

sudo systemctl stop suricata
sudo systemctl start suricata

You can use jq to parse the event log looking for alerts

jq '. | select(.event_type=="alert")' /var/log/suricata/eve.json

and it's not too hard to set up the Wazuh agent to send these to your home lab SIEM. Once you have installed wazuh-agent on your Raspberry Pi, you can add various log files to monitor by editing /var/ossec/etc/ossec.conf and adding this block near the end of the file.

<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>

Restart wazuh to pick up the changes.

sudo systemctl restart wazuh-agent

As long as you're getting alert events in eve.json (which you should be able to check with the jq command above), then the events should also start funneling into your Wazuh instance. You will probably want to refresh the wazuh-alerts-* index from the Dashboard Management menu in Wazuh after Suricata alerts start coming in, so that the new fields are searchable.

Build your home-lab SIEM with Wazuh

noreply@blogger.com (Ax0n) — Wed, 17 Sep 2025 03:11:00 +0000

To land that SOC role, you need SIEM experience. How do you get it without the infosec job? Wazuh is an open-source SIEM you can set up in minutes. It has some surprisingly huge production deployments, so it's not just a toy for the home lab. I've been using Wazuh and it's predecessor, OSSec, at home for close to twenty years, but I recently rebuilt my home lab security monitoring stack.

I started with a Debian 13 VM on ProxMox and followed the instructions for a single-node install. Mind the system requirements. 4 cores, 8GB RAM and 50GB of storage are recommended at minimum. You could run it on a laptop or a small home server as well. The version numbers and instructions are subject to change, so I'd recommend following the official procedure, rather than my trying to copy and paste steps here.

I ran into one snag during installation that caused a bunch of errors on the main dashboard and kept some stats from loading. Buried in the GitHub issues for Wazuh, I found a command that I had to run from inside the single-node Docker Compose directory to initialize wazuh-modules:

sudo docker exec single-node-wazuh.manager-1 /var/ossec/bin/wazuh-modulesd

I rebooted my wazuh server but you could probably just restart the containers with docker-compose down; docker-compose up -d

After you start the docker container, wait a few minutes then visit https://<your IP>/ and accept the self-signed certificate. The default credentials are admin:SecretPassword and you should change those ASAP.

The "Endpoints" page has a "Deploy new agent" link that will help you generate a small script to run on your Windows, Mac and Linux machines to install, enable and start the agent. You'll have to run it manually on the endpoint, either on the console or through a remote session (like RDP, VNC, or SSH).

Then you can get attack alerts, watch the logs, check security benchmarks, and start building in-demand cybersecurity skills at home, or just use it for monitoring your fleet of computers.

The main dashboard will show you a summary of all the agents and alerts (or a bunch of errors if you ran into the snag I ran into and haven't run the work-around yet). And the "Discover" app inside Wazuh gives you a robust event log search.

I've found, especially as new logs start coming in from various operating systems, you should refresh the field lists for the wazuh-alerts index. From the main menu on the upper left, select "Dashboards Management" near the bottom of the menu, click "Index Patterns", then "wazuh-alerts-*" and near the upper right, click the refresh icon next to the trash can icon. This will allow you to search on new fields in the Discover app.

In my next post, I'll cover setting up a Suricata IDS on a Raspberry Pi, and integrating Suricata network IDS alerts into Wazuh, too.

Modernizing The HoneyNet: Bringing Community Honey Network Into 2025

noreply@blogger.com (Ax0n) — Tue, 19 Aug 2025 23:08:00 +0000

Eight years ago, I wrote about building a honeypot army with Raspberry Pi, EC2, and Modern Honey Network. Back then, the Modern Honey Network (MHN) project was the gold standard for deploying a large fleet of honeypots, but it was already showing its age as Python 2 deprecation loomed. in 2020, some folks forked the work and got it running on Python 3, but haven't maintained it since. To the surprise of everyone who remembers me introducing the SecKC MHN effort and the stunning WebGL dashboard Wintel and I worked on together, my old MHN server was still running in 2025, dutifully grinding away on Ubuntu 16.04 LTS and Python 2.7.12. For the past 2 years, folks have asked me how to build their own, and I've had to say "First, time-travel back to 2017..."

I'd actually set out to do this work over my vacation a few months ago, but I was not in a good headspace and really just needed to disconnect. I did get familiar with CHN back in May. It ran fine in Docker but it was still dated, and it was going to need some work to integrate with the WebGL Dashboard. In many ways, I felt like some kind of archaeologist, looking at the mostly-abandoned CHN work, the few-and-infrequent MHN updates prior to 2018, and the fossils of purpose-built honeypots, many untouched since before 2015.

What's left of a once-vibrant honeypot ecosystem is a bit of a shame. The original MHN stack had become a museum of dependencies that couldn't be installed on modern systems. Even CHN featured Ubuntu 18.04 base images, archaic PyMongo trying to talk to MongoDB 8.x (spoiler: it can't), and many other outdated Python packages. I also realized that if anything happened to my precious EC2 instance, the entire stack was going to be offline indefinitely. I have backups of everything, but trying to untangle everything to restore a fragile artifact like this wasn't my idea of fun, and I'd probably just let it fade into obscurity. At the same time, I also envisioned getting the whole thing running in Python virtual environments on one of my OpenBSD systems, instead of relying on Docker on a cloud node somewhere. Docker is great, but it should be a deployment consideration, not a hard requirement.

Claude Code -- or -- vibe-technical-debt-repayment

This was the first seriously large project I've used Claude Code to help with. I used it mostly for documentation and test automation. I started by having it unpack how all of the pieces work together and creating a Mermaid syntax diagram (left) and description in Markdown to help better understand the data flow between the honeypots, hpfeeds, mnemosyne, MongoDB, SQLite and the core CHN-Server itself. I also had Claude help me keep track of the project plan, broken up into phases, and when I was getting tired and had to take a break, it could summarize the commit logs, diffs, and create a quick checklist of next-steps that I could come back to the next day to get my head back into the game quicker. When I found a class of problems in the code, Claude highlighted other places the same patterns were found. That wasn't anything I couldn't do in a modern IDE, but it was a nice touch, since I was working in vim the entire time. If you actually try to have Claude write code, it's kind of a mixed bag. Many of its decisions are based on popular and harmful anti-patterns propagated through StackOverflow, Quora and Reddit. You'll have to babysit it and tell it no quite often.

The Modernization Journey

The initial scope seemed straightforward enough: upgrade some dependencies, fix some syntax errors and APIs, clean up a few bugs, get it all running in an OpenBSD VMM instance, then focus on rolling some new Docker containers. What started as a simple refresh turned into a journey through eight years of accumulated technical debt. I started with just the CHN-Server repository, but it had dependencies on the hpfeeds3 repository, and updating that meant messing with the mnemosyne repository. Several projects install my updated hpfeed3 package directly from GitHub in requirements.txt or the Dockerfile. There were layers of compatibility issues forcing me to take a phased, incremental approach to modernization, and a few gotchas that bit me several times, particularly syntax changes around PyMongo. Some bugs weren't obvious until I tried end-to-end testing with real honeypots in the lab. Honestly, I'm sure I missed a few obvious ones, but none that impact basic functionality so far. I threw hundreds of events per hour at the system using an infinite loop of telnet attempts. The system didn't even notice. It's much less resource-intensive.

The front-end needed some work, too. I parameterized the base API URL inside the JavaScript. Rob Scanlon's original work was built with Grunt, and Wintel's middleware used an ancient python2 WebSocket library that is incompatible with anything in modern JavaScript. After a few hours of trying to remove all of the Deprecated bits from the front-end, I decided to revert back to the basics, and gut the WebSocket code from the middleware entirely, and add a REST API to poll the honeypot attacks. I tweaked the Javascript as minimally as possible. I'm really not that comfortable with front-end code.

End to end also revealed a few things that'll need attention soon. The deployment scripts all reference docker containers with architecture tags (-amd64, -arm, etc) that don't exist, for example. Hpfeeds-logger and hpfeeds-cif start up and appear functional, but they need more comprehensive testing than just "the container starts and doesn't immediately crash." I do my own log collection with a custom HPFeeds scraper I wrote in Go last year, replacing the PHP junk I had written back in 2017. I haven't used CIF since 2017 either, and don't really have much need for it. That's future work or maybe even someone else's problem. I'm working on a plan to submit my improvements upstream in a practical way that doesn't require the current maintainers to review massive, monolithic pull requests (if they're even paying attention to PRs). I may end up having to just maintain this fork myself for a while. I'll come up with a more sustainable strategy to keep it up to date if it looks like that's how it will be.

Getting CHN deployed in 2025 is easier than it was in 2017, assuming you can navigate the initial setup. Once I had verified all of the pieces kind of worked on their own, I forked the chn-quickstart project. The guided Docker Compose generator handles most of the complexity, and the whole CHN stack comes up with a simple docker-compose up -d. It's missing the attack-map and custom middleware for the time being, but they're not too hard to deploy next to CHN once it's up and running. I did manage to dockerize the middleware. As of last night, I cut over the DNS records from my old EC2 instance to my new VPS. This thing's actually running in production! nginx handles routing the web requests to the right places, and hosting the static assets of the animated front-end.

The OpenBSD deployment in my lab environment has been rock-solid, with Cowrie honeypots running on Raspberry Pi devices feeding data back to the central server. Watching the attack data flow in real-time through the web interface brings back that same sense of satisfaction I felt eight years ago - except now it's running on modern infrastructure. I need to clean up the OpenBSD init scripts and write some documentation around that part. I don't think it'll be as easy to deploy on bare metal (in Python Virtual Environments with uWSGI) as I'd like.

During the 2020 CHN effort, Duke University's STINGAR team built a bunch of dockerized honeypots that are still functional today, but similarly dated. Modernizing those honeypot projects would be nice. If we concede that the honeypot deployment strategy is just docker images on single board computers, home lab VMs and cloud nodes, it's not really that urgent. Cowrie is actively maintained, and a bare-metal deployment script is on my list of things to build soon.

OpenBSD Power Management

noreply@blogger.com (Ax0n) — Sat, 29 Jun 2024 06:04:00 +0000

OpenBSD's power management features are powerful and plenty. My current setup floats the battery at 80% charged, to reduce battery wear during the work week, and it doesn't suspend when I close the lid as long as it's plugged in. On battery power, it adjusts the CPU speed under load to optimize battery life without sacrificing performance when I need it, and it will automatically suspend at 5% battery to save me from the system powering off unexpectedly. When I plan to head out, I can use a quick alias to allow the battery to charge all the way, which takes about 20 minutes from 80%. We'll go through how I have it set up.

Long-time readers of HiR will not be surprised I'm running OpenBSD as my primary general-purpose operating system on my ThinkPad X1 Carbon. Over on Instagram, people do a double-take. One of the surprises was the fact that in a NeoFetch screenshot, it was noted that my CPU was 400 MHz because I was on battery power without anything heavy running. Power management on OpenBSD also blew some minds.

Out of the box, power management is disabled on OpenBSD. It's one of the few things that do not "just work" by default. The vast majority of OpenBSD systems do not need power management features, but it's a must for laptops.

Understanding apmd

apmd is the Advanced Power Management daemon. If you just set apmd to start with no options, on a well-supported laptop like the 8th Generation Lenovo ThinkPad X1 Carbon I'm using, your laptop will probably suspend when you close the lid or use "zzz" on the command line. And it will wake up when you open the lid or mess with the keyboard. apmd will also enable automatic performance adjustment mode -- clocking down the CPU when there's not much load. That's a pretty good start. There will likely be no warning when your battery is close to dying, and there won't be anything there to stop it from just turning off abruptly when it hits 0%. That's not optimal. Also, when you close the laptop lid and it's plugged in, you might want the system to remain active. You can do that by tweaking machdep.lidaction with sysctl, but there's a much better way.

Looking at the manual page for apmd, we have a lot of useful options.

We can start apmd in high-performance mode (-H) to get the most processing power out of the system, low-performance mode (-L) to extend battery life at the expense of CPU speed, or force automatic performance adjustment mode (-A) which happens to be the default.

The -a option (lowercase) will block incoming BIOS suspend requests, such as those coming from closing the lid, if the system is plugged in. You can still manually suspend through your window manager or the command line zzz utility.

The -z [percent] option will automatically suspend the system if it is not plugged in and the battery is at or below the threshold percentage.

Enable and configure apmd. I assume that you've configured doas. I've covered this on several pages, like my OpenBSD webserver article. I explicitly set automatic performance mode (-A), blocking suspend when plugged in (-a), and set it to automatically suspend at 5% battery (-z 5). Feel free to change this however you please.

doas rcctl enable apmd
doas rcctl set apmd flags -A -a -z 5

The apm command line utility

Simply running the apm utility will provide battery and charge status

apm
Battery state: high, 79% remaining, 153 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: auto (400 MHz)

There are a number of display flags that you can pass to APM to get specific details, for instance, apm -m will display the number of minutes of estimated battery life (or time to achieve a full charge). See the man page for apm for all the details. This is useful if you are making scripts to determine power management status such as for tmux/powerline or custom status bar scripts.

You can also adjust the performance mode on-the-fly, using apm -H, apm -L or apm -A to enable high performance, low-performance or automatic performance modes respectively, without restarting apmd.

sysctl, power management and sensors

This will dump out everything from the hw.sensors tree in sysctl:
sysctl hw.sensors

From here, we can see fan speeds, temperatures, the number of battery charge cycles and even things like the battery's factory design capacity and last fully-charged capacity in Watt-hours.

By dividing last full capacity by the design capacity, you can see how far below the rated capacity your battery has deteriorated, in a way a measure of battery health. For example, my battery's design capacity is 51 Wh, but my last full charge was 39.76 Wh. 39.76 / 51 is about 0.78, so my "full" capacity is about 78% of what it was when new. That's not bad for a 4-year-old laptop on the original battery with about 500 discharge cycles.

Extending battery health with charging optimization

Many devices are now limiting the battery charge to about 80% when the system spends a lot of time plugged in. The MacBook my employer issued to me does this using some kind of magic algorithm that determines if it hasn't been running on battery power much lately. Leaving your battery slightly discharged like this actually extends the life of the battery substantially if you use it while plugged in most of the time.

OpenBSD can do the same thing, to an extent. The maximum charge level can be set with sysctl, so you can place the following line in /etc/sysctl.conf so that it's set immediately when booting up:

hw.battery.chargestop=80

Then, manually set it with sysctl, or reboot:

doas sysctl hw.battery.chargestop=80

If your battery is fully charged, it won't do anything, but the next time you run the battery down below 80% and plug it back in, it will stop charging the battery once it hits 80%. As far as I know, the battery will still charge to 100% if you turn the system off, though.

You can set or adjust the maximum charge level from the command line as well. For instance, if you know you're going to be on the go later today and want to actually charge the battery to 100%, running this command will take care of things:

doas sysctl hw.battery.chargestop=100

There are also additional hw.battery.chargemode options and an hw.battery.chargestart variable, for advanced use cases that I haven't needed. You can reference the hw.battery section of the detailed manual page for the sysctl API to read more about these settings.

Finally, I've been using XFCE lately, and the package "xfce4-battery" does a decent job, allowing me to place a battery widget in any of the XFCE panels. There may be additional widgets or plugins for your GUI of choice.

Running your own Wireguard VPN server and Travel Router

noreply@blogger.com (Ax0n) — Sun, 05 May 2024 04:44:00 +0000

If you travel, or work from the road a lot, you probably have a good reason to set up a travel router and VPN. Travel routers let you create a private network for all of your personal devices. Paired with a VPN, you can obscure the nature of your activity from the local network, and evade IP address or geographical restrictions.

The good use cases for “privacy” focused VPN services are vanishing. Improved encryption and protocols prevent many of the ways a casual attacker can spy on you with wifi. On top of that, many such providers have been caught selling user data to third parties and turning over information to authorities under subpoena, making them possibly worse than any attacker you’re sharing the hotel wifi with.

Running your own cloud VPN is easy and affordable. Once you know how to set it up, you can run it on most hosting providers anywhere in the world, or set it up at home so that you can virtually hop on your home network while you’re out and about. Actually installing Wireguard is the main part that’s different between operating systems.

OpenBSD Server

It's probably no surprise that I run Wireguard on my OpenBSD Servers. OpenBSD has had full kernel support for Wireguard for years, so it's just a matter of installing the userland tools, and setting up the interface.

doas pkg_add wireguard-tools

/etc/hostname.wg0:

inet 10.0.0.1 255.255.255.0 NONE
up
!/usr/local/bin/wg setconf wg0 /etc/wireguard/wg0.conf

Amazon Linux

Amazon Linux is just one easy example I found of a Red Hat-based system. These steps should work similarly on others like Rocky or Alma.

sudo wget -O /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo

sudo yum upgrade

sudo yum clean all

sudo yum install wireguard-tools wireguard-dkms iptables-services

Debian Linux

As the root of many other distributions like Ubuntu and RaspiOS, it made sense to also cover Debian since these instructions will also likely work on many distributions.

sudo apt update

sudo apt install wireguard

Generating Public and Private Keys

Most of the travel routers I've seen don't have a way to generate Wireguard keys on the device if you're manually configuring it. These can be generated on your VPN server and imported. We're changing the umask here to ensure the files are not world or group readable. We're going to be editing files as root, so just use sudo -i (linux) or doas -s (OpenBSD)

sudo -i

umask 077

Create the client keys:

wg genkey | tee client-private.key | wg pubkey > client-public.key

And then server keys:
cd /etc/wireguard
wg genkey | tee private.key | wg pubkey > public.key

Figure out your main network interface:

ip a

In Amazon AWS EC2, the interface was enX0 but it may very well be eth0 or something ridiculous like enp37s8lmaowtf depending on your configuration. You'll need this interface name for your iptables rules.

Using this example skeleton configuration file as a template, paste it into /etc/wireguard/wg0.conf and edit the interface name and fill in the appropriate public and private keys. You can pick any port number you wish. There is no standardized port for Wireguard.

/etc/wireguard/wg0.conf

[Interface]
PrivateKey = [the contents of /etc/wireguard/private.key]
ListenPort = 57609
Address = 10.0.0.1/24
PostUp = iptables -t nat -I POSTROUTING -o [Interface] -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o [Interface] -j MASQUERADE
PreDown = iptables -t nat -D POSTROUTING -o [Interface] -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o [Interface] -j MASQUERADE

[Peer]
PublicKey = [the contents of client-public.key]
AllowedIPs = 10.0.0.2/32

Final Setup and starting the server

OpenBSD

For OpenBSD, you won't need the Address or IPTables entries in wg0.conf above. You'll need to tell PF to NAT traffic for wg0, though. Again, you'll need the primary interface name, which you can find with ifconfig. Place the following lines into /etc/pf.conf AFTER the "pass" and before the block commands at the end of the file and restart pf.

pass in on wg0
pass in inet proto udp from any to any port 51820
pass out on egress inet from (wg0:network) nat-to ([Interface]:0)

doas pfctl -f /etc/pf.conf

Enable IP Forwarding by adding these lines to /etc/sysctl.conf:

net.inet.ip.forwarding=1
net.inet6.ip6.forwarding=1

To start Wireguard, run the following commands, or reboot:

doas sysctl net.inet.ip.forwarding=1

doas net.inet6.ip6.forwarding=1

doas sh /etc/netstart wg0

Linux

For Amazon Linux or Debian, it's also similar. Add these to /etc/sysctl.conf:

net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1

Reload sysctl:

sudo sysctl -p

Enable and start the Wireguard service with systemctl

sudo systemctl enable wg-quick@wg0.service

sudo systemctl start wg-quick@wg0.service

Travel Router Configuration

I've been using GL.iNet routers with Wireguard for about 3 years. The example screenshots are from my GL-SFT1200 "Opal" travel router. Manually configure the Wireguard client and set these values:

Interface

IP Address: 10.0.0.2 (or your "peer" address from the Wireguard server config)

Private key: Contents of client-private.key file we generated earlier

Peer

Public Key: Contents of /etc/wireguard/public.key from the wireguard server

Endpont host: IP address and port of your wireguard server (e.g. 3.45.67.89:57609)

Allowed IPs: 0.0.0.0/0 (or, all IP addresses are allowed through the Wireguard server)

Once you have configured the Wireguard client, you can connect to the VPN. Browse to an IP address checking site like whatismyip.com to verify you're coming from the VPN server's IP address.

Many travel routers have a mode switch on the side that allows you to easily change how the router works. I set up my Opal router so that the mode switch enables or disables Wireguard on the fly so I have more flexibility without worrying about having to log into the admin control panel and change settings.

November 2023 SecKC Presentation: Mobile SDR

noreply@blogger.com (Ax0n) — Wed, 15 Nov 2023 03:09:00 +0000

Thanks to all who showed up and asked questions!

Introducing NEMO for the M5Stick C Plus

noreply@blogger.com (Ax0n) — Sun, 01 Oct 2023 07:40:00 +0000

I've been working on this project for a couple of weeks, and it's pretty close to finished. I've been trying to build some more skills in the embedded systems, microcontroller and Internet of Things realm, and when I decided it was time to expand my experience to ESP32, I wanted a dev kit with a little bit of everything built in. I already have breadboards, displays, servos, sensors, LEDs and accessories galore. I just wanted something cute that'd keep my interest for a while. Enter the M5Stack M5Stick C Plus. Powered by an ESP32, featuring an AXP192 power management unit, accelerometer, IR and red LEDs, a 100mAh battery, microphone, speaker, display, a few buttons and plenty of exposed GPIO pins, it seemed like a good place to start.

My usual method of learning involves sketching out a rough plan for demonstrating mastery of core concepts, so my first few projects were about getting the ESP-IDF and arduino environments working with simple programs. I also ported CircuitPython to it for some of my early projects. I focused on the WiFi stack and designing user interfaces at first, then using UART, SPI and I2C via the GPIO pins.

With most of the tech community excited about the Flipper Zero, I started thinking about what sorts of high-tech pranks one could get away with on a platform like this. The end result is NEMO, named after the titular character in Finding Nemo, in contrast to some other high-tech toy named after a fictional dolphin.

The Stick C Plus has no IR sensor, but it does have a transmitter. Infrared replay attacks might work if you plugged an IR receiver into the GPIO, but I'm not worried about that. I settled for an implementation of TV-B-Gone, relying on previous work by Ken Shirriff and a local hacker, MrARM. I had previously messed with similar projects in both CircuitPython, and at the source-code level, way back in 2008 with the DefCon 16 badge, which also featured an infrared TV killer mode.

Right about the time I was starting to work on this, DefCon 31 was wrapping up, and a ton of folks were commenting on the bizarre behavior of their iOS devices at the conference, seemingly always displaying pop-ups trying to connect AirPods or other accessories. This became known as the "AppleJuice" attack, and relies on bluetooth low energy beacon advertisements, and iOS's user experience that tries to make device pairing easier. I found a very bare-bones implementation for ESP32, that was somewhat broken. I fixed it and gave it a decent two-button user interface as well.

I rounded out the pranks with WiFi Spamming, using a list of funny WiFi SSIDs, the now-popular "RickRoll" SSIDs and a mode that spams hundreds of randomly-named SSIDs per minute.

It defaults to a "watch" mode with a 24-hour clock backed by the on-board real-time-clock. There's a few kilobytes of non-volatile EEPROM storage on board, of which I'm using a few bytes to keep settings like left/right hand rotation, brightness, auto-dimming timer and TV-B-Gone region settings persistent through deep sleep or power off mode. All in all, it's a few existing projects just kind of glued together in a novel way that's easy to use. Those who've known me for a while would say that's on-brand.

A few people have asked me if it's for sale. I have no plans to sell anything, such as M5Stick units pre-flashed with NEMO. This is open-source software I put together for fun, and anyone can use it and extend it. You can buy the device and learn how to load my code on it, but I'd be more excites to hear about people being inspired to build their own cool projects on it.

At $20-$30 depending on the site and accessories you get with the M5Stick C Plus, it has a lot of capabilities. Here's an Amazon Affiliate Link to buy a version with a watch strap, lego mounting and wall-mounting options. The project source code and pre-compiled binaries are up on the m5stick-NEMO GitHub repository, and I am keeping the project up to date in the M5Burner app. You can see a quick walk-through reel on my Instagram as well.

Running a Kubernetes Cluster with OpenBSD VMM

noreply@blogger.com (Ax0n) — Sat, 25 Feb 2023 23:18:00 +0000

Kubernetes relies on Linux containers and cgroups, so you can't run Kubernetes or even docker containers directly on OpenBSD, but Alpine Linux runs great under OpenBSD's VMM hypervisor. Alpine shares a lot of the same ideologies as OpenBSD, and it has become a favorite in the Linux container ecosystem.

What's the point?

Kubernetes is a system for deploying containerized applications at scale, in a clustered environment. This lets developers create microservices that run in a mesh configuration, or large, monolithic apps that run in Docker. These docker containers can then be deployed to a kubernetes cluster for testing and production use. In the modern enterprise world, it's becoming far less common to build and provision web servers and run apps on them. More often than not, the infrastructure is virtual, software-defined, and deployed in containers.

It would be far faster and efficient to follow my OpenBSD HTTPD guide and then install Wordpress directly, so this is less about getting wordpress running on OpenBSD than it is about getting one's feet wet in clustered workloads and applying modern DevOps principles in an OpenBSD-centric home lab. Once this is up and running, you can use kubectl, kustomize, or helm to deploy all kinds of things to the cluster with relative ease. I'm gonna try OWASP Juice Shop next.

Caveat Emptor

This is not a good project for someone who’s never used OpenBSD before. I make some assumptions that you’re generally familiar with OpenBSD and performing routine system administration and housekeeping tasks.

This is not a supported configuration. I’ve been running kubernetes on OpenBSD’s VMM hypervisor in my home lab for about 7 months as of the time of writing. I wanted to play with Kubernetes at home, and at the time, my Dell PowerEdge R410 running OpenBSD was the only thing I had available, so I decided to try this out. Occasionally, the network or nodes lag a little, but it’s been pretty stable for the most part.

There are a few limitations to this setup. VMM currently has no way to allocate more than one CPU core to a VM. This causes two problems for Kubernetes:

First is that Kubernetes’ master node minimum requirement is for 2 cores. We can override it, and it seems to run with just one core, but it’s not optimal.

Second is that some workloads may request more than 1 CPU worth of computing resources for a pod. The master node will be unable to find a node that can support that pod, because these worker nodes will only have one core, or 1000 milli-cores, of CPU capacity each. If you see errors like “Unschedulable” and “Insufficient cpu,” this is one potential reason.

VMM Vs. The World

I’ve been running production websites on OpenBSD VMM guests for years without any problems, but I won’t pretend that VMM’s relative immaturity isn’t a deal-breaker for clustered workloads like this. This project was my way of better understanding how kubernetes works under the hood, and an excuse to play UNIX nerd.

Since late last year, I have also been running a similar K8S cluster based on Alpine Linux VMs, but hosting it on slightly better hardware running the ProxMox VE hypervisor. I’m still using the NFS server on my R410, though. ProxMox allows me to allocate 4 cores to each node, so I can run heavier applications. This setup is production-ready and I could justify operating a business on a ProxMox-based cluster like this if I were on a tight budget.

There are commercial solutions that take a lot of the work out of on-premise kubernetes, and affordable options for managed cluster workloads (in the clouds or whatever). Do what makes sense.

Conventions

Commands you should run are in green

File contents are in blue

OpenBSD Host Considerations

Minimum System Requirements

8GB RAM
4-core CPU that has VMM/EPT support (most i5 or i7 CPU should work)
50GB of storage

For this example, we’ll run 3 Alpine Linux VMs – one master node and two worker nodes. Each node will get 2GB of RAM and be set up for 10GB of storage, but qcow2 images only allocate storage when it’s used.

Installing OpenBSD

I make some assumptions about your OpenBSD environment:

A default OpenBSD install with all installsets
/etc/doas.conf is configured so you can use it from a user account you created during the installation. The below is a minimalist doas.conf:

permit persist :wheel

Enough storage for 3 Alpine Linux virtual machines.

I use a 100GB filesystem mounted at /vmm for this
The QCOW2 files in my example lab as of the time of writing are only using about 7GB of storage

Enough storage for the NFS server to support persistent storage for some applications.

I use a 100GB filesystem mounted at /k8s
A full WordPress/MySQL install in k8s is using less than 1GB

You can change these example directories around as you need to, but you’ll see these paths in the documentation.

Networking the OpenBSD host and the VMM Guests

We are going to bridge our guest VMs to the LAN. This is easier if you have multiple ethernet interfaces on your OpenBSD host, but we can work around it if you only have one.

Two ethernet interfaces

On a system with more than one ethernet interface, use a secondary interface to bridge the VMs to the network. In this example, I allowed the installer to configure the ethernet interface bnx0 with dhcp but I also connected the second ethernet interface bnx1 to the network. Set the second interface to come up with no IP address needed.

/etc/hostname.bnx1

doas sh /etc/netstart bnx1

–or – Single ethernet interface

If we use a DHCP client on the OpenBSD host, it will intercept all DHCP traffic on the interface and keep the guest VMs from obtaining DHCP leases.

Set up a DHCP reservation for the MAC address of your OpenBSD host. This is only so your router doesn’t issue your IP address to some other system. Configure the OpenBSD host to use the reserved IP address in a static configuration.

An example where my ethernet interface is em0. Static address of this interface is 192.168.1.2. I have marked this IP address as reserved on my home router.

/etc/hostname.em0

inet 192.168.1.2 255.255.255.0

! route add default 192.168.1.254

Your static IP details will likely differ from the above. Set appropriately. You may also need to manually configure /etc/resolv.conf

VM Bridge

Add the interface that you’ll be using to bridge0 as in the example below. For my lab machine, I have two interfaces and I’m using bnx1 to bridge my VMs.

/etc/hostname.bridge0

add bnx1

Make sure you bring up the bridge interface

doas sh /etc/netstart bridge0

Set up NFS

Kubernetes requires some kind of network-attached storage that all of the containers can access regardless of which worker node they get allocated to. NFS is a popular option, and we’ll eventually install an automated NFS Client storage provisioner on the cluster. We might as well run this on the VMM server itself, since OpenBSD comes with an NFS server in the base install.

Export the /k8s filesystem (with enough storage, as mentioned above) via /etc/exports. You must ensure the network and netmask are appropriate for your LAN.

/etc/exports

/k8s -alldirs -network=192.168.1 -mask=255.255.255.0 -mapall=root

Each Persistent Volume will invoke a new NFS thread, so we’ll max it out with 20 server threads for NFS and enable both TCP and UDP modes. mountd, portmap, statd and lockd are all part of the RPC and NFS system. Let’s enable them and start the services.

doas rcctl enable mountd

doas rcctl enable statd

doas rcctl enable lockd

doas rcctl enable portmap

doas rcctl enable nfsd

doas rcctl set nfsd flags -t -u -n 20

doas rcctl start mountd statd lockd portmap nfsd

Create Template VM

Directory setup

As mentioned above, this should have plenty of space, at least 30GB. We make it group writable so our user level account (which should be in the wheel group) can use it easily.

doas mkdir /vmm

doas chmod 770 /vmm

cd /vmm

Configure VMD’s virtual switch

Create A very bare-bones vm.conf to set up our bridge network. We’ll add to this later.

/etc/vm.conf

switch "bridged" {

interface bridge0

}

Enable and start vmd

doas rcctl enable vmd

doas rcctl start vmd

Download alpine-virt ISO image

ftp https://dl-cdn.alpinelinux.org/alpine/v3.17/releases/x86_64/alpine-virt-3.17.2-x86_64.iso

Create template VM disk image

vmctl create -s 10G alpine-template.qcow2

Boot the template vm

This will start the VM, boot from the iso, and attach your template VM disk image.

doas vmctl start -c -d alpine-virt-3.17.2-x86_64.iso \

-d alpine-template.qcow2 -m 2G -n bridged alpine-template

Install Alpine Linux

Kubernetes works best when there’s no swap, so we’ll disable it with a variable we pass to setup-alpine. Mostly, just follow the prompts.

Log in as root and run the below command
SWAP_SIZE=0 setup-alpine
Specify a hostname (I usually use ‘kube’ but we’ll change it later)
Configure network (DHCP is fine)
Busybox for cron
Create a user-level account
Use Openssh server
Use the vdb disk as “sys” volume
halt

After a while, hit enter. vmctl will exit back to the OpenBSD shell with an [EOT].

Reboot into the template VM

Same command as above but without the installer ISO attached

doas vmctl start -c \

-d alpine-template.qcow2 -m 2G -n bridged alpine-template

Set up the basic software

su -

Edit /etc/apk/repositories. The default Alpine Linux install only includes vi. If you must, you can use “apk add nano” first.

We only want these 3 repos enabled. You can leave the # in front of the others in the file.

/etc/apk/repositories

http://dl-cdn.alpinelinux.org/alpine/v3.17/main

http://dl-cdn.alpinelinux.org/alpine/v3.17/community

http://dl-cdn.alpinelinux.org/alpine/edge/testing

Update the package index and install some software we need:

apk update

apk add doas kubernetes kubeadm docker cni-plugins kubelet kubectl nfs-utils cni-plugin-flannel flannel flannel-contrib-cni docker uuidgen git

We’ll use doas from this point forward. The default configuration of doas should be fine for our purposes (allows wheel-group users to do anything, caches the password for the session). Exit your root shell.

exit

Test doas – this will also cache the password so the rest of the commands run all at once if you just paste them in.

doas id

Paste the below into your terminal if you want. Or type it. I’m not the boss of you.

doas rm /etc/ssh/*key*

printf "#!/bin/sh\nmount --make-rshared /\n" |\

doas tee /etc/local.d/sharemetrics

doas chmod +x /etc/local.d/sharemetrics

doas rc-update add local

doas rc-update add docker default

doas rc-update add containerd default

doas rc-update add kubelet default

doas rc-update add rpc.statd default

doas rc-update add ntpd default

echo "net.bridge.bridge-nf-call-iptables=1" | doas tee -a /etc/sysctl.conf

doas apk add 'kubelet=~1.26'

doas apk add 'kubeadm=~1.26'

doas apk add 'kubectl=~1.26'

The last 3 commands ensure we don’t let Kubernetes components get upgraded past the minor version we specify. Replace 1.26 with the current minor version (1.22.3-r1 would be 1.22). As of writing, 1.26 is the latest. This keeps the cluster nodes from inadvertently updating to a higher version with incompatibilities.

Shut down the system. This has most of what we need for all the kubernetes nodes.

doas halt

Once vmctl exits and you are back at the OpenBSD shell, make this template disk image read-only. This will be our base image for the 3 Alpine Linux VMs, and if something changes in this file, it’ll break the derivative images.

doas chmod 400 alpine-template.qcow2

Clone Template VM

Create the derivative images for the master node and two workers.

doas vmctl create -b alpine-template.qcow2 kube-master.qcow2

doas vmctl create -b alpine-template.qcow2 kube-w1.qcow2

doas vmctl create -b alpine-template.qcow2 kube-w2.qcow2

Add them to /etc/vm.conf. We specify MAC addresses inside the interface clause because if we don’t, they will get a different random MAC address (and probably IP address) at runtime. My /etc/vm.conf now looks like this:

/etc/vm.conf

switch "bridged" {

interface bridge0

}

vm "kube-master" {

disable

memory 2048M

disk "/vmm/kube-master.qcow2"

interface {

switch "bridged"

lladdr fe:e1:ba:d9:fb:c0

}

vm "kube-w1" {

disable

memory 2048M

disk "/vmm/kube-w1.qcow2"

interface {

switch "bridged"

lladdr fe:e1:ba:d9:fb:c1

}

vm "kube-w2" {

disable

memory 2048M

disk "/vmm/kube-w2.qcow2"

interface {

switch "bridged"

lladdr fe:e1:ba:d9:fb:c2

}

Before we continue, it’s a good idea to set up a DHCP reservation for the MAC address you use for the master node. If the master node IP changes, the workers can’t find it, and fixing the cluster is not a very straightforward task. This isn’t too important if you’re just playing around with kubernetes for fun, though.

If you have more than 8GB of RAM, I’d allocate about 25% of your RAM to each VM. 16GB of RAM? 4096M per node. 32GB of RAM? Give each node 8192M.

If you have a system with more than 4 cores, and more than 32GB of RAM, consider adding more worker nodes and tuning the RAM on them. 2GB per node is an absolute minimum and will lag a lot.

Reload the configuration and start up the master node with a console

doas vmctl reload

doas vmctl start -c kube-master

Bootstrap the master node

Set the host name and machine-id

These are important for the k8s networking components.

echo "master" | doas tee /etc/hostname

doas hostname -F /etc/hostname

uuidgen | doas tee /etc/machine-id

Install k8s management tools

doas apk add k9s helm curl

Initialize Kubernetes

Here, we have to work-around the requirement for two CPU cores.

doas kubeadm init --ignore-preflight-errors=NumCPU \

--pod-network-cidr=10.244.0.0/16 --node-name=master

This could take some time to pull images and generate crypto keys. It will eventually spit out a bunch of stuff including the below (slightly modded).

Execute these with your user-level account on master.

mkdir -p $HOME/.kube

doas cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

doas chown $(id -u):$(id -g) $HOME/.kube/config

The initialization will also show the command to join nodes to the cluster...

kubeadm join 192.168.1.xxx:6443 --token foobar.foobarfoobarfoob \

--discovery-token-ca-cert-hash sha256: \

d34db3efd34db3efd34db3efd34db3efd34db3efd34db3efd34db3efd34db3ef

Save this kubeadm join command. You'll need it for all your workers. I create a file on master and save it just so it’s easy to find.

Install Flannel CNI plugin.

This is technically the first package you manually deploy to your cluster. It creates a daemonset of containers (pods) that will self-replicate across all nodes as they join the cluster.

kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

Worker Nodes

Boot up the first worker node. On your OpenBSD VMM host, run:

doas vmctl start -c kube-w1

Set the host name and machine-id

Similar to how we set up the master node, we need each worker to have a unique name and machine-id

echo "kube-w1" | doas tee /etc/hostname

doas hostname -F /etc/hostname

uuidgen | doas tee /etc/machine-id

Run the command to join the cluster as provided when initializing the master node. Don’t forget to use doas.

doas kubeadm join 192.168.1.xxx:6443 --token foobar.foobarfoobarfoob \

--discovery-token-ca-cert-hash sha256: \

d34db3efd34db3efd34db3efd34db3efd34db3efd34db3efd34db3efd34db3ef

Kubernetes tokens are only valid for 24 hours. If you want to join a new worker to the cluster, you can generate and print a new join token at any time. You must execute this on the MASTER node, then run the output of this command on your new worker node.

kubeadm token create --print-join-command

That’s it. Log off. You're done with this worker node.

You can hit enter and then use the “tilde period” escape sequence ~. to break out of the vmctl console while the VM remains running. If connected to your VM server over SSH, note that ~. is also the sequence to terminate your SSH session, so use ~~. instead.

Rinse, Repeat

Repeat the above process for kube-w2 (make sure you change the hostname in the commands above) before you continue. You can repeat this process to make as many worker nodes as you have the resources for. You’ll need to make new drive images and VMs in /etc/vm.conf to support them.

Behold, your Kubernetes cluster

Basic kubectl commands

kubectl get nodes

kubectl get pods --all-namespaces

You should see stuff running.

K9S Navigation

K9S is a curses-based Kubernetes UI. Just run “k9s”

If k9s exits with an error message, it may be due to your termcap being unsupported. Try the below command, then run k9s again. If that works, consider adding this to the .profile file so it runs every time you log in.

export TERM=xterm-256color

":" will let you jump to the various pages. Some pages worth knowing:

node - all connected nodes
deploy - deployments, which configure pods and replicaSets
daemonset - daemonsets - groups of pods that should run on many nodes
statefulset - Stateful applications
pods - Individual containers
namespace - namespaces in the cluster

On each page, note the hotkey menu at the top. You can also use "/" to search the current content of the given page. You can on-the-fly edit a manifest of a deployment, for example, or delete a pod to evict it (usually results in a restart which may or may not be on the same node) - Also pay attention to the number hotkeys which let you filter by namespace. Often, you'll want 0 for ALL namespaces

Troubleshooting with K9S

Cursor over an asset (like a pod, daemonset, deployment) and use “d” to describe the asset. You can usually see information about what’s going on. This is useful for figuring out why a pod is in a CrashLoopBackoff state.

Use “l” (lowercase L) to fetch logs. You may need to use the hotkeys to view head or tail the logs, adjust line wrapping, etc.

Use “e” to edit a manifest on-the-fly. You can often “hack” quick fixes in if something is typoed or you want to scale up a deployment manually.

Use “s” on a pod to try to get a shell on the container. Some containers do not support shells. Containers that are crashing will not remain up long enough to do anything meaningful in a shell.

Provision NFS Storage

SSH back into your MASTER node.

When an application requires storage, it makes a “Persistent Volume Claim.” These will lurk around forever and stop the application from deploying until a persistent volume is created that meets the criteria for the claim. In a managed cluster, this happens automatically, so we’re going to deploy our own magic process to create these volumes on the fly, using storage we provide via NFS.

For this, we will use nfs-subdir-external-provisioner, and set up Kustomize to tweak it for our environment. Kustomize can modify and patch stock manifests so you don’t have to edit them directly – and as you’ll see here, sometimes you don’t even need to download them, you can just reference the repository.

Make a directory

Generally speaking, we work in a directory for a given task. We’ll make a new directory for our storage provisioning.

mkdir storage; cd storage

Create configuration files

Create the below files inside the storage directory with the contents as shown. YAML is extremely picky and your browser might not copy/paste these correctly. You can snag all of the YAML files I use in this example from my github: n0xa/k8s-playground

namespace.yaml

apiVersion: v1

kind: Namespace

metadata:

Be sure to modify the highlighted values in the patch file to match your NFS server’s details.

patch_nfs_details.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
    app: nfs-client-provisioner
name: nfs-client-provisioner
spec:
template:
    spec:
      containers:
        - name: nfs-client-provisioner
          env:
            - name: NFS_SERVER
              value: 192.168.1.122
            - name: NFS_PATH
              value: /k8s
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.1.122
            path: /k8s

kustomization.yaml

namespace: nfs-provisioner

bases:

- github.com/kubernetes-sigs/nfs-subdir-external-provisioner//deploy

resources:

- namespace.yaml

patchesStrategicMerge:

- patch_nfs_details.yaml

Deploy with Kubectl

This will use the kustomization.yaml to patch the manifest files, and apply the resulting assets to your cluster.

kubectl apply -k ./

Deploy MetalLB Load Balancer

Now we need to build a load balancer to expose the service to an external set of IP addresses. We will use MetalLB for this. We are going to arbitrarily use some LAN IP addresses here. In my home lab, the range 192.168.1.1 through 192.168.1.63 is out of the normal DHCP scope. You may wish to set aside a range of addresses that aren’t managed by DHCP at all.

Make a directory

mkdir ~/metallb; cd ~/metallb

Install MetalLB with kubectl

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml

Configure Load Balancer IP Addresses

Create a configuration yaml for the IP addresses you’re reserving for the load balancer. You can specify IP address ranges, CIDR blocks or single IPs if you want. You can add as many lines as you wish. You can see I defined two IP address ranges, one named “production” and the other (which is technically one IP address) named “wordpress”

address.yaml

apiVersion: metallb.io/v1beta1

kind: IPAddressPool

metadata:

namespace: metallb-system

spec:

addresses:

- 192.168.1.16-192.168.1.24

---

apiVersion: metallb.io/v1beta1

kind: IPAddressPool

metadata:

namespace: metallb-system

spec:

addresses:

- 192.168.1.14/32

---

apiVersion: metallb.io/v1beta1

kind: L2Advertisement

metadata:

namespace: metallb-system

Apply the configuration

Note that the API extensions this manifest references won’t be available until after the MetalLB resources are all up and running.

kubectl apply -f address.yaml

By default, any new service that gets deployed will get an IP address from the “production” pool. If we add the proper annotations to any new service that gets deployed, we can force it to use the wordpress IP address we specified.

Deploy WordPress

Let’s deploy a simple Wordpress blog using helm.

Add the Bitnami Helm Repository

helm repo add bitnami https://charts.bitnami.com/bitnami

Configure Wordpress

Here, I’ve put together a YAML file with just enough details to get it up and running. We’ll give it a title, a username, and details about our storage and load balancer service annotations. You should change any of these details as you need.

wp-values.yaml

wordpressUsername: myuser

wordpressEmail: ax0n@example.com

wordpressFirstName: Noah

wordpressLastName: Axon

wordpressBlogName: "Ax0n's Blog"

global:

storageClass: "nfs-client"

service:

annotations:

metallb.universe.tf/address-pool: wordpress

Install Wordpress with Helm

We’ll make a new “wordpress” namespace in k8s for this installation.

helm install wordpress -f wp-values.yaml --create-namespace wordpress \

--namespace wordpress bitnami/wordpress

This will spit out a whole bunch of text explaining how to find the randomly-generated password, the service IP address and more. Of course, we know it should pick up the IP address we defined for Wordpress in the MetalLB configuration. Grab the password via the commands provided.

Helm will create a whole bunch of resources, including a statefulset for MariaDB, a deployment for the Wordpress webserver, volumes for the database and wordpress web application itself, a secret to hold the generated password, and a number of other resources. This can take several minutes to complete. Feel free to open k9s again and watch the logs as MariaDB initializes, Wordpress waits to connect, and the entire provisioning process unfolds.

Once it’s complete, browse to the IP address you set up for Wordpress.

Use the admin URL and log in.

I did run into a well-documented issue with the installation, in that the health checks (readiness and liveness probes) caused the Wordpress container to restart before it was finished setting everything up. I had to manually create a “themes” directory inside my NFS server under the directory provisioned for wordpress and then manually download and set a theme inside the admin page. This seems to happen on lower-performance clusters. sometimes.

Dedicated page for Multi-Booting Windows 10 and OpenBSD

noreply@blogger.com (Ax0n) — Thu, 27 May 2021 22:48:00 +0000

I've created a dedicated page with my guide for Multi-Booting Windows 10 and OpenBSD. This supersedes the earlier blog post on this topic. I've been running this setup for a few months now and I seem to have ironed out most of the gotchas, including how to, as elegantly as practicable, deal with Windows' BitLocker shenanigans as well as its tendency to override the rEFInd boot manager.

OpenBSD 6.9 Released, PHP/MySQL Page updated

noreply@blogger.com (Ax0n) — Sun, 02 May 2021 03:37:00 +0000

The 50th release of OpenBSD hit the mirrors last night, but I had some problems installing packages -- they were out of sync a bit. Anyhow, today, all of the package repositories on all the mirrors seem to be working swimmingly (you see what I did there?) and getting OpenBSD's built-in HTTPD working with PHP 8.0.3 and MariaDB (a MySQL Fork) 10.5.9 is a breeze. I've updated the OpenBSD HTTPD/PHP/MySQL page accordingly.

I'm most excited about a number of fixes in the VMM hypervisor that mean it can once again run some of my Linux virtual machines that have newer kernels. That had been broken for quite a while. There are also some changes to video and audio subsystems that I feel like might have been driven by some of my input on the mailing lists. The world may never know.

In news that's related only by virtue of OpenBSD tinkering, I also managed to get OBS Studio working on OpenBSD-CURRENT, which just required me to figure out how to get the excellent openbsd-wip ports tree working alongside the official OpenBSD Ports. I'm still figuring out how to tune OBS to get high-quality live streams working, and at present, directly attaching the webcam to OBS results in a Kernel Panic. So there are some bugs to iron out.

Review: OpenBSD 6.8 on 8th Gen Lenovo ThinkPad X1 Carbon 13.3"

noreply@blogger.com (Ax0n) — Wed, 24 Mar 2021 03:06:00 +0000

10 days ago, I bought this X1 Carbon. I immediately installed OpenBSD on it. It took me a few days to settle in and make myself at home, but here are my impressions.

This was the smoothest experience I've had getting OpenBSD set up the way I like it. The Toshiba NB305 in 2011 was a close second, but the Acer I used between these two laptops required a lot more tweaking of both hardware and kernel to get it to feel like home.

The bad news

Let's start with what doesn't work flawlessly on the ThinkPad under OpenBSD-STABLE (6.8 with all patches to date applied), roughly in the order I noticed them. At the moment, the issues with the TrackPad and browser webcam are the only outstanding annoyances. Everything else was easily addressed with basic configuration adjustments.

The resolution is just too high.

First world problems. While I admire cramming a full-blown 4K UHD into this diminutive portable workstation, at 3840x2160 on a 13-inch-class display, everything was too small to read. Windows and MacOS both handle the ever-growing number of pixels on a display by having a "scale" item in the display properties. While display managers designed for BSD and Linux, such as XFCE or GNOME, do have the ability to scale items, these scale settings don't work globally across all applications in a predictable way.

The high-DPI display was most problematic during installation, wherein the kernel modesetting used the native screen resolution for the text-mode installer, with each line of text being barely a millimeter tall. I literally wore a headset magnifier to install OpenBSD on this thing. After install, the console was a reasonable size. I don't know why the installer used such a high resolution, but suppose it could be related to firmware for the on-board graphics adapter that's not present in the install media but is present after a full install and fw_update.

Upon logging in to X and opening a terminal window, I had to bump up the font size just to see what's going on. I opted to just decrease the resolution of my display to solve this problem. Using xrandr to experiment with different 16x9 resolutions, I settled on 2048x1152, though plain old 1080p is also quite pleasant. I added this lovely gem to my .xinitrc file before calling the desktop environment:

xrandr --output eDP-1 --mode 2048x1152

The touchpad occasionally goes non-responsive.

I think this may be hardware-level wrist-detection stuff at work, but backing completely off the computer and trying to use the touchpad doesn't fix it. I often have to use two or three fingers at a time and repeatedly tap the touchpad to get it to come back. Thinking about it now, I should probably see if it works after I just leave it alone for a few seconds. In the meantime, I disabled the trackpad in the BIOS and I'm trying my very best to embrace the TrackPoint "Eraser Head" pointer. If you know what's going on with the touchpad, let me know.

The TrackPoint doesn't scroll by default under X.

On Windows, you can scroll by holding the center TrackPoint button while moving the TrackPoint head. This didn't work by default -- center button is "paste" by default under X. I was able to make some more additions to the beginning of my .xinitrc file to get it right, where clicking the center button pastes the clipboard contents, and holding it allows you to scroll with the TrackPoint:

xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation" 1
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Button" 2
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Axes" 6 7 4 5

Audio quality with the default settings

The audio sounded a little tinny and not all that loud when I first played audio over them. Part of the backstory of my admiration of the ThinkPad X1 line is that I pay attention to OpenBSD developers and what they say about hardware. ThinkPads get a lot of praise from the developers I follow, and in one of jcs@'s recent-ish blog posts about the previous generation of X1 Carbon, there was some concern about the audio output. I noticed that while sound was coming out of the "bass" speakers on the bottom of the wrist rest and the "treble" speakers on top near the screen hinges, the tone of the sound coming out of all of the speakers seemed amiss -- and muting the small speakers made it sound better. It turned out to be the same problem as jcs@ noted on the 7th gen X1 Carbon, and adding this line to /etc/mixerctl.conf fixed it, while providing crystal-clear sound through all 4 speakers:

outputs.spkr2_source=dac-0:1

When this laptop's audio is firing on all cylinders, it sounds positively amazing given its size. I've had big old chunky gaming laptops with big old woofers inside them that didn't sound this good. What it has in audio quality, it lacks, just a little, in maximum volume, but it's more than loud enough to fill my workspace with sound, whether I'm in the back of my camper-van or hacking away in my home office.

Webcam support in the browser

YouTube, Discord and some other sites will TRY to use the webcam and microphone - and take note of the kern.audio.record (and upcoming kern.video.record) sysctl options. On Discord's web app, I briefly see my webcam video as the webcam activity LED illuminates, then the LED turns off and Discord returns an error. On YouTube, I never see my own video, but the webcam activity LED blinks briefly. Video capture tools such as ffmpeg and vlc work quite well with the webcam. Given that, I believe there's probably a simple fix to make it work flawlessly, I just haven't found it yet. I'm looking forward to a time, hopefully soon, when I can use an official package or port of OBS Studio, maybe even with working virtual camera support.

The fingerprint reader isn't supported

jcs@ also noted the same of the 7th generation X1 as of 2019. It doesn't bother me in the least. Maybe it'd be neat to log in to OpenBSD with a fingerprint, but I've been using OpenBSD for 21 years without it, so I don't miss the functionality and it's only barely worth mentioning.

No Bluetooth

Bluetooth has been unsupported by OpenBSD for many years. I don't miss it, but if you decide to try OpenBSD, you might notice that there is no Bluetooth stack.

The good news

What works? Basically everything else.

The function keys for volume, mute, brightness, and keyboard backlight worked without any hassle
The built-in ethernet port (which requires a dongle to use) has full support in the kernel via em(4) without requiring a firmware blob.
After loading firmware, the on-board Intel WiFi6 adapter is fast and functional via iwx(4).
Sleep/suspend/wake works well via zzz(1) or simply closing the laptop lid. Similarly, using sysctl to disable sleep when the laptop is closed works and it will stay running while closed.
WebGL applications, such as some of my favorite online games, work fine now. About a year ago, none of them worked. It could just be that my old laptop didn't have enough resources for these web applications.
YouTube, Social media applications, Google Drive, etc... all good.
Even the USB microscope that I use for small electronics work and examining small mechanical parts such as those found in locks and analog watches works great with VLC once I'd created /dev/video2 and set up device permissions.

Battery life seems good. I have been using this laptop for about 3 and a half hours before and during the writing of this review, with moderate screen brightness, several "hungry" tabs open in Firefox and with pianobar (a CLI Pandora client) blasting my "Orbital" inspired playlist. I have two OpenBSD virtual machines running in vmm, though I'm not currently doing anything intense with them. I've been on battery the whole time and I've got 43% battery remaining, with an estimated run time of about 2.5 hours remaining. I can deal with 6 hours of untethered run-time under my usual working conditions.

The system temperature has hovered in the 40-60*C range most of the time, though it got a little warmer when certain browser tasks get rolling. The cooling fan has remained off almost the entire time, but when it's running, it's still very quiet.

I was a little worried that I'd have a "never meet your heroes" moment when I bought this laptop, and that it might not live up to the expectations that I had. So far, it's everything I need and then some.

Multi-booting OpenBSD and Windows 10 on modern hardware with rEFInd

noreply@blogger.com (Ax0n) — Thu, 18 Mar 2021 02:16:00 +0000

The information here has been refined and documented in a dedicated page for Multi-Booting Windows 10 and OpenBSD. That page has all up-to-date details, and this post is no longer the best available source of information on this topic.

I recently purchased a 13.3" 8th Gen Lenovo ThinkPad X1 Carbon. Frankly, the X1 series has been my dream machine for years. I like small laptops, and this one is light, powerful and is similar to what's used by many of the OpenBSD core developers, so I knew it would probably be well-supported. My previous laptop -- the Acer I upgraded to an i5 for VMM years ago -- was set up for dual-boot, but somewhere along the way, the Windows boot manager stopped booting OpenBSD so I'd been using a modified OpenBSD install image on an SD card to load the OpenBSD kernel from the internal SSD, I set the BIOS to prioritize the SD card for booting, and I just remove the SD Card from my Acer if I need to boot Windows. That laptop is growing long in the tooth, but it's served me well for the past 5 years.

I decided to try properly dual-booting Windows and OpenBSD again with my new ThinkPad. And that's where things got ugly.

The steps to get Windows and OpenBSD working together, as outlined in the OpenBSD Multibooting FAQ seem to not work at all on recent Windows 10 versions, and especially on modern PCs with EFI and GPT disks. I tried several times without any luck, and I also rendered my system unbootable a number of times in my quest. Fortunately, I had made recovery media so I could blow away my X1 Carbon to factory defaults when things went sideways. That's a 45 minute process each time.

Start with a Windows install, and have good backups, including, if possible, external recovery media from the manufacturer. Several times, the drive partition table was so screwed up that the recovery partition was missing as well, leaving me with the recovery USB stick as my only way forward. To resize the Windows partitions, you will have to completely disable BitLocker full-disk encryption if it's enabled. I am a fan of FDE, but we have to turn it off for this to work. You can re-enable it when you have your whole system back up and running, but there are come caveats at the end.

Create a Live USB of GParted.

On another USB stick, write the contents of the OpenBSD installXX.img. This link references install68.img from OpenBSD 6.8, which may be out of date or a broken link when you read this.

Boot into the gparted live distro. On modern EFI/UEF systems, you will probably need to adjust secure boot and/or legacy boot options in your system's BIOS to continue.

Shrink the main Windows partition by some amount to make room for OpenBSD. I gave myself 120GB. That's how much room I have dedicated to OpenBSD on my Acer, and it seems to be a good size. I also usually create another FAT32 or Exfat partition that I can store files on to be accessed from both OpenBSD and Windows, but that's beyond the scope of this write-up.

Create a new partition for OpenBSD in the empty space. GParted doesn't know about OpenBSD partition types, so you'll have to then close GParted and launch a terminal window from the live environment. You'll have to launch gdisk via sudo and address your drive's device. For example:

sudo gdisk /dev/nvme0n1

Use the "p" option to print a list of partition entries. Find the one you created and use the "t" option to change the partition type to "A600" which is what OpenBSD expects to use for its disklabel entries. "w" will write the GPT and exit. You may also want to use the "b" option before you exit to make a backup of your partition tables just in case you mess something up. You'll have to store it to a USB drive, but you can probably store it on the same USB stick you booted GParted from.

At this point, I decided to reboot and make sure Windows still works. Thankfully, it did. Reboot into the OpenBSD installer using the USB stick you created. I won't walk through the whole installer process, but pay very close attention to the disk partitioning options. When prompted for the disks to install OpenBSD to, you should see an "OpenBSD Area" option and that should be the default disk partition to install to. If that option doesn't exist and you choose "gpt" or "whole disk" you will destroy the GPT record on your drive and destroy the Windows installation. Your system will only boot into OpenBSD if you proceed. You can probably use gdisk and your backup of the GPT to recover the partition table if you didn't actually install OpenBSD, or you may have to reinstall Windows and start all over again, and that isn't fun. Trust me. I've done that four times this week. Don't let the system do an auto-layout. Choose "custom." Unless you know what you're doing, just make one big disklabel partition for OpenBSD's root drive.

Once OpenBSD is installed, exit to the shell. You will need to copy the EFI boot executable to some other media so you can access it from Windows. I inserted a USB stick that was formatted for FAT32. It showed up as sd1 and the first non-BSD partition typically shows up as "i"

mkdir /usb
mount /dev/sd1i /usb
cp /mnt/usr/mdec/BOOTX64.EFI /usb/bootx64_openbsd.efi
umount /usb

Go ahead and reboot. It should boot into Windows. Fingers crossed!

Now, go download rEFInd and unzip the archive. I followed the Windows manual install instructions to get rEFInd working. I rebooted again, simply because I'd become so accustomed to bricking my shiny new laptop. To my surprise, rEFInd presented me with a boot menu. Windows showed up, and an additional menu item called "Fallback boot" also appeared. This menu option booted me into OpenBSD. That could be pretty much the end of it, but I wanted an actual OpenBSD menu option.

To accomplish this, I borrowed some mojo from this somewhat dated blog entry on FunctionallyParanoid

You have to access the EFI system partition from a privileged command shell (hearkening back to the instructions to manually install rEFInd from Windows), so I copied the refind.conf file off to my Documents folder, edited it with notepad, then saved it and copied it back over to the EFI system partition.
I added this clause near the end of the refind.conf file:

menuentry “OpenBSD”
{
icon \EFI\refind\icons\os_openbsd.png
loader \EFI\boot\bootx64_openbsd.efi
}

Make sure to download the OpenBSD icon and place it in the \EFI\refind\icons folder, too. Once I did that and rebooted, rEFInd still had the "fallback" menu item, but OpenBSD showed up with its own logo alongside the Windows logo. Both operating systems boot, and my mission was finally accomplished.

Mobile Weather Balloon Chasing Rig

noreply@blogger.com (Ax0n) — Mon, 21 Sep 2020 14:40:00 +0000

A few locals (mostly part of the SecKC crew) have been chasing weather balloons for the past few months. It's an interesting way to get out of the house and go do something. We are also trying to reverse engineer the guts of these weather balloon payloads, but that's a story for another post.

Weather Balloons and Radiosondes

In the US, a number of National Weather Service offices (I'm guessing about a third to half of them) deploy weather balloons every day at about 0:00 and 12:00 UTC, give or take an hour either way. They often launch at about 45 minutes ahead of time, but they can be delayed by severe weather. That's over 700 weather balloons per year from each of the dozens of stations that launch them!

The weather balloons carry something called a radiosonde into the stratosphere. This package contains a battery, radio transmitter, GPS, and weather sensors. The radio transmissions include position information, humidity, temperature and other metrics, once per second. Position information is used to determine wind speed and elevation to correlate with the other metrics. This data is shared internationally and is used for local forecasts and models, and worldwide climate trends.

Close up of the bottom panel of a 400 MHz Lockheed-Martin Sippican LMS-6 Radiosonde.

The air gets thinner and the pressure lowers as the balloon climbs past 100,000 feet, and it eventually bursts. The package, weighing less than a pound, falls back to the ground under a small parachute so that it doesn't hurt anyone or anything when it lands.

Here's a video I shot through a telescope, of a weather balloon bursting at about 130,000 feet. You can faintly see the radiosonde swinging beneath the balloon. When it bursts, the parachute expands as the package falls.

A recovered weather balloon, after untangling all of the rope.

The National Weather Service does not recover these devices from the field. Some of them have a mailing bag and shipping label attached so that folks who find them can return them to be refurbished. The radiosondes that we've been finding have no instructions aside from "dispose safely". That is to say, once they have fulfilled their mission and landed, these radiosondes are very much "finders keepers" and are no longer government property. They can land more than a hundred miles away from the launch site, depending on jet streams and wind conditions closer to the surface.

Tracking

To facilitate the tracking of these devices, a number of software tools have been created to make use of software-defined radio receivers (such as the RTL-SDR or HackRF One) or simple audio-decoding from a computer sound card. My favorite tools are radiosonde_auto_rx and chasemapper, both part of Project Horus, an amateur radio high-altitude-ballooning project in Australia. The tools to monitor amateur balloons happens to work just fine for tracking weather balloons, and folks have added code to help decode the payload data for weather balloons.

radiosonde_auto_rx scans a small range of frequencies you define, looking for a signal that's likely to be a radiosonde. It then tunes to that frequency and tries to decode the location data. Once it's locked on, it continuously tracks the location of the balloon. It can also upload balloon location data to websites like sondehub (radiosonde tracking) and habhub (high-altitude balloon tracking), so folks can share data about these balloons' trajectories with a world-wide audience.

Screen shot from sondehub.org showing multiple weather balloons in flight, and locations of auto_rx sites:

Chasemapper acquires the balloon location data from radiosonde_auto_rx, and your location from local GPS data, then draws a map of your location and the payload's location, in a browser session. This is a nice visual aid when you're planning on recovering a radiosonde. Here's a screen shot showing my vehicle's track and a radiosonde payload location on a recent balloon chase. The payload location doesn't have a track following it because I rebooted my setup to move it to my car. The movement was from me hiking toward my car while unplugging the battery.

Building the mobile tracker

I decided I'd like to build a semi-mobile balloon tracker that I could leave running at home most of the time, but also quickly toss into my car or even carry with me if a radiosonde was going to be landing nearby, to help me recover it from some corn field or woods or an 8-foot tall patch of thistles and prairie grass out in the middle of nowhere. These things never seem to land anywhere convenient, like in the ditch of a dirt road.

I decided to make do with stuff I already had laying around. You may recognize some pieces from previous articles. The below links are Amazon affiliate links to the parts I used if you wish to reproduce my exact setup, and purchasing from these links supports this site).

Raspberry Pi 3 with an AdaFruit 3.5" TFT
RTL-SDR v3 receiver kit or NooElec NESDR Nano Three kit (you only need one SDR, both of these models work in this setup)
Inseego MiFi 8800L WiFi Hot-Spot
Rii wireless mini keyboard/trackpad
26800mAh USB battery pack

The MiFi 8800L not only offers 4G wireless connectivity so radiosonde_auto_rx can upload location data and chasemapper can download map data, but it also has a GPSd server integrated so other devices (like the Raspberry Pi) can use the GPS location of the hotspot. You must log in to the MiFi admin page to activate the GPS Service. By default, it runs on port 11010, and it's recommended to leave that default set.

Actually getting chasemapper to use that GPS data turned out to be more trouble than I had bargained for. You may be better-off connecting a USB GPS to your Raspberry Pi. I'll cover how I managed to cobble everything together as I go through this post.

The first order of business was installing the latest RasPiOS to a fresh 16GB SD Card. There is more than enough documentation on raspberrypi.org to get you started. The Rii keyboard works both with a nano-receiver or via Bluetooth. Pick your poison. I chose to use the nano-receiver because bluetooth seems to not like to auto-reconnect on reboot some of the time. Feel free to use whatever kind-of-portable human-interface device you like.

Next, I had to get the display working.

I had really good luck with the fbcp-ili3941 driver on this Raspberry Pi with Kali Linux, and the instructions I wrote about setting up fbcp worked fine on the latest RasPiOS. You can follow most of the instructions in that article to get the AdaFruit TFT working, just keep in mind the touch screen won't work with the fbcp driver. The digitizer on my display actually broke a few years ago, so I don't miss it.

For my setup, I uncommented the following lines in config.h. Note that these lines need the # at the beginning of the line. I removed the // from these two lines to uncomment them:

#define DISPLAY_ROTATE_180_DEGREES
#define DISPLAY_BREAK_ASPECT_RATIO_WHEN_SCALING

I used the following options to build fbcp:

cmake -DADAFRUIT_HX8357D_PITFT=ON -DSPI_BUS_CLOCK_DIVISOR=30 ..

As per the Kali instructions, I put the call to /usr/local/bin/fbcp near the top of /etc/rc.local so that it runs on boot.

I set my display up to run in 480p mode since the display is so tiny. The entirety of my /boot/config.txt file is:

hdmi_force_hotplug=1
dtparam=audio=on
hdmi_group=1
hdmi_mode=3
dtoverlay=pwm,pin=18,func=2

Reboot and make sure the TFT display works.

Now for Radiosonde_auto_rx. The setup instructions mostly work. You'll need to install a bunch of dependencies. They recommend installing rtl-sdr from source. I just added it via apt, and it supported the bias-tee option. Make sure you install the udev rules and module blacklist options per the instructions.

Keep following the instructions. Maybe, if you're lucky it'll just work. For me, though, I had to do some hacky garbage to get it to compile. If build.sh fails, you can try these tricks:

I had to tell the compiler use the c11 standard for compiling fsk_demod by adding “-std=c11” to line 50 of auto_rx/build.sh, which now looks like this:

gcc -std=c11 fsk_demod.c fsk.c modem_stats.c kiss_fftr.c kiss_fft.c -lm -o fsk_demod

I had to tell the compiler to use the built-in alloca() for some reason, and the real baffler was having to define the meaning of freaking Pi, twice.

In utils/fsk.c, I added these lines to the "includes" block near the top:

#define alloca(x) __builtin_alloca(x)
#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

And I added the following to utils/modem_stats.c, also near the top.

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

With all that out of the way, the instructions for setting up Radiosonde_auto_rx work just fine. Make sure to edit station.cfg. You probably want to specify a name, callsign or handle for uploading to HabHub (and enable uploads), and you should specify your latitude and longitude. You could, in theory, also use gpsd for radiosonde_auto_rx as well. I didn't set up auto_rx to use gpsd, so even when I'm mobile, the reports appear to come from the hard-coded location in auto_rx. I'm fine with that.

It seems that the National Weather Service relies mostly on radiosondes made by Lockheed Martin Sippican. The LMS-6 Radiosonde comes in two "flavors", one operating between 400 and 406 MHz and the other one operating around 1680 MHz. The Vaisala RS41 is a newer radiosonde model used at some locations, and it also operates around 400 MHz. You should ensure the proper frequency range for your location is enabled. The 1680 MHz radiosondes also work best with a circular-polarized antenna, similar to those you might use for certain FPV drone video.

Setting up Chasemapper

The instructions for Chasemapper mostly work out of the box, with the exception of GPSd in my case. The version of GPSd on the MiFi 8800L doesn't support JSON output which Chasemapper requires, so I ended up running a modern version of GPSd on RasPiOS, pointing it at the GPSd on the hot-spot. Details on that toward the end of the article. I also had some trouble running GPSd on the default port of 2947, so of course I ran it on port 1337.

For horusmapper.cfg, I changed only the following lines:

car_source_type = gpsd

gpsd_port = 1337

habitat_call = [my amateur radio callsign]

Tying it all together

I didn't set up systemd services for anything, but you may want to follow the instructions in the git repositories to enable systemd services if you plan on building a dedicated tracker. I run gpsd, auto_rx and chasemapper on-demand with a simple shell script that I call "loon.sh":

#!/bin/sh
gpsd -S 1337 gpsd://192.168.1.1:11010
cd ~/radiosonde_auto_rx/auto_rx
python auto_rx.py&
cd ~/chasemapper/
python horusmapper.py&

Everything runs in the background, and the terminal will fill up with logs about both chasemapper and auto_rx status. You can fire up your Raspberry Pi's web browser and hit localhost:5001 for ChaseMapper, and localhost:5000 for the auto_rx status page.

GMRS and You

noreply@blogger.com (Ax0n) — Tue, 04 Aug 2020 21:26:00 +0000

With the availability of handheld radios that are more powerful than cheap walkie-talkies, even more powerful radios for your home and vehicles, antenna masts and a small network of repeaters, GMRS allows your family some of the benefits of amateur radio, at a marginal cost, and without every member having to pass an exam. With a decent home and mobile GMRS radio set-up, your family could likely stay in touch even if you stray several miles from home for work or errands.

With the potential of a wide-spread infrastructure outage in an emergency, and increased tracking of location data via smart phones, payment card transactions and the like, adding GMRS to your family's communications strategy can make a lot of sense.

FRS vs GMRS

General Mobile Radio Service (GMRS) is a UHF Land Mobile Personal Radio Service, not much unlike Citizens Band (CB) or Family Radio Service (FRS). In fact, 14 frequencies used by GMRS are shared with FRS.

Up until the rules changed in 2017, one had to obtain a GMRS license to use channels 15-22 on FRS/GMRS handheld radios that look a lot like the one on the left in the title photo above. That radio is actually a 5 watt Midland GXT-1000 GMRS radio, but with a few caveats, it can be used for FRS as well.

Recent changes were made to allow up to 2 watts on channels 1-7 and 15-22 as part of FRS without obtaining a license. Channels 8-14 are still reserved solely for FRS use in the US, with a maximum of 500mW output. A number of FRS radios are available that run close to 2W on legal channels, but today I'll be focusing on GMRS specifically. The primary differences between FRS and GMRS are:

GMRS handheld radios are allowed to transmit up to 5W
GMRS mobile and base-station radios are allowed up to 50W
Removable antennae are allowed
Repeaters can be used on GMRS
An FCC license is required for GMRS, but there is no exam.
Businesses can legally use FRS for operations, but business use of GMRS is mostly disallowed.

The Rules

A short, multi-page primer on GMRS is provided by the FCC.

The full rules for operating on GMRS are in FCC Part 95 subpart E.

The short, short version of the rules that should cover most of the highlights:

No "public broadcast" messages, advertising or music
No profanity
Only communicate with other GMRS or FRS users. Communication with amateur radio stations is not allowed.
No "Jamming" or continuous transmissions
Don't use GMRS to assist in any criminal activity
You must identify your call sign (e.g. WRBX000) in English or morse code

At the end of a single transmission that you do not expect a reply to
At the end of a conversation
At least once every 15 minutes while communicating

You can authorize any family members to use your license with your permission.

Your parents, children, grandparents, nieces, siblings and uncles can legally operate on GMRS under one single license, if you give them permission and ensure they know the rules.
If they break the GMRS rules under your license, your license is likely in jeopardy. You are ultimately responsible for the actions of those using your license.

While GMRS is provided as a convenient way for family members to stay in touch, an authorized GMRS user is allowed to talk to others outside of their family. They do not need to be physically close enough to you to communicate with you as the license holder as long as they obey the rules.

Licensing

Most adult United States citizens are eligible to apply for a GMRS license. As of 2020, the license fee is $85, and it is valid for 10 years from the date of issue.

One can apply for a GMRS license online through the Universal Licensing System, or by mail. Either way, you must fill out FCC Form 605. Filing online requires you to register for an FCC Registration Numer (FRN) if you do not already have one. Amateur radio operators may use their existing FRN, for example.

Once logged in to ULS, click "Apply for a new license" and choose "ZA - General Mobile Radio Service" from the very bottom of the drop-down list.

Upon completion of FCC Form 605 for GMRS, you will be required to make an online payment. Your license will usually show up within a few hours or on the next business day. You will also likely receive an email about your license grant.

Hardware

YOU MUST NOT USE AMATEUR RADIO EQUIPMENT* ON GMRS.

Transceivers specifically designed for amateur radio are not allowed on GMRS. Some hams use commercial radios that have been tuned to work on amateur radio frequencies, and there's a bit of a grey area there.

Until recently, hardware specifically designed to take full advantage of GMRS was pretty rare. Radios must be type-certified under FCC Part 95 to operate on GMRS and strict standards must be met with regard to channel deviation, frequency stability at a wide variety of temperatures, and spurious emissions. It just so happens that commercial land mobile UHF Radios type-certified under FCC Part 90 meet or exceed the specifications for GMRS, so long as they do not exceed 50 watts of output power. As such, many GMRS users will re-program commercial UHF radios to operate on GMRS frequencies. The FCC hasn't ever given a straight answer about if this is allowed, but most repeater operators are okay with it. The Motorola Radius in the above photo is one of these, but a variety of 15-45 watt mobile radios and 2-5 watt handhelds from the commercial lines of Motorola, Kenwood, Bendix/King and others can often be found inexpensively on the used market. Just make sure you, or the seller, can program them properly.

BTech (purveyors of the ubiquitous, cheap "Baofeng" ham radios) markets two GMRS-specific radios: the GMRS-v1 handheld and the GMRS-50X1 mobile radio. These two have been type-certified for GMRS, have the ability to use GMRS repeaters, and are legal. The GMRS-V1 is, in fact, the only GMRS-specific handheld radio I was able to find that has repeater capability.

Midland, Cobra, and Uniden have also been making a variety of type-certified GMRS radios. Most of the handheld units, like the Midland GXT-1000 I have, do not have the capability to use GMRS repeaters, but the Midland Mobile and Micro-Mobile radios, designed to be installed inside vehicles, do have repeater capability.

Most GMRS radios are interoperable with FRS radios. The GMRS-specific radios mentioned above may have more than 22 channels, but channels 1-22 are almost guaranteed to work between any GMRS and FRS radio. If your family does a lot of outdoor activity, you may find that inexpensive FRS radios work fine for kids, and your GMRS radios will let you communicate with them.

Many old-school GMRS users refer to frequencies -- and especially repeaters, by the kilohertz part of the frequency only. I suspect this persists in part because GMRS users are begrudgingly sharing practically all of their frequencies with FRS users and dislike the concept of channel numbers. At any rate, "700" refers to either 462.700 MHz, or a repeater that uses 467.700 MHz on the input and 462.700 MHz on the output.

You can see actual frequencies in this chart on Wikipedia:

https://en.wikipedia.org/wiki/General_Mobile_Radio_Service#Frequency_Table

Repeaters

Like amateur radio, GMRS operators can run repeater systems. These repeater systems listen 5MHz higher than the base frequency, and re-transmit the signal on the base frequency so that all radios listening can hear the message. Not all regions have GMRS repeaters, but here in the Kansas City area, there are several to choose from. Unlike amateur radio repeaters, most of them require permission from the repeater operator before you use them.

MyGMRS.com is probably the closest thing there is to a directory of all GMRS repeaters in the United States. You can browse the repeater listings without signing up for an account, but many repeater details (such as the CTCSS or DCS codes to use them) are hidden until you log in. Some of these details are completely unlisted, instead requiring you to ask the repeater owner for permission. You can only create a MyGMRS account once your GMRS license has been active for a day or two and the website has imported your license from the FCC.

You can also buy or build your own GMRS repeater, and it probably comes as no surprise that commercial repeater hardware is also quite common. Repeater building is a complex topic I won't cover here, but the cost is usually pretty significant.

Yaesu FTM-400XDR - Undocumented Cross-Band Repeater Mode

noreply@blogger.com (Ax0n) — Wed, 13 May 2020 03:23:00 +0000

I was in the market for a new dual-band amateur radio. I'm a bit of a Yaesu fan, and I was torn between trying to find a used workhorse like the FT-8900R, or trying something a bit more modern, like the FTM-400XDR. The one thing I really wanted the '8900R for was its cross-band repeater. That was the only thing missing from the new '400XDR.

Cross-band repeater mode will listen on two different bands (usually 70cm and 2m) and repeat what's being "heard" on one of the bands, transmitting it on the other. You can use this for a variety of purposes, but it's most commonly used to boost the range of a small handheld radio when you can't feasibly take a high-powered radio with you -- such as into an office building, down in your basement storm shelter, or keeping in touch with a group of spread-out friends while in an area without good repeater coverage.

Lo and behold, the FTM-400XDR does have a cross-band repeater built-in. It's just not documented officially. It's actually pretty easy to set it up.

Start by configuring your radio's tuners the way you want them to work together. Check that the frequencies, repeater offsets, squelch are all correct, and disable APRS if you had it enabled.

In this case, I configured the top tuner to communicate with a local repeater, on medium power. It might be kind of hard to see, but there are indicators "-" and "T-TRX" in the header of the top tuner that indicate a negative repeater offset, and "Tone Squelch on Transmit and Receive" which are common radio configurations for repeater use. You could instead set the upper tuner to a simplex frequency if you want to run it as a stand-alone temporary repeater.

The bottom tuner has to be on the other band. Since the repeater I wanted to talk through is on the 2m band, I selected a simplex frequency from within the 70cm band. Since I plan on staying pretty close to my radio for this test, I set the power level on the bottom tuner to low power, and made sure there was no auto-repeater-shift offset. You'll notice there are no indicators in the header of the lower tuner. You would not want to accidentally link two other repeaters together. Don't cross the streams.

Power the radio off. Next, hold the SETUP, F and GM buttons under the power button at the same time. Keep holding them while you power the radio on.

When it powers up, you will see an "X-Repeater" indicator in the middle of the screen.

If you're setting up a stand-alone repeater, all users will have to configure their dual-band handheld radios for "split" operation. This varies by make and model, but you'll want them to transmit on the same frequency as the bottom tuner, and receive on the same frequency as the top tuner of the '400XDR. Anything transmitted by members of your party on the lower tuner's frequency will be repeated out to everyone else listening on the upper tuner's frequency.

To use the cross-band repeater with another repeater like I did, you'll want to set your handheld radio to use the simplex frequency, without a repeater shift, that's displayed on the bottom tuner. The cross-band will relay bi-directionally, so whatever you transmit will be sent to the repeater configured on the upper tuner, and whatever the repeater transmits will be sent back to your handheld via the simplex frequency on the lower tuner.

To disable cross-band repeater mode, power the radio off, then use the same 3-finger-salute while powering it back on.

Caveats:

When the repeater isn't being actively used, you're still responsible for ensuring it is functioning properly. Your cross-band repeater has no way to identify itself. (e.g. CW ID) and lacks the sophistication of a real repeater.
You or someone you trust should be close enough to your cross-band repeater to shut it off quickly should it malfunction or otherwise transmit undesired activity (such as static, intentional interference, radio pirates).
Turn the radio off or disable cross-band repeater mode if you are not actively using it or are unable to monitor it.
Use the minimum power level possible for the communications required. This is just best-practice, but also, if you end up cross-band repeating a long-running discussion, you may overheat your radio and/or drain your car battery. Mobile radios like this are designed for a relatively low duty cycle -- transmitting only for a few minutes at a time, then given a chance to cool down while others talk. Low power (5 Watts) is probably safe for extended, continuous bidirectional operation.
The FTM-400XDR is capable of operating on Yaesu System Fusion (C4FM) digital modes, but under cross-band repeater mode, it will only operate in analog FM mode. You cannot cross-band repeat to a digital repeater from an analog handheld radio.

I do wonder if another Fusion radio could communicate through a cross-band repeater to a Fusion Repeater and vice/versa... I don't have a second Fusion radio to test this with.

02/02/2020! The first palindrome date since 11/11/1111

noreply@blogger.com (Ax0n) — Sun, 02 Feb 2020 19:05:00 +0000

It's been almost a decade since I've seen an "only happens every several hundred years" thing floating around that seemed too out-there to be real.

So let's debunk the "first palindrome date since 11/11/1111" shall we? Surely these happen more frequently than that. And for shame not using ISO-8601 format. Fortunately, today also works as an ISO-8601 palindrome: 2020-02-02.

I whipped up a quick bash script to scan for dates n-days before and after today's date looking for palindromes in ISO-8601 format as well as the two other formats that are commonly (ab)used here in the United States, DD-MM-YY and DD-MM-YYYY. It's inefficient, relying on a lot of calls to date(1) and rev(1) but it is what it is.

#!/bin/sh

export i=1

while true

do

# ISO-8601 or GTFO.

idtb=`date -v-${i}d +%Y%m%d`

idtf=`date -v+${i}d +%Y%m%d`

# MM-DD-YYYY format

ydtb=`date -v-${i}d +%m%d%Y`

ydtf=`date -v+${i}d +%m%d%Y`

# MM-DD-YY format

dtb=`date -v-${i}d +%m%d%y`

dtf=`date -v+${i}d +%m%d%y`

if [ "$idtb" -eq "`echo $idtb | rev`" ]

then

echo YYYYMMDD $idtb was a palindrome.

fi

if [ "$idtf" -eq "`echo $idtf | rev`" ]

then

echo YYYYMMDD $idtf will be a palindrome.

fi

if [ "$ydtb" -eq "`echo $ydtb | rev`" ]

then

echo MMDDYYYY $ydtb was a palindrome.

fi

if [ "$ydtf" -eq "`echo $ydtf | rev`" ]

then

echo MMDDYYYY $ydtf will be a palindrome.

fi

if [ "$dtb" -eq "`echo $dtb | rev`" ]

then

echo MMDDYY $dtb was a palindrome.

fi

if [ "$dtf" -eq "`echo $dtf | rev`" ]

then

echo MMDDYY $dtf will be a palindrome.

fi

export i=`expr $i + 1`

done

A quick run for a minute or so shows a lot of palindromes past and future.

MMDDYY 021120 will be a palindrome.
MMDDYY 022220 will be a palindrome.
YYYYMMDD 20211202 will be a palindrome.
MMDDYYYY 12022021 will be a palindrome.
MMDDYY 121121 will be a palindrome.
MMDDYY 122221 will be a palindrome.
MMDDYY 112211 was a palindrome.
MMDDYY 111111 was a palindrome.
YYYYMMDD 20111102 was a palindrome.
MMDDYYYY 11022011 was a palindrome.
MMDDYY 012210 was a palindrome.
MMDDYY 011110 was a palindrome.
YYYYMMDD 20300302 will be a palindrome.
MMDDYYYY 03022030 will be a palindrome.
YYYYMMDD 20100102 was a palindrome.
MMDDYYYY 01022010 was a palindrome.
MMDDYY 031130 will be a palindrome.
MMDDYY 032230 will be a palindrome.

AppSec Lab: RasPwn with a MiFi-8800L JetPack Router

noreply@blogger.com (Ax0n) — Sat, 04 Jan 2020 00:34:00 +0000

I'm hosting a few Application Security workshops later this year. I settled on RasPwn for the lab because it comes pre-configured with a bunch of vulnerable applications out of the box.

RasPwn acts as a stand-alone wireless access point using the Raspberry Pi's on-board Wi-Fi. If you plug in ethernet, it can route packets, but DNS forwarding seems broken. Some of the participants will have to be online and available during the workshops, so I wanted to make sure the lab has full Internet access. Additionally, it helps when folks can look up information about vulnerabilities while learning new concepts. I won't always be able to rely on on-site ethernet to provide Internet access to participants, so I decided to set up my MiFi 8800L hotspot as an Internet gateway on RasPwn, and I had to make sure DNS worked.

Hotspot setup:
When you plug in most WiFi hotspots over USB, some will only charge the internal battery, while others will immediately show up as a network device. Some also show up as a "virtual USB drive" with drivers and software. The Inseego MiFi-8800L touch-screen model prompts you when you plug it in, and has an option to serve Internet via USB only or USB+WiFi.

If you use the Web UI, you can set this option as the default. There's no way to set it up from the touch-screen interface. All other Inseego (and their previous brand, Novatel) hotspots I've used can be set up to provide USB Internet access by default, using the web admin portal. See owners' manual for details on accessing the admin portal. It'll probably vary widely by model. Example from my 8800L:

RasPwn setup:

Download the RasPwn software and follow the install instructions on the download page. If you've messed with Raspberry Pi distributions before, this should be pretty self-explanatory.
Place the card into a Raspberry Pi 3 and power it up. You won't need a screen or keyboard for anything. I did have to power-cycle the Raspberry Pi after the first boot for the WiFi network to show up. You may have to do the same.

When RasPwn boots up, you'll see a new WiFi network called RasPwnOS show up. Connect to it. The default WiFi password is In53cur3!
SSH to 192.168.99.1. The username is pi and the password is pwnme!

ssh pi@192.168.99.1

Set up eth1 (for the hotspot's USB interface)

edit /etc/network/interfaces with vi or nano
insert the two lines below, preferably after "eth0" is specified:
allow-hotplug eth1
iface eth1 inet dhcp
Save the file

Change the IP masquerading rules for iptables to use eth1

edit /etc/iptables.up.rules with vi or nano
change the MASQUERADE rule from
-A POSTROUTING -o eth0 -j MASQUERADE
to
-A POSTROUTING -o eth1 -j MASQUERADE
save the file

Set up the DHCP server to issue an external backup resolver

edit /etc/udhcpd.conf with vi or nano
change the "opt dns" line from
opt dns 192.168.99.1 192.168.99.10
to
opt dns 192.168.99.1 8.8.8.8

(Note: the DNS stuff is kind of hacky. You could configure the on-board bind9 DNS server to resolve recursively, but it's more complicated and this works just fine)

Reboot RasPwn and test Internet connectivity.

sudo reboot
Close your SSH window
Wait a minute or so
Reconnect to the RasPwnOS wifi network
Try browsing the internet. If it doesn't work, make sure the HotSpot is showing a USB connection. You may need to unplug it and plug it back in, or unplug the hotspot, reboot RasPwn again, and plug the hotspot in after RasPwn boots up all the way.

Okay, so let's hack something!

Go to playground.raspwn.org from your RasPwn WiFi connection
Pick an app and start hacking!

The first thing in the playground is the OWASP Bricks practice application. It's intentionally vulnerable and designed to be increasingly complex with each challenge building on what you learned with the previous ones.

Some of the exercises will require an intercepting proxy such as BurpSuite, Charles Proxy, or OWASP ZAP, but the first login page can be hacked with just a browser. I actually didn't read any documentation for Bricks, and had never played with it before setting up RasPwn. My first login attempt was "admin" with a password of "admin" and it logged me in.

It wasn't until I saw the SQL in the footer that I knew this was supposed to be an SQL Injection challenge.Whoops. Okay, let's try this again with foo and a password of bar.

Okay, so that's what "access denied" looks like. Now let's throw some SQL injection into the username field. Here, I used a username of "foo ' OR 1=1 -- " (note the space after the -- comment, that's needed for MySQL and maybe other databases to acknowledge a comment).

And we've successfully used SQL Injection to hack the first Bricks challenge.

Happy hacking, friends!

OpenBSD 6.6 released early!

noreply@blogger.com (Ax0n) — Mon, 21 Oct 2019 00:11:00 +0000

OpenBSD 6.6 was released earlier this week. Along with it come a number of exciting enhancements to not just hardware support, but improvements to the installer, and security enhancements to the userland as unveil and pledge continue to get integrated more. You can read the entire change log at the link above.

As I had mentioned when OpenBSD 6.5 came out, sysupgrade(8) was making snapshot upgrades a breeze for those of us running -CURRENT. A few weeks back, the team made a sysupgrade patch available to bring this functionality to OpenBSD 6.5, so that folks could take advantage of it to upgrade to OpenBSD 6.6 when it was released. I spent some time this week testing it on my VMM virtual machines running OpenBSD-Stable and indeed, it's just as easy as upgrading snapshots. Then I upgraded everything else, including my production servers.

To upgrade from OpenBSD 6.5, as root or with doas, just run these commands:

syspatch

sysupgrade (it'll download what it needs, reboot, do the upgrade, and reboot again, fully unattended)

pkg_add -u (to upgrade all of your binary packages to the latest version)

As per usual, I updated the OpenBSD/httpd/MariaDB/PHP walk-through.

Scams: Two Close Calls

noreply@blogger.com (Ax0n) — Wed, 25 Sep 2019 13:57:00 +0000

Over on Twitter, Eric Mill tweeted:

A friend of mine who works in infosec recently fell for a scam and had to cancel their credit card. They're very embarrassed about it right now, but I'm pretty sure we can all be scammed, right? It's definitely happened to me.

Have you been scammed before? How'd it happen?
— Eric Mill (@konklone) September 25, 2019

My stories are a bit too long for Twitter, but let's unpack two scams that were pretty well done which I fell for -- at least partially -- recently. We'll also highlight some early telltale signs that something was wrong, which I embarrassingly either missed or shrugged off at first, so that perhaps you'll be able to spot these scams better.

Feel free to share your own "scammed" stories in the aforementioned Twitter thread, or here in the comments.

My bank's doppelganger phone number

My debit card had been getting flaky in chip readers recently. In fact, the plastic around the embedded chip contacts was breaking. It was time for a new card. I turned the card over to find the customer service number, which was a bit difficult to read because it was inexplicably printed directly under the embossed credit card number. The conversation went like this:

Agent: Thank you for calling [my bank's name] Card Services, this is [name]. Who am I speaking with today?
Me: ... my real name ...
Agent: Good morning, [name]! How can we help you today?
Me: My card's pretty worn out and isn't working consistently. I need a replacement, please.
Agent: We can get your new card sent out right away! What's your card number?
Me: ... reads the card number ...
Agent: And the expiration date?
Me: ... reads the expiration date after a short pause ...
Agent: And for security purposes, the 3-digit CVV code.

I suspected something was fishy when the agent requested my expiration date, but a few things were going on in my head. *I* called them, not the other way around. Also, the agent was professional and friendly, and even answered the phone with my bank's name. But when I got asked for the CVV code, that's when I knew something was completely wrong. I took a very close look at the back of my card, and compared it to the phone number I was calling. One of the hardest-to-read digits of the phone number on the back of my card was an 8, instead of the 0 that I dialed.

Having disclosed my first and last name, Primary Account Number and expiration date, I called my bank's real number and had my card disabled and ordered a replacement. My real bank didn't even need my whole card number to look my account up when I contacted them. That was the first red flag, and I had completely missed it.

The mobile phone carrier "Fraud Department"

I got a call unusually early on a Saturday morning from my mobile carrier's customer service number (It was in my contacts and it was the right number). The person on the line was from the fraud department, and explained that they'd seen unusual activity on my account. Someone had changed the address on my account and then mail-ordered a new iPhone X for a little over $1000. She explained that any time an address is changed right before a purchase, their system flags the transaction for review.

This sounds quite rational to me. But who had access to my account? My wife's caregiver had recently quit and moved out, and she had a phone on our account. When she quit, we made her leave the phone behind. Perhaps she was up to no good? I was confused and furious; I felt violated. I explained that our old roommate may be behind it.

"Do you recognize this address?" the agent asks, before rattling off some random address in The Bronx. There's no way our old roommate was in The Bronx. Her family is all in Texas and Oklahoma. I thought it was very strange that a fraud department representative would disclose this information to me. That was the first red flag. I chose to ignore it.

"Sir, we'll take care of this," she explains. "We never processed the transaction, because it was flagged for review. Let's get your account secured! I just sent you a one-time code to verify you're in possession of the phone tied to your account. Can you read it to me?" There's red flag #2. I was still far too flummoxed to see it.

I get an SMS message from my wireless carrier. In a rush, I don't even read the whole message. I rattle off the 8-digit number. But then something catches my eye as I bring the phone back up to my head. Right at the beginning of the text message, there's a big disclaimer along the lines of "For the security of your account, we will never contact you for this code."

Now the plot thickens, but I'm a bit sharpened up. I begin to suspect this is an elaborate ruse, and it worked pretty well.

"I am not comfortable with this call," I say, grabbing my laptop and trying to log in to my account. The password has already been changed, in under a minute. Even the temporary code I'd just been texted isn't working. "Is there a direct number I can call you back at?"

"I'm securing your account, sir. I assure you, I'm from the fraud department. We do this all the time. I understand you're angry. We're almost finished with the password reset," she says, quite professionally. Meanwhile, I'm issuing my own password reset through my carrier's website. I get the exact same text message this agent had "sent" me, with a different one-time code, obiously.

I tell her that something has come up and I'll have to call her back in a few minutes. I ask for her name again. "Jessica," she says.

"May I please have your direct phone number so I can call you back in a bit, Jessica?"

"Sure thing! Just call me back at the customer service number I'm calling from. I'm at extension 105."

I hang up, and finish resetting my password.

I call back while scrolling through my account to make sure nothing's been purchased or changed. I get my carrier's customer service, as expected. There is no way to dial an extension. I get a real human on the phone, and ask to be transferred to extension 105. There is no extension 105. There *IS* a fraud department, but they do not call subscribers directly. Customer service pulls up my account's history. They keep a record of every agent who's looked at my account. No one had opened my account since we added a line to the account for our recently-departed caregiver.

Attackers can easily spoof a call to make it look like it came from any phone number. Armed with only my carrier's customer service phone number, and a list of phone numbers assigned to my carrier, they can trawl through the list and perpetrate this scam over and over. Having a young woman with a southern twang make the calls, with obvious call-center background noise was icing on the cake.

Former student pleads guilty in "USB Killer" case

noreply@blogger.com (Ax0n) — Tue, 30 Apr 2019 13:57:00 +0000

A few weeks old, from the Department of Justice website, comes the first mention I've heard of a "USB Killer" being used nefariously at scale:

Akuthota admitted that on February 14, 2019, he inserted a “USB Killer” device into 66 computers, as well as numerous computer monitors and computer-enhanced podiums, owned by the college in Albany. The “USB Killer” device, when inserted into a computer’s USB port, sends a command causing the computer’s on-board capacitors to rapidly charge and then discharge repeatedly, thereby overloading and physically destroying the computer’s USB port and electrical system.

Akuthota admitted that he intentionally destroyed the computers, and recorded himself doing so using his iPhone, including making statements such as “I’m going to kill this guy” before inserting the USB Killer into a computer’s USB port. Akuthota also admitted that his actions caused $58,471 in damage, and has agreed to pay restitution in that amount to the College.

This is the predominant threat model that came to mind when USB Killer Hype kicked in about a year and a half ago. That is, someone repeatedly using it to attack unattended computers. While USB Killer devices are no longer one-off devices, and they have achieved a sort of "commercial viability," the kind that look convincing enough for a random person to insert into their own PC cost more than $60 USD. That's a lot of cash to spend on potentially destroying devices belonging to a random person by just leaving it laying around. Cheaper ones that are chunky (or have no case at all, or have cases emblazoned with menacing logos) are easier to come by, but obviously look more suspicious.
This is a pretty "clean" way for someone to destroy a computer they have physical access to, but ultimately, "physical access is total access" as the saying goes.

OpenBSD 6.5 released early

noreply@blogger.com (Ax0n) — Mon, 29 Apr 2019 03:33:00 +0000

A few days late posting this, but OpenBSD 6.5 hit the wire last week, ahead of the May 1 target release date. Our OpenBSD Web Server Guide -- using the built-in httpd -- has been updated. And the PHP-FPM quirks from OpenBSD 6.4 got ironed out.

As far as installation and daily use go, you probably won't notice much has changed in OpenBSD 6.5. There was a ton of work done in areas of hardware support and network-stack enhancements.

If your console supports it, you may notice a new default console font (called "Spleen"). I've seen this on my OpenBSD-Current laptop for a few months. At first, I didn't really like it, but it's quite readable and has grown on me when working in text-only mode. I'm considering setting it as my default xterm font as well.

If you use OpenBSD-CURRENT with snapshots, however, there's already some fun stuff unfolding there, with sysupgrade(8) among them. This makes in-place upgrades a breeze. While it's not available in OpenBSD 6.5, upgrading from one release to the next should get a lot easier in about a year's time. The 6.6 to 6.7 upgrade will be the first supported release with this tool, unless they backport it to 6.5 with an errata/patch -- unlikely, indeed...

Here's our new sysupgrade utility in action: a fully unattended snapshot upgrade with just one command. https://t.co/wRF8jlHvA6 pic.twitter.com/NVOO9yHTns
— OpenBSD (@openbsd) April 26, 2019

OpenBSD VMM Hypervisor Part 4: Running Ubuntu (and possibly other distros)

noreply@blogger.com (Ax0n) — Mon, 03 Dec 2018 05:12:00 +0000

TL;DR: you cheat.

I've been trying for almost a year to figure out how to get the cloud-init meta-data service to work with the Ubuntu Cloud image. I've asked on misc@ and other OpenBSD groups, and no one has an answer. The documentation is vague. If anyone ever figures out how to configure meta-data, let me know. I'd still like to give it a shot.

Last week, I rescued a server from a pile of computers destined to be scrapped and recycled. For me, it's the perfect setup for getting serious with OpenBSD VMM in my home lab. Two older Xeon E5-2620 CPUs and 128 GB of RAM. No hard drives, but it came with enough empty drive trays for getting started. I threw a pair of old SAS drives into it.

No surprise, OpenBSD just worked. This renewed my fervor for replicating a bunch of my cloud instances at home, and there's a lot of Ubuntu in use.

I decided to bite the bullet and just use qemu to do the installation and configuration of Ubuntu. Install qemu from packages:

doas pkg_add qemu

Download Ubuntu Server. I've actually used both 18.04 LTS and 16.04 LTS. I'm focusing on 16.04 for this because that's what I'm running on most of my EC2 instances.

Create a disk image.

vmctl create qcow2:ubuntu16lts.qcow2 -s 20G

Boot the ubuntu ISO and attach the new ubuntu disk image to qemu:

qemu-system-x86_64 -boot d -cdrom ~/Downloads/ubuntu-16.04.5-server-amd64.iso -drive file=ubuntu16lts.qcow2,media=disk -m 640

Install Ubuntu as usual. I didn't bother adding anything other than the SSH server during installation. qemu is really slow on OpenBSD, but it works... eventually. When the install is done, shut down and then restart qemu without the installation ISO attached.

qemu-system-x86_64 -drive file=ubuntu16lts.qcow2,media=disk -m 640

Log in with the user-level account you created. There are only two things to tweak before it's ready to run in vmm: Configuring the serial console, and the network interface.

Under qemu, Ubuntu sees "ens3" as the network interface. Under vmm, the network interface is "enp0s3". Change "ens3" to "enp0s3" in /etc/network/interfaces if you're using 16.04. On Ubuntu 18.04, you must instead change the "netplan" config file in /etc/netplan/50-cloud-init.yaml with the same kind of change, ens3 to enp0s3.

To configure the serial console, edit /etc/default/grub and change this line:

GRUB_CMDLINE_LINUX=""

to

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8"

then run

sudo update-grub

Shut down qemu again. Your disk image is basically ready to go under vmm.

To save the trouble of having to mess with qemu again, I recommend creating derivative images of the one you just created, and using those for vmm.

vmctl create qcow2:ubuntu16lts-1.qcow2 -b ubuntu16lts.qcow2

Add the new disk image to a configuration clause in /etc/vm.conf on your OpenBSD host system. Mine looks like this:

vm "Ubuntu16.04" {
        disable
        owner axon
        memory 4096M
        disk "/home/axon/vmm/ubuntu16lts-1.qcow2"
        interface {
                switch "local"
                lladdr fe:e1:ba:f0:eb:b0
        }
}

For more information about setting up switches and networks in vmm, see Part 2 of my VMM series.

Voila! Ubuntu in VMM!

Although the configuration files you must edit to make it work might vary, you can do the same thing and it may very well work for text-mode-only distributions.

I actually didn't need to use qemu to get arch linux installed in vmm, but it was somewhat tedious to do entirely in vmm, and it took me a few tries to get it right. Qemu might have been easier.

OpenBSD vmm Hypervisor Part 3: qcow2 and derived disk images

noreply@blogger.com (Ax0n) — Fri, 02 Nov 2018 02:44:00 +0000

With OpenBSD 6.4, the VMM hypervisor got support for qcow2 disk images. This format is used by QEMU, but it has several features that make it a better choice than raw image files. The images are dynamically-allocated, so the disk image file grows as you use more space instead of taking up the entire filesystem size when the image is created. It won't ever shrink, though. "Derived images" are also supported. While VMM doesn't officially support snapshots yet, you can kind of get away with using derived images to do something similar. I'll cover that toward the end of this article.

You will probably want to have the networking set up on your OpenBSD VM host before you continue. That information is covered in Part 2 of my VMM series.

To create a qcow2 image, prefix the image file name with qcow2:

vmctl create qcow2:obsd64-base.qcow2 -s 10G

--OR--

You can also use the qemu-img utility (from qemu in the package repository) to convert an existing raw image to qcow2 format, if you've already been using VMM before OpenBSD 6.4 was released. This image file will not be dynamically sized, but it can serve as a base image for derivatives:

qemu-img convert obsd64.img obsd64-base.qcow2

Start the VM using your bsd.rd as the boot image, then follow the installer prompts.

doas vmctl start obsd64-base -n local -m 512m -d obsd64-base.qcow2 -b /bsd.rd -c

When the install is done, rebooting will just bring the installer back. Exit to shell instead, type "halt -p" and use the ~. command sequence to exit the VM. Anything else you press will probably reboot the system (back into the installer). Now you have a pristine, freshly-installed OpenBSD image to start from.

To create a derived image, select your base image with the -b option to vmctl create:

vmctl create qcow2:obsd64-test1.qcow2 -b obsd64-base.qcow2

WARNING: If you make any changes to the base image, all derived image files it was based on will become corrupt and unusable. You can remove write access to the base image if you want. The VMs relying on derived images will run fine.

chmod 400 obsd64-base.qcow2

Now, create a VM in /etc/vm.conf with the new obsd64-test1.qcow2 image file. All changes will be stored in this new image file. The original filesystem image will remain unchanged, and you can make as many derived images as you want from it.

# bridge0 for VMs, NAT and dhcpd (required for networking in this example)

switch "local" {

interface bridge0

}

# OpenBSD Stable

vm "test.vm" {

disable

owner axon

memory 512M

disk "/home/axon/vmm/obsd64-test1.qcow2"

interface {

switch "local"

lladdr fe:e1:ba:d0:eb:ab

}

Reload vmm's configuration:

doas vmctl reload

Then go ahead and boot it up with the console attached:

vmctl start test.vm -c

For snapshot-like functionality, you can make a copy of your derived image and save it with another file name in the same directory. You should shut down the VM before you do this, though. To restore, just copy it back over the derived image, or create a new vm clause in /etc/vm.conf pointing to your saved derived image file.

cp obsd64-test1.qcow2 snapshot-2018-11-01_obsd64-test1.qcow2

You can run multiple VMs at the same time, with different derived images from the base image as well. If I create a new derived image file and add a vm clause for it, both VMs can run at the same time.

vmctl create qcow2:obsd64-test2.qcow2 -b obsd64-base.qcow2

I added this to /etc/vm.conf:

# OpenBSD test2

vm "test2.vm" {

disable

owner axon

memory 512M

disk "/home/axon/vmm/obsd64-test2.qcow2"

interface {

switch "local"

lladdr fe:e1:ba:d0:eb:ac

}

Reload vmm, and start up your VMs!

doas vmctl reload

vmctl start test.vm

vmctl start test2.vm

You can attach to the consoles of each to see that they're running. Remember that you can use the [RETURN]~. key sequence to exit the console.

vmctl console test.vm

vmctl console test2.vm

New OpenBSD FAQ: Virtualization

noreply@blogger.com (Ax0n) — Tue, 30 Oct 2018 03:19:00 +0000

OpenBSD has, arguably, some of the best officially-maintained documentation of any modern operating system. Solene Rapenne added a new FAQ section for Virtualization that covers getting OpenBSD's VMM hypervisor off the ground, and it gets the basics out of the way pretty well.

The FAQ kind of glosses over the more elaborate network configuration schemes, one of which I covered in Part 2 of my VMM article a while ago, though if you poke around between the FAQ and man pages, you can find pretty much all you need.

There are some new features to VMM which I plan on writing about soon. Stay tuned!

Via Undeadly

HiR Information Report

Self-Hosting a BitWarden-Compatible Password Manager Service

Raspberry Pi Home-Lab IDS with Suricata and Wazuh

Build your home-lab SIEM with Wazuh

Modernizing The HoneyNet: Bringing Community Honey Network Into 2025

Claude Code -- or -- vibe-technical-debt-repayment

The Modernization Journey

Links

OpenBSD Power Management

Understanding apmd

The apm command line utility

sysctl, power management and sensors

Extending battery health with charging optimization

Running your own Wireguard VPN server and Travel Router

OpenBSD Server

Amazon Linux

Debian Linux

Generating Public and Private Keys

Final Setup and starting the server

OpenBSD

Linux

Travel Router Configuration

Interface

Peer

November 2023 SecKC Presentation: Mobile SDR

Introducing NEMO for the M5Stick C Plus

Running a Kubernetes Cluster with OpenBSD VMM

What's the point?

Caveat Emptor

VMM Vs. The World

Conventions

Minimum System Requirements

Installing OpenBSD

Networking the OpenBSD host and the VMM Guests

Two ethernet interfaces

doas sh /etc/netstart bnx1

–or – Single ethernet interface

VM Bridge

Set up NFS

Create Template VM

Directory setup

Configure VMD’s virtual switch

Enable and start vmd

Download alpine-virt ISO image

Create template VM disk image

Boot the template vm

Install Alpine Linux

Reboot into the template VM

Set up the basic software

Clone Template VM

Bootstrap the master node

Set the host name and machine-id

Install k8s management tools

Initialize Kubernetes

Install Flannel CNI plugin.

Worker Nodes

Set the host name and machine-id

Rinse, Repeat

Behold, your Kubernetes cluster

Basic kubectl commands

K9S Navigation

Troubleshooting with K9S

Provision NFS Storage

Make a directory

Create configuration files

Deploy with Kubectl

Deploy MetalLB Load Balancer

Make a directory

Install MetalLB with kubectl

Configure Load Balancer IP Addresses

Apply the configuration

Deploy WordPress

Add the Bitnami Helm Repository

Configure Wordpress

Install Wordpress with Helm

Dedicated page for Multi-Booting Windows 10 and OpenBSD

OpenBSD 6.9 Released, PHP/MySQL Page updated

Review: OpenBSD 6.8 on 8th Gen Lenovo ThinkPad X1 Carbon 13.3"

The bad news

The resolution is just too high.