Les droits et fichier changent tout seul Oo
Résolu/Fermé
mazzz86
Messages postés
6
Date d'inscription
mardi 2 février 2010
Statut
Membre
Dernière intervention
3 février 2010
-
2 févr. 2010 à 12:43
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 3 févr. 2010 à 14:47
mamiemando Messages postés 33079 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 23 avril 2024 - 3 févr. 2010 à 14:47
A voir également:
- Les droits et fichier changent tout seul Oo
- Fichier rar - Guide
- Fichier host - Guide
- Fichier iso - Guide
- Comment réduire la taille d'un fichier - Guide
- Ouvrir fichier .bin - Guide
11 réponses
mazzz86
Messages postés
6
Date d'inscription
mardi 2 février 2010
Statut
Membre
Dernière intervention
3 février 2010
1
3 févr. 2010 à 13:40
3 févr. 2010 à 13:40
Bien joué les gars.
En effet il s'agissait bien du msec qui vérifiait toutes les heures certains paramètres de sécurité.
Merci à tous pour votre aide !!
@+
En effet il s'agissait bien du msec qui vérifiait toutes les heures certains paramètres de sécurité.
Merci à tous pour votre aide !!
@+
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
2 févr. 2010 à 12:58
2 févr. 2010 à 12:58
1°/ La connexion SSH en "root" ne fonctionne pas.
J'ai donc modifié le fichier /etc/ssh/sshd_config et j'ai modifié la ligne PermitRootLogin à yes
Je relance le démon ssh, je me reconnecte en root, cela fonctionne.
Normal. Ceci dit d'un point de vue sécurité ce n'est pas une idée géniale d'autoriser les connexions ssh en root, car c'est le premier compte que quelqu'un tentera d'attaquer. Si le mot de passe est faible... c'est dommage.
En général, root se crée un compte utilisateur sur lequel il se connecte en ssh, puis passe en root avec la commande :
Au bout d'un certain temps où je ne me suis pas connecté, la connexion en root ne fonctionne plus et la ligne PermitRootLogin est repassé à "without-password" !! C'est à n'y rien comprendre. Je précise que je suis le seul à accéder à ce serveur.
Un fichier ne change pas par magie je te rassure. A priori quelqu'un la changé (peut être une tâche planifiée dans un cron ?). Tu peux par exemple regarder la date du dernier accès :
Tu dois avoir possibilité avec des commandes comme ftrace, strace, ou lsof de surveiller l'activité sur ce fichier. A priori plutôt lsof :
http://www.delafond.org/traducmanfr/man/man8/lsof.8.html
2°/ Les droits se modifient tout seul
J'ai créé un outil de configuration en php qu'y s'utilise donc via un navigateur. J'ai donc installé apache et tout configuré. Cet outil doit pouvoir recharger la configuration de squid via la commande "service squid reload"
Il est impossible de lancer cette commande avec l'utilisateur apache, ce qui est normal.
J'ai donc copié la commande /sbin/service dans /bin/service, puis modifié les droits :
chown root:apache /bin/service
chmod 755 /bin/service
Oulala stop. Aucune raison de copier un binaire, surtout de /sbin dans /bin. Cette commande doit (si elle est non trouvée parce que /sbin n'est pas défini dans la variable d'environnement PATH) être appelée explicitement par la commande /sbin/service.
Pour afficher tes variables d'environnement :
A priori il ne faut
J'ai ensuite modifié les droits du service squid :
chown root:apache /etc/init.d/squid
chmod 755 /etc/init.d/squid
NON !
Déjà pourquoi les membres en dehors de apache aurait les droits en éxecution sur /etc/init.d/squid ? Ce serait plutôt du 750. Ensuite comme je t'ai dit, on ne modifie jamais les droits sur des documents en dehors de ton home.
Squid n'a aucune raison de changer de propriétaire, donc remets-lui ses droits et propriétaires initiaux. C'est simplement ton apache qui doit utiliser des trucs comme suphp.
http://doc.ubuntu-fr.org/suphp
mon outil fonctionne bien, mais même problème qu'avec SSH, au bout d'un certain moment, ou d'un reboot, les droits du fichier /etc/init.d/squid reviennent en 700 root root.
Tant mieux :-) Ils sont bien mieux comme ça. Ceci dit ils n'ont a priori pas de raison de changer. Peux-tu me donner le résultat de la commande :
Le but est de voir quels systèmes de fichiers tu utilises. Typiquement de la FAT32 (vfat) ne stocke pas de droits, ils sont donc perdus entre deux reboots. A priori ce n'est pas la source du problème si tu as eu le bon goût d'installer linux sur un système de fichiers linux (ext3, ext4, reiserfs...).
Bonne chance
J'ai donc modifié le fichier /etc/ssh/sshd_config et j'ai modifié la ligne PermitRootLogin à yes
Je relance le démon ssh, je me reconnecte en root, cela fonctionne.
Normal. Ceci dit d'un point de vue sécurité ce n'est pas une idée géniale d'autoriser les connexions ssh en root, car c'est le premier compte que quelqu'un tentera d'attaquer. Si le mot de passe est faible... c'est dommage.
En général, root se crée un compte utilisateur sur lequel il se connecte en ssh, puis passe en root avec la commande :
su -
Au bout d'un certain temps où je ne me suis pas connecté, la connexion en root ne fonctionne plus et la ligne PermitRootLogin est repassé à "without-password" !! C'est à n'y rien comprendre. Je précise que je suis le seul à accéder à ce serveur.
Un fichier ne change pas par magie je te rassure. A priori quelqu'un la changé (peut être une tâche planifiée dans un cron ?). Tu peux par exemple regarder la date du dernier accès :
ls -l /etc/ssh/sshd_config
Tu dois avoir possibilité avec des commandes comme ftrace, strace, ou lsof de surveiller l'activité sur ce fichier. A priori plutôt lsof :
http://www.delafond.org/traducmanfr/man/man8/lsof.8.html
2°/ Les droits se modifient tout seul
J'ai créé un outil de configuration en php qu'y s'utilise donc via un navigateur. J'ai donc installé apache et tout configuré. Cet outil doit pouvoir recharger la configuration de squid via la commande "service squid reload"
Il est impossible de lancer cette commande avec l'utilisateur apache, ce qui est normal.
J'ai donc copié la commande /sbin/service dans /bin/service, puis modifié les droits :
chown root:apache /bin/service
chmod 755 /bin/service
Oulala stop. Aucune raison de copier un binaire, surtout de /sbin dans /bin. Cette commande doit (si elle est non trouvée parce que /sbin n'est pas défini dans la variable d'environnement PATH) être appelée explicitement par la commande /sbin/service.
Pour afficher tes variables d'environnement :
env env | grep PATH echo $PATH
A priori il ne faut
JAMAISchanger les droits d'un fichier (exécutable ou autre). On ne devrait JAMAIS changer les droits, ils sont bien configurés par défaut. La seule exception concerne les documents dans ton home directory (là, c'est ton problème). Partout ailleurs, tu es susceptible de faire des boulettes et de compromettre la sécurité de ton système.
J'ai ensuite modifié les droits du service squid :
chown root:apache /etc/init.d/squid
chmod 755 /etc/init.d/squid
NON !
Déjà pourquoi les membres en dehors de apache aurait les droits en éxecution sur /etc/init.d/squid ? Ce serait plutôt du 750. Ensuite comme je t'ai dit, on ne modifie jamais les droits sur des documents en dehors de ton home.
Squid n'a aucune raison de changer de propriétaire, donc remets-lui ses droits et propriétaires initiaux. C'est simplement ton apache qui doit utiliser des trucs comme suphp.
http://doc.ubuntu-fr.org/suphp
mon outil fonctionne bien, mais même problème qu'avec SSH, au bout d'un certain moment, ou d'un reboot, les droits du fichier /etc/init.d/squid reviennent en 700 root root.
Tant mieux :-) Ils sont bien mieux comme ça. Ceci dit ils n'ont a priori pas de raison de changer. Peux-tu me donner le résultat de la commande :
cat /etc/fstab
Le but est de voir quels systèmes de fichiers tu utilises. Typiquement de la FAT32 (vfat) ne stocke pas de droits, ils sont donc perdus entre deux reboots. A priori ce n'est pas la source du problème si tu as eu le bon goût d'installer linux sur un système de fichiers linux (ext3, ext4, reiserfs...).
Bonne chance
judasperge
Messages postés
153
Date d'inscription
jeudi 5 novembre 2009
Statut
Membre
Dernière intervention
19 février 2012
35
2 févr. 2010 à 12:59
2 févr. 2010 à 12:59
après tes modifs t'as bien fait un restart sur tes services..?
c'est vrai que c'est bizarre ton truc...tu peut poster ton squid.conf pour voir ?
c'est vrai que c'est bizarre ton truc...tu peut poster ton squid.conf pour voir ?
mazzz86
Messages postés
6
Date d'inscription
mardi 2 février 2010
Statut
Membre
Dernière intervention
3 février 2010
1
2 févr. 2010 à 15:02
2 févr. 2010 à 15:02
Tout d'abord merci pour vos réponses rapides.
Mamiemando :
"Normal. Ceci dit d'un point de vue sécurité ce n'est pas une idée géniale d'autoriser les connexions ssh en root, car c'est le premier compte que quelqu'un tentera d'attaquer. Si le mot de passe est faible... c'est dommage.
En général, root se crée un compte utilisateur sur lequel il se connecte en ssh, puis passe en root avec la commande :
su -"
Je me doute bien que c'est pas très sécurisé, mais notre système d'information est plutôt bien fait, et les gens se connectent en client léger avec des droits restreints. Ils ne disposent pas de putty ou même des commandes MSDOS. De plus, mon serveur est dans la zone LAN, je ne voyais pas l'intérêt de le mettre dans la DMZ, d'autant plus qu'il gère une authentification avec notre AD. Il est d'autant plus protégé de l'extérieur dans notre LAN. Tout ceci est un autre débat, mais je te remercie pour le conseil.
Il y a tout de même quelque chose qui me parait bizare.
Quand je modifie le fichier sshd_config, et que je relance le service SSH, ma session putty reste ouverte, comme si un autre daemon ssh était en fonctionnement. Ceci explique peut-être que le fichier change ?
"Un fichier ne change pas par magie je te rassure. A priori quelqu'un la changé (peut être une tâche planifiée dans un cron ?). Tu peux par exemple regarder la date du dernier accès :
ls -l /etc/ssh/sshd_config"
J'avais déjà vérifié par cette commande, le fichier s'était bien modifié mais je ne trouvais pas quel utilisateur l'avait fait.
Je vais fouiller les pistes que tu m'as donné
Oulala stop. Aucune raison de copier un binaire, surtout de /sbin dans /bin. Cette commande doit (si elle est non trouvée parce que /sbin n'est pas défini dans la variable d'environnement PATH) être appelée explicitement par la commande /sbin/service.
Pour afficher tes variables d'environnement :
env
env | grep PATH
echo $PATH
OK pour ça. J'appellerai mon script avec la commande /sbin/service
Je vais regarder pour suphp, c'était histoire de pas surcharger la mule, et ça ne me paraissait pas être si mauvais. ;)
mon outil fonctionne bien, mais même problème qu'avec SSH, au bout d'un certain moment, ou d'un reboot, les droits du fichier /etc/init.d/squid reviennent en 700 root root.
Tant mieux :-) Ils sont bien mieux comme ça. Ceci dit ils n'ont a priori pas de raison de changer.
Peut-être qu'ils sont mieux comme ça mais comme tu l'as si bien dit : ils n'ont pas de raison de changer tout seul. Tu crois que c'est le système qui check ça au démarrage ?
Voila le contenu de mon fichier /etc/fstab (pas de FAT sur mon Linux) :
/dev/cciss/c0d0p1 / ext3 relatime 1 1
/dev/cciss/c0d0p6 /cache ext3 relatime 1 2
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
/dev/fd0 /media/floppy auto umask=0,users,iocharset=utf8,noauto,exec,flush 0 0
none /proc proc defaults 0 0
/dev/cciss/c0d0p7 /var ext3 relatime 1 2
/dev/cciss/c0d0p5 swap swap defaults 0 0
Encore merci
Mamiemando :
"Normal. Ceci dit d'un point de vue sécurité ce n'est pas une idée géniale d'autoriser les connexions ssh en root, car c'est le premier compte que quelqu'un tentera d'attaquer. Si le mot de passe est faible... c'est dommage.
En général, root se crée un compte utilisateur sur lequel il se connecte en ssh, puis passe en root avec la commande :
su -"
Je me doute bien que c'est pas très sécurisé, mais notre système d'information est plutôt bien fait, et les gens se connectent en client léger avec des droits restreints. Ils ne disposent pas de putty ou même des commandes MSDOS. De plus, mon serveur est dans la zone LAN, je ne voyais pas l'intérêt de le mettre dans la DMZ, d'autant plus qu'il gère une authentification avec notre AD. Il est d'autant plus protégé de l'extérieur dans notre LAN. Tout ceci est un autre débat, mais je te remercie pour le conseil.
Il y a tout de même quelque chose qui me parait bizare.
Quand je modifie le fichier sshd_config, et que je relance le service SSH, ma session putty reste ouverte, comme si un autre daemon ssh était en fonctionnement. Ceci explique peut-être que le fichier change ?
"Un fichier ne change pas par magie je te rassure. A priori quelqu'un la changé (peut être une tâche planifiée dans un cron ?). Tu peux par exemple regarder la date du dernier accès :
ls -l /etc/ssh/sshd_config"
J'avais déjà vérifié par cette commande, le fichier s'était bien modifié mais je ne trouvais pas quel utilisateur l'avait fait.
Je vais fouiller les pistes que tu m'as donné
Oulala stop. Aucune raison de copier un binaire, surtout de /sbin dans /bin. Cette commande doit (si elle est non trouvée parce que /sbin n'est pas défini dans la variable d'environnement PATH) être appelée explicitement par la commande /sbin/service.
Pour afficher tes variables d'environnement :
env
env | grep PATH
echo $PATH
OK pour ça. J'appellerai mon script avec la commande /sbin/service
Je vais regarder pour suphp, c'était histoire de pas surcharger la mule, et ça ne me paraissait pas être si mauvais. ;)
mon outil fonctionne bien, mais même problème qu'avec SSH, au bout d'un certain moment, ou d'un reboot, les droits du fichier /etc/init.d/squid reviennent en 700 root root.
Tant mieux :-) Ils sont bien mieux comme ça. Ceci dit ils n'ont a priori pas de raison de changer.
Peut-être qu'ils sont mieux comme ça mais comme tu l'as si bien dit : ils n'ont pas de raison de changer tout seul. Tu crois que c'est le système qui check ça au démarrage ?
Voila le contenu de mon fichier /etc/fstab (pas de FAT sur mon Linux) :
/dev/cciss/c0d0p1 / ext3 relatime 1 1
/dev/cciss/c0d0p6 /cache ext3 relatime 1 2
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
/dev/fd0 /media/floppy auto umask=0,users,iocharset=utf8,noauto,exec,flush 0 0
none /proc proc defaults 0 0
/dev/cciss/c0d0p7 /var ext3 relatime 1 2
/dev/cciss/c0d0p5 swap swap defaults 0 0
Encore merci
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
mazzz86
Messages postés
6
Date d'inscription
mardi 2 février 2010
Statut
Membre
Dernière intervention
3 février 2010
1
2 févr. 2010 à 15:07
2 févr. 2010 à 15:07
Judasperge :
Oui je suis sur d'avoir redémarrer mes services :
Voila le contenu de mon fichier squid.conf, bien que je ne comprenne pas en quoi cela puisse interférer. J'ai supprimer les lignes de commentaires bien sur :
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm keep_alive on
acl NTLMUsers proxy_auth REQUIRED
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow NTLMUsers
http_port 3128
maximum_object_size_in_memory 16 KB
cache_dir ufs /cache 100 16 256
logformat squid %tl %>a %Ss/%03Hs %rm %ru %un
logformat common %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st %Ss:%Sh
access_log /var/log/squid/access.log common
url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
url_rewrite_children 5
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern (cgi-bin|\?) 0 0% 0
refresh_pattern . 0 20% 4320
shutdown_lifetime 5 seconds
cache_effective_user squid
cache_effective_group squid
icp_port 3130
error_directory /etc/squid/errors
dns_nameservers 194.2.0.20
append_domain <mondomaine>
forwarded_for off
coredump_dir /var/spool/squid
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
Merci
Oui je suis sur d'avoir redémarrer mes services :
Voila le contenu de mon fichier squid.conf, bien que je ne comprenne pas en quoi cela puisse interférer. J'ai supprimer les lignes de commentaires bien sur :
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 5
auth_param ntlm keep_alive on
acl NTLMUsers proxy_auth REQUIRED
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_access allow NTLMUsers
http_port 3128
maximum_object_size_in_memory 16 KB
cache_dir ufs /cache 100 16 256
logformat squid %tl %>a %Ss/%03Hs %rm %ru %un
logformat common %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %<st %Ss:%Sh
access_log /var/log/squid/access.log common
url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
url_rewrite_children 5
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern (cgi-bin|\?) 0 0% 0
refresh_pattern . 0 20% 4320
shutdown_lifetime 5 seconds
cache_effective_user squid
cache_effective_group squid
icp_port 3130
error_directory /etc/squid/errors
dns_nameservers 194.2.0.20
append_domain <mondomaine>
forwarded_for off
coredump_dir /var/spool/squid
redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf
Merci
mazzz86
Messages postés
6
Date d'inscription
mardi 2 février 2010
Statut
Membre
Dernière intervention
3 février 2010
1
2 févr. 2010 à 16:35
2 févr. 2010 à 16:35
Au passage, je vous prouve le coup du ssh :
J'ai modifié le sshd et redémarré le service sshd.
Je me connecte en root à 15h46 et je ne fais rien.
à 16h30 je fais un ls -l, le fichier a été modifié à 16h01.
Incroyable mais vrai !!
login as: root root@10.50.2.203's password: Last login: Tue Feb 2 15:46:44 2010 [root@PROXY ~]# ll /etc/ssh/sshd* -rw------- 1 root root 3548 2010-02-02 16:01 /etc/ssh/sshd_config
J'ai modifié le sshd et redémarré le service sshd.
Je me connecte en root à 15h46 et je ne fais rien.
à 16h30 je fais un ls -l, le fichier a été modifié à 16h01.
Incroyable mais vrai !!
judasperge
Messages postés
153
Date d'inscription
jeudi 5 novembre 2009
Statut
Membre
Dernière intervention
19 février 2012
35
2 févr. 2010 à 21:57
2 févr. 2010 à 21:57
Re,
mis à part le fait que tu omette de refuser la connection à ceux qui ne sont pas mentionnés dans ton fichier, je ne vois pas grand chose qui me saute au yeux.
tu te connectais sans probléme à ssh avant ..?
tiens j'ai trouvé ça essaye de farfouiller https://wiki.squid-cache.org/Features/Authentication car perso jsuis largué...
mis à part le fait que tu omette de refuser la connection à ceux qui ne sont pas mentionnés dans ton fichier, je ne vois pas grand chose qui me saute au yeux.
tu te connectais sans probléme à ssh avant ..?
tiens j'ai trouvé ça essaye de farfouiller https://wiki.squid-cache.org/Features/Authentication car perso jsuis largué...
mazzz86
Messages postés
6
Date d'inscription
mardi 2 février 2010
Statut
Membre
Dernière intervention
3 février 2010
1
2 févr. 2010 à 23:33
2 févr. 2010 à 23:33
T'inquiète pas pour l'authentification.
Elle s'appuie sur un Active Directory grâce au NTLM. Aucun compte non connu sur l'AD ne peut aller sur le net.
Pour SSH je me connecte sans problème, à part en root :(
Elle s'appuie sur un Active Directory grâce au NTLM. Aucun compte non connu sur l'AD ne peut aller sur le net.
Pour SSH je me connecte sans problème, à part en root :(
jipicy
Messages postés
40842
Date d'inscription
jeudi 28 août 2003
Statut
Modérateur
Dernière intervention
10 août 2020
4 895
3 févr. 2010 à 09:45
3 févr. 2010 à 09:45
Salut,
Effectivement, il semblerait que la piste msec soit la bonne ;-))
Effectivement, il semblerait que la piste msec soit la bonne ;-))
mamiemando
Messages postés
33079
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
23 avril 2024
7 749
3 févr. 2010 à 14:47
3 févr. 2010 à 14:47
En tout cas si tu suis bien les conseils qu'on t'a donné sur les droits, msec ne devrait pas poser problème. Au final ce qu'à fait msec était plutôt une bonne chose et je t'invite à gérer proprement tes droits (et non à désactiver msec ^^).
Bonne chance
Bonne chance
lami20j
Messages postés
21331
Date d'inscription
jeudi 4 novembre 2004
Statut
Modérateur, Contributeur sécurité
Dernière intervention
30 octobre 2019
3 567
3 févr. 2010 à 06:40
3 févr. 2010 à 06:40
Salut,
Il faut peut être regarder côté msec. Voir le niveau de sécurité de système. S'il est élevé peut être que ce qui ça semble bizarre en fait ne l'ai pas.
Je suis d'accord avec les remarques faite par Miss.
Ils ne disposent pas de putty ou même des commandes MSDOS.
Tu ne pourras jamais le savoir. Ils peuvent l'avoir sur une clé USB. Ils peuvent avoir même un cygwin sur une clé usb. Mais comme tu le dis ça c'est un autre débat ;-)
Il faut peut être regarder côté msec. Voir le niveau de sécurité de système. S'il est élevé peut être que ce qui ça semble bizarre en fait ne l'ai pas.
Je suis d'accord avec les remarques faite par Miss.
Ils ne disposent pas de putty ou même des commandes MSDOS.
Tu ne pourras jamais le savoir. Ils peuvent l'avoir sur une clé USB. Ils peuvent avoir même un cygwin sur une clé usb. Mais comme tu le dis ça c'est un autre débat ;-)
