Bonjour,

imaginons qu'une personne supprime des répertoires du serveur (/boot, /etc,/proc,/opt,...),
y a-t-il un moyen pour savoir :
- quels sont les répertoires et les fichiers supprimés
- comment ils ont été supprimé
- les lignes de commandes tapés
- l'heure à laquelle il y a eu l'incident,
- le cas échéant, l'ip du responsable

je pose cette question, car en entreprise j'ai eu affaire à ce genre d'incident.

Merci d'avance, cordialement.
Pour les repertoires supprimés cité impossible de le faire sans être root, donc le problème est ailleurs (mauvaise gestion utilisateurs, mauvaise sécurité, etc).
Comment ils ont été supprimé, pas besoin de loguer ça, c'est un rm si c'est un utilisateur shell, sinon via un autre programme.
Pour les lignes de commandes tapées ya l'historique de l'utilisateur, pas très fiable si "l'accident" est volontaire, sinon il y a psacct mais je sais pas si c'est toujours d'actualité. Me semble qu'avec auditd/selinux on peut aussi arriver à ce genre de chose.
Qu'appelles tu un accident? Comment le défini tu? Comment l'OS ou un programme peut reconnaître un accident pour le loguer?
L'ip du responsable est normalement déjà logué s'il s'agit d'un accès distant classique via SSH par ex.

Désolé de pas aider plus mais en 6 ans d'entreprise j'ai jamais vu tout ça.
Tu as pas mal d'infos dans le fichier /var/log/secure

mais on peut supposer que si quelqu'un peut effacer les fichiers que tu dis, il peut aussi effacer les fichiers de log, donc la question est sans objet.
Le petit plus pour ça sera aussi d'envoyer les logs sur un serveur collecteur, pour éviter ce genre de problème.
Merci à vous,

en faite la personne qui a supprimé les répertoires, c'était moi (grosse bavure).

Voilà la vraie histoire :

je voulais supprimer le contenu d'un répértoire dans un site web en ssh, et j'étais en root.

Et au lieu de faire rm -rv ./* , j'ai fait rm -rv /* (sans le point derrière le slash),
du coup, j'ai supprimé tous les répertoires de l'OS par ordre alphabétique.
Et quand j'ai vu ça dans le verbose, j'ai toute suite appuyé sur Ctrl+C pour stopper la suppression.
Et la suppression s'est arrété au répertoire /opt.
Heureusement, que j'ai stoppé à temps et que la suppression n'est pas arrivé jusqu'au dossier /var où il y a les sites web et les bases mysql : ouf !
(mais bon, je fais quand meme des sauvegardes hebdomadaires).

Maintenant, je sais ce qu'il faut faire pour ne pas recommencer :
créer un compte non root, et administrer le serveur avec ce compte.
Et quand je supprime quelque chose, il faut toujours avoir le réflexe de mettre l'option -i.

Mais je voudrais savoir s'il y a une manipulation à faire ou une commande à taper en plus pour autoriser la connexion ssh pour le compte non root ?

Merci pour votre solidarité.
totoAussi wrote:Mais je voudrais savoir s'il y a une manipulation à faire ou une commande à taper en plus pour autoriser la connexion ssh pour le compte non root ?
En fait la question sur un serveur ssh serait plutôt l'inverse ! Par défaut il faut interdire l'accès à root en ssh !
Dans /etc/ssh/sshd_config mettre PermitRootLogin no.

Après il faut voir quelles opérations sont nécessaires mais par moment le compte root est obligé d'être utilisé.
Sinon un conseil, j'ai fait aussi une boulette similaire un jour : dans les backup ajouter le dossier /etc comme cela à la réinstallation la plupart des configurations sont déjà récupérées !
Je me doutais bien qu'une boulette avait été faite avec le compte root. Mais tu as bien appris la leçon je pense, ne rien faire (ou presque) avec le compte root. Bien faire gaffe surtout quand on supprime quelque chose. Ceci est moins grâve si tu fais des backups réguliers mais quand même. Perso par habitude je fais pas de rm -i je préfère deplacer, genre dans /tmp, et supprimer bien plus tard quand je serais bien sûr que ça sert plus. Une sorte de corbeille en shell 😉
Bonsoir,

merci pour vos réponses.
MarbolanGos wrote:En fait la question sur un serveur ssh serait plutôt l'inverse ! Par défaut il faut interdire l'accès à root en ssh !
Dans /etc/ssh/sshd_config mettre PermitRootLogin no.
=> ok, mais une fois connecté au ssh à partir des identifiants d'un compte non root,
est-ce qu'on peut se mettre ensuite en root avec su root ?
Par ailleurs, j'aurais bien voulu interdire l'accès au ssh pour le root, mais le problème est que le chef de p
rojet (qui ne connait rien en linux) ne veut pas que j'interdise le root au ssh,
c'est pour ça que je dois créer un compte non root, et je cherche à savoir s'il y a une manipulation à faire ou une commande en plus pour autoriser le compte non root au ssh ?
Madko wrote:Perso par habitude je fais pas de rm -i je préfère deplacer, genre dans /tmp, et supprimer bien plus tard quand je serais bien sûr que ça sert plus. Une sorte de corbeille en shell 😉
=> merci pour l'astuce, je prend exemple.

Cordialement
Pour savoir si on peut effectuer un su - lorsqu'on est connecté en ssh, tu aurais pu essayer, tu aurais constaté que oui!

Ensuite par défaut un compte non root est autorisé dans la mesure où il a un compte et le mot de passe correspondant.
J'ai rien compris à ton histoire, un utilisateur par défaut peu accèder à ssh si le service est activé. C'est le comportement normal. Le compte root est un compte utilisateur avec des droits particuliers, mais du coup lui aussi par défaut peut accèder à ssh.
Par contre comme on l'a suggéré, la bonne pratique veut qu'on interdise l'accès root en ssh. La bonne pratique veut aussi qu'on utilise rarement le compte root, soit en passant les commandes avec su -lc "commande" soit avec sudo.
Si quelqu'un d'autre que toi peux se connecter en root, directement par ssh ou via su/sudo, je ne vois pas pourquoi on peut te demander des comptes sur la sécurisation. C'est comme pour tout, si ya des passes droits tout s'écroule.
Te restera plus que les logs pour savoir ce qui s'est passé, mais trop tard. On dit toujours qu'il faut mieux prévenir que guerrir...
En tout cas pour la surveillance de la machine tu as regardé psacct et auditd?