Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Sécurité Sécurité Sécurité Tester la securite d'un serveur

Tester la securite d'un serveur

24 réponses
Avatar
Arnaud
Bonjour,

Je suis dans une petite société qui vient d'investir dans un serveur
pour héberger nous-même notre site. Le problème, c'est que personne
n'est vraiment calé en matière de sécurité et on voudrait tout de même
se débrouiller seuls plutôt que de dépenser une fortune pour un audit et
la solution qui irait avec.

Ma question est : comment vérifier depuis l'extérieur que notre serveur
est "bien" protégé ?

Je pourrais m'amuser à récupérer quelques outils que les SK utilisent
mais bon... ça risque de faire pas mal de trucs à chercher et au final,
j'aurais vraiment pas testé à fond... donc, on oublie cette solution...
sans compter que je me méfierai de ce genre d'outils car on ne sait
jamais ce que ça peut contenir !!!

J'ai aussi vu que des sites permettaient de tester les ports d'un
ordinateur mais cela me pose deux problèmes :
- est-ce suffisant ? (je pense que non)
- qu'est-ce qui me garantis que les infos collectées pour le test ne
servent pas derrière à trouver des cibles potentielles ? (je sais, c'est
un peu de la parano mais je préfère rester prudent ! si ça avait été
pour ma machine perso, ça ne m'aurait pas dérangé : je teste, je me
déconnecte et je me reconnecte et plus de soucis car mon IP aura (en
principe) changé... Mais là, avec un serveur (en IP fixe donc), j'ai
quelques craintes...)

Merci de vos conseils en tout genre (liens vers des outils, des
articles, des ouvrages... Bref, tout ce qui peut m'aider !)

Arnaud
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Leo Wauters
On 12 Nov 2003 15:56:23 GMT, swollen wrote:

Xavier Roche wrote:

Si seul le site est hébergé, vérifier que seul le port 80 est ouvert
derrière le firewall. Après, vérifier que le serveur web est correctement
configuré (exemple: sous Linux, un Apache récent, avec les modules type
php en safe mode, le tout chrooté sur un système dont le / est en
read-only)


Si j'execute Apache sous un users.group qui n'a des droits en lecture
ecriture que dans son repertoire, exemple bill.web dans /www,
y'a t'il des risques hors /www ?
Il faudrait que apache soit chrooté dans son répertoire, et même comme

ca, il semble qu'il y a des moyens de contourner le chroot.
N'oublies pas de poser des autorisations par défaut sur / avec une
directive <directory /> avec order allow, deny deny from all.
Faire attention aux liens symboliques : interdits les ou mets bien
symlinksifownermatch.
tu peux pousser le vice et avoir une partition dédiée montée dans /www
avec les options ro, noexec, nodev, nosuid....
Tu peux jouer avec chattr pour protéger tes fichiers, mais ca commence
à devenir très contraignant.

Léo.


Avatar
Pierre BETOUIN
Xavier Roche wrote:
Si j'execute Apache sous un users.group qui n'a des droits en lecture
ecriture que dans son repertoire, exemple bill.web dans /www, y'a t'il des
risques hors /www ?


Oui.
Tu peux chrooter apache (cf docs sur google) pr limiter les dégats en cas
de pbl.

Pierre
--
°°°°°°°°°----------------°°°°°°°°°
Pierre BETOUIN

°°°°°°°°°----------------°°°°°°°°°

Avatar
Eric Razny
"swollen" a écrit dans le message de
news:3fb24614$0$11226$
Xavier Roche wrote:

Si seul le site est hébergé, vérifier que seul le port 80 est ouvert
derrière le firewall. Après, vérifier que le serveur web est
correctement


configuré (exemple: sous Linux, un Apache récent, avec les modules type
php en safe mode, le tout chrooté sur un système dont le / est en
read-only)


Si j'execute Apache sous un users.group qui n'a des droits en lecture
ecriture que dans son repertoire, exemple bill.web dans /www,
y'a t'il des risques hors /www ?


Je pense que la question est mal posée (meuh non je ne suis pas un politique
qui commence par cette phrase pour répondre "à côté"!).
Sur un système "normal" (sans acl par exemple) ton users.group définit
uniquement pour l'occasion profite des droits "other" pour tous les
fichiers. Donc si tu as un "petit" problème de configuration (du genre /bin
en -rwxr-xrwx) tu vas direct vers une compromission de la machine. De même
une faille locale accédée...en local[1]! et reboom.

Maintenant si tu es à jour des versions OS et softs et que tu ne t'es pas
planté dans ta config tu doit être raisonnablement tranquille.

Note que le chroot est un plus, mais il ne prend toute sa valeur que si tu
en connait les limites. Tu as eu un MISC il y a quelques temps là dessus.


Eric

[1] Attention à ce que tu laisse comme scripts cgi entre autre.


Avatar
swollen
Eric Razny wrote:
"swollen" a écrit dans le message de
news:3fb24614$0$11226$

Xavier Roche wrote:


Si seul le site est hébergé, vérifier que seul le port 80 est ouvert
derrière le firewall. Après, vérifier que le serveur web est



correctement

configuré (exemple: sous Linux, un Apache récent, avec les modules type
php en safe mode, le tout chrooté sur un système dont le / est en
read-only)


Si j'execute Apache sous un users.group qui n'a des droits en lecture
ecriture que dans son repertoire, exemple bill.web dans /www,
y'a t'il des risques hors /www ?



Je pense que la question est mal posée (meuh non je ne suis pas un politique
qui commence par cette phrase pour répondre "à côté"!).
Sur un système "normal" (sans acl par exemple) ton users.group définit
uniquement pour l'occasion profite des droits "other" pour tous les
fichiers.


Oui mais il ne peut pas faire grand chose de ca. De plus il est lancé
sous le non de l'utilisateur et non par root, je sais pas si c'est une
sécurité en plus?


Donc si tu as un "petit" problème de configuration (du genre /bin
en -rwxr-xrwx)


Non quand même pas! Même pour /etc/httpd/http.conf et autres, cet
utilisateur ne peur que lire.

tu vas direct vers une compromission de la machine. De même
une faille locale accédée...en local[1]! et reboom.

Maintenant si tu es à jour des versions OS et softs et que tu ne t'es pas
planté dans ta config tu doit être raisonnablement tranquille.


C'est plutot à jour, derniere Slackwar 9.1


Note que le chroot est un plus, mais il ne prend toute sa valeur que si tu
en connait les limites. Tu as eu un MISC il y a quelques temps là dessus.


J'ai trouvé une doc, je vais lire :)

http://penguin.epfl.ch/chroot.html



Avatar
Eric Razny
"swollen" a écrit dans le message de
news:3fb305b3$0$27033$
Eric Razny wrote:
"swollen" a écrit dans le message de
news:3fb24614$0$11226$


Je pense que la question est mal posée (meuh non je ne suis pas un
politique


qui commence par cette phrase pour répondre "à côté"!).
Sur un système "normal" (sans acl par exemple) ton users.group définit
uniquement pour l'occasion profite des droits "other" pour tous les
fichiers.


Oui mais il ne peut pas faire grand chose de ca. De plus il est lancé
sous le non de l'utilisateur et non par root, je sais pas si c'est une
sécurité en plus?


Il est sous l'id de l'utilisateur si tu as activé l'option qui va bien
(suexec). Sinon c'est l'uid d'apache.
Je veux juste mettre en exergue que ton utilisateur est, de fait, via ses
script, local, et qu'on trouve encore pas mal de systèmes avec des droits

Non quand même pas! Même pour /etc/httpd/http.conf et autres, cet
utilisateur ne peur que lire.


oops : pourquoi cet utilisateur peut-il lire la config des autres -voire
même la sienne-? (tu as un seul apache avec des virtuals?).
Là par contre ce n'est même pas une plaisanterie : une erreur de config est
toujour possible, ce n'est pas la peine d'aller l'afficher en grand!

Maintenant si tu es à jour des versions OS et softs et que tu ne t'es
pas


planté dans ta config tu doit être raisonnablement tranquille.
C'est plutot à jour, derniere Slackwar 9.1



Ca dépend de ce que tu ajoute dessus.
Par exemple ça ne m'est jamais venu à l'idée d'utiliser l'apache ou le
openssl, openssh, sendmail etc livrés avec la distro (même si openssl c'est
parfois galère à remplacer proprement à cause des dépendances :) ). Tu as
même parfois des vulnérabilités propre à la version de la distro (mais tu
échappe rarement aux failles "génériques"!)

Note que le chroot est un plus, mais il ne prend toute sa valeur que si
tu


en connait les limites. Tu as eu un MISC il y a quelques temps là
dessus.


J'ai trouvé une doc, je vais lire :)
http://penguin.epfl.ch/chroot.html


Je jette un oeil quand j'ai le temps (ça risque d'être long en ce moment).

Eric


Avatar
Eric Razny
"Eric Razny" a écrit

Oops :

Je veux juste mettre en exergue que ton utilisateur est, de fait, via ses
script, local, et qu'on trouve encore pas mal de systèmes avec des droits


... pas assez restrictifs sur pas mal de fichiers clefs.

Désolé, ça doit être un coup de fil au milieu de l'écriture de la réponse!

Eric.

Avatar
Eric Belhomme
(Xavier) wrote in
news:1g4eaui.17b60qsk4u0wsN%:

Je ne voudrais pas paraître pessimiste, mais :

Si c'est un Windows, il est d'ores et déja troué jusqu'à l'os.
Si c'est un Linux Redhat ou Mandrake, c'est très probable.
Si c'est un BSD, ça se peut aussi, mais moins probable.

Comme dit par un autre contributeur, la sécurité informatique, c'est un
métier.

Vu la teneur de ton message, ca n'est de toute evidence pas le tien.

C'est pas la peine de poster ici si c'est pour répeter ce que tu as entendu
de la bouche d'un parfait inconnu, sans verifier la réracité de ses
dires...

--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/

Avatar
Eric Belhomme
(Xavier) wrote in
news:1g4lcch.j46tme10t9heiN%:

C'est pas la peine de poster ici si c'est pour répeter ce que tu as
entendu de la bouche d'un parfait inconnu, sans verifier la réracité
de ses dires...


C'est une expérience personnelle.

Autre question ?

Non, mais des éléments de réponse :


Primo, désolé pour le ton un peu sec de ma précédente réponse, mais le
genre de réponse que tu as faite (en substance windows = caca, linux = de
la balle) a le don de me faire sortir de mes gonds. Maintenant je vais
développer le pourquoi du comment :

Un système d'exploitation - quel qu'il soit - n'est _que_ ce qu'on en fait.
Dire que windows est plus ou moins sur que gnu/linux qui est plus ou moins
sur que openBSD n'a pas de sens, car la sécurité d'un système est
directement lié à la compétence de son administrateur.

Bien sur, on ne peut pas nier que OpenBSD fraichement installé est
incomparablement plus sûr que W2k server juste installé... mais on compare
alors ce qui n'est pas comparable :

- par défaut, OpenBSD ne démarre _aucun_ service, que qui signifie que les
seules attaques applicables alors sont contre sa pile IP, ou par IP
spoofing si la machine tente de se connecter à un service distant... dans
ces conditions, la machine est difficilement compromissible (encore qu'un
DOS ou DDOS pourrait peut être la mettre mal...)

- a l'inverse, win2k server installe et démarre _automatiquement_ dès le
1er boot un tas de services plus ou moins utiles... Comme chacun sait, plus
un serveur propose de services, plus le nombre de failles potentielles est
élevé, donc plus les risques de compromission sont grands...

- mais qi on installe un équivalent de tous les services fournis par défaut
sur windows sur notre serveur OpenBSD ??? sera-t-il toujours la forteresse
imprenable dont les BSDistes chantent les louanges ??? perso j'en doute...
A l'inverse, pour trouer un win2k dont tous les services inutiles et/ou
dangeureux ont été désactivés, il faudra se lever de bonne heure...

- en suivant la meme logique, dire que si on est sous Red Ha, on est
probablement troué, mais qu'on est protégé si on est sous Debian est
simplement stupide, pourtant je suis pro-Debian, je m'en suis jamais
caché... mais entre ces 2 distribs, la seule chose qui change, c'est
l'admin...

Bref, un admin un tant soit peu expérimenté te le confirmera, j'ai vu des
serveurs IIS se prendre des beignes dans la gueule sans broncher, et des
serveurs Apache se faire lamentablement trouer parce le fichier /etc/passwd
etait accessible en http !!!

La grosse différence entre un admin UNIX et un admin windows (la plupart du
temps) :
- l'admin UNIX est vraiment formé à son métier,
- l'admin Windows n'est pas un vrai administrateur, mais "hérite" de titre
plus ou moins officiellement, en plus de sa "vraie" fonction (c'est en tout
cas le cas de figure généralement constaté des les PME/PMI, et des fois
meme dans des grosses boites...)

Pour conclure, je maintiens ma 1ere assertion : la sécurité informatique
n'est de toute évidence pas ton métier, ne t'en déplaise...

PS : je passe sur ton post-criptum hautement constructif...

--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/


Avatar
Eric Masson
"Eric" == Eric Belhomme writes:






Eric> Un système d'exploitation - quel qu'il soit - n'est _que_ ce
Eric> qu'on en fait. Dire que windows est plus ou moins sur que
Eric> gnu/linux qui est plus ou moins sur que openBSD n'a pas de sens,
Eric> car la sécurité d'un système est directement lié à la compétence
Eric> de son administrateur.

Donc si on conserve le contexte du fil, la réponse de Xavier est
parfaitement valide.

Le posteur initial annonce qu'il n'a aucune compétence et qu'il veut
mettre un serveur sur le net, donc en reprenant vos évaluations, vous
arriverez au résultat décrit par Xavier.

Maintenant il est toujours possible de sécuriser un système et le fait
que cela soit le métier d'une personne ne fait pas forcément de cette
personne quelqu'un de compétent.

J'ai vu chez un de mes clients un FW1 sur base NT qui générait lui même
du traffic netbios sur son interface reliée au routeur externe et encore
plus amusant, qui répondait aux requêtes venant de l'extérieur et cette
machine avait été installée par un professionnel de la profession.

Eric Masson

--
GA: pas assez convivial et surtout ce qui me gene le plus, c'est
GA: que linux c'est trop un systeme de droite.
HS: linux est en train d'etre récuperé politiquement par DL
-+- Hans in Guide du linuxien pervers : "ST serait il un virus ?" -+-





Avatar
Arnaud
"Arnaud" a écrit dans le message
de news:3fb12909$0$13273$
[...]
Merci de vos conseils en tout genre (liens vers des outils, des
articles, des ouvrages... Bref, tout ce qui peut m'aider !)


Bonsoir,

J'ai lu toutes vos réactions et je vous en remercie.

J'ai peut-être été un peu "léger" en annonçant que personne chez nous
s'y connaissait en sécurité. J'ai suivi une formation qui m'a donné
quelques bases (un dess à amiens :
http://www.isri.u-picardie.fr/index.phtml?e=1 (pour ceux que ça
intéresse !), ça vaut ce que ça vaut...)

Alors, concernant les diverses questions que j'ai pu voir, notre serveur
est en phase de test (on le connecte sur le monde extérieur que quand on
a besoin de vérifier quelque chose et pour le moment, aucune donnée
'sensible' ne s'y trouve...)
il tourne sous OpenBSD et à priori, ça a l'air d'être fiable...

En tout cas, merci de vos posts. Je regrette juste de n'avoir pas eu le
moindre lien ou la moindre bibliographie dans aucun de vos messages...
ça aurait pu me faire découvrir quelques trucs que je ne connaissais
pas... dommage !

Arnaud

1 2 3