Blog hébergé par Yves et Iris :-)

Aller au contenu | Aller au menu | Aller à la recherche

Mot-clé - security

Fil des billets - Fil des commentaires

jeudi 20 avril 2017

Git is available again

When I setup gitolite on my server for Git access through SSH, of course I did test that cloning worked from outside my network. That was for my Paperweb project.

Later I configured port-knocking on the server to get rid of bot-based authentication attempts that were polluting my log files. Unfortunately, at this time, the “outside” server on which I have an account was down, so I could not leave my network to check that all was fine; from the inside of the network, all worked like a charm, though!

Same situation when someone asked me for the Paperweb code by e-mail because they could not get it the normal Git way. I had no idea that port-knocking was the problem: from my side of the firewall, all worked correctly…

Lire la suite...

mercredi 8 juin 2016

Light-weight port-knocking to protect SSH

A bit more than a year ago, I hardened my SSH server, which resulted in the near-disappearance of automated SSH login attempts. Alas, the script-kiddie tools have finally caught up with the current state of cryptography; or at least with the level of cryptography that I dare require, and still maintain compatibility with most devices that I use.

Fail2ban, although dormant all this time, still ran like the ever-vigilant Argos, and resumed its usual work as the attacks came back. But I do not like relying solely on fail2ban. So I decided to add port-knocking as a protection.

Lire la suite...

mardi 13 janvier 2015

Hardened SSH server

I strongly suggest that you heed the advice from stribika’s page on securing the Secure Shell (SSH), the aim of which is to make your SSH server safe from the NSA; or so they say…

Cet article est aussi disponible en français.

Lire la suite...

lundi 12 janvier 2015

Un serveur SSH endurci

Je vous conseille vivement de suivre les recommandations de la page de stribika sur le « Secure Secure Shell », ou « Secure SSH », qui visent à rendre le serveur SSH suffisamment sécurisé pour résister à la NSA, disent-ils…

This article has been translated to English.

Lire la suite...

dimanche 2 novembre 2014

Migrate from DenyHosts to Fail2ban

A new version of OpenSSH has been released and is bound to be quickly integrated into our preferred Linux distributions; good news! But…

sshd(8): Support for tcpwrappers/libwrap has been removed.

This may look rather inoffensive. But this means, that the SSH server will not use the /etc/hosts.allow and /etc/hosts.deny files to decide wether the IP address of a machine that is attempting to connect should be allowed to, or not.

My problem is that DenyHosts is relying on these files to protect the SSH port on my server. I fear this will be the death of the DenyHosts project. For instance, the Debian Linux distribution removed it from its software repositories. Thus I have to find an alternative software.

The two most common suggestions for replacing DenyHosts are Fail2ban and Sshguard. I choose Fail2ban because the latest version of Sshguard is a few years old (2011), and because Fail2ban allows for more personalization.

Cet article existe aussi en français.

Lire la suite...

jeudi 30 octobre 2014

Migration de DenyHosts à Fail2ban

La nouvelle version d’OpenSSH vient de sortir et sera rapidement intégrée à nos distributions Linux préférées ; excellente nouvelle ! Mais…

sshd(8): Support for tcpwrappers/libwrap has been removed.

Cela peut, à première vue, sembler inoffensif. Mais concrètement, cela signifie que le serveur SSH ne va plus consulter les fichiers /etc/hosts.allow et /etc/hosts.deny pour autoriser ou interdire l’accès au serveur en fonction de l’adresse IP de la machine qui se connecte.

Or DenyHosts utilise ce mécanisme pour protéger le port SSH du serveur. Cela marque, je le crains, la mort du projet DenyHosts. La distribution Debian l’a d’ailleurs retiré de sa logithèque. Il faut donc trouver une alternative.

Deux propositions reviennent régulièrement lorsqu’il s’agit de remplacer DenyHosts : Fail2ban et Sshguard. J’ai choisi Fail2ban car la dernière version de Sshguard date de quelques années (2011) et que Fail2ban est plus souple dans ses options de configuration.

This article has been translated to English.

Lire la suite...

samedi 22 février 2014

Multiplex SSH and HTTPS on a single port

I want to allow both SSH and HTTPS on port 443 of my server, because port 22 is often blocked by firewalls. The usual tool for this task is the excellent sslh tool, which can recognize SSH and HTTPS connections, but also HTTP, OpenVPN, tinc, and XMPP! Besides, sslh does not rely only on the “who speaks first, server or client?” technique, which makes it compatible with more SSH clients; an excellent port multiplexer indeed!

There is one drawback, though: sslh listens to a port on the server, receives an incoming connection from a remote client, detects the protocol, and then forwards packets for this connection to the adequate service; the problem is that the latter is seeing packets coming from the server itself (usually localhost), not from the IP address of the remote client.

Lire la suite...