This post briefly describes and solves a problem that can appears in RStudio on managing SSH keys while using git. In certain situations (generally when a modification has been made on a RStudio project), an error message appears while trying to pull/push on a valid git repository:

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
	
This message indicates that RStudio is not able to properly load or find the user's SSH key used to access the git repository. It is solved by launching in RStudio Tools / Shell and typing
ssh-add ~/.ssh/id_rsa
	
and then
git pull
	


Ce post décrit l'installation de apache2 sur Kimsufi, Ubuntu server 20.04 LTS et la mise en place de divers outils de sécurité.

Installation basique de apache2

apache2 est installé par

sudo apt install apache2
On crée ensuite une entrée DNS de type "A" sur la manager OVH pour diriger mydomain.org vers l'IP du server puis on ajoute l'entrée mydomain.org dans le fichier /etc/hosts. La configuration de base de apache2 est présente dans le fichier /etc/apache2/sites-available/00-default.conf et pointe vers le répertoire physique /var/www/html. On peut éditer ce fichier pour en modifier les paramètres avant de démarrer apache2 avec
sudo systemctl start apache2

Enfin, il ne faut pas oublier, si on utilise shorewall, d'ouvrir le protocole correspondant, en ajoutant la ligne

HTTP(ACCEPT)    net             $FW
dans le fichier /etc/shorewall/rules puis en redémarrant shorewall :
sudo systemctl restart shorewall.service
L'ouverture de l'URL mydomain.org dans le navigateur devrait afficher la page de configuration de base de apache2.

SSL

Refs : https://www.memoinfo.fr/tutoriels-linux/configurer-lets-encrypt-apache/ et https://certbot.eff.org/lets-encrypt/ubuntubionic-apache.html.

L'encryptage SSL est activé sur apache2 par

sudo a2enmod ssl
sudo a2enmod rewrite
sudo systemctl restart apache2
	
On va alors obtenir un certificat de sécurité SSL publié par le serveur qui authentifiera son identité. Pour cela, on commence par installer le ppa "certbot" :
sudo add-apt-repository ppa:certbot/certbot
**Attention** : Ce ppa n'existe pas pour focal, on édite donc le fichier /etc/apt/sources.list.d/certbot-ubuntu-certbot-focal.list pour remplacer focal par bionic en attendant la publication du ppa pour la 20.04 LTS. On peut alors installer certbot avec :
sudo apt update
sudo apt-get install certbot python3-certbot-apache
	
Le certificat SSL, certifié par Let's Encrypt peut alors être obtenu avec la commande
certbot certonly --webroot --webroot-path /var/www/html/ --domain mydomain.org --email tuxette@mydomain.org
**Attention** : Pour la création du certificat, le site mydomain.org doit être une URL valide. Si la création est réussie, un message s'affiche de ce type :
IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/mydomain.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/mydomain.org/privkey.pem
   Your cert will expire on XXX-XX-XX. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
	

Pour terminer l'activation de SSL sur mydomain.org, on édite le fichier /etc/apache2/sites-available/default-ssl.conf pour modifier les deux lignes

SSLCertificateFile	/etc/letsencrypt/live/mydomain.org/fullchain.pem
SSLCertificateKeyFile	/etc/letsencrypt/live/mydomain.org/privkey.pem
	
puis on active la configuration :
sudo a2ensite default-ssl
sudo systemctl restart apache2
	
L'URL https://mydomain.org sur le navigateur doit alors afficher le fichier de configuration par défaut d'apache2 avec une indication que le certificat est valide et que la navigation est protégée.

CAA et Forward Secrecy

Refs : https://www.ssllabs.com/ssltest/, https://blog.qualys.com/ssllabs/2017/03/13/caa-mandated-by-cabrowser-forum et https://www.digicert.com/kb/ssl-support/ssl-enabling-perfect-forward-secrecy.htm

À ce stade le site est authentifié et la navigation sécurisé mais il ne respecte pas pour autant les dernières recommandations en terme de sécurité de la navigation. Pour le vérifier, entrez mydomain.org à https://www.ssllabs.com/ssltest/. En particulier, les points faibles suivants peuvent être identifiés :

  • La non présence d'une entrée CAA qui indique quelle devrait être l'autorité de certification de mydomain.org. Pour créer cette entrée, allez dans le manager OVH et ajoutez un champ CAA du type
    IN CAA 0 issue "letsencrypt.org"
    qui indique que Let's Encrypt devrait être l'autorité certifiant l'authenticité du site.
  • Le non respect de Perfect Forward Secrecy qui peut être corrigé en éditant la configuration SSL /etc/apache2/sites-available/default-ssl.conf pour y ajouter les lignes suivantes :
    		
    SSLProtocol all -SSLv2 -SSLv3
    SSLHonorCipherOrder on
    SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
    
Il faut bien sur terminer par recharger la configuration de apache2 :
sudo systemctl restart apache2

modsecurity

Refs : https://doc.ubuntu-fr.org/modsecurity

Le module de sécurisation de apache2 "modsecurity" est installé avec

sudo apt install libapache2-mod-security2
Ce module est fourni avec un fichier de configuration exemple qu'il faut copier dans le fichier de configuration définitif dans /etc/modsecurity :
sudo cp modsecurity.conf-recommended modsecurity.conf
	
On peut éditer le fichier /etc/modsecurity/modsecurity.conf pour ajouter, par exemple, une signature personnalisée aux pages "404" d'apache2 par exemple :
SecServerSignature "Custom Name"
	
Puis on active la configuration de modsecurity avec
sudo systemctl reload apache2.service

fail2ban pour apache

Refs : https://www.supinfo.com/articles/single/2660-proteger-votre-vps-apache-avec-fail2ban

fail2ban peut aussi être utilisée pour sécuriser apache contre divers types de nuisances. En particulier, un certain nombre de filtres sont déjà fournis dans /etc/fail2ban/filters.d/apache-*** dont les paramètres spécifiques sont documentés dans /etc/fail2ban/jail.conf. Pour activer un de ces filtres, il suffit de la copier dans /etc/fail2ban/jail.local en ajoutant enabled = true et en personnalisant les paramètres éventuellement. Par exemple, on peut ajouter le filtre apache-auth avec:

[apache-auth]
enabled = true
port = http,https
filter = apache-auth
logpath = /var/log/apache2/error.log
bantime = 600
maxretry = 3
findtime = 600
ignoreip = XXX.X.X.XX
	
On peut aussi créer des filtres personnalisés. Par exemple, en créant un fichier /etc/fail2ban/filter.d/apache-dos.conf contenant
[Definition] 
failregex = ^<HOST> -.*"(GET|POST).*
ignoreregex =
	
et en ajoutant ces lignes au fichier /etc/fail2ban/jail.conf :
[apache-dos]
enabled = true
port = http,https
filter = apache-dos
logpath = /var/log/apache2/access.log
bantime = 600
maxretry = 300
findtime = 300
ignoreip = XXX.X.X.XX
action = iptables[name=HTTP, port=http, protocol=tcp]
	
on protège apache2 contre les attaques DOS. Pour mettre en œuvre, on recharge la configuration de fail2ban :
sudo systemctl restart fail2ban.service
	
dont on peut vérifier le bon fonctionnement avec
sudo fail2ban-client status
	


This post describes the update of xUbuntu 18.04 LTS to xUbuntu 20.04 LTS (focal). The upgrade process has been launched with

sudo do-release-upgrade -d
and everything went smoothly except for two things:
  • First, chromium now seems to be available only through snap. It does not require to do anything special but it is something to remember.
  • Second, xscreensaver needs to be deactivated for the upgrade. I did it and have not fixed this issue since (so the session is just locked with the standard xfce tool and displays a black screen).

After the upgrade, these minor fixes have been performed:

  • A few repositories have been deactivated for the update, including **R** and nextcloud client. I reactivated them by (for **R**) adding the line
    deb https://cloud.r-project.org/bin/linux/ubuntu focal-cran40
    
    to the file /etc/apt/sources.list and (for nextcloud) by editing the file /etc/apt/sources.list.d/nextcloud-devs-ubuntu-client-DIST.list to uncomment the line
    deb http://ppa.launchpad.net/nextcloud-devs/client/ubuntu focal main
    
    Then,
    sudo apt update
    sudo apt upgrade
    
    upgraded everything.
  • The software gcstar is no more available. I downloaded the version available for Ubuntu 18.04 LTS at https://launchpad.net/ubuntu/+source/gcstar/ and installed it with:
    sudo dpkg -i gcstar_1.7.1+repack-1_all.deb
    sudo apt install -f
    
    However, this temporary fix is still unsatisfactory and I hope that gcstar will somehow reappear in the Ubuntu official software library.


Migrating my old git server (on Ubuntu 18.04 LTS) to a new one (on Ubuntu 20.04 LTS), I switched to gitolite3 to manage server authentication. This post explains how.

Refs: https://gitolite.com/gitolite/migr.html and https://gitolite.com/gitolite/basic-admin#appendix-1-bringing-existing-repos-into-gitolite

First, gitolite3 was installed using:

sudo apt install gitolite3
(with administrator's key left blank) and configured with:
sudo dpkg-reconfigure gitolite3
where:
System user name for gitolite: gituser
Repository path: /var/lib/gitolite3
Finally, I copied my public key into /var/lib/gitolite3/.ssh/authorized_keys to give me access to admin SSH authentication to my git server.

Once done, I simply hard copied all bare repository on my old server in the directory /var/lib/gitolite3/repositories of the new server (except for the repository gitolite-admin for which I kept the one installed by gitolite configuration). I also made sure that all copied repositories have the proper owner on the new server:

sudo chown gituser:gituser -R *
(from within /var/lib/gitolite3/repositories).

Then I ran:

su gituser
gitolite compile
gitolite setup --hooks-only
gitolite trigger POST_COMPILE

The last step of the installation was made from my local computer. I first configured the domain name gitolite.mydomain.org to point to my new git server (with the proper addition in /etc/hosts and locally cloned the new admin

git clone gituser@gitolite.mydomain.org:gitolite-admin
In this directory, I then edited the file conf/gitolite.conf to add all repositories and user rights and I added in keydir the corresponding users' keys. Then I pushed that to my new server.

The last step simply consists in asking all users to edit the file .git/config in their repositories to replace the old server URL by gituser@gitolite.mydomain.org.


This post describes how the server can be secured using fail2ban and shorewall. It mostly builds on the procedure that I described earlier in this post with a few additional warnings.

fail2ban

Refs: https://ubuntu.tutorials24x7.com/blog/how-to-install-fail2ban-on-ubuntu-20-04-lts and https://doc.ubuntu-fr.org/fail2ban

fail2ban is a software that is used to protect against brute force and DDoS attacks. The principle is that it blocks IPs that repeatedly fail to authenticate in a variety of services. Here, we explain how to configure it to block failed ssh login attempts. The tutorial will eventually be updated later with other services.

fail2ban is installed with:

sudo apt install fail2ban
and its status can be checked with
sudo systemctl status fail2ban
which, at that state, should return
Active: active (running) since Thu 2020-07-30 18:24:24 CEST; 1min 11s ago

The main configuration files are /etc/fail2ban/fail2ban.conf and /etc/fail2ban/jail.conf, that can be kept as is and amended with the creation of /etc/fail2ban/fail2ban.local and /etc/fail2ban/jail.local for custom configurations. More precisely, I created /etc/fail2ban/fail2ban.local with

[DEFAULT]
loglevel = INFO
logtarget = /var/log/fail2ban.log
and /etc/fail2ban/jail.local with [DEFAULT] ignoreip = 127.0.0.1 XX.XXX.XXX.XX bantime = -1 findtime = 3600 maxretry = 3 destmail = me@mydomain.org action = %(action_mwl)s backend = systemd </pre> that configures fail2ban to ban forever any IP that has at least 3 failed connexion attempts (on sshd service) in the last 3600 seconds. Emails are sent to my address with detailed information on IP and whois who have been banned.

Other specific jails can be configured using custom files in /etc/fail2ban/jail.d/myfile.conf. In my case, I created /etc/fail2ban/jail.d/ssh.conf with

enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 4
that additionnaly ban any IPs failing to connect 4 times as indicated in the file /var/log/auth.log.

The configuration is finally validated with

systemctl restart fail2ban
Note that other interesting commands are:
  • fail2ban-client set JAIL banip IP to ban a given IP address
  • fail2ban-client set JAIL unbanip IP to unban a given IP address
  • fail2ban-client set JAIL addignoreip IP to add an IP to the whitelist

Shorewall

shorewall is a tool to manage easily IP tables and secure the allowed connexions on the server. It is installed with:

sudo apt install shorewall
and a first basic configuration (for a single server) can be obtained with
sudo cp /usr/share/doc/shorewall/examples/one-interface/* /etc/shorewall/.

Starting from that, the default policy is described in /etc/shorewall/policy, where a standard configuration can be:

$FW     net             ACCEPT
$FW	all		ACCEPT

net     $FW             DROP            info
net     all             DROP            info      

# The FOLLOWING POLICY MUST BE LAST
all     all             REJECT          info
that allows all connexions from the firewall to the net and all other interfaces, drops all connexions from the net and rejects all the other connexions.

Exceptions to these rules are describes in /etc/shorewall/rules that typically should at least contains

PING(ACCEPT)	net	$FW
SSH(ACCEPT)     net     $FW
if you want to allow ping and ssh connexions to your server.

Be careful that the file /etc/shorewall/interfaces contains the appropriate configuration

net     NET_IF          dhcp,tcpflags,logmartians,nosmurfs,sourceroute=0,physical=YYY
in which YYY is replaced by the name of your network interface as given by ifconfig. Forgetting this setting led me to test the RESCUE mode of Kimsufi after the starting of shorewall...

Finally, shorewall is enabled by editing the file /etc/default/shorewall in which the line starting with startup has to be modified to be:

startup=1
or (I don't know which one of the two was successful) by running
sudo systemctl enable shorewall
Finally, the value STARTUP_ENABLED of /etc/shorewall/shorewall.conf has to be set to Yes and shorewall is started with
sudo systemctl start shorewall