Bonjour,
Je compte réaliser des sauvegardes de données de mon PC sous Linux Mint sur un Raspberry Pi qui se trouvera chez un ami en utilisant rsync via SSH par la commande suivante:
rsync -e ssh -aH --delete /home/user/backup userPi@XXX.XXX.XXX.XXX:/backupJe vais donc devoir ouvrir 1 port sur chaque box.
D'après vous, est-ce que je dois prendre des précautions en termes de sécurité? Pare-feu ou autres? Ou bien suis-je parano?
Merci d'avance
# Pistes de configuration
Posté par root_rtfm . Évalué à 4.
Hello,
Normalement, s'il n'y a que des sauvegardes de votre pc vers celui de votre ami, 1 seul port est à ouvrir chez votre ami (plus probablement une redirection de port de la box vers le Raspberry).
Par contre, pour la sécurité, il est préférable d'avoir un compte dédié à l'administration du Raspberry (évitez le user pi) et d'interdire le login interactif sur root en imposant l'utilisation d'une clef SSH (fichier /etc/ssh/sshd_config)
Après pour la parano, un disque crypté sur le Raspberry est préférable
Bonne continuation
[^] # Re: Pistes de configuration
Posté par feth . Évalué à 4.
si chiffrement il doit y avoir, plutôt chiffrer côté maison que chiffrer le disque distant (et oui, il y a des outils de sauvegardes incrémentales chiffrées)
[^] # Re: Pistes de configuration
Posté par root_rtfm . Évalué à 1.
Certes, mais pas rsync nativement ….tous les outils de sauvegarde professionnel proposent le chiffrement actuellement.
Il me semble plus simple de mettre en place un disque crypté sur le Raspberry, de le monter via une commande ssh, de faire le rsync puis de le démonter.
Après, il est aussi possible de faire un snapshot, le chiffreret de l'envoyer… en gros il n'y pas qu'une seule solution.
# port ?
Posté par MonsieurPaulLeBoulanger . Évalué à 2.
pour des besoins similaires mais avec un serveur web, j'utilise sslh en front, sur le port 80 ou 443.
Ca me permet de n'ouvrir que l'un de ces ports et de faire passer le ssh sur ce port non standard pour ssh.
Et openvpn (en tcp). Et d'autres choses (Minetest).
Mais avec seulement du ssh il suffit de changer le port :)
[^] # Re: port ?
Posté par Michaël (site web personnel) . Évalué à 2. Dernière modification le 08 novembre 2017 à 21:20.
À signaler que répartiteur HA-PROXY permet aussi de faire ce genre de choses: une analyse du contenu ou de l'origine permet de rerouter le traffic. Avec l'avantage que c'est un outil beaucoup plus général.
# Merci
Posté par toffe . Évalué à 1.
Merci pour les infos.
Concernant le chiffrement du disque dur, j'ai regardé du côté de VeraCrypt, mais je ne suis pas très confiant. Ça m'a semblé un peu compliqué et j'ai peur de me retrouver avec une sauvegarde inutilisable le jour J.
Je suis surtout préoccupé par le risque d'intrusion chez mon ami. Je veux être sûr de ne pas causer de problème à cause du Raspberry.
[^] # Re: Merci
Posté par root_rtfm . Évalué à 1.
Pour le disque, regarde peut-être crypsetup en native sur Linux
# Logs
Posté par Michaël (site web personnel) . Évalué à 2. Dernière modification le 08 novembre 2017 à 21:41.
Comme les autres l'ont déjà signalé:
Il est crucial de désactiver l'identification par mot de passe et de n'utiliser que des identifications par clef publique (
PasswordAuthentication noetPubkeyAuthentication yes)Il faut créer un utilisateur Unix dédié pour la procédure sauvegarde.
Il faut montrer le moins de surface possible pour la machine, donc n'ouvrir qu'un seul port (le routeur du FAI doit permettre faire du NAT pour rediriger un port du routeur (IP publique) sur le Pi.
Un aspect qui n'a pas été encore mentionnant et qui est peut-être plus inattendu est qu'il faut impérativement configurer le système de logs et le firewall de façon appropriée… Je l'ai appris à mes dépens car il y a quelques années j'avais effectivement ce genre de montage chez moi, et j'ai rapidement remarqué que le serveur SSH était en permanence sollicité… par des attaques de dictionnaire, ce qui a rempli le dossier de logs en environ un mois, et flingué la carte SD. Je n'ai vérifié les détails mais le scénario probable de l'écriture synchrone de chaque ligne de log sur la carte SD a fait beaucoup de mal au système.
Pour se prévenir de cela, il faut donc:
Utiliser des règles de firewall qui vont rejeter les tentatives infructueuses répétées. Il y a plusieurs stratégies utilisables, j'ai rapidement regardé et l'approche de Joao S Veiga semble à la fois simple et raisonnable: il paramètre iptables pour rejeter toutes les tentatives multiples sur le port 22 (SSH) suivant de moins de 15 secondes une tentative plus ancienne.
En ce qui concerne les logs il faut vérifier que syslog ou tout autre système utilisé n'écrit pas de façon synchrone sur le disque ou bien mettre les logs sur un autre système de fichiers. Par exemple un disque USB attaché au Pi (si l'alimentation est assez forte!), un disque réseau NFS, voire envoyer tous les logs sur une autre machine via syslog, ou bien utiliser un système de fichiers tmpfs et utiliser logrotate de façon très agressive pour limiter la place consommée par ceux-ci!
[^] # Re: Logs
Posté par MonsieurPaulLeBoulanger . Évalué à 2.
Pour les règles de firewall, tu peux aussi installer fail2ban qui s'occupera de tout ça
[^] # Re: Logs
Posté par Michaël (site web personnel) . Évalué à 2.
Oui, c'est un problème ancien et il suffit d'une brève recherche pour se rendre compte qu'il y a une bonne dizaine de possibilités… je n'en ai jamais utilisé une mais pour le besoin de l'exemple j'en ai pioché une où il n'y a pas trop de plomberie à faire.
# ne pas utiliser le port par defaut
Posté par NeoX . Évalué à 2.
c'est bete, mais les scanners regardent souvent les ports standards (par ex le port ssh par defaut : 22), et pas forcement les autres ports
un debut de securité sur la box distante, tu parametres un port different du port ssh (tu as du choix entre 1024 et 65535)
et la box renverra vers la RPi pour 22
evidemment on durcit le RPi avec l'absence de compte root, le login par clef ssh, etc.
sur un linux standard je simplifie generalement ta ligne :
en
[^] # Re: ne pas utiliser le port par defaut
Posté par MonsieurPaulLeBoulanger . Évalué à 1. Dernière modification le 10 novembre 2017 à 10:36.
du coup, en changeant le port ssh cible, autant le spécifier dans la commande rsync plutôt que de le définir comme comportement global, non ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.