Partitionnement serveur sécurisé

Pause Café
#1

Bonjour à tous!

Je sais que ce sujet a déjà été traité plusieurs fois et je me suis justement beaucoup renseigné avant de poster.
Le soucis c’est que je suis débutant en Linux et que les infos glanées ici et là ne me parlent parfois pas beaucoup.
Mon but est simple : je veux héberger mon site internet et disposer de mon propre serveur mail.
Je suis en train d’orienter mes études vers la sécurité informatique, ayant découvert une passion pour cela cette année. Donc je voulais commencer par le plus logique : un partitionnement sécurisé.
Désolé pour le pavé mais j’ai beaucoup planché sur ces notions et j’aimerais vraiment avoir les idées parfaitement claires!
C’est pour ça que j’ai numéroté les questions, pour que vous puissiez répondre à ce que vous savez/souhaitez.
Et j’aimerais aussi dire qu’il est inutile de me dire “te casse pas la tête”, je me la casse intentionnellement, je trouve que ma démarche est un bon point de départ pour comprendre le fonctionnement du fs Linux (surtout avec les questions que je vous pose) et je ne changerais pas d’avis :wink:

Ce que j’ai retenu, c’est qu’il y a 2 types de données sur un systeme. Les données statiques et les données dynamiques. La première catégorie désigne des données qui changent seulement par la volonté du super-utilisateur tandis que la seconde catégorie désigne des fichiers tels que les logs qui se modifient seuls.
(1) On recommande donc de placer les données statiques en lecture seule pour ennuyer un potentiel attaquant passé dans le systeme.
(2)On recommande aussi de séparer en plusieures partitions certains fichiers du système.

J’ai distingué : (3) / en ro sur support externe (je suppose que c’est pour emepecher tout acces au systeme quand l’ordinateur n’est pas utilisé par l’admin ??)
(4) une partition pour /var , pour /var/log , pour /homr , pour /var/tmp Car ce sont des dossiers qui sont modifiables par un utilisateur (je suppose que cette raison concerne un serveur avec plusieurs utilisateurs qui y accèdent à distance ??? ce qui ne sera pas le cas de mon servueur. On précise aussi que cela évite que ces utilisateurs fassent du dos en remplissant le disque puisqu’au pire ils rempliront seulement une partoche )
(5) /var/mail et /var/spool/mail (pour empecher un attaquant qui aurait réussi a entrer sur une des partitions d’en plus me piquer mes mails ??? a condition qu’il n’arrive pas à accéder à ces partitions évidemment)
(6) /usr et /usr/local (ou /opt) si j’ai bien compris, séparer cette partoche empeche l’attaquant d’utiliser des executables contre moi car ils n’auront effet que sur cette partiton donnée ???

(7) Certains conseillent également de binder-mounter /var/tmp avec /tmp. Si j’ai bien compris, c’est parce que /tmp s’efface au bout d’un court moment par défaut, alors que c’est plus long sur /var/tmp donc si on met ce dernier avec /tmp, il s’effacera aussi régulièrement que /tmp donc si un pirate y accède, avec un peu de chance il ne trouvera rien car déjà effacé c’est ça ???

J’ai voulu lire le man fstab et man mount pour trouver les options de montages les plus adéquates à chaque partition mais comme je suis débutant, je ne savais pas trop.
Mais j’ai trouvé ça : seulement je ne comprends pas toujours en quoi ces options sont adaptées, je le noterais à côté a chaque fois.

/var defaults, nodev, nosuid, noexec (8) je n’ai pas compris ce que fait le nodev (d’apres le man)
/usr defaults, nodev (9) pourqoi ici il n’a pas mis nosuid et noexec? parce que l’utilisateur a besoin d’executer des programmes et aussi parce qu’il a besoin parfois d’etre en root pour certaines choses donc grace a suid il peut le faire? C’est ça ???
/home defaults, nodev, nosuid (10) meme question pour le noexec manquant mais cette fois il y a nosuid pourquoi? Quelle différence avec /usr ?
/opt defaults, nodev, nosuid, noexec
tmpfs defaults, nodev, nosuid, noexec (11) que vient faire un type de fs ici ???
/tmp defaults, nodev, noexec, nosuid
floppy noauto, exec, utf8 (12) pourquoi il y a utf8 ???
cdrom noauto, exec, utf8
/media noauto, exec, utf8

Je me suis renseigné aussi sur LVM mais je ne comprends vraiment pas ce qu’il apporte de bien par rapport à des partoches physiques, (13) quelqu’un saurait m’expliquer??

Voilà j’ai fini !!

Merci à tous ceux qui prendront le temps de me lire/répondre et double merci aux courageux qui arriveront jusqu’ici !

Cordialement,

kingström

#2

Bonsoir tout seul.

Je crois qu’il faut surtout déjà que tu partes dans une logique inverse, en te posant la question “quelles parties du fs nécessitent d’être en écriture ?”, et que tu prépares une image de ton système que tu copies sur un support >physiquement< protègé en écriture (dvd bootable, pourquoi pas ?), sauf les parties nécessairement en rw que tu configures en dur dans ton fstab sur ton image.
Pour ces parties comme /var ou /usr/var (mais aussi p.e. /tmp), il faut penser que pour une bonne sécurisation, tu vas devoir mettre tous tes services dans des chroot ou des jail donc qu’il y aura autant de ces répertoires temporaires que de chroot, et je te déconseille de les mutualiser, pour que la compromission d’un des services ne donne pas accés aux répertoires de temp des autres services.
Tu peux d’ailleurs, à part pour /home qui se doit d’être persistant par nature ( et où je te conseille aussi de “jailer” tous les utilisateurs dans leurs répertoires propres) mettre en ramdisk de taille contrainte tous ces répertoires pour qu’ils ne laissent aucune trace d’écriture disque (même effacées) dés que tu rebootes ton appliance.
Pour les logs, ils ne devraient rien avoir à faire je pense sur une machine en sécurité maximale, et je chercherais un moyen de me passer même de système de log.
Et il faut penser à zapper tout ce qui n’est pas absolument nécessaire au bon fonctionnement de tes services, en sabrant même les commandes d’administration.
Personnellement, je chercherais des infos sur ce que tu cherches, si j’ai bien compris ce que tu veux faire, sur le site du projet emdebian.

Mais ça, c’est ce qui me vient à l’esprit comme ça sans aucune connaissance en sécurité, donc des spécialistes auront surement de meilleures suggestions à te faire.

Ah oui, et LVM, ça peut te permettre d’ajouter de la taille à ta partition /home en ajoutant juste de nouveaux supports que tu intègres comme extensions physiques de ta partition logique, mais avec un système ro, c’est p.e. un peu touchy, je ne connais pas assez LVM.

#3

Bonjour,

avec lvm2, tu peux aussi faire des snapshot pour faire des backup à chaud du système, mais bon, c’est plus utile pour des serveurs de prod qu’un serveur web sécurisé…

Tu peux aussi schrooter les services qui tournent sur la machine pour emprisonner l’attaquant en cas de crackage d’un service.

avec rsyslog, tu peux envoyer tes logs sur un serveur distant de cette façon, ils ne pourront pas être modifiés.

et pourquoi pas aussi un petit mod_security pout ton serveur web :slightly_smiling:

Quoi que, je suis un peu hors sujet là :slightly_smiling: désolé.

#4

[quote=“grigric”]Bonjour,

avec lvm2, tu peux aussi faire des snapshot pour faire des backup à chaud, mais bon, c’est plus utile pour des serveurs de prod qu’un serveur sécurisé…[/quote]
Non les snapshots ne sont pas des backups pour la simple raison que tout est stocké sur le même support.

#5

bah en fait, tu peux les rapatrier sur un autre serveur une fois l’image faite. Les outils commerciaux comme backupExec utilisent ce principe pour faire des backups à chaud il me semble. Par contre, ce n’est pas intégré dans notre brave backuppc malheureusement…

#6

quote="grigric"
avec rsyslog, tu peux envoyer tes logs sur un serveur distant de cette façon, ils ne pourront pas être modifiés.
(…)[/quote]Ils peuvent surtout être sniffés au passage.

#7

Bon je vais m’y mettre j’ai un peu de temps.

Utiliser un support en écriture seule me semble contraignant (si tu veut faire une mise à jour il faut regraver, tu as des latence plus importante et une mécanique moins fiable), il vaut mieux passer le système de fichier en lecture seule ou, si tu crains vraiment que le code du système de fichier sécurise mal cette partie, formater ta partition dans un système de fichier en lecture seul. Mais je suis d’accord qu’il faut que le maximum de données soit en lecture seule (idéalement toutes les partitions en rw doivent être en noexec). Personnellement je ne suis pas expert en sécurité mais il semble que se limiter à noexec ne soit pas suffisant pour empêcher un utilisateur d’executer du code, je préfère donc mettre le maximum de no* possible.

Pour ce qui est des services je pense que plus que de simplement les « chrooter », il faut les mettre dans des conteneurs LXC. Ça va permettre en plus de les chrooter de gérer leur occupation des ressources (en principe tu peut subir un DDOS sur ton serveur web en continuant d’accéder à la machine en SSH).

Pour les logs à minima il faut définir des quotas et bien sûr il faut mettre du logrotate. Avoir des logis me semble important pour pouvoir apprendre des attaques que tu subit.

Enfin les LSM, c’est extrêmement puissant, mais leur configuration prend beaucoup de temps. Il faut définir un grand nombre de droits qui peuvent être assez subtiles. Ce serait cool d’avoir une distrib’ avec un SELinux préconfiguré (je crois que Fedora (option dans anaconda) le fait mais je ne suis plus certain).

Enfin, une fois le système mis en place il me semble important d’en créer une image pour pouvoir restaurer rapidement la bête.

#8

Pour gérer un serveur MisterFreez à commencé une bonne base, mais à la limite si c’est pour de tels besoin pourquoi rester encore sur Linux :think:

#9

Wow, c’est moi ou je sens pointer un troll Linux/BSD à l’horizon ?

#10

Wahou ça fait plaisir d’avoir autant de réponses en si peu de temps. Merci à vous!!
Je vais répondre du plus récent au plus ancien.

@ MisterFreez et Clochette, oui j’ai entendu parler du fait que les systèmes BSD géraient mieux leur sécurité que Linux, ceci dit, je suis pas sur que ce soit pour les bonnes causes (les bonnes causes étant un système pensé pour la sécu dont tous les paquets sont surveillés attentivement etc…) Je me demande juste si c’est pas parce que c’est moins répandu et donc potentiellement mois ciblé par les pirates?
D’autre part, étant débutant, je pense que c’est mieux de maîtriser mon Linux avant de passer à bsd tout simplement parce que par exemple en ce moment je suis en stage où je fais du monitoring et j’utilise Linux et je suis amené à l’utiliser encore dans un futur proche (alors que BSD bof ^^)

@ MisterFreez L’idée était un formatage des dossiers du fs en ro oui, j’ai pas trop compris ton histoire de wo regravage etc. Désolé ^^
J’avais lu un truc sur chroot dans le contexte cité, je vais me pencher dessus merci =)
Et les conteneurs LXC non plus je connaissais pas. Je vais checker ça :slightly_smiling:
Le logrotate oui j’y avais pensé et je le ferais tout bien et je suis d’accord avec toi que c’est mieux d’en avoir un minimum sinon boujour la galère pour s’informer.
Les LSM c’est le principe de SELinux non ? J’avais lu un truc là-dessus également, va falloir que je m’y penche sérieusement aussi ^^

@Mattotop : oui je suis d’accord avec toi, hors de question que je fasse transiter mes logs sur internet.
En revanche si ma partoche de log est sur un disque dur externe, ça peut peut-être résoudre le problème?
D’ailleurs sur ce point j’aimerais comprendre : un mec qui met certains éléments de la hiérarchie de son fs dans une partition dédiée sur support externe (admettons /var/log) . Il est obligé de la brancher à son PC/Serveur quand il l’utilise non ? Vu que sinon les services vont pas trouver où ils doivent logguer leurs infos. Donc en faite ca crée de la sécurité parce que le support est physique et séparé du disque dur mais ce n’est pas safe du tout pour autant je suppose. Bref quel intérêt ?

@ Grigric Mod_security ? Je vais checker :slightly_smiling: Et sache que si tu me parles de sécurité t’es pas hors-sujet pour moi, tant que tu m’apprends quelque chose, je prends! :smiley:

@ Mattotop Je vais regarder pour les jail aussi, je suppose que c’est le même principe que SELinux.
Faut que je me renseigne sur la ramdisk parce que même si je suis pas con et que je devine ce que c’est et à quoi ça sert, j’avais rarement entendu parler ^^
Je vais tâter emdebian aussi.

Merci à vous pour tout vos conseils.
J’invite ceux qui peuvent me répondre à regarder quand même les questions numérotées de mon premier post pour lesquelles je souhaiterais avoir une réponse qui n’a pas été donnée jusqu’ici, soit les questions (ou parfois juste ddes remarques numérotées pour qu’un expert donne un petit détail dessus comme les questions 1 et 2 par exemple) 3 à 7 et 9 pour lesquelles j’aimerais savoir si j’ai bien supposé et les questions 8, 10, 11, 12.

Merci d’avance pour les futures réponses!

#11

Wow, c’est moi ou je sens pointer un troll Linux/BSD à l’horizon ?[/quote]

Loin de moi l’idée de lancer un troll, mais une “jail” n’est pas un “chroot”, et la sécurisation d’une BSD précise est déjà bien conçue :083

Pour le restant je précisé simplement que la base à été bien développé, mais le partitionnement sécurisé c’est … enfin bref … :whistle:

Le plus important c’est de savoir sécurisé son système, le partitionnement n’est qu’une chose de plus dans la sécurisation d’une machine car si le mots de passe ftp c’est “toto” ( rigolez pas j’en ai vue :005 ).

#12

[quote=“k1ngstr”]
J’invite ceux qui peuvent me répondre à regarder quand même les questions numérotées de mon premier post pour lesquelles je souhaiterais avoir une réponse qui n’a pas été donnée jusqu’ici, soit les questions (ou parfois juste ddes remarques numérotées pour qu’un expert donne un petit détail dessus comme les questions 1 et 2 par exemple) 3 à 7 et 9 pour lesquelles j’aimerais savoir si j’ai bien supposé et les questions 8, 10, 11, 12.

Merci d’avance pour les futures réponses![/quote]

Abonnement…Je trouve ton sujet très instructif, mais reconnais qu’une question par post, t’y vas un peu fort tout de même! :005

#13

Pour FreeBSD et NetBSD je ne sais pas. Pour OpenBSD, non. OpenBSD met au cœur de de sa priorité la sécurité. Ils vont très loin. Par exemple Xorg sur openbsd n’est pas lancé en tant que root, ils n’utilisent plus malloc car ils trouve cette méthode dangereuse et préfèrent en utiliser une à eux plus sécurisé. D’autre part ils sont très rigoureux sur la liberté.

SElinux est un des Modules de Sécurité Linux. Il en existe 3 autres.

Nan. Les jails comme les conteneurs (type OpenVZ) sont là pour créer un environnement cloisonné pour un ou plusieurs programmes. Les jails sont réputés plus sûr que le chroot (qui est l’« équivalent » linux), mais je ne sais pas ce qu’il en ai avec LXC (chroot + cgroup). SELinux est là pour rendre plus fins l’attribution des droits à chaque programme/utilisateur.

#14

@Tetrix Oui tu as raison hihi. Je suis assez tête en l’air alors je préfère fonctionner comme ça. De cette façon je n’oublie rien. Mais j’ai quand même du respect pour les gens qui répondent, c’est pour ça que j’ai numéroté ^^
En tout cas, content que ça te plaise :slightly_smiling:

@ MisterFreez, merci beaucoup pour ces éclaircissements, c’est très intéressant!!

#15

[quote=“MisterFreez”]

Nan. Les jails comme les conteneurs (type OpenVZ) sont là pour créer un environnement cloisonné pour un ou plusieurs programmes. Les jails sont réputés plus sûr que le chroot (qui est l’« équivalent » linux), mais je ne sais pas ce qu’il en ai avec LXC (chroot + cgroup). SELinux est là pour rendre plus fins l’attribution des droits à chaque programme/utilisateur.[/quote]

Plus sûr :whistle: pas forcement lorsque le “chroot” est bien réalisé il n’y a pas vraiment de différence de sécurité; c’est avant tout plus simple te léger à mettre ne place correctement.

Mais je le répète la sécurité passe avant tout sur le système, le partitionnement n’est qu’une partie minime de la sécurité.

#16

@ clochette Je n’ai vu personne te contredire en ce qui concerne le fait que c’est une partie infime.
Mais tu as l’air d’omettre que réaliser ce partitionnement a pour but premier de m’apprendre le fonctionnement de Linux.

Bien sur tu me diras il y a d’autres moyens pour ça. Mais moi je veux apprendre par ce biais puisqu’il m’intéresse énormément ^^

#17

[quote=“k1ngstr”]@ clochette Je n’ai vu personne te contredire en ce qui concerne le fait que c’est une partie infime.
Mais tu as l’air d’omettre que réaliser ce partitionnement a pour but premier de m’apprendre le fonctionnement de Linux.

Bien sur tu me diras il y a d’autres moyens pour ça. Mais moi je veux apprendre par ce biais puisqu’il m’intéresse énormément ^^[/quote]

Je n’omets rien du tout je te propose avant tout de mettre les mains dans le soft avant de peaufiner ce qui à mes yeux viendra naturellement après que tu es maîtrisé tes applications et leurs fonctionnements.

Je ne suis pas un spécialiste de la sécurité me confrontant presque tous les jours à des machines trouées :whistle:
De plus j’ai travaillé sur deux projets orienté sécurité et anonymat et à chaque fois la base du travail à été avant tout l’applicatif.

Après tu pense ce que tu veux mais si personne ne te dit exactement quoi mettre en lecture seule, quoi protéger via un “chroot” ( et comment le mettre ne place correctement ), etc …

Le plus simple est dans un premier temps d’apprendre la base :

[ul]Mettre en place ta machine
Configurer et sécurisé le système de base
configurer et sécurisé les différents applicatifs
optimisés leur fonctionnement sans défavorisé la sécurité
… et finalement s’attaquer au support de tout ça afin de finaliser ta futur machine de production[/ul]

Je reste vague car je n’ai absolument aucune idée du niveau de sécurité et le type d’applicatif que tu compte mettre ne place ( c’est pour ça que je parler aussi de OpenBSD ) :033

D’ailleurs MisterFreez à ton travail vous utilisez quoi pour les audit des machines ( OpenVAS, OSSEC, Autres ) ?

#18

Je comprends et respecte ton raisonnement.

Seulement, je voulais commencer par le partitionnement puisque c’est le commencement ^^