[Serveur] : Sécurité et autodiscipline

Bonjour,
J’ai récemment installé un serveur WEB/FTP sous debian contrôlé par SSH. Trois questions me taraudent depuis quelques jours :
1 - Est-il judicieux de désinstaller la commande sudo? Le but serait d’éviter les $>sudo su et ainsi de forcer tous les utilisateurs à utiliser su.
2 - On conseille de changer le port SSH (par défaut 22) pour éviter les bruteforce courants sur ce port. Faut-il en faire autant avec les ports FTP?
3 - Finalement, il arrive qu’on parle de créer un utilisateur par service. Chacun de ces services serait ainsi accessible pour ce seul user et chaque user n’aurait accès qu’à son service. Qu’en dîtes-vous?

J’attend vos réactions! :smiley:
M.

  1. sudo n’étant pas un paquet de base d’une debian, tu peux le supprimer sans problème.
  2. plutôt que d’utiliser FTP, regarde plutôt du côté de SFTP si tu veux de la sécurité.

Merci pour ta réponse Iroy,
A vrai dire, j’utilise proFTPD et je crois savoir qu’il gère le SFTP, je vais donc voir du côté configurations. D’autres idées? :slightly_smiling:

Voir le guide de la sécurité Debian (cf. ma signature) pour les idées :stuck_out_tongue:

Merci agentsteel,
j’avais repéré ton dernier lien, je compte bien lire tout ça avec beaucoup d’attention!

Lut,
Pour être contrariant… :smiley:

Quel est donc le problème avec sudo?
il demande un mot de passe de la même façon que su.
loggue les accès nominativement contrairement à su
te permets de limiter les droits de chaque utilisateur et groupe … contrairement à su

Pour le SFTP bah ce n’est à mon sens pas la réponse à la question "comment je sécurise mon FTP"
Moi je propose plûtot FTPS ou FTPES (FTP classique avec certificat donc) plus fail2ban.

Pourquoi changer les ports par défaut…
Evidemment cela limite les scans… mais en même temps avec une bonne politique de mots de passe et un bon fail 2ban c’est réglé.

A mon sens les scans ne sont pas dangereux si on se prépare un minimum, par contre les vrais attaquants qui t’en veulent à toi… contre eux tu pourra changer le port cela ne changera rien, ils le trouveront et tenteront de rentrer…

Changer le port c’est par contre complexifier la vie des utilisateurs, voir rendre l’accès au service impossible (par exemple sur certains hotspot c’est 80/ 443 et udp 53 et c’est tout…)…
C’est le modèle de la sécurité par l’obscurité… si tu penses que tu est protégé car personne ne voit ton service…

Pour être constructif ^ ^
Pourquoi pas SFTP
Ce n’est pas du FTP (donc solution à coté du besoin énoncé) - je ne sais pas pour le besoin réel
Il faut laisser un accès SSH à tous les users (même si on peut effectivement le limiter)
on peut écouter en SSH avec openssh-server et en même temps avoir proftpd en ecoute pour le sftp ? (vrai question hein :slightly_smiling: )

3
Je pense qu’il y a une petite confusion.
Quand on parle d’avoir un utilisateur par service cela signifie que le service tourne avec un utilisateur particulier (et différent des autres service, et par root evidement).
Ce qui permet en cas de corruption du serveur de limiter la casse .

Par exemple
tu crée un user websrv qui sera utiliser pour faire tourner ton serveur web.
il n’a besoin des droits d’ecriture que sur les repertoires web (et encore dans certains cas)
tu peux donc limiter les droits.
Si ton serveur Web est corrompu, l’attaquant ne pourra créer des fichier que dans la zone du serveur Web n’ayant à priori pas les droits de créér des fichiers ailleurs…

Bon je schématise un peu mais l’idée est là.

Salut jackall,
Tu as raison d’être contrariant, ça nourrit les discussions!
Les arguments que tu avances pour la commande sudo me semble très intéressant (notamment les logs nominatifs). Mais pour en arriver là, il faut une bonne configuration de sudo (etc/sudoers ?) car ce que je ne veux surtout pas, c’est que mes utilisateurs puissent outrepasser leur session en devenant root avec la commande “sudo su” qui exempte d’avoir à connaître le mot de passe root.

Je lis souvent des topics qui préfèrent le SFTP au FTPS car ce dernier est jugé trop compliqué… Balivernes? Après tout, ce qui marche si bien pour le HTTPS devrait bien fonctionner pour le FTPS.

Par chance j’ai déjà installer Fail2ban, et il paraît qu’il est en effet suffisamment efficace pour ne pas avoir à se passer du changement de port FTP.
Par ailleurs, j’utilise actuellement proFTPd sans qu’aucune autre raison que la précipitation ne justifie mon choix, y’a-t-ils des services plus compétents ou bien se valent-ils tous (bien que je doute qu’ils aient tous les mêmes fonctionnalités) ?

Concernant sudo, il ne faut pas l’installer si il n’est pas utile.
Comme tout logiciel, il possède potentiellement des failles de sécurité, et peut être mal configuré.
Donc pour réduire la surface d’attaque, il est prudent de ne pas l’installer.
Et c’est valable pour tout logiciel, mais particulièrement ceux qui sont lancés avec les droits root.

Bonjour,

Je partage aussi cet avis ; un nmap bien scripté fait des miracles et ne reste pas dans l’obscurité longtemps…

[quote=“NairOS”]
Par ailleurs, j’utilise actuellement proFTPd sans qu’aucune autre raison que la précipitation ne justifie mon choix, y’a-t-ils des services plus compétents ou bien se valent-ils tous (bien que je doute qu’ils aient tous les mêmes fonctionnalités) ?[/quote]
J’ai longtemps utilisé ProFTPD pour un usage personnel, mon seul critère de choix à l’époque (années 2000) était que Free le déployait pour ses clients/utilisateurs. (Quel critère… :wink: ).
Entre temps, je me suis penché sur la question et me suis tourné vers VSFTPd (pour VerySecureFTPd)
J’avais lu à divers endroits qu’il était plus simple que ProFTPD qui ne devait être choisi que s’il y avait un réel besoin, du fait des nombreuses failles non résolues. Est-ce le cas encore aujourd’hui ?
Toujours est-il que c’est VSFTPd que j’ai choisi d’utiliser dans le cadre professionnel.

Vu la nature des objectifs (la sécurité), le choix de VSFTPd me semble cohérent.

Si par FTPS, on entend FTP sur SSL, la configuration avec VSFTPd n’est pas compliquée.
Quelques lignes supplémentaires dans le fichier de configuration et le tour est joué :slightly_smiling:

[quote=“aazudd”]Bonjour,

Je partage aussi cet avis ; un nmap bien scripté fait des miracles et ne reste pas dans l’obscurité longtemps…

[quote=“NairOS”]
Par ailleurs, j’utilise actuellement proFTPd sans qu’aucune autre raison que la précipitation ne justifie mon choix, y’a-t-ils des services plus compétents ou bien se valent-ils tous (bien que je doute qu’ils aient tous les mêmes fonctionnalités) ?[/quote]
J’ai longtemps utilisé ProFTPD pour un usage personnel, mon seul critère de choix à l’époque (années 2000) était que Free le déployait pour ses clients/utilisateurs. (Quel critère… :wink: ).
Entre temps, je me suis penché sur la question et me suis tourné vers VSFTPd (pour VerySecureFTPd)
J’avais lu à divers endroits qu’il était plus simple que ProFTPD qui ne devait être choisi que s’il y avait un réel besoin, du fait des nombreuses failles non résolues. Est-ce le cas encore aujourd’hui ?
Toujours est-il que c’est VSFTPd que j’ai choisi d’utiliser dans le cadre professionnel.

Vu la nature des objectifs (la sécurité), le choix de VSFTPd me semble cohérent.

Si par FTPS, on entend FTP sur SSL, la configuration avec VSFTPd n’est pas compliquée.
Quelques lignes supplémentaires dans le fichier de configuration et le tour est joué :slightly_smiling:[/quote]

Proftpd, Vsftpd c’est du pareil au même niveau sécurité, seul la configuration change et encore que lorsque l’on cherche à interfacé le bouzin avec une base de données c’est kif kif.

J’utilise Pureftpd personnellement, mais au travail c’est essentiellement Vsftpd de façon classique ou Proftpd lorsque cela sort du cadre conventionnelle.

[quote]Pourquoi changer les ports par défaut…
Évidemment cela limite les scans… mais en même temps avec une bonne politique de mots de passe et un bon fail 2ban c’est réglé.[/quote]

Changer les ports par défauts est un bon moyen de se protéger des 0days disponibles utilisés par les bots qui scannent justement les ports par défauts.

Vérifie que ton serveur web “tourne” bien sous le compte www-data et non pas root, cela est catastrofique lors de compromission (sauf si SELinux est de la partie :smiley: ).

Changement des ports par défaut + pare-feu + mots de passe complexe (voir utilisation de certificats ou bi clé RSA 2048bits pour le SSH) + système maintenu à jour ! + fail2ban + portsentry + limiter les paquets installées au juste besoin et les sécuriser indépendamment les uns des autres (défense en profondeur) te permettront de partir serein pendant quelques années :smiley:

Une fois tout ceci mis en place tu peux t’auto auditer via Lynis (qui a été mis à jour récemment et de donnera un petit apercu des oublis) + un scan Nmap (attention si portsentry est déjà présent !) suivi de Nessus.

N’oublie pas de “chrooter” tes utilisateurs :079 voir les services installés :013 si tu veux diminuer l’impact d’une personne malveillante ayant pu outre passer ces éléments de sécurité.

pour mon usage privé et familial j’utilise depuis longtemps proftpd (avec login et passwd) qui ne m’a jamais posé de pb de sécurité,il suffit de donner les bons droits 755 avec chown sur le répertoire ftp (je reste propriétaire du répertoire ftp) et ainsi les utilisateurs peuvent lister et télécharger les fichiers;et c’est là tout ce qu’ils ont le droit de faire.Pour uploader des fichiers à distance sur mon serveur ftp je me sers de la commande scp qui vient avec ssh.
La configuration de tout ça est simplissime.
Chrootage des utilisateurs bien sûr!

!!! IPTABLES !!!

Lut,

Au vu de toute les contributions je me permets de préciser ma pensé/façon de voir…

La sécurité absolue n’existe pas!! Partant de là la vrai sécurité est un curseur à placer entre protection du serveur/service et fonctionnalité…

Quand je vois ça je suis presque d’accord dans l’absolue… c’est cool technologiquement parlant… mais après quoi… c’est complexe à mettre en place / a maintenir / a mettre en oeuvre / a debugger…
Et surtout en fonction de l’utilisation du besoin, j’ai l’impression que c’est quand même prendre un lance roquette pour tuer une mouche… :smiley:
Faut pas oublier que dans sécurité il y a aussi disponibilité… si je mets 3 jours à debugger un service qui ne fonctionne pas au lieu d '1 bah j’ai raté quelque chose dans la mise en place…

C’est sur ça fonctionne, mais un peu de pragmatisme ne fait pas de mal selon moi…

Et pour prendre l’exemple des ports, un portsentry peut se justifier selon la criticité mais mes serveurs sont protégés par un FW et fail2ban, je regarde les logs tous les matins, je suis les grosses failles de sécu… et résultat des courses mon serveur n’est à mon sens pas plus en danger qu’un autre.

Que serait le monde sans les Well Known ports… on ferait quoi si chaque site Web utilisait sont propre ports…

A l’inverse j’ai récemment fait un audit de sécu pour une boite qui avais tout fermé, changer les ports par défauts et laisser uniquement ouvert un acces HTTPS avec authentification… bah j’ai quand même trouver un compte valide, je suis rentré etc…

Bref tous ça pour revenir à mon histoire de curseur, la meilleur archi technique ne vaut rien si elle ne survit pas à l’épreuve de l’exploitation.

Mais bon au dela de ça si c’est juste pour toi pas nécessairement critique et que tu veux tester, bah fait toi plaisir ça ne peut pas faire de mal. Mais si c’est pour du pro je dirais Keep It Simple…( attention simple, pas simpliste ^^).

Pour l’histoire du serveur FTP, bah prend celui avec lequel tu te sens le mieux, dans les fait s’il est toujours maintenue cela ne changera rien, si il y avait un produit ultime on serait au courant :stuck_out_tongue:

Pour le sudo je suis d’accord, si tu n’en n’as pas besoin, oublie. Mais si certain utilisateur doivent pouvoir effectuer des taches en root ou autre alors pour moi un sudo bien configuré est la solution…

Mais du coup avec mon discours je me pose une question, sur vos serveurs vous faite systématiquement les mises à jours?

On est d’accord en terme de sécu c’est ce qui est conseillé, mais en vrai tout n’est pas si simple.
Dans un cadre pro faire une mise à jour c’est prendre un risque d’instabilité d’interaction non souhaité etc…
evidement c’est rare, mais si on considère que la disponibilité est une des composante de la sécu, alors ce risque est à prendre en considération.

Désolé pour le post fleuve :slightly_smiling:
++

ton approche est intéressante, et méritait un post aussi long :slightly_smiling:
Je rajouterai que le niveau de sécurité doit être proportionnel à la valeur des données à protéger.

Petite question à tous les utilisateurs patenté de fail2ban en IPV6 vous faites comment (question comme ça, je ne m’en sert plus de fail2ban depuis que je suis passé à l’IPV6 justement ^^ protégé par la masse et quelques règles bien senti).

Maintenant Si Pascal passe par ici il aurait peut-être une idée pour mettre ne place un système de règle anti-bruteforce à base de règle iptable/ip6table couplé au module xt_recent.
Mais mes derniers essai n’était guère concluant en IPV4 et me faisait même ‘laguer’ le surf sur une série de simple page html.

A titre personnel, mes serveurs dédiés GNU/Linux se mettent à jour chaque jour quotidiennement et automatiquement depuis des années. Ma supervision ou mes utilisateurs m’indiqueront rapidement un incident si il se produit et mes sauvegardes correctement réfléchies ET effectuées m’assurent les arrières en cas trop grosses difficultés. Je trouve plus “professionnel” d’annoncer à mes clients “désolé cela est du à la mise à jour de sécurité publiée en urgence cette nuit (et appliquée automatiquement), je restaure de suite le serveur (indispo = 1h max après signalement)” plutôt que "oui le serveur est piraté à cause d’une vulnérabilité connue de l’année dernière, faut que je regarde si on a une sauvegarde et si elle fonctionne…

A titre professionnel, lors d’audit (moi aussi 8) ), j’entends souvent la dispo et le coût comme excuse à des MCO / MCS correctement réfléchit et appliqué (mais ça existe :023 ).

Maintien en condition opérationnel (PCA) et maintien en condition de sécurité.

Après personnes n’est absolument en sécurité : l’exemple du soir

@Clochette : J’utilise pas encore IPv6 :075
@piratebab : Bien souvent les textes obligent l’hébergeur, le fournisseur de services,… a protéger les données utilisateurs.

Travaillant justement chez un hébergeur nous n’effectuons aucune mise à jour sans en avoir jaugés les impact éventuel, régression possible voir incompatibilité avec l’existant et les besoins du clients.
A noter que les plateformes des clients sujettent à de l’infogérance sont systématiquement protéger avec du firewall applicatif ou hardware et soumise à un monitoring très strict.
Et donc forcèmenet auditées régulièrement.

Le plus chiants c’est de plabnifiés avec l’accord du clients les reboot obligatoires heureusement peu nombreuses.

Donc oui tu mets dans le mile … on la fait la MAJ ou pas, et si on la fait pas, qu’est ce qu’on fait ?

Dommage quand tu vois la taille d’un slah je souhaite du courage à ceux qui tentent des scannes depuis de pauvres petits VPS :whistle:

Oui bien entendu, c’est pour ça que les plate-formes internes sont très rigoureuses en termes de sécurité, mais nous ne sommes jamais à l’abri d’un zéro day et dans ce cas c’est la veille des alertes et la vitesse de correction qui prime.

Pour ce qui est du client, j’oserai dire lambda, nous diffusons une ‘newsletter’ pour les problèmes de sécurité vraiment graves sinon c’est au client de prendre soin de ne pas se faire couper et de faire un tantinet son job :whistle:

Merci des retour.

@Clochette
Il existe un patch IPv6 pour fail2ban, mais je n’ai jamais testé…

Sur les mises à jours, me concernanr j’ai un peu tous les point de vu…
J’ai bossé chez un hébergeur, et je bosse dans une SSI qui est aussi opérateur… du coup
J’e suis d’acccord faire une mise à jour de secu pour corrigé une faille qui ne “touche pas mon système” me parait pas intéressant dans l’absolu.

Mais quand il faut il faut et là effectivement ça se complique…

Mais coté SSII quand on fait des audits bah on est tombe forcement sur des serveurs non à jours mais les clients qui font leur exploite eux même ne veulent pas entendre parler de mise à jours automatique…

Sur Windows pas de soucis , wSUS et consort + 2 patch days par mois et le tours est joué, mais sous GNU/Linux j’ai un peu de mal à soutenir le discours…
Surtout si on parle de vrai serveurs applicatif avec deu dev maison /des applis compilé etc…
Là evidement mettre à jour un système qui n’a pas connaissance de certaines appli qui sont dessus , et donc ne prend pas en compte les dépendances c’est chaud…

@secuIP
Comme dis précédemment, dans l’absolu pas de problème avec ton discours , je suis plutôt d’accord.
Mais si tu vois les choses façon exploitation ne vaut il pas mieux ne pas faire de MAJ, comme ça pas de coupure du tout.
Et grâce à la veille techno: une grosse faille qui me concerne je corrige avec une maintenance préventive. mais le reste du temps si ça ne me concerne pas , pas besoin dans l’immediat…

[quote=“jackall”][…]On est d’accord en terme de sécu c’est ce qui est conseillé, mais en vrai tout n’est pas si simple.
Dans un cadre pro faire une mise à jour c’est prendre un risque d’instabilité d’interaction non souhaité etc…
evidement c’est rare, mais si on considère que la disponibilité est une des composante de la sécu, alors ce risque est à prendre en considération.

Désolé pour le post fleuve :slightly_smiling:
++[/quote]

Ce que tu dis rejoint ce que j’ai constaté. Une mesure trop contraignante peut être pire que le mal soigné. J’imposais à 80 personnes un changement de mot de passe chaque année (mot de passe aléatoire délicat à se rappeler). Cela s’est traduit par des papiers avec login/mot de passe oubliés. J’ai du coup changé mon fusil d’épaule et reconduit les mots de passe d’une année à l’autre (sans rappel donc). Au bout de 2 ans, les mots de passe sont commus et plus de bout de papier. Inconvénient, il faut pour moi vérifier la cohérence des connexions.
De façon générale, j’essaye non pas de blinder mes serveurs mais d’être sur d’identifier immédiatement une connexion non désirée ou une compromission d’une machine.