Serveur Debian @ Home (premier pas)

Support Debian
#1

Bonjour.

je ne suis pas novice avec Debian mais absolument pas pro !! assurément pas.
Par contre, ceci serra ma première expérience par rapport au sujet de ce post.
J’ai cela étant dit un nas Asustor donc je vois un peu parfois de quoi il en retourne.

voilà:

J’ai receuilli un petit et très ancien mac mini…
(blanc et bord alu … ça tourne en tout cas)

J’aurais aimé expérimenter la mise en place d’un serveur local Debian afin d’exécuter des taches simple au départ sur mon réseau local pour commencer:

  • Pour y faire des sauvegarde de HDD, /home, clé usb, … de data en somme.
  • Pouvoir y mettre des fichiers et en faire donc un serveur de fichiers pour Linux/mac essentiellement, window peut-être un atout si jamais si…
  • réaliser des sauvegarde de celui si (je suppose qu’Rsync planifié périodiquement me le permetra très facilement - avec un hd exeterne directement relié)
  • Mettre une bibliothèque musicale et donc y ajouter un serveur son (pour le local - et on verra si mais à l’avenir j’aimerais y avoir accès depuis internet … j’ai parcourus quelques soft cette effet - subsonic et autres …)
  • Voilà donc les premier points
  • de deux : niveau sécurité qui que quoi faire ?
  • autres conseils bienvenu
  • …

Je serrais le seul utilisateur de ce serveur (du moins dans un premier temps)

Il a 3Go de ram, c’est un i386 intel … J’ai ajouté une baie à la place du lecteur cd/dvd et donc a deux disques embarqué (HDD et un SSD) … 1e prise éthernet, 4 usb, un firewire 400 je dirais… casque et entrée son et pour finir la connectique de l’écran.

Il a normalement le wifi, mais en démontant l’ordi, j’ai peur de l’avoir rendu HS. Mais je ne pense pas en avoir besoin réellement… Je sais pas pour le bluetooth mais j’en aurais pas utilité je pense…

Voilà
(je peux m’atteler à l’informatique qu’à certains moments, donc ne suis pas le plus rapide répondre … :grinning_face_with_smiling_eyes: )
Merci d’avance
et à bientôt
++

#2

Salut,

De mon expérience, déjà, utiliser du vieux matériel a énormément de désavantages mais permet au moins de lui offrir une seconde vie. La vitesse de rotation du disque dur, le vieux processeur et la quantité limitée de RAM vas peut-être parfois te poser quelques problèmes, mais rien d’incontournable.

Par exemple sur un disque dur assez lent, les bases de données seront un peu lente, donc patience.

Ceci dit, c’est faisable.

Concernant la sécurité, à partir du moment où ton port SSH/sFTP, FTP et tout ce qui te permet d’interagir avec le serveur, sont fermés vers le monde extérieur, tu n’as pas trop à t’en faire. La seul faille en l’occurrence c’est depuis ton propre réseau local.

Si jamais tu devais l’ouvrir sur le WAN (Internet par exemple), il faut impérativement:

  • Avoir des règles iptables (le parefeu) afin de tout bloquer et ouvrir, au cas par cas, ce qui est nécessaire (HTTP/HTTPS, SSH etc).

  • Pourquoi pas utiliser un outil, qui fait débat d’un point de vue sécurité, comme fail2ban qui bloquera les tentatives massives de connexion non désirées. C’est plus pour limiter les logs inutiles que pour améliorer la sécurité, mais je ne suis pas d’accord avec cela. Disons que seul fail2ban n’améliorez pas de beaucoup la sécurité, mais au moins les bots auront plus de mal à bruteforce ta machine (encore une fois, le risque est faible, surtout avec une clé SSH obligatoire).

Disons que c’est un petit plus pas dégueu.

  • Avoir un serveur bien à jour, par exemple une fois par semaine le mettre à jour et le redémarrer si nécessaire pour appliquer les nouvelles versions du noyau

  • Si SSH depuis l’extérieur, utilise une clé avec un mot de passe et interdit, idéalement, toutes connexions sans cette clé. Bloque bien sûr la connexion par défaut au compte root.

J’aime ajoute aussi des utilisateurs autorisées avec le paramètre AllowUsers afin d’être sûr de limiter les possibilités de connexion (bien qu’il y ait une clé SSH!).

Pas besoin d’être paranoïaque, mais il faut quand même un minimum de sécurité.

Aussi, par exemple, les connexions aux bases de données (s’il y en a) doivent bien être configuré pour n’être accessible que localement (un compte localhost) et si jamais tu as un compte distant (%) alors bien lui indiquer quels sont les IPs autorisées à s’y connecter.

PS: Si jamais ton serveur venait à n’être utilisé qu’épisodiquement, et uniquement par toi, n’hésite pas à l’éteindre quand il ne sert pas. Premièrement l’électricité faut bien la produire et ça pollue, de plus avec les dernières augmentations de tarifs… ça peut faire mal à la fin de l’année ;).

Cordialement,
Kévin GASPARD

#3

le FTP est toujours quelques soient les considération une faille de sécurité; c’est aussi sécurisé qu’un telnet en gros. donc à bannir autant que possible et remplacer par SFTP ou FTPS.

C’est clair.
Pour ce qui est des brutes forces, avec de vrai mots de passe, ils n’ont aucune chance.

le mieux est d’utiliser une interface de management, qui sera toujours plus facile à sécuriser, et ne garder les connexions directe que pour le réseau local. Ou alors via VPN si c’est distant.

#4

Pour te dégrossir, il y a Yunohost sur base Debian.

https://yunohost.org/#/

C’est ce que je commence à utiliser, étant un peu dans le même cas que toi.
Je le fais sur un vieil ordi (c’est vrai qu’il y a vite des limites, qui viennent aussi de ton FAI quand il bloque complètement des ports ou des protocoles.) je le fais aussi sur un VPS de 1984, histoire d’être moins près des regards .

https://1984.hosting/

Il est aussi intéressant de s’initier au maniement des containers (avec Docker, par exemple).
Ca je le fait en local avec un searX que je mettrai ensuite sur un serveur.

#7

coté vieux matériel j’ai un serveur qui est un PC Dell Optiplex qui date du début des années 2000, et il tourne très bien.

Après les NAS sont des matériels specifiques la plupart du temps (à 90% et plus), donc les recycler en serveur est loin d’etre très simple.

#8

+1 pour yunohost
Installé en VPS et en homes server sur une Olimex A20, LIME 2
Vraiment nickel
Mon how to de l’instal / config
https://cbiot.fr/dokuwiki/homeserver:olinolinux
++

#9

Bof, plus vraiment. Déjà il existe des outils additionnels (ex: mysecureshell) et les jails pour pouvoir limiter les risques. Mais de toute façon, c’est plus dans un soucis de rétrocompatibilité sous Linux d’utiliser du FTP je pense (et quand je dis rétrocompatibilité, je parle des dinosaures dans le monde pro qui persistent sur un serveur Linux à utiliser du FTP au lieu du sFTP qui sera quoi qu’il arrive plus sécurisé).

Bah, ta CLI c’est une interface de management :P.

(J’aime pas les GUI pour ce genre de truc, mais c’est une question de goût)

#10

Merci d’avance.
Je lis au fur et à mesure.
Je ne suis pas chez moi encore pour une bonne semaine…
Je mettrais en pratique cela une fois rentré !

a+
et bonne journée
!!

#11

dans ce cas là SSH.
les interfaces directes aux bases de données son toujours médiocres coté sécurité.

#12

Merci.
J’attaque cela today ou demain !

Juste, je me posais une question:
Lors de l’installation: définir un mot de passe root et un différent pour mon user est-il un avantage pour la sécurité ?
Le premier je devrai utiliser « su - » et le second (si je n’indique rien comme pw pour root), j’aurais « sudo » de mis en place directement.

Lors de mes installation: je n’indique généralement pas de mot de passe spécifique à root.
J’avais parfois des embrouilles quand je faisais le contraire: sûrement surmontable. (embrouilles à lancer certaines applis graphique en utilisant « sudo » mais installé après la première connexion d’un système tout frais et d’un « su - » qui …(?) - ça fait longtemps je ne me rappel plus très bien mais donc par habitudes j’ai pris cette voie pour mes installes)

Voilà
hâte de commencer ce bazar de bazar de serveur.
Merci

#13

Personnellement, je recommande de ne pas autoriser les connexion en tant que root et d’installer sudo.

Ce n’est pas grave ça, c’est un serveur, il n’y aura pas d’appli graphique (enfin, normalement).

#14

Il y a une différence entre ne pas autorisé une connection root, et ne pas mettre de mot de passe, car on peux echapper une commande vers root, alors les problèmes commencent.

#15

Cela ne change rien au niveau sécurité. Si un intrus arrive à se connecter à un compte utilisateur ayant tous les privilèges via sudoers, c’est exactement comme s’il était root.
On pourrait même dire que l’utilisation de sudo augmente la surface d’attaque puisque l’on est soumis aux éventuelles failles de sécurité de sudo (il y en a déjà eu d’importantes par le passé).

Les seuls avantages de sudo sont de :

  • faciliter (un peu) l’administration système (un seul compte pouvant élever ses privilèges, un seul mot de passe) ;
  • gérer finement les privilèges accordés à certains utilisateurs / groupes ;
  • enregistrer dans les logs les différentes actions des utilisateurs se servant de sudo.

Il n’y aucun risque à autoriser les connexion directes en tant que root : localement avec un mot de passe solide, à distance (SSH) par clé uniquement.

1 J'aime
#16

sudo je ne suis pas fan, mais c’est une question de choix et de configuration: si c’est bien paramétré les risques sont faibles.

Perso, pour un serveur, un compte root + un compte utilisateur avec tout deux de bons mot de passes, interdire les connexions SSH à root ou tout compte sudo c’est déjà très bien.

J’ajoute mon utilisateur de connexion, non root, non sudo, à la directive AllowUsers dans mon fichier /etc/ssh/sshd_config pour limiter encore plus les risques (alors que je n’autorise la connexion que par clé SSH, avec mot de passe et en interdisant bien sûr la connexion par mot de passe).

#17

Bonjour (Bon Dimanche).
Alors voici.

As tu des conseilles précis de configuration pour sudo. Personnellement, sur mes ordi, j’utilise sudo, il me parait donc plus classique de l’utiliser.

De deux: j’ai fait une première install…
Un disque hdd de 80Go pour le système avec une partition n°2 et donc différente pour le /home qui se trouve être à la base d’un deusième hdd de 2To.
D’où une autre question ? Sur certains site on parle de créer une partition pour /var, /home, … surtout en cas de serveur multi-users.
Alors dans un premier temps, je serrais l’unique utilisateur (a fin de pouvoir un rien maîtriser le sujet et tutti) mais biensur regardant sur le web … d’autres applications que celles prévue au départ me donnent envie: subsonic, apt-cache, nextcloud, … dont il y aurait possiblement 2 ou 3 utilisateurs/utilisatrices en plus (en tout cas, une en plus assurement)…

Pour ne pas devoir faire et refaire des installes, bien préparer ces disques des le départ afin de pouvoir évoluer vers différentes options, services, installes, … me parait judicieux… Que me conseilleriez vous pour un serveur avec 2 hdd: 80Go et 2To muni de 3Go de RAM.
Le hdd de 80Go peut-être remplacé si besoin par un SSD de 128 ou 256Go de récup.

Merci
a++

(veuillez noter e temps qui distance mes messages : bcp de chantiers dans ma maison et le soleil sont de la partie :wink: )