Discussion :

[den66]

Bonjour

C'est juste une vérification que je demande ici.
J'utilise SPIP et pour les dossiers ou le site doit écrire, il demande à ce que les droits soit 777

J'ai essayé de changer l'utilisateur sur le dossier et de mettre www-data comme utilisateur et 755 comme droit. Ça fonctionne sauf que la question est :

QUEL EST LE PLUS SÉCURISÉ ?

Merci d'avance pour vos réponses.

[BufferBob]

salut den66,

777 est le mode le plus permissif qui soit, 755 est un mode assez standard pour les répertoires, pour les fichiers on a en général 644
la méthode "la plus sécurisée" consiste à donner les droits adéquats en changeant éventuellement le propriétaire et le groupe des fichiers
plutôt qu'un répertoire qui appartient à root.root et avec un mode 755, on préfèrera un répertoire appartenant à www-data.www-data avec des droits 750 typiquement

les droits unix ne sont pas hautement compliqués, pourtant très peu de gens en tirent parti convenablement au quotidien, et je pense que la foultitude d'applications web qui préconisent de "tout mettre en 777" n'y est pas étrangère, un peu comme si dans la procédure d'installation d'un serveur ftp on te conseillait de ne pas mettre de mot de passe sur ton compte ssh parce que c'est plus simple, de mon point de vue c'est inadmissible qu'en 2016 on trouve encore des trucs comme ça en pagaille dans les docs mais bon...

[Escapetiger]

Bonjour,

Par définition 777 est en lecture, écriture et exécution (rwx) pour tout le monde et 755 en lecture et exécution pour les users autres que le propriétaire www-data .

Cette dernière option est de facto plus sécurisée.

Après, les questions sont:

- Qui était le propriétaire initial (avant www-data) ?

- Est-ce que le site fonctionnera dans ce cas ?

http://cyberzoide.developpez.com/unix/droits.php3

[Edit]
BufferBob me "grille" à 06;19

[den66]

Bonjour

Merci à tous les deux pour vos réponses. C'est bien ce qu'il me semblait.
Je viens de voir aussi que pour sécurisé un peu plus php (je me suis fais véroler des fichiers php récemment ce qui m'a mis dans une situation très embarrassante ! ), j'ai vu qu'il y avait la possibilité d'installer Apache itk-mpm
Le problème est que certains disent que l'installation de cette "version" d'apache entraine l'effacement du contenu du dossier /var/www.
J'ai lu aussi que pour sécuriser ses fichier php, on pouvais utiliser le paquet libapache-mod-security et configurer ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
<IfModule mod_security2.c>
 
# enable mod_security 
SecRuleEngine On
# access to request bodies
SecRequestBodyAccess On
#SecRequestBodyLimit 134217728
#SecRequestBodyInMemoryLimit 131072
# access to response bodies
SecResponseBodyAccess Off
#SecResponseBodyLimit 524288
SecResponseBodyMimeType (null) text/html text/plain text/xml
#SecServerSignature "Apache/2.2.0 (Fedora)"
 
SecUploadDir /tmp
SecUploadKeepFiles Off
 
# default action
SecDefaultAction "log,auditlog,deny,status:406,phase:2,t:none"
 
SecAuditEngine RelevantOnly
#SecAuditLogRelevantStatus "^[45]"
# use only one log file
SecAuditLogType Serial
# audit log file
SecAuditLog /var/log/apache2/modsec_audit.log
# what is logged
SecAuditLogParts "ABIFHZ"
 
#SecArgumentSeparator "&"
SecCookieFormat 0
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel        0
 
SecDataDir /tmp
SecTmpDir /tmp
 
#########
# RULES
#########
 
# File name
SecRule REQUEST_FILENAME "modsecuritytest1"
# Complete URI
SecRule REQUEST_URI "modsecuritytest2"
SecRule REQUEST_FILENAME "(?:n(?:map|et|c)|w(?:guest|sh)|cmd(?:32)?|telnet|rcmd|ftp)\.exe"
 
</IfModule>

Si je peux me permettre de vous demander votre avis sur ces procédures, ce serait super.
Il n'est pas facile d'apprendre tout seul quand on a peur de faire de grosses boulettes !

Merci d'avance pour votre aide.

[BufferBob]

Je viens de voir aussi que pour sécurisé un peu plus php (...) j'ai vu qu'il y avait la possibilité d'installer Apache itk-mpm

changer le type d'Apache ne sécurise rien en soi, ça va juste permettre d'exécuter PHP dans un processus séparé et plus en module directement, ce qui ensuite permet de mieux isoler le contenu web, c'est utile typiquement dans le cas où on a plusieurs sites web, chaque site tourne sous un utilisateur spécifique et moyennant les droits adéquats la compromission d'un site web ne permet alors plus la compromission des autres sites

Le problème est que certains disent que l'installation de cette "version" d'apache entraine l'effacement du contenu du dossier /var/www.

c'est un moindre problème ça...

J'ai lu aussi que pour sécuriser ses fichier php, on pouvais utiliser le paquet libapache-mod-security

méfiance avec mod_security, sur le papier c'est très bien, en pratique ce n'est pas un outil qu'on pose et qu'on oublie, il convient de le maintenir autant sinon plus que le serveur Apache, et sa configuration demande par ailleurs de bonnes connaissances en sécurité

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
(...)
   SecRule REQUEST_FILENAME "modsecuritytest1"
   SecRule REQUEST_URI "modsecuritytest2"
   SecRule REQUEST_FILENAME "(?:n(?:map|et|c)|w(?:guest|sh)|cmd(?:32)?|telnet|rcmd|ftp)\.exe"
</IfModule>

illustration typique de ce que je te disais au dessus, cette règle sert à matcher tout un tas de fichiers .exe, alors que ton serveur est sous Linux, ça n'est donc pas pertinent, par ailleurs les sets de règles qu'on trouve sur le net même s'ils sont bons dans l'absolu vont souvent lever des faux-positifs, ce qui risque de dégrader la disponibilité de certaines pages sur tes sites web

plutôt que de te lancer sur mod_security et cie. apprends à gérer les droits unix correctement dans /var/www/ et garde tes outils à jour, rien que ça c'est déjà 90% de risques en moins
quant à changer à terme de serveur web, tant qu'à mettre un apache-itk autant préférer un nginx avec php-fpm, mais c'est hors considérations de sécurité, et ça nécessite de savoir un peu où on va avant de migrer

[den66]

Salut BufferBob

Merci pour tes conseils toujours pertinents et je vais essayer d'apprendre à gérer les droits correctement et éviter de me lancer dans des trucs que je ne maîtriserais pas.

[den66]

Rebonjour à tous

Vraiment désolé de revenir encore vous tartiner avec mes problèmes.
J'essaie de suivre les conseils de BufferBob en apprenant à ma servir correctement des droits.
Donc, nous sommes sur spip. Il a y trois dossiers qui doivent être accessibles en écriture par le site.
Je les ai passés dans le groupe et le propriétaire www-data... mais du coup, quand il écrit un fichier il est en 666 et non 644, ce qui me semble-t-il n'est pas très bon non plus.

Alors est-ce normal ? Suis-je sur la bonne piste ?
Vraiment navré de vous harceler.

[BufferBob]

nous sommes sur spip (...) du coup, quand il écrit un fichier il est en 666

je pense que c'est le fait de SPIP directement, il y a cette commande umask qui permet de déterminer le masque de création des fichiers sous Linux (quand on fait un touch toto par défaut il est en 644 par exemple, c'est lié au umask 022 correspondant, à voir si en le modifiant ça changerait quelque chose mais méfiance là encore, il s'agit d'un paramètre "systemwide", sa modification peut entrainer d'autres problèmes, éventuellement silencieux pendant un temps

encore une fois le paramètre important ici est de comprendre ce que l'on fait pour éventuellement apporter quelques modifications mineures, en mode horloger, plutôt que s'en remettre à tout et n'importe quoi trouvé sur le net et se lancer dans des grands travaux qui peuvent éventuellement déstabiliser le fonctionnement des sites
par ailleurs il faut faire la distinction entre les fichiers lus par apache/mod_php et les fichiers écrits par php (spip), le propos étant non pas d'arriver à faire en sorte que les fichiers aient tous des droits 3879 mais que les droits aient une cohérence globale dans l'optique de protéger le système d'une éventuelle intrusion

pour le dire simplement et néanmoins sans offense aucune, il y a évidemment pleins de choses à possibles à faire entre l'écriture de romans, de poésie, la rédactions de blogs, d'articles journalistiques, l'écriture de thèses diverses etc. mais à un élève de CP on ne propose rien de tout ça, on l'invite plutôt continuer d'apprendre à écrire, on pourrait lui filer un blog ou n'importe quel support, mais il n'en sortira rien de concluant

encore une fois on parle ici de connaissances (et de leurs mises en relations surtout) en administration Linux et en sécurité, ça n'a rien de simple, à défaut de s'y intéresser suffisamment pour entamer un apprentissage de toutes façons assez long, la moindre des choses est de tenir ses logiciels à jour de manière impérative et quasi-quotidienne, c'est à la fois la première ligne de défense et à la fois celle qui élague le plus

[chrtophe]

Autre point, tu dis t'être fait véroler des fichiers. Ton SPIP ou ses éventuelles extensions sont à jour ? Si tu es sur un vieux SPIP, il est probablement vulnérable.

[den66]

OK BufferBob
Je vais m'en tenir à cela. Je voulais juste éviter de devoir avoir des dossiers en 777 pour que le spip fonctionne. Donc, chaque jour, vérification des mAJ spip, plugins et système. Ça marche.
Et je ne prends pas mal le parallèle avec un élève de CP. C'est aussi mon sentiment, avec l'impression de devoir faire un devoir de terminal.
Merci à tous pour aide et point de vu.

[BufferBob]

Ton SPIP ou ses éventuelles extensions sont à jour ? Si tu es sur un vieux SPIP, il est probablement vulnérable.

c'était tout le propos justement, de vieux SPIP qui se sont vus exploiter, probablement par un botnet ou un autre

Je vais m'en tenir à cela. Je voulais juste éviter de devoir avoir des dossiers en 777 pour que le spip fonctionne.

disons que dans l'ordre, quelque soit les droits sur tes fichiers SPIP est censé être suffisamment bien codé pour empêcher toute intrusion par son intermédiaire, affiner les droits fait office de "couche supplémentaire", et c'est finalement comme ça que fonctionne la sécurisation, on empile les couches les unes sur les autres, les experts te diront probablement dans le but de seulement ralentir un pirate déterminé, toujours est-il que la principale ligne de défense, c'est des SPIP à jour

Donc, chaque jour, vérification des mAJ spip, plugins et système. Ça marche.

il semble que SPIP dispose d'un écran de sécurité (à installer ?) qui permet entre autres de vérifier rapidement ce genre de choses

sinon, une amélioration possible pourrait consister à créer une sonde qui check automatiquement toutes les 6h si il y a une mise à jour, et le cas échéant t'envoie un mail (il convient de bien la tester au préalable évidemment avant de se reposer entièrement dessus), à la fois ça oblige à coder un peu (shell ?) et à apprendre à faire des tâches d'administration de base, à la fois ça rend moins pénible la vérification des mises à jour, tout en étant très peu intrusif sur le système : c'est tout bénef

[den66]

Oui, l'écran de sécurité est bien installé.
J'ai enregistré le flux RSS de spip contrib qui devrait me mettre au courant des nouvelles versions.
Je vais donc faire confiance dans la programmation de spip et être vigilant sur les MAJ.
Pour le reste, je crois qu'il faut que je prenne des cours. Je vais surement commencer par voir les tuto de developpez.com.
Encore merci pour ton soutien et tes conseils particulièrement avisés.

[Pierre Louis Chevalier]

C'est ça il faut que tu te formes, exemple :
Cours et tutoriels Linux
Cours et tutoriel développement Web
Cours et tutoriels PHP

[den66]

Bonjour Pierre Louis Chevalier
Merci pour les liens, ça fait gagner du temps. Je regarde ceux de linux de ce pas.