Interdire l'accès à la racine

Lancelot du Lac · 16-03-2016 19:28:15

Bonjour à tous !
Comme j'utilise de plus en plus mon accès ssh, je ne voudrais pas qu'on puisse se servir des codes de mon utilisateur distant pour faire n'importe quoi dans mon système, ou même simplement jeter un oeil. Je voudrais donc interdire l'accès à la racine, voire carrément limiter l'accès au seul dossier personnel de l'utilisateur. Mais je ne voudrai pas faire de bêtise. Est-ce que la commande suivante irait :

chmod -R o-x /

Est-ce qu'il n'y a pas un utilisateur système qui risque d'avoir besoin de l'accès ?
Qu'en pensez-vous ?
Merci d'avance.

raleur · 16-03-2016 19:35:22

J'en pense que ce serait une très grosse bêtise, sauf si le but est de rendre le système vraiment inutilisable.

smolski · 16-03-2016 19:41:27

Mais encore raleur, pourquoi ?

sogal · 16-03-2016 19:49:23

Car aucun autre utilisateur du système (utilisateur "virtuel" sous l'ID duquel s'exécute un processus (ex: www-data pour apache) ou utilisateur humain) n'aurait accès aux ressources essentielles du système comme les utilitaires système de bases, les icônes, les données des programmes etc...

Ex:

ls -al /

[...]

drwxr-xr-x  10 root root  4096 janv. 28 11:23 usr

[...]

À l'issue d'une telle commande ça deviendrait :

[...]

drwxr-xr--  10 root root  4096 janv. 28 11:23 usr

[...]

Donc à moins d'être root ou membre du groupe root, pas moyen de rentrer dans le dossier usr.

raleur · 16-03-2016 19:50:02

Il y a vraiment besoin d'expliquer pourquoi supprimer la permission d'exécution générale sur tous les programmes et répertoires n'est pas une bonne idée ?

sogal · 16-03-2016 19:51:36

raleur a écrit :

Il y a vraiment besoin d'expliquer pourquoi supprimer la permission d'exécution générale sur tous les programmes et répertoires n'est pas une bonne idée ?

À quelqu'un qui méconnaît suffisamment son système et les implications d'une telle commande et qui pose la question avant de faire une bêtise ? Oui, ça me paraît essentiel et l'objet même d'un tel forum

smolski · 16-03-2016 19:52:28

C'est la question posée qui implique que oui, y faut expliquer les conséquences, sinon, pourquoi poser des questions si on connaît déjà la réponse ?

captnfab · 16-03-2016 19:59:11

@raleur: je pense que pour beaucoup qui ne savent pas ce que cela signifie, oui. Et ceux qui posent ce genre de question en font a priori partie

@Lancelot du Lac: la commande que tu proposes interdit à tous les utilisateurs, sauf root, l'exécution de n'importe quel programme présent dans /usr/bin. Mais ce n'est que le moindre des problèmes.

Elle empêche l'exécution du dossier / à tout le monde. Or, pour pouvoir « traverser » un dossier (pour accéder à un sous-dossier), il faut que ce dossier soir accessible en exécution.
Autrement dit, en retirant les droits d'exécution sur / à others, tu empêches tous les utilisateurs de ton système (sauf root) d'accéder à tous les fichiers du système. Ils ne peuvent pas lancer de shell, pas se connecter, rien.
Et quand on dit « tous les utilisateurs » ça inclue aussi les utilisateurs système…

Il est normal que les utilisateurs puissent accéder à /usr/bin et /bin. Si tu ne veux pas qu'ils puissent faire ça, il faut soit leur interdire de se connecter par ssh (mais, par exemple, seulement un accès sftp), soit leur donner un shell restreint.

Lancelot du Lac · 17-03-2016 11:20:42

Ok, merci de vos réponses, ça m'évitera une bourde magistrale ! ;-)
Ce que je voulais surtout, mais je ne sais si je suis clair, c'est qu'un petit malin qui ait récupéré mes codes puisse se balader dans mon système.

sogal · 17-03-2016 11:40:25

En ce cas, sécurise bien ton accès ssh avec, par exemple, un accès par clé uniquement.

Papadakis · 17-03-2016 19:07:01

Et un port autre que 22.

Lancelot du Lac · 18-03-2016 07:30:53

Papadakis a écrit :

Et un port autre que 22.

Ça, c'est bon ! J'ai dû changer quatre fois, je crois.

Du coup, je vais plutôt essayer un chroot, d'après ce que j'ai lu, ça devrait répondre à ma demande.

vv222 · 18-03-2016 09:05:36

Lancelot du Lac a écrit :

Ce que je voulais surtout, mais je ne sais si je suis clair, c'est qu'un petit malin qui ait récupéré mes codes puisse se balader dans mon système.

Un petit malin qui récupérerait tes codes sera capable de faire tout ce que tu fais toi avec ces codes, quelles que soient les sécurités que tu mets en place.

Mon avis sur les différentes solutions proposées :

Changer de port d’écoute pour SSH n’arrêtera pas un attaquant motivé, en fait ça sert essentiellement à avoir un peu moins de "bruit" dans tes fichiers journaux et à te donner un faux sentiment de sécurité.
Le chroot peut paraître attirant, mais garde en tête que tu seras toi aussi coincé dedans, et surtout quelqu’un de suffisamment calé techniquement pourra en sortir pour accéder au reste du système. Si tu choisis cette méthode il faudra absolument que tu sécurises ton chroot autant (sinon plus) que ton système réel.
L’identification par clé, contrairement aux deux précédentes, est une *vraie* solution fiable. Plus moyen d’essayer de deviner ton mot de passe, il faut te voler cette clé pour espérer accéder à ton serveur SSH. Ne reste plus donc qu’à protéger celle-ci, en particulier en ne la copiant pas sur des machines dont tu n’as pas le contrôle total.

sogal · 18-03-2016 09:11:58

vv222 a écrit :

L’identification par clé, contrairement aux deux précédentes, est une *vraie* solution fiable. Plus moyen d’essayer de deviner ton mot de passe, il faut te voler cette clé pour espérer accéder à ton serveur SSH. Ne reste plus donc qu’à protéger celle-ci, en particulier en ne la copiant pas sur des machines dont tu n’as pas le contrôle total.

À ces bons conseils, j'ajouterai l'obligation de protéger ta clé par phrase de passe. Ainsi même si le fichier de clé est dérobé, il est inutilisable sans ta phrase de passe. Et en mode parano, tu peux conserver ce fichier de clé sur une clé USB chiffrée que tu conserverais sur toi.

bendia · 18-03-2016 09:28:29

Salut

Pour ma part, j'ai ajouté une alerte par mail a chaque fois qu'une session root ou user est ouverte.

Si tu es seul à pouvoir te connecter, si tu reçois un mail alors que tu n'as rien fait, c'est qu'il y a un loup

vv222 · 18-03-2016 10:49:26

sogal a écrit :

Et en mode parano, tu peux conserver ce fichier de clé sur une clé USB chiffrée que tu conserverais sur toi.

La mienne se trouve sur une unique machine, au disque intégralement chiffré
Et pour pousser la parano jusqu’au bout même le BIOS de cette machine a été remplacé par libreboot, pour éviter un éventuel firmware espion…
Et comme ça ne suffit toujours pas, cette machine ne me quitte jamais !

raleur · 19-03-2016 12:21:01

vv222 a écrit :

La mienne se trouve sur une unique machine, au disque intégralement chiffré

Vraiment intégralement chiffré ? Même le chargeur d'amorçage et /boot ?
Ou alors tu amorçes depuis un autre support ?

Anonyme-8 · 19-03-2016 12:41:41

s'il utilise libreboot, il me semble que /boot peut également être chiffré.

anonyme · 19-03-2016 14:19:33

le site => https://libreboot.org/docs/gnulinux/gru … aller.html

vv222 · 19-03-2016 14:30:06

raleur a écrit :

Vraiment intégralement chiffré ? Même le chargeur d'amorçage et /boot ?

L’instance de GRUB lancée par libreboot se trouve sur une puce externe au disque dur, le MBR n’est pas utilisé.

-----

Anonyme-8 a écrit :

s'il utilise libreboot, il me semble que /boot peut également être chiffré.

Exact, mais je ne sais pas si c’est vraiment spécifique à libreboot/coreboot, qui fait appel à GRUB pour le lancement de l’OS.

Dernière modification par vv222 (19-03-2016 14:40:46)

raleur · 19-03-2016 15:55:52

vv222 a écrit :

L’instance de GRUB lancée par libreboot se trouve sur une puce externe au disque dur, le MBR n’est pas utilisé.

D'accord pour GRUB, mais pour le noyau et l'initramfs ? le GRUB inclus dans libreboot est capable de lire un /boot chiffré ?

vv222 · 19-03-2016 18:31:32

raleur a écrit :

D'accord pour GRUB, mais pour le noyau et l'initramfs ? le GRUB inclus dans libreboot est capable de lire un /boot chiffré ?

Oui, comme tu peux le voir dans ce guide pour Trisquel facilement adaptable à Debian :
https://libreboot.org/docs/gnulinux/enc … squel.html

raleur · 19-03-2016 20:41:25

Hmm. Quand j'avais essayé avec le GRUB de Debian 8, je n'avais pas réussi à lui faire reconnaître un PV LVM contenu dans un volume chiffré.

fabricew · 31-03-2016 09:12:41

bonjour, tu as des éléments de réponse ici :
https://debian-facile.org/doc:reseau:ss … ssh-server

tu chroot ton utilisateur dans son home.

Moi perso, j ai interdit les logins root via ssh .
J'utilise un utilisateur non privilégié et une fois connécté, je fait une escalade de privilèges via su.
Vu que le tunnel ssh est deja ouvert, le mot de passe root circule sous forme cryptée.

Si tu as reelement besoin d'un log direct root via ssh, tu peut limiter les ip autorisées à se connecter en root.

fichier /etc/sshd_config , ajoutes

Match Address X.Y.Z.A
PermitRootLogin yes

Match Address *
PermitRootLogin no

Debian-facile

#1 16-03-2016 19:28:15

Interdire l'accès à la racine

#2 16-03-2016 19:35:22

Re : Interdire l'accès à la racine

#3 16-03-2016 19:41:27

Re : Interdire l'accès à la racine

#4 16-03-2016 19:49:23

Re : Interdire l'accès à la racine

#5 16-03-2016 19:50:02

Re : Interdire l'accès à la racine

#6 16-03-2016 19:51:36

Re : Interdire l'accès à la racine

#7 16-03-2016 19:52:28

Re : Interdire l'accès à la racine

#8 16-03-2016 19:59:11

Re : Interdire l'accès à la racine

#9 17-03-2016 11:20:42

Re : Interdire l'accès à la racine

#10 17-03-2016 11:40:25

Re : Interdire l'accès à la racine

#11 17-03-2016 19:07:01

Re : Interdire l'accès à la racine

#12 18-03-2016 07:30:53

Re : Interdire l'accès à la racine

#13 18-03-2016 09:05:36

Re : Interdire l'accès à la racine

#14 18-03-2016 09:11:58

Re : Interdire l'accès à la racine

#15 18-03-2016 09:28:29

Re : Interdire l'accès à la racine

#16 18-03-2016 10:49:26

Re : Interdire l'accès à la racine

#17 19-03-2016 12:21:01

Re : Interdire l'accès à la racine

#18 19-03-2016 12:41:41

Re : Interdire l'accès à la racine

#19 19-03-2016 14:19:33

Re : Interdire l'accès à la racine

#20 19-03-2016 14:30:06

Re : Interdire l'accès à la racine

#21 19-03-2016 15:55:52

Re : Interdire l'accès à la racine

#22 19-03-2016 18:31:32

Re : Interdire l'accès à la racine

#23 19-03-2016 20:41:25

Re : Interdire l'accès à la racine

#24 31-03-2016 09:12:41

Re : Interdire l'accès à la racine

Pied de page des forums