Jean Segers wrote:
>
> Bonjour à tous,
>
> Tout d'abord, il est absolument exclus que je publie sur une liste de
> diffusion, qui de plus est archivée, un mode d'emploi détaillé pour
> craquer un serveur Linux.
> Ca serait pas "linuxement correct" et ca mettrais en péril bien des
> fournisseurs d'accès et/ou d'hébergement...
>
> Cependant, comprenant les questions qu'ont dû se poser les copains de
> cette liste suite à mon post, je vais donner quelques pistes et points
> faibles à surveiller de près. D'abord, j'expliquerai pourquoi freeBSD
> plutôt que Linux pour un serveur: la raison est simple, le noyau!
> Fondamentalement différent du noyau Linux, freeBSD (et toute la famille
> BSD d'ailleur) est conçu à la base pour remplir sa tâche, soit être un
> serveur. Il est donc optimisé et surtout sécurisé dans ce sens et
> comporte bien moins de "back orifices" exploitables par les crackers.
> Un autre avantage, et non des moindre, est la capacité de montée en
> charge des serveurs BSD face à Linux et donc, par exemple, le nombre de
> sites web dynamique cohébergeable sur une même machine avant qu'elle ne
> soit à genoux.
>
> La sécurité:
> Le premier daemon qui sera attaqué par un cracker sera le DNS. S'il ne
> représente pas trop de risque pour le serveur web lui-même (à condition
> d'être hébergé sur une machine dédiée bien évidemment), mal configuré il
> pourra être utilisé comme passerelle qui bouffera toute la bande
> passante de l'hébergeur pour une attaque type DOS vers d'autres victimes
> (Yahoo, Amazone par exemple, on a vu ca il y a peu)
> C'est arrivé il y a trois semaines chez http://www.cfr.fr où un port du
> serveur DNS dédié fut utilisé pour attaquer les serveurs Cobalt (qui
> sont patchés depuis) qui eux-même ont servi de passerelle (et
> d'anonymiseur) pour attaqué un autre service (Altavista)... Pourtant,
> suite à une audit commanditée par un de leur futur client, je les avais
> mis en garde: et je le jure, je ne suis pas l'auteur de cette attaque!
>
> Ensuite, le craker essayera dans l'ordre, après avoir "sniffé" vos
> installations, les ports des serveurs telnet, mail, ftp, real (hé oui),
> etc. toujours dans le but d'utiliser la bande passante. Dans le cas du
> serveur mail, il s'agit souvent d'un relaying de spamm massif.
> Et pour les administrateurs réseaux les plus inconscient, il reste les
> ports des serveurs X !!! et donc aussi les fontes, le son, etc, etc...
>
> Parlons maintenant des utilisateurs d'un serveur de cohébergement:
> donnez moi un accés telnet sur un serveur MDK de base, Y EN A POUR CINQ
> MINUTES!!!
> Et pour cause, presque toutes les infos nécessaires se trouve dans /etc
> qui est "world readable" ainsi que le sont la plupart des fichiers de
> config!!!
>
> Il appartient donc à l'administrateur de surveillé de très près les
> configurations ainsi que l'accès à certains logiciels installés en
> standard.
>
> Voilà, j'espère vous avoir entr-ouvert la porte, mais je n'irai pas plus
> loin car là c'est mon gagne pain, je suis ingénieur système.
> --
> Jean
Mwai,
Le problème des BSD c'est le manque de portage des applis
(pas ou peu de moteurs et de clients SGBD,
et je vous parle pas de la tête qu'a fait notre fournisseur d'onduleur
quand on lui a demandé
une solution d'extinction pour Open BSD !)
l'autre hic c'est le manque de robustesse du file system,
surtout vis à vis d'extinctions brutales.
En ce qui nous concerne on réserve BSD pour les firewalls
(qui ne laissent pas passer telnet ;-)
et on met du linux en serveur derrière.
mais si tu as des suggestions de sécu ou que tu pense
pouvoir réussir une intrusion,
mail moi directement, on peut discuter d'une prestation: [EMAIL PROTECTED]
(le site à sécuriser n'est pas celui de ma boite mais celui d'un client
;-)
