Building a Privacy Box (with a Raspberry Pi)

Privacy for you Internet access plus a monitor for your devices, a Wi-Fi/LAN intruder detector and a VPN Server for remote access with a Raspberry Pi + Bonus Track: a Password Manager

Building a Privacy Box with a Raspberry Pi © 2022 by Daniel Alomar is licensed under CC BY-NC-SA 4.0. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/4.0/

You can dowload a PDF of this article here: BuildingPrivacyBox

Changelog

  • 20230103 – Added Netdata as a monitoring solution recommended instead RPi-monitor

Index

  1. Introduction
  2. Objective
  3. Requirements
  4. Setup of the Privacy Box
  5. Installing WireGuard (light, secure and fast VPN)
  6. Installing Pi.Alert, a Wi-Fi/LAN intruder detector (optional)
  7. Installing a monitoring tool (optional)
  8. Securing the Raspberry
  9. Backup and restore
  10. Bonus track. Password manager: Vaultwarden
  11. Bibliography

Introduction

Background

In these uncertainty and strange times we are living – it seems to be – forever, we should take care of our privacy. The saying “if you are not paying for it, then you are the product”1,2 it is absolutely true.

We have not been trained at school in the use of Information and Communications Technologies (ICT). Most of us are not digital natives, and even if we were, the evolution of technology is faster than the speed of adaptation of training. Those of us who are lucky enough to like technology and to be early adapters of it, we have ‘somewhat less difficult’, like an intuition, to manage ICT, but that does not mean we are safe from the dangers of exposing our lives to the Internet, where different companies are on the lookout to collect our data in order to create the most reliable profile they can from us, a detailed description of our tastes, our preferences, our habits… they know us much better than we know ourselves, and that is not a cliché, it is a reality.

This data is collected by companies called Data Brokers3 through multiple techniques. The data is used to create profile of us to different purposes, like marketing and advertising, risk-mitigation, people-search services4,5, etc…. Regarding marketing and advertising, while this could sound nice for someone who wants to have personalizing advertisements, we have to know some side effect, such as the price not being the same for everyone, and other worse effects. Since companies have a wide information from us, better than us, they will know also our risks and the potential collateral effects from our habits. All this information let us calculate, with a high accuracy, prices for the services or products we want to acquired or advertisements we see. For example, the price for a health insurance will not the same if the company knows, through the information from us acquired from the Data Brokers. The same apply to the advertisements we see in our devices. Here you have an example from Signal: https://signal.org/blog/the-instagram-ads-you-will-never-see/

It is common to hear someone say: “I do not care about privacy concerns. I do not have nothing to hide”… The quick answer you could provide, with a smile on your face: “If you do not have nothing to hide, then you can give me your email password…”. For sure he/she will not, so EVERYONE have some information to protect.

What is a Privacy Box

What I call Privacy Box is a device that will provide privacy to your Internet access. Various tools are installed and configured within this device. It will block advertisements, through the pi-hole application, to all your network and for all kind of devices without to have to install software on each one. With unbound we are going to have a validating, recursive, and caching DNS resolver locally. This means that our Internet Service Providers (ISP) will not see what we are searching for, the Domain Name Resolution will be locale, and even faster, within our Raspberry Pi. Along with the previous tools we will also add WireGuard, a VPN Server that will alow us a remote and secure connection to our network and continue provide privacy when we are outside our local network.

All this functionalities are going to be installed inside a Raspberry Pi device in order to have it running 24×7 at low cost.

The main characteristics of the privacy box are:

  • Blocking unwanted contend to all devices connected, without installing any client-side software (Pi-hole)
  • Network-wide protection (Pi-hole)
  • Improve network performance (Pi-hole)
  • Secure open-source recursive DNS server for local resolution (unbound)
  • Network intrude detector (Pi.Alert)
  • Device monitoring (RPI-Monitor)
  • Secure and remote access through a VPN (WireGuard)

As a bonus track I have added a tutorial to setup a raspberry pi to host a password manager and how to access it from Internet. I have choose Vaultwarden, based on the well know solution Bitwarden. Due to technical reasons, it is easier to run this server on another raspberry pi. You can try to setup on the same device where you have Pi-hole, but I will not recommend you.

If you do not have enough technological knowledge to follow this guide and build this Privacy Box for yourself, ask a friend with more knowledge in technology (maybe a geek) to help you to setup it. Those of us who are techies love to help others. My will has been to create a very simple tutorial, with step-by-step instructions, explaining the reason for each step so that we can understand what we are doing.

Before starting, I will like to thanks Mr.Smashy (@THESMASHY) who wrote a guide6, origin and source of inspiration of this one.

Note 1: Commands are identified using a different text style framed within a grey box like this:

$ls -l

The command will start with a $ or # symbol. That means the command is executed without administrator privileges ($ symbol) or with administrator privileges (# symbol). To elevate privileges (from $ to #) we must run ‘sudo -s’ command or start the command with sudo. In both cases you will need the administrator password. Examples:

$sudo -s
#

Running ls command with elevated privileges

$sudo ls -l

Objective

As I mention in the previous section, I am going to show also how to set up a password manager. This tool it will installed on another Raspberry Pi device.

Requirements

This is the list of requirements:

  • Raspberry Pi 3 Model B (or higher)
  • Computer to write the image and connect to the Raspberry to configure it
  • SD Card or USB memory stick (capacity: 16 GB or higher)
  • Internet connection
  • Basic knowledge of computers or have a geek friend on hand
  • Power supply
  • Curiosity
  • Time

Note 1: Regarding the computer, I have used my laptop with GNU/Linux (Manjaro flavour) to write the image and connect to the Raspberry, so the commands you will see belongs to the GNU/Linux operating system. The remaining instructions are independent of the operating system you use. If you are a Windows or Mac user, you will find several alternatives easily on Internet to write the image to the SD Card or USB stick and connect to the Raspberry.

Note 2: Whether to choose SD Card or USB memory stick? People says the lifetime of a SD Card is shorter than the USB memory stick, so many people boot from SD Card and use the USB memory stick (or even a SSD hard drive) to run the operating system. From Raspberry Pi 3 and up the operating system can be booted and run directly from the USB. In this manual I have added some tools to decrease the write cycles to the disk using the RAM memory. Which one to choose? There is not a right answer.. well, yes.. MAKE REGULAR BACKUPS to ensure you have a plan B for any incident related the device.

Setup of the Privacy Box

This section will explain how to setup Pi-hole and unbound plus another optional and recommended tools.

Why I choose Debian instead Raspbian or RaspberryPi OS

There are several reasons why I choose a Debian image instead Raspbian or RaspberryPi OS. The main reason is freedom. Debian is a full GNU/Linux flavour, with no commercial nor propietary software.

A second reason is the incident related with the internal repository files modification without notification Raspbian did in February 20217,8,9. A Microsoft repositoy pointing to a Microsoft server was added secreatly without any notification. The reason was to provide Visual Studio Code for some scenarios. This modification wihout consent crossed the boundaries of (my) trust and make me decide to move to a full open source distribution like Debian. If they changed this without notification, what could they do next time?

Identifying the device

First we have to check which raspberry model we have. If using visual inspection we are not sure, we can do a «logical inspection», asking the device throught a command.

Run the command below will be the first option. The output will be the Raspberry Pi Model

$cat /proc/device-tree/model


In case we have installed Raspbian as operating system, we can run the following command to check the model. It will returns us information from our device:

$rev=$(awk '/^Revision/ { print $3 }' /proc/cpuinfo) && curl -L perturb.org/rpi?rev=$rev

Download and flash an image

Debian image for raspberry pi can be downloader from: https://raspi.debian.net/. For a production environment I would recommend to use a Tested image

Choose the (xz-compressed) image according the hardware you have

Locate where the file was donwloaded and open a console session into that folder. Decompress the image downloaded using the following unxz command:

$unxz 20210823_raspi_3_bullseye.img.xz

You will get a img file. In my case 20210823_raspi_3_bullseye.img

Plug a SD card or USB memory stick into your laptop and flash the image to the device with the following command (sdb is how the SD Card or USB has been identified. Check the partition in your case)

$sudo dd bs=4M if=20210823_raspi_3_bullseye.img of=/dev/sdb conv=fdatasync status=progress

If you have choose to boot and run the operating system from the USB stick, you have to configure the device in order to boot from USB. Setting the boot from USB can be found at Raspberry site10

If you have a RaspberryPi 2 version 1.1 or lower your can only boot from SD but then you switch to the USB.

Configuring remote access with SSH

The secure way to connect to your Raspberry Pi is through a SSH connection. This can be done in two ways:

  1. Using a login and password we set. This will let connect to the device anyone who knows the user and password from anyplace

  2. Using a SSH key, which are more secure. Our public key is stored on the remote machine and a private key is stored on our machine. The two SSH keys are required to make a secure connection

In this guide I will show you how to set the second one.

Enable SSH on Raspberry Pi in headless mode without keys (easy way)

First we have to enable the SSH connection, disabled by default for security reasons.

  1. Turn off the device and remove the card or USB stick

  2. Put the microSD card in the card reader or USB stick into the computer

  3. Create an empty file inside boot partition called SSH

Pre-configuration and enabling ssh remote connection using SSH key

We are going to generate ssh keys on our computer and copy the public key inside sysconf.txt (raspifirm partition)

$ssh-keygen -t rsa


Edit sysconf.txt, uncomment the “root_authorized_key” entry and paste the public key generated in previous step (located at id_rsa.pub file). We can also modify the hostname of the Raspberry (I have chosen Anuk)


Go to the RASPIROOT partition (has this name) and set an static IP address modifying the eth0 file located at the following path: /etc/network/interfaces.d/eth0. Set the IP address you want and the IP of the router gateway (192.168.1.1 in my case). As a DNS we are going to set the cloudflare one (1.1.1.1):

iface eth0 inet static
        address 192.168.1.10
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 1.1.1.1

Create the file /etc/resolv.conf with the content:

nameserver 1.1.1.1

Put the SD Card or USB stick back to the Raspberry Pi and boot it.

Now we can try to connect to the Raspberry using the username root and IP we set.

$ssh root@192.168.1.10

Basic configurations

Setting the host name

Set the hostname at the file /etc/hostname

#nano /etc/hostname

and add a hostname entry to the hosts file (Anuk in my case)

#nano /etc/hosts

In case you are using Raspbian, you can set hostname through raspi-config application

Updating the system

Let’s going to update the system to grab the latest uptades

#apt update && apt-get upgrade -y

Install some additional software stuff we will need

#apt install sudo dnsutils gnupg wget curl git

Adding a non root user

Add a non root user and set a password for it

#adduser daniel


Add user to sudo and video groups

#adduser daniel video
#adduser daniel sudo

Attention: In case we are using a Raspbian OS, the default user is ‘pi’. I will recommend to create another user and remove the default one once you have created the new one with the following command:

$sudo pkill -u pi $sudo deluser -remove-home pi

Lock down the SSH service

Edit the SSH config file. We recommend to use the ssh keys generated previously and disable password access

$nano /etc/ssh/sshd_config

Uncomment the lines of the following image that are in white

and copy-paste the pub key we have generated previously.

$mkdir -p ~/.ssh 
$nano ~/.ssh/authorized_keys

Save changes and exit the editor. Restart SSH:

$sudo service ssh restart

Restart the service We are going to be disconnected in case we were connected through ssh.

$sudo service networking restart

In case you have assigned previously this IP address, you will get this message

Just delete the entry in your know hosts data base:

$nano ~/.ssh/known_hosts

Logout root & login as the new user (daniel in my case)

$ssh daniel@192.168.1.10

Check IP configuration (static IP and DNS configuration)

Seting the time zone

Let’s gone set our time zone. We can check all the timezones listed with the command:

$timedatectl list-timezones

Choose the one that fits you best. In my case I choose Europe/Madrid

$sudo timedatectl set-timezone Europe/Madrid

Once set, I can retrieve the status with the following command:

$timedatectl status

We are going to set the time automatically, using the NTP protocol who help us to change and synchronize periodically the date and time.

$sudo nano /etc/systemd/timesyncd.conf

set NTP to “time.cloudflare.com” and uncomment the FallbackNTP and PollIntervalMaxSec lines

Installing unattended upgrades package (recommended)

To have unattended upgrades, we need to install an additional package

$sudo apt install unattended-upgrades

The configuration of unnattended upgrades is set inside this file:

$sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

You may want to update some settings, I recommend uncomment and change “Unattended-Upgrade::Remove-Unused-Dependencies” to “true”. Exit and save the file.

Basically, we commented out those type of upgrade we want to apply. The second last line allows the system to email us the status. We must install mailutils or mailx first in Raspbian for the email notification to be effective. The last line allow the system to reboot automatically. Please also make sure that update-notifier-common has been installed.

There are more option that we can set such as reboot time and log file in the configuration file. Uncomment any option when necessary.

Create a periodic upgrade file with the following command:

$sudo nano /etc/apt/apt.conf.d/02periodic

And the following content:

// Control parameters for cron jobs by /etc/cron.daily/apt-compat //

// Enable the update/upgrade script (0=disable)
APT::Periodic::Enable "1";

// Do "apt-get update" automatically every n-days (0=disable)
APT::Periodic::Update-Package-Lists "1";

// Do "apt-get upgrade --download-only" every n-days (0=disable)
APT::Periodic::Download-Upgradeable-Packages "1";

// Run the "unattended-upgrade" security upgrade script
// every n-days (0=disabled)
// Requires the package "unattended-upgrades" and will write
// a log in /var/log/unattended-upgrades
APT::Periodic::Unattended-Upgrade "1";

// Do "apt-get autoclean" every n-days (0=disable)
APT::Periodic::AutocleanInterval "7";

// Send report mail to root
// 0: no report (or null string)
// 1: progress report (actually any string)
// 2: + command outputs (remove -qq, remove 2>/dev/null, add -d)
// 3: + trace on
APT::Periodic::Verbose "2";

Check your unattended upgrades by running this command to debug
your configuration:

$sudo unattended-upgrades -d

Installing Fail2Ban (optional)

Fail2ban is an instrusion prevention software designed to prevent against brute-force attacks. Firtst we need to install the package

$sudo apt install fail2ban -y

Fail2ban will block attackers IP if they fail to login after 5 failures for 10 minutes.

Note: Fail2Ban installed from the repository will only provide security on IPv4 protocol. If you want Fail2Ban to support IPv6, please look at this guide.

The configuration of fail2ban is set in the following file:

/etc/fail2ban/jail.conf

If you make any config changes, restart the service via:

sudo service fail2ban restart

If you make any config changes, restart the service via:

sudo service fail2ban restart

In order to recover acces

$ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@your.vps.ip

Installing a firewall (optional)

Install the packages

$sudo apt install ufw

Configuring the firewall

Create your access list to the ports you need

$sudo ufw allow 80
$sudo ufw allow 443
$sudo ufw allow 53
$sudo ufw allow 8888
$sudo ufw allow 22

You can even be more restrictive with extended parameters on the rules, like SSH for example. You can only allow access on port 22 from your computer’s IP address:

$sudo ufw allow from 192.168.1.120 port 22

Enabling the firewall

$sudo ufw enable

To show rules once the firewall is enabled, run the following command:

sudo ufw status verbose

Installing log2ram to expand SSD life (recommended)

SSD Disks, SD Cards and USB sticks have a SSD inside, have a life span determined by the write cycles mainly (times we write something to the disk). To reduce the times we write to the SSD memory, we can derive the writing of the system logs to RAM memory using log2ram. To do that we have to install the log2ram application.

First we need to force a log reduction before to start to use log2ram

$sudo journalctl --vacuum-size=16M

Let’s gonna add the repository where we are going to install the application and his key. Please check the Debian flavour you are using (bullseye in my case)

$sudo echo "deb http://packages.azlux.fr/debian/ bullseye main" | sudo tee /etc/apt/sources.list.d/azlux.list $sudo wget -qO - https://azlux.fr/repo.gpg.key | sudo apt-key add -

Let’s gonna update the system database and install the application.

$sudo apt-get update
$sudo apt install log2ram -y

Once installed we need a reboot

$sudo reboot

Configuring log2ram

We need to configure log2ram to increase the size

$sudo nano /etc/log2ram.conf

Increase the SIZE parameter to 128MB, disable the mail notification and increase the LOG_DISK_SIZE to 200M. Exit and save.


Restart log2ram

$sudo service log2ram restart

And check that log2ram is running.

$df -h

Installing a DDNS service (in case you do not have a static IP address)

To access to your network from outside through a VPN (WireGuard) you will need to know the public IP address of your local network (or a domain name associated). Usually this IP address is dynamic and can change. Static IP addresses are limited in number and are more expensive. One solution is to use a DDNS service. This service provide a free domain that will point to a public IP address. A script will update periodically my public IP to this service, so in case my IP changes, the domain will point to the new IP.

If you have a static public IP address, you can skip this step. I will use duckdns. They have detailed instructions and provide scripts to install to several devices, including raspberry pi.

In our case we are going to create the cron with the sudo command and execute the script at 5 minutes past every hour. I think it is enough update every hour and not every 5 minutes. My script has xiuxiueig.sh as its name since I will be adding more scripts.

$sudo crontab -e

This is how the crontab looks


With crontab guru you can play with different combinations: https://crontab.guru/

Installing and configuring Pi-hole

Now that system is configured and secured, we can install Pi-hole. The install process is very simple, we just to execute the following command and the script downloaded it will start to install the application:

$sudo curl -sSL https://install.pi-hole.net | bash

After some checks, you’ll be greeted with the install screen:

Remember to give a donation to the project if you find useful (I did it)


I recommend to select all the third-party list listed. We can add additional sources later.

Choose the protocols you have in your network

Ensure you have a IP reservation for your raspberry


I will recommend to install the web interface

Let the log enable


When the installation is complete you will get a final screen with some important info. Save this information to access to the Pi-hole server:

Save the admin webpage password in your password manager for now, it should be changed later.

This same info is displayed once you return to the shell, note the command to change the web admin password (pihole -a -p)

Tweaking Pi-hole

To change the privacy setting from Pi-hole application, we have to edit the following file:

$sudo nano /etc/pihole/pihole-FTL.conf 

Set the privacy level and the days to store the queries in the database.

#Which privacy level is used?. More info: https://docs.pi-hole.net/ftldns/privacylevels/
PRIVACYLEVEL=0 
#How long should queries be stored in the database? Setting this to 0 disables the database. Default 365
MAXDBDAYS=30

Installing Unbound

Enhancing Pi-hole Security (optional if we are not fine with Cloudfare DNS)

So now we have a working Pi-hole, but it has minimal blocking and just forwards lookup to Google DNS. We can change our upstream DNS provider, but that is just changing who we trust with our DNS. What if we don’t trust anyone? We can install Unbound and resolve DNS ourselves using root servers to recursively resolve DNS names. A more in depth explanation of how this works can be found here: https://docs.pi-hole.net/guides/dns/unbound/ but essentially Unbound will look up a DNS query by asking TLD servers for DNS in a recursive manner. The benefit is more security; you do not have to trust an upstream provider with your DNS traffic. The drawback is performance for initial lookup, as they need to traverse and this takes time. Pi-hole and Unbound can both be configured with caching, which will help mitigate this for subsequent lookup.

$sudo apt install unbound -y $wget https://www.internic.net/domain/named.root -qO- | sudo tee /var/lib/unbound/root.hints

Creating a configuration for Pi-hole

$sudo nano /etc/unbound/unbound.conf.d/pi-hole.conf

Paste into the file this configuration. This is different than the one in Pi-hole’s documentation. It includes caching configuration that will improve performance.

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0
    
interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

# May be set to yes if you have IPv6 connectivity
    do-ip6: no
    
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no
    
# Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    root-hints: "/var/lib/unbound/root.hints"
    
# Trust glue only if it is within the server's authority
    harden-glue: yes
    
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes
    
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no
    
# Reduce EDNS reassembly buffer size.
    # Suggested by the unbound man page to reduce fragmentation reassembly problems
    edns-buffer-size: 1472
    
# Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    # This refreshes expiring cache entries if they have been accessed with
    # less than 10% of their TTL remaining
    prefetch: yes

    # This attempts to reduce latency by serving the outdated record before
    # updating it instead of the other way around. Alternative is to increase
    # cache-min-ttl to e.g. 3600.
    cache-min-ttl: 0
    serve-expired: yes
    # I had best success leaving this next entry unset.
    # serve-expired-ttl: 3600 # 0 or not set means unlimited (I think)

    # Use about 2x more for rrset cache, total memory use is about 2-2.5x
    # total cache size. Current setting is way overkill for a small network.
    # Judging from my used cache size you can get away with 8/16 and still
    # have lots of room, but I've got the ram and I'm not using it on anything else.
    # Default is 4m/4m
    msg-cache-size: 128m
    rrset-cache-size: 256m

# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1
    
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m
    
# Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

# To get unbound stats (sudo unbound-control stats_noreset)
remote-control:
    control-enable: yes

Let’s gonna check the unbound configuration

$sudo unbound-checkconf


Last step: restart the service

$sudo service unbound restart

Testing Unbound

Now we are going to test unbound, measuring the time it spend to reach a domain, coneixement.info in this example.

As you can see in the second test, the time decrease, since unbound has a cache.


Keeping unbound updated

Let’s setup some cron jobs to keep unbound updated

$sudo crontab -e

Add a new line at the end and paste the following:

01 02 03 */4 * wget -N -O -q /var/lib/unbound/root.hints https://www.internic.net/domain/named.root

Exit and save.

With the -O option we have to tell it the path to store the file. Also the -N will only update it if the remote file is newer than the file you have. The -q option will keep it quiet so it doesn’t dump a bunch of output in your logs needlessly.

The update will be done at 02:01 on day-of-month 3 every 4 months. I think it is not necessary to update more often.

Keeping updated Pi-hole (optional)

Let’s setup some cron jobs to keep Pi-hole updated. In case we want to keep Pi-hole updated, we have to run periodically the ‘pihole -up’ command.

$sudo crontab -e

Paste the following to update every sunday at 2:30 AM

#30 2 * * SUN  pihole -up

Warning: The PiHole team does not recommend updating Pi-hole via cron jobs. Be aware that with the previous configuration your server will update Pi-hole every Sunday via cron, and stay up-to-date on patch notes. If there is a major change, and you don’t want to update, runsudo crontabe -e’ again and comment out the line to update Pi-hole (place a # before the line).

Configuring Pi-hole to use unbound

Login to your Pi-hole admin page at http://pi.hole/admin and use the password you saved from the install. Navigate to Settings, and click on the DNS tab. Uncheck the DNS Servers checked and check custom 1 and enter 127.0.0.1#5335. Click Save button at the bottom of the page.

As things get queried initial performance will be slow but quickly improve because of the caching nature of Pi-hole and the cache that has been configured for Unbound. Here is an example:

If we login into the web interface, we will see some statistics.

And here how the statistics of queries blocked increase over time

Improving our Blocklists (Blacklist, Adlist and Whitelist)

I strongly recommend to understand which kind of block do you want (advertising, telemetry, parental control, NSFW, malware domain, etc..) and add list from each category. Pi-hole comes out-the-box with an optional blocklist (in case we have selected them during the installation process). This list is maintained and updated regularly. In case we want to add additional blocklist, we can check several sources. Firebog is the main reference (The Big Blocklist Collection) of blocklist where we can find several lists separated into categories:

  • Suspicious
  • Advertising
  • Tracking & Telemetry
  • Malicious
  • Other

We can start adding from one to three list from each category you are interested to block, but before starting to add sources, read the points regarding each list from Firebog page. To add a new list, once logged into the Pi-hole web interface, you should to the Adlists option and paste the url list.


If the list has been successfully added, a message like this will appear:In case we have added previously this list, this will be ignored and a warning message like this will appear:Once we have added all the lists, we have to update the internal database to have applied the new blocklists. This can be done running ‘pihole -g’ at the command line or through the web interface, clicking the update button we can find under ‘Update Gravity’.

This will take a while . Be patient. As appear on the screen, do not navigate away from or close the page

Wait until a success message appears

Remember “The more is not always the better”. If you add too much lists, you will get false positives, which implies you will get troubles while you are surfing Internet, being some services inaccessible, unreachable or not fully functional

Some domains should be added to the Whitelist to avoid malfunctions or troubles while browsing.

You can also add domains to the Blacklist or Whitelist (Domains menu). Here you have an example of domains enabled:

For example, if you have problems with gmail icons (does not appear), you should add the domain gstaticadssl.l.google.com to the whitelist.

Removing existing blocklist

To remove the existing blocklist, we have to run this command:

$sudo sqlite3 /etc/pihole/gravity.db "DELETE FROM adlist"

Backup Pi-hole configuration

After all the tuning done, I will recommend to make a backup. This can be done through the web interface, creating a file (steps 1 to 3) that can be imported (4) in the same client or another pi-hole, saving configuration time:

Additional functionalities

Here’s a list of additional functionalities, among others, that Pi-hole can do:

  • Transforming Pi-hole to our DHCP service provider
  • Managing clients and groups
  • Disable blocking
  • Query log to review black and white list, allowing to add or remove from black or whitelist

Installing WireGuard (light, secure and fast VPN)

A light, secure and fast VPN Server to allow remote and secure access.

Introduction

WireGuard is a communication protocol and free and open-source software that implements encrypted virtual private networks (VPNs), and was designed with the goals of ease of use, high speed performance, and low attack surface. It aims for better performance and more power than others VPN Servers like IPsec and OpenVPN. (From the Wikipedia :-))

To install the most recent version of WireGuard, we’ll need packages from the Debian unstable release. Add the Debian unstable release, and pin the Debian unstable priority behind Raspbian stable. This allows us to install packages that are not available in Debian stable, while keeping the “stable” versions of everything else.

Configuring repositories

By default, Raspbian doesn’t trust the Debian package repository. We need to add Debian’s public keys to the trusted set of keys.

$sudo apt-key adv --keyserver http://p80.pool.sks-keyservers.net:80 --recv-keys 04EE7237B7D453EC 648ACFD622F3D138

And

$sudo sh -c "echo 'deb http://deb.debian.org/debian/ unstable main' >> /etc/apt/sources.list.d/unstable.list"

And prevent RPi from using the Debian distro for normal Raspbian packages to avoid conflicts.

$sudo sh -c "printf 'Package: *\nPin: release a=unstable\nPin-Priority: 90\n' >> /etc/apt/preferences.d/limit-unstable"

And

$wget -O - https://ftp-master.debian.org/keys/archive-key-$(lsb_release -sr).asc | sudo apt-key add -

Installing applications

We need some additional stuff along WireGuard, so let’s gonna update the system database

$sudo apt-get update

And install all the packages needed.

$sudo apt-get install wireguard wireguard-dkms wireguard-tools linux-headers-$(uname r) qrencode linux-hearders

Note: In case you are using a raspbian OS, you will need the kernel headers:

$sudo apt-get install raspberrypi-kernel-headers

Set Up and Configuring the WireGuard VPN Server

We are going to configure 2 access, from a phone and from a laptop.

Generating security keys

To ensure that not just anyone gets access to our network and ensure a secure connection, we’ll first need to generate a set of public/private key pairs with the following commands (execute them one line at a time in your RPi):

$sudo su -
#cd /etc/wireguard
#umask 077
#wg genkey | tee server_private_key | wg pubkey > server_public_key
#wg genkey | tee phone_private_key | wg pubkey > phone_public_key
#wg genkey | tee laptop_private_key | wg pubkey > laptop_public_key
#wg genpsk < phone_private_key > phone_preshared_key
#wg genpsk < laptop_private_key > laptop_preshared_key

This is the list of files created:

This is the content of each file (in this particular case, you will get another result)

server_public o7Omx+P/xRTtIAYw04msRW2IU3llreJ/EZ2ZLVeTEA8=
server_private yL3BldjULCz/zqitAReoPLTfDTCM8khZbOV1+g0ZtHg=
phone_public M0bXWPhF/qbDJeKP52gAM+igeR6csNnKf4pWZexYynM=
phone_private 4LGoHHvFUacRvXC19LvMldEKZWsLpY3SupcLg5Dx/V8=
phone_preshared RP37rPp6ARczPuL0j8NDMB41vEOLqHvtSjmVAlPYzoI=
laptop_public PQ1k3QVZoV1OOCKHBG8PGH5XIsakI+44W4aKYp/IKic=
laptop_private IMT6LFk00+iJbRrY0/yWTUnfh/rOb1AHrXtoh/yfV1A=
laptop_preshared CeBp3tPfoDBRX+5qpvugNVajs217nFeeJg3OjJAyomg=

Generating server configuration

We need to create the server configuration:

#nano /etc/wireguard/server.conf

With this content

[Interface]
PrivateKey = 
#SaveConfig = false
ListenPort = 51900
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
### begin phone configuration ###
[Peer]
PublicKey = 
#PresharedKey = 
#AllowedIPs = 10.6.0.2/32
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
### end phone ###
### begin laptop configuration ###
[Peer]
PublicKey = 
#PresharedKey = 
AllowedIPs = 10.6.0.3/32
PersistentKeepalive = 25
### end laptop ###

In case you need to edit the server configuration later, you will have to stop the interface with this command:

#systemctl stop wg-quick@wg0.service

Gotchas

  1. Be sure to replace the key values in the configuration for PrivateKey and PublicKey.

  2. Note that the above configuration assumes you are using a wired ethernet connection on your RPi WireGuard server. If you instead wish to use wifi (wlan0), change the above config to use -o wlan0 in PostUp and PostDown. See this forum post for additional information.

Enabling IP Forwarding on the Server

Edit sysctl.conf on the Raspberry Pi with:

#nano /etc/sysctl.conf

Uncomment the line with “net.ipv4.ip_forward=1″ and save changes.

And enable the interface

#systemctl enable wg-quick@wg0

Securing access to sensitive files

Ensure sensitive files are protected (root rw olny)

#chown -R root:root /etc/wireguard/

And

#chmod -R og-rwx /etc/wireguard/*

Reboot the raspberry

$sudo reboot

Access to your raspberry and check the WireGuard interface is correctly created with the command ‘ip addr’

You need to access to your router to forwards 51900 to the internal IP address and port 51900 of the Raspberry protocol UDP. This is an example of configuration:

Set Up the WireGuard Client for each client

Create a file for each client with the content

Phone access

Creating the file for the phone client

$sudo nano /etc/wireguard/phone.conf

With this content

[Interface]
Address = 10.6.0.2/24
PrivateKey = 
DNS = 10.6.0.1

[Peer]
PublicKey = 
#PresharedKey = 
Endpoint = :51900
AllowedIPs = 0.0.0.0/0, ::/0

Laptop access

Creating the file for the laptop client

$sudo nano /etc/wireguard/laptop.conf

With this content

[Interface]
Address = 10.6.0.3/24
PrivateKey = 
DNS = 10.6.0.1

[Peer]
PublicKey = 
#PresharedKey = 
Endpoint = :51900
AllowedIPs = 0.0.0.0/0, ::/0

With the qrencode command we generate a qr code to import the configuration easily into the wireguard app.

#qrencode -t ansiutf8 < /etc/wireguard/phone.conf

Set Up the WireGuard Server

To configure WireGuard we have to create the wg0 file:

$sudo nano /etc/network/interfaces.d/wg0

With this information

# indicate that wg0 should be created when the system boots, and on ifup -a 
auto wg0 

# describe wg0 as an IPv4 interface with static address 
iface wg0 inet static 

       # static IP address  
       address 10.6.0.1/24 

       # before ifup, create the device with this ip link command 
       pre-up ip link add wg0 type wireguard 

       # before ifup, set the WireGuard config from earlier 
       pre-up wg setconf wg0 /etc/wireguard/server.conf 

       # Routing 
       pre-up iptables -A FORWARD -i wg0 -j ACCEPT 
       pre-up iptables -A FORWARD -o wg0 -j ACCEPT 
       pre-up iptables -t nat -A  POSTROUTING -o eth0 -j MASQUERADE 

       # route packages when the VPN interface is up 
       #post-up sysctl --write net.ipv4.ip_forward=1 

       # and stop routing when stopping the VPN interface 
       #post-down sysctl --write net.ipv4.ip_forward=0 

       # Routing post-down 
       post-down iptables -D FORWARD -i wg0 -j ACCEPT 
       post-down iptables -D FORWARD -o wg0 -j ACCEPT 
       post-down iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE 

       # after ifdown, destroy the wg0 interface 
       post-down ip link del wg0

Adding unattended upgrades (optional)

If you are using third-party packages (e.g. via PPAs), the system has no idea about security updates for those packages. So you need to take an additional step and get them included manually.

Remember to determine the PPA Origin and Suite

The first goal is to determine the details from the PPA (or other external package type). This can be done by peeking in the /var/lib/apt/lists directory. Use the related files ending with InRelease, to see more details about the specific package.

$less /var/lib/apt/lists/deb.debian.org_debian_dists_unstable_InRelease

The two things we need from this file is the field Origin and Suite. These two strings have to be combined and provided to unattended-upgrade. It then understands that this PPA should be upgraded automatically.

Installing Pi.Alert, a Wi-Fi/LAN intruder detector (optional)

Pi.Alert is a nice and small project that provide a Wi-Fi and LAN intruder detector. Check the devices connected and alert you with unknown devices. It also warns of the disconnection of “always connected” devices. It can be located at https://github.com/pucherot/Pi.Alert

The installation is quite simple. Just run the following script (It will ask for the sudo password)

$curl -sSL https://github.com/pucherot/Pi.Alert/raw/main/install/pialert_install.sh | bash

Here you have the screens you will have with the options I have choose for my system:

Save this information to access to the Pi.Alert server:

And this is how Pi.Alert looks like

Here you will find more information regarding device management:

https://github.com/pucherot/Pi.Alert/blob/main/docs/DEVICE_MANAGEMENT.md

To have Pi.alert updated, we have to add to the cron

$sudo crontab -e

And paste this command at the end of the file

3 1 4 */1 * curl -sSL https://github.com/pucherot/Pi.Alert/raw/main/install/pialert_update.sh | bash

Attention: Since I start to write this guide, it seems Pi.Alert project has not quite activity, and others users has started to create forks that are more updated:

Installing a monitoring tool (optional)

We have several options to monitor our system. We can use light applications or heavier ones with a lot of functionalities but with more resource consumptions.

When I started to write this guide I choose RPi-Monitor. An simple and light monitor with all the basic parameters. The problem I found is that is not longer maintained. The last version is from august 2017, so I decided to find another light solution and I found NetData, an open source tool designed to collect real-time metrics, such as CPU usage, disk activity, bandwidth usage, website visits, etc., and then display them in live, easy-to-interpret charts. It offers the possibility to create a free cloud account to complement the netdata agent to provide:

  • Infrastructure level dashboards (each chart aggregates data from multiple nodes)
  • Central dispatch of alert notifications
  • Custom dashboards editor
  • Intelligence assisted troubleshooting, to help surface the root cause of issues

The offer some paid functionalities but they claim the free account will be free forever.

In case you need a powerful solution to monitor devices with a lot of integrations and functionalities like Machine Learning, you can use Grafana. There is a sandbox where you can play with Dashboards.

Installing RPi-Monitor (deprecated)

Rpi-Monitor let us to monitor basic parameters like temperature, CPU load, disk space, and packages upgradables. To install we need to execute the following commands:

$sudo apt-get install dirmngr
$sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 2C0D3C0F
$sudo wget http://goo.gl/vewCLL -O /etc/apt/sources.list.d/rpimonitor.list
$sudo apt-get update
$sudo apt-get install rpimonitor

Configure RPi-Monitor to show network statistics:

$sudo nano /etc/rpimonitor/template/network.conf

Uncomment the first two sections that start with “dynamic.10” and “dynamic.11”. Comment out the third, fourth and fifth lines in the next section that start with “web.status.1” and uncomment the last one. Uncomment the next section that starts with “web.statistics.1”. Exit and save.

Restart RPi-Monitor.

$sudo service rpimonitor restart

Update RPi-Monitor package status:

$sudo /etc/init.d/rpimonitor update

Check the RPi-Monitor web page at http://<IPAddress>:8888

You now have a web dashboard of your server’s status, and there is a historical view under Statistics. This can be helpful for monitoring and troubleshooting. Here is a view in Statistics of temperature over 14 days:

Installing Netdata (recommended)

Netdata helps to monitor and troubleshoot several kind of devices and applications they run, like raspberry pi and Pi-hole.

Afet a quick installation and with no additional configuration required, you will be able to see device parameters like CPU load, memory and disk usage, bandwidth… Netdata collects about 1.500 metrics every second.

On Raspberry Pi, the installation is done by one commands script. This script asks you tto install dependencies and compile Netdata from the source:

$wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh && sh /tmp/netdata-kickstart.sh --disable-telemetry

Parameters:

  • Use a stable release: ‘–stable-channel’
  • Do not send anonymous statistics, ‘–disable-telemetry’
  • No automatic updates: ‘–no-updates’

As you can see, the command line use a nightly version (more updated), I do not want to sent anonymous statistics and I want to receive automatic updates.

When we run this script, it will ask for you administrator account and install all the required packages.

Once finished, we have to modify a configuration file in order to enable the temperature sensor monitoring. We have to uncomment the sensors=force line from the charts.d.conf configuration file. The installation path differs if we have Debian or Raspbian

Debian:

$cd /etc/netdata
$sudo ./edit-config charts.d.conf

Raspbian:

$cd /opc/netdata
$sudo cp usr/lib/netdata/conf.d/charts.d.conf etc/netdata/
$cd etc/netdata
$sudo ./edit-config charts.d.conf

Once modified we have to restart the service to enable Raspberry Pi temperature sensor monitoring:

$sudo systemctl restart netdata

Another improvement suggested by Netdata is to increase the allocation to increase historical metrics. As they said on their website, I will recommend to use their database sizing calculator and guide on storing historical metrics to help you determine the right setting for your Raspberry Pi.

Once installed, we can point our browser to our raspberry pi IP with the port 19999 (http://[our raspberry pi IP]:19999)

The first login will show a reminder to create a cloud account to access your data through Internet and provide:

  • Infrastructure level dashboards (each chart aggregates data from multiple nodes)
  • Central dispatch of alert notifications
  • Custom dashboards editor
  • Intelligence assisted troubleshooting, to help surface the root cause of issues

Through the right menu you can browse different metrics Netdata collects, from the device like CPU, memory, Disks, network, temperature (under sensors Section)… to metrics from the applications installed, like Fail2ban, firewall, Pi-hole, WireGuard

In case you create a cloud account, a command with an agent to be installed is provided in order to grab the data and send to the cloud.

I will also strongly recommend the use of their app to monitoring remotely our systems.

Grafana

Grafana has a web where explain step by step how to install an agent for raspberry pi.

Securing the Raspberry

In case we have a raspberry with a Wi-Fi interface and we do not use it, we can disable it

To completely disable the onboard WiFi from the firmware on the Pi3 / Pi4, add in /boot/config.txt

dtoverlay=disable-wifi
dtoverlay=pi3-disable-wifi

Or can add to this two lines

blacklist brcmfmac
blacklist brcmutil

to the module blacklist

$sudo nano /etc/modprobe.d/raspi-blacklist.conf

Backup & restore

Method 1: Copy the SD Card Image

The easiest way is dump the SD Card or USB to an image. Let’s assume the SD is at the sdb partition.

$sudo dd bs=4M if=/dev/sdb of=raspbian_bck.img conv=fdatasync status=progress

Method 2: Zip the Home Directory

(To Be Done)

Method 3: Scheduled Backups

(To Be Done)

Bonus track. Password manager: Vaultwarden

When I started to use password managers, I choose a light an open-source solution, keepass. I have written on my blog an article a few years ago how to set and use passwords in a safety way using this solution. With the time, a new solution has appear with more functionalities and open-source also: Bitwarden.

Instead Bitwarden I choose Vaultwarden, an alternative implementation of the Bitwarden server API written in Rust and compatible with upstream Bitwarden clients, perfect for self-hosted deployment where running the official resource-heavy service might not be ideal.

The basic installation of Vaultwarden can be done following the instructions from here. I decided to use another raspberry pi since the first one has dedicated exclusively to privacy filter and VPN Server and I prefer to not overload with more services running in the same device.

To access to the password manager server a proxy manager is needed (Nginx). We will need a container manager, portainer, since Vaultwarden and Nginx (application and database) are running within containers.

As we did it before, a DDNS service is needed in order to reach the raspberry from Internet. This also will help us to have a secure connection since it is mandatory to access the password manager. It will be foolish to access your passwords with an http connection.

How to update components

Here I detailed the steps to update all the components we have inside this raspberry pi. The update procedure is not always explained in the installation pages, so I decided to describe how to update each component.

Portainer

Updating Portainer can be done in 4 steps from the raspberry pi command line:

  1. stop portainer dock

    $docker stop portainer
  2. Remove the container

    $docker rm portainer
  3. Pull the new version

    $docker pull portainer/portainer-ce:latest
  4. Run the docker

    $sudo docker run -d -p 9000:9000 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Containers

Every certain time we should check if a new version has been released and evaluate if we want to update it. The update can be done in two ways, through portainer or by command line.

Updating through portainer

  1. Select Containers, then stop the container that you’d like to update.
  2. Select the container, and you’ll see a button named Recreate. By selecting this button, the container will take the persistent data and recreate the container. Keep in mind that the only data that will stay on the container is data that was mapped to a volume.
  3. Select Pull latest image, then Recreate.
  4. When this process is finished, the container will be recreated with the latest image. Select the container and Start it. The status will change to running.
  5. The container will now exist with the newest released version!

Note 1: It will take some time. Be patient.

Note 2: You can remove old container images in order to save space.

Updating command line

First we pull the latest image

$docker pull vaultwarden/server:latest
 sudo docker run -d --name bitwarden \
    --restart=always \
    -v /bw-data/:/data/ \
    -p 127.0.0.1:8080:80 \
    -p 127.0.0.1:3012:3012 \
    vaultwarden/server:latest

And with this command we launch it removing the previous one

$docker run --rm -it --mount type=volume,source=vaultwarden-rclone-data,target=/config/ ttionya/vaultwarden-backup:latest rclone config

Updating Nginx

The reverse proxy should be updated in this order. First the app

$sudo docker update --restart always nginx_app_1

And later the database

$sudo docker update --restart always nginx_db_1

Bibliography

Base

  1. https://www.forbes.com/sites/marketshare/2012/03/05/if-youre-not-paying-for-it-you-become-the-product/
  2. https://medium.com/change-your-mind/if-you-are-not-paying-for-the-product-you-are-the-product-4dbc15b9a3f2
  3. https://clearcode.cc/blog/what-is-data-broker/
  4. https://www.peekyou.com/
  5. https://www.toptenreviews.com/best-people-search-services
  6. https://thesmashy.medium.com/building-a-pihole-for-privacy-and-performance-f762dbcb66e5
  7. https://www.thetechherald.com/tech-news/raspberry-pi-raspbian-os-gets-a-microsoft-repo-without-any-notification-heres-how-to-remove-concerns-of-telemetry-data-collection/
  8. https://arstechnica.com/gadgets/2021/02/raspberry-pi-os-added-a-microsoft-repo-no-its-not-an-evil-secret/
  9. https://betanews.com/2021/02/08/linux-based-raspberry-pi-os-secret-microsoft-repo/
  10. https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

Pi-hole

Unbound

Fail2ban

Unattended-Upgrades

Pi.Alert

WireGuard

Monitoring tools

Backup

Vaultwarden

Others

Por qué la energía de fusión siempre está a 50 años vista

Por Francisco R. Villatoro, el 2 septiembre, 2022.

 

Muchas veces se bromea con que la energía de fusión comercial siempre está a cincuenta años vista; aunque los más optimistas prefieren decir que siempre está a veinte años vista. Así se decía hace cincuenta años, y hace veinte años, y se sigue diciendo hoy. De hecho, mi propia estimación es que la ruta hacia la energía fusión con ITER+IFMIF+DEMO+PROTO acabará con los primeros reactores comerciales (si todo va bien) alrededor de 2070 (que está a unos cincuenta años vista). ¿Cuál es la razón? «Es la economía, estúpido» (the economy, stupid, la famosa frase de la campaña electoral de Bill Clinton en 1992). La investigación, el desarrollo y la innovación en energía de fusión siempre han estado infrafinanciados. Y no solo lo saben y lo afirman los científicos, también los políticos. Pero una cosa es saberlo y otra muy diferente poner un arreglo. Mientras el motor de la política sean los resultados a cuatro o cinco años vista, la energía de fusión nunca será alcanzada. Nunca. Si de verdad queremos que la energía de fusión revolucione nuestro mundo tenemos que apostar de forma rotunda por una vía rápida hacia la fusión.

Lo sé, lo sé, me dirás que ya está otra vez Francis con su matraca de siempre… Ya lo conté en «Hacia un reactor de fusión comercial en 2030», Naukas, 11 jun 2012; mi respuesta a la pregunta de Javier Peláez (@irreductible): ¿en qué proyecto científico gastarías cien mil millones de euros? Y lo cuento cada vez que tengo ocasión. Ahora al hilo de que en ITER se van a gastar unos veinte mil millones en quince años mientras que en la Misión Artemisa de la NASA se van a gastar casi cien mil millones en cinco años ($93 billion by FY 2025 según el informe «NASAS’s Management of the Artemis Missions,» Report No. IG-22-003, NASA Office of Inspector General, 15 Nov 2021 [PDF]). La crisis energética es el mayor problema del s. XXI; acelerar la ruta hacia el primer reactor de fusión comercial me parece que debería ser la prioridad máxima. En 2011 nos lo contaba David J. Campbell, director científico de ITER, una «vía rápida» hacia la fusión podría conducir al primer reactor comercial alrededor del año 2050, entonces a cuarenta años vista, y una «vía ultrarrápida» hacia la fusión lo lograría sobre 2030, entonces a veinte años vista (LCMF, 09 ene 2012). Pero en lugar de un apoyo firme a la fusión lo único que encontramos son retrasos y trabas (LCMF, 24 nov 2015).

La figura de Geoffrey M. Olynyk que abre esta pieza (Wikimedia Commons) resume cinco proyecciones presupuestarias realizadas en 1976 para la financiación de la investigación en fusión en EEUU. Con el esfuerzo financiero máximo se estimaba en 1976 que se lograría un reactor comercial en 1990 (en unos 15 años); con un esfuerzo moderado se lograría en 2005 (en unos 30 años); pero manteniendo constante el presupuesto esperado entonces para 1978 no se lograría nunca («fusion never»). Repito, nunca se logrará la fusión comercial sin un gran esfuerzo financiero. Pero la situación es aún peor, pues la figura de Olynyk añade a la versión original una estimación del gasto de EEUU en fusión hasta el año fiscal 2013, un gasto muy inferior al gasto esperado en 1978. El escenario actual sería pero que el escenario «fusion never», si no fuera porque en este siglo la fusión está liderada por una iniciativa internacional financiada por la Unión Europea, Japón, Estados Unidos, Corea del Sur, India, Rusia y China (sí, me refiero a ITER). Pero al ritmo actual ITER será un éxito alrededor de 2040, IFMIF también debería serlo alrededor de 2040, DEMO no lo será hasta 2055 (como pronto), y PROTO hasta 2070 (también como pronto). Necesitamos acelerar la ruta hacia la fusión. No lo digo yo, cada vez que tengo oportunidad, no lo decía David J. Campbell, director científico de ITER, en 2011, también lo decía la ERDA de EEUU en 1976, de hecho, se lleva diciendo «desde siempre».

Te cuento de nuevo todo este rollo al hilo de un hilo en Twitter del físico de partículas Martin Bauer @MartinMBauer sobre por qué el progreso en fusión nuclear es tan lento. En su hilo incluye la figura de Olynyk, una versión a color de una figura en blanco y negro que se publicó en 1976 (hace unos cincuenta años) en «Fusion Power by Magnetic Confinement Program Plan. Volume I. Summary,» ERDA-76/110/1, U.S. Energy Research and Development Administration, July 1976 [PDF], y que se republicó en 1998 en Stephen O. Dean, «Fusion Power by Magnetic Confinement Program Plan,» Journal of Fusion Energy 17: 263-287 (1998), doi: https://doi.org/10.1023/A:1021815909065.

Y quizás te preguntas, ¿son confiables las proyecciones de ERDA en 1976? No, no lo son, ni lo eran. Hoy sabemos que eran demasiado optimistas. La física de plasmas en reactores es mucho más complicada de lo que se pensaba a principios de los 1970. Con los conocimientos actuales se podría volver a hacer un ejercicio de proyección presupuestaria para estimar lo que se necesita para lograr una «vía rápida», incluso una «vía ultrarrápida», hacia la fusión. En mi opinión hay que volver a poner en la palestra esta cuestión.

Este  artículo apareció originalmente en  La ciencia de la mula Francis

 

…Searching Always New Horizons.