Jump to content

Archived

This topic is now archived and is closed to further replies.

-rem-

Securite Systeme et Réseau

Recommended Posts

Rem : Je n'ai aucun problèmes. :craint: Mais merci pour l'info. Il se peut que ça me serve rapidement.

Ah ! Intéressant WebDAV donc. Et est-ce que l'utilisateur peut se retrouver loggué avec son compte plutôt que celui d'apache ?
Je ne me suis pas posé la question, mais vu que ça passe par apache, je ne pense pas. Je ne vois pas apache s'autentifier autrement.
Oui, alors ça je suis contre. Si on a fait des ports dans le protocole TCP, c'est pas pour les chiens.
Oui, mais le problème, c'est que webdav est une extention, du protocole HTTP1.1.
Avec WebDAV et XML-RPC qui se multiplient, le port 80 va devenir une vraie poubelle, et le firewall servira plus à rien. On peut pas filtrer sur les ports si tout passe par le même.
C'est déjà beaucoup le cas je trouve. Beaucoup de choses passent par le port 80. Bientôt le filtrage de contenu ?
Comment ça se fait que je ne sois pas surpris... :incline:
Pour être tout à fait honête, ça ne merdouille qu'avec certaines versions et je crois que c'est corrigé. Mais bon, le nombre de mails qu'on a reçut. Pourquoi ça ne fonctionne pas ? Blablabla. La feinte du renard, c'est de s'autentifier normalement => accès refusé, on se réautentifie et on clique sur annuler, et on est connecté :reflechi:

Crois moi, j'ai encore de quoi ne pas t'étonner. :transpi:

Share this post


Link to post
Share on other sites

ben il suffit de modifier quelques droits sur les fichiers, pour que tu ne puisse pas les lire, quelque soit ton shell.

Share this post


Link to post
Share on other sites
ben il suffit de modifier quelques droits sur les fichiers, pour que tu ne puisse pas les lire, quelque soit ton shell.

Oui, mais /etc/passwd, je pense qu'il doit être en lecture pour tout le monde :)

Pour ce qui est de WebDAV, c'est dans la FAQ de mod_dav, c'est pas possible d'avoir des droits différents du process apache, donc dommage, c'est pas encore ça le top...

Share this post


Link to post
Share on other sites

Je vais vous parler d'une version de Linux destinée à la sécurité : SELinux.

Je ne vais pas expliquer comment l'installer, pour celà je vous renvoie au site de gentoo (par exemple) :

http://www.gentoo.org/proj/en/hardened/sel...86-handbook.xml

Par contre, je vais vous expliquer un peu ce que SELinux propose, pourquoi et comment. Je ne pourrais bien sûr pas tout dévoiler ici, d'autant plus que je ne connais pas tout, mais je vais essayer de donner un bon aperçu pour ceux qui se demandent ce qu'apporte SELinux et pourquoi.

Ce que SELinux Rajoute

SELinux définit un certain nombre de nouveaux attributs :

Les types sont des attributs de sécurités qui concernent les fichiers, les ports, les peripheriques ... Le type d'un process est appelé son domaine. Les politiques de sécurité de SELinux permettent de renforcer les regles décrivant les interactions entre les objets ou entre les domaines selon leur type. Un type est suffixé par "_t" comme par exemple sysadm_t. C'est l'attribut le plus important.

Les roles concernent les utilisateurs. Ils permettent d'en limiter les actions possibles, mais ils ne sont pas fixes. Pour administrer le système, le role sera "sysadm_r", alors qu'une utilisation normale se fera avec le role "staff_r". Si un role n'a pas le droit d'accéder à un certain domaine, l'action qu'il tentera sera rejetée. L'utilisateur peut cependant être changé temporairement de role pour effectuer une action. Un role est suffixé par "_r".

Les identités ressemblent fortement aux noms d'utilisateurs sous Linux, mais ils ne sont pas censés changer. L'interet est de s'affranchir de la dangereuse fonction setUID. L'utilisateur ne peut pas changer d'identité, mais seulement de role. Chaque identité à une certaine liste de roles qui lui sont accessibles.

Un context est l'alliance des trois attributs précédent, par exemple "system_u:object_r:bin_t". Si l'on fait un ls -l, on obtient :

drwxr-xr-x  root     root     system_u:object_r:bin_t          bin
drwxr-xr-x  root     root     system_u:object_r:boot_t         boot
drwxr-xr-x  root     root     system_u:object_r:device_t       dev

On voit qu'il y a toujours les permissions habituelles, mais aussi le contexte du repertoire. Il en est de même pour un ps.

Les politiques généralement définies dans les fichiers situés dans /etc/security/selinux/src/policy contiennent toutes les définitions concernant la sécurité, en particulier les attributs présentés au dessus. Il existe un certain nombre de macros permettant de créer simplement ces politiques.

A quoi ca sert ?

Toutes ces modifications s'accompagnent d'un grand nombre de patchs modifiant le noyau pour améliorer la sécurité. On note tout d'abord qu'il n'est plus nécessaire d'avoir un utilisateur root possédant les pleins pouvoirs. Le but est qu'à tout instant, chaque utilisateur et chaque processus n'aie pas plus de droits qu'il n'en a besoin. Cela permet de faire tourner en toute sécurité des programmes auxquels on ne fait pas totalement confiance (aussi bien au niveau de la stabilité que de la sécurité).

La sécurité du systeme ne dépend plus que sur la fiabilité du code du noyau (et des patchs), et de la configuration des politiques de sécurité, alors que sous une version classique de Linux, la sécurité dépend aussi des processus privilégiés.

Et si je veux en savoir plus ?

Je conseille la documentation de la version Gentoo SELinux :

http://www.gentoo.org/proj/en/hardened/sel...86-handbook.xml

Mais aussi le site de SELinux :

http://www.nsa.gov/selinux/

Share this post


Link to post
Share on other sites

Je m'occupe de ce topic tres prochainement. Je reprends ce tutoriel certainement pednant les vacances, mais je veux aussi pouvoir prendre le temps de revoir certaines manip assez pointues histoire de faire un truc complet, qu" on ne dise pas apres que rem fait des tutos creux...

Share this post


Link to post
Share on other sites

Je ne crois pas que quelqu'un aie pu dire ça :francais:

Le topic sur les fstab est vraiment bien aussi, mais il y a pas mal de fautes. Là je suis un peut fatigué, je corrigerais un autre jour.

Lors d'une install de serveur, on a utilisé un tuto vraiment très bien fait, très complet, fait par un français en plus : http://entreelibre.com/scastro/debian-secinst/

Je pense que ça mérite d'être donné en lien quelque part.

Share this post


Link to post
Share on other sites

Fautes orthographe, oui je sais j'y suis allé assez vite sans me relire. Je devais faire ca cette aprem, mais je suis aller au resto puis on a pris un café, rentré 19h donc c'était tres juste.

Des fautes techniques ?

Share this post


Link to post
Share on other sites

Heu non orthographe grammaire uniquement.

Par contre il aurait peut être des trucs à rajouter. Mais je te ferais un post bien propre dans le bon topic avec tout ça quand tu auras fait tes corrections, comme ça j'arrète mon HS ici.

Share this post


Link to post
Share on other sites

salut tt le monde !

je viens de lire un peu les précautions pour la sécurité en local .... mais je comprend pas prquoi sudo est pref par rapport a su ? parce que on est oblige de taper le mot de passe root en su c'est ca ?

Share this post


Link to post
Share on other sites

Parce qu'avec su on se logge en super-user (admin?) jusqu'à ce qu'on pense à se déconnecter alors qu'avec sudo on "emprunte" les droits super-user uniquement le temps de la commande ---> pas de risque de continuer avec des droits inapropriés (et dangereux)

Ps: Sauf si je me trompes...

Share this post


Link to post
Share on other sites

Sauf si tu fait "sudo su -" comme beaucoup de monde.

L'avantage aussi de sudo la_commande, c'est que les logs ne sont pas chez le root, mais chez l'utilisateur de la commande (le bash history), c'est plus facile pour savoir qui à fait quoi.

Parce que quand on doit appeller tout le monde pour savoir qui a fait une commande, pourquoi comment, c'est la galère (expérience désastreuse inside).

Pour ne pas oublier de déconnecter le root, tu peux mettre un TMOUT=XXsecondes dans le bashrc ou le bash_profile du root.

EDIT : par ailleurs, on peut coupler ça à un "export HISTFILE=/dev/null" pour le root, ce qui permet en cas d'attaque d'éviter que l'on sache les dernière opérations faites par le root.

Share this post


Link to post
Share on other sites

pis on peut bourrinement modifier le .bashrc de chaque user (à mettre dans le /etc/skel, donc) pour logger toutes les commandes tapées par tous les users.

On avait fait ça y'a presque 10 ans dans notre salle Linux. J'ai plus la commande ne tête mais je peux retrouver ça... en tout cas ça nous a pas mal dépatouill". évidemment il faut que le .bashrc soit en 644 owné par root

Share this post


Link to post
Share on other sites
évidemment il faut que le .bashrc soit en 644 owné par root

Si il est dans le répertoire perso du user, qu'est-ce qui l'empêche de faire un rm ~/.bashrc et d'en refaire un autre ? Son répertoire est pas chmod +t à ce que je sache, non ?

Share this post


Link to post
Share on other sites

petite question : chmod est accéssible au simple user ....un simple utilisateur peut alors modifier lui même les droits sur des fichiers ? ( c'est pas possible ca quand même ?!)

Share this post


Link to post
Share on other sites
petite question : chmod est accéssible au simple user ....un simple utilisateur peut alors modifier lui même les droits sur des fichiers ? ( c'est pas possible ca quand même ?!)

Bien sûr qu'il a le droit, c'est ses fichiers après tout, il en fait ce qu'il veut ! Mais il peut pas changer les droits si les fichiers ne lui appartiennent pas.

Share this post


Link to post
Share on other sites

merci pour la précision gauret !!!!!

comme ca je ferais plus gaffe au groupe et au utilisateur .......

merci man !!!!

Share this post


Link to post
Share on other sites

il a même le droit de faire

chmod -R 000 ~/* 

puis d'appeler root au secours (il faut toujours avoir un root de secours) parcequ'il peut plus rien faire ...

Share this post


Link to post
Share on other sites

Ben on a encore les droits dessus. :craint:

theo@fermat:~/tests$ touch fichier
theo@fermat:~/tests$ chmod 000 fichier
theo@fermat:~/tests$ rm fichier
rm: détruire un fichier protégé en écriture fichier régulier vide `fichier'? y
theo@fermat:~/tests$ ls -l fichier
ls: fichier: Aucun fichier ou répertoire de ce type

theo@fermat:~/tests$ echo "test" > fichier
theo@fermat:~/tests$ chmod 000 fichier
theo@fermat:~/tests$ cat fichier
cat: fichier: Permission non accordée
theo@fermat:~/tests$ chmod 700 fichier
theo@fermat:~/tests$ cat fichier
test

Share this post


Link to post
Share on other sites

je relance le topic j'aimerais en particulier quelque chose sur le firewall intégré de mdk 10.1

(je crois pas en avoir besoin d'un autre vu que j'ai déjà un routeur firewall matériel)

Share this post


Link to post
Share on other sites

Lorsque j'aurais le temps je le reprendrai, mais ca fait longtemps que je ne trouve plus le temps de le faire, et en plein demenagement actuellement, ce n'est pas pour tout de suite ( pas mars, ou vers fin mars ). Concernant le firewall Mandrake, pour ma part il en est hors de question car je n'utilise ni mandrake ni son firewall, le noyau linux en proposant un absolument parfait.

Share this post


Link to post
Share on other sites

l'interface de firewall de mandrake n'est de toute façon qu'un frontend à iptables...

Share this post


Link to post
Share on other sites

Sur le firewall de Mandrake, il n'y a rien à dire. Pour peu que l'on sache lire...

Autant faire un sujet sur iptables.

neo

Share this post


Link to post
Share on other sites

×
×
  • Create New...