Suggestions: Ajout de fonctionnalités de sécurité

Bonjour,

Il ne s’agit pas d’un rapport de bogue, mais de quelques suggestions.

Port

Après avoir créé un serveur, je change toujours le port par défaut 22 pour se connecter avec SSH. La principale raison est que la plupart des attaques de robot utilisent le port pat défaut, et ça alourdit inutilement les fichiers de log entre autres.

Ça serait bien si on pouvait préciser un port lors de la création d’un serveur. La commande fournit par Gandi serait donc:

ssh -p PORT_PERSO ubuntu@ADRESSE_IP

Il faudrait que le script de création du serveur édite le fichier /etc/ssh/sshd_config pour modifier la variable Port.

ufw

Ça serait bien si ufw était activé par défaut. Il faudrait lui fournir le port personnalisé s’il y a lieu:

ufw allow PORT_PERSO comment SSH
ufw limit PORT_PERSO/tcp
ufw enable

fail2ban

Un autre bonus serait d’avoir fail2ban installé automatiquement, l’équivalent de ces fonctions:

apt-get install fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
systemctl enable fail2ban
systemctl start fail2ban

À noter que le fichier /etc/fail2ban/jail.local devrait contenir le port personnalisé s’il y a lieu:

[sshd]
enabled = true
port    = PORT_PERSO
filter = sshd
logpath = %(sshd_log)s

Discussion

J’ai hésité à créer ce message en le présentant comme des suggestions en lien avec la sécurité, car je me dis que ça serait très intéressant d’avoir simplement la possibilité de préciser un template ou un script que Gandi lancerait automatiquement après la création d’un serveur pour le personnaliser.

Dans ce cas, mes suggestions ci-dessus seraient simplement des exemples que permettrait cette fonctionnalité plus globale.

Un autre exemple serait de pouvoir préciser à Gandi de générer un fichier swap après la création du serveur, donc l’équivalent de ces commandes:

fallocate -l TAILLE /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo "/swapfile none swap defaults 0 0" >> /etc/fstab

Merci.

Salut Kiwi,
merci à nouveau pour ces suggestions très pertinentes ! :slight_smile:

A vrai dire aujourd’hui nous proposons les images cloud par défaut fournies par les distributions, et ne nous voulons pas vraiment avoir à maintenir des images personnalisées par Gandi (oui on est fainéants:see_no_evil:).

Par contre aujourd’hui, maintenant que l’API publique est disponible, il est possible d’associer un script cloud-init de post-configuration du serveur lors de sa création.
Ex: https://docs.openstack.org/nova/ussuri/user/metadata.html#metadata-userdata

On va documenter un peu cette partie là, et je pense qu’on va aussi pouvoir ajouter cette option dans l’UI de création de serveur directement !

bonne journée :slight_smile:
Maël

Bonjour,

Pourquoi ne pas utiliser les security groups pour le firewall ?

openstack --os-cloud gandi security group create accesmaison
openstack --os-cloud gandi security group rule create --protocol tcp --dst-port 22 --remote-ip xx.xx.xx.xx accesmaison
openstack --os-cloud gandi security group rule create --ethertype ipv6 --protocol tcp --dst-port 22 --remote-ip 2a01:xxx:xxxx:xxxx::/64 accesmaison

Par défaut, les paquets en sortie sont autorisés et tout est interdit en entrée. Il ne reste qu’à ouvrir les ports nécessaires.
Puis soit on spawn la machine virtuelle directement sur le bon security group soit on en change :

openstack --os-cloud gandi server add security group test-cl accesmaison
openstack --os-cloud gandi server remove security group test-cl default # tout est ouvert par défaut par la config gandi

La bonne nouvelle, on peut stacker les security group et donc créer un spécifique pour le web par exemple et l’ajouter aux machines virtuelles qui en ont besoin.

My 2 cents

Bonjour,

En effet les security groups peuvent etre utilises comme le suggère @clop51 ! J’ajoute le lien vers la documentation des security groups qui sont accessibles via la CLI (et l’API): https://docs.openstack.org/nova/ussuri/admin/security-groups.html

A noter que le security group qui est créé par défaut dans votre projet et affecté par défaut à vos serveurs autorise tout le traffic entrant et sortant. Pas de problème donc si vous créez un nouveau security group et y assignez les serveurs souhaités (comme suggéré ci-dessus), en revanche si vous modifiez les règles du security group par défaut, ces modifications s’appliqueront a tous vos serveurs.