Le DOS de Bind n'est pas nouveau non plus, et est facile à reproduire meme sans nmap.
Voici ce qui se passe normalement :
- Un nouveau client arrive
- Bind accepte une connexion
- Bind regarde d'ou vient la connexion
...
- Le client coupe la connexion
Cependant, avec une durée de connexion très courte (par exemple lors d'un TCP scan avec Nmap), voici ce qui se passe :
- Le client se connecte
- Bind accepte la connexion
- Le client se deconnecte
- Bind regarde d'où vient la connexion, sans vérifier si elle est encore là
- Bind tente de répondre, alors que l'adresse du client mémorisée est n'importe quoi.
Ce n'est que la n-ieme preuve que Bind a été écrit n'importe comment, sans vérification élémentaire des erreurs. Déplorable pour un logiciel censé etre très stable.
Non le problème des performances concernait khttpd (l'actuel serveur web du noyau, livré en standard depuis les 2.3) qui se faisait battre par BOA pour les pages statiques.
Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.
Deux remarques cependant :
- BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
- Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.
Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
Non le problème des performances concernait khttpd (l'actuel serveur web du noyau, livré en standard depuis les 2.3) qui se faisait battre par BOA pour les pages statiques.
Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.
Deux remarques cependant :
- BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
- Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.
Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
Parser du HTML "à la mano" n'est pas forcément très fiable. Il suffit qu'un site ajoute un retour chariot pour les lignes trop longues, pour que le parser foire sur certaines news.
Et pour certains sites bourrés de tags identiques, mais dans des contextes différents, le parsage n'est pas évident.
Donc le mieux est de créer un arbre d'après le document HTML. En Perl, les modules XML::Driver::HTML et HTML::TreeBuilder sont géniaux pour ce genre d'opération.
En C, une interface SAX comme Gnome-XML (libxml) est aussi très pratique pour construire facilement cet arbre, à condition que le HTML ne soit pas trop pourri.
Va-y ! Prévoie juste un truc générique pour que ça puisse facilement s'adapter aux différents sites de news. Teste avec linuxfr, je m'occuperai des filtres pour les autres sites.
Le plus simple est à mon avis de passer par Gnome-XML pour parser les différents sites.
Le gros problème de cette appliquette vient du fait qu'elle ne va pas chercher les informations à la source (freshmeat, slashdot...) . Les news sont prises à une adresse inscrite en dur dans le code ("http://zion.kirowski.com/gnews/news.php3?idx="(...) suivie d'un nombre, correspondant à la news) .
Bref, il suffit que le site de l'auteur ne fonctionne plus pour que les news ne s'affichent plus.
Pire encore : si l'auteur trouve une faille de sécurité (introduite volontairement ou pas) dans l'appliquette, il a en sa possession toutes les adresses IP des clients qui l'utilisent, et peut donc faire joujou avec.
Bref, je vous déconseille fortement l'utilisation de Gnews dans l'état actuel des choses.
Il y a environ deux mois, j'ai reçu un coup de fil du boss d'une joyeuse start-up, dont j'ai oublié le nom, mais il se pourrait bien que ce soit eux. Cette joyeuse start-up travaillait en effet sur un project absolument identique à ce qui est rapporté dans cet article (basé sur le mpeg2, qualité mortelle à 2k, ...)
Ils avaient besoin de mon aide pour... coder un truc bidon ! Ils devaient en effet réaliser une démonstration de leur produit auprès de Sagem et de je ne sais plus qui histoire de gratter du pognon. Malheureusement, la démonstration devait avoir lieu une semaine plus tard et leur produit n'était pas au point, soit-disant qu'il ne manquait que le streaming.
Mais voici précisément ce qu'ils me demandaient de faire : reprendre un logiciel de streaming video quelconque en GPL, le trafiquer pour qu'on ne le reconnaisse pas, et leur livrer la chose à temps pour leur démonstration. Bref, une démonstration réalisée sur un réseau local, qui n'integre pas le moindre bit de leur super-vapour-codec. Mais le but était simplement de convaincre des commerciaux et journalistes crédules.
Ces rigolos proposaient meme 50 000 Frs (oui, pour 1 semaine de boulot) pour réaliser ce produit bidon. Mais j'ai préféré les envoyer bouler et garder la conscience tranquille. Quelqu'un d'autre a visiblement réagit différemment...
Ne me souvenant pas du nom exact de la société ni du bougre qui m'avait tenu la jambe au téléphone, je ne peux jurer qu'il s'agit des mêmes énergumenes que ceux cités dans l'article. Mais il y a vraiment trop de ressemblances flagrantes.
Le principal intéret de QNX est sa rapidité (on a l'impression que tout est immédiat, c'est assez impressionnant) et le fait que ce soit un micro-noyaux dont les modules sont minuscules et très ciblés. Pour des systèmes embarqués, c'est impeccable.
Et un kernel patché pour les temps de latence ne donne pas les memes fonctionnalités. QNX permet par exemple de faire communiquer différents modules au moyen de messages, dont l'interface est assez bien conçue. En gros, une fois qu'une application est écrite avec cette interface, et qu'elle fonctionne parfaitement sur ta machine locale, tu peux prendre chaque bout, les disperser sur différentes machines, et l'application tourne en distribué sans modification.
J'aime aussi beaucoup la gestion du filesystem, tu peux par exemple en une ligne de commande dire "/dev/lp0 c'est géré par le driver de port parallèle de telle machine distante". Hop, tes applications n'y voient que du feu, écrivent en /dev/lp0 pour imprimer, et sans se soucier de qui gère ce périphérique et comment.
Bah l'un des gros intéret de Perl est qu'il convient à tous.
On a envie de programmer "propre et structuré" ? On peut ! On veut du code bourrin ? On peut ! On aime la programmation objet ! On peut ! On déteste la programmation objet ? Pas grave !
Et pour ceux qui ne jurent que par Java, sachez qu'un compilateur Perl -> bytecode Java est en développement.
"Courrier" est une très bonne alternative, et est sous license GPL. Par contre je n'ai pas du tout confiance en la façon dont ça a été programmé, les auteurs ne se sont visiblement pas du tout souciés de la sécurité de leur code dès le départ. "Maildrop" était à lui seul un nid de buffer overflows, et "Courrier" a les mêmes lacunes. Ils ne se sont décidés que très récemment à corriger quelques sprintf/strcat/strcpy.
Qmail est nickel. Aucun problème de sécurité, très fiable, rapide, et une architecture à base de petits composants plutôt qu'une usine à gaz. Quasiment aucune contribution n'a été intégrée à la distribution officielle, il faut donc se préparer à patcher le source d'origine dans tous les sens si on souhaite en bénéficier. Mais on n'a pas forcément besoin des contributions.
Postfix... hum.... non, je n'ai pas envie d'utiliser un soft dont l'auteur n'arrete pas de se vanter, de se moquer hypocritement des autres logiciels pour promouvoir le sien, et de répondre "va t'acheter unix pour les nuls, connard" lorsque, sur la mailing-list, quelqu'un pose une question un peu trop basique à son goût.
Il reste aussi Zmailer, réputé pour sa rapidité, et Exim, une usine à gaz qui a connu quelques failles de sécurité, mais qui est GPL et a déjà largement fait ses preuves.
Oublie par contre "postaci", encore buggué et sur lequel un important overflow a été découvert hier.
Rassure-toi, je n'utilise pas le module Perligata, mais c'était un exemple pour montrer la souplesse de Perl par rapport à PHP qui serait bien en peine d'avoir un tel module.
Hum, cela dit mes sources en Perl sont peut-être illisibles malgré tout, preuve en est l'entrée "dlister" au concours Obfuscated Perl Programming Contest de cette année ( www.tpj.com ) .
Plutôt que de muscler leur configuration matérielle, pourquoi n'essaieraient-ils pas de remplacer leur bon vieux bind par djbdns ( voir http://www.tinydns.org(...) ) ?
Hum, oui, mais les sessions de PHP sont compatibles avec la quasi-totalité des serveurs web, pas ce module visiblement.
Il n'y a pas qu'Apache sous Linux...
- WN (http://www.wnserver.org(...)) est plus sécurisé (et possède des fonctionnalités intégrés intéressantes, comme un moteur de recherche)
- Roxen (http://www.roxen.com(...)) est très puissant, dispose d'une magnifique interface de configuration, se met à jour automatiquement par le net, et il existe de nombreux modules aussi originaux que pratiques, ainsi qu'un langage (RXML) simple et complet pour les pages dynamiques.
- WebFS (j'ai plus l'url en tete) et le serveur web du noyau Linux 2.4 (khttpd) sont parfaits pour les pages statiques.
- THttpd bat de loin tous ses concurrents... pour les trous de sécurité. Son principal argument concerne le throttling (limitation de bande passante pour chaque service) . Mais Roxen fait aussi ça à merveille, et propose meme d'affecter des priorités à tous les modules.
Hum, je commence a être fatigué, donc on va essayer d'etre concis.
Le principe est très simple : prenons deux machines. (C) étant le client à partir duquel on souhaite lancer "ssh" (ou scp, hsftp, etc...) . (S) est le serveur sur lequel on souhaite se connecter à l'aide du compte "plop".
On installe une clef publique sur (S), dans le compte "plop". En fait, on installe cette clef publique sur toutes les machines où l'on souhaite se connecter sans mot de passe à partir de (C) .
Pour que l'authentification réusisse, il suffit de posséder sur (C) la clef privée correspondant à la clef publique déposée sur les serveurs. Simple, non ?
Voici comment créer le couple clef publique à exporter/clef privée à conserver sur (C) :
ssh-keygen -d
Et c'est tout. On obtient en retour dans le répertoire ~/.ssh deux fichiers : id_dsa (clef privée : ne pas donner l'acces en lecture aux autres !), et id_dsa.pub (clef publique) .
Le contenu de id_dsa.pub est à copier sur (S) dans le fichier ~plop/.ssh/authorized_hosts2 (le 2 n'est pas une faute de frappe, c'est pour le protocole SSH 2) .
Et... c'est tout ! Dans le fichier authorized_hosts2 vous pouvez évidemment mettre plusieurs clefs privées, une par ligne.
Pour résumer :
ssh-keygen -d
scp .ssh/id_dsa plop@nom.du.serveur:.ssh/authorized_hosts2
(scp demande le mot de passe)
Et voilà. Les "scp" et "ssh" suivants ne vous demanderont plus de passe.
Attention : dans les fichiers sshd_config et ssh_config (en principe dans /usr/local/etc) vous devez avoir la ligne suivante :
[^] # Re: J'ai essayé...
Posté par j . En réponse à la dépêche Vulnerabilite ProFTPd/BSD FTPd. Évalué à 1.
Si tu n'as quasiment aucun répertoire dans ton FTP c'est normal que l'effet ne soit pas transcendant non plus.
[^] # Re: pub
Posté par j . En réponse à la dépêche Vulnerabilite ProFTPd/BSD FTPd. Évalué à 1.
Le FTP de Solaris et BeroFTPd se font avoir aussi...
C'est la fete.
# Bind...
Posté par j . En réponse à la dépêche Problèmes dans BIND et TCP. Évalué à 1.
Voici ce qui se passe normalement :
- Un nouveau client arrive
- Bind accepte une connexion
- Bind regarde d'ou vient la connexion
...
- Le client coupe la connexion
Cependant, avec une durée de connexion très courte (par exemple lors d'un TCP scan avec Nmap), voici ce qui se passe :
- Le client se connecte
- Bind accepte la connexion
- Le client se deconnecte
- Bind regarde d'où vient la connexion, sans vérifier si elle est encore là
- Bind tente de répondre, alors que l'adresse du client mémorisée est n'importe quoi.
Ce n'est que la n-ieme preuve que Bind a été écrit n'importe comment, sans vérification élémentaire des erreurs. Déplorable pour un logiciel censé etre très stable.
http://cr.yp.to(...) DJBdns n'est pas vulnérable à ce type d'attaque.
http://pureftpd.sourceforge.net(...) Pure-FTPd non plus :)
[^] # Re: dans la serie
Posté par j . En réponse à la dépêche Apache 1.3.19. Évalué à 1.
Et PureFTPd rulez ( http://pureftpd.sourceforge.net(...) ) .
[^] # Re: C'est pas chouette ça ?
Posté par j . En réponse à la dépêche Accédez gratuitement à IPv6 !. Évalué à 1.
# C'est pas chouette ça ?
Posté par j . En réponse à la dépêche Accédez gratuitement à IPv6 !. Évalué à 1.
1: lo: <LOOPBACK,UP> mtu 16144 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:80:ad:97:92:c8 brd ff:ff:ff:ff:ff:ff
inet 195.132.209.42/24 brd 195.132.209.255 scope global eth0
inet6 fe80::280:adff:fe97:92c8/10 scope link
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 100
link/ether 00:00:e8:e8:57:2f brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP,UP> mtu 1480 qdisc noqueue
link/sit 0.0.0.0 brd 0.0.0.0
inet6 ::195.132.209.42/96 scope global
inet6 ::127.0.0.1/96 scope host
5: sit1@NONE: <POINTOPOINT,NOARP,UP> mtu 1480 qdisc noqueue
link/sit 0.0.0.0 peer 64.71.128.26
inet6 fe80::c384:d13c/10 scope link
inet6 3ffe:1200:3028:ff01::75/127 scope global
-=[root@synchron]=(~)# ping6 3ffe:1200:3028:ff01::75 <(12:12:45)
PING 3ffe:1200:3028:ff01::75(3ffe:1200:3028:ff01::75) from ::1 : 56 data bytes
64 bytes from 3ffe:1200:3028:ff01::75: icmp_seq=0 hops=64 time=40 usec
64 bytes from 3ffe:1200:3028:ff01::75: icmp_seq=1 hops=64 time=38 usec
64 bytes from 3ffe:1200:3028:ff01::75: icmp_seq=2 hops=64 time=38 usec
64 bytes from 3ffe:1200:3028:ff01::75: icmp_seq=3 hops=64 time=39 usec
--- 3ffe:1200:3028:ff01::75 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/mdev = 0.038/0.038/0.040/0.007 ms
-=[root@synchron]=(~)# host -taaaa www.6bone.net <(12:13:02)
www.6bone.net is a nickname for 6bone.net
6bone.net IPv6 address 3ffe:b00:c18:1::10
6bone.net IPv6 address 3ffe:b00:c18:1::10
-=[root@synchron]=(~)# tracepath6 3ffe:b00:c18:1::10 <(12:14:12)
1?: [LOCALHOST] pmtu 1480
1: 3ffe:1200:3028:ff01::74 419.801ms
2: 3ffe:b00:c18::6a 568. 44ms
3: 3ffe:b00:c18:1::10 536.741ms reached
Resume: pmtu 1480 hops 3 back 3
[^] # Re: c'est bète comme choux....
Posté par j . En réponse à la dépêche Trou de sécurité dans SSH1. Évalué à 1.
http://pureftpd.sourceforge.net(...)
[^] # Re: Question ???
Posté par j . En réponse à la dépêche Le serveur WEB le plus rapide du monde. Évalué à 1.
[^] # Re: perfs
Posté par j . En réponse à la dépêche Le serveur WEB le plus rapide du monde. Évalué à 1.
Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.
Deux remarques cependant :
- BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
- Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.
Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
[^] # Re: perfs
Posté par j . En réponse à la dépêche Le serveur WEB le plus rapide du monde. Évalué à 1.
Un patch (en fait deux, le premier n'était pas bon) pour gérer le keepalive a été posté, et du coup le khttpd se révélait plus rapide, mais avec un temps de latence plus long.
Deux remarques cependant :
- BOA est vraiment destiné aux pages statiques et aux simples scripts CGI, il ne sait pas s'interfacer avec PHP par exemple, sans passer par l'interface CGI.
- Utiliser khttpd en combinaison avec un autre serveur (apache, roxen, thttpd, zeus...) n'est pas idiot, et contribue à réduire un peu la charge de la machine et l'occupation de la mémoire. On lance le serveur web sur un port alternative, comme 8080, et ktthpd sur le port 80. Quand il ne sait pas faire (ex: CGI, PHP, Perl...) il agit comme un petit proxy et passe la requete à l'autre serveur web.
Cela dit TUX est nettement plus performant et configurable, que ce soit pour les CGI ou les pages statiques.
# URL
Posté par j . En réponse à la dépêche Le serveur WEB le plus rapide du monde. Évalué à 1.
Enfin, la voici :
ftp://ftp.redhat.com/pub/redhat/tux/tux-2.0/(...)
[^] # Re: Mouais...
Posté par j . En réponse à la dépêche Les news de linuxfr sous gnome. Évalué à 1.
Et pour certains sites bourrés de tags identiques, mais dans des contextes différents, le parsage n'est pas évident.
Donc le mieux est de créer un arbre d'après le document HTML. En Perl, les modules XML::Driver::HTML et HTML::TreeBuilder sont géniaux pour ce genre d'opération.
En C, une interface SAX comme Gnome-XML (libxml) est aussi très pratique pour construire facilement cet arbre, à condition que le HTML ne soit pas trop pourri.
[^] # Re: Mouais...
Posté par j . En réponse à la dépêche Les news de linuxfr sous gnome. Évalué à 1.
Le plus simple est à mon avis de passer par Gnome-XML pour parser les différents sites.
# Mouais...
Posté par j . En réponse à la dépêche Les news de linuxfr sous gnome. Évalué à 1.
Bref, il suffit que le site de l'auteur ne fonctionne plus pour que les news ne s'affichent plus.
Pire encore : si l'auteur trouve une faille de sécurité (introduite volontairement ou pas) dans l'appliquette, il a en sa possession toutes les adresses IP des clients qui l'utilisent, et peut donc faire joujou avec.
Bref, je vous déconseille fortement l'utilisation de Gnews dans l'état actuel des choses.
-Jedi.
[^] # Re: Je vous sers une suze?... Non, un ricard!
Posté par j . En réponse à la dépêche SuSE 7.1 début février. Évalué à 1.
> Une bonne distro doit au moins respecter les standards...
Hem.... SuSE est au contraire la distribution qui a suivi le plus fidelement la LSB (linux standard base) .
# Pipo
Posté par j . En réponse à la dépêche Nouveau format de compression vidéo internet. Évalué à 5.
Ils avaient besoin de mon aide pour... coder un truc bidon ! Ils devaient en effet réaliser une démonstration de leur produit auprès de Sagem et de je ne sais plus qui histoire de gratter du pognon. Malheureusement, la démonstration devait avoir lieu une semaine plus tard et leur produit n'était pas au point, soit-disant qu'il ne manquait que le streaming.
Mais voici précisément ce qu'ils me demandaient de faire : reprendre un logiciel de streaming video quelconque en GPL, le trafiquer pour qu'on ne le reconnaisse pas, et leur livrer la chose à temps pour leur démonstration. Bref, une démonstration réalisée sur un réseau local, qui n'integre pas le moindre bit de leur super-vapour-codec. Mais le but était simplement de convaincre des commerciaux et journalistes crédules.
Ces rigolos proposaient meme 50 000 Frs (oui, pour 1 semaine de boulot) pour réaliser ce produit bidon. Mais j'ai préféré les envoyer bouler et garder la conscience tranquille. Quelqu'un d'autre a visiblement réagit différemment...
Ne me souvenant pas du nom exact de la société ni du bougre qui m'avait tenu la jambe au téléphone, je ne peux jurer qu'il s'agit des mêmes énergumenes que ceux cités dans l'article. Mais il y a vraiment trop de ressemblances flagrantes.
[^] # Re: Wow !
Posté par j . En réponse à la dépêche DNS dans les choux. Évalué à 1.
http://cr.yp.to(...)
Et pour la compilation :
make setup check
Quelles erreurs as-tu ?
[^] # Re: Une petite question et au lit
Posté par j . En réponse à la dépêche Le nouveau QNX est arrivé !. Évalué à 1.
Et un kernel patché pour les temps de latence ne donne pas les memes fonctionnalités. QNX permet par exemple de faire communiquer différents modules au moyen de messages, dont l'interface est assez bien conçue. En gros, une fois qu'une application est écrite avec cette interface, et qu'elle fonctionne parfaitement sur ta machine locale, tu peux prendre chaque bout, les disperser sur différentes machines, et l'application tourne en distribué sans modification.
J'aime aussi beaucoup la gestion du filesystem, tu peux par exemple en une ligne de commande dire "/dev/lp0 c'est géré par le driver de port parallèle de telle machine distante". Hop, tes applications n'y voient que du feu, écrivent en /dev/lp0 pour imprimer, et sans se soucier de qui gère ce périphérique et comment.
[^] # Re: Ah oui, là...
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
On a envie de programmer "propre et structuré" ? On peut ! On veut du code bourrin ? On peut ! On aime la programmation objet ! On peut ! On déteste la programmation objet ? Pas grave !
Et pour ceux qui ne jurent que par Java, sachez qu'un compilateur Perl -> bytecode Java est en développement.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
"Courrier" est une très bonne alternative, et est sous license GPL. Par contre je n'ai pas du tout confiance en la façon dont ça a été programmé, les auteurs ne se sont visiblement pas du tout souciés de la sécurité de leur code dès le départ. "Maildrop" était à lui seul un nid de buffer overflows, et "Courrier" a les mêmes lacunes. Ils ne se sont décidés que très récemment à corriger quelques sprintf/strcat/strcpy.
Qmail est nickel. Aucun problème de sécurité, très fiable, rapide, et une architecture à base de petits composants plutôt qu'une usine à gaz. Quasiment aucune contribution n'a été intégrée à la distribution officielle, il faut donc se préparer à patcher le source d'origine dans tous les sens si on souhaite en bénéficier. Mais on n'a pas forcément besoin des contributions.
Postfix... hum.... non, je n'ai pas envie d'utiliser un soft dont l'auteur n'arrete pas de se vanter, de se moquer hypocritement des autres logiciels pour promouvoir le sien, et de répondre "va t'acheter unix pour les nuls, connard" lorsque, sur la mailing-list, quelqu'un pose une question un peu trop basique à son goût.
Il reste aussi Zmailer, réputé pour sa rapidité, et Exim, une usine à gaz qui a connu quelques failles de sécurité, mais qui est GPL et a déjà largement fait ses preuves.
Oublie par contre "postaci", encore buggué et sur lequel un important overflow a été découvert hier.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
Hum, cela dit mes sources en Perl sont peut-être illisibles malgré tout, preuve en est l'entrée "dlister" au concours Obfuscated Perl Programming Contest de cette année ( www.tpj.com ) .
# Alternative...
Posté par j . En réponse à la dépêche DNS dans les choux. Évalué à 1.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
Il n'y a pas qu'Apache sous Linux...
- WN (http://www.wnserver.org(...)) est plus sécurisé (et possède des fonctionnalités intégrés intéressantes, comme un moteur de recherche)
- Roxen (http://www.roxen.com(...)) est très puissant, dispose d'une magnifique interface de configuration, se met à jour automatiquement par le net, et il existe de nombreux modules aussi originaux que pratiques, ainsi qu'un langage (RXML) simple et complet pour les pages dynamiques.
- WebFS (j'ai plus l'url en tete) et le serveur web du noyau Linux 2.4 (khttpd) sont parfaits pour les pages statiques.
- THttpd bat de loin tous ses concurrents... pour les trous de sécurité. Son principal argument concerne le throttling (limitation de bande passante pour chaque service) . Mais Roxen fait aussi ça à merveille, et propose meme d'affecter des priorités à tous les modules.
[^] # Re: Zont qu'à programmer en Java !
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
[^] # Re: Pure-FTPd
Posté par j . En réponse à la dépêche Un virus attaque les machines RedHat. Évalué à 1.
Le principe est très simple : prenons deux machines. (C) étant le client à partir duquel on souhaite lancer "ssh" (ou scp, hsftp, etc...) . (S) est le serveur sur lequel on souhaite se connecter à l'aide du compte "plop".
On installe une clef publique sur (S), dans le compte "plop". En fait, on installe cette clef publique sur toutes les machines où l'on souhaite se connecter sans mot de passe à partir de (C) .
Pour que l'authentification réusisse, il suffit de posséder sur (C) la clef privée correspondant à la clef publique déposée sur les serveurs. Simple, non ?
Voici comment créer le couple clef publique à exporter/clef privée à conserver sur (C) :
ssh-keygen -d
Et c'est tout. On obtient en retour dans le répertoire ~/.ssh deux fichiers : id_dsa (clef privée : ne pas donner l'acces en lecture aux autres !), et id_dsa.pub (clef publique) .
Le contenu de id_dsa.pub est à copier sur (S) dans le fichier ~plop/.ssh/authorized_hosts2 (le 2 n'est pas une faute de frappe, c'est pour le protocole SSH 2) .
Et... c'est tout ! Dans le fichier authorized_hosts2 vous pouvez évidemment mettre plusieurs clefs privées, une par ligne.
Pour résumer :
ssh-keygen -d
scp .ssh/id_dsa plop@nom.du.serveur:.ssh/authorized_hosts2
(scp demande le mot de passe)
Et voilà. Les "scp" et "ssh" suivants ne vous demanderont plus de passe.
Attention : dans les fichiers sshd_config et ssh_config (en principe dans /usr/local/etc) vous devez avoir la ligne suivante :
DSAAuthentication yes
Voilà !