Using HTTP headers to protect your visitor’s security and privacy

Recently there has been a lot of controversy over Google starting to use Federated Learning of Cohorts (FLoC) in its Chrome browser. This new technique is used to track users without using third party cookies, but has severe privacy implications because it actually makes fingerprinting users easier and can reveal your interests to websites.

To prevent tracking by FLoC and other tracking techniques, there is only one good solution: stop using Google Chrome. The best privacy friendly browser is Firefox, especially if you set it to strict enhanced tracking protection. If you really need to use Chrome, then at least install one of the open source extensions which disable FLoC and Privacy Badger for other tracking protection.

As a website owner, you can also do something to protect your users. You can opt out your website to be included in cohort computation by sending the header Permissions-Policy: interest-cohort=()

This can be easily done for all your websites by modifying your Apache configuration. While at it, you should set some other security and privacy related headers, notably:

  • X-Frame-Options "SAMEORIGIN": this makes sure that browsers will not allow your website to be included in an iframe on another domain.
  • X-Content-Type-Options "nosniff": This will prevent the browser from trying to automatically detect the file type of a downloaded file instead of using the MIME type sent by the server. This can mitigate attacks where a hacker manages to upload a malicious file by giving it a filename which makes it look like a harmless file type which is then served to your visitors.
  • Referrer-Policy "no-referrer-when-downgrade": when a visitor clicks on a link, the browser will only send the referrer when it’s not going from a HTTPS to a HTTP connection. This is fine if your URLs don’t contain any private information. If they do, then consider using strict-origin-when-cross-origin, so that only your domain name instead of the complete URL is sent as referrer if people click on a link leading to an external website, or even same-origin, which prevents any referrer being sent to external sites. You should probably do this for an internal website, web application or wiki, webmail, etc. More information about Referrer-Policy

To set these in Apache in Debian, create a file /etc/apache2/conf-available/security-headers.conf with these contents:

<IfModule mod_headers.c>
   Header always set X-Frame-Options "SAMEORIGIN"
   Header always set X-Content-Type-Options "nosniff"
   Header always set Referrer-Policy "no-referrer-when-downgrade"
   Header always set Permissions-Policy: interest-cohort=()
</IfModule>

Then make sure the mod_headers module is loaded and this file is enabled by running these commands:

# a2enmod headers
# a2enconf security-headers
# systemctl reload apache2

Another important header to set in your SSL virtualhosts is the HSTS header: it ensures that the browser will automatically use HTTPS every time when connecting to the website in the future. Place this in your SSL enabled virtualhost:

<IfModule mod_headers.c>
   Header always set Strict-Transport-Security "max-age=63072000"
</IfModule>

Then you should also add this to your non-SSL virtualhost to redirect all visitors using HTTP to HTTPS:

<IfModule mod_rewrite.c>
   RewriteEngine on
   RewriteCond %{HTTPS} !=on
   RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
</IfModule>

Of course make sure mod_rewrite is enabled if that’s not yet the case:

# a2enmod rewrite
# systemctl reload apache2

You can check your server configuration on securityheaders.com. There you can also find more information about the headers Cross-Origin-Embedder-Policy, Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy, some other security related headers. Because they require more changes to your website to implement correctly, I’m not discussing them here.

More information

Using Fangfrisch to improve ClamAV malware detection in e-mail

If you have an e-mail server, maybe you already are using the open source tools Amavis and ClamAV to detect malicious e-mails. ClamAV’s default virus signatures however, while being useful, still only detect a limited set of malware. Fortunately there exist third-party unofficial signatures which you can use to drastically improve the detection rate so that it becomes similar to the detection rate of commercial anti-virus software. These third-party signatures are a must-have on any mail server using ClamAV.

ClamAV can also be very useful to scan the webroot directories on web servers in order to detect malicious PHP scripts which may be installed on your server after an intrusion in a web application. Several of the third-part ClamAV definitions proposed here, specialize in this kind of malware.

Fangfrisch is a utility which automates downloading third-party ClamAV virus definitions. It has several free repositories containing ClamAV signatures configured by default, but you can also easily add other ones.

Third-party ClamAV virus definitions

SaneSecurity

SaneSecurity is a set of signatures focusing on so-called 0-day and 0-hour malware, which means that it includes hashes of new malicious files being sent by e-mail. Furthermore it contains signatures for malicious URLs, common spam and phishing messages and generic signatures which detect some commonly types of techniques used in malware, such as exe files with a double extenstion (for example pdf.exe), exe files hidden in ISO files and often abused functions in MS Office macros. Sanesecurity also distributes signatures from other sources, such as phishing URLs from phishtank.com. A complete list of available signature databases can be found on their website.

SaneSecurity signatures are free to use, however a donation is appreciated.

SecuriteInfo

The French company SecuriteInfo claims that their ClamAV definitions add 4.000.000 signatures for malware and spam not detected by the official ClamAV signatures. There is a free feed of the signatures available, however it only contains signatures older than 30 days. For up-to-date 0-day malware detection, you will need one of the paid plans.

In the MalwareBazaar database you can see that SecuriteInfo is often the only ClamAV definitions database which detects malicious Windows binaries.

Malwarepatrol

MalwarePatrol is a commercial threat intelligence company which offers free and paid feeds, including ClamAV virus signatures which contain URL’s pointing to malware files on the world wide web. The free feed is only updated every 72 hours, while the paid feed is updated every 4 hours. If you need an invoice or want to use the feeds for protecting customers of your company, you will have to use the commercial feeds.

Quickly after integrating the free feed in my Amavis installation, I noticed it was wrongly blocking legitimate mails with links to arxiv.org/pdf, which is used a lot in academic environments. So be careful when you integrate this feed. For this reason you should not automatically block all messages marked by Malwarepatrol. With Amavis you can give them them a positive spam score. In combination with the score from the Bayes spam filter, legitimate mails will not be blocked.

MalwareExpert

MalwareExpert offers a commercial, paid feed of signatures which detect malicious PHP files, meant for scanning your web servers.

URLHaus

URLHaus is a project from abuse.ch collecting URLs of sites distributing malware. They offer a ClamAV signature database of all these malicious URLs so that you can block all e-mail containing links to sites distributing malware. This database can be used for free, both for commercial and non-commercial purposes.

Clam-punch

Clam-punch is described as a “highly curated set of signatures for ClamAV”. It seems to focus mainly on malicious macros in MS Office documents. They do not seem to be updated regularly any more, however as the signatures appear to be rather generic, they can probably still be useful.

TwinWave Security Twinclams

Twinclams is a Github repository by TwinWave Security and contains signatures for malicious MS Office documents. The author of twinclams appears to be a contributor of Clam-punch. This ClamAV virus database is getting updated daily and appears to be highly effective in detecting newly found Office documents with malicious macros. Recent malicious Office document in the MalwareBazaar database are almost always detected by the Twinclams definitions, sometimes even detecting files which are not detected yet by commercial anti-virus software.

R-FX Networks Linux Malware Detect

Part of its Linux Malware Detect (LMD) tool, R-FX Networks offers a set of ClamAV signatures specializing in detecting Linux specific malware, including malicious PHP scripts, trojan horses such as malicious IRC bots, worms, etc.

InterServer

Another set of ClamAV signatures focused on malicious PHP scripts is maintained by the hosting provider InterServer. I highly recommend this feed if you want to scan your web servers.

ditekshen

The ClamAV signatures by security reseacher ditekshen add detection for various Windows, MacOS and Linux trojan horses en ransomware.

Installing Fangfrisch

Unfortunately Debian does not have a package for Fangfrisch, so you need to install it manually. In contrast to the documentation, I prefer to install fangfrisch in /opt though, using /var/lib/fangfrisch only for the database, and saving the signatures in /var/lib/fangfrisch/signatures, so that we can check them later on before letting ClamAV use them.

# mkdir -m 0770 -p /var/lib/fangfrisch/signatures
# chgrp -R clamav /var/lib/fangfrisch
# mkdir /opt/fangfrisch 
# cd /opt/fangfrisch
# apt-get install python3-venv python3-pip
# python3 -m venv venv
# source venv/bin/activate
# pip3 install fangfrisch

Configuring Fangfrisch

Create the file /etc/fangfrisch/fangfrisch.conf with these contents:

[DEFAULT]
db_url = sqlite:////var/lib/fangfrisch/db.sqlite

# The following settings are optional. Other sections inherit
# values from DEFAULT and may also overwrite values.

local_directory = /var/lib/fangfrisch/signatures
max_size = 5MB
on_update_exec = /usr/local/bin/setup-clamav-sigs
on_update_timeout = 42
log_level = info

[malwarepatrol]
enabled = no
# Replace with your personal Malwarepatrol receipt
# receipt = XXXXXXXXX
# change product id if necessary.
# 32 = free guard, 33 = Basic Defense yearly, 34 = Basic Defense monthly, 37 = Basic Defense EDU/Contributor
# product = 32

# This is untested
[malwareexpert]
enabled = no
max_size = 20M
prefix = https://signatures.malware.expert
interval = 1d
# serial_key = xxxxxxx
url_malware.expert_fp = ${prefix}/${serial_key}/malware.expert.fp
url_malware.expert_hdb = ${prefix}/${serial_key}/malware.expert.hdb
url_malware.expert_ldb = ${prefix}/${serial_key}/malware.expert.ldb
url_malware.expert.ndb = ${prefix}/${serial_key}/malware.expert.ndb

[sanesecurity]
prefix = https://ftp.swin.edu.au/sanesecurity/
max_size = 10M
enabled = yes
interval = 1h
url_malwareexpert_fp = disabled
url_malwareexpert_hdb = disabled
url_malwareexpert_ldb = disabled
url_malwareexpert_ndb = disabled

[securiteinfo]
enabled = no
# uncomment the next line if you want to use the securiteinfoold.hdb database with old signatures
# max_size = 500MB
# Replace with your personal SecuriteInfo customer ID
# customer_id = abcdef123456
# Remove the exclamation mark before the next databases if you have the Professional subscription
!url_0hour = ${prefix}securiteinfo0hour.hdb
!url_securiteinfo_mdb = ${prefix}securiteinfo.mdb
# The next databases are disabled by default in fangfrisch because they are prone to false positives, but we reduce most of them to a spam score in Amavis
url_old = ${prefix}securiteinfoold.hdb
url_spam_marketing = ${prefix}spam_marketing.ndb

[urlhaus]
enabled = yes
max_size = 2MB

[twinwave]
enabled = yes
max_size = 2M
integrity_check = disabled
interval = 1h
prefix = https://raw.githubusercontent.com/twinwave-security/twinclams/master/
url_twinclams = ${prefix}twinclams.ldb
url_twinwave_ign2 = ${prefix}twinwave.ign2

[clampunch]
enabled = yes
max_size = 2M
integrity_check = disabled
interval = 24h
prefix = https://raw.githubusercontent.com/wmetcalf/clam-punch/master/
url_miscreantpunch099low = ${prefix}MiscreantPunch099-Low.ldb
url_exexor99 = ${prefix}exexor99.ldb
url_miscreantpuchhdb = ${prefix}miscreantpunch.hdb

[rfxn]
enabled = yes
interval= 4h
integrity_check = disabled
prefix = https://www.rfxn.com/downloads/
url_rfxn_ndb = ${prefix}rfxn.ndb
url_rfxn_hdb = ${prefix}rfxn.hdb
url_rfxn_yara = ${prefix}rfxn.yara

[interserver]
enabled = yes
interval = 1d
integrity_check = disabled
prefix = https://sigs.interserver.net/
url_interserver_sha256 = ${prefix}interserver256.hdb
url_interserver_topline = ${prefix}interservertopline.db
url_interserver_shell = ${prefix}shell.ldb
url_interserver_whitelist = ${prefix}whitelist.fp

[ditekshen]
enabled = yes
interval = 1d
integrity_check = disabled
prefix = https://raw.githubusercontent.com/ditekshen/detection/master/clamav/
url_ditekshen_ldb = ${prefix}clamav.ldb
filename_ditekshen_ldb = ditekshen.ldb

Don’t forget to customize the entries if you have any paid subscription. Set some safe file permissions on this file, especially if it contains tokens of commercial subscriptions:

# chown root:clamav /etc/fangfrisch/fangfrisch.conf
# chmod 640 /etc/fangfrisch/fangfrisch.conf

Checking the new signatures before letting ClamAV use them

In the configuration file above, I call the script setup-clamav-sigs whenever signatures were updated. This script will check whether the downloaded files are really different than the signatures in /var/lib/clamav, and if they are, check them to ensure they don’t contain errors preventing ClamAV to load them. If ClamAV can successfully load them, it will copy them to /var/lib/clamav and restart clamdscan if it’s loaded. Download the script from the GitLab repository, place it in /usr/local/bin and make sure it’s executable.

Initalizing Fangfrisch

When you have set up Fangfrisch, you have to initialize it by executing

sudo -u clamav -- /opt/fangfrisch/venv/bin/fangfrisch --conf /etc/fangfrisch.conf initdb

Configuring Clamav

SecuriteInfo recommends setting these settings in /etc/clamav/clamd.conf in order to get the best detection while still avoiding too many false positives:

DetectPUA yes
ExcludePUA PUA.Win.Packer
ExcludePUA PUA.Win.Trojan.Packed
ExcludePUA PUA.Win.Trojan.Molebox
ExcludePUA PUA.Win.Packer.Upx
ExcludePUA PUA.Doc.Packed

Configuring Amavis

I assume you already have a working Amavis instance. Sanesecurity gives some recommendations for Amavis for the best results. Add this to the configuration, for example In Debian you can create the file /etc/amavis/conf.d/50-clamav:

@keep_decoded_original_maps = (new_RE(
  qr'^MAIL$',   # retain full original message for virus checking (can be slow)
  qr'^MAIL-UNDECIPHERABLE$', # recheck full mail if it contains undecipherables
  qr'^(ASCII(?! cpio)|text|uuencoded|xxencoded|binhex)'i,
# qr'^Zip archive data',     # don't trust Archive::Zip
));

@virus_name_to_spam_score_maps =
   (new_RE(  # the order matters!
     [ qr'^TwinWave\.'                                      => undef ],# keep as infected
     [ qr'^MiscreantPunch\.'                                => undef ],# keep as infected
     [ qr'^Structured\.(SSN|CreditCardNumber)\b'            => 2.0 ],
     [ qr'^(Heuristics\.)?Phishing\.'                       => 2.0 ],
     [ qr'^(Email|HTML)\.Phishing\.(?!.*Sanesecurity)'      => 10.0 ],
     [ qr'^Sanesecurity\.(Malware|Badmacro|Foxhole|Rogue|Trojan)\.' => undef ],# keep as infected
     [ qr'^Sanesecurity\.Phishing\.'                        => 6.0 ],
     [ qr'^Sanesecurity\.Blurl\.'                           => 4.0 ],
     [ qr'^Sanesecurity\.Jurlbl\.'                          => 2.0 ],
     [ qr'^Sanesecurity\.Spam\.'                            => 2.0 ],
     [ qr'^Sanesecurity\.SpamL\.'                           => 2.0 ],
     [ qr'^Sanesecurity\.Junk\.'                            => 4.0 ],
     [ qr'^Sanesecurity\.Scam4\.'                           => 2.0 ],
     [ qr'^Sanesecurity\.'                                  => 0.1 ],
     [ qr'^Sanesecurity.TestSig_'                           => 0   ],
     [ qr'^Email\.Spam\.Bounce(\.[^., ]*)*\.Sanesecurity\.' => 0   ],
     [ qr'^BofhlandMW\.'                                    => undef ],# keep as infected
     [ qr'^Bofhland\.Malware\.'                             => undef ],# keep as infected
     [ qr'^Bofhland\.'                                      => 2.0 ],
     [ qr'^winnow.malware\.'                                => undef ],# keep as infected
     [ qr'^winnow\_'                                        => 2.0 ],
     [ qr'^PhishTank\.Phishing\.'                           => 6.0 ],
     [ qr'^Porcupine\.Malware\.'                            => undef ],# keep as infected
     [ qr'^Porcupine\.'                                     => 2.0 ],
     [ qr'^Email\.Spammail\b'                               => 2.0 ],
     [ qr'^Safebrowsing\.'                                  => 2.0 ],
     [ qr'^winnow\.(phish|spam)\.'                          => 2.0 ],
     [ qr'^SecuriteInfo.com\.Phish'                         => 6.0 ],
     [ qr'^SecuriteInfo.com\.Spam'                          => 2.0 ],
     [ qr'^MBL_'                                            => 4.0 ],
   ));

These settings ensure that not only the different parts and attachments will be separately scanned by ClamAV, but also the mail as a whole. Then we will reduce some ClamAV virus detections from infected to a spam score in Spamassassin. I do this on rules which could be more likely causing false positives. You can adapt the score to your own situation.

Automatically running Fangfrisch using a systemd timer

Create the file /etc/systemd/system/fangfrisch.service:

[Unit]
Description=Download unofficial clamav virus definition files
ConditionPathExists=/var/lib/fangfrisch/db.sqlite

[Service]
Type=oneshot
User=clamav
WorkingDirectory=/var/lib/fangfrisch
ExecStart=/opt/fangfrisch/venv/bin/fangfrisch --conf /etc/fangfrisch/fangfrisch.conf refresh

[Install]
WantedBy=multi-user.target

Then create the file /etc/systemd/system/fangfrisch.timer:

[Unit]
Description=Download unofficial clamav virus definition files
Requires=fangfrisch.service

[Timer]
Unit=fangfrisch.service
Persistent=true
OnUnitActiveSec=10min
RandomizedDelaySec=30

[Install]
WantedBy=timers.target

Run this command to activate the timer:

# systemctl enable --now fangfrisch.timer

Ignoring virus definitions

It is possible that you hit false positives with certain definitions. If you want to completely disable a specific virus definition, you can add its name to a text file with the ign2 extension in /var/lib/clamav/. For example for me the Sanesecurity.Badmacro.Doc.hypers caused a false positive for me, so I created the file /var/lib/clamav/local_whitelist.ign2 with content:

Sanesecurity.Badmacro.Doc.hypers

To reload the database after changing the database, run

# sudo -u clamav clamdscan --reload

Conclusion

With free third-party databases (Sanesecurity, URLHaus, Clam-punch, Twinclams, R-FX MLD, Interserver and ditekShen) it is possible to drastically improve the detection rate of ClamAV so that it becomes an excellent virus scanner for e-mail and web servers at least if you use it In combination with Amavis’ configuration to block malicious file types (such as exe, com, vbs, dll, pif, etc.) and a well configured and trained Spamassassin. If you want the best protection, add a subscription to the SecuriteInfo feeds.

De waarheid over Coronalert en gedecentraliseerde contact tracing apps

Inhoudstafel

Te lang om allemaal te lezen? Ga onmiddellijk door naar de conclusie.

Wie mij een beetje kent, weet dat ik privacy erg belangrijk vind. Daarom dacht ik dat contact tracing apps for COVID-19 een zeer slecht idee waren toen men daar enkele maanden geleden begon over te praten. Een app die contant bijhoudt waar je bent en wie je tegenkomt, dat is enkel iets dat je in ondemocratische landen en dictatoriale regimes verwacht, maar niet in Europa waar onze privacy gewaarborgd zou moeten zijn door de GDPR (AVG). En wat met de betrouwbaarheid van deze apps? Bluetooth was nooit voor dergelijke toepassingen ontworpen. Het zou leiden tot veel foutieve waarschuwingen. Geen denken aan dat ik zo’n app ooit zou installeren.

Althans, dat was mijn mening enkele maanden geleden. Ondertussen is mijn mening volledig veranderd. En dat is gebeurd na het lezen over gedecentraliseerde contact tracing apps gebaseerd op de Google en Apple Exposure Notification (GAEN) API en DP-3T. Ik heb reeds de Italiaanse contact tracing app Immuni gebruikt in Italië en ook in België gebruik ik de app Coronalert (Androidversie, iPhone-versie).

DP-3T

Decentralized Privacy-Preserving Proximity Tracing of DP-3T is een open protocol ontwikkeld door verschillende universiteiten waaronder ETH en EPFL uit Zwitserland, de KU Leuven uit België en TU Delft uit Nederland.

Volgende cartoon geeft een eenvoudig overzicht van hoe DP-3T werkt.

Elke dag wordt een nieuwe random seed (gebaseerd op de seed van de dag voordien) op de telefoon van elke gebruiker en deze dagelijkse seed wordt op te elefoon bijgehouden gedurende 14 dagen. Op basis van deze seed worden er ephermal identifiers (EphIDs) aangemaakt. Deze EphIds verandere verscheidene keren per uur.

EphIDs worden uitgewisseld met andere gebruikers van de tracking app via Bluetooth Low Energy (BLE) en elke telefoon houdt de EphIDs die hij ontvangen heeft lokaal bij op de telefoon, samen met de datum en de sterkte van het signaal, dat kan gebruikt worden om de afstand in te schatten.

Wanneer iemand positief test op COVID-19 kan die, met de hulp van de gezondheidsauthoriteiten, de seed van de eerste dag waraop hij besmettelijk was, uploaden naar een centrale server. Op dat moment worden alle voorgaande dagelijkse seeds gewist van de telefoon en wordt een compleet nieuwe random dagelijkse seed aangemaakt, zodat de gebruiker ook in de toekomst niet kan gevolgd worden.

De app downloadt regelmatig een lijst van al de dagelijkse seeds van de besmette gebruikers van de centrale server en kan op basis daarvan al de EphIDs berekenen. De app vergelijkt deze EphIDs met de lijst van EphIDs die hij onlangs is tegengekomen. Op basis van de het aantal overeenkomstige EphIDs kan de app berekenen hoe lang de twee in elkaars buurt zijn geweest en op basis van de opgeslagen signaalsterkte kan een inschatting gemaakt worden van de afstand. Als de twee langer dan een bepaalde tijd binnen een bepaalde afstand in elkaars buurt zijn geweest, dan zal de gebruiker een waarschuwing krijgen dat hij in contact is geweest met een besmettelijke persoon, samen met verdere instructies. Een contact met een besmette persoon wordt in het Engels “exposure” genoemad, Coronalert gebruikt in het Nederlands de term “blootstelling”.

Meer details zijn te vinden in de DP-3T white paper.

Apple/Google Exposure Notifications API

De Google/Apple Exposure Notifications API (soms afgekort tot GAEN) is een API die door Google en Apple is ontwikkeld en die gebruikt kan worden door gedecentralseerde contact tracing apps. Deze API is gebaseerd op de principes van het DP-3T-protocol en kan enkel gebruikt worden door apps die zijn goedgekeurd door Google en Apple: slechts één app per land, ontwikkeld door de officiële gezondheidsauthoriteiten, kan goedgekeurd worden. Enkel gedecentraliseerde apps die geen enkele informatie over de positie van gebruikers verzamelen, worden goedgekeurd.

Op Apple iOS kunnen apps normaal geen Bluetooth op de achtergrond gebruiken, maar een uitzondering werd gemaakt voor apps die gebruik maken van deze API. Dit betekent dat op Apple iPhone, deze API de enige manier is om een betrouwbare contact tracing app te maken. Apps die deze API niet gebruiken, zoals de StopCovid France app, moeten via work-arounds de app in de achtergrond toch naar de voorgrond halen, wat hen potentieel minder betrouwbaar maakt en een negatief effect heeft op het batterijverbruik.

Het DP-3T framework werd aangepast om gebruik te maken van de Exposure Notifications API.

De Google/Apple Exposure Notifications API en DP-3T wordt gebruikt door de Belgische contact tracing app Coronalert. Andere apps die deze API gebruiken zijn Coronamelder (Nederland), SwissCovid (Zwitserland), Immuni (Italië), Corona-Warn-App (Duitsland).

De broncode van de de implementatie van het framework voor Android en iOS werd in de tweede helft van juli 2020 gepubliceerd.

Veel gestelde vragen (FAQ) – Enkele mythes ontkracht

Deze apps zijn soms onderwerp van moedwillige fake news campages, of lokken in ieder geval hevige reacties uit die het gevolg zijn van een een gebrek aan begrip van de werking van deze apps. Hier zal ik enkele belangrijke vragen beantwoorden.

Schenden deze apps mijn privacy? Zullen de authoriteiten weten wie ik ontmoet, waar ik ben en wat ik doe?

De apps die gebruik maken van de Google Apple Exposure Notification API houden geen persoonlijke informatie bij van de gebruikers: ze kennen je naam niet, je telefoonnummer, waar je woont of andere persoonlijke gegevens. Ze verzamelen ook geen locatiegegevens, dus ze weten niet waar je bent.

Het enige dat deze apps doen, is anonieme codes uitwisselen met andere mensen in je buurt. Deze codes veranderen verscheidene malen per dag, zodat het onmogelijk is om je te volgen door middel van deze codes.

De codes die de uitgewisseld worden, worden enkel lokaal op je telefoon bijgehouden en niet in een centrale databank. Er is dus geen manier voor de authoriteiten om te weten hoeveel mensen en wie u ontmoet heeft.

Contact tracing apps maken daarnaast gebruik van uitgebreide preventiemaatregelen om uw veiligheid en privacy te beschermen: zo doen ze dummy uploads om te vermijden dat door middel van netwerkanalyse zou kunnen ontdekt worden wie een positieve test heeft afgelegd, wordt er gebruikt gemaakt van CA of certificate pinning om man-in-the-middle-aanvallen te voorkomen, enzovoort.

Deze apps zijn geen hulpmiddel voor massarveillance en zijn ook geen Big Brother zoals sommigen beweren.

Hoe kan ik zeker zijn dat de app werkt zoals beweerd wordt en echt geen privé-informatie verstuurd?

Deze apps zijn gewoonlijk open source, wat betekent dat je de zelf de code kan onderzoeken om te zien hoe de app werkt en wat deze precies doet. Zelfs als je zelf de kennis niet hebt om de code na te kijken, dan mag je er zeker van zijn dat er genoeg experten zijn die hier naar kijken en zij zullen het wel luid en duidelijk laten horen wanneer iets niet zuiver op de graat is. Het moet gezegd: vaak zijn degenen die het luidst over deze apps roepen politici uit de oppositie en activisten die nooit naar de code of de documentatie hebben gekeken.

Hier zijn links naar de broncode van enkele contact tracing apps en de documentatie:

Op de issue trackers van deze apps kunnen problemen gemeld worden en vragen gesteld worden.

Ook de broncode van het Exposure Notifications framework, gebruikt door deze apps, is openbaar:

Een eerste analyse van de broncode van de Coronalert app toont aan dat deze inderdaad niet meer gegevens bijhoudt en verstuurt dan aangekondigd en dat Sciensano en Ixor (het Belgische bedrijf dat de backendservers beheert) nooit persoonlijke data ontvangen van de app.

Waarom zou ik Google en Apple, die een slechte reputatie hebben op vlak van privacy, nu moeten vertrouwen?

Eigenlijk hebben Google en Apple deze API zelfs niet nodig om je te volgen. Als je een telefoon gebruikt met iOS of Android met Google Play Services, heb je op zich al een veel groter privacyprobleem dan deze gedecentraliseerde, open source contact tracing apps. Dat is ook het geval als je Facebook, Twitter, Instagram, TikTok, NetFlix, Spotify, FaceAp, Tinder en dergelijk apps gebruikt: deze kennen uw naam, locatie, uw interesses, vrienden en dat allemaal zonder deze API. Gedecentraliseerde contact trcacing apps weten veel minder over u dan al deze apps. Dit beeld vergelijkt de verschillende permissies die SwissCovid, Facebook en Whatsapp kunnen aanvragen op iOS. Het is duidelijk dat het niet de contact tracing app is die het meeste informatie kan verzamelen.

Prof. Bart Preneel (KU Leuven), een cryptograaf die meegewerkt heeft aan het de ontwikkeling van het DP-3T framework, zegt dat “voor één keer Google en Apple kiezen voor de goede kant van de privacy”.

Daarnaast is er een manier om deze contact tracing apps te gebruiken zonder enige Google-services op je telefoon. Het microg-project heeft zijn eigen, volledig open source implementatie gemaakt van de Exposure Notification API. Deze kan geïnstalleerd worden op een Androiddistributie zoals LineageOS. Er is bevestiging dat SwissCovid en Immuni werken met de microg-implementatie van de API, dus andere apps werken wellicht ook. Op deze manier is het mogelijk om deze contact tracing apps te gebruiken zonder enige binaire code van Google of Apple.

Waarom vereist Coronalert dat Locatie aan staat op mijn Androidtelefoon als de app zogezegd mijn locatie niet bijhoudt?

Om te scannen naar Bluetooth-apparaten op Android, is het nodig dat de locatie-instelling aan staat op Android omdat dit in theorie kan gebruikt worden om uw positie te bepalen. Dit wordt bijvoorbeeld gebruikt door navigatie-apps om uw positie te bepalen in ondergrondse tunnels. In werkelijkheid is het voor apps die gebruik maken van de GAEN API niet toegelaten om uw locatie op te vragen. Het kan ook in de broncode van de app geverifieerd worden dat op geen enkel moment de locatie wordt bepaald. In Instellingen – Locatie – Machtigingen op app-niveau kan u ook nog altijd locatietoegang uitschakelen voor apps. Coronalert (of andere contact tracing app gebaseerd op de Expsoure Notificatoins API) zal in deze lijst niet verschijnen omdat deze geen locatie opvraagt.

In Android 11, uitgekomen in september 2020, is het niet meer nodig om Locatie aan te hebben op uw telefoon om contact tracing apps te gebruiken die gebaseerd zijn op de Exposure Notifcation API.

Zullen deze apps mij een waarschuwing geven telkens wanneer een besmette persoon voorbijgekomen is en dus heel wat valse waarschuwingen geven?

De apps zullen enkel een waarschuwing geven als aan bepaalde voorwaarden voldaan is. Die voorwaarden worden gewoonlijk door de overheid vastgelegd op basis van epidemioloigsche data. De Italiaanse Immuni app bijvoorbeeld, zal een waarschuwing geven wanneer iemand op een afstand van maximaal 2 meter staat gedurende minstens 15 minuten. SwissCovid zal pas waarschuwen bij een contact van minstens 15 minuten binnen een afstand van 1,5m.

De afstand wordt geschat op basis van de verzwakking van het signaal. Die verzwakking hangt helaas wel af van heel wat parameters, zoals het model van de telefoon dat gebruikt wordt, de richting waarin die telefoon wordt gehouden, enzovoort. Google past voor elk telefoonmodel een correctie toe op de verzwakking, zodat de waardes vergelijkbaar zouden moeten zijn tussen verschillende modellen. De drempelwaarden die worden gebruikt om waarschuwingen te geven, zijn gebaseerd op experimenten in verschillende omgevingen en kunnen in de toekomst nog aangepast worden om het aantal vals positieven en negeatieven aan te passen.

Dus nee, contact tracing apps zullen u geen waarschuwing geven telkens wanneer iemand die even kortbij gepasseerd is, positief wordt getest. Enkel wanneer zeer redelijke drempelwaarden worden overschreden, zal u een waarschuwing krijgen. Ook de authoriteiten realiseren zich dat deze contact tracing apps een hulpmiddel zijn voor tracing, maar nooit manuele contact tracing kunnen vervangen. Een contact tracing app kan ook nooit een COVID-19-test vervangen.

In de praktijk zal Coronalert ook niet-risicovolle contacten weergeven: er zal dan in de app staan dat er een blootstelling geweest is, maar het risico blijft op laag staan en de app blijft groen. Enkel bij een contact langer dan 15 minuten op een afstand die minder dan 1,5m geschat wordt, zal het scherm rood worden en zal er een notificatie komen over een hoogrisico-contact. Enkel in dat laatste geval zal een quarantaine en test aangeraden worden.

Zijn deze apps nuttig als niet iedereen of ten minste een groot deel van de bevolking ze gebruikt?

Contact tracing apps zijn zeker nuttig, zelfs als enkel een deel van de bevolking ze gebruikt.

Een vaak geciteerd artikel van de Oxford University stelt dat als 60% van de bevolking een contact tracing app gebruikt, dit de epidemie volledig zou kunnen stillegen. Wat echter veel minder geciteerd wordt is het volgende deel van de zin: “zelfs met een lager aantal van gebruikers van de app, schatten we een vermindering in het aantal coronavirusgevallen en het aantal doden”. Ze schatten dat één besmetting kan vermeden worden voor elke 2 gebruikers van de contact tracing app.

Dus zelfs een adoptiegraad van minder dan 60% is nuttig om de curve te helpen afplatten of zelfs naar beneden te halen, waardoor mensenlenvens gered worden.

Zal dit nefast zijn voor het batterijverbruik van mijn telefoon?

Doordat gebruik gemaakt wordt van Bluetooth Low Energy, zou het batterijverbruik beperkt moeten zijn. Bluetooth Low Energy is speciaal ontworpen voor een laag energieverbruik en wordt ook gebruikt om verbinding te maken met smartwatches en draadloze hoofdtelefoons. Het batterijverbruik zou minder dan 5% moeten zijn in vergelijking met een situatie waarin Bluetooth volledig uitgeschakeld is op de telefoon.

Moet ik een andere app installeren als ik naar het buitenland ga?

Met de steun van de Europese Unie werd een gateway service gebouwd die de uitwisseling van keys van besmette personen tussen Europese landen mogelijk maakt. Op 19 oktober 2020 werd deze in gebruik genomen en sindsdien kunnen de Italiaanse (Immuni), Duitse (Corona-Warn-App) en Ierse app (COVID Tracker) hiervan gebruik maken. Het is de bedoeling dat de apps van andere EU-landen deze ondersteuning ook in de toekomst krijgen. Voor de Belgische app Coronalert wordt dit in verwacht tegen november 2020.

Merk op dat er geen uitwisseling mogelijk is met de StopCovid France app omdate deze een gecentraliseerd systeem gebruikt in plaats van het gedecentraliseerde DP-3T.

Wat vinden experts van deze apps?

Het is belangrijk om te herhalen dat DP-3T en dus het Google/Apple Expsoure Notifications framework dat erop gebaseerd is, ontworpen is door academici van universiteiten in verschillende landen. Prof. Bart Preneel (KU Leuven), een cryptograaf die meegewerkt heeft aan het de ontwikkeling van het DP-3T framework, zegt dat “voor één keer Google en Apple kiezen voor de goede kant van de privacy”.

Het British Information Commissioner’s Office (de nationale gegevensbeschermingsauthoriteit) “gelooft dat het CTF (Google/Apple’s contact tracing framework) van bij het ontwerp rekening houdt met de principes van gegevensbescherming, inclusief ontwerpprincipes rond dataminimisatie en veiligheid.

Prof. Douglas Leith (Trinity College Dublin) heeft analyse van het netwerkverkeer van contact tracing apps gedaan. In een rapport besluit hij: “We vinden dat de apps zich over het algemeen goed gedragen op vlak van privacy, alhoewel de privacy van de Ierse, Poolse en Letse apps kan verbeterd worden.” Hij bekritiseerde wel het feit dat het Google/Apple Exposure Notifcations framework niet open source was op dat moment (intussen is de code daarvan wel openbaar) en het feit dat de Google Play Services privégegevens verzenden naar Google (iets dat op alle Androidtelefoons met Google Play Services gebeurt, los van de aanwezigheid van dit framework.)

Analyses van de broncode van de apps zoals deze van Coronalert en deze van Immuni, tonen aan dat de apps geen persoonlijke data bijhouden en versturen.

De grootste kritiek op het framework komt van prof. Serge Vaudenay, cryptograaf van EPFL. Hij klaagt over het feit dat de GAEN (toen nog) closed source was en stelt dat een aantal aanvallen op het systeem mogelijlk zijn. Het DP-3T-team heeft geantwoord op de kritiek.

Conclusie

Vergeet al de samenzweringstheorieën en de bezwaren van privacy-activisten die nooit uitgezocht hebben hoe deze apps werken: gedecentraliseerde open-source contact tracing apps die gebruik maken van de Google/Apple Exposure Notification API zijn geen Big Brother en geen instrument voor massale spionage van de bevolking. Het protocol werd ontwikkeld door academici gespecialiseerd in IT-beveiliging en privacy en de broncode van de apps kan door iedereen nagekeken worden. Uitgebreide documentatie beschrijft de werking van de apps, en legt uit wat er allemaal gedaan wordt om de privacy van de gebruikers te beschermen. Door anonieme ephemerial IDs te gebruiken en geen locatiegegevens te verzamelen, weten deze contact tracing apps minder van u dan de meeste social network apps of dan het besturingssysteem van uw telefoon zelf. Als u zich zorgen maakt om uw privacy, hebt u belangrijkere dingen om u zorgen over te maken.

Contact tracing apps kunnen zeer nuttig zijn in het bestrijden van de epidemie, ook als slechts een klein deel van de bevolking ze gebruikt. Voor mij is het gewoon een kwestie van verantwoordelijkheid waarom ik gebruik maak van deze apps: om anderen te beschermen, om onze maatschappij en economie te beschermen en uiteindelijk om zelf beschermd te worden door anderen die de app gebruiken.

Meer informatie

Geschiedenis van dit artikel

Update 19 september 2020: voeg links naar broncode Coronalert toe – Voeg informatie toe over de implementatie van microg van de API

Update 29 september 2020: voeg informatie over EU gateway service toe

Update 13 oktober 2020: voeg informatie over laagrisico- en hoogrisicontacten in Coronalert toe

Update 19 oktober 2020: EU federation gateway actief in 3 landen

The truth about decentralized contact tracing apps like Immuni

Lees dit artikel in het Nederlands: De waarheid over gedecentraliseerde contact tracing apps zoals Coronalert

Too long to read? Skip to the conclusion.

Table of contents

Those that know me a bit, know that I think that privacy is very important. For this reason when they started talking about contact tracing apps for COVID-19 a few months ago, I thought this was an extremely bad idea. Having an app constantly tracking where you are and who you meet, is only something which you think is possible in undemocratic nations and dictatorial regimes. Something you expect in North Korea, China but not in European countries, where our privacy is supposed to be protected by the GDPR. And then what about the reliability of these apps? Bluetooth was never made for this. It would result in many false positives and negatives. No way I would ever install such an app.

That was at least my opinion a couple of months ago. Now my opinion about this matter has completely changed. Reading about decentralized solutions based on the Google and Apple Exposure Notification (GAEN) API and DP-3T, has completely changed my mind. I use the Italian contact tracing app Immuni and I am willing to use a similar decentralized app from any country where I am staying.

DP-3T

Decentralized Privacy-Preserving Proximity Tracing or DP-3T is an open protocol developed by different universities amongst others ETH and EPFL from Switzerland, KU Leuven from Belgium, Tu Delft from the Netherlands.

This comic shows a simple explanation of how it works.

Comic describing the DP-3T protocol

Technically speaking, every day a new random seed (based on the seed of the day before) is created on every user’s phone, and this daily seed is saved on the phone for 14 days. From this seed are derived ephemeral identifiers (EphIDs). These EphIDs change several times an hour.

EphIDs are exchanged with other users of the tracking app by Bluetooth Low Energy (BLE) and every phone saves the EphIDs he received locally on the phone, together with the date and the attenuation of the signal, which can be used to estimate the distance.

When a user is tested positive for COVID-19, this user can, with the help of authorized health personal, upload the seed of the first day he was contagious, to a central server. All previous daily seeds are deleted from the infected user’s phone, and a completely new random daily seed is created, so that he does not become trackable in the future.

All other app users regularly download a list of all daily seeds of all contagious users from the central server and they can derive all EphIDs from them. The app compares all these EphIDs with the list of stored EphIDs which they met recently. Based on the amount of matching EphIDs the app can calculate how long the two have seen each other and based on the stored attenuation it can estimate the distance. If they were longer than a certain time within a certain distance, a warning will be given to the user that they were exposed to a contagious user, with instructions on what to do.

More details can be found in the DP-3T white paper.

Apple/Google Exposure Notifications API

The Google/Apple Exposure Notifications API (sometimes abbreviated as GAEN) is an API created from a joint effort by Google and Apple and enables the creation of decentralized contact tracing apps. This API, which is based on the principles of the DP-3T protocol described above, can only be used by apps approved by Google and Apple (only one per country, and created by official healthcare instances). Only decentralized contact tracing apps which do not collect any location information can get approved.

Apple by default does not allow background apps to use Bluetooth, except for approved contact tracing apps using this API. This means that on Apple iPhone, this API is the only way to create a reliable contact tracing app. Apps which don’t use this API, such as the StopCovid France app, have to apply work-arounds to keep the app waking up in the background, making them potentially less reliable and draining the battery more.

The DP-3T framework has since been modified to make use of the Exposure Notifications API.

Some of the apps currently available using the Google/Apple Exposure Notifications API are SwissCovid (Switzerland), Immuni (Italy), Corona-Warn-App (Germany).

The source code of the implementation of the framework for Android and iOS of the API were published the second half of July 2020.

Frequently Asked Questions – Debunking some myths

These apps appear to be the subject of deliberate fake news campaigns or at least emotional reactions resulting from a lack of understanding of how they work. Here I will try to address some questions.

Will these apps violate my privacy? Will the authorities know who I meet and where I am, what I do?

The applications based on the Google Apple Exposure Notification API do not know any personal information about the users: they don’t know your name, your phone number, where you live, or any other personal data. They also do not collect location data, so they don’t know where you are.

The only thing these apps do, is exchanging anonymous codes with other people in your neighbourhood. These codes change multiple times a day, making it impossible to keep tracking you.

The exchanged codes are only stored on your own phone and not in a central database. So there is no way for the authorities to know how many people and who you met.

Contact tracing apps usually apply even more extensive kinds of measures to protect security and privacy: for example dummy uploads are done in order to prevent network traffic analysis revealing a positive test, CA or certificate pinning to prevent MITM attacks, etc…

This is not a mass surveillance tool or Big Brother, as some try to let you believe.

How can I be sure that the app really works as promised and really does not collect and send private information?

These apps are usually open source, which means you can check the code to see how they work and what they do exactly. Even if you personally don’t have the knowledge to check the code, rest assured that there are enough experts taking a look at this, and will shout loudly when something is wrong. It has to be said: the only ones shouting loudly about these apps are politicians and activists who clearly have never looked at the source code, nor at the documentation. For example code reviews of Coronalert and Immuni have found these apps do live up to their privacy claims.

Here are some links to the source code of the different apps and their documentation:

On the issue tracker of these apps you can report problems and ask questions.

Also the source code of the Exposure Notifications framework, used by these apps, is available:

Why should I trust Google and Apple, who have a bad track record in privacy?

Actually Google and Apple don’t even need this API to track you. If you are running a phone running iOS or Android with Google Play Services, you actually already have much larger privacy problems than these decentralized, open source contact tracing apps. The same if you are using any of Facebook, Twitter, Instagram, TikTok, NetFlix, Spotify, FaceApp, Tinder. These do know your name, your location, your interests, your friends, and this without this API. Decentralized contact tracing apps, do know much less than any of these apps. This picture compares the different permissions SwissCovid, Facebook and Whatsapp can request.

That being said, there is now a way to run these contact tracing apps without using any Google services on your phone. The microg project now includes its own completely open source implementation of the Exposure Notification API. It can be installed on an Android distribution like LineageOS. It is confirmed that SwissCovid and Immuni work with microg’s implementatoin of the API, probably other apps do too. This way you can run these applications without having to rely on any of Google’s or Apple’s proprietary binaries.

Why does this app require Location setting to be enabled on my Android phone if no location information is collected?

To scan for nearby Bluetooth devices on Android the Location setting needs to be switched on because Bluetooth scanning can in theory be used to determine your location. For example this is used by navigation apps to determine your location in underground tunnels. In reality, apps making use of the GAEN API are not allowed to request your location. It can be verified in the source code of the app that at no time it determines your location. In Settings > Location > App permission you can still disable location access to apps. In Android 11, which came out in September 2020, it is noe required any more to have Location enabled on your device in order to use contact tracing apps based on the Exposure Notification API.

Will this app give me a warning every time an infected person passes nearby, resulting in many false positives?

The apps will only give warnings when certain conditions, usually defined by the government based on epidemiological data, are satisfied. For example, the Italian Immuni app will give a warning when someone is standing within a distance for 2 metres for at least 15 minutes. The SwissCovid app requires a 15 minute contact within 1,5 metre distance. Coronalert will show you also low-risk exposures in the app, however only in case of a high-risk exposure (at least 15 minutes within 1,5 – 2 m of distance) will result in a red screen and an explicit exposure notification. Only in this case a test and quarantine is recommended.

The distance is estimated from the attenuation of the signal. Unfortunately, attenuation will depend on lots of parameters, such as the the phone model being used and the direction in which it is hold, etc. Google adds a per device correction value to the attenuation so that values should be similar between different devices. The thresholds being used are based on experiments in different environments and can be modified in the future in order to lower false positives and negatives. Immuni for example uses an attenuation threshold of 73 dBm.

So no, contact tracing apps are not going to give you a warning when anyone who shortly passed nearby, is tested positive. Only when reasonable thresholds are exceeded, you will get a warning. Nevertheless, false positive and false negatives are possible. Authorities also realize this, and view the tracing app as a support tool for tracing, but not as a complete replacement for manual contact tracing. A contact tracing app also does not replace a diagnostic test.

Are these apps useful if not everyone or at least a large part of the population downloads them?

Contact tracing apps are certainly useful, even if only a part of the population uses them.

A highly quoted article from Oxford University states that if 60% of the population installs the contact tracing app, this can completely stop the epidemic. However what is often not quoted is the next part of the phrase: “even with lower numbers of app users, we still estimate a reduction in the number of coronavirus cases and deaths.” They estimate that that one infection will be averted for every one to two users.

So even much lower numbers than 60% are useful to help flattening or crushing the curve, saving lives.

Will this drain the battery of my phone?

By using Bluetooth Low Energy, battery consumption should be limited. Bluetooth Low Energy was created specifically for low energy consumption and is also being used to connect to smartwatches and wireless headphones. Battery consumption should be less than 5% in the worst case, if you otherwise did have Bluetooth completely disabled.

Do I need to install another app when I go abroad?

With support of the European Union, a gateway service has been built that allows the exchange of keys of infected persons between European countries. The 19th of October 2020 the Italian (Immuni), German (Corona-Warn-App) and the Irish app (StopCOVID Tracker) started using this. It is planned that other decentralized contact tracing apps of the European Union will connect to this this gateway too, for example the Belgian Coronalert will add support in November.

However note that keys can never be exchanged with the StopCovid France app because this one uses a centralized system instead of the decentralized DP-3T.

What do experts say about these apps?

First it’s important to repeat that DP-3T, and hence the Google/Apple Exposure Notifications framework based on it, were designed by academics from universities in different countries. Prof. Bart Preneel (KU Leuven), cryptographer, who contributed to the DP-3T framework, says that “for once, Google and Apple are on the right side of privacy“.

The British Information Commissioner’s Office (the national data protection authority) “believes the CTF (Google/Apple’s contact tracing framework) is aligned with the principles of data protection by design and by default, including design principles around data minimisation and security.”

In a report from prof. Douglas Leith (Trinity College Dublin), analysis of network traffic of contact tracing apps was done. He concludes: “We find that the health authority client apps are generally well behaved from a privacy point of view, although the privacy of the Irish, the Polish and Latvian apps could be improved.” They criticize the closed source nature of the Google/Apple Exposure Notifications framework though and the fact that Google Play Services sends private data to Google (something which happens on any Android phone having Google Play Services installed, irrespective of the presence and usage of this framework). Update 23 July 2020: the source code of the framework itself is now available.

The biggest criticism of the framework appears to come from prof. Serge Vaudenay, cryptographer of EPFL. He complains about the closed source nature of the GAEN, and the fact that some attacks are possible. There is an answer by the DP3T team to one of his papers. Update 23 July 2020: the source code of the GAEN framework itself is now available.

Conclusion

Forget all conspiracy theories and emotional objections by privacy activists who never looked at how these apps work: open source decentralized contact tracing apps making use of the Google/Apple Exposure Notification API are not Big Brother, no mass surveillance instrument. The protocol has been developed by academics specialized in security and privacy in IT and the source code of the apps can be verified by anyone. Extensive documentation describes the working of the apps and what is being done to protect the privacy of the users. By using anonymous ephemeral IDs and not collecting any location information, these contact tracing apps know less from you than the average social network app or your phone’s OS itself, so if you are worried about privacy, you have more important things to look at.

Contact tracing apps can be very useful in combating this epidemic, also if only a small part of the population is using them. For me it’s simply a matter of responsibility installing these apps: to protect others, to protect our society and economy and in the end to get protected myself by others using the app.

Further information

History of this article

Update 23 July 2020: Added links to the source of Google and Apple Exposure Notifications framework – Added info about Belgian contact tracing app in development – Added link to picture comparing permissions requested by SwissCovid, Facebook and Whatsapp

Update 6 September 2020: Added question about Location requirement on Android phones

Update 19 September 2020: Added link to source code of Belgian Coronalert app – Added info about an Expsore Notifications API implementation in microg, enabling you to run these apps without Google services

Update 4 October: add information about EU gateway service

Update 19 October: EU federation gateway service in use by 3 apps

Which DNS server to use?

Update 4 August 2020: replace CHAOS class by CH in dig commands so they work with kdig too, Quad9 now does support QNAME minimisation, Quad9 has alternative servers available with ECS support and without QNAME minimisation, Google now also does QNAME minimisation.

DNS is a crucial part of the Internet. However DNS traffic is usually not encrypted and can leak lots of interesting information and originally DNS also did not provide date integrity, making it vulnerable to DNS spoofing.

These days, improvements are being made to fix these problems. Data integrity is proved by DNSSEC and the privacy part is being tackled by the DNS Privacy project, proposing solutions like DNS-over-TLS (all data between resolver and client is encrypted) and QNAME minimisation (not sending the FQDN but only the relevant part to each DNS server when doing recursive resolving). More information about the DNS Privacy project can be found in this Fosdem 2018 talk.

There are basically 3 options for DNS on your client systems:

  1. You forward all requests to your ISP’s DNS servers (which is what is usually done by default).
  2. You forward all requests to a public global DNS service, like Cloudlfare’s 1.1.1.1, Quad9 or Google DNS.
  3. You set up your own DNS recursor which connects itself to authoritative DNS servers.

ISP’s default DNS servers

Quite often the problem with your ISP’s DNS servers, is that they don’t support DNSSEC and QNAME minmisation. There is an online test to check whether your DNS server does DNSSEC validation. To test whether QNAME minimisation is enabled for your current resolver, use this command:

$ dig +nodnssec +short TXT qnamemintest.internet.nl

(replace dig by kdig if you are using Knot’s DNS utils)

Some (mostly American) ISPs serve redirect pages when you enter an unexisting domain name and they often block hosts with content which is illegal in your country (child pornography, sites helping with copyright infringement, illegal gambling sites,…). In less democratic countries local DNS server are abused for censorship.

These might all be reasons in order to not to use your ISP’s DNS servers.

But at least in Europe, ISPs should be restricted by the GDPR to sell DNS data. And your ISP’s DNS servers prevent a single point of failure, a single point of data collection, and a single point of censorship. So there are advantages too.

Public global DNS services

The popular global public DNS services all support DNSSEC by default and you can connect to them using encrypted DNS-over-TLS. Some also do QNAME mimisation.

These public global DNS providers are often praised for their speed. You can find result of benchmarks of public DNS resolvers on dnsperf.com. You can also use namebench to benchmark different DNS servers . For example:

$ namebench 1.1.1.1 8.8.8.8 9.9.9.9 -x -O

You want your DNS resolver to be as close to you as possible, especially if your DNS server does not support EDNS Client Subnet (ECS). This is a method which allows a DNS recursor to send the subnet of the client to the authoritative DNS server. This is used by content delivery networks to provide you with the IP of the nearest server serving the requested content. Many privacy oriented DNS services do not support ECS, so the only information the authoritative DNS server has, is the location of your recursor. If that recursor is far away from you, this will lead to the client being sent to a far away server of the content delivery network, leading to much slower access to the content. For this reason, you should rather not use a DNS server in a foreign country, but use one which is as close as possible to your location. You can check how many hops a server is from you using the traceroute or mtr command, for example

$ mtr --report-wide 1.1.1.1

More information about this issue can be found in the blog post “Using Cloudflare’s 1.1.1.1 might lead to slower CDN performance” by Sajal Kayan.

Also for privacy reasons you would also prefer to have one in your own country, so that it’s not susceptible to legislation of a foreign country. Often, countries have a more relaxed legislation regarding spying on foreign connections.

That brings us to the last, but not least consideration: the privacy policy of the DNS service you are using. Are DNS requests being logged, for how long, and are they shared with a third party? On the PowerDNS blog there is a more elaborate article on the risks of using global DNS providers.

Your own DNS recursor

Then there is the third alternative to using a global public DNS service or your ISP’s DNS servers: running your own local recursive DNS resolver, for example with Knot Resolver. If you DNS server is well configured, it will provide you with DNSSEC validation and QNAME minimisation. However this has a serious privacy disadvantage too because this will reveal your own IP to all authoritative servers you connect to. Furthermore connections to authoritative DNS servers currently are always unencrypted, so your ISP and anyone between you and the authoritative server can see your DNS queries.

Overview of public DNS servers

In case you have decided for whatever reason you do not want to use your ISP’s DNS servers and also don’t want to do recursion yourself, there are many public DNS recursors. On the dnsprivacy.org website you can also find a list of public DNS resolvers and experimental servers with support for DNS-over-TLS. I will review a few of the most important ones here.

Cloudflare

Cloudflare‘s DNS service running on the 1.1.1.1 IP address appears to be the fastest in most cases. Unlike some other services, they do have a local server here in Brussels, which likely contributes to the great performance here. You can check which server you would be using by running this command:

$ dig +short CH TXT id.server @1.1.1.1

You can look up the three-letter code on https://www.cloudflarestatus.com/ (these are IATA codes of nearby airports). Cloudflare does not support EDNS Client Subnet, so make sure there is a server nearby when using 1.1.1.1. Cloudflare claims privacy to be one of their main advantages but in their privacy policy they admit that they share certain antonymous data with APNIC (the organization managing the IP addresses in Asia and the Pacific) for research. Cloudflare does support DNSSEC and QNAME minimisation.

Quad9

Quad9, running on the 9.9.9.9 IP address, is a DNS service set up by a nonprofit organization supported by the Global Cyber Alliance, IBM and PCH together in collaboration with other security partners. Their main feature is that they block malicious hosts (like phishing sites), improving security for your devices. Like Cloudflare, Quad9 shares some anonymized data with their threat-intelligence partners for security analysis.

In 2020, Quad9 had servers in 150 locations in 90 countries. Unfortunately there is no server in Belgium. Probably because of this, resolving of domains which DNS server is located in Belgium, is slower in the few tests I did. Because it also does not support ECS, it might not forward you to the nearest content location. You can check with the same command as Cloudflare which DNS server of Quad9 is in use for your location:

$ dig +short CH TXT id.server @9.9.9.9

You can see all locations where Quad9 does have a DNS cluster on the Quad9 website.

Quad9 does DNSSEC validation and now also supports QNAME minimisation.

However, Quad9 also does have alternative DNS servers (9.9.9.11) available which supports ECS. You can use these to get nearby hosts if Quad9 does not have a server in your country. However note that these alternative servers do not support QNAME minimisation. So by using ECS and disabling QNAME miminisation, more information is leaked to DNS servers.

Google

Google Public DNS, running on 8.8.8.8, appears to be the most public DNS service in use globally. According to SIDN (the registry maintaining the .nl domain), 15% of the requests come from Google’s public DNS servers. That’s probably because it’s around longer than many others (started in December 2009). Also systemd-resolved uses Google’s DNS as a fallback of there are no working default DNS servers set up. This is configured in /etc/systemd/resolved.conf.

Google supports ECS. The list of locations where it has servers can be found in the FAQ.

Google stores request logs a bit longer than some others, some even permanently. These days also more and more people distrust Google with their private data. Google DNS does DNSSEC validation, and now also QNAME minimisation.

OpenDNS

OpenDNS was already launched in 2006 and was acquired by Cisco in 2015. They have been redirecting unexisting domains to a custom search page with advertisements, but stopped doing so in 2014. OpenDNS has optional filtering of adult domains and other unwanted content.

OpenDNS seems to have less servers world-wide than the other services., but they do support ECS though.

Conclusion

Which of all these options to choose, is a personal decision. Personally I think that running your own recursor on your own computer is a bad idea. All authoritative name servers will see your personal IP, and your unencrypted queries can be easily monitored by your ISP. I think this should only be considered if you are setting up a DNS server for a fairly large number of clients.

My own ISP does not support DNSSEC and QNAME minimisation. I think these two are crucial features to protect the user’s privacy and for this reason I prefer to use one of the public DNS services. I have set up Knot Resolver to forward DNS requests to Cloudflare’s DNS service over TLS. Not only does it support QNAME minimisation in addition to DNSSEC and DNS-over-TLS, it is fast and has a local server in Belgium. Combine this with the abuse.ch urlhaus RPZ file to add some protection from malicious domains. More details about this can be found in my previous blog post Secure and private DNS with Knot Resolver. I also use this set up on the network I manage at work.

Secure and private DNS with Knot Resolver

Update 5 March 2018: this post was updated to work around a problem with the RPZ file from abuse.ch being ignored because it contains CRLF instead of LF where Knot Resolver does not expect them (bug 453) and to fix an error in the configuration of the predict module.

Knot Resolver is a modern, feature-rich recursive DNS server. It is used by Cloudflare for its 1.1.1.1 public DNS service.

To install it on Debian, run:

# apt-get install knot-resolver knot-dnsutils lua-cqueues

The knot-dnsutils contains the kdig command which is useful for testing your DNS server. lua-cqueues is needed for automatic detection of changes in the RPZ file.

By default the kresd daemon will listen on localhost only (see /lib/systemd/system/kresd.socket). If you want it to be available on other addresses, you will need to override the kresd.socket file. Execute

# systemctl edit kresd.socket

This will create the file /etc/systemd/system/kresd.socket.d/override.conf. Add a ListenStream and ListenDatagram line for all addresses you want it to listen on. For example:

[Socket]
ListenStream=127.0.0.1:53
ListenDatagram=127.0.0.1:53
 
ListenStream=[::1]:53
ListenDatagram=[::1]:53
 
ListenStream=192.168.0.1:53
ListenDatagram=192.168.0.1:53

If you want to listen on all interfaces, it is enough to put this in the file:

ListenStream=53
ListenDatagram=53

You can do the same with kresd-tls.socket to define the addresses on which to listen over DNS-over-TLS requests (port 853).

Knot Resolver’s configuration file is /etc/knot-resolver/kresd.conf. I give an example configuration file with comments:

-- Default empty Knot DNS Resolver configuration in -*- lua -*-
-- Switch to unprivileged user --
user('knot-resolver','knot-resolver')

-- Set the size of the cache to 1 GB
cache.size = 1*GB

-- Uncomment this only if you need to debug problems.
-- verbose(true)

-- Enable optional modules
modules = {
  'policy',
  'view',
  'hints',
  'serve_stale < cache',
  'workarounds < iterate',
  'stats',
  'predict'
}

-- Accept all requests from these subnets
view:addr('127.0.0.1/8', function (req, qry) return policy.PASS end)
view:addr('[::1]/128', function (req, qry) return policy.PASS end)
view:addr('134.184.26.1/24', function (req, qry) return policy.PASS end)

-- Drop everything that hasn't matched
view:addr('0.0.0.0/0', function (req, qry) return policy.DROP end)

-- Use the urlhaus.abuse.ch RPZ list
policy.add(policy.rpz(policy.DENY, '/etc/knot-resolver/abuse.ch.rpz',true))


-- Forward all requests for example.com to 192.168.0.2 and 192.168.0.3
policy.add(policy.suffix(policy.FORWARD({'192.168.0.2', '192.168.0.3'}), {todname('example.com')}))

-- Uncomment one of the following stanzas in case you want to forward all requests to 1.1.1.1 or 9.9.9.9 via DNS-over-TLS.

-- policy.add(policy.all(policy.TLS_FORWARD({
--          { '1.1.1.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/ca-certificates.crt' },
--          { '2606:4700:4700::1111', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/ca-certificates.crt' },
-- 
-- })))

-- policy.add(policy.all(policy.TLS_FORWARD({
--           { '9.9.9.9', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt' },
--           { '2620:fe::fe', hostname='dns.quad9.net', ca_file='/etc/ssl/certs/ca-certificates.crt' },
-- })))

-- Prefetch learning (20-minute blocks over 24 hours)
predict.config({ window = 20, period = 72 })

I use the urlhaus.abuse.ch RPZ file, which contains a blacklist of malicious domains. You will have to download it first:

# cd /etc/knot-resolver
# curl https://urlhaus.abuse.ch/downloads/rpz/ | sed -e 's/\r$//' -e '/raw.githubusercontent.com/d'> /etc/knot-resolver/abuse.ch.rpz

I use sed to convert CRLF in LF (otherwise Knot Resolver fails to parse the file), and I filter out raw.githubusercontent.com. According to urlhaus.abuse.ch it hosts some malware, but there is too much useful stuff there too to block the domain completely.

In order to update it automatically, create /etc/systemd/system/update-urlhaus-abuse-ch.service:

[Unit]
Description=Update RPZ file from urlhaus.abuse.ch for Knot Resolver

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'curl https://urlhaus.abuse.ch/downloads/rpz/ | sed -e 's/\r$//' -e '/raw.githubusercontent.com/d'> /etc/knot-resolver/abuse.ch.rpz'

and then create a timer which will run the service approximately every 10-15 minutes./etc/systemd/system/update-urlhaus-abuse-ch.timer:

[Unit]
Description=Update RPZ file from urlhaus.abuse.ch for Knot Resolver

[Timer]
OnCalendar=*:0/10
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

Use the first two commands to enable and start the timer. You can check the status using the last command:

# systemctl enable update-urlhaus-abuse-ch.timer
# systemctl start update-urlhaus-abuse-ch.timer
# systemctl list-timers

Now you need to enable and start one or more instances of kresd. kresd is single-threaded, so if you want to make use of all of your CPU cores, you can start as many instances as the numbers of cores you have. For example in order to enable and start 4 instances run this command:

# systemctl enable --now kresd@{1..4}.service

More information

Running different PHP applications as different users

Often you run different web applications on the same web servers. For security reasons, it is strongly recommended to run them in separate PHP-FPM processes under different user accounts. This way permissions can be set so that the user account of one PHP application, cannot access the files from another PHP application. Also open_basedir can be set so that accessing any files outside the base directory becomes impossible.

To create a separate PHP-FPM process for a PHP application on Debian Stretch with PHP 7.0, create a file /etc/php/7.0/fpm/pool.d/webapp.conf with these contents:

[webapp]
user = webapp_php
group = webapp_php
listen = /run/php/php7.0-webapp-fpm.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 12
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 2
pm.max_requests = 5000
rlimit_core = unlimited
php_admin_value[open_basedir] = /home/webapp/public_html

Replace webapp by a unique name for your web application. You can actually copy the default www.conf file and adapt it to your needs.

Create the webapp_php, with /bin/false as shell and login disabled to secure it against login attacks:

# adduser --system --disabled-login webapp_php --shell /bin/false --no-create-home --home /home/webapp webapp_php

In the above example the webapp is located in /home/webapp, but you can of course also use a directory somewhere in /var/www.

I strongly recommend against making all your PHP files in /home/webapp owned by webapp_php. This is a dangerous situation, because PHP can overwrite the code itself. This makes it possible for malware to overwrite your PHP files with malicious code. Only make the directories where PHP really needs to be able to write into (for example a directory where files uploaded in your web applications are stored), writable for the webapp_php user. Your code itself should be owned by a different user than webapp_php. It can be a dedicated user account, or just root.

Finally we need to configure Apache to contact the right php-fpm instance for the web application. Create a file /etc/apache2/conf-available/php7.0-webapp-fpm.conf:

&lt;Directory /home/webapp/public_html&gt;

# Redirect to local php-fpm if mod_php is not available
    &lt;IfModule proxy_fcgi_module&gt;
        # Enable http authorization headers
        &lt;IfModule setenvif_module&gt;
        SetEnvIfNoCase ^Authorization$ &quot;(. )&quot; HTTP_AUTHORIZATION=$1
        &lt;/IfModule&gt;

        &lt;FilesMatch &quot;. \.ph(p[3457]?|t|tml)$&quot;&gt;
            SetHandler &quot;proxy:unix:/run/php/php7.0-webapp-fpm.sock|fcgi://localhost-webapp&quot;
        &lt;/FilesMatch&gt;
        &lt;FilesMatch &quot;. \.phps$&quot;&gt;
            # Deny access to raw php sources by default
            # To re-enable it's recommended to enable access to the files
            # only in specific virtual host or directory
            Require all denied
        &lt;/FilesMatch&gt;
        # Deny access to files without filename (e.g. '.php')
        &lt;FilesMatch &quot;^\.ph(p[3457]?|t|tml|ps)$&quot;&gt;
            Require all denied
        &lt;/FilesMatch&gt;
    &lt;/IfModule&gt;
&lt;/Directory&gt;

This file is based on the default php7.0-fpm.conf. You will need to create a symlink to make sure this gets activated:

# cd /etc/apache2/conf-enabled
# ln -s ../conf-available/php7.0-webapp-fpm.conf .

Now restart your Apache and PHP-FPM services and you should be ready. You can see the user your code in /home/webapp/public_html is being run as in the output of the phpinfo() function.


Linux security hardening recommendations

In a previous blog post, I wrote how to secure OpenSSH against brute force attacks. However, what if someone manages to get a shell on your system, despite all your efforts? You want to protect your system from your users doing nasty things? It is important to harden your system further according to the principle of defense in depth in order.

Software updates

Make sure you are running a supported distribution, and by preference the most recent version one. For example, Debian Jessie is still supported, however upgrading to Debian Stretch is strongly recommended, because it offers various security improvements (more recent kernel with new security hardening, PHP 7 with new security related features, etc…)

Install amd64-microcode (for AMD CPU’s) or intel-microcode (for Intel CPU’s) which are needed to protect against hardware vulnerabilities such as Spectre, Meltdown and L1TF. I recommend installing it from stretch-backports in order to have the latest firmware.

Automatic updates and needrestart

I recommend installing unattened-upgrades . You can configure it to just download updates or to download and install them automatically. By default, unattended-upgrades will only install updates from the official security repositories. This way it is relatively safe to let it do this automatically. If you have already installed it, you can run this command to reconfigure it:

# dpkg-reconfigure unattended-upgrades

When you update system libraries, you should also restart all daemons which are using these libraries to make them use the newly installed version. This is exactly what needrestart does. After you have run apt-get, it will check whether there are any daemons running with older libraries, and will propose you to restart them. If you use it with unattended-upgrades, you should set this option in /etc/needrestart/needrestart.conf to make sure that all services which require a restart are indeed restarted:

$nrconf{restart} = 'a';

Up-to-date kernel

Running an up-to-date kernel is very important, because also the kernel can be vulnerable. In the worst case, an outdated kernel can be exploited to gain root permissions. Do not forget to reboot after updating the kernel.

Every new kernel version also contains various extra security hardening measures. Kernel developer Kees Cook has an overview of security related changes in the kernel.

In case you build your own kernel, you can use kconfig-hardened-check to get recommendation for a hardened kernel configuration.null

Firewall: filtering outgoing traffic

It is very obvious to install a firewall which filters incoming traffic. However, have you considered also filtering outgoing traffic? This is a bit more difficult to set up because you need to whitelist all outgoing hosts to which connections are needed (I think of your distribution’s repositories, NTP servers, DNS servers,…), but it is a very effective measure which will help limiting damage in case a user account gets compromised, despite all your other protective efforts.

Ensuring strong passwords

Prevent your users from setting bad passwords by installing libpam-pwquality, together with some word lists for your language and a few common languages. These will be used for verifying that the user is not using a common word as his password. libpam-quality will be enabled automatically after installation with some default settings.

# apt-get install libpam-pwquality wbritish wamerican wfrench wngerman wdutch

Please note that by default, libpam-pwquality will only enforce strong passwords when a non-root user changes its password. If root is setting a password, it will give a warning if a weak password is set, but will still allow it. If you want to enforce it for root too (which I recommend), then add enforce_for_root in the pam_pwquality line in /etc/pam.d/common-password:

password	requisite			pam_pwquality.so retry=3 enforce_for_root

Automatically log out inactive users

In order to log out inactive users, set a timeout of 600 seconds on the Bash shell. Create /etc/profile.d/tmout.sh:

export TMOUT=600
readonly TMOUT

Prevent creating cron jobs

Make sure users cannot set cron jobs. In case an attacker gets a shell on your system, often cron will be used to ensure the malware continues running after a reboot. In order to prevent normal users to set up cron jobs, create an empty /etc/cron.allow.

Protect against fork bombs and excessive logins and CPU usage

Create a new file in /etc/security/limits.d to impose some limits to user sessions. I strongly recommend setting a value for nproc, in order to prevent fork bombs. maxlogins is the maximum number of logins per user, and cpu is used to set a limit on the CPU time a user can use (in minutes):

*	hard	nproc		1024
*	hard	maxlogins 	4
1000:	hard	cpu		180

Hiding processes from other users

By mounting the /proc filesystem with the hidepid=2 option, users cannot see the PIDs of processes by other users in /proc, and hence these processes also become invisible when using tools like top and ps. Put this in /etc/fstab to mount /proc by default with this option:

none	/proc	proc	defaults,hidepid=2	0	0

Restricting /proc/kallsyms

It is possible to restrict access to /proc/kallsyms at boot time by setting 004 permissions. Put this in /etc/rc.local:

chmod 400 /proc/kallsyms

/proc/kallsyms contains information about how the kernel’s memory is laid out. With this information it becomes easier to attack the kernel itself, so hiding this information is always a good idea. It should be noted though that attackers can get this information from other sources too, such as from the System.map files in /boot.

Harden kernel configuration with sysctl

Several kernel settings can be set at run time using sysctl. To make these settinsg permanent, put these settings in files with the .conf extension in /etc/sysctl.d.

It is possible to hide the kernel messages (which can be read with the dmesg command) from other users than root by setting the sysctl kernel.dmesg_restrict to 1. On Debian Stretch and later this should already be the default value:

kernel.dmesg_restrict = 1

From Linux kernel version 4.19 on it’s possible to disallow opening FIFOs or regular files not owned by the user in world writable sticky directories. This setting would have prevented vulnerabilities found in different user space programs the last couple of years. This protection is activated automatically if you use systemd version 241 or higher with Linux 4.19 or higher. If your kernel supports this feature but you are not using systemd 241, you can activate it yourself by setting the right sysctl settings:

fs.protected_regular = 1
fs.protected_fifos = 1

Also check whether the following sysctl’s have the right value in order to enable protection hard links and symlinks. These work with Linux 3.6 and higher, and likely will already be enabled by default on your system:

fs.protected_hardlinks = 1
fs.protected_symlinks = 1

Also by default on Debian Stretch only root users can access perf events:

kernel.perf_event_paranoid = 3

Show kernel pointers in /proc as null for non-root users:

kernel.kptr_restrict = 1

Disable the kexec system call, which allows you to boot a different kernel without going through the BIOS and boot loader:

kernel.kexec_load_disabled = 1

Allow ptrace access (used by gdb and strace) for non-root users only to child processes. For example strace ls will still work, but strace -p 8659 will not work as non-root user:

kernel.yama.ptrace_scope = 1

The Linux kernel includes eBPF, the extended Berkeley Packet Filter, which is a VM in which unprivileged users can load and run certain code in the kernel. If you are sure no users need to call bpf(), it can be disabled for non-root users:

kernel.unprivileged_bpf_disabled = 1

In case the BPF Just-In-Time compiler is enabled (it is disabled by default, see sysctl net/core/bpf_jit_enable), it is possible to enable some extra hardening against certain vulnerabilities:

net.core.bpf_jit_harden = 2

Take a look at the Kernel Self Protection Project Recommended settings page to find an up to date list of recommended settings.

Lynis

Finally I want to mention Lynis, a security auditing tool. It will check the configuration of your system, and make recommendations for further security hardening.

Further ideas

Securing OpenSSH

Security hardening the OpenSSH server is one of the first things that should be done on any newly installed system. Brute force attacks on the SSH daemon are very common and unfortunately I see it going wrong all too often. That’s why I think it’s useful to give a recapitulation here with some best practices, even though this should be basic knowledge for any system administrator.

Firewall

The first thing to think about: should the be SSH server be accessible from the whole world, or can we limit it to certain IP addresses or subnets. This is the most simple and effective form of protection: if your SSH daemon is is only accessible from specific IP addresses, then there is no risk any more from attacks coming from elsewhere.

I prefer to use Shorewall as a firewall, as it’s easy to configure. Be sure to also configure shorewall6 if you have an IPv6 address.

However as defense in depth is an essential security practice, you should not stop here even if you protected your SSH daemon with a firewall. Maybe your firewall one day fails to come up at boot automatically, leaving your system unprotected. Or maybe one day the danger comes from within your own network. That’s why in any case you need to carefully review the next recommendations too.

SSHd configuration

Essential security settings

The SSH server configuration can be found in the file /etc/ssh/sshd_config. We review some essential settings:

  • PermitRootLogin: I strongly recommend setting this to No. This way, you always log in to your system with a normal user account. If you need root access, use su or sudo. The root account is then protected from brute force attacks. And you can always easily find out who used the root account.
  • PasswordAuthentication: This setting really should be No. You will first need to add your SSH public key to your ~/.ssh/authorized_keys . Disabling password authentication is the most effective protection against brute force attacks.
  • X11Forwarding: set this to No, except if your users need to be able to run X11 (graphical) applications remotely.
  • AllowTcpForwarding: I strongly recommend setting this to No. If this is allowed, any user who can ssh into your system, can establish connections from the client to any other system using your host as a proxy. This is even the case even if your users can only use SFTP to transfer files. I have seen this being abused in the past to connect to the local MTA and send spam via the host this way.
  • PermitOpen: this allows you to set the hosts to which TCP forwarding is allowed. Use this if you set AllowTcpForwarding to indicate to which hosts TCP forwarding is limited.
  • ClientAliveInterval, ClientAliveCountMax: These values will determine when a connection will be interrupted when it’s unresponsive (for example in case of network problems). I set ClientAliveInterval to 600 and ClientAliveCountMax to 0. Note that this does not drop the connection when the user is simply inactive. If you want to set a timeout for that, you can set the TMOUT environment variable in Bash.
  • MaxAuthTries: the maximum number of authentication attempts permitted per connection. Set this to 3.
  • AllowUsers: only the users in this space separated list are allowed to log in. I strongly recommend using this (or AllowGroups) to whitelist users that can log in by SSH. It protects against possible disasters when a test user or a system users with a weak password is created.
  • AllowGroups: only the users from the groups in this space separated list are allowed to log in.
  • DenyUsers: users in this space separated list are not allowed to log in
  • DenyGroups: users from the groups in this space separated list are not allowed to log in.
  • These values should already be fine by default, but I recommend verifying them: PermitEmptyPasswords (no), UsePrivilegeSeparation (sandbox), UsePAM (yes), PermitUserEnvironment (no), StrictModes (yes), IgnoreRhosts (yes)

So definitely disable PasswordAuthentication and TCP and X11 forwarding by default and use the AllowUsers or AllowGroups to whitelist who is allowed to log in by SSH.

Match conditional blocks

With Match conditional blocks you can modify some of the default settings for certain users, groups or IP addresses. I give a few examples to illustrate the usage of Match blocks.

To allow TCP forwarding to a specific host for one user:

Match User username
        AllowTcpForwarding yes
        PermitOpen 192.168.0.120:8080

To allow PasswordAuthentication for a trusted IP address (make sure the user has a strong password, even if you trust the host!) :

Match Address 192.168.0.20
        PasswordAuthentication yes

The Address can also be a subnet in CIDR notation, such as 192.168.0.0/24.

To only allow SFTP access for a group of users, disabling TCP, X11 and streamlocal forwarding:

Match group sftponly
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no
        AllowStreamLocalForwarding no

chroot

You can chroot users to a certain directory, so that they cannot see and access what’s on the file system outside that directory. This is a a great way to protect your system for users who only need SFTP access to a certain location. For this to work, you need to make the user’s home directory being owned by root:root. This means they cannot write directly in their home directory. You can create a subdirectory within the user’s home directory with the appropriate ownership and permissions where the user can write into. Then you can use a Match block to apply this configuration to certain users or groups:

Match Group chrootsftp
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
        X11Forwarding no
        AllowStreamLocalForwarding no

If you use authentication with keys, you will have to set a custom location for the authorized_keys file:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u .ssh/authorized_keys

Then the keys for every user have to be installed in a file /etc/ssh/authorized_keys/username

Fail2ban

Fail2ban is a utility which monitors your log files for failed logins, and will block IPs if too many failed log in attempts are made within a specified time. It cannot only watch for failed login attempts on the SSH daemon, but also watch other services, like mail (IMAP, SMTP, etc.) services, Apache and others. It is a useful protection against brute force attacks. However, versions of Fail2ban before 0.10.0, only support IPv4, and so don’t offer any protection against attacks from IPv6 addresses. Furthermore, attackers often slow down their brute force attacks so that they don’t trigger the Fail2ban threshold. And then there are distributed attacks: by using many different source IPs, Fail2ban will never be triggered. For this reasons, you should not rely on Fail2ban alone to protect against brute force attacks.

If you want to use Fail2ban on Debian Stretch, I strongly recommend using the one from Debian-backports, because this version has IPv6 support.

# apt-get install -t stretch-backports fail2ban python3-pyinotify python3-systemd

I install python3-systemd in order read the log messages from Systemd’s Journal, while python3-pyinotify is needed to efficiently watch log files.

First we will increase the value for dbpurgeage which is set to 1 day in /etc/fail2ban/fail2ban.conf. We can do this by creating the file /etc/fail2ban/fail2ban.d/local.conf:

[Definition]
dbpurgeage = 10d

This lets us ban an IP for a much longer time than 1 day.

Then the services to protect, the thresholds and the action to take when these are exceeded are defined in /etc/fail2ban/jail.conf. By default all jails, except the sshd jail, are disabled and you have to enable the ones you want to use. This can be done by creating a file /etc/fail2ban/jail.d/local.conf:

[DEFAULT]
banaction = iptables-multiport
banaction_allports = iptables-allports
destemail = email@example.com
sender = root@example.com

[sshd]
mode = aggressive
enabled = true
backend = systemd

[sshd-slow]
filter   = sshd[mode=aggressive]
maxretry = 10
findtime = 3h
bantime  = 8h
backend = systemd
enabled = true

[recidive]
enabled=true
maxretry = 3
action = %(action_mwl)s

First we override some default settings valid for all jails. We configure it to use iptables to block banned users. If you use Shorewall as firewall, then set banaction and banaction_allports to shorewall in order to use the blacklist functionality of Shorewall. In that case, read the instructions in /etc/fail2ban/action.d/shorewall.conf to configure Shorewall to also block established blacklisted connections. Other commonly used values for banactions and banactions_allports are ufw and firewallcmd-ipset, if you use UFW respectively Firewalld. We also define the sender address and destination address where emails should be sent when a host is banned.

Then we set up 3 jails. The sshd and recidive jail are jails which are already defined in /etc/fail2ban/jails.conf and we enable them here. The sshd jail will give a 10 minute ban to IPs which do 5 unsuccessful login attempts on the SSH server in a time span of 10 minutes. The recidive jail gives a one week ban to IPs getting banned 3 times by another Fail2ban jail in a time span of 1 day. Furthermore I define another jail sshd-slow, which gives a 8 hour ban to IPs doing 10 failed attempts on the SSH server in a time span of 3 hours. This catches many attempts which try to evade the default Fail2ban settings by slowing down their brute force attack. In both the sshd and sshd-slow jails I use the aggressive mode which catches more errors, such as probes without trying to log in, and attempts with wrong (outdated) ciphers. See /etc/fail2ban/filter.d/sshd.conf for the complete lists of log message it will search for. The recidive jail will sent a mail to the defined address in case a host gets banned. I enable this only for recidive in order not to receive too much e-mails.

Two-factor authentication

It is possible to enable two-factor authentication (2FA) using the libpam-google-authenticator package. Then you can use an application like FreeOTP+ (Android), AndOTP (Android), Authenticator (iOS), KeepassXC (Linux) to generate the time based token you need to log in.

First install the required PAM module on your SSH server:

# apt-get install libpam-google-authenticator

Then edit the file /etc/ssh/sshd_config:

ChallengeResponseAuthentication yes
AuthenticationMethods publickey keyboard-interactive:pam

You can also put this in a Match block to only enable this for certain users or groups.

This will allow you to log in with either key based authentication, either by password and your time-based token.

Now you need to set up the new secret for the user account you want to use OTP authentication using the google-authenticator command. Run it as the user. Choose time-based authentication tokes, disallow multiple uses of the same authentication token, and don’t choose to increase the time window to 4 minute and enable rate-limiting.

$ google-authenticator
Do you want authentication tokens to be time-based (y/n) y
                                                          
Do you want me to update your "/home/username/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, tokens are good for 30 seconds. In order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with
poor time synchronization, you can increase the window from its default
size of +-1min (window size of 3) to about +-4min (window size of
17 acceptable tokens).
Do you want to do so? (y/n) n

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Now enter the code given by this command in your OTP client or scan the QR code.

Edit the file /etc/pam.d/sshd and add this line:

auth required pam_google_authenticator.so noskewadj

You need to make sure to add this line before the line

@include common-auth

Otherwise an attacker can still brute force the password, and then abuse it on other services. That is because of the auth requisite pam_deny.so line in common-auth: this will immediately return a failure message when the password is wrong. The time-based token would only be asked when the password is correct.

The noskewadj option increases security by disabling the option to automatically detect and adjust time skew between client and server.

Now restart the sshd service, and in another shell, try the OTP authentication. Don’t close your existing SSH connection yet, because otherwise you might lock yourself out if something went wrong.

The biggest disadvantage of pam_googleauthenticator is that it allows every individual user to set values for the window size, rate limiting, whether to use HOTP or TOTP, etc. By modifying some of these, the user can reduce the security of the one-time-password. For this reason, I recommend only enabling this for users you trust.

Living in a surveillance state

Because of time constraints it has been a long time since I wrote something here. However, this is something I want to share with as many people as possible now: Mikko Hypponen’s talk titled “Living in a surveillance state”, last week at TEDxBrussels. If you think that you don’t have to fear the spying by the NSA, GCHQ and other state services because you have nothing to hide, or you are wondering what we can do against it, then you should definitely watch this. “Open source” is the key answer to the latter question by the way.

These are 20 very well spent minutes of your time.