web-dev-qa-db-fra.com

meilleures autorisations de fichier journal Apache sur le serveur cpanel

Dans le but de protéger mon site contre les robots malveillants, y compris les pirates ridicules qui peuvent se connecter au serveur, je souhaite sécuriser autant que possible access_log et error_log sans casser Apache ou cpanel.

Je pense que l'utilisateur, quel que soit l'utilisateur Apache, doit avoir un accès en lecture et en écriture au fichier journal.

Je ne sais pas si cpanel a des exigences particulières pour accéder au fichier journal. et je ne sais pas si quelque chose dans cpanel va casser si je mets les autorisations du fichier journal trop restrictives.

Actuellement, je l'ai où tout le monde a un accès en lecture au fichier journal et que seul root et le groupe racine est en lecture et en écriture. Je souhaite supprimer l'accès en lecture pour tous les autres utilisateurs, mais cela affectera-t-il cpanel ou Apache de quelque manière que ce soit?

Mon objectif est d'améliorer la sécurité des sites Web et des serveurs Web et de continuer à servir des pages à haute vitesse sans compromettre les fonctionnalités.

Mon serveur est basé sur Linux.

apachecpanellinuxpermissionsfiles
1
Mike

S'ils parviennent à se connecter via votre shell, alors le jeu est presque terminé et, comme mentionné par @ w3d, les fichiers journaux Apache sont le moindre de vos soucis.

  • Apache écrit directement dans les fichiers journaux, personne ne peut afficher ces journaux à moins qu'ils ne soient stockés dans le chemin d'hébergement.

Si la sécurité est une préoccupation majeure, vous devez alors confirmer que vous utilisez les pratiques suivantes:

  • Votre SSH doit être sécurisé à l'aide de clés SSH, et non de nom d'utilisateur ou de mot de passe, ou même mieux… désactivé si vous ne l'utilisez pas et lancez-le quand vous en avez besoin.
  • Votre compte cPanel doit utiliser un mot de passe complexe, idéalement ... utilisez au moins 12-18 chiffres avec des chiffres, des majuscules et des symboles. cPanel est également en train d’ajouter une authentification bidirectionnelle. Dès que celle-ci est publiée, vous devez l’activer, et il en va de même pour toutes les plates-formes extérieures à cPanel.
  • FTP doit être désactivé en faveur de FTPS ou FTP TLS/SSL. Le serveur doit bloquer la fissuration brutale à l'aide de fail2ban ou similaire.
1
Simon Hayter

Je suis fondamentalement d’accord avec l’affirmation de Simon Hayters selon laquelle s’ils obtenaient un accès à Shell - sauf s’ils disposaient d’un accès limité à Shell par injection dans une application php utilisant Shell_exec -, personnellement, je commencerais à penser à restaurer le système à partir de sources fiables. Mais alors la question devient - si vous ne savez pas comment ils sont arrivés à cette époque - comment pouvez-vous les arrêter la prochaine fois? - avoir des entrées de journal sans compromis peut aider à reconstruire la rupture.

Mais à la question, voici comment nginx (et de mémoire Apache est identique) configure les autorisations de fichier journal sur Ubuntu 14.04.

$ls -al /var/log/
... 
drwxr-s---  2 mysql     adm      4096 Nov 22 06:38 mysql
-rw-r-----  1 mysql     adm         0 Nov 20 17:39 mysql.err
-rw-r-----  1 mysql     adm         0 Nov 22 06:38 mysql.log
drwxr-x---  2 www-data  adm      4096 Nov 22 06:38 nginx
-rw-------  1 root      root        0 Nov 22 06:38 php5-fpm.log
-rw-r-----  1 syslog    adm      9734 Nov 23 00:17 syslog
...

En n'autorisant pas les "autres" sur la nginxrépertoire lui-même - les utilisateurs ordinaires ne peuvent même pas voir les fichiers eux-mêmes - et encore moins les lire. S'ils avaient des permissions root, ils pourraient le faire

$ Sudo ls -al nginx/
total 28
drwxr-x---  2 www-data adm    4096 Nov 22 06:38 .
drwxrwxr-x 13 root     syslog 4096 Nov 22 06:38 ..
-rw-r-----  1 www-data adm    2082 Nov 23 00:30 access.log
-rw-r--r--  1 root     root   9803 Nov 22 06:26 access.log.1
-rw-r-----  1 www-data adm       0 Nov 22 06:38 error.log

Maintenant, sauf si vous êtes www-data, adm ou root, vous ne pourrez pas lire les journaux. access.log.1 qui n'est pas créé par le serveur Web, mais par l'utilitaire d'archivage des journaux logrotate a des autorisations de lecture, mais parce que toute personne qui n'est pas root, www-data ou adm gagné N'ayez pas d'autorisations sur chaque segment du chemin d'accès à /var/log/nginx/access.1.log afin qu'elles ne puissent toujours pas lire le fichier (l'autorisation directory est toujours bloquante).
Vous pouvez donc essayer cette structure d’autorisations - ce qui vous gênera d’administrer car vous devez élever à su ou ajouter votre utilisateur à www-data ou adm groupes ou similaire - en fonction de votre système - juste pour accéder aux répertoires de journaux et lire les journaux.
De plus, il est IMPORTANT de ne pas enfreindre les autorisations de la fonction logrotate, c’est ce qui nettoie vos enregistrements de journal (archivage et suppression des entrées de journal sur un certain âge - généralement un an).

1
the_velour_fog