diff options
Diffstat (limited to 'htdocs/guide')
| -rw-r--r-- | htdocs/guide/cryptexisting.md | 152 | ||||
| -rw-r--r-- | htdocs/guide/krbnfs.md | 124 | ||||
| -rw-r--r-- | htdocs/guide/ovpnip6.md | 69 | ||||
| -rw-r--r-- | htdocs/guide/wifi103.md | 64 |
4 files changed, 409 insertions, 0 deletions
diff --git a/htdocs/guide/cryptexisting.md b/htdocs/guide/cryptexisting.md new file mode 100644 index 0000000..a77eba2 --- /dev/null +++ b/htdocs/guide/cryptexisting.md @@ -0,0 +1,152 @@ +% Encrypting existing drives + +# Disclaimer +**It is not easily possible to use most of the methods described here +to encrypt existing drives without having to make and restore a backup.** + +# Preparation: Making a backup +It is necessary to create a backup of your drive as encrypting will +erase your data. + +## SquashFS +I like to use SquashFS as I don't have much backup +space: + +```sh +apt update +apt install squashfs-tools + +mksquashfs /media/drive/mountpoint /media/backup/mountpoint/drive.sqsh +``` + +The above commands all need to be run as root. + +A major disadvantage of SquashFS is its slowness. It uses all CPU cores +but still takes a long time to complete depending on how much data is +being squashed. + +## tar +If you can afford to store a raw copy, you can create it with `tar`. +The `tar` command is faster than `cp` or `rsync` for copying many +large files. Here's how to use it: + +```sh +tar -c -C /media/drive/mountpoint . | \ +tar --same-owner -xp -C /media/backup/location +``` + +Make sure you run this as root. + +This is much faster compared to squashing but it requires much more +storage space. + +# Wiping +This is optional but it's highly recommended to do if unencrypted data +used to be stored on the drive. +Some encryption tools such as OS installers do this automatically, but +pure cryptsetup does not. To be safe, wipe manually: + +```sh +dd bs=1M if=/dev/urandom of=/dev/sdX +``` + +Once again only root can do this. + +Replace `/dev/sdX` with the device file of the drive you want to encrypt. +You can specify a partition number if you only want to wipe a single +partition. + +If you're still using an old kernel (<4.8) this is going to be slow. +Replace `/dev/urandom` with `/dev/zero` to counter this. + +# Encrypting +There are three methods I have used. + +## LVM + LUKS +This is recommended for drives with an operating system. + +Do a complete reinstall and select the "encrypted LVM" option when +partitioning. Make sure to use a secure passphrase that you can still +remember. + +This sets up LVM and LUKS. + +## LUKS +Use this for external drives that are always connected to the same +machine. + +Run the following commands as root: + +```sh +cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/sdXY +cryptsetup luksOpen /dev/sdXY sdXY-crypt +mkfs.ext4 /dev/mapper/sdXY-crypt +cryptsetup luksClose sdXY-crypt +``` + +where sdXY is the name of the device file of the partition. + +## VeraCrypt volume +This is useful if you want to use your drive in other places or on +other platforms. Follow the VeraCrypt instructions for this. + +# Restoring the backup +No matter how you made your backup, `tar` is the way to restore it. +Before you do that you have to take care of some other things. + +## SquashFS +Mount the SquashFS image: + +```sh +mount /media/squashfs/location/drive.sqsh /media/backup/mountpoint +``` + +You now need to mount the encrypted device. This is quite easy to do +with VeraCrypt volumes. When you mount one the mountpoint is usually +`/media/veracryptX`. For LUKS it works like this: + +```sh +cryptsetup luksOpen /dev/sdXY sdXY-crypt +mount /dev/mapper/sdXY-crypt /media/drive/mountpoint +``` + +LVM + LUKS is slightly different: + +```sh +cryptsetup luksOpen /dev/sdXY sdXY-crypt +lvchange -ay hostname-vg/partitionname +mount /dev/hostname-vg/partitionname /media/drive/mountpoint +``` + +Now restore the backup: + +```sh +tar -c -C /media/backup/mountpoint . | \ +tar --same-owner -xp -C /media/drive/mountpoint +``` + +# Cleaning up +Now unmount the encrypted volume (if you don't want to use it yet) +and delete the SquashFS. Unmounting VeraCrypt volumes is easy +enough to not be documented here. + +## Unmounting LUKS +```sh +umount /media/drive/mountpoint +cryptsetup luksClose sdXY-crypt +``` + +## Unmounting LVM + LUKS +```sh +umount /media/drive/mountpoint +lvchange -an hostname-vg/partitionname +cryptsetup luksClose sdXY-crypt +``` + +***WARNING: Store the SquashFS image on an encrypted drive +or wipe it securely! A simple `rm` won't do, especially with +solid state storage!*** + +[Return to Guide List](/cgi-bin/guides.lua) + +[Return to Index Page](/cgi-bin/index.lua) diff --git a/htdocs/guide/krbnfs.md b/htdocs/guide/krbnfs.md new file mode 100644 index 0000000..bc388f1 --- /dev/null +++ b/htdocs/guide/krbnfs.md @@ -0,0 +1,124 @@ +% Kerberized NFS: access denied by server while mounting + +# Introduction +Protecting a NFS share with Kerberos is not very easy to do but definitely +doable with a good setup manual. A very helpful website is +https://wiki.ubuntuusers.de although some of the pages +have since been archived. + +# Setup +The hostnames are different in my actual setup and will certainly be +different for you. + +There are two machines involved. The first one is the server. +It's running a krb5 KDC and admin server as well as a NFS server. +The NFS export is configured to allow any source address +but requires krb5i or krb5p security. + +The client computer is running a krb5 client and a NFS client with +the necessary rpc daemons. + +#### Kerberos principals +* admin/admin, has full access to kadmin +* himbeerserverde, a regular user +* host/srv.himbeerserver.de, server host key +* host/clt.himbeerserver.de, client host key +* nfs/srv.himbeerserver.de, server NFS key +* nfs/clt.himbeerserver.de, client NFS key + +The users are synced across other clients and the server using LDAP. +The clients use SSSD to cache credentials. This way they can operate +without a permanent connection to the LDAP server. They also keep working +in case of a server failure. +The server uses local auth for the actual accounts. The other accounts +are not intended to be logged into. A LDAP failure will only result +in a broken NFS. + +I'm aware this isn't the best solution. I'm probably going to come up +with a better one in about half a decade. + +# The Error +This is the command I use to mount the NFS share: + +```sh +sudo mount -t nfs4 -o sec=krb5i,async,soft srv.himbeerserver.de:/media/ssd /mnt/himbeerserverde/nfs +``` + +This suddenly resulted in the above error. I couldn't really figure out +what was going on. This has happened several times and could sometimes be +fixed by rebooting both machines. Unfortunately rebooting didn't help +most of the time. + +# Debugging +The logs are not very helpful for debugging this error. +Adding `-vvvv` to the mount command outputs more but still only shows +that permission was denied, not why it's happening. +Looking at the traffic with wireshark I didn't see any Kerberos packets. + +The syslog eventually lead me to the systemd service `auth-rpcgss-module`. +It failed to start. The reason was a kernel update that had been installed +but not yet activated. Rebooting fixed this by restoring synchronization +of the kernel version and the modules' required kernel version. + +I'm not sure if that module is required but given its name it seems to be. +Reading the krb5 logs (using `journalctl -xeu krb5-kdc.service`) I could +see that the KDC refused to issue service tickets to the server. +There were attempts from the client to get a service ticket earlier that +day that were also denied. In both cases the reason was failing authentication. + +The fact that the server was experiencing the issue made me think that it +was a host authentication issue that had nothing to do with the user. +This later turned out to be correct. + +# The Solution +After spending days googling for a solution and trying different things +I decided to completely reconfigure host-related principals. +Here's exactly what I did: + +Server: +```sh +srv# rm /etc/krb5.keytab +srv# kadmin -p admin/admin +kadmin: purgekeys host/srv.himbeerserver.de +kadmin: purgekeys nfs/srv.himbeerserver.de +kadmin: delprinc host/srv.himbeerserver.de +kadmin: delprinc nfs/srv.himbeerserver.de +kadmin: addprinc -randkey host/srv.himbeerserver.de +kadmin: addprinc -randkey nfs/srv.himbeerserver.de +kadmin: ktadd host/srv.himbeerserver.de +kadmin: ktadd nfs/srv.himbeerserver.de +kadmin: quit +srv# systemctl restart nfs-kernel-server rpc-gssd rpc-svcgssd +``` + +It's important to restart rpc-gssd to make it reload the keytab. +I'm not sure if restarting rpc-svcgssd is necessary. +Purging the user keys is *probably* not needed either but you can +do it if the above steps didn't work. + +Client (repeat for all affected clients with the corresponding keys): +```sh +clt# rm /etc/krb5.keytab +clt# kadmin -p admin/admin +kadmin: purgekeys host/clt.himbeerserver.de +kadmin: purgekeys nfs/clt.himbeerserver.de +kadmin: delprinc host/clt.himbeerserver.de +kadmin: delprinc nfs/clt.himbeerserver.de +kadmin: addprinc -randkey host/clt.himbeerserver.de +kadmin: addprinc -randkey nfs/clt.himbeerserver.de +kadmin: ktadd host/clt.himbeerserver.de +kadmin: ktadd nfs/clt.himbeerserver.de +kadmin: quit +clt# systemctl restart rpc-gssd +``` + +Once again purging the user keys is *probably* not needed but you +can do it if the above steps didn't work. + +Now mount the NFS share again. If it still doesn't work, reboot +the server and the client. If that doesn't fix it unfortunately +I can't help you. + +[Return to Guide List](/cgi-bin/guides.lua) + +[Return to Index Page](/cgi-bin/index.lua) diff --git a/htdocs/guide/ovpnip6.md b/htdocs/guide/ovpnip6.md new file mode 100644 index 0000000..10921d5 --- /dev/null +++ b/htdocs/guide/ovpnip6.md @@ -0,0 +1,69 @@ +% Setting up OpenVPN IPv6 support + +# The different kinds of IPv6 support +OpenVPN supports IPv6 in two different ways. It can listen on +an IPv6 socket so that IPv6 clients can connect to it. +This way you can run OpenVPN servers that are IPv6 only. + +This does not allow connected clients to access hosts via IPv6. +In order to achieve that the server needs to assign addresses +that are routable on the internet. + +# Listening on an IPv6 socket +This is quite easy to set up. Open your `/etc/openvpn/server.conf` +and append a 6 to the proto line. For example `proto udp` +becomes `proto udp6`. + +# Assigning addresses from a prefix +The OpenVPN server can assign IPv6 addresses from a prefix. +I recommend a /64 subnet, but OpenVPN supports smaller prefixes +such as /112 as well. If you have a bigger subnet such as /60 +you can make it a /64 by filling it up with zeros. + +To enable this feature add this to your `/etc/openvpn/server.conf`: + +``` +server-ipv6 2001:db8:0:123::/64 +``` + +## Static addresses +*WARNING: If you're using the client config dir to set static IPv4 +addresses you have to set static IPv6 addresses as well:* + +``` +ifconfig-ipv6-push 2001:db8:0:123::abcd/64 2001:db8:0:123::1 +``` + +where `abcd` is the IFID you'd like the client to get. + +## Pushing routes +Now we have to route IPv6 traffic through the tunnel. +Traffic to the subnet of GUAs (2000::/3) always has to be routed +through the tunnel. If you have an ULA prefix or anything else +you'd like to go through the tunnel simply add another +line to the config and use that prefix. + +Add this to `/etc/openvpn/server.conf`: + +``` +push "route-ipv6 2000::/3" +``` + +# Routing +The OpenVPN IPv6 prefix either needs to be NATed or routed. +If it's a subnet of the IPv6 prefix assigned by your ISP +everything should work right away. Otherwise you have to configure +IPv6 NAT which is a dirty solution but should work. + +# Firewall +Don't forget to protect the OpenVPN IPv6 subnet with a firewall. +This is NOT a security issue of IPv6, IPv4 needs a firewall too. + +You can allow certain requests to go through. This way you can +"forward" IPv6 ports from a location that supports it to another +location that doesn't support it but is connected to the OpenVPN +server. + +[Return to Guide List](/cgi-bin/guides.lua) + +[Return to Index Page](/cgi-bin/index.lua) diff --git a/htdocs/guide/wifi103.md b/htdocs/guide/wifi103.md new file mode 100644 index 0000000..d929c28 --- /dev/null +++ b/htdocs/guide/wifi103.md @@ -0,0 +1,64 @@ +% rtl8812au WiFi driver setup on RPi@5.10.103-v7l + +# The Problem +WiFi drivers on Linux are already annoying enough, and it's gotten even worse +with the 5.10.103 kernel. This version is no longer compatible with the +[install-wifi script](http://downloads.fars-robotics.net/wifi-drivers/install-wifi). +On top of that some versions of the rtl8812au driver I'm using drop IPv6 Multicast, +breaking NDP and preventing you from automatically connecting to the IPv6 internet. +Fortunately aircrack-ng maintains a working version of the driver. However it has +to be compiled from source. Here's how. + +# Kernel Headers +You may need to install the raspberry pi kernel headers. +The apt package name is `raspberrypi-kernel-headers`. +If you're using the 64-bit RPi OS, make sure to install +the arm64 version of the package. +Use `apt list raspberrypi-kernel-headers` to check if you have +the correct version installed. + +# Installing +Run the following shell commands. If you aren't using sudo, run commands that +require root access in some other way. + +```sh +sudo apt update && sudo apt install -y git dkms + +git clone https://github.com/aircrack-ng/rtl8812au.git +cd rtl8812au/ + +sed -i 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/g' Makefile +sed -i 's/CONFIG_PLATFORM_ARM_RPI = n/CONFIG_PLATFORM_ARM_RPI = y/g' Makefile +export ARCH=arm +sed -i 's/^MAKE="/MAKE="ARCH=arm\ /' dkms.conf + +sudo make dkms_install +``` + +**For 64-bit, these are the commands to run:** + +```sh +sudo apt update && sudo apt install -y git dkms + +git clone https://github.com/aircrack-ng/rtl8812au.git +cd rtl8812au/ + +sed -i 's/CONFIG_PLATFORM_I386_PC = y/CONFIG_PLATFORM_I386_PC = n/g' Makefile +sed -i 's/CONFIG_PLATFORM_ARM64_RPI = n/CONFIG_PLATFORM_ARM64_RPI = y/g' Makefile +export ARCH=arm64 +sed -i 's/^MAKE="/MAKE="ARCH=arm64\ /' dkms.conf + +sudo make dkms_install +``` + +If the last command gives an error because the DKMS module already exists, +remove any existing installations of the driver. + +# Loading +The driver should now automatically be loaded. It seems to be +loaded at boot time automatically, but I haven't tested it yet. +If you can confirm or disprove this please let me know. + +[Return to Guide List](/cgi-bin/guides.lua) + +[Return to Index Page](/cgi-bin/index.lua) |