🗓️ Note : Cet article est une archive importée de mon ancien blog. Certaines informations peuvent ne plus être à jour.

Ou comment on relance automatiquement Caddy au démarrage ? Et protection du système.

Résumé des épisodes précédents

 

Disclaimer

Je commence à saturer d’écrire des tartines. Cet article sera « épuré » et « droit au but » ; pour rappel :

  • Je ne suis pas un expert
  • Il peut y avoir des erreurs et des inexactitudes dans ce qui va suivre
  • C’est à vos risques et périls.
  • Néanmoins, n’hésitez pas à faire avancer le schmilblick et à me faire remarquer les points noirs.

 

Caddy au démarrage du système

 

Debian, Ubuntu, Raspbian

En fouillant un peu, je me suis rendu compte que normalement Caddy est censé démarrer au démarrage du système (merci systemd) . En effet, d’après la documentation officielle :

Installing this package automatically starts and runs Caddy for you as a systemd service named caddy using our official caddy.service unit file.

Mais chez moi… ca marchait pas…

Et pour les autres OS ?

Veuillez vous référer à la documentation du système. J’ai cru comprendre qu’on peut faire certaines choses avec systemd (vous trouverez un bon article à ce sujet : ici) ; et vous trouverez ici le fichier caddy.service officiel.

 

Chez moi, ça marche pas.

Comme je l’ai déjà dit, au démarrage du système, caddy ne démarre pas. Enfin… Plus exactement. Il démarre : mais rien ne se passe mon super site est innaccessible. Je suis obligé de l’arrêter de le relancer à la mano. On va donc voir ce qui se passe, et on va utiliser systemctl.

Quelques commandes utiles systemctl

Pour activer ou désactiver le service au démarrage du système :


sudo systemctl enable caddy.service
sudo systemctl disable caddy.service

Pour démarrer ou arrêter le service :


sudo systemctl start caddy.service
sudo systemctl stop caddy.service

Pour vérifier l’état d’un service : 
systemctl status caddy.service

Vérifier le statut

Du coup, après un reboot, j’ai tapé systemctl status caddy.service et voilà ce qu’on obtient (j’ai caviardé les informations personnelles) :

On remarque que même si le service est actif, tout ne se passe comme prévu. Apparemment, c’est des problèmes de « permission denied » (permissions refusées) sur le dossier /var/lib/caddy… (oui c’est pas écrit en entier, la mise en page n’est pas adéquat).

A qui donner les permissions ?

Pour éviter de donner les permissions « à tout le monde » (et augmenter les risques vis à vis de la sécurité du systéme) , il faudrait savoir à qui il faut donner ses permissions. Je me suis donc mis à étudier le fichier caddy.service de la documentation officielle.

Et on voit quelque chose d’intéressant à la ligne 22 :

[Service]
User=caddy
Group=caddy

J’ai donc déduis que c’est à l’user « caddy » que je dois donner les droits sur le dossier /var/lib/caddy 

A  l’assaut du probléme

Première etape, on remarque que dans notre log, la commande « mkdir » échoue à créer le dossier. On va donc le créer nous même et donner les droits à ce dossier.

mkdir /var/lib/caddy

Ensuite, on va donner tous les droits au propriétaire du fichier et droit de lecture pour les autres.

chmod -R 744 /var/lib/caddy

  • chmod est la commande qui permet de modifier les droits sur un fichier ou un dossier. Pour plus d’informations sur chown / chmod c’est par ici.
  • -R signifie que la commande est récursive, les sous dossier bénéficieront des mêmes droits.
  • 744 est le code qui signifie que le propriétaire aura tous les droits, et le groupe et les autres auront juste le droit de lecture. Pour mieux comprendre ce code, rendez vous ici.
  • et enfin le chemin : /var/lib/caddy

Pour le moment, on a juste donné les droits au propriétaire du dossier. Maintenant on va dire : « C’est monsieur Caddy le propriétaire désormais ! » :

chown -R caddy /var/lib/caddy

  • chown est la commande qui permet de modifier le propriétaire d’un fichier ou d’un dossier. Pour plus d’informations sur chown / chmod c’est par ici.
  • -R signifie que la commande est récursive, les sous dossier bénéficieront des mêmes droits.
  • caddy est le nom du propriétaire
  • et enfin le chemin : /var/lib/caddy

Vérification

On est content, on fait un reboot du systeme. Je refais un petit coup de systemctl status caddy.service . Je ne vous refais pas une capture d’écran mais il y avait un problème similaire : caddy ne pouvait pas écrire dans les logs. Et c’est facheux, puisque c’est eux qui permettent de bannir des gens via fail2ban. (On en a déja parlé dans un précédent article.)

Encore un petit coup !

On refait la même chose cette fois ci pour le fichier de log (vu que c’est un fichier et pas un dossier, pas besoin de -R) :

chmod 744 /var/log/caddy-torrent.log

chown caddy /var/log/caddy-torrent.log

Dernière vérification…

Alors on reboot… on revérifie les logs… on essaye d’accéder à notre super site… et… c’est ouvert !

Améliorer la sécurité du système

Ce qui suit est fortement inspiré de ceci.

Désactiver SSH pour root.

On en avait déjà parlé, mais on va continuer d’améliorer la sécurité de notre système, on va interdire à l’utilisateur root de se connecter directement en SSH. En effet, le mot de passe root donne les privilèges les plus élevé sur une machine, et on peut donc en faire ce qu’on veut. L’idée c’est de mettre des bâtons dans les roues des personnes qui seraient malintentionnées. (plus d’informations ici)

C’est très facile à faire. Il vous faut un utilisateur supplémentaire (en plus de l’utilisateur root). Si vous vous rappelez bien, on l’a créé au tout début de notre épopée avec Helios64 !
Dans l’idéal, il faut que le mot de passe pour root et le mot de passe pour ce nouvel utilisateur soient différents.

Avant de commettre l’irréparable, assurez vous que vous arrivez à vous connecter avec ce nouvel utilisateur (via ssh) , et que vous pouvez passer root ! N’oubliez pas de donner à ce nouvel user les droits :

usermod -aG sudo username

En tant que user, vous devez taper :

su - puis, le mot de passe root.  Et voilà !  Si c’est concluant, (et seulement si c’est concluant) on peut faire la suite :

Puis on vient éditer le fichier suivant sshd_config :

nano /etc/ssh/sshd_config

On cherche la ligne PermitRootLogin yes et on remplace par PermitRootLogin no ; on enregistre, et on recharge les nouvelles configurations via :

service ssh restart

Voilà, root ne peut plus se connecter directement via SSH.

 

Rebinder le port SSH (par défaut : 22)

Encore une fois, l’idée c’est d’améliorer la sécurité. Par défaut, tout le monde sait (et particuliérement les vilains programmes malicieux) que le port SSH est par défaut le port 22. On va corser un peu la difficulté en changeant le port par défaut. Prenez garde à choisir un port qui n’est pas déjà utilisé par quelque-chose sur votre machine !

nano /etc/ssh/sshd_config

Vous devriez repérer la ligne suivante :
# Port 22

Admettons que vous choisissez le port 1234, vous devez modifier cette ligne et la remplacer par : (pensez bien à retirer le #) :
Port 1234

On enregistre, et on relance SSH pour prendre en compte cette modification :

service ssh restart

Désormais, pour vous connecter en local vous devrez taper :

user@192.168.x.y -p 1234

(à adapter selon votre configuration)

 

On vérifie que c’est bien pris en compte avec fail2ban

On en a déja parlé ici, je ne vais pas refaire le topo. Fail2ban par défaut vous protège des personnes qui tentent de forcer l’accès SSH. L’idée c’est de tenter de se connecter en SSH depuis votre machine (qui normalement peut pas être auto-banni) et depuis une autre IP pour voir si vous vous retrouvez bien ban. Et de surveillez les logs pour être sur et certain de pas se faire pirater ! On essaye de se connecter depuis n’importe quel machine via :

ssh user@monsupersite.truc -p 1234

(à adapter selon votre configuration)

 

Conclusion

Ben voilà; c’est déjà fini !

Ce fut court, j’espère que ca vous a intéressé quand même. Si jamais j’ai dit des bêtises, n’hésitez pas à me corriger ! Je continue d’apprendre les arcanes de « l’adminsys ».