# [Sécurité serveur] Conseils de base?

## FTG

Bonjour à tous,

je suis, avec un pote, en train de monter sur une vieille tour un serveur web (apache2), mail (postfix), ftp (proftp), jabber (ejabberd) et ssh pour controler le tout a distance. Le tout autour d'un nom de domaine + alias sur DynDns puisque l'ip que fourni le FAI a notre routeur (speedtouch home --> pro) est dynamique.

Le but étant bien sur de le rendre dispo à un certain nombre de personne (voire peut etre bcp pour jabber).

Je me posais la question de l'arsenal de sécurité à déployer pour ne pas se le faire hacker.

Nous avons commencer à rédiger des regles iptables assez serrées. Que peut on faire de plus?

Quels sont les risques les plus courants sur ce type de serveur vu que pas mal de port vont etre "ouverts" pour permettre les connexions?

Merci pour les réponses

----------

## kwenspc

Le noyau hardened-sources est pas mal. Touches pas aux réglages de GRSec et PAx à moins que tu saches ce que tu fais, mais déjà de base il est très bien.

Ensuite si t'as plusieurs comptes utilisateurs la moindre des choses c'est de régler les droits afin que seul l'utilisateur ait accès à son home dir. Pas mal de petites choses comme ça. 

Après tu peux toujours voir les docs section "projet hardened": http://www.gentoo.org/doc/fr/list.xml (je trouve ça un peu trop parano, crypter les compiles en ram etc... bof)

Il y aussi la doc hardened debian qui est pas mal.

 sinon on dit pas "hacker" c'est un abus de langage, mais "hijack" ou quelque chose comme ça. Fin en français ceci dit c'est "pirater"... ouais je sais on s'en fout. 

----------

## lesourbe

les conseils de base :

se passer de tout ce qui est inutile

chrooter quand c est possible

executer en non-root les services sensibles

mettre à jour

surveiller

ssh : pas de root access

mot de passe costauds

port knocking ?

la sécurité c'est d'abord de bonnes pratiques.

----------

## mornik

Ne pas oublier non plus des outils de surveillance comme logwatch, ou tripwire.

----------

## Link31

 *lesourbe wrote:*   

> ssh : pas de root access
> 
> mot de passe costauds
> 
> port knocking ?

 

Je dirais même :

- changer le port de SSH et le mettre parmi les valeurs improbables type 51674 (et mettre le port en sleath/DROP la plupart du temps, pour ne l'ouvrir qu'après un port-knocking)

- peu importe les mots de passe, puisque tu devrais te connecter par clé privée/publique (avec passphrase)

Pour tout ce qui est ouvert : pas de miracle, il faut que les daemons tournent avec le moins de privilèges possibles et éventuellement dans un chroot. Ou mieux, chacun dans une VM ou un vserveur, c'est plus lourd à mettre en place mais c'est incontestablement beaucoup plus solide.

Si tu prévois d'avoir des comptes utilisateurs, alors il va falloir être extrêmement prudent et surveiller autant que possible tout ce qui se passe : il n'y a rien de plus dangereux que des comptes SSH, malgré toutes les mesures de sécurité que tu peux imaginer (sauf à les mettre chacun dans son vserveur, enfin bon...).

En plus, c'est d'autant plus sensible que tu héberges toi-même le serveur, ce qui veut dire que s'il se fait rooter tu vas te retrouver avec un pirate dans ton propre réseau personnel. Et il finira rapidement par rentrer dans tes données sur d'autres machines, même celles qui n'ont rien à voir avec ton serveur (photos de vacances, données bancaires...).

Je sais, j'exagère volontairement, mais en sécurité il vaut mieux envisager le pire dès le début plutôt que de s'en apercevoir trop tard.

----------

## kwenspc

 *lesourbe wrote:*   

> 
> 
> chrooter quand c est possible
> 
> 

 

chroot n'a rien d'un outil de sécurité, ça tiens de la bidouille dans ce cas là, en fait c'est carrément déconseillé par le devs linux (il y avait un article à ce sujet, mi-2007, ça avait pas mal discuté à ce sujet). En fait c'est bien simple: entre gagner les droits root dans un chroot et dans l'env natif: aucune différence = le système est bon à mettre en quarantaine, être analysé et écrasé. Ça corse juste un ptit peu les manips pour arriver à l'env natif c'est tout.

Mais c'est vrai qu'on a pas de jail sous linux et c'est bien dommage  :Confused: 

Ah bah tiens: http://kerneltrap.org/Linux/Abusing_chroot

----------

## geekounet

 *kwenspc wrote:*   

>  *lesourbe wrote:*   
> 
> chrooter quand c est possible
> 
>  
> ...

 

+1

Enfin sous Linux ya les vserver qui peuvent se rapprocher des jails, mais ça les vaut pas encore parait-il.  :Razz: 

----------

## lesourbe

 *kwenspc wrote:*   

> Ça corse juste un ptit peu les manips pour arriver à l'env natif c'est tout.
> 
> 

 

y a pas de solution ultime, avoir un anti-virus ne garantit pas de ne pas avoir de virus.

à moins que chrooter favorise activement le piratage (et c'est ptet le cas, mais j'en doute), ça reste une mesure de sécurité au même titre que changer le port de ssh.

----------

## kwenspc

 *lesourbe wrote:*   

> ça reste une mesure de sécurité au même titre que changer le port de ssh.

 

Nan c'est pas exactement une mesure de sécurité. 

C'est un sujet qui fait pas mal couler d'encre (virtuelle). Ce genre de manip, ainsi que le port-knocking d'ailleurs, de même que changer le port ssh, c'est une mesure d'obfuscation. En aucun cas ça ne garantit une sécurité quelconque. Mais oui en effet l'obfuscation permet une "certaine" sécurité qui n'en est pas (pour le port ssh par exemple, ça fait juste foirer les scripts kiddies, mais comme c'est 90% au moins des attaques sur ssh on a l'impression que c'est une mesure de sécurité alors que c'est juste l'attaquant qui est moisi.)

Pour moi la sécurité c'est tout ce qui touche à l'authentification et les accès: la garantie qu'un tel est bien qui il est, et que ces droits ne peuvent en aucun cas être usurpé ni être étendue/amoindrie par aucune mesure non-prévue par le système. Et dans ce cas précis le port-knocking, changer le port ssh et le chroot ne sont pas des mesures de sécurité. Dans les transmissions de données, et donc parfois de données d'authentification, il est souvent nécessaire de faire appel à l'obfuscation pour garantir l'integrité des données transmises. Dans ce cas là précis la sécurité a besoin de mesure obfuscation (sinon tu sniffes, t'as tout en clair et zou tu prend la main et mets la sécurité en péril). 

Bon je sais pas si je suis très clair  :Laughing:  . Il y a de bien meilleur articles à ce sujet sur le net.

----------

## lesourbe

ben j'suis d'accord et c'est ce que je dis, je considère évidemment pas que changer de port ssh est une mesure de sécurité.

----------

## razer

J'ajouterais juste le programme fail2ban, qui bloque les ports de services (ssh, ftp...) pour les IPs ayant provoqué des échecs d'authentification

----------

## Jacqueline

Bonjour

  J'etais tres decue de decouvrir  recemment  dans une doc de BSD sur les jails, que chroot n'etait pas la panacee et etait contournable.

 alors que j'avais trouve un super tuto ( un peu ancien, mais les principes restent valables , je pense  ) que je gardais sous le coude.

http://www.cgisecurity.com/lib/ryan_barnett_gcux_practical.html

Kwenspc  nous le confirme.

Je suis allee voir le lien..qu il a donne, mais je reste  sur une impression mitigee.. ( ya des pour et ya des contre , en plus je n'ai pas tout capte ..)

Alors si chroot n'est pas une secuirite  : on l'oublie ou on le met quand meme. ?

 Enfin je me demande si mon tuto  est encore valable, car il apporte  pas mal de mesures  complementaires.

 j'avais essaye de le suivre sur une OpenSuse, mais helas a chaque etape il y avait un probleme , un conflit avec la conf  faite par Suse.. j'attendais donc l'install de la Gentoo , pour  mettre en oeuvre ce tuto :

 le user que l'on verrouille, les quotas de zero,  le chroot etc..

 Meme probleme  pour les serveurs FTP avec chroot ?

 Ou est ce que l'alternative au chroot, c'est un truc comme la virtualisation ?

C'est tout de meme un peu demoralisant d'installer un truc dont on sait qu il n' apporte pas la securite escomptee..

----------

## kwenspc

 *Jacqueline wrote:*   

> 
> 
> C'est tout de meme un peu demoralisant d'installer un truc dont on sait qu il n' apporte pas la securite escomptee..

 

Salut Jacqueline!

Passer par une virtualisation complète n'y changera rien à moins qu'aucune données critique n'y soit stockées (il n'y aurait que les services qui tournent et qui accède à un réseau réstreint pour lire/écrire les données: bdd etc...). À la rigueur si une vm se fait corrompre, tu la tue, t'as un backup en attente, tu relances et hop: ton service et de nouveau en route. Le pb: c'est que ça ne résout pas l'origine du problème  :Laughing: . Ce qui a permit de corrompre la 1ère vm pourra être utilisé encore une fois sur la seconde. Il faut donc comprendre ce qui c'est passé, trouver la faille et fixer celle ci dans la vm de remplacement. Si tu veux la virtualisation t'évites seulement d'avoir à installer/désinstaller/manipuler une install en dure: ce de sont que des fichiers images que tu peux créer/détruire à la volée. Pour autant le travaile de "sécurité/veille" et tout aussi éprouvant avec ou sans la virtualisation.

Sinon oui une bonne administration du système est une bonne pratique pour accéder à une relativement bonne sécurité: 

- user verouillé: droits finement distribués, password bourrins, accès par ssh à clé + authentification 

- quotas

- droits d'execution (sur certains reps accessibles comm /tmp: le mieux et d'avoir une partoche à part pour lui et le monter en noexec)

- service qui tournent: n'avoir que le strict necessaire et les configurer aux ptits oignons 

- le noyau: n'y insérer en dur que ce qui est nécessaire là encore, virer tout le reste. GrSec, Pax, RBAC sont à utiliser, mais c'est pas accessible à tout le monde (je veux dire: ça prend du temps, y a pas mal de doc à lire etc...)

- les logs: bien les mettres en place, les backuper ailleurs, les analyser automatiquement. Dans le pire des cas: tu auras une chance d'y trouver ce qui a amener à la corruption de ton système.

- veille de sécurité. 

Bon avant de te (de vous, ceux qui lisent tout ça) lancer là dedans il ya une chose que tu dois faire (auquel on ne pense pas vraiment en fait): évaluer le risque. 

Qu'est ce que tu risques à te faire attaquer?

C'est la question auquelle tu dois d'abord répondre. Par exemple, j'ai beau jeux de donner tout un tas de conseils   :Razz:   mais moi je risque rien sauf si mon serveur est rooté et qu'il est alors utilisé comme passerelle pour une autre attaque. C'est tout. (et c'est un risque minim parce qu'utiliser un serveur à fiabilité moindre dans la connexion - bd et ping pourrie - pour servir de passerrelle pour une attaque moi je dis: faute de goût ^^)

Le reste? que dalle: aucune données critiques, aucun réseau critique derrière... j'ai pas grand chose à cacher (hann ma sexe-tape  :Laughing:  ah ah je déconne...)

Du coup j'ai pu virer un TAS de trucs dans la liste des taches de sécurité, parce que la seule attaque qui arrive jusqu'à moi c'est les botnets, les scripts kiddies: bon bah sécurité de base (ssh bien config), un noyau hardened-sources à peine modif, des règles iptables basiques (j'ai puste ouvert ce dont j'avais besoin) et surtout: une installe sans toute un barda de services qui servent à rien et un check des glsa de temps en temps et voilà. 2 ans que le bouzin tourne: aucune attaque. 

Y a sécurité et sécurité donc. C'est juste un travail avec sa parano, faut savoir faire la part des choses le tout de bien évalure les risques. J'aurais la même config au taf que ce que je fais à la maison il y aurait limite faute professionnelle  :Laughing: 

----------

## Jacqueline

Merci de ta reponse kwenspc

En effet  il faut analyser la securite  en fonction des enjeux :

Je n'ai pas de donnees ultra confidentielles sur mon PC et je n'ai pas d'activite illegale a cacher.   :Laughing: 

 Mais je ne voudrais pas  en ouvrant un serveur sur Internet, que  ma compta et mon courrier adminsitratif soit  pirate..    Disons que ca m'ennuyerait  

bon je fais ca sur un autre systeme que le serveur.. partitions non montees sur le serveur .. mais bien sur ca ne suffit pas , si qqun prend le root, il va pouvoir  monter ces partitions et les lire, voire les supprimer..   :Twisted Evil: 

 ( je n'ai qu un seul PC , ca complique les choses.. )

Je connais une solution,  c'est de les mettre dans une patite partoche au bout et des la cacher  quand on s'en sert pas...  Efficace   : il faut rebooter pour changer le statut de la partition..   Un peu contraignant aussi..

Plus simple un cle USB    :Very Happy:    mais ca se perd...

 L'autre que tu as cite  : servir de relais  et d'anonymiser a un pirate qui voudrait attaquer un site.avec monm IP..   ( c'est bien ca  ? )

J'ai vu un log comme ca , lorsque j'ai laisse tourner Apache , a vide , pour voir ce qui se presenttait sur mon serveur. je ne me souviens plus excatement de la requete, et c'etait un robot, car repetitif , et il y avait l'IP d'un autre site.

 Avec Wireshark,  j'ai pu voir que mon serveur ne repondait pas a cette requete. en poussant un peu plus loin , j'ai trouve la doc de ce type de requetes , un peu particulier.. mais  je n'avais pas ce module d'apache installe .

Donc j'ai bien compris qu il ne fallait pas tous les mettre en se disant qu ils pourraient nous servir un jour...

 Je suppose que ce robot  ( avec une IP de chez OVH , qui semble heberger pas mal de saloperies :  info de mon hebergeur pour un site que j'avais fait   )   ne se livrait pas une attaque de ce site Linux en Italie ( lequel se portait tres bien d'ailleurs et a part leur piquer de la doc Linux    :Laughing:   :Laughing:   :Laughing:   pas grand chose a pirater ) , mais que c'etait juste une recherche  de vulnerabilite  de serveurs sur  toute une  plage d'IP , dont la mienne.  ( je ne suis pas celebre et je n'avais pas fait de pub pour mon serveur.. )

Et si mon serveur avait repondu j'aurais sans doute ete reperee, comme anonymiser potentielle pour un jour  aller faire une vraie attaque sur un site qui en vaut la peine, ou peut etre simplement pirater quelque choses...

 Mais tout de meme ca me derangerait que ce soit avec mon IP.. apres s'il ya une plainte il faut aller s'expliquer..

 Ce n'est pas de la parano, mais c'est pour comprendre et apprendre le volet securite. 

 J'ai fait un site  avec OS commerce  pour une amie..  j'ai hallucine de voir la naivete des gens qui mettent  un OS Commerce sur un PC   de leur  magasin, sous windows avec EasyPHP ( en plus ils pataugent a fond , dans les chmod... )  Bin oui ca existe des gens comme ca . Bien sur a cote on passe pour des paranos.. 

Mais je vois regulierement sur leur forum des boutiques qui se font  hacker  ( chez des hebergeurs ) le site d'un concurrent de mon amie entre autres..  Recemment un  ancien  site de mon amie  : un Joomla , celui d'un petit aeroclub  ) 

Il  faut dire aussi qu 'OScommerce defie les lois les plus elementaires de securite du php,  mais ce n'est pas la peine d'aller leur le dire..ils sont convaincus du contraire. A croire qu ils n'ont jamais lu la doc sur la securisation d'un site, ni lu les techniques d'attaque largement disponibles sur le net.  Ce ne sont pas des failles qu ils ont laissees, c'est  des portes de grange..  Mais c'est leur probleme   :Razz:   Pour la prochaine version du site on choisira  un autre  CMS  qu OS Commerce.  Probablement Drupal. ).

Si le site de mon amie tient debout, apres  9 mois sans aucun souci ( un seul spam )  malgre ces lacunes, je pense  parce qu on a choisi un hebergeur  integriste de la securite : Icodia, qui fait bien le menage avant , sinon il aurait fume comme les autres.. 

Cette securite a un prix, c'est 24 euros  par mois, pas 1,99 euros .  C'est justifie pour une boutique de e-commerce, ou la il y a un vrai enjeu. Mais il n'y a pas de petites economies pour les obsedes du tiroir caisse et du caddie...

 En complement d'iptables, quelqu un m'a parle de conntrack le suivi de connection..  j'ai lu la doc en diagonale et j'ai vu qu il etait disponible dans Gentoo. Je m'attendais a ce que qqun en parle ici. Pourtant c'est cense  contrer  des attaques bien precises et connues, qui peuvent aussi etre ennuyeuses sur un serveur perso..

 J'ai decouvert le hardened ,mais j'ai lu sur le forum , que c'etait complique  a configurer et que le remede pouvait etre pire que le mal, si c'etait mal configure, aussi  je m'abstiendrais  pour un serveur personnel....Laissons ca aux "pros "

 En lisant mon doc de securisation d'Apache, je me disais en voyant toutes ces redondances , que le securite c'est comme les oignons : plusieurs couches, puisqu ' aucune securite n'est vraiment parfaite..Ca peut preserver en cas d'un oubli dans la conf apres une modif ou une mise a jour pas faite assez rapidement..

----------

## kwenspc

 *Jacqueline wrote:*   

> 
> 
>  J'ai decouvert le hardened ,mais j'ai lu sur le forum , que c'etait complique  a configurer et que le remede pouvait etre pire que le mal, si c'etait mal configure, aussi  je m'abstiendrais  pour un serveur personnel....Laissons ca aux "pros "
> 
> 

 

C'est compliqué si tu commences à modifier toi même les options GRSec et Pax  :Wink:  (et oui ça peut en plus se retourner contre l'utilisateur si ce dernier fait une config au pif) . La config de base livré avec le paquet est bien suffisante pour la plupart des utilisations, faut juste pas toucher aux options GRSec et PAx donc.

----------

## Jacqueline

Merci pour  tes explications sur hardened  qui semble donc utilisable ( meme si je trouve ca encore complique pour moi ) 

Et pour  conntrack ... utile  inutile ?

 Lorsque j'ai lu pour la premiere fois la doc de packetfilter  , le firewall d' OpenBSD,  j'ai  compris qu il manquait un truc au firewall de Linux ..et il m'est venue cette image : les jeux de cartes..

 idem pour conntrack  ( mais c'est moins facile a configurer ).

 Supposons une partie de carte.. ( belote tarot )

iptables se contenterait de regarder chaque pli (requete  )  l'une apres l'autre et de verifier que celui qui emporte le pli est celui qui a mis la plus forte carte  ou le plus gros atout  ( sinon c'est une facon de tricher un peu trop grossiere )

Alors que conntrack ou packetfilter  suivrait toute la partie    pour verifier qu' on ne passe pas deux fois la meme carte..  ( mais il y a bien d'autres facons de tricher aux cartes et avec les protocoles apparament )

Iptable seul ne conserve pas la memoire de la sequence  de connection.

Ca m'intrigue .. aussi j'aimerais bien avoir des avis sur conntrack de qqun qui a l'experience.

Mais peut etre que ca ne concerne que tres peu d'attaques ou que ma comprehension est mauvaise, c'est fort possible   :Very Happy: 

----------

## loopx

Bonsoir vous tous, 

 *kwenspc wrote:*   

>  *lesourbe wrote:*   
> 
> chrooter quand c est possible
> 
>  
> ...

 

Je suis septique (ok, j'ai pas encore lu les liens fourni dans ce thread  :Very Happy: ) ... Pour moi, chroot c'est bien mieux que pas chroot. Pourrais-tu me dire en quoi c'est vraiment mal chroot ? Car bon, un service est craqué et paf, un ptit con accède à ton serveur .. il n'est pas root et même si il le devient, il aurait du mal à faire un "rm" vu que cette commande n'est pas présente... Puis, rm de quoi ? Il n'a pas accès au fichier important (sauf ceux du service déjà cassé). Ok, après, il faut modifier le service pour combler la faille (qui n'aurait déjà jamais du être présente). Mais après ? Le ptit con est root, il a rien ... peut rien faire ... Il pourrait peut-être ajouter lui meme les commandes utile (genre, cfdisk pour virer les partitions  :Very Happy:   voir init pour rebooter lol) ... mais est-ce vraiment possible ? (il n'a pas de programme pour télécharger un programme ... il n'a pas accès au shell si il est passé par apache. Donc, chroot, c'est quand même très bien au final, non ? (oui ok, promis, je vais lire mais ce thread est déjà long, mes yeux sont usé  :Very Happy: ).

Sinon, a part tout ca, je vais aussi apporter un peu ma contribution dans ce thread. 

J'ai entendu dire que "hardned, c'est dur, c'est pour les pro et je suis qu'une m****  :Sad: " ... Ben, franchement, je suis pas d'accord. Si tu sais gérer une Gentoo normal, tu gèrera une Gentoo hardened (il n'y a que quelques truc à savoir, et google sera toujours ton ami donc, fonce, c'est une expérience en plus). Qu'y a t'il comme changement dans un hardned et un non hardened ? Ben, principelement le fait que tu aura peut être des problèmes d'accès pour tes services/Utilisateur (car trop de sécu) .. après, j'ai pas poussé plus loins et je connais pas d'autre désavantage.

Du blabla :

* moins le monde en sais, mieux c'est (principe de celui qui vois rien ne craquera rien)

* sculter vos besoin, et uniquement vos besoin (donc, ne rien mettre d'inutile)

* filtrer à la brute (à la brute = bloque toutes les entrées et ouvrir juste le minimum ... voir ouvrir juste à certaine ip/mac avec ptet un reject pour dire au utilisateur non autorisé que tiens, il n'y a aucun service labas  :Smile: )

* chroot si assez de motivation  :Smile:  (je pense toujours que c'est bien le chroot :p)

* sur le net, le http restera sur le port 80 (uh ..) mais les autres (shell) devrait impérativement être sur un autre port (voir le premier principe plus haut)

* savoir qui doit faire quoi ... autrement dis, savoir qui doit pouvoir faire quoi et enore une fois, sculter selon vos besoin (tout les users n'ont pas besoin d'un accès au shell!).

* cacher les infos c'est bien ... mais ont ne devrait pas vraiment le faire si le serveur était bien sécurisé

* hardened powaa :p

* sur un serveur, personne ne doit pouvoir prendre la main sur le compte root directement (il faut toujours passer par un user => compte root désactivé sur ssh et ftp, etc)

* les clés pour vos connexion ssh ... ok ... mais moi j'aime pas. Car genre, sur un portable, une zolie clé pour se connecter au serveur mais oh, pas de bol, le portable à été craqué ...

* rendre les choses compliqué, ca peut être bien, mais ca n'est pas spécialement mieux ... de plus, l'administration est plus difficile

* le filtrage des sorties sur le serveur, ca pourrait être intéressant mais c'est aussi de la parno  :Wink: 

* toujours crypter sur le net (ssh et openvpn donc)

* un système de check pour l'intrusion, ca peut être utile mais est-ce vraiment efficace ?

* les mots de passe, c'est bien mais faut pas que le monde sache comment vous les créers  :Wink:  (donc pass de bourin?) ... et puis, j'y pensais juste ainsi, en le tapant, pas besoin de mimer avec les lèvres, c'set pas sécu non plus  :Very Happy: 

* bien sur, mettre à jour ... meme si ca peut ouvrir de nouvelle porte (celle-ci ne sont peut être pas encore découverte voir connue du future cracker)

* pour le kernel, je pense aussi qu'il faut mettre le minimum en dur ... mais de mon coté, j'ai ajouté en module les trucs d'iptables car je sais jamais exactement ce qu'il me faut  :Smile: 

* un système d'alerte, ca peut être intéressant (nagios) car .. si "/var" est full, la machine devient instable et ca, personne ne le saura avant le crash

* il est vrai qu'il faut analyser l'impact que pourrait avoir une attaque, mais ce n'est pas pour cette raison qu'il faut omettre certain niveau de sécurité

Heu, franchement, je sais plus quoi rajouter  :Smile:    je cale ...

Sinon, jacqueline, pour conntrack ... moi je connais pas vraiment ... fin, je connais le conntrack_ftp mais je pense que ca n'a rien avoir  :Surprised: 

----------

## Enlight

moi j'en aurais une très bête à ajouter : éviter les conneries! parce que le genre j'ai une jolie hardened j'installe mon ftp et là pour tester vite fait je crée un utilisateur test/test en omettant bien de ne PAS lui mettre de shell... ben c'est tout sauf rare et ça c'est déjà vu ici... (bon ok le gars était vraiment un sous-doué mais le principe demeure...)

----------

## Jacqueline

Merci loopx   pour ton long post    :Very Happy: 

 Je ne vais pas jeter le chroot  ( de toutes facons j'avais envie de l'essayer    :Very Happy:   , mais c'est un peu le but )

@Enlight    je crois bien que c'est  l'exemple  que j'avais lu sur ce forum.. ( mais j'ai peur de me rajouter a la liste des sous doue(e)s   :Laughing:  )   bon ca,  ca presse pas.. j'ai encore plein de choses a  voir avant.

----------

## loopx

 *Jacqueline wrote:*   

> Merci loopx   pour ton long post   
> 
>  Je ne vais pas jeter le chroot  ( de toutes facons j'avais envie de l'essayer     , mais c'est un peu le but )
> 
> @Enlight    je crois bien que c'est  l'exemple  que j'avais lu sur ce forum.. ( mais j'ai peur de me rajouter a la liste des sous doue(e)s   )   bon ca,  ca presse pas.. j'ai encore plein de choses a  voir avant.

 

Mais 2 rien  :Wink: 

J'ai beau me creuser la tete, je ne comprend pas comment on peut avoir un problème de secu avec chroot SI on fait bien cela ... Car il serait impossible d'ajouter des fichiers dans ce chroot ... comment faire donc  :Surprised:  ?  Je pense que c'est plus un bug qui a eu lieu qu'une faille consistante ... (ou alors, expliquer moi car j'ai du mal ... Bien sur, si on fou un clietn ftp dans le chroot, tout deviens plus simple   :Rolling Eyes:  )

----------

## Enlight

 *loopx wrote:*   

>  *Jacqueline wrote:*   Merci loopx   pour ton long post   
> 
>  Je ne vais pas jeter le chroot  ( de toutes facons j'avais envie de l'essayer     , mais c'est un peu le but )
> 
> @Enlight    je crois bien que c'est  l'exemple  que j'avais lu sur ce forum.. ( mais j'ai peur de me rajouter a la liste des sous doue(e)s   )   bon ca,  ca presse pas.. j'ai encore plein de choses a  voir avant. 
> ...

 

parceque chroot est fait de telle manière à ce que l'on puisse en sortir, car c'est ce que le comportement que l'on attend de lui.

Pourquoi? Car chroot est un outil de test et de debuggage, pas un outil de sécurité comme malheureusement beaucoup semblent le croire.

----------

## geekounet

Et ya aucun besoin de rajouter des fichiers dans le chroot ou d'avoir des binaires sous la main pour en sortir, une injection de code dans le binaire compromis histoire d'appeller les bons syscall et t'en sors les doigts dans le nez du chroot. Le chroot ne fait qu'isoler imparfaitement au niveau du FS, il n'y aucune isolation sur la pile réseau ni au niveau kernel, un user root dans un chroot a tous les pouvoirs, tout comme s'il n'y était pas.

Si tu veux une isolation FS + kernel + réseau pour avoir une vraie sécu, il faut aller voir du coté des jails sous BSD  :Wink: 

----------

## guilc

 *geekounet wrote:*   

> Si tu veux une isolation FS + kernel + réseau pour avoir une vraie sécu, il faut aller voir du coté des jails sous BSD 

 

Si tu veux ralentir tout ça, tu peux quand même voir du côté du renforcement de chroot offert par grsecurity  :Wink: 

----------

## guilc

 *loopx wrote:*   

> J'ai entendu dire que "hardned, c'est dur, c'est pour les pro et je suis qu'une m**** " ... Ben, franchement, je suis pas d'accord. Si tu sais gérer une Gentoo normal, tu gèrera une Gentoo hardened (il n'y a que quelques truc à savoir, et google sera toujours ton ami donc, fonce, c'est une expérience en plus). Qu'y a t'il comme changement dans un hardned et un non hardened ? Ben, principelement le fait que tu aura peut être des problèmes d'accès pour tes services/Utilisateur (car trop de sécu) .. après, j'ai pas poussé plus loins et je connais pas d'autre désavantage.

 

Utiliser un linux renforcé, ça ne se résume pas à passer sur un profil "hardened".

Il faut aussi mettre en place une politique de RBAC ( http://forums.grsecurity.net/viewforum.php?f=5 ) propre, entre autres choses. Et ça, c'est long, difficile et particulièrement fastidieux (et demande d'avoir une parfaite connaissance de son système, pour savoir quel programme a droit à quoi)

----------

## Enlight

 *guilc wrote:*   

>  *geekounet wrote:*   Si tu veux une isolation FS + kernel + réseau pour avoir une vraie sécu, il faut aller voir du coté des jails sous BSD  
> 
> Si tu veux ralentir tout ça, tu peux quand même voir du côté du renforcement de chroot offert par grsecurity 

 

tu as un lien pour ça stp?

----------

## guilc

Bah tout simplement le site officiel  :Smile:  http://www.grsecurity.net/features.php

----------

## Enlight

effectivement ça semble pas mal restreindre les possibilités, il reste des possibilités de sortir du chroot connues à ce jour?

----------

## Jacqueline

Euh moi j'en ai un..  :Very Happy: 

http://sysjail.bsd.lv/sysjail.3.html

Apparement ca a ete refait entierement , car la version precedente avait ete craquee..   :Sad: 

http://sysjail.bsd.lv/

[url]www.watson.org/~robert/2007woot/2007usenixwoot-exploitingconcurrency.pdf [/url]

 [EDIT]  pardon , c'etait pour les jails, mais je les laisse tout de meme..    Piouh la securite  c'est hard   ! [/EDIT]

----------

## guilc

 *Enlight wrote:*   

> effectivement ça semble pas mal restreindre les possibilités, il reste des possibilités de sortir du chroot connues à ce jour?

 

Je dois dire que je ne me suis pas penché a fond sur la question : je pars du principe que passé un certain niveau de protection, le risque encouru par rapport à la pénibilité de mise en place ne justifie plus d'aller plus loin.

Donc je considère qu'un système renforcé par PAX + Grsec + une politique de RBAC correcte et une administration carrée est suffisant par rapport au risque qu'encours ma machine, et je ne me pose pas plus de questions  :Very Happy: 

----------

## loopx

Je comprend mieux chroot quand on me parle d'isolation kernel/reso  :Wink: 

Ok ok ... mais encore une fois, bien que tu as accès au kernel et au réseau, comment tu arrive à faire une injection sans avoir d'outil sous la main ? Donc, je persiste à croire que si le chroot est bien fait, ca devrait pas poser de problème de secu ...

Enfin, il est vrai que j'ai pensé qu'il était peut être possible de créer un binaire avec vi (y a po vi dans un chroot.. ni meme echo ...)  :Surprised:     mais ca doit être bien chaud quand meme ...

Sinon, pour hardened, j'ai pas cherché du tout  :Smile:  je l'ai installé minimalement, et j'ai déjà des trucs activer, de la protection en plus donc, c'est déjà bien et j'en suis content  :Smile:    maintenant, jte le fais pas dire, je suis pas trop du genre à faire ca dans les règles de l'art ... :s

----------

## Jacqueline

Une explication interessante 

http://www.touslesreseaux.com/forum/index.php?showtopic=40

 Mais le chroot bien fait  , ca a l'air de ressembler a chroot +  grsecurity.

 Mais  sortir  du  chroot simple , c'est pas a la portee du premier gamin, qui veut s'entrainer a cracker des sites sur un serveur perso, meme avec la doc   :Very Happy: 

Mais c'est mieux que pas de chroot du tout. Meme si sans , ca resiste assez bien au courant...

 Puis qu on a parle du hardened  pour Gentoo .. j'avais decouvert  PHP  hardened http://www.hardened-php.net/

avec Suoshin. http://www.hardened-php.net/suhosin/index.html

Sur un serveur, perso ou il y a un site avec un CMS souvent bourre de failles,  c'est plus simple a attaquer qu un chroot., et on se retrouve avec une photo de Q sur son site..   :Laughing:   ou un virus qui pourira le PC des amis et de la famille.. 

 J'ai bien ri en lisant ca :  

ne pas confondre complexité et sécurité : si votre système de sécurité vous échappe, considérez que vous n'êtes pas en sécurité. Bon, de toute façon, vous n'êtes jamais en sécurité.

----------

## Jacqueline

Jail dans Portage    :Rolling Eyes: 

[url]

http://gentoo-portage.com/app-misc/jail/[/url]

----------

## kwenspc

 *Jacqueline wrote:*   

> Jail dans Portage   
> 
> [url]
> 
> http://gentoo-portage.com/app-misc/jail/[/url]

 

Ce jail là n'est pas le jail des BSD.  (vas voir le site officiel du-dit projet, c'est un outil qui aide au déploiement d'un environnement chrooté)

 *loopx wrote:*   

> 
> 
> Ok ok ... mais encore une fois, bien que tu as accès au kernel et au réseau, comment tu arrive à faire une injection sans avoir d'outil sous la main ? Donc, je persiste à croire que si le chroot est bien fait, ca devrait pas poser de problème de secu ...
> 
> 

 

Ahem...   :Rolling Eyes: 

Tu ferais bien d'aller faire un tour du coté des techniques d'exploitations de failles. (c'est sur c'est pas donné à tous le monde de réussir ce genre d'injection) 

chroot n'est pas et ne seras JAMAIS un outil de sécurité. (il est pas prévu pour ça, comme l'a résumé Enlight)

Utiliser chroot chez soit pas de problème, tu subiras jamais une attaque de haut vol. Utiliser chroot sur des serveurs critiques par contre c'est mettre une protection en mousse: dès lors que l'attaquant prend la main dans le chroot s'en est finit du serveur racine.

Si après vous avez toujours pas saisis la nuances moi je laisse tomber.   :Razz: 

----------

## Jacqueline

kwenspc

 Merci  apres  ce  passage en revue, c'est  clair.   :Very Happy: 

----------

## loopx

Ok, j'avais oublié que ctais l'injection qui faisait tout  :Smile:    donc oui, si tu arrive déjà a craquer .. libre à toi de bypasser le chroot ... mais ca doit pas être facile, en effet  :Wink: .

Intéressant tout ca  :Smile: 

Mais entre chroot et pas chroot, c'est quand meme un peu plus sécu avec :p

----------

## Jacqueline

bonjour a tous au fait..

 Je viens de lire : 10.16 - Parlez moi de chroot(2) Apache ? la doc d'OpenBSD.

Je crois qu ils montrent bien tous les aspects du  probleme avec chroot., sans parti pris, a la limite ca peut etre pire que sans.. 

http://www.openbsd.org/faq/fr/faq10.html#httpdchroot

----------

## loopx

Mouarf  :Sad:  on est mal barré avec notre nux alors  :Sad: 

----------

## Jacqueline

 *loopx wrote:*   

> Mouarf  on est mal barré avec notre nux alors 

 

 Non pourquoi, si on suit les autres conseils .. donnes au debut.

 Ce ne sera pas une forteresse, mais : les enjeux  !  :Very Happy:  et plutot qu une mauvaise ou fausse solution.. derriere laquelle on se croit a l'abri de tout   :Crying or Very sad: 

----------

## kwenspc

Franchement vous me prenez pas la tête. Loopx avec ta liste de point à voir pour la sécu, sans chroot c'est du très solide pour un serveur @ home. 

Je n'ai pas chroot chez moi (ok j'ai pas apache qui est généralement l'appli que les gens mettent dans un chroot), j'ai assez confiance dans tout le reste, chroot c'est vraiment un détail si tout le reste à côté est bon. Et de fait il FAUT s'attarder à bien config tout le reste plutôt que de perdre du temps avec chroot. (qui est faillible puisque pas fait pour ça, je sais je rabache...)

Quelques commentaires sur ta liste loopx:

- tu peux mettre les modules iptables dont tu as besion en dur (et virer le support des modules dans le noyaux). Iptables va gueuler (il va dire qu'il arrive pas à charger les modulse) mais pour autant il va fonctionner.

- Au sujet des clé ssh, le mieux c'est de l'avoir sur clé usb, et encryptée. Ce qui veut dire que pour pouvoir te connecter à ton serveur faut la clé certes, mais aussi la passphrase pour la décrypter (donc si on te choures ta clé, le temps que le mcs décrypte du triple-des t'as le temps de te rendre compte du vol, de blacklister la clé et de t'en recréer un jeu  :Wink: ). Le panard c'est une smartcard rsa usb, la clé est illisible car générée et écrite dans la clé, avec passphrase. C'est du parano tranquile, c'est du bon.

- Sinon pour l'IDS oui c'est trop de boulot avec le risque de te retrouver perdu devant tout un tas de faux-positifs. Le meilleur IDS c'est un admin consciencieux   :Laughing: 

- Les mise à jour maintenant, privilégies les mises à jour de sécurité uniquement (les GLSA). Ça sert à rien de passer d'une version à une autre sur un soft, si la version actuelle que tu utilise est stable et sans faille connue. (une mise à jour pourrait rendre ton système moins stable, si tu tombes sur un paquet mal finit sait-on jamais)

- Nagios est en effet trop lourd pour 1 serveur (en plus un serveur @home). Je préfères des ptits scripts perso (cron job tout con, pas besoin de se prendre la tête). Sinon les rddtools, munin pour lest stats.

----------

## Enlight

 *loopx wrote:*   

> 
> 
> Enfin, il est vrai que j'ai pensé qu'il était peut être possible de créer un binaire avec vi (y a po vi dans un chroot.. ni meme echo ...)     mais ca doit être bien chaud quand meme ...
> 
> 

 

Tu plaisantes là? Si tu ne connais pas les rudiments des exploits de base (genre ceux qui ne marchent même plus depuis des lustres mais qui sont simple à comprendre) c'est normal que tu ais du mal à concevoir la manière dont tu risques d'être attaqué...

----------

## loopx

Ouais, je sais bien, je suis pas trop intéressé par le crackage/hacking et donc, je n'y connais pas grand chose. Mais j'ai quand même de bonne connaissance en informatique  :Very Happy: 

J'ai mis nagios sur mon serveur, c'est pas mal et je monitore aussi par VPN ...

Mais avec tout les systèmes de monitoring en place, je m'appercois que je bouff un bon gros giga octet d'adsl par mois ... hum ...

* routage dynamique (10 secondes)

* cacti (5 min)

* nagios (5 min)

... :s

----------

## kwenspc

 *loopx wrote:*   

>  Mais j'ai quand même de bonne connaissance en informatique 
> 
> 

 

Ça c'est toi qui le dit  :Mr. Green: 

penser que chroot est un outil de sécu hein, mmh...

oui c'est bon je te permet de me pousser vers la sortie, voilà  :Arrow:   []

----------

## loopx

 :Laughing: 

EDIT: no comment   :Cool: 

----------

## lesourbe

 *kwenspc wrote:*   

> Utiliser chroot sur des serveurs critiques par contre c'est mettre une protection en mousse: dès lors que l'attaquant prend la main dans le chroot s'en est finit du serveur racine.

 

je remets de l'huile sur le feu, parce que y'en a qui ont pas compris :

en quoi ça le rend plus faillible ?

----------

## geekounet

 *lesourbe wrote:*   

>  *kwenspc wrote:*   Utiliser chroot sur des serveurs critiques par contre c'est mettre une protection en mousse: dès lors que l'attaquant prend la main dans le chroot s'en est finit du serveur racine. 
> 
> je remets de l'huile sur le feu, parce que y'en a qui ont pas compris :
> 
> en quoi ça le rend plus faillible ?

 

Ça fait une complexité inutile en plus, donc t'es moins efficace à l'administration du reste, de choses plus importantes, donc ta sécurité est moindre, c'est dans les principes de sécu de base, KISS  :Wink: 

----------

## kwenspc

 *lesourbe wrote:*   

>  *kwenspc wrote:*   Utiliser chroot sur des serveurs critiques par contre c'est mettre une protection en mousse: dès lors que l'attaquant prend la main dans le chroot s'en est finit du serveur racine. 
> 
> je remets de l'huile sur le feu, parce que y'en a qui ont pas compris :
> 
> en quoi ça le rend plus faillible ?

 

serveur critique = en principe un admin derrière que essais d'avoir une sécurite maxi (enfin ça c'est le principe). Si l'attaquant réussit a passer le tout pour arriver dans un chroot: il va rigoler et ça lui prendre que dalle à bousiller ça et passer à la racine du serveur. C'est pas que chroot rend le serveur plus faillibel, c'est puste que c'est totalement inutile dans ce contexte là. c'est tout.

[edit] ouais geekounet l'explique mieux que moi ^^[/edit]

----------

## scherz0

 *lesourbe wrote:*   

>  *kwenspc wrote:*   Utiliser chroot sur des serveurs critiques par contre c'est mettre une protection en mousse: dès lors que l'attaquant prend la main dans le chroot s'en est finit du serveur racine. 
> 
> je remets de l'huile sur le feu, parce que y'en a qui ont pas compris :
> 
> en quoi ça le rend plus faillible ?

 

Pour résumer : maintenir correctement un système est une activité complexe.  Maintenir plusieurs racines ajoute de la complexité, et on risque facilement :

 - d'oublier de mettre à jour les racines alternatives,

 - de le faire de façon incohérente,

 - de casser des dépendances,

 - de fragiliser les processus concernés, etc.

Démarrer un processus dans une racine alternative peut être utile pour beaucoup de raisons.  Mais pas pour la sécurité du système, ou uniquement de façon marginale et à condition de comprendre parfaitement en quoi ça consiste.  Extrait de man chroot(2) : "This call changes an ingredient in the pathname resolution process and does nothing else".

Sauf lorsqu'on sait précisément pourquoi on le fait, changer la racine d'un processus n'a aucun intérêt et ne fait que compliquer inutilement les choses.   C'est donc dangereux de le faire de façon systématique ("chrooter quand c'est possible").

----------

## lesourbe

on s'est mal entendu sur le "quand c'est possible".

postifix par exemple est construit avec... en fait, c'est même pas top, il semble que faut le désactiver pour permettre selinux.

ok ok chroot c'est le mal.

----------

## scherz0

 *lesourbe wrote:*   

> 
> 
> postifix par exemple est construit avec... en fait, c'est même pas top, il semble que faut le désactiver pour permettre selinux.
> 
> 

 

C'est un autre sujet : il ne s'agit pas d'adminstration de système, mais de programmation. On l'utilise en sachant précisément ce que ça fait (c'est à dire très peu !)

On fixe la racine au répertoire de base du processus (celui qui contient les données), et on réduit (un peu) la possibilité de lire/écrire par erreur en dehors de ce répertoire.   Mais ça ne permet que de limiter les conséquences directes des erreurs de programmation, et en aucun cas ça ne protège de leur exploitation.

----------

## lesourbe

 *scherz0 wrote:*   

> en aucun cas ça ne protège de leur exploitation.

 

... si l'exploit en question prévoit le chroot.

----------

## loopx

 *geekounet wrote:*   

>  *lesourbe wrote:*    *kwenspc wrote:*   Utiliser chroot sur des serveurs critiques par contre c'est mettre une protection en mousse: dès lors que l'attaquant prend la main dans le chroot s'en est finit du serveur racine. 
> 
> je remets de l'huile sur le feu, parce que y'en a qui ont pas compris :
> 
> en quoi ça le rend plus faillible ? 
> ...

 

Ca porte ravageusement à débat tout ca ... Car bon, ok simple ok ... mais le compliqué est aussi une protection  :Wink:   suffi de demander au admin de Windows  :Very Happy: 

----------

## geekounet

 *loopx wrote:*   

>  *geekounet wrote:*    *lesourbe wrote:*    *kwenspc wrote:*   Utiliser chroot sur des serveurs critiques par contre c'est mettre une protection en mousse: dès lors que l'attaquant prend la main dans le chroot s'en est finit du serveur racine. 
> 
> je remets de l'huile sur le feu, parce que y'en a qui ont pas compris :
> 
> en quoi ça le rend plus faillible ? 
> ...

 

Bah non, si tu fais compliqué (et inutilement de plus), t''as beaucoup plus de chances de faire une erreur, donc non t'es pas protégé, tu t'attires plus de problèmes qu'autre chose  :Wink: 

----------

## Oupsman

 *geekounet wrote:*   

> 
> 
> Bah non, si tu fais compliqué (et inutilement de plus), t''as beaucoup plus de chances de faire une erreur, donc non t'es pas protégé, tu t'attires plus de problèmes qu'autre chose 

 

C'est clair  :Rolling Eyes:  Le principe KISS est utile en sécurité, en programmation, partout en fait  :Smile: 

----------

