💾 Archived View for perso.pw › blog › rss.xml captured on 2024-06-16 at 12:19:30.
⬅️ Previous capture (2024-05-26)
-=-=-=-=-=-=-
<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Solene'%</title>
<description></description>
<link>gemini://perso.pw/blog/</link>
<atom:link href="gemini://perso.pw/blog/rss.xml" rel="self" type="application/rss+xml" />
<item>
<title>OpenBSD extreme privacy setup</title>
<description>
<![CDATA[
<pre># Introduction
This blog post explains how to configure an OpenBSD workstation with extreme privacy in mind.
This is an attempt to turn OpenBSD into a Whonix or Tails alternative, although if you really need that level of privacy, use a system from this list and not the present guide. It is easy to spot OpenBSD using network fingerprinting, this can not be defeated, you can not hide the fact you use OpenBSD to network operators.
I did this guide as a challenge for fun, but I also know some users have a use for this level of privacy.
Note: this guide explains steps related to increase privacy of OpenBSD and its base system, it will not explain how to configure a web browser or how to choose a VPN.
# Checklist
OpenBSD does not have much network activity with a default installation, but the following programs generate traffic:
127.0.0.9 firmware.openbsd.org
## Packages, firmware and mirrors The firmware installation and OpenBSD mirror configuration using Tor and I2P are covered in my previous article, it explains how to use tor or i2p to download firmware, packages and system sets to upgrade. => https://dataswamp.org/~solene/2024-05-25-openbsd-privacy-friendly-mirror.html OpenBSD privacy-friendly mirrors There is a chicken / egg issue with this though, on a fresh install you have neither tor nor i2p, so you can not download tor or i2p packages through it. You could download the packages and their dependencies from another system and install them locally using USB. Wi-Fi and some other devices requiring a firmware may not work until you run fw_update, you may have to download the files from another system and pass the network interface firmware over a USB memory stick to get network. A smartphone with USB tethering is also a practical approach for downloading firmware, but you will have to download it over clearnet. ## DNS DNS is a huge topic for privacy-oriented users, I can not really recommend a given public DNS servers because they all have pros and cons, I will use 1.1.1.1 and 9.9.9.9 for the example, but use your favorite DNS. Enable the daemon unwind, it is a local DNS resolver with some cache, and supports DoT, DoH and many cool features. Edit the file `/etc/unwind.conf` with this configuration:
forwarder { 1.1.1.1 9.9.9.9 }
As I said, DoT and DoH is supported, you can configure it directly in the forwarder block, the man page explains the syntax: => https://man.openbsd.org/unwind.conf OpenBSD manual pages: unwind.conf Now, enable, start and make sure the service is running fine:
rcctl enable unwind
rcctl start unwind
rcctl check unwind
A program named `resolvd` is running by default, when it finds that unwind is running, resolvd modifies `/etc/resolv.conf` to switch DNS resolution to 127.0.0.1, so you do not have anything to do. ## Firewall configuration A sane firewall configuration for workstations is to block all incoming connections. This can be achieved with the following `/etc/pf.conf`: (reminder, last rule matches)
set block-policy drop
set skip on lo
match in all scrub (no-df random-id max-mss 1440)
antispoof quick for egress
block
pass out quick inet
pass out quick inet6
pass in proto icmp
Reload the rules with `pfctl -f /etc/pf.conf`. ## Network configuration Everything is ready so you can finally enable networking. You can find a list of network interfaces with `ifconfig`. Create the hostname.if file for your network device. => https://man.openbsd.org/hostname.if OpenBSD manual pages: hostname.if An ethernet device configuration using DHCP would look like this
inet autoconf
A wireless device configuration would look like this:
join SSID_NAME wpakey password1
join OTHER_NET wpakey hunter2
inet autoconf
You can randomize your network device MAC address at each boot by adding the line `lladdr random` to its configuration file. Start the network with `sh /etc/netstart ifname`. # Special attention during updates When you upgrade your OpenBSD system from a release to another or to a newer snapshot using `sysupgrade`, the command `fw_update` will automatically be run at the very end of the installer. It will bypass any `/etc/hosts` changes as it runs from a mini root filesystem, if you do not want `fw_update` to be used over clearnet at this step, the only method is to disable network at this step, which can be done by using `sysupgrade -n` to prepare the upgrade without rebooting, and then:
mv /etc/hostname.* /root/
sysupgrade -n
echo 'mv /root/hostname.* /etc/' > /etc/rc.firsttime
echo 'sh /etc/netstart' >> /etc/rc.firsttime
chmod +x /etc/rc.firsttime
reboot
It will move all your network configuration in `/root/`, run sysupgrade, and configure the next boot to restore the hostname files back to place and start the network.
# Webcam and Microphone protection
By default, OpenBSD "filters" webcam and microphone use, if you try to use them, you get a video stream with a black background and no audio on the microphone. This is handled directly by the kernel and only root can change this behavior.
To toggle microphone recording, change the sysctl `kern.audio.record` to 1 or 0 (default).
To toggle webcam recording, change the sysctl `kern.video.record` to 1 or 0 (default).
What is cool with this mechanism is it makes software happy when they make webcam/microphone a requirement, they exist but just record nothing.
# Conclusion
Congratulations, you achieved a high privacy level with your OpenBSD installation! If you have money and enough trust in some commercial services, you could use a VPN instead (or as a base) of Tor/I2P, but it is not in the scope of this guide.
I did this guide after installing OpenBSD on a laptop connected to another laptop doing NAT and running Wireshark to see exactly what was leaking over the network. It was a fun experience.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/openbsd-privacy-setup.gmi</guid>
<link>gemini://perso.pw/blog//articles/openbsd-privacy-setup.gmi</link>
<pubDate>Mon, 10 Jun 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>OpenBSD mirror over Tor / I2P</title>
<description>
<![CDATA[
<pre># Introduction
For an upcoming privacy related article about OpenBSD I needed to setup an access to an OpenBSD mirror both from a Tor hidden service and I2P.
The server does not contain any data, it only act as a proxy fetch files from a random existing OpenBSD mirror, so it does not waste bandwidth mirroring everything, the server does not have the storage required anyway. There is a little cache to keep most requested files locally.
=> https://en.wikipedia.org/wiki/I2P Wikipedia page about I2P protocol
=> https://en.wikipedia.org/wiki/The_Tor_Project Wikipedia page about Tor
It is only useful if you can not reach OpenBSD mirrors, or if you really need to hide your network activity. Tor or I2P will be much slower than connecting to a mirror using HTTP(s).
However, as they exist now, let me explain how to start using them.
# Tor
Using a client with tor proxy enabled, you can reach the following address to download installers or sets.
=> http://kdzlr6wcf5d23chfdwvfwuzm6rstbpzzefkpozp7kjeugtpnrixldxqd.onion/pub/OpenBSD/ OpenBSD onion mirror over Tor
If you want to install or update your packages from tor, you can use the onion address in `/etc/installurl`. However, it will not work for sysupgrade and syspatch, and you need to export the variable `FETCH_CMD="/usr/local/bin/curl -L -s -q -N -x socks5h://127.0.0.1:9050"` in your environment to make `pkg_*` programs able to use the mirror.
To make sysupgrade or syspatch able to use the onion address, you need to have the program `torsocks` installed, and patch the script to use torsocks:
[MIRROR]
type = client
address = 127.0.0.1
port = 8080
destination = 2st32tfsqjnvnmnmy3e5o5y5hphtgt4b2letuebyv75ohn2w5umq.b32.i2p
destinationport = 8081
keys = mirror.dat
Now, enable and start i2pd with `rcctl enable i2pd && rcctl start i2pd`. After a few minutes to let i2pd establish tunnels, you should be able to browse the mirror over i2p using the address `http://127.0.0.1:8080/`. You can configure the port 8080 to another you prefer by modifying the file `tunnels.conf`. You can use the address `http://127.0.0.1:8080/pub/OpenBSD/` in `/etc/installurl` to automatically use the I2P mirror for installing/updating packages, or keeping your system up to date with syspatch/sysupgrade. Note: from experience the I2P mirror works fine to install packages, but did not play well with fw_update, syspatch and sysupgrade, maybe because they use ftp command that seems to easily drop the connection. Downloading the files locally using a proper HTTP client supporting transfer resume would be better. On the other hand, this issue may be related to the current attack the I2P network is facing as of the time of writing (May 2024). # Firmware mirror OpenBSD pulls firmware from a different server than the regular mirrors, the address is `http://firmware.openbsd.org/firmware/`, the files on this server are signed packages, they can be installed using `fw_update $file`. Both i2p and tor hidden service hostname can be reused, you only have to change `/pub/OpenBSD/` by `/firmware/` to browse the files. The proxy server does not cache any firmware, it directly proxy to the genuine firmware web server. They are on a separate server for legal matter, it seems to be a grey area. ## Disable firmware.openbsd.org For maximum privacy, you need to neutralize `firmware.openbsd.org` DNS lookup using a hosts entry. This is important because `fw_update` is automatically used after a system upgrade (as of 2024). In `/etc/hosts` add the line:
127.0.0.9 firmware.openbsd.org
The IP in the snippet above is not a mistake, it will avoid fw_update to try to connect to a local web server if any. ## Tor access If you use tor, it is complicated to patch `fw_update` to use torsocks, the best method is to download the firmware manually. => http://kdzlr6wcf5d23chfdwvfwuzm6rstbpzzefkpozp7kjeugtpnrixldxqd.onion/firmware/ Firmware onion address ## I2P access If you use i2p, you can reuse the tunnel configuration described in the I2P section, and pass the full url to `fw_update`:
fw_update -p http://127.0.0.1:8080/firmware/$(uname -r)/
fw_update -p http://127.0.0.1:8080/firmware/snapshots/
Or you can browse the I2P url using an http client with the i2p proxy to download the firmware manually.
=> http://2st32tfsqjnvnmnmy3e5o5y5hphtgt4b2letuebyv75ohn2w5umq.b32.i2p:8081/firmware/ Firmware i2p address
# Conclusion
There were no method to download OpenBSD files over Tor and I2P for people really needing it, it is now a thing.
If you encounter issues with the service, please let me know.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/openbsd-privacy-friendly-mirror.gmi</guid>
<link>gemini://perso.pw/blog//articles/openbsd-privacy-friendly-mirror.gmi</link>
<pubDate>Sat, 25 May 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>Improve your SSH agent security</title>
<description>
<![CDATA[
<pre># Introduction
If you are using SSH quite often, it is likely you use an SSH agent which stores your private key in memory so you do not have to type your password every time.
This method is convenient, but it comes at the expense of your SSH key use security, anyone able to use your session while the agent holds the key unlocked can use your SSH key. This scenario is most likely to happen when using a compromised build script.
However, it is possible to harden this process at a small expense of convenience, make your SSH agent ask for confirmation every time the key has to be used.
# Setup
The tooling provided with OpenSSH comes with a simple SSH agent named `ssh-agent`. On OpenBSD, the agent is automatically started and ask to unlock your key upon graphical login if it finds a SSH key in the default path (like `~/.ssh/id_rsa`).
Usually, the method to run the ssh-agent is the following. In a shell script defining your environment at an early stage, either your interactive shell configuration file or the script running your X session, you use `eval $(ssh-agent -s)`. This command runs ssh-agent and also enable the environment variables to make it work.
Once your ssh-agent is correctly configured, it is required to add a key into it, now, here are two methods to proceed.
## OpenSSH ssh-add
In addition to ssh-agent, OpenSSH provides ssh-add to load keys into the agent. It is simple of use, just run `ssh-add /path/to/key`.
=> https://man.openbsd.org/ssh-add ssh-add manual page
If you want to have a GUI confirmation upon each SSH key use, just add the flag `-c` to this command line: `ssh-add -c /path/to/key`.
In OpenBSD, if you have your key at a standard location, you can modify the script `/etc/X11/xenodm/Xsession` to change the first occurrence of `ssh-add` by `ssh-add -c`. You will still be greeting for your key password upon login, but you will be asked for each of its use.
## KeepassXC
It turns out the password manager KeepassXC can hold SSH keys, it works great for having used for a while. KeepassXC can either store the private key within its database or load a private key from the filesystem using a path and unlock it using a stored password, the choice is up to you.
You need to have the ssh-agent variables in your environment to have the feature work, as KeepassXC will replace ssh-add only, not the agent.
KeepassXC documentation has a "SSH Agent integration" section explaining how it works and how to configure it.
=> https://keepassxc.org/docs/ KeepassXC official documentation
In the key settings and "SSH Agent" tab, there is a checkbox to ask user confirmation upon each key use.
# Other security features
## Timeout
I would recommend to automatically delete the key from the agent after some time, this is especially useful if you do not actively use your SSH key.
In `ssh-add`, this can be achieved using `-t time` flag (it's tea time, if you want to remember about it), where time is a number of seconds or a time format specified in sshd_config, like 5s for 5 seconds, 10m for 10 minutes, 16h for 16 hours or 2d for 2 days.
In KeepassXC, it's in the key settings, within the SSH agent tab, you can configure the delay before the key is removed from the agent.
# Conclusion
The ssh-agent is a practical software that ease the use of SSH keys without much compromise with regards to security, but some extra security could be useful in certain scenarios, especially for developers running untrusted code as their user holding the SSH key.
While the extra confirmation could still be manipulated by a rogue script, it would come with a greater complexity at the cost of being spotted more easily. If you really want to protect your SSH keys, you should use them from a hardware token requiring a physical action to unlock it. While I find those tokens not practical and expensive, they have their use and they can not be beaten by a pure software solution.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/ssh-agent-security-enhancement.gmi</guid>
<link>gemini://perso.pw/blog//articles/ssh-agent-security-enhancement.gmi</link>
<pubDate>Mon, 27 May 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>Organize your console with tmuxinator</title>
<description>
<![CDATA[
<pre># Introduction
This article is about the program tmuxinator, a tool to script the generation of tmux sessions from a configuration file.
=> https://github.com/tmuxinator/tmuxinator tmuxinator official project website on GitHub
This program is particularly useful when you have repeated tasks to achieve in a terminal, or if you want to automate your tmux session to save your fingers from always typing the same commands.
tmuxinator is packaged in most distributions and requires tmux to work.
# Configuration
tmuxinator requires a configuration file for each "session" you want to manage with it. It provides a command line parameter to generate a file from a template:
$ tmuxinator new name_here
By default, it will create the yaml file for this project in `$HOME/.config/tmuxinator/name_here.yml`, if you want the project file to be in a directory (to make it part of a versioned project repository?), you can add the parameter `--local`. # Real world example Here is a tmuxinator configuration file I use to automatically do the following tasks, the commands include a lot of monitoring as I love watching progress and statistics:
name: dpb
root: ~/
on_project_start: cd /usr/ports && doas -u solene git pull -r
windows:
- dpb:
layout: tiled
panes:
- dpb:
- cd /root/packages/packages
- ./dpb.sh -P list.txt -R
- watcher:
- cd /root/logs
- ls -altrh locks
- date
- while true ; do clear && env CCACHE_DIR=/build/tmp/pobj/.ccache/ ccache -s ; sleep 5 ; done
- while true ; do df -h /build/tmp/pobj_mfs/ | grep % ; sleep 10 ; done
- top
- top -U _pbuild
# Going further
Tmuxinator could be used to ssh into remote servers, connect to IRC, open your email client, clean stuff, there are no limits.
This is particularly easy to configure as it does not try to run commands, but only send the keys to each tmux panes, which mean it will send keystrokes like if you typed them. In the example above, you can see how the pane "dpb" can cd into a directory and then run a command, or how the pane "watcher" can run multiple commands and leave the shell as is.
# Conclusion
I knew about tmuxinator for a while, but I never gave it a try before this week. I really regret not doing it earlier. Not only it allows me to "script" my console usage, but I can also embed some development configuration into my repositories. While you can use it as an automation method, I would not rely too much on it though, it only types blindly on the keyboard.
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/potw-tmuxinator.gmi</guid>
<link>gemini://perso.pw/blog//articles/potw-tmuxinator.gmi</link>
<pubDate>Mon, 20 May 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>What is going on in Nix community?</title>
<description>
<![CDATA[
<pre># Introduction
You may have heard about issues within the Nix/NixOS community, this blog post will try to help you understand what is going on.
Please note that it is hard to get a grasp of the big picture, it is a more long term feeling that the project governance was wrong (or absent?) and people got tired.
This blog posts was written with my knowledge and feelings, I clearly do not represent the community.
=> https://save-nix-together.org/ Save Nix Together: an open letter to the NixOS foundation
=> https://xeiaso.net/blog/2024/much-ado-about-nothing/ Xe blog post: Much ado about nothing
There is a maintainer departure milestone in the Nixpkgs GitHub project.
=> https://github.com/NixOS/nixpkgs/milestone/27 GitHub milestone 27: Maintainers leaving
# Project structure
First, it is important to understand how the project works.
Nix (and NixOS, but it is not the core of the project), was developed by Eelco Dolstra early 2000. The project is open source, available on GitHub and everyone can contribute.
Nix is a tool to handle packaging in a certain way, and it has another huge repository (top 10 GitHub repo) called nixpkgs that contains all packages definition. nixpkgs is known to be the most up-to-date repository and biggest repository of packages, thanks to heavy automation and a huge community.
The NixOS foundation (that's the name of the entity managing the project) has a board that steer the project in some direction and handle questions. First problem is that it is known to be slow to act and response.
Making huge changes to Nix or Nixpkgs requires making an RFC (Request For Comment), explaining the rationale behind a change and a consensus has to be found with others to agree (it is somewhat democratic). Eelco decided a while ago to introduce a huge change in Nix (called Flakes) without going through the whole RFC process, this introduced a lot of tension and criticism because they should have gone through the process like every other people, and the feature is half-baked but got some traction and now Nix paradigm was split between two different modes that are not really compatible.
=> https://github.com/NixOS/rfcs/pull/49#issuecomment-659372623 GitHub Pull request to introduce Flakes: Eelco Dolstra mentioning they could merge it as experimental
There are also issues related to some sponsors in the Nix conferences, like companies related to militaries, but this is better explained in the links above, so I will not make a recap.
# Company involvement
This point is what made me leave NixOS community. I worked for a company called Tweag, involved into Nix for a while and paying people to contribute to Nix and Nixpkgs to improve the user experience for their client. This made me realize the impact of companies into open source, and the more I got involved into this, the more I realized that Nix was mostly driven by companies paying developers to improve the tool for business.
Paying people to develop features or fixing bug is fine, but when a huge number of contributors are paid by companies, this lead to poor decisions and conflicts of interest.
In the current situation, Eelco Dolstra published a blog post to remember the project is open source and belong to its contributors.
=> https://determinate.systems/posts/on-community-in-nix/ Eelco Dolstra blog post
The thing in this blog post, that puzzles me, is that most people at Determinate Systems (Eelco co-founded company) are deeply involved into Nix in various way. In this situation, it is complicated for contributors to separate what they want for the project from what their employer wants. It is common for nix contributors to contribute with both hats.
# Conclusion
Unfortunately, I am not really surprised this is happening. When a huge majority of people spending their free time contributing to a project they love and that companies relentlessly quiet their voice, it just can't work.
I hope Nix community will be able to sort this out and keep contributing to the project they love. This is open source and libre software, most affected people contribute because they like doing so, they do not deserve what is happening, but it never came with any guarantees either.
# Extra: Why did I stop using Nix?
I don't think this deserved a dedicated blog post, so here are some words.
From my experience, contributing to Nix was complicated. Sometimes, changes could be committed in minutes, leaving no time for other to review a change, and sometimes a PR could take months or years because of nitpicking and maintainer losing faith.
Another reason I stopped using nix was that it is quite easy to get nixpkgs commit access (I don't have commit access myself, I never wanted to inflict the nix language to myself), a supply chain attack would be easy to achieve in my opinion: there are so many commits done that it is impossible for a trustable group to review everything, and there are too many contributors to be sure they are all trustable.
# Alternative to Nix/NixOS?
If you do not like Nix/NixOS governance, it could be time to take a look at Guix, a Nix fork that happened in 2012. It is a much smaller community than nix, but the tooling, packages set and community is not at rest.
Guix being a 100% libre software project, it does not target MacOS like nix, nor it will include/package proprietary software, however for the second "problem", there is an unofficial repository called guix-nonfree that contains many packages like firmware and proprietary software, most users will want to include this repo.
Guix is old school, people exchange over IRC and send git diff over email, please do not bother them if this is not your cup of tea. On top of that, Guix uses the programming language Scheme (a Lisp-1 language) and if you want to work with this language, emacs is your best friend (try geiser mode!).
=> https://guix.gnu.org/ Guix official project webpage
</pre>
]]>
</description>
<guid>gemini://perso.pw/blog//articles/nix-internal-crisis.gmi</guid>
<link>gemini://perso.pw/blog//articles/nix-internal-crisis.gmi</link>
<pubDate>Sat, 27 Apr 2024 00:00:00 GMT</pubDate>
</item>
<item>
<title>OpenBSD scripts to convert wg-quick VPN files</title>
<description>
<![CDATA[
<pre># Introduction
If you use commercial VPN, you may have noticed they all provide WireGuard configurations in the wg-quick format, this is not suitable for an easy use in OpenBSD.
As I currently work a lot for a VPN provider, I often have to play with configurations and I really needed a script to ease my work.
I made a shell script that turns a wg-quick configuration into a hostname.if compatible file, for a full integration into OpenBSD. This is practical if you always want to connect to a given VPN server, not for temporary connections.
=> https://man.openbsd.org/hostname.if OpenBSD manual pages: hostname.if
=> https://git.sr.ht/~solene/wg-quick-to-hostname-if Sourcehut project: wg-quick-to-hostname-if
# Usage
It is really easy to use, download the script and mark it executable, then run it with your wg-quick configuration as a parameter, it will output the hostname.if file to the standard output.
wg-quick-to-hostname-if fr-wg-001.conf | doas tee /etc/hostname.wg0
In the generated file, it uses a trick to dynamically figure the current default route which is required to keep a non-vpn route to the VPN gateway. # Short VPN sessions When I shared my script on mastodon, Carlos Johnson shared their own script which is pretty cool and complementary to mine. If you prefer to establish a VPN for a limited session, you may want to take a look at his script. => https://gist.github.com/callemo/aea83a8d0e1e09bb0d94ab85dc809675#file-wg-sh Carlos Johnson GitHub: file-wg-sh gist # Prevent leaks If you need your WireGuard VPN to be leakproof (= no network traffic should leave the network interface outside the VPN if it's not toward the VPN gateway), you should absolutely do the following: