Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Sécurité serveur] Conseils de base?
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index French
View previous topic :: View next topic  
Author Message
FTG
n00b
n00b


Joined: 28 Nov 2008
Posts: 10

PostPosted: Tue Dec 02, 2008 1:15 pm    Post subject: [Sécurité serveur] Conseils de base? Reply with quote

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
Back to top
View user's profile Send private message
kwenspc
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 4954

PostPosted: Tue Dec 02, 2008 1:47 pm    Post subject: Reply with quote

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.
_________________
membre officieux du SAV Ati GEntoo
Back to top
View user's profile Send private message
lesourbe
l33t
l33t


Joined: 24 Nov 2005
Posts: 710
Location: Champagne !

PostPosted: Tue Dec 02, 2008 2:28 pm    Post subject: Reply with quote

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.
_________________
Is that a banhammer ?
LeSourbe, Member of EPowerforce.
Back to top
View user's profile Send private message
mornik
Apprentice
Apprentice


Joined: 12 Mar 2005
Posts: 184
Location: Niort

PostPosted: Tue Dec 02, 2008 2:36 pm    Post subject: Reply with quote

Ne pas oublier non plus des outils de surveillance comme logwatch, ou tripwire.
_________________
Pousser pas j'y suis déjà !
Back to top
View user's profile Send private message
Link31
Apprentice
Apprentice


Joined: 17 Apr 2006
Posts: 200
Location: France

PostPosted: Tue Dec 02, 2008 7:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
kwenspc
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 4954

PostPosted: Tue Dec 02, 2008 8:45 pm    Post subject: Reply with quote

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 :?

Ah bah tiens: http://kerneltrap.org/Linux/Abusing_chroot
_________________
membre officieux du SAV Ati GEntoo
Back to top
View user's profile Send private message
geekounet
Bodhisattva
Bodhisattva


Joined: 11 Oct 2004
Posts: 3772
Location: Wellington, Aotearoa

PostPosted: Tue Dec 02, 2008 9:07 pm    Post subject: Reply with quote

kwenspc wrote:
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 :?

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

+1
Enfin sous Linux ya les vserver qui peuvent se rapprocher des jails, mais ça les vaut pas encore parait-il. :P
Back to top
View user's profile Send private message
lesourbe
l33t
l33t


Joined: 24 Nov 2005
Posts: 710
Location: Champagne !

PostPosted: Wed Dec 03, 2008 10:01 am    Post subject: Reply with quote

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.
_________________
Is that a banhammer ?
LeSourbe, Member of EPowerforce.
Back to top
View user's profile Send private message
kwenspc
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 4954

PostPosted: Wed Dec 03, 2008 12:08 pm    Post subject: Reply with quote

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 :lol: . Il y a de bien meilleur articles à ce sujet sur le net.
_________________
membre officieux du SAV Ati GEntoo
Back to top
View user's profile Send private message
lesourbe
l33t
l33t


Joined: 24 Nov 2005
Posts: 710
Location: Champagne !

PostPosted: Wed Dec 03, 2008 1:31 pm    Post subject: Reply with quote

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é.
_________________
Is that a banhammer ?
LeSourbe, Member of EPowerforce.
Back to top
View user's profile Send private message
razer
l33t
l33t


Joined: 08 Oct 2004
Posts: 893
Location: Paris - France

PostPosted: Wed Dec 03, 2008 1:55 pm    Post subject: Reply with quote

J'ajouterais juste le programme fail2ban, qui bloque les ports de services (ssh, ftp...) pour les IPs ayant provoqué des échecs d'authentification
Back to top
View user's profile Send private message
Jacqueline
Apprentice
Apprentice


Joined: 28 Jul 2006
Posts: 161
Location: Netherland

PostPosted: Sat Dec 13, 2008 10:46 am    Post subject: Reply with quote

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..
Back to top
View user's profile Send private message
kwenspc
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 4954

PostPosted: Sat Dec 13, 2008 11:51 am    Post subject: Reply with quote

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 :lol:. 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 :P 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 :lol: 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 :lol:
_________________
membre officieux du SAV Ati GEntoo
Back to top
View user's profile Send private message
Jacqueline
Apprentice
Apprentice


Joined: 28 Jul 2006
Posts: 161
Location: Netherland

PostPosted: Sat Dec 13, 2008 2:52 pm    Post subject: Reply with quote

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. :lol:

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:

( 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 :D 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 :lol: :lol: :lol: 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 :P 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..
Back to top
View user's profile Send private message
kwenspc
Advocate
Advocate


Joined: 21 Sep 2003
Posts: 4954

PostPosted: Sat Dec 13, 2008 4:15 pm    Post subject: Reply with quote

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.
_________________
membre officieux du SAV Ati GEntoo
Back to top
View user's profile Send private message
Jacqueline
Apprentice
Apprentice


Joined: 28 Jul 2006
Posts: 161
Location: Netherland

PostPosted: Sat Dec 13, 2008 5:57 pm    Post subject: Reply with quote

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 :D
Back to top
View user's profile Send private message
loopx
Advocate
Advocate


Joined: 01 Apr 2005
Posts: 2787
Location: Belgium / Liège

PostPosted: Sun Dec 14, 2008 6:15 pm    Post subject: Reply with quote

Bonsoir vous tous,


kwenspc wrote:
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 :?

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



Je suis septique (ok, j'ai pas encore lu les liens fourni dans ce thread :D) ... 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 :D 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é :D).


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**** :(" ... 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 :))
* chroot si assez de motivation :) (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 ;-)
* 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 ;) (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 :D
* 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 :-)
* 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 :) 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 :o
_________________
Mon MediaWiki perso : http://pix-mania.dyndns.org
Back to top
View user's profile Send private message
Enlight
Advocate
Advocate


Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)

PostPosted: Sun Dec 14, 2008 6:27 pm    Post subject: Reply with quote

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...)
Back to top
View user's profile Send private message
Jacqueline
Apprentice
Apprentice


Joined: 28 Jul 2006
Posts: 161
Location: Netherland

PostPosted: Sun Dec 14, 2008 8:08 pm    Post subject: Reply with quote

Merci loopx pour ton long post :D

Je ne vais pas jeter le chroot ( de toutes facons j'avais envie de l'essayer :D , 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 :lol: ) bon ca, ca presse pas.. j'ai encore plein de choses a voir avant.
Back to top
View user's profile Send private message
loopx
Advocate
Advocate


Joined: 01 Apr 2005
Posts: 2787
Location: Belgium / Liège

PostPosted: Sun Dec 14, 2008 9:43 pm    Post subject: Reply with quote

Jacqueline wrote:
Merci loopx pour ton long post :D

Je ne vais pas jeter le chroot ( de toutes facons j'avais envie de l'essayer :D , 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 :lol: ) bon ca, ca presse pas.. j'ai encore plein de choses a voir avant.



Mais 2 rien ;)



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 :o ? 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 :roll: )
_________________
Mon MediaWiki perso : http://pix-mania.dyndns.org
Back to top
View user's profile Send private message
Enlight
Advocate
Advocate


Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)

PostPosted: Sun Dec 14, 2008 10:31 pm    Post subject: Reply with quote

loopx wrote:
Jacqueline wrote:
Merci loopx pour ton long post :D

Je ne vais pas jeter le chroot ( de toutes facons j'avais envie de l'essayer :D , 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 :lol: ) bon ca, ca presse pas.. j'ai encore plein de choses a voir avant.



Mais 2 rien ;)



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 :o ? 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 :roll: )


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.
Back to top
View user's profile Send private message
geekounet
Bodhisattva
Bodhisattva


Joined: 11 Oct 2004
Posts: 3772
Location: Wellington, Aotearoa

PostPosted: Sun Dec 14, 2008 10:40 pm    Post subject: Reply with quote

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 ;)
Back to top
View user's profile Send private message
guilc
Bodhisattva
Bodhisattva


Joined: 15 Nov 2003
Posts: 3326
Location: Paris - France

PostPosted: Sun Dec 14, 2008 10:44 pm    Post subject: Reply with quote

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 ;)
_________________
Merci de respecter les règles du forum.

Mon site perso : https://www.xwing.info
Mon PORTDIR_OVERLAY : https://gentoo.xwing.info ou layman -a xwing
Back to top
View user's profile Send private message
guilc
Bodhisattva
Bodhisattva


Joined: 15 Nov 2003
Posts: 3326
Location: Paris - France

PostPosted: Sun Dec 14, 2008 10:53 pm    Post subject: Reply with quote

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)
_________________
Merci de respecter les règles du forum.

Mon site perso : https://www.xwing.info
Mon PORTDIR_OVERLAY : https://gentoo.xwing.info ou layman -a xwing
Back to top
View user's profile Send private message
Enlight
Advocate
Advocate


Joined: 28 Oct 2004
Posts: 3519
Location: Alsace (France)

PostPosted: Sun Dec 14, 2008 11:02 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index French All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum