IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Découverte de CronRAT, un nouveau logiciel malveillant pour Linux qui devrait frapper le 31 février


Sujet :

Sécurité

  1. #1
    Communiqués de presse

    Femme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2018
    Messages
    1 050
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 31
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2018
    Messages : 1 050
    Points : 46 772
    Points
    46 772
    Par défaut Découverte de CronRAT, un nouveau logiciel malveillant pour Linux qui devrait frapper le 31 février
    Des chercheurs en sécurité ont découvert CronRAT, un nouveau cheval de Troie d'accès à distance (RAT) furtif conçu pour attaquer les systèmes Linux, se cachant sous la forme d'une tâche planifiée

    Des chercheurs en sécurité ont découvert un nouveau cheval de Troie d'accès à distance (RAT) furtif, conçu pour attaquer les systèmes Linux. Baptisé CronRAT, ce malware cible actuellement les boutiques en ligne et permet aux attaquants de voler des données de cartes de crédit en déployant des skimmers de paiement en ligne sur les serveurs Linux.

    Les chercheurs de Sansec avertissent que CronRAT "permet le vol de données Magecart côté serveur en contournant les solutions de sécurité basées sur le navigateur". C'est un phénomène particulièrement préoccupant.

    CronRAT est décrit comme "une menace sophistiquée, dotée de techniques furtives inédites", et Sansec affirme que son mode de fonctionnement signifie qu'elle ne sera pas reconnue par les autres sociétés de sécurité avant un certain temps.

    L'entreprise explique : "Sansec a découvert que CronRAT était présent sur plusieurs magasins en ligne, dont le plus grand magasin du pays. En raison de son exécution inédite, nous avons dû réécrire une partie de notre algorithme eComscan afin de le détecter. CronRAT n'est actuellement pas détecté par les autres fournisseurs de sécurité".

    La société de sécurité poursuit :

    "La principale prouesse de CronRAT est de se cacher dans le sous-système calendrier des serveurs Linux ("cron") un jour inexistant. De cette façon, il n'attire pas l'attention des administrateurs de serveurs. Et de nombreux produits de sécurité n'analysent pas le système cron de Linux.
    CronRAT facilite le contrôle persistant d'un serveur de commerce électronique. Sansec a étudié plusieurs cas où la présence de CronRAT a conduit à l'injection de skimmers de paiement (alias Magecart) dans le code côté serveur
    ."

    Nom : sansec-1107x208.png
Affichages : 87426
Taille : 14,6 Ko

    Le CronRAT ajoute un certain nombre de tâches à la crontab avec une curieuse spécification de date : 52 23 31 2 3. Ces lignes sont syntaxiquement valides, mais génèrent une erreur d'exécution lorsqu'elles sont exécutées. Cependant, cela ne se produira jamais car elles sont programmées pour être exécutées le 31 février. Au lieu de cela, le véritable code du malware est caché dans les noms des tâches et est construit en utilisant plusieurs couches de compression et de décodage base64.

    La véritable charge utile de CronRAT est un "programme Bash sophistiqué qui se caractérise par l'autodestruction, la modulation du temps et un protocole binaire personnalisé pour communiquer avec un serveur de contrôle étranger".

    De plus, la connexion se fait sur TCP via le port 443 en utilisant une fausse bannière pour le service SSH Dropbear, ce qui permet également au malware de rester sous le radar.

    Après avoir contacté le serveur C2, le déguisement tombe, envoie et reçoit plusieurs commandes, et obtient une bibliothèque dynamique malveillante. À la fin de ces échanges, les attaquants derrière CronRAT peuvent exécuter n'importe quelle commande sur le système compromis.

    CronRAT a été trouvé sur plusieurs magasins à travers le monde, où il a été utilisé pour injecter sur le serveur des scripts qui volent les données des cartes de paiement - les attaques dites Magecart.

    Sansec décrit le nouveau malware comme "une menace sérieuse pour les serveurs de commerce électronique Linux", en raison de ses capacités :

    • Exécution sans fichier
    • Modulation du temps
    • Sommes de contrôle anti-tampering
    • Contrôle via un protocole binaire et obscurci
    • Lancement d'un RAT en tandem dans un sous-système Linux distinct.
    • Serveur de contrôle déguisé en service "Dropbear SSH".
      Charge utile cachée dans les noms de tâches programmées CRON légitimes.


    Toutes ces caractéristiques rendent CronRAT pratiquement indétectable. Sur le service d'analyse VirusTotal, 12 moteurs antivirus ont été incapables de traiter le fichier malveillant et 58 d'entre eux ne l'ont pas détecté comme une menace.

    Source : Sansec

    Et vous ?

    Qu'en pensez-vous ?

    Voir aussi :

    Le ransomware "Hive" chiffre désormais les systèmes Linux et FreeBSD,
    Mais cette variante du ransomware est encore boguée et ne fonctionne pas toujours


    La NSA et le FBI dévoilent le nouveau malware Drovorub de fabrication russe ciblant Linux, les agences émettent une alerte commune contenant des détails techniques sur ce logiciel malveillant
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Membre extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    369
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 369
    Points : 1 359
    Points
    1 359
    Par défaut
    Qu'en pensez-vous ?

    Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
    SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
    Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.

  3. #3
    Membre habitué Avatar de greg91
    Homme Profil pro
    Administrateur système
    Inscrit en
    novembre 2007
    Messages
    112
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur système

    Informations forums :
    Inscription : novembre 2007
    Messages : 112
    Points : 172
    Points
    172
    Par défaut
    Comment un site web pourrait compromettre crond ?
    Je voie pas (si PHP est bien configuré).

  4. #4
    Membre confirmé
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2014
    Messages
    259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2014
    Messages : 259
    Points : 475
    Points
    475
    Par défaut
    Citation Envoyé par defZero Voir le message
    Qu'en pensez-vous ?

    Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
    SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
    Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.
    Tout à fait d'accord. Surtout qu'entre nous, cron n'arrive pas à la cheville des timers Systemd (pas de randomisation native, impossible de faire concilier day of month et day of week sous Cron sans passer par la commande "test" et j'en passe).

  5. #5
    Membre confirmé
    Profil pro
    Développeur indépendant
    Inscrit en
    août 2004
    Messages
    352
    Détails du profil
    Informations personnelles :
    Âge : 53
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : Transports

    Informations forums :
    Inscription : août 2004
    Messages : 352
    Points : 452
    Points
    452
    Par défaut le moment terreur
    encore un article fumeux pour foutre les jetons.
    mais la seule chose qui serait interressante de savoir, c'est le mode de contamination.
    j'aimerais bien savoir par quel moyen ce truc a pu s'implanter sur cron, voir meme etre enregistré sur le serveur et etre executé..
    comme d'hab, on nous présente un épouvantail mais ca s'applique à ... personnne.
    ils citent que ce cronrat serait présent sur plusieurs magasins en ligne, dont le plus grand magasin du pays" et c'est tout. quel pays, quel magasin??
    du vent, rien de plus.

    si vous voulez être en sécurité, donnez vous les moyens de pouvoir réinstaller complétement votre serveur et tous ses services. en clair, vos services /serveurs doivent etre des phénix, aptes à renaitre de leurs cendres si besoin.
    ca résoudra 2 problématqiues principales.
    - plantage matériel.
    - contamination par une mauvaise politique de sécurité. reinstaller un serveur est l'equivalent d'une petite revue, l'occasion de se demander. 'mais pourquoi on fait ca.? pourquoi ce code fait ca. ou pourquoi ce code est obscurci? ou inaccessible?'

    les plugins ou les services developpés par d'autres, c'est pratique, mais c'est comme de laisser un ouvrier extérieur bosser sur la serrure de votre coffre fort, seul la nuit, sans surveillance, chez vous, sans meme savoir qui c'est. donc, mef...
    developper ses propres services ou prendre le temps de controler ce que fait une lib, comprendre ce qu'elle fait et comment avant de l'implanter, c'est le minimum..
    maitrisez vos sauvegardes, ayez vos propres serveurs de sauvegarde.. ca aussi c'est important. et ca coute pas un bras..

    HA, github, c'est pas la panacée, surtout quand c'est maintenant géré par agrosoft.. qui a toujours bien compris les besoins de la NSA.. laquelle NSA bosse pour l'etat americain qui pratique l'espionnage economique, entre autres.

    quand on est developpeur, la méfiance doit devenir une seconde nature.. si on veut assurer la sécurité de ses clients et sa tranquilité..

  6. #6
    Expert confirmé
    Avatar de becket
    Profil pro
    Informaticien multitâches
    Inscrit en
    février 2005
    Messages
    2 516
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Informaticien multitâches
    Secteur : Service public

    Informations forums :
    Inscription : février 2005
    Messages : 2 516
    Points : 5 106
    Points
    5 106
    Par défaut
    Nom : Screenshot 2021-12-01 123845.png
Affichages : 1811
Taille : 8,0 Ko

    Le 31 février ? Même pas peur !

  7. #7
    Membre confirmé
    Avatar de Hominidé
    Homme Profil pro
    Paysan à 3 francs six sous
    Inscrit en
    juin 2018
    Messages
    422
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Paysan à 3 francs six sous

    Informations forums :
    Inscription : juin 2018
    Messages : 422
    Points : 625
    Points
    625
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    Le CronRAT ajoute un certain nombre de tâches à la crontab avec une curieuse spécification de date : 52 23 31 2 3. Ces lignes sont syntaxiquement valides, mais génèrent une erreur d'exécution lorsqu'elles sont exécutées. Cependant, cela ne se produira jamais car elles sont programmées pour être exécutées le 31 février.
    Comment un cron qui ne s'exécute pas peut-il lancer un code?

  8. #8
    Membre habitué
    Homme Profil pro
    Développeur Java
    Inscrit en
    juin 2017
    Messages
    86
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 70
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java

    Informations forums :
    Inscription : juin 2017
    Messages : 86
    Points : 176
    Points
    176
    Par défaut
    Citation Envoyé par defZero Voir le message
    Qu'en pensez-vous ?

    Que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod.
    SystemD, adopté par toutes les principales distribs, proposant les units "timers", ils devraient faire des maj de leurs serveurs pour passer sur de la distrib contemporaine.
    Ce qui devrait également leurs offrir au passage, une meilleur sécurité globale et de meilleurs perfs.
    Pour modifier cron, il faut être root.

  9. #9
    Membre confirmé
    Homme Profil pro
    Robotique
    Inscrit en
    août 2007
    Messages
    334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Robotique

    Informations forums :
    Inscription : août 2007
    Messages : 334
    Points : 561
    Points
    561
    Par défaut
    Citation Envoyé par edrobal Voir le message
    Pour modifier cron, il faut être root.
    Bonjour et tout faux.
    N'importe qui sous Linux peut utiliser la commande pour modifier sa propre crontab.

    hth,

  10. #10
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    9 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 9 821
    Points : 26 774
    Points
    26 774
    Billets dans le blog
    1
    Par défaut
    Bonjour
    Citation Envoyé par tabouret Voir le message
    cron n'arrive pas à la cheville des timers Systemd (pas de randomisation native, impossible de faire concilier day of month et day of week sous Cron sans passer par la commande "test" et j'en passe)
    Normal puisqu'il n'a pas été fait pour ça !!! Ah ben ma voiture n'arrive pas à la cheville des avions (pas de ADI, pas de pilotage automatique, impossible de la faire voler sans lui rajouter des ailes et j'en passe)

    cron contient 3 paramètres de datation
    • la datation horaire (à quelle heure dans la journée)
    • la datation mensuelle (quel jour du mois et quel mois de l'année)
    • la datation hebdomadaire (quel jour de la semaine)

    avec possibilité souple dans l'expression des datations (ex 0-60/2 signifiant "toutes les 2 unités de temps entre 0 et 60) mais surtout avec cette spécification que si une datation mensuelle et hebdomadaire sont explicitement spécifiées (donc avec autre chose que l'étoile), il s'exécutera alors si l'une ou l'autre des dates se présente. Autrement dit je programme un truc le 31/12 le dimanche, le truc s'exécutera tous les 31/12 et aussi tous les dimanches. C'est comme ça que les concepteurs l'ont voulu et c'est comme ça que les concepteurs l'expliquent. Fatalement si ce n'est pas comme ça que toi tu veux l'utiliser, à toi de coder ce qu'il faut pour combler. Mais ce n'est pas parce que tu ne veux pas l'utiliser de la façon dont il a été conçu que ça doit être sa faute à lui !!! Justement Linux se veut assez souple et ouvert pour permettre l'utilisation d'autres outils plus adaptés (anacron, at, etc). Tu ne l'aimes pas ok, ce n'est pas une raison pour affirmer "qu'il n'arrive pas à la cheville d'autres trucs que tu aimes". Et puis ce n'est pas parce qu'un truc est plus récent, plus "moderne" qu'un autre qu'il sera forcément mieux tout le temps. Tout le monde se fout de la tronche des russes qui ont encore des ordinateurs à lampe en activité alors que nous on a des crays. Sauf que le jour où on se prend une IEM dans la tronche, les ordinateurs russes continueront à fonctionner tandis que nous, on sera dans le noir. Donc peut-être que dans d'autres situations que toi tu n'as pas mais que d'autres peuvent avoir c'est cron qui aura l'avantage.

    Citation Envoyé par Ti-Slackeux Voir le message
    tout faux.
    N'importe qui sous Linux peut utiliser la commande pour modifier sa propre crontab.
    Je pense que tu n'as pas bien réfléchi à tout ça.

    N'importe qui peut utiliser la commande crontab -e à condition de ne pas se trouver dans cron.deny (première barrière qui liste les utilisateurs interdits et qui donc autorise tous les autres) ou d'être dans cron.allow (seconde barrière qui, si elle est présente, supplante la première et qui liste les utilisateurs autorisés et qui donc interdit tous les autres).

    Et même si cela reste possible, tu présentes ça comme très simple, comme un simple user qui peut faire un crontab -e ("utiliser la commande" as-tu dit). Mais pour "utiliser une commande" il faut déjà être dans le système !!!
    Donc déjà il faut que le "virus" qui s'exécute sur le serveur linux (on parle donc déjà là d'un truc qui va forcer un serveur style apache à faire des trucs pour lui) fasse lui-même le crontab -e (qui n'est pas un éditeur de cron mais qui se contente juste de lancer l'éditeur standard, peut-être "ed", peut-être "vi", peut-être "emacs", ou même peut-être rien du tout si l'admin de apache a bien configuré le compte associé au serveur donc dans ce cas là, pas d'éditeur !!!). Donc déjà c'est bien bien chaud. Mais allez, admettons. Mais ensuite quoi? Le processus lancé par ledit cron reste un processus utilisateur et pas root (l'utilisateur étant donc apache et qui n'a donc accès qu'à ses propres fichiers). Question droits d'accès au système, il devrait pouvoir gérer ça facilement le serveur Linux...

    Et enfin comme d'autres l'ont si bien dit, je ne vois pas comment crond pourrait détecter qu'on est le 31 février pour enfin lancer le processus. A la limite convertir un "31 février" en "3 mars" certains outils savent le faire (exemple datetime de Python) mais penser qu'un outil (système en plus) ait été programmé pour faire l'inverse...

    Donc non, pas "tout faux"...
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

  11. #11
    Membre confirmé
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2014
    Messages
    259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2014
    Messages : 259
    Points : 475
    Points
    475
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Bonjour

    Normal puisqu'il n'a pas été fait pour ça !!! Ah ben ma voiture n'arrive pas à la cheville des avions (pas de ADI, pas de pilotage automatique, impossible de la faire voler sans lui rajouter des ailes et j'en passe)

    cron contient 3 paramètres de datation
    • la datation horaire (à quelle heure dans la journée)
    • la datation mensuelle (quel jour du mois et quel mois de l'année)
    • la datation hebdomadaire (quel jour de la semaine)

    avec cette spécification que si une datation mensuelle et hebdomadaire sont explicitement spécifiées (donc avec autre chose que l'étoile), il s'exécutera alors si l'une ou l'autre des dates se présente. Autrement dit je programme un truc le 31/12 le dimanche, le truc s'exécutera tous les 31/12 et aussi tous les dimanches. C'est comme ça que les concepteurs l'ont voulu et c'est comme ça que les concepteurs l'expliquent. Fatalement si ce n'est pas comme ça que toi tu veux l'utiliser, à toi de coder ce qu'il faut pour combler. Mais ce n'est pas parce que tu ne veux pas l'utiliser de la façon dont il a été conçu que ça doit être sa faute à lui !!! Justement Linux se veut assez souple et ouvert pour permettre l'utilisation d'autres outils plus adaptés (anacron, at, etc). Tu ne l'aimes pas ok, ce n'est pas une raison pour affirmer "qu'il n'arrive pas à la cheville d'autres trucs que tu aimes". Et puis ce n'est pas parce qu'un truc est plus récent, plus "moderne" qu'un autre qu'il sera forcément mieux tout le temps. Tout le monde se fout de la tronche des russes qui ont encore des ordinateurs à lampe en activité alors que nous on a des crays. Sauf que le jour où on se prend une IEM dans la tronche, les ordinateurs russes continueront à fonctionner tandis que nous, on sera dans le noir. Donc peut-être que dans d'autres situations que toi tu n'as pas mais que d'autres peuvent avoir c'est cron qui aura l'avantage.


    Je pense que tu n'as pas bien réfléchi à tout ça.
    Je pense que tu n'as pas vraiment réfléchi au problème.
    Cron a été crée pour faire des tâches planifiés, tout comme les timers Systemd. ils ont exactement le même but.
    Définir un OU logique entre day of month et day of week est une erreur de conception que Systemd (agissant comme un ET logique), bien plus souple, à corriger.

    La preuve, pour corriger ce défaut de conception de Cron, tu es obligé de rajouter la commande "test" si tu veux imiter le comportement de Systemd. Bref du bricolage degueula....Rajouter une commande dans la commande finale, tu y perds en lisibilité.

    Idem pour la randomisation de démarrage, Cron en est tout à fait incapable. Et ce ne sont que des choses parmi d'autres qui font que les timers Systemd sont bien au dessus de Cron. Je ne crache pas sur Cron mais il faut savoir voir quand une chose est meilleur qu'une autre.

    J'ajouterai que Cron ne fait strictement rien de mieux que ce que ne font déjà les timers Systemd et des cas d'utilisation j'en ai vu à la pelle sinon je t'en pris donne moi un seul exemple.

  12. #12
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    9 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 9 821
    Points : 26 774
    Points
    26 774
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par tabouret Voir le message
    Je pense que tu n'as pas vraiment réfléchi au problème.
    Tu veux jouer au comique de répétition?

    Citation Envoyé par tabouret Voir le message
    Cron a été crée pour faire des tâches planifiés, tout comme les timers Systemd. ils ont exactement le même but.
    Oui, tout comme "anacron" ou "at". Même but mais pas dans les mêmes conditions. Et ce sont ces conditions qui te feront choisir l'outil qui s'y adapte le mieux. Même "timer" sera utile dans des conditions qui lui sont adaptées.

    Citation Envoyé par tabouret Voir le message
    Définir un OU logique entre day of month et day of week est une erreur de conception
    Ah? Et d'où tu sors que c'est une erreur? Sans déconner, des types ont voulu faire un truc agissant selon une certaine logique qu'ils ont définie et toi tu arrives et tu leur dis "non non les gars, c'est pas comme ça que vous devez penser votre truc". M'étonnerait pas qu'ils te répondent d'aller te faire...
    Tout choix aura toujours des avantages et des inconvénients. Mais choisir A plutôt que B n'est certainement pas une erreur de conception. Ou bien ce sera une erreur dans le cas où tu veux faire B mais eux ont voulu faire A.

    Citation Envoyé par tabouret Voir le message
    que Systemd (agissant comme un ET logique), bien plus souple, à corriger.
    "à corriger" et "a corrigé" n'ont pas la même signification. Sauf que j'ai l'impression que tu voulais exprimer l'autre (sinon ça veut dire que systemd est un truc pas fini "à finir"). Si tu ne sais pas quand employer l'infinitif ou le participe passé, tu remplaces par "vendre" comme ça tu verras de suite s'il faut dire "à vendre" ou "a vendu".

    Citation Envoyé par tabouret Voir le message
    La preuve, pour corriger ce défaut de conception de Cron, tu es obligé de rajouter la commande "test" si tu veux imiter le comportement de Systemd.
    Alors déjà ce n'est pas moi qui ai besoin de faire quoi que ce soit (je n'ai jamais dit avoir besoin moi de faire en sorte qu'une chose se lance tel jour de tel mois à condition que ce soit aussi tel jour de la semaine, c'est toi, et déjà j'ai du mal à voir le but d'un tel truc) et ce n'est pas une preuve de défaut de conception, c'est juste la preuve que tu utilises un outil dans des conditions pour lesquelles il n'a pas été conçu. Ok tu as le droit d'avoir des besoins spécifiques mais ce n'est pas la faute de l'outil si tes besoins t'obligent à rajouter les contrôles qui manquent, et même si un autre outil le permet, ce n'est pas pour cela que le premier doit être foutu au trou. Et à l'inverse si cron était codé pour lancer la tâche au jour et au mois qui correspond pile poil au jour de la semaine, je me demande bien comment tu ferais pour lui demander l'inverse, c'est à dire de lancer un truc au jour et au mois et aussi au jour de la semaine. Un "ou" (qui contient trois "uns" et un seul "zéro") peut parfaitement être réduit à un "et" (suffit de rajouter les tests manquants pour éliminer les "uns" en trop) tandis que pour transformer un "et" en "ou" (c'est à dire faire revenir l'information qui a été détruite)...

    Citation Envoyé par tabouret Voir le message
    Bref du bricolage degueula....Rajouter une commande dans la commande finale, tu y perds en lisibilité.
    Bah non, j'utiliserais timer (je n'ai jamais dit non plus qu'il n'était pas à utiliser !!!). Et dans le pire des cas, rien ne m'interdit de faire un lanceur intermédiaire un peu universel que je viendrai intercaler entre le cron et ma commande finale. De suite ça devient moins "bricolage degeu"...

    Citation Envoyé par tabouret Voir le message
    Je ne crache pas sur Cron
    Ah ben si, quand tu réponds "tout à fait d'accord" à la phrase de defZero disant que cron ne doit plus être utilisé. Si ça ce n'est pas "cracher dessus"...

    Citation Envoyé par tabouret Voir le message
    mais il faut savoir voir quand une chose est meilleur qu'une autre.
    Meilleur !!! En voilà un jugement bien péremptoire!!! Encore une fois tout dépend du besoin (cf mon exemple entre voiture et avion). Qu'est-ce qui est meilleur? Une pêche ou une poire? Même les plus grands dans leur discipline l'ont dit, il n'y a pas d'absolu. Bruce Lee disait "il n'y a pas de meilleur combattant qu'un autre, seulement des combattants qui maitrisent mieux une discipline qu'une autre". Herbert Mayer lui a dit "Aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers.". Et toi tu arrives "oui il faut savoir quand une chose est meilleure qu'une autre" tu te sens plus inspiré que ces deux références? Pour planter un clou, un marteau est bien meilleur qu'un tournevis. Mais pour visser... Et même pour un besoin équivalent, par exemple pour transformer de la data entrante je choisirai tantôt awk (super complet mais super lourd) ou tantôt sed (super léger mais très réduit en possibilités par rapport au premier) pourtant tous deux pouvant faire le job.

    Citation Envoyé par tabouret Voir le message
    J'ajouterai que Cron ne fait strictement rien de mieux que ce que ne font déjà les timers Systemd et des cas d'utilisation j'en ai vu à la pelle sinon je t'en prie (du verbe "prier", qui est un verbe du premier groupe) donne moi un seul exemple.
    Je n'ai pas d'exemple en tête. Mais le manque de preuve n'est pas la preuve d'un manque.
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

  13. #13
    Membre confirmé
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2014
    Messages
    259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2014
    Messages : 259
    Points : 475
    Points
    475
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Ah? Et d'où tu sors que c'est une erreur? Sans déconner, des types ont voulu faire un truc agissant selon une certaine logique qu'ils ont définie et toi tu arrives et tu leur dis "non non les gars, c'est pas comme ça que vous devez penser votre truc". M'étonnerait pas qu'ils te répondent d'aller te faire...
    Si je remets en cause leur logique avec des arguments où est le problème? j'ai tout à fait le droit de dire que leur logique est à chier et que le rendement final est médiocre

    Citation Envoyé par Sve@r Voir le message
    Alors déjà ce n'est pas moi qui ai besoin de faire quoi que ce soit (je n'ai jamais dit avoir besoin moi de faire en sorte qu'une chose se lance tel jour de tel mois à condition que ce soit aussi tel jour de la semaine, c'est toi, et déjà j'ai du mal à voir le but d'un tel truc) et ce n'est pas une preuve de défaut de conception, c'est juste la preuve que tu utilises un outil dans des conditions pour lesquelles il n'a pas été conçu. Ok tu as le droit d'avoir des besoins spécifiques mais ce n'est pas la faute de l'outil si tes besoins t'obligent à rajouter les contrôles qui manquent, et même si un autre outil le permet, ce n'est pas pour cela que le premier doit être foutu au trou. Et à l'inverse si cron était codé pour lancer la tâche au jour et au mois qui correspond pile poil au jour de la semaine, je me demande bien comment tu ferais pour lui demander l'inverse, c'est à dire de lancer un truc au jour et au mois et aussi au jour de la semaine. Un "ou" (qui contient trois "uns" et un seul "zéro") peut parfaitement être réduit à un "et" (suffit de rajouter les tests manquants pour éliminer les "uns" en trop) tandis que pour transformer un "et" en "ou" (c'est à dire faire revenir l'information qui a été détruite)...
    Le but d'un tel truc? Pourtant évident..Lancer une commande (de mise à jour automatique via unattended-upgrade par exemple) uniquement le 3ème lundi du mois. Et je suis désolé mais Cron aurait du être conçu pour ce cas d'utilisation. Systemd ne fait que pallier les manquements de Cron.
    Faire une tâche planifiée une fois par mois tel jour, c'est normalement dans la roadmap d'un planificateur de tâche. Cron n'est pas à la hauteur, Systemd l'est. Transformer un OU en ET te demande de rajouter une commande dans ta commande finale, la lisibilité devient à chier.
    Transformer un ET en OU via Systemd est un jeu d'enfant, il suffit de rajouter des directives OnCalendar.


    Citation Envoyé par Sve@r Voir le message
    Ah ben si, quand tu réponds "tout à fait d'accord" à la phrase de defZero disant que cron ne doit plus être utilisé. Si ça ce n'est pas "cracher dessus"...
    Je ne crache pas dessus, je dis que Cron n'arrive pas à la cheville des timers Systemd.

    Citation Envoyé par Sve@r Voir le message
    Meilleur !!! En voilà un jugement bien absolu !!! Encore une fois tout dépend du besoin (cf mon exemple entre voiture et avion). Qu'est-ce qui est meilleur? Une pêche ou une poire? Même les plus grands dans leur discipline l'ont dit, il n'y a pas d'absolu. Bruce Lee disait "il n'y a pas de meilleur combattant qu'un autre, seulement des combattants qui maitrisent mieux une discipline qu'une autre". Herbert Mayer lui a dit "Aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers.". Et toi tu arrives "oui il faut savoir quand une chose est meilleure qu'une autre" tu te sens plus inspiré que ces deux références? Pour planter un clou, un marteau est bien meilleur qu'un tournevis. Mais pour visser... Et même pour un besoin équivalent, par exemple pour transformer de la data entrante je choisirai tantôt awk (super complet mais super lourd) ou tantôt sed (super léger mais très réduit en possibilités par rapport au premier) pourtant tous deux pouvant faire le job.
    Tes comparaisons sont ridicules. Comparer un avion à une voiture n'a aucun sens, pas plus que de comparer un marteau à un tournevis, ils n'ont pas le même cas d'utilisation. Les timers Systemd et Cron jouent dans la même cour.

    D'autre part tu m'expliques comment tu randomises le délai de départ via Cron sans encore une fois overrider la commande pour la rendre illisible?
    Tu me parles aussi d'anacron et at qui n'ont rien à voir avec cron, je te parle de tâches régulières sur serveur.
    Même si les timers Systemd font aussi ce que font anacron et at.

    Citation Envoyé par Sve@r Voir le message
    Je n'ai pas d'exemple en tête. Mais le manque de preuve n'est pas la preuve d'un manque.
    Et tu n'en auras jamais aucun.

  14. #14
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    9 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 9 821
    Points : 26 774
    Points
    26 774
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par tabouret Voir le message
    Le but d'un tel truc? Pourtant évident..Lancer une commande (de mise à jour automatique via unattended-upgrade par exemple) uniquement le 3ème lundi du mois.
    Une mise à jour de sécurité à faire tous les 3° lundi de chaque mois? Effectivement c'est évident Perso je l'aurais mise par exemple tous les lundi à 2h du matin (une date que cron sait faire et qui me semble peu impactante sur la disponibilité du système tout en offrant un bon référentiel en matière de périodicité) mais bon, je ne suis pas ingénieur en sécurité...

    Citation Envoyé par tabouret Voir le message
    Et je suis désolé mais Cron aurait du être conçu pour ce cas d'utilisation. Systemd ne fait que pallier les manquements de Cron.
    Aurait dû aurait dû, encore du péremptoire que rien n'étaye (rien d'autre que ton besoin perso je veux dire). Et dans ce cas tu aurais en face de toi tous ceux qui disent "oui et moi j'aimerais bien du ou".

    Citation Envoyé par tabouret Voir le message
    Tes comparaisons sont ridicules. Comparer un avion à une voiture n'a aucun sens, pas plus que de comparer un marteau à un tournevis, ils n'ont pas le même cas d'utilisation. Les timers Systemd et Cron jouent dans la même cour.
    Ridicules? Non, exagérées tout au plus. Je pourrais te dire qu'une voiture et un avion jouent tous deux dans la même cour des transports. Ou alors entre avion et train (justement j'ai eu à choisir récemment entre les deux et j'ai pesé les avantages et inconvénients des deux). Mais bon, n'en parlons plus. Mais que fais-tu de la comparaison entre "sed" et "awk" qui jouent tous deux dans la même cour et où le premier n'arrive clairement pas à la cheville du second et où, malgré tout, j'utilise sed chaque fois que je le peux?

    Citation Envoyé par tabouret Voir le message
    Tu me parles aussi d'anacron et at qui n'ont rien à voir avec cron, je te parle de tâches régulières sur serveur.
    Euh... déjà c'était juste un exemple pour dire qu'il y a d'autres outils mais anacron est un programme informatique qui permet l'exécution de tâches quotidiennes, hebdomadaires ou mensuelles sur un système Unix. Me semble que cette définition correspond assez à la notion de "tâche régulière". Et en plus, contrairement à cron, il peut même gérer le cas où la machine était éteinte au moment où la tâche était nécessaire et la rattrapper alors au redémarrage. Me semble pas mal aussi comme possibilité. Ca te manque pas ça dans cron ?

    Citation Envoyé par tabouret Voir le message
    Et tu n'en auras jamais aucun.
    Mouais. Tu aurais dû t'appeler "Hari Seldon"...

    Citation Envoyé par tabouret Voir le message
    D'autre part tu m'expliques comment tu randomises le délai de départ via Cron sans encore une fois overrider la commande pour la rendre illisible?
    Encore une fois je ne le fais pas et encore une fois si j'ai ce besoin je passerai par timer où, encore une fois, je n'ai jamais dit que je ne l'utiliserais pas. La différence entre ton discours et le mien, c'est que toi tu dis "oui tout à fait d'accord, cron doit être poubellisé" (parce que n'oublions pas que ça a quand-même été ta réponse à defZero qui dit que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod). Tandis que moi je dis "on a plein d'outils qui s'adapteront tous peu ou prou à des situations diversifiées, c'est super profitons-en". A ton avis, quel discours est le plus correspondant aux valeurs d'ouverture et de liberté (sans pour autant négliger la sécurité) que défendent Unix et Linux ?
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

  15. #15
    Membre confirmé
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2014
    Messages
    259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2014
    Messages : 259
    Points : 475
    Points
    475
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Une mise à jour de sécurité à faire tous les 3° lundi de chaque mois? Effectivement c'est évident Perso je l'aurais mise par exemple tous les lundi à 2h du matin (une date que cron sait faire et qui me semble peu impactante sur la disponibilité du système tout en offrant un bon référentiel en matière de périodicité) mais bon, je ne suis pas ingénieur en sécurité...
    Oui sauf qu'un reboot une fois par semaine (possiblement) n'est pas acceptable pour la majorité des clients. Evidemment j'ai proposé une fois par semaine, ça a été refusé. D'où le cas d'utilisation du 3ème lundi du mois.

    Citation Envoyé par Sve@r Voir le message
    Ridicules? Non, exagérées tout au plus. Je pourrais te dire qu'une voiture et un avion jouent tous deux dans la même cour des transports. Ou alors entre avion et train (justement j'ai eu à choisir récemment entre les deux et j'ai pesé les avantages et inconvénients des deux). Mais bon, n'en parlons plus. Mais que fais-tu de la comparaison entre "sed" et "awk" qui jouent tous deux dans la même cour et où le premier n'arrive clairement pas à la cheville du second et où, malgré tout, j'utilise sed chaque fois que je le peux?
    sed est plus facile à mettre en oeuvre que awk, c'est son seul avantage. Et ne me parles pas de la facilité de cron vis à vis des timers Systemd je te vois venir^^.

    Citation Envoyé par Sve@r Voir le message
    Euh... déjà c'était juste un exemple pour dire qu'il y a d'autres outils mais anacron est un programme informatique qui permet l'exécution de tâches quotidiennes, hebdomadaires ou mensuelles sur un système Unix. Me semble que cette définition correspond assez à la notion de "tâche régulière". Et en plus, contrairement à cron, il peut même gérer le cas où la machine était éteinte au moment où la tâche était nécessaire et la rattrapper alors au redémarrage. Me semble pas mal aussi comme possibilité. Ca te manque pas ça dans cron ?
    Ça ne me manque en tout cas pas dans les timers Systemd via la directive "Persistent"
    Et non cron c'est les tâches régulières sur serveur.
    Anacron, les tâches régulières sur PC.

    Citation Envoyé par Sve@r Voir le message
    Encore une fois je ne le fais pas et encore une fois si j'ai ce besoin je passerai par timer où, encore une fois, je n'ai jamais dit que je ne l'utiliserais pas. La différence entre ton discours et le mien, c'est que toi tu dis "oui tout à fait d'accord, cron doit être poubellisé" (parce que n'oublions pas que ça a quand-même été ta réponse à defZero qui dit que ça devrait faire un moment que crond ne devrait plus être sur des serveurs en prod). Tandis que moi je dis "on a plein d'outils qui s'adapteront tous peu ou prou à des situations diversifiées, c'est super profitons-en". A ton avis, quel discours est le plus correspondant aux valeurs d'ouverture et de liberté (sans pour autant négliger la sécurité) que défendent Unix et Linux ?
    Autant j'utilise sed et awk conjointements, autant cron je ne l'utilise plus parce que les timers sont plus puissants. Mais nous n'avons pas mis cron à la poubelle (d'ailleurs peu de gens savent comment paramétrer des timers Systemd en production).

    Mais tu sais c'est exactement le même débat qu'avec policykit vs sudo.
    Pour ma part, inutile d'installer sudo sur un système mais qui sait vraiment utiliser polkit? d'où le fait que nous laissons aussi sudo en production.

  16. #16
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    février 2006
    Messages
    9 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : février 2006
    Messages : 9 821
    Points : 26 774
    Points
    26 774
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par tabouret Voir le message
    Oui sauf qu'un reboot une fois par semaine (possiblement) n'est pas acceptable pour la majorité des clients. Evidemment j'ai proposé une fois par semaine, ça a été refusé. D'où le cas d'utilisation du 3ème lundi du mois.
    Hé voilà. Le souci du besoin. Toi tu as des clients qui comptent sur une HD de tes serveurs et pas moi. D'où le fait que le choix d'un outil plutôt qu'un autre se réfléchit au cas par cas.

    Citation Envoyé par tabouret Voir le message
    sed est plus facile à mettre en oeuvre que awk, c'est son seul avantage.
    C'est pas ce que j'avais en tête. Je pensais plutôt à la "lourdeur" de l'un vis à vis de l'autre. Utiliser awk là où sed suffit, c'est utiliser un marteau pilon pour ouvrir une noix.

    Citation Envoyé par tabouret Voir le message
    Et non cron c'est les tâches régulières sur serveur.
    Anacron, les tâches régulières sur PC.
    Hum... j'ai du mal à voir la différence. Ou alors tu penses au fait qu'un serveur ne s'arrête jamais rendant alors anacron inutile. Perso je te dirai que j'ai jamais utilisé anacron et si mon PC est éteint au moment où la tâche devait se lancer ben tant pis, ça attendra la prochaine fois. Mais c'est pareil, encore une fois parce que j'ai pas ce souci de HD

    Citation Envoyé par tabouret Voir le message
    (d'ailleurs peu de gens savent comment paramétrer des timers Systemd en production).
    Bah, ça doit s'apprendre comme le reste.

    Citation Envoyé par tabouret Voir le message
    Mais tu sais c'est exactement le même débat qu'avec policykit vs sudo.
    Pour ma part, inutile d'installer sudo sur un système mais qui sait vraiment utiliser polkit? d'où le fait que nous laissons aussi sudo en production.
    Pareil, je ne connais même pas cet outil polkit. Mais quelque chose me dit que même le jour où je le connaitrai, je continuerai à dire "ok, maintenant je connais deux outils donc j'ai deux fois plus de choix" et non pas "oh là là polkit est bien mieux que sudo, vite oublions cette erreur de la nature "
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site

  17. #17
    Membre confirmé
    Avatar de Hominidé
    Homme Profil pro
    Paysan à 3 francs six sous
    Inscrit en
    juin 2018
    Messages
    422
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Paysan à 3 francs six sous

    Informations forums :
    Inscription : juin 2018
    Messages : 422
    Points : 625
    Points
    625
    Billets dans le blog
    1
    Par défaut
    Bonjour,
    Pour ce qui est de cron et systemd, j'utilise systemd pour créer un service, cron pour demander à mon pc de préparer le café à 5h30 précise(voir juste un jour j/5h30), ou anacron pour qu'il le prépare quand il sera dispo. J'y vois trois outils différant que je choisis selon mes besoins.
    Je n'administre pas de serveur, et n'ai aucune connaissance sur le sujet, mais bon il semble évident que ces outils ont chacun leurs approches spécifiques. Pour un serveur, j'imagine que l'on veut des interactions avec le système comme le permet la création de service avec systemd. Ceci dit, ça en fait pas un outil meilleur. Il est juste adapté à cette tache (par contre pour me faire le café de 5h30, c'est cron ).

  18. #18
    Membre confirmé
    Homme Profil pro
    Ingénieur sécurité
    Inscrit en
    avril 2014
    Messages
    259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur sécurité
    Secteur : Industrie

    Informations forums :
    Inscription : avril 2014
    Messages : 259
    Points : 475
    Points
    475
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    Pareil, je ne connais même pas cet outil polkit. Mais quelque chose me dit que même le jour où je le connaitrai, je continuerai à dire "ok, maintenant je connais deux outils donc j'ai deux fois plus de choix" et non pas "oh là là polkit est bien mieux que sudo, vite oublions cette erreur de la nature "
    O rassures toi on aura ce débat la en temps voulu

Discussions similaires

  1. Réponses: 48
    Dernier message: 03/08/2018, 18h31
  2. Quand le FBI se sert de logiciels malveillants pour ses besoins d'enquête
    Par Stéphane le calme dans le forum Sécurité
    Réponses: 0
    Dernier message: 08/11/2016, 20h59
  3. Réponses: 15
    Dernier message: 08/08/2013, 12h42
  4. Réponses: 10
    Dernier message: 04/01/2011, 16h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo