Salut, je suis nouveau sur ce forum. Voila, je serai en derniere annee de ma licence dans quelques mois et je dois deja avoir un sujet de memoire sous la main, une idee me vient en tete: Arriver a modifier les descriptions ou actions des certaines commandes de base pour qu'en cas d'intrusion par un pirate, hacker, bref, une personne mal intentionnee, qu'elle n'arrive pas a avoir les bonnes actions, exemple lorsqu'il arrive tant bien que mal a penetrer le reseau, lorsqu'il tape "ls" elle a un autre resultat genre le message d'erreur qu'on obtient lorsque l'on tape une commande sans parametre, bref que la personne ait une autre action que celle attendue normalement; mais mis a part ca, j'aimerai rendre cette modification QUE pour le point de vue externe c'est-a-dire pour les gens ne faisant pas parti du reseau ET que les descrpitions ou actions normales des commandes modifiees soient et restent intactes pour ceux de l'interieur du reseau.

Je cherche a savoir si cela est faisable et si ca peut faire objet d'un sujet de memoire? ET si quelqu'un peut me mettre sur la voie afin de me guider pour ne pas que je ne fasse pas autre chose!

P.S. Devrai-je telecharger et modifier le noyau Linux afin de le recompiler ou je dois juste taper du code(scripts) dans mon shell afin d'arriver a faire ce qui me semble le plus difficile(modification des commandes)???

Ce sont la, les questions que je me pose, n'hesitez pas a poser des questions si je n'ai pas ete assez clair ou carrement m'ecrire a mon mail pour les volontaires qui veulent m'aider de pres:xxxxxxxxxxx

Je suis ouvert aussi a d'autres suggestions dans la meme file d'idee.

Merci!

Je ne comprends pas la finalité. On dirait que tu fais de l'expérimental mais en même temps tu y ajoute des users standard donc tu vas faire ça sur une machine en production ? Quel est l'objectif ? Si tu veux renforcer ton système il faut peaufiner le système d'authentification et d'autorisation. Un user indésirable ne doit même pas pouvoir faire un login.

+1.
J'ai du mal à voir l'intérêt de la chose et cela me parait relativement limité. Si tu as un parc homogène d'équipement, éventuellement mais ce n'est vraiment pas là ni de cette manière que je mettrais mon énergie à sécuriser une infra.
 
Avant de songer à jouer avec l'attaquant, il faut déjà identifier les attaques et les équipements compromis.
 
Sinon, regarde du côté des honeypot. Tu laisses ou tu diriges des attaques vers des endroits contrôlés afin d'étudier le comportement de l'attaquant ou de lui faire perdre du temps.

Sinon pour ce genre de truc, c'est simplement une modification du .bashrc de l'utilisateur courant, avec la définition d'alias  
Mais comme les autres, je doute sérieusement de l'utilité pratique de la chose...
 
Il serait aussi bon que tu n'indiques pas qu'un "hacker" c'est un pirate informatique. Parles plutôt en terme de "black hat" si tu veux parler de pirates informatiques... sinon si ton mémoire est lu par un dév un tantinet barbu (=hacker), il va te coller un zéro pointé.

Je vais donner mon avis sur la question, puisque c'est du sys principalement.
De base, sur un linux vanilla, non patché, hors distro, tout est fermé, même les sockets internes. Ensuite les deux premières choses a comprendre, sur linux et sa sécurité, c'est d'un coté l'arborescence des répertoires, et de l'autre la gestion des utilisateurs.
De base, chaque utilisateur possède son socket sur la machine, et n'a accès a qu'a sa partie congrue (/home/nomd'utilisateur), tout se qu'il lance est dans sa partie congrue et n'en sort pas, c'est se qu'on appel un jail. Ensuite, encore une fois de base, si un utilisateur a besoin de droits, il faut lui créer un jail plus étoffé, donc de base, la sécurité élémentaire d'un linux vanilla, c'est le chroot + jail applicatif.
Maintenant, sortit de ce principe de base, toutes les distro incluent des systèmes et patchs kernel pour avoir une gestion en bus + socket. Et via les busses, on peu avoir se qu'on appel des "privilège escalation" en gros, c'est la première source de piratage sous linux. En gros, le hacker va chercher un bus qui est commun a root et a utilisateur. Pour palier a ce genre de comportement tu as plusieurs choix : patch kernel a nouveau (grsec et selinux) qui va contrôler les busses et via une interface elle aussi bussé, via root/kernel va avec une access control list, une sorte de liste blanche de se que l'utilisateur va pouvoir faire, ou pas niveau applicatif. C'est un mécanisme primaire d'isolation.
Après on rentre dans les domaines particuliers, même si largement utilisés et on rentre dans la configuration fine. Mais la première règle de sécurité sur un linux, c'est 1 appli = 1 user dans un jail. Et ce, y compris en local. Et déjà rien que là, tu va éviter beaucoup de problèmes. (en gros, les seules failles restantes sont des PE kernel et tu peu pas y faire grand chose si un 0day sort, même un patchage grsec ou selinux n'y feront rien).
Tout ça, c'est de la sécurité "violente", après tu peu avoir plus "soft" via udev/*kit + kernel grsec ou selinux + tout un tas de trucs louches.
 
En aucuns cas, ton shell va avoir la main sur ton kernel et les "commandes" du shell sont indépendante du kernel. Puisque même "ls" est un binaire qu'exécute le kernel via un interpréteur du shell et est contenu dans /bin. Le comportement le plus proche de se que tu décrit serait un chroot sans /bin et où ses programmes seraient lancés via appel bus externes du propriétaire du chroot (et on en revient au fait que les PE viennent du kernel dans ce cas, ou de l'isolation du bus mal foutue suivant comment est codé le programme de base sur ce point).
 
On pourrait digresser pendant longtemps sur tout les cas de figure mais ça n'amènerait a rien de probant pour toi. Et si t'as pas un socle de connaissance de base (qui visiblement tu n'a pas vue ta question) ça sert a rien d'en débattre.

http://linuxfr.org/forums/linux-no [...] n-intranet
 

Merci les gars pour vos reponses.  
J'avoue que c'est aussi vague comme sujet de memoire.
 
Quelqu'un aurait une idee autre a me proposer pour mon memoire(sous Linux bien sur).  
 
Merci de pour vos suggestions...

Ce qui est très en vogue c'est tout ce qui est cluster, filesystem cluserisé toussa. Si tu vas par là t'aura du succès.

pour l'idée du FS clusturisé et des clusters de stockage en tout genre, dans la "mouvance commerciale" du cloud.