Envoi de spam à partir d'un serveur, comment réagir ?

Posté par (page perso) . Édité par palm123, Nils Ratusznik et Benoît Sibaud. Modéré par Pierre Jarillon. Licence CC by-sa
Tags :
55
5
août
2015
Sécurité

Après l'article sur comment retrouver l'origine d'une attaque, nous allons voir aujourd'hui comment accueillir comme il se doit sur votre serveur un envoi de spam. Pour changer, on partira du principe que l'on est sur une Debian avec un postfix. Notre serveur s'appelle exemple.octopuce.fr, et notre site de référence installé sur ce serveur s'appelle exemple.com.

On partira aussi du principe que l'on n'aime pas beaucoup le spam… voire même qu'on lui mettrait bien un bon coup de clavier en pleine poire.

Sommaire

Au commencement était…

Une liste d'envoi de mails (mailq) qui se remplit beaucoup trop rapidement, on parle de plusieurs centaines, voire plusieurs milliers de mails en quelques minutes/heures (selon la technique que l'attaquant utilise). Vous pouvez voir en bas de cet article comment être alerté automatiquement.

On commence par regarder la liste d'attente des mails (mail queue) avec la commande mailq. La commande less est là pour éviter d'afficher plusieurs centaines de mails, on aura ainsi seulement les premiers de la liste :

mailq | less

Vous devriez voir une suite de blocs qui ressemble à ceci :

E35BA5318CA83     1389 Fri Jul 31 10:25:10  MAILER-DAEMON
(delivery temporarily suspended: connect to yahoo.com[63.250.192.45]:25: Connection refused)
                                         darcy.bolden75@yahoo.com

F21DC4093C551     1400 Fri Jul 31 09:36:40  MAILER-DAEMON
(delivery temporarily suspended: connect to yahoo.com[63.250.192.45]:25: Connection refused)
                                         nicki.forth76@yahoo.com

F125553301B52     1409 Fri Jul 31 18:15:21  MAILER-DAEMON
(delivery temporarily suspended: connect to yahoo.com[63.250.192.45]:25: Connection refused)
                                         renato_kalman62@yahoo.com

Détaillons le premier bloc :

  • E35BA5318CA83 correspond à l'ID du mail
  • et 1389 correspond à la taille du mail en octet
  • Fri Jul 31 10:25:10 correspond à la date de l'envoi (idéal pour le retrouver dans les logs ;-))
  • MAILER-DAEMON est l'expéditeur (peut être www-data, une adresse mail…)
  • delivery temporarily suspended explique pourquoi le mail est toujours là (dans notre cas, les serveurs de yahoo ne veulent pas de lui)
  • darcy.bolden75@yahoo.com représente le destinataire

Si ça ressemble à du spam, que ça a le goût du spam (et que ça tente de vous vendre du viagra…)…

Je choisis dans mon tas de mail celui avec l'ID B58B18A1C2140 et je "l'ouvre" avec la commande postcat (à noter que cette commande affiche par défaut la totalité du mail (header, body, envelope content) :

postcat -q B58B18A1C2140|less

Et voici le résultat :

*** ENVELOPE RECORDS deferred/B/B58B18A1C2140 ***
message_size:             826             195               1               0             826
message_arrival_time: Fri Jul 24 06:08:12 2015
create_time: Fri Jul 24 06:08:12 2015
named_attribute: rewrite_context=local
sender: mechant@exemple.octopuce.fr
*** MESSAGE CONTENTS deferred/B/B58B18A1C2140 ***
Received: by exemple.octopuce.fr (Postfix, from userid 2001)
    id B58B18A1C2140; Fri, 24 Jul 2015 06:08:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exemple.com;
    s=alternc; t=1437710892;
    bh=jovdSJ/Kn2/7639VFyVqNVkUC4F7d1BbnAP59auo7XI=;
    h=To:Subject:From:Reply-To:Date;
    b=EkH7RR1L6vi0gkvl/AXhJChbwtOvMTB6KFS/tuoxoo6+O3UINMgxpLqp45vY9E+ED
     Dl0rOINTF8YDAGFmv6VCU4SDt1FTmWyjcJyefj1Mc9wl3TGRQVPfUDkUhVrrDB3yau
     Boz8MjYyfBIz28gXWB680XdkC1E5LQwnsmmay//8=
To: anhselagiolong_2710@yahoo.com
Subject: RE:  Your Top Affordable Vagra solutions
X-PHP-Originating-Script: 2001:dir.php
From: "Melba Bauer" <melba_bauer@exemple.com>
Reply-To:"Melba Bauer" <melba_bauer@exemple.com>
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-RealFrom:
Message-Id: <20150724040812.B58B18A1C2140@exemple.octopuce.fr>
Date: Fri, 24 Jul 2015 06:08:12 +0200 (CEST)


<div>
Your Top Affordable Vagra solutions &ndash; <a href="http://strobeton.ru/assets/plugins/tinymce/jscripts/tiny_mce/plugins/contextmenu/defines.html">check it out</a>
</div>

*** HEADER EXTRACTED deferred/B/B58B18A1C2140 ***
named_attribute: encoding=8bit
original_recipient:
recipient: anhselagiolong_2710@yahoo.com
*** MESSAGE FILE END deferred/B/B58B18A1C2140 ***

Les points importants :

  • create_time: Fri Jul 24 06:08:12 2015 (date de création)
  • Received: by exemple.octopuce.fr (Postfix, from userid 2001) (reçu par)
  • sender: exemple@exemple.octopuce.fr (si c'est une de vos adresses mails qui existe réellement, c'est simple : changement de mot de passe immédiat).
  • X-PHP-Originating-Script: 2001:dir.php (origine de l'envoi (fichier vérolé, formulaire sans captcha…))

Et puis bon, celui là il est facile, il tente de nous vendre du viagra… je pouvais pas avoir plus stéréotypé comme exemple…

Viens, on joue à cache-cache \o/

À partir de là, la marche à suivre est la même que dans l'article "remonter une attaque avec les logs d'apache2". Nous allons commencer notre chasse dans le fichier /var/log/mail.log.

On commence par aller voir au moment de l'attaque :

astuce : / permet de faire une recherche dans less, comme par exemple 2015:06:0 si vous n'avez qu'une seule journée par fichier

less /var/log/mail.log

176.9.139.10 - - [24/Jul/2015:06:07:18 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 382 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 5
129.195.0.205 - - [24/Jul/2015:06:07:27 +0200] "GET /wp-includes/js/comment-reply.min.js?ver=4.1.4 HTTP/1.1" 304 - "-" "Mozilla/4.0 (compatible;)" 0
89.184.77.50 - - [24/Jul/2015:06:07:26 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 466 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 2
89.184.77.50 - - [24/Jul/2015:06:07:34 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 219 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 1
176.9.139.10 - - [24/Jul/2015:06:07:28 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 64 "-" "Mozilla
/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 10
89.184.77.50 - - [24/Jul/2015:06:07:41 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 541 "-" "Mozill
a/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 2
89.184.77.50 - - [24/Jul/2015:06:07:48 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 370 "-" "Mozill
a/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 1
176.9.139.10 - - [24/Jul/2015:06:08:12 +0200] "POST /wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php HTTP/1.1" 200 374 "-" "Mozill
a/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.7.6)" 9

oh bah si c'est [google analytics] ça doit pas être ça…

OU PAS ! Comme nous l'avions vu, nous recherchons des requêtes POST dans les logs, et là nous en avons une jolie fournée ! Les "pirates" étant des animaux fourbes et rusés, ils n'hésitent pas à mettre des faux noms, comme des fichiers wordpress dans l'arborescence d'un drupal…

Allons voir de plus près ce fichier !

less /var/www/alternc/m/monjolisite/wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php

On y trouve quelque chose comme ceci :

virus spotted

Et là, on appelle ça un fichier vérolé :]

Note : si vous n'avez que ça dans votre fichier, vous pouvez l'effacer directement après avoir remonté entièrement l'attaque. Si vous avez du code "valide" dans le fichier, vous pouvez enlever seulement la partie incompréhensible.

Juste pour savoir, j'ai eu combien de requêtes sur ce fichier depuis 4 jours ?

cat access-20150721.log access-20150722.log access-20150723.log access-20150724.log|grep -c "/wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php"
3204

Ah oui quand même… Et avec combien d'IPs différentes ?

cat access-20150721.log access-20150722.log access-20150723.log access-20150724.log|grep "/wp-content/plugins/wsanalytics-google-analytics-and-dashboards/images/dir.php"|awk '{print $1}'|sort -gu|wc -l
123

Comme vous vous en doutez, la "traque" ne s'arrête pas là. Je vous renvoie à l'article remonter une attaque avec les logs d'Apache2, vu que c'est là que ça va se passer. Je vous conseille de finir de trouver la faille avant de passer à la suite.

KILL EVERYTHING WITH FIRE

fire

Mais avant, on va quand même faire une sauvegarde, parce que l'on est jamais à l'abri d'une connerie… (la commande suivante vous permet de copier votre mailq dans le dossier /var/tmp/svg-mail) :

mkdir /var/tmp/svg-mail
rsync -avP /var/spool/mail/ /var/tmp/svg-mail

Reprenons notre lance-flammes. Comme vous l'avez vu au début de cet article, la commande mailq est assez verbeuse, et nous avons juste besoin de l'ID des mails pour les effacer. La commande qu'il nous faut est la suivante (en changeant MOTIF, bien entendu…):

mailq|grep MOTIF|awk '{print $1}'|postsuper -d -
  • mailq -> affiche la liste des mails en attente
  • grep MOTIF --> recherche les lignes avec le motif que nous voulons (ici ce serait MAILER-DAEMON)
  • awk '{print $1}' -> affiche la première partie de la ligne, ça correspond ici à l'ID des mails
  • postsuper -d - --> indique à la commande postsuper d'effacer (-d pour delete) les mails qu'on lui donne.

Et ça nous donnera quelque chose ressemblant à ceci :

mailq|grep MOTIF|awk '{print $1}'|postsuper -d -
[...]
postsuper: F21198830C2B1: removed
postsuper: F108B894D4171: removed
postsuper: F22718A48D820: removed
postsuper: F11EB8FB2A9E7: removed
postsuper: F02B78A14E94D: removed
postsuper: F0B5B8D42374F: removed
postsuper: F02BB8D422BEC: removed
postsuper: Deleted: 17047 messages

Spamhaus

Si votre serveur a envoyé (beaucoup) de spam, il est sans doute dans les listes de différents organismes (comme les RBL, pour Realtime blacklist), qui fournissent eux-mêmes des systèmes antispams. Les plus célèbres d'entre eux sont sans doute anti-abuse.org et spamhaus qui a le mérite (en plus de faire du très bon travail) d'avoir un site plutôt bien foutu, sur lequel on peut vérifier et débloquer son serveur s'il est considéré comme spammeur : spamhaus.org/lookup/.

Améliorons encore

Supervision

Il existe des outils pour vous aider à superviser et à vous alerter en cas de problèmes. Ils peuvent se présenter sous la forme de script "à la main" (merci stackoverflow). Des checks pour Nagios (que ce soit sur les RBLs) ou la taille de la mailq. On peut aussi parler de mailgraph et de pflogsumm.

À noter que anti-abuse.org fournit un service en ligne, rblmon.com qui peut vous alerter automatiquement quand une de vos IPs arrivent dans une RBL.

PHP / mail.log

Pour retrouver plus facilement les fichiers ayant servi à envoyer du spam, n'hésitez pas à les logger via l'option mail.log de votre php.ini :

vim /etc/php5/apache2/php.ini

## trouver la ligne "mail.log" et la compléter comme ceci :
mail.log = /var/log/mail.php.log

Puis on crée le fichier (n'hésitez pas à modifier les permissions si le coeur vous en dit):

touch /var/log/mail.php.log && chmod 777 /var/log/mail.php.log

SPF, DKIM et DMARC

Au fur et à mesure du temps, des techniques ont été inventées pour lutter contre le spam et authentifier les expéditeurs "légaux". On parle ici de 3 choses :

  • SPF, pour Sender Policy Framework,
  • DKIM pour DomainKeys Identified Mail,
  • DMARC pour Domain-based Message Authentication, Reporting and Conformance.

Je vous conseille vivement de les configurer sur vos serveurs de mails. Vous pouvez lire à ce sujet les articles de Steve Kemp.

Des outils le font par défaut, comme AlternC.

antivirus

Si vous avez un antivirus, par exemple ClamAV (idéalement en y ajoutant les signatures de maldet) sur votre serveur, il peut vous aider à (re)trouver des fichiers vérolés :

clamscan -ri /var/www/

/var/www/search.php: Php.Trojan.StopPost FOUND
/var/www/help.php: Php.Trojan.StopPost FOUND

----------- SCAN SUMMARY -----------
Known viruses: 3912137
Engine version: 0.98.5
Scanned directories: 550
Scanned files: 78469
Infected files: 2
Data scanned: 1382.68 MB
Data read: 1509.90 MB (ratio 0.92:1)
Time: 132.390 sec (2 m 12 s)
  • # hum

    Posté par . Évalué à -9.

    Quand je lis cela:

    sender: exemple@exemple.octopuce.fr (si c'est une de vos adresses mails qui existe réellement, c'est simple : changement de mot de passe immédiat

    Cela décribilise l'ensemble de l'article. On peut envoyer un mail avec n'importe quelle adresse émail. Jusqu'à preuve du contraire, je n'ai pas besoin de m'identifier pour envoyer un mail.

    • [^] # Re: hum

      Posté par . Évalué à 0.

      Euh… Non.

      Tu as des serveurs mail en open relay pour lesquelles tu ne dois pas t'identifier (typiquement ce que propose les fournisseurs internet quand tu es dans leur réseau).

      Si tu configures un serveur de cette manière, tu n'as pas à te tracasser du spam car tu en envois plein.

      Sinon tu ajoutes une identification avant l'envoi.

    • [^] # Re: hum

      Posté par . Évalué à 8.

      Si le serveur SMTP est correctement configuré, il est nécessaire de s'authentifier avant d'envoyer un mail.

      • [^] # Re: hum

        Posté par . Évalué à 8.

        Oui, sauf que l'exemple est mauvais. Ici il utilise une faille d'un site web, et envoie du spam. Typiquement, il se connecte au SMTP via localhost ou appelle directement la commande sendmail. Et généralement, il n'y a pas besoin d'authentification.

        De plus, tu peux aussi t'authentifier avec un compte et envoyer avec un From différent.

        Il est intéressant, pour trouver l'origine des spams d'avoir auparavant :
        - configuré ses sites pour que les scripts soient utilisés par un compte différent, par exemple php-fpm avec des pools ayant chacun un user différent
        - configuré son mailer pour qu'il ajoute dans les headers l'uid ayant invoqué sendmail
        - si mails entrants, configuré son mailer pour qu'il ajoute dans les headers le compte qui s'est authentifié.

        Le cas le plus délicat, est quand le site est hacké, mais envoie du spam directement sans passer par le mailer du système.

        • [^] # Re: hum

          Posté par . Évalué à 6.

          Attention, l'auteur du journal parle bien de la zone "sender", pas du "From" de l'entête de mail qui est effectivement libre.

          • [^] # Re: hum

            Posté par . Évalué à 1.

            Même la zone sender me semble fragile. En vérifiant dans des spams reçus, je dirais que c'est plutôt la zone Return-Path qui est la plus pertinente pour repérer le destinataire. C'est la première ligne des en-têtes qui sert à Bounce address ou plus complet : en anglais

            Elle correspond à envelope-from que l'on trouve dans les paramètres de Mutt par exemple ou « envelope from » du SMTP. Bien sûr ils peuvent tous être forcés mais un peu moins facilement à mon avis.

        • [^] # Re: hum

          Posté par . Évalué à 1.

          Ça s'appelle un serveur SMTP configuré avec les pieds.

          Sur mes serveurs, une authentification est nécessaire (ie: t'es qui pour vouloir m'utiliser pour envoyer des mails ?).
          Mais également, ce n'est pas parcque toi, grouillot, tu as un compte mail, que tu peux envoyer des mails from le boss.

          Pourquoi autoriserais-je cela ?

          Chaque utilisateur possède un compte, et les from autorisé sont déduis de ce compte et des alias en cours.

          Au final, il n'y a plus qu'une sorte de spammeur qui utilisent mes serveurs : c'est bob, from bob@machin, qui envoye de la merde. Et je sais qui est le coupable. C'est bob.

          Le problème du spam, c'est avant tout des serveurs SMTP débiles.

          • [^] # Re: hum

            Posté par . Évalué à 4.

            Tu fais exprès de pas comprendre ?
            Ou alors tes applis en php doivent s'authentifier aussi en localhost ?

            • [^] # Re: hum

              Posté par . Évalué à -2.

              Ben ouais, pourquoi ne le feraient-elles pas ?

              • [^] # Re: hum

                Posté par . Évalué à 4.

                Donc tu vas mettre dans le config.inc.php (ou équivalent) de ton CMS les identifiants SMTP.
                Ok, mais sachant que les pirates passent par ton CMS pour déposer leurs .php, ils pourraient très bien jeter un œil à ce fichier pour te voler les identifiants.

                • [^] # Re: hum

                  Posté par . Évalué à 3.

                  Aucune importance.
                  Je sais quel compte est utilisé (et je suis sûr que c'est lui).

                  Je peux donc, de source sûr, et que ce soit via php, d'autres site, ou des clients SMTP plus classique, trouver le coupable (ou a minima, le responsable), et le châtier.

                  De plus, il est impossible de faire du source spoofing : la page PHP de machin.fr peut envoyer des mails pour vendre du viagra .. from info@machin.fr uniquement.

                  • [^] # Re: hum

                    Posté par (page perso) . Évalué à 3.

                    De plus, il est impossible de faire du source spoofing : la page PHP de machin.fr peut envoyer des mails pour vendre du viagra .. from info@machin.fr uniquement.

                    J'ai pas trouvé d'exemple de configuration implémentant ça, je suis curieux d'en voir un.

                    Sinon, comment tu fais pour autoriser l'utilisateur example@example.net à envoyer des mails avec l'adresse support@example.net ou noc@example.net ?

                    • [^] # Re: hum

                      Posté par . Évalué à 4.

                      La conf postfix qui fait ça: smtpd_sender_login_maps
                      Dans ton smtpd_sender_restrictions, utilise reject_sender_login_mismatch

                      reject_sender_login_mismatch:
                      Reject the request when $smtpd_sender_login_maps specifies an owner for the MAIL FROM address, but the client is not (SASL) logged in as that MAIL FROM address owner; or when the client is (SASL) logged in, but the client login name doesn't own the MAIL FROM address according to $smtpd_sender_login_maps.
                      
                      
                      smtpd_sender_login_maps (default: empty)
                      Optional lookup table with the SASL login names that own sender (MAIL FROM) addresses.
                      
                      Specify zero or more "type:name" lookup tables, separated by whitespace or comma. Tables will be searched in the specified order until a match is found. With lookups from indexed files such as DB or DBM, or from networked tables such as NIS, LDAP or SQL, the following search operations are done with a sender address of user@domain:
                      
                      1) user@domain
                      This table lookup is always done and has the highest precedence.
                      2) user
                      This table lookup is done only when the domain part of the sender address matches $myorigin, $mydestination, $inet_interfaces or $proxy_interfaces.
                      3) @domain
                      This table lookup is done last and has the lowest precedence.
                      In all cases the result of table lookup must be either "not found" or a list of SASL login names separated by comma and/or whitespace.
                      
  • # Le probléme d'origine

    Posté par . Évalué à 10.

    Visiblement, le problème d'origine viens du fonctionnement des CMS utilisés qui nécessite des droits en écriture sur eux-même pour l'installation de divers thèmes et extentions. Ce qui permet a l'attaquant d'exploiter une faille du site web pour écrire la backdoor.

    • [^] # Re: Le probléme d'origine

      Posté par (page perso) . Évalué à 0.

      Oui mais d'un autre coté, il est souvent nécessaire d'avoir un répertoire de cache, donc avec l'accès en écriture.
      Au final, il sera toujours possible d'exploiter la faille en mettant le fichier dans ce répertoire.

      Sinon, rien n'empêche d'enlever l'écriture et de le remettre au moment des mises à jour/installations.

      • [^] # Re: Le probléme d'origine

        Posté par . Évalué à 6.

        Et la on se demande pourquoi le cache a besoin de stocker des fichiers exécutables…

        • [^] # Re: Le probléme d'origine

          Posté par . Évalué à 4. Dernière modification le 05/08/15 à 12:34.

          Et la on se demande pourquoi le cache a besoin de stocker des fichiers exécutables…

          Parce que dans le doute chmod -R 777 *

        • [^] # Re: Le probléme d'origine

          Posté par . Évalué à 4.

          Un script n'a pas besoin d'avoir les droits d'exécution. Un binaire non plus, remarquez.

          • [^] # Re: Le probléme d'origine

            Posté par (page perso) . Évalué à -1.

            Comment fais-tu pour le lancer s'il n'a pas les droits d'exécution ?
            Lancement direct = ça ne fonctionne pas
            Lancement via un autre programme = il faut une faille bien spécifique

            • [^] # Re: Le probléme d'origine

              Posté par . Évalué à 9.

              cp /bin/echo /tmp/echo
              chmod -x /tmp/echo
              /lib64/ld-linux-x86-64.so.2 /tmp/echo -e "bla\tbla"
              
              • [^] # Re: Le probléme d'origine

                Posté par (page perso) . Évalué à 10. Dernière modification le 07/08/15 à 08:52.

                Et pour un shell :

                $ ./coin.sh 
                pan
                $ chmod -x coin.sh 
                $ source coin.sh 
                pan
                $ sh coin.sh
                pan
              • [^] # Re: Le probléme d'origine

                Posté par (page perso) . Évalué à 2.

                Bah, non. Ta technique ne devrait pas marcher. As-tu au moins vérifié que ta point de montage /tmp était monté avec l’option « noexec » ?

                Dans le doute j’ai quand-même vérifié sur ma machine, en m’assurant que /tmp est en « noexec » :

                $ cp /bin/echo /tmp/echo
                $ chmod -x /tmp/echo
                $ /lib64/ld-linux-x86-64.so.2 /tmp/echo -e "bla\tbla"
                /tmp/echo: error while loading shared libraries: /tmp/echo: failed to map segment from shared object: Operation not permitted

                • [^] # Re: Le probléme d'origine

                  Posté par . Évalué à 5.

                  J'ai testé mon exemple sur un VPS qui n'a donc que le root en point de montage. Ça ne doit pas passé SElinux et autres sécurités ( à tester ).

                  Le but était surtout de démontrer que le droit d'exécution peut être outre-passé. Que le droit lecture suffit. De toute manière, dans le même genre, si on à le droit lecture, on peut recopier le fichier te lui donner le droit d'exécution.

                • [^] # Re: Le probléme d'origine

                  Posté par (page perso) . Évalué à 3.

                  Le montage en noexec était pas dans le cahier des charges.

                  • [^] # Re: Le probléme d'origine

                    Posté par (page perso) . Évalué à 1.

                    Bien vu, j’ai réagi trop vite à cause du /tmp, mais il n’est pas rare de trouver des répertoires d’installation de CMS qui ne sont pas montés en « noexec », donc le contournement via ld-linux-… fonctionne.

                    Raison de plus pour être paranoïaque sur une machine qui expose des services sur le grand Internet, ce ne sont pas les mécanismes de mitigation qui manquent avec Linux !

              • [^] # Re: Le probléme d'origine

                Posté par (page perso) . Évalué à 1.

                /lib64/ld-linux-x86-64.so.2 /tmp/echo -e "bla\tbla"

                Si tu es capable de lancer une commande abitraire (/lib64/ld-linux-x86-64.so.2) c'est que tu as accès au shell (même de manière indirecte). Donc c'est bien une faille spécifique.
                Et de toutes manières, une fois que tu as l'accès au shell, il est facile de modifier ce que tu veux.

                Donc la question est toujours : comment tu exécutes ton fichier sans le bit x depuis une page PHP moisies ?

            • [^] # Re: Le probléme d'origine

              Posté par . Évalué à 8.

              Lancement via un autre programme = il faut une faille bien spécifique

              Ou pas.
              http://0x90909090.blogspot.fr/2015/07/no-one-expect-command-execution.html
              En fait, plein de commandes permettent d'en exécuter d'autres, sans avoir besoin de faille.

    • [^] # Re: Le probléme d'origine

      Posté par . Évalué à 3.

      Sans oublier qu'il y a sans doute une faille dans la version installée du CMS, ou un mot de passe qui s'est envolé dans la nature. Il serait bon de remonter jusqu'à la mise en place de la backdoor pour savoir par quel moyen elle est arrivée là. Et bien entendu, s'arranger pour que ça n'arrive plus.

      • [^] # Re: Le probléme d'origine

        Posté par . Évalué à 3.

        Les failles sont listées dans les changelog des projets open-source, couplé à l'utilisation de CMS pas a jour fait forcement des ravages :p

        Des CMS comme DotClear sont utilisé par de nombreux non-informaticiens, qui vont décompresser via leur client FTP favoris puis ne jamais mettre a jour. Bonjour les problèmes…

        • [^] # Commentaire supprimé

          Posté par . Évalué à -10.

          Ce commentaire a été supprimé par l'équipe de modération.

          • [^] # Re: Le probléme d'origine

            Posté par . Évalué à 1.

            Tout aussi pratique que sous Windows…

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Commentaire supprimé

              Posté par . Évalué à -10.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: Le probléme d'origine

                Posté par . Évalué à 6. Dernière modification le 10/08/15 à 09:31.

                Ça fait au moins 15 ans que je fais ça en cliquant sur un icône et en tapant mon mot de passe une seule fois…

                Et en fait c'est pas que moi, mais tous les utilisateurs de distributions grand public.

                Franchement je me demande dans quel univers parallèle tu vis.

                Et depuis quand c'est centralisé sous windows ?!

                C'est bien pour y remédier que windows 10 introduit un gestionnaire de paquets !

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Commentaire supprimé

                  Posté par . Évalué à -10.

                  Ce commentaire a été supprimé par l'équipe de modération.

                • [^] # Re: Le probléme d'origine

                  Posté par . Évalué à 3.

                  Il parlait des installations hors gestionnaire de packages. S’il n’y a pas de package (.deb ou .rpm) fourni et c’est pas super simple pour le grand public.

                  Mais il est effectivement un peu hors sujet parce que le grand public il a pas besoin de faire des installations hors gestionnaire de packages :)

                  • [^] # Commentaire supprimé

                    Posté par . Évalué à -10. Dernière modification le 16/08/15 à 18:03.

                    Ce commentaire a été supprimé par l'équipe de modération.

                    • [^] # Re: Le probléme d'origine

                      Posté par . Évalué à 2. Dernière modification le 16/08/15 à 18:50.

                      applet meteo correcte: ppa (https://wiki.ubuntu.com/WeatherIndicator)

                      xfce4-weather-plugin dit bonjour.

                      (ceux de KDE sont biens aussi)
                      (et avant y'avait celui de KDE 4 sur les dépôts Ubuntu)

                      mudlet

                      dispose d'un PPA officiel : https://launchpad.net/~mudlet-makers/+archive/ubuntu/ppa

                      Drivers video efficace ?…..

                      Les drivers nvidia et intel sont très efficaces.

                      Bref, tu ne sais pas de quoi tu parles.

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Commentaire supprimé

                        Posté par . Évalué à -10. Dernière modification le 17/08/15 à 00:54.

                        Ce commentaire a été supprimé par l'équipe de modération.

                    • [^] # Re: Le probléme d'origine

                      Posté par . Évalué à 5.

                      Ajouter un PPA Officiel c’est pas forcément M. Michu compliant mais l’installation de certains trucs sous Windows ou Mac ne le sont pas pas plus. C’est pour ça qu’on a des professionnels, des cours d’informatique et « le neveu qui s’y connaît »…

                      [mylife]
                      J’ai un pote qui a récupéré le « vieux » Mac de son grand frère. Ses parents un jour on voulu lui offrir un disque dur externe. Ils lui offrent le disque… Flûte il marche pas ! Ah bin oui, sur la boîte ya écrit « Compatible Windows », vous êtes cons Papa, Maman, j’ai un Mac moi :( C’est pas grave fiston, on va aller au magasin pour l’échanger et en prendre un où il y a écrit « Compatible Windows et Mac ». Ce qu’ils ont fait. Et c’est là que mon pote m’appelle : « ouai le disque il marche pas :( » Il me raconte ce que je viens de vous raconter… Bah oui ce disque il était formaté en NTFS… (tout comme le premier vous vous en doutez…). N’y connaissant pas grand chose au Mac et au format de partoche utilisé et ayant conscience que son DD il voudrait l’utiliser sur son Mac mais aussi sur l’ordi des potes j’ai cherché comment faire lire du NTFS à un Mac… Pour un informaticien comme moi je dois dire que ce fût assez facile, il suffit d’installer le logiciel qui va bien (qui est d’ailleurs le même que celui utilisé sous GNU/Linux pour lire le NTFS), vraiment rien de bien compliqué… Pourtant il est bien clair que si tu n’as pas la notion de « système de fichiers » et qu’a fortiori tu ne sais pas qu’il en existe plusieurs…
                      [/mylife]

                      Pour reprendre ton exemple d’applet météo, tu penses vraiment que l’utilisateur de base fait un comparatif des applet météo et cherche à installer celle qui roxe du poney ? Bah non, il utilise celle fournie… S’il est sous Ubuntu il utilise celle du gestionnaire de package, s’il est sous Windows il utilise celle déjà installée sous Windows…

                      Bon, pour Skype là je m’incline, effectivement ça pue côté Linux :( J’espère que le Hello de Firefox va prendre, si Google fout un truc compatible dans Chrome (et ils ont tout intérêt à le faire pour contre Microsoft sur ce terrain…) les choses pourraient bien changer rapidement…

                    • [^] # Re: Le probléme d'origine

                      Posté par . Évalué à 3.

                      Je ne connaissais pas mudlet…

                      Un « MUD client » : grand public, vraiment ?

                      Je ne connais pas l’univers des gamers (mais pour moi un gamer fait effectivement partie de ce grand public), m’enfin ce truc là c’est vraiment super répandu parmi les joueurs ?

                      • [^] # Commentaire supprimé

                        Posté par . Évalué à -10. Dernière modification le 17/08/15 à 08:50.

                        Ce commentaire a été supprimé par l'équipe de modération.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à 2. Dernière modification le 17/08/15 à 08:51.

                          Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: Le probléme d'origine

              Posté par (page perso) . Évalué à -1. Dernière modification le 10/08/15 à 09:57.

              Windows a une part de marché correcte, tout comme Mac OS, Android, iOS, ça OK.
              Linux, c'est déjà pas beaucoup, mais ensuite un truc pour Debian ne marche pas pour Fedora, et compagne…

              Faudra un jour arrêter de (se) mentir sur la praticité hors gestionnaire paquet Linux, la réalité frappe en permanence les développeurs.

              • [^] # Re: Le probléme d'origine

                Posté par . Évalué à 2.

                Que ce soit Windows 10 avec son gestionnaire de paquets, ou n'importe quel distribution Linux, si c'est pas sur les dépôts/stores, la mise à jour devient plus problématique.

                Pendant longtemps sous Windows, il fallait mettre à jour chaque application une à une, et je doute que ça change de sitôt avec Windows 10 (le pois de l'existant).

                Bref, dire que Windows est plus pratique à ce niveau là (regarde le post auquel je réponds, ça t'évitera de répondre à côté la prochaine fois), c'est juste un mensonge.

                "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                • [^] # Re: Le probléme d'origine

                  Posté par (page perso) . Évalué à -2. Dernière modification le 10/08/15 à 15:59.

                  tu n'as pas compris : part de marché.
                  Les développeurs diffusent pour Windows (avec un peu de chance, Mac aussi). Ils font le taf.
                  Linux, c'est tellement la merde (un .deb ne va pas passer sur Fedora, vice-versa, une version pour Debian 6 va crasher sous Debian 8 car une lib aura été enlevée…) et c'est tellement explosé comme part de marché que les développeurs ne font pas.

                  D'un côté, l’utilisateur a un installeur, pas de l'autre.
                  D'où le "arrête de te mentir sur Linux aussi pratique que Windows" : non, ça ne l'est pas, tout simplement car sorti du repo, c'est "démerde-toi, c'est trop chiant à faire le packaging pour ta distro qui a si peu de monde".
                  Et c'est ça qu'il faudra se mettre dans la tête : quand on est petit, on évite d'encore plus diviser, à défaut pas l'utilisateur n'a rien (il doit prier pour avoir le logiciel dans le repo, et pas avec une version d'il y a 3 ans), et c'est aussi pour ça que des OS pour particuliers marchent (Win, Mac, iOS, Android) et pas d'autres (Linux desktop par exemple)

                  • [^] # Re: Le probléme d'origine

                    Posté par . Évalué à 2. Dernière modification le 10/08/15 à 16:39.

                    "arrête de te mentir sur Linux aussi pratique que Windows"

                    Le truc, c'est que tu es hors sujet.

                    Je répondais à un post qui prétendait que Linux n'avait aucun moyen de tout mettre à jour en une seule fois. Or, ça fait 20 ans que ça existe, ça s'appelle un couple gestionnaire de paquets + dépôts.

                    Quant au reste de ton poste, Windows gagne d'abord parce qu'il est préinstallé depuis 20 ans. Le reste, c'est des détails d'implémentation dont l'impportance est ridiculement petite face à un avantage aussi massif et utilisé constamment depuis 20 ans (et tout ce qui en découle : support matériel meilleur, plus d'applications, etc. …).

                    Le nerf de la guerre, ce n'est pas la stabilité de l'ABI, la diversité des distros, ou je ne sais quoi. Une ABI stable, c'est très bien,, mais ça changera pas grand chose aux parts de marché.

                    "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                    • [^] # Re: Le probléme d'origine

                      Posté par (page perso) . Évalué à -2.

                      Le truc, c'est que tu es hors sujet.

                      Tu répondais à "Faut dire c'est super pratique les mises a jour hors gestionnaire de paquet sous linux….", j'ai répondu dans le sujet.

                      Je répondais à un post qui prétendait que Linux n'avait aucun moyen de tout mettre à jour en une seule fois.

                      Non.

                      Une ABI stable, c'est très bien,, mais ça changera pas grand chose aux parts de marché.

                      Ca fait que les développeurs apprécient, ça fait boule de neige.
                      Ho que si c'est important, et c'est bien pour ça que MS, Appl, Google… Gardent leur API longtemps.
                      tu crois sérieusement que Windows resterait aussi implanté si MS cassait les API toutes les versions?

                      • [^] # Re: Le probléme d'origine

                        Posté par . Évalué à 2.

                        tu crois sérieusement que Windows resterait aussi implanté si MS cassait les API toutes les versions?

                        Non, mais je sais que Windows s'est imposé via la vente liée d'abord, et une ABI stable ENSUITE, pas l'inverse !

                        Non

                        Bah si.

                        Ca fait que les développeurs apprécient, ça fait boule de neige.

                        T'auras peut-être plus de développeurs, mais pas beaucoup plus de parts de marché.

                        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                        • [^] # Re: Le probléme d'origine

                          Posté par . Évalué à 3.

                          T'auras peut-être plus de développeurs, mais pas beaucoup plus de parts de marché.

                          Ben c'est un peu un cercle vicieux/vertueux. Si t'as pas de développeurs, t'as pas d'appli sympa. Si t'as pas d'appli sympas, t'as pas de clients. Pas de clients pas de parts de marché. Pas de parts de marché, pas de développeurs… Bref.

                          Ce n'est pour rien qu'Apple, MS et Google ont fait la danse du ventre aux développeurs pour les encourager à développer sur leurs plateformes mobiles où l'on partait de rien.
                          Faut bien commencer quelque part.

                          • [^] # Re: Le probléme d'origine

                            Posté par . Évalué à 3.

                            Android s'est imposé via la vente liée sur des milliers de devices.

                            Windows, pareil.

                            La danse du ventre pour qu'on vienne développer chez toi, c'est quand tu as pas de vente liée, et pas de part de marché.

                            C'est long, et à la fin, Android domine toujours. ;-)

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: Le probléme d'origine

                              Posté par . Évalué à 5.

                              C'est long, et à la fin, Android domine toujours. ;-)

                              La réalité est beaucoup moins rose que ça en fait.
                              En gros, Android c'est bien en nombre d'utilisateurs, mais si tu veux gagner de l'argent, faut faire de l'iOS. Si je me rappelle bien et groumly< me fouettera si c'est faux mais l'ordre de grandeur, iOS c'est 20% de PDM en nombre de smartphones pour 80% des bénéfices.

                              • [^] # Re: Le probléme d'origine

                                Posté par (page perso) . Évalué à 4.

                                J'ai vu que des « jeux gratuits pour votre smartphone » passent en publicité à la télévision.
                                Vu le coût de ces publicité, je suppose qu'Android génère tout de même un bon paquet de fric.

                        • [^] # Commentaire supprimé

                          Posté par . Évalué à -8.

                          Ce commentaire a été supprimé par l'équipe de modération.

                          • [^] # Re: Le probléme d'origine

                            Posté par . Évalué à 3.

                            Oui et ?

                            Il n'empêche qu'il s'est vraiment imposé à partir du moment où il était en vente liée.

                            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                            • [^] # Re: Le probléme d'origine

                              Posté par (page perso) . Évalué à 2.

                              J'ai le souvenir que MS-DOS et Windows était déjà les standards de facto en 1990, pourtant il fallait les acheter à part.
                              La vente liée à vraiment débuté vers 1995 je pense (quelqu'un a de meilleurs souvenirs ou sources ?). En 1995 les gens achetait pas mal de machines assemblées, donc pas de vente liée. De toutes manières il n'y avait que Windows d'utilisable, donc vente liée ou pas c'était kif-kif : OS/2 Warp qui était très très très prometteur a été coulé par les mauvaises manœuvres d'IBM (en gros c'est mieux que Windows, donc on le vend plus cher. Résultat = 0% de parts de marché), et il n'y avait pas d'autres concurrents crédibles.

                              • [^] # Re: Le probléme d'origine

                                Posté par . Évalué à 3.

                                En 1995 les gens achetait pas mal de machines assemblées, donc pas de vente liée.

                                Source ? Parce que cela me semble suggestif. Je pourrais aussi affirmer « pas mal de gens achetaient des machines de constructeurs ». À l’époque pré 95 l’OS n’était peut-être pas souvent pré-installé mais les disquettes (de MS-DOS) étaient dans le carton avec la machine, vu que la machine ne sert strictement à rien sans un OS.

                                OS/2 Warp qui était très très très prometteur a été coulé par les mauvaises manœuvres d'IBM (en gros c'est mieux que Windows, donc on le vend plus cher. Résultat = 0% de parts de marché)

                                Certainement. Tout comme Digital Research avec CP/M un peu plus d’une dizaine d’années auparavant…

                                • [^] # Re: Le probléme d'origine

                                  Posté par (page perso) . Évalué à 3.

                                  Source ?

                                  Je bossais chez un « semi-grossiste » informatique, qui avait aussi une boutique.
                                  Les demandes était quasi-uniquement pour de l'assemblé.
                                  Et chez les gens et les artisants, on ne voyait presque que de l'assemblé. Les collèges, lycées, IUT et facs que j'ai connu étaient également en assemblés (de mémoire).
                                  En entreprise plus grosse c'était Dell, IBM, et compagnie. Remarque c'était peut-être déjà plus que 50% des parts de marché.

                                  Mais dans tous les cas il n'y avait rien d'autre que Windows qui soit convaincant, donc vente liée ou pas ça ne changeait rien.

                                  Tout comme Digital Research avec CP/M un peu plus d’une dizaine d’années auparavant

                                  Je ne connais pas l'histoire de CP/M. Je l'ai utilisé mais c'est tout.

                                  Par contre Digital Research a sorti l'excellent DR-DOS, mais qui n'a pas fait le poids commercialement devant MS-DOS.
                                  Lorsqu'on est challenger, on ne peut clairement pas appliquer les mêmes tarifs, méthodes de communication, etc, que le premier. Donc disparition aussi.

                                  • [^] # Re: Le probléme d'origine

                                    Posté par (page perso) . Évalué à 2.

                                    Tu peux arrêter de réinventer l'histoire un moment ?
                                    La chute de DR-DOS n'est pas due à son poids commercial mais au fait que windows 3.xx faisait exprès d’afficher un faux message d'erreur si le DOS présent n´était pas estampillé M$. Du coup les gens rejetaient la faute sur DR-DOS.
                                    La chute d'OS/2 (projet commun IBM et M$) est surtout due au fait que M$ à fait semblant de bosser en n'y affectant un seul ingé sur les 40 financés, les 39 autres repompant/imitant tout ce qui était possible pour le projet Chicago.
                                    Il me semble même qu'il y a eu des actions de justice pour ces histoires.

                                    • [^] # Re: Le probléme d'origine

                                      Posté par (page perso) . Évalué à 2.

                                      La chute de DR-DOS n'est pas due à son poids commercial

                                      Le poids commercial de qui/quoi ?
                                      J'ai écrit que DR-DOS n'a pas fait le poids commercialement devant MS-DOS = DR-DOS s'est beaucoup moins bien vendu.
                                      Je précise « commercialement » car il faisait très largement le poids techniquement. Microsoft était très à la traîne.

                                      windows 3.xx faisait exprès d’afficher un faux message d'erreur si le DOS présent n´était pas estampillé M$

                                      J'avais DR-DOS + Windows 3.xx et je n'ai jamais eu cela.
                                      Une rapide recherche avec ton ami Google m'indique qu'aucun Windows commercialisé n'a eu ce faux message d'erreur. Uniquement une béta.
                                      https://en.wikipedia.org/wiki/AARD_code

                                      La chute d'OS/2 (projet commun IBM et M$) est surtout due au fait que M$ à fait semblant de bosser en n'y affectant un seul ingé sur les 40 financés, les 39 autres repompant/imitant tout ce qui était possible pour le projet Chicago.

                                      La triche Le comportement habituel de Microsoft n'est pas la cause de l'échec d'OS/2. IBM était déjà très à la traine avant cet accord (c'est d'ailleurs pour cela qu'il y a eu l'accord).

                                      IBM a réussi à sortir un excellent système (OS/2 Warp) plusieurs mois avant que Microsoft ne sorte Windows 95. Ils ont décidé qu'il était possible de l'utiliser gratuitement pendant quelques mois, pour ensuite le vendre bien plus cher que Windows. Qui va acheter plus cher pour un truc qui fait la même chose ? Même si techniquement c'est mieux, encore que ce point soit discutable car il était critiqué pour être moche, et je me souviens que c'était le cas :-)

                                      Les magasines de l'époque parlaient pas mal d'OS/2 Warp, donc la communication d'IBM a bien fonctionné aussi, bingo. Tout le monde pensait qu'il allait continuer à être gratuit afin de gagner de grosses parts de marché.
                                      Lorsqu'IBM a finalement fait payer OS/2 Warp, je suppose que ça a été terminé en 2 mois (c'était pile au moment où Windows 95 sortait).

                          • [^] # Re: Le probléme d'origine

                            Posté par . Évalué à 3. Dernière modification le 13/08/15 à 01:17.

                            Il me semble que la vente liée date de MS-DOS… Ce n’est pas très clair toute cette histoire mais la manœuvre de Bill Gates pour imposer l’OS de sa compagnie montre qu’il devait avoir bien saisi l’importance de la vente liée pour parvenir à être en position de monopole.

                            https://fr.wikipedia.org/wiki/Gary_Kildall#Le_.22contrat_du_si.C3.A8cle.22_avec_IBM

                            Après la sortie de l'IBM PC, Gary Kildall constata que MS-DOS était un plagiat de CP/M. Il menaça alors IBM d'un procès. IBM trouva alors l'accord suivant : l'acheteur de l'IBM PC pourra choisir d'installer soit MS-DOS soit CP/M sur sa machine. Hélas, MS-DOS était vendu à 40$ alors que CP/M était vendu à 240$ : le choix de l'utilisateur moyen était vite fait…

                            Gary Kildall a peut-être à ce moment là fait un mauvais choix en alignant pas le prix de CP/M sur celui de MS-DOS mais quoi qu’il en soit, de par le fait c’est MS-DOS qui allait très vite se retrouver pré-installé sur tous les Compatible PC…

                    • [^] # Re: Le probléme d'origine

                      Posté par . Évalué à 6.

                      Je répondais à un post qui prétendait que Linux n'avait aucun moyen de tout mettre à jour en une seule fois. Or, ça fait 20 ans que ça existe, ça s'appelle un couple gestionnaire de paquets + dépôts.

                      Il me semble que ce thread discute de la pénibilité pour un utilisateur comme un développeur de mettre à jour une application dans une distrib en dehors d'un gestionnaire de package. Qu'on puisse mettre à jour sa distrib via un apt-get update+upgrade en utilisant son gestionnaire est un fait mais n'est pas le sujet.

                      Le problème, quand on écrit "Or, ça fait 20 ans que ça existe, ça s'appelle un couple gestionnaire de paquets + dépôts.", c'est que c'est peut-être vrai, mais ça nécessite :
                      1 - d'avoir un packageur pour chaque distrib (si on compte les distribs majeures, ça en fait au moins 5, sans compter les parfums)
                      2 - d'être accepté par la distrib (problématiques possibles d'ego, de compatibilité de licence, de brevets machin toussa), d'un dépôt parallèle connu ou de faire son équivalent PPA perso avec le site d'explications qui va bien autour.

                      C'est très très lourd. Du coup ça peut être fait (genre pour virtualbox) ou pas. Du coup, quand on doit installer ou mettre un jour un soft hors distrib, ça donne au choix :
                      1-targz autoporteur genre firefox
                      2-targz de sources
                      3-un script shell qui embarque une archive qui est elle-même décompressée sur acceptation d'une licence.
                      4-d'autres solutions créatives toutes pourrites à base de copier collage qui finissent par un wget | sh

                      Sous Windows, ben les développeurs se démerdent parfois/souvent (mais c'est vrai pas dans tous les cas, et ce n'est pas centralisé) pour faire des trucs qui se mettent à jour tout seul, mais de toute façon, ils mettent à disposition un installateur qui marche sur à peu près tout depuis Windows XP à Windows 10.

                      Le fait de passer par des stores à la MS, Apple ou Google permet de régler les problèmes propres à Windows.

                      Chaque solution a ses avantages et ses inconvénients. Mais force est de constater que sous Linux quand tu es en dehors du gestionnaire de packages, c'est rapidement chiant.

                      Ce qui est étonnant c'est que ce débat revienne environ tous les 3 mois.

        • [^] # Re: Le probléme d'origine

          Posté par (page perso) . Évalué à 3.

          Des CMS comme DotClear sont utilisé par de nombreux non-informaticiens, qui vont décompresser via leur client FTP favoris puis ne jamais mettre a jour. Bonjour les problèmes

          Beaucoup de CMS ont maintenant des mises à jour en un clic ;) c'est le cas pour dotclear par exemple

          • [^] # Re: Le probléme d'origine

            Posté par (page perso) . Évalué à 0.

            Beaucoup de CMS ont maintenant des mises à jour auto ;) c'est le cas pour wordpress par exemple.
            nan, parce que les mises à jour en un clic, on sait tous que les gens ne le font pas et que c'est le meilleur moyen d'avoir la moité des installs trouées.

            Le monde évolue, les mises à jour en un clic (ou plus compliqué) devraient appartenir au passé.

            • [^] # Commentaire supprimé

              Posté par . Évalué à -10. Dernière modification le 08/08/15 à 16:16.

              Ce commentaire a été supprimé par l'équipe de modération.

              • [^] # Re: Le probléme d'origine

                Posté par (page perso) . Évalué à 8.

                la pire connerie de li(n)ux, c'est a dire le manager de paquet

                Soit tu es un génie incompris. Soit tu es un crétin total.
                Je ne vois aucune possibilité entre les deux.

                Peux-tu donner des arguments pour faire comprendre que les gestionnaires de paquet sont une erreur ?

                • [^] # Commentaire supprimé

                  Posté par . Évalué à -10. Dernière modification le 09/08/15 à 01:02.

                  Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: Le probléme d'origine

                    Posté par (page perso) . Évalué à 8.

                    Ce que je comprends de tes arguments, c'est que tu estimes qu'il est problématique de faire confiance à quelques personnes pour gérer les mises à jour. C'est à peu près cela ?
                    Personnellement, je trouve cela très bien. Pas parfait, mais globalement bien mieux que si je devais tout me farcir moi-même.

                    Que proposes-tu de mieux ?
                    Tout faire à la mimine ?
                    Que les logiciels se mettent à jour tous seuls (comme Firefox sous Windows) ?

                    Si il n'y avait pas de stores jusqua present, c'est parce que c'etait un systeme merdique de base

                    L'idée des stores est bien antérieur à l'internet de masse. Au début c'était des entreprises de commande par correspondance. Même principe, mais avec les moyens de l'époque.
                    L'internet, sa consommation de masse, et le poids des géants ont rendu possibles les stores actuels. Dont le but est effectivement de gagner de l'argent. Tu penses que ça devrait avoir un but humanitaire ?

                  • [^] # Re: Le probléme d'origine

                    Posté par (page perso) . Évalué à 3. Dernière modification le 09/08/15 à 08:15.

                    Le cretin total t'emmerde.

                    Au moins tu n'oses pas affirmer être un génie incompris…

                    Ils passent d'un modele economique a un autre pour assurer des revenus permanent. Et pas parce que c'est une bonne idee.

                    Et comme tu n'es pas un génie incompris, tu n'as rien comme idée pour proposer mieux.

                    En attendant, un modèle économique est utile si on veut que les utilisateurs utilisent, sinon on se retrouve avec Debian qui est pas mal mais n'est que peu utilisé dans le monde réel (à part quelques admins de serveur et quelques geeks, pas foule, et après on a Ubuntu et Linux Mint mais qui ont aussi une tentative de modèle économique pour pouvoir proposer encore plus ensuite).

                    L'histoire de Windows qui n'avait pas de gestionnaire de paquet, ça va appartenir de plus en plus au passé, pour une raison toute simple : non, pas "faire banker", mais surtout que ce modèle ne marche plus avec les utilisateurs qui ne sont plus de passionnés, mais des gens qui veulent trouver facilement et que ça marche, tout simplement.

                    Maintenant, le jour où un génie incompris arrive à proposer quelque chose de mieux, ce sera utilisé, je n'en doute pas.

                    • [^] # Commentaire supprimé

                      Posté par . Évalué à -10. Dernière modification le 10/08/15 à 09:21.

                      Ce commentaire a été supprimé par l'équipe de modération.

                      • [^] # Re: Le probléme d'origine

                        Posté par (page perso) . Évalué à -1.

                        Le modèle actuel fonctionne très bien.

                        Il marche tellement bien que personne y reste.

                        Le monde change, avec des utilisateurs ayant grandi (et leur nombre augmenté, pour passer des quelques geeks aimant la souffrance technique à des utilisateurs) et n'ayant plus du tout envie de s'emmerder à faire les choses à la main.

                        Le problème est sans doute que le monde change. tu peux rester dans le "modèle actuel", il n'est pas enlevé, donc pourquoi te plaindre? Toi tu es content, les autres le sont aussi avec le nouveau modèle, tout va pour tout le monde!

  • # euh et mettre un filtre antispam ?

    Posté par . Évalué à 1.

    un outil qui aurait aussi son utilité pour améliorer c'est simplement un filtre antispam comme spamassassin par exemple.
    http://spamassassin.apache.org/

    il se base sur des règles publiques et privées qu'il applique sur le mail. C'est de l'analyse de contenue.

    Cela ralentie les mails queues mais bon si tu ne route pas des millions d'email, il n'y aura pas de problème.
    Par contre, pas d'analyse comportementale comme nos amis de gmail.

    Aussi, paramétrer postfix pour interroger les blacklists.

    Euh sinon, yahoo peut aussi bloquer les email pour des raisons de throtling (limitation de nombre de mail par heure) De mémoire, je crois que c'est 50 000/h.

    • [^] # Re: euh et mettre un filtre antispam ?

      Posté par (page perso) . Évalué à -1.

      Oui et ?
      Tu as un beau filtre anti-spam.
      Plus un anti-virus.
      Plus une super politique de sécurité.
      Plus des utilisateurs au dessus de la moyenne.
      Et donc ça te garanti de ne jamais avoir de spam envoyé à partir de ton serveur ?
      --> montes vite une entreprise, car tu vas être riche dans les 6 mois. Mais je suppose tu vas également être la cible de plusieurs contrat sur ta tête, c'est un inconvénient certain.

      • [^] # Re: euh et mettre un filtre antispam ?

        Posté par (page perso) . Évalué à 5.

        Je ne comprends pas ton commentaire, il propose juste d'utiliser un antispam en complément des outils cités dans la dépêche. Je ne vois pas où il dit avoir une solution parfaite.

      • [^] # Re: euh et mettre un filtre antispam ?

        Posté par . Évalué à -2.

        Ouah un beau troll comme on en fait plus.
        MA - GNI - FIQUE !!!
        Ohhh ca réchauffe le coeur d'avoir des gens accueillants, chaleureux,…

        PS: J'ai déjà monté mon entreprise et je suis consultant emailing & délivrabilité ;-)
        Mais vu que tu as l'air de mieux t'y connaitre…

        • [^] # Re: euh et mettre un filtre antispam ?

          Posté par (page perso) . Évalué à 3.

          Le titre de ton commentaire est « euh et mettre un filtre antispam ? »
          Je l'ai interpreté comme « à la place de tes manipulations compliquées, utilises plutôt un filtre anti-spam ». Ce qui est peut-être/probablement une erreur de ma part.

          PS: J'ai déjà monté mon entreprise et je suis consultant emailing & délivrabilité ;-)
          Mais vu que tu as l'air de mieux t'y connaitre…

          Ce genre d'argument, ça vaut exactement zéro.
          Tout comme n'importe quel spécialiste de tel ou tel domaine, il y a zéro garantie qu'il soit compétent. J'ai trop vu de mauvais médecins, de mauvais garagistes. Pour les informaticiens/développeurs/administrateurs, nous ne sommes pas mieux.

  • # Commentaire supprimé

    Posté par . Évalué à -1. Dernière modification le 14/08/15 à 08:51.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Commentaire supprimé

      Posté par . Évalué à 0. Dernière modification le 14/08/15 à 08:51.

      Ce commentaire a été supprimé par l'équipe de modération.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.