Agilité, Développement Java, Nouvelles technologies et plus…
  • rss
  • Accueil
  • Management
  • Programmation agile
  • Technologie
  • Linux
  • Evénement
  • App Android
  • Contact
  • A propos de l'auteur
  • English
  • Francais

Comment écrire un article de blog? En tout cas à ma façon!

Fabian Piau | lundi 5 décembre 2022 - 22:28
  • Imprimer
  • Twitter
  • LinkedIn
  • Facebook
  • Pocket

 English version available

Comment écrire un article de blog? A plusieurs reprises, j’ai reçu des messages de lecteurs me demandant des conseils autour de ce sujet.

  • Comment trouver des idées?
  • Comment faire le tri dans ses pensées avant de se plonger dans l’écriture?
  • Est-ce que je suis un processus particulier?
  • Ai-je des conseils à partager avec quelqu’un qui aimerait commencer à bloguer?

Je me souviens encore du jour où j’ai commencé ce blog, il y a près de 13 ans (au moment où j’écris ceci, je me rends compte à quel point cela sonne préhistorique). A l’époque, mon objectif initial était de publier une fois par mois sur des sujets variés liés à l’informatique, que ce soit sur des thématiques liées à mon travail, ou à des projets personnels. Si cela fonctionnait plutôt bien au début, ces derniers temps, je dois l’avouer, cela ne fonctionne pas si bien que ça. J’ai presque honte quand je regarde la date du dernier (précédent) article, il y a plus d’un an, c’est de loin la plus grosse période d’inactivité sur mon blog!

Aujourd’hui, j’ai décidé d’écrire sur ce sujet en particulier, non seulement parce que l’on m’a interrogé à plusieurs reprises à ce propos, mais aussi parce que cet article représente une étape importante pour mon blog. C’est en effet le 100ème article, et c’est l’occasion parfaite pour écrire sur un tel sujet même si c’est quelque chose d’inhabituel et non technique.

Photo Ecrire Article Ordinateur Portable

Pour être honnête, à moins que cela fasse partie d’un travail à plein temps, il faut un certain dévouement pour écrire des articles, car cela prend pas mal de temps, et je ne pense pas qu’il y ait de recette magique. L’état d’esprit de chacun fonctionne différemment, et ce qui peut fonctionner pour moi pourrait avoir l’effet inverse sur vous. Néanmoins, dans cet article, je vais essayer de décrire ma recette qui fonctionne. Du moins je l’espère, je l’ai appliquée pour écrire cet article donc vous pouvez juger de la méthode par vous-même.


L’idée

Tout commence par une idée (ça ressemble à une bande-annonce de film je sais mais c’est vrai). Une idée est une phrase courte, un ensemble de mots-clés tout au plus, qui représente un sujet particulier, ni trop spécifique, ni trop vague. Il n’y a pas de moment précis pour avoir une idée, cela peut être en travaillant, en pianotant sur son ordinateur, en marchant, en prenant une douche. Une idée pointe le bout de son nez généralement bien avant que vous ne commenciez à écrire du contenu à son sujet, mais ce n’est pas toujours vrai, et vous pourriez trouver une idée qui vous passionnera à tel point que vous allez commencer à écrire un article dans l’heure qui suit.

Personnellement, je conserve toutes mes idées sous la forme d’une liste à puces non ordonnée dans un fichier texte sur mon ordinateur. Pour vous donner une idée (oui celle-ci était facile désolé), j’ai actuellement 9 idées dans cette liste.

Tout au long de l’année, j’ai ce puits d’idées dans lequel je peux puiser pour écrire des articles. Comme je l’ai mentionné précédemment, il n’y a pas de règles lorsque vous sélectionnez une idée ; parfois j’écris un article sur une idée que je viens juste d’ajouter (cet article en fait partie), d’autres fois j’écris un article sur une idée que j’ai ajoutée il y a 3 ans. La plupart des idées que j’ai maintenant ne feront probablement jamais l’objet d’un article, il est donc normal d’en abandonner un grand nombre au fil du temps, et cela pour diverses raisons, par exemple l’idée:

  • n’est pas suffisamment bonne pour faire un article intéressant ;
  • n’est pas alignée avec la ligne éditoriale de mon blog, c’est-à-dire qu’elle cible un tout autre public ;
  • est portée sur un sujet niche trop spécialisé ;
  • ou, au contraire, concerne un sujet archi connu et déjà couvert par de nombreux blogueurs.


Contenu brut

Une fois que j’ai sélectionné l’idée, je trouve 1 ou 2 heures dans mon agenda et je commence à écrire. J’ai besoin d’un temps de concentration maximum, et si je peux j’évite de faire des pauses pour limiter toutes coupures et autres distractions. Ici, je parle d’écrire du contenu pur, une version vraiment brute de décoffrage, tout ce qu’il peut me passer par la tête quand je pense à cette idée, ça peut être sous forme de phrases complètes, de listes à puces, de quelques liens ou une description textuelle des futurs images ou schémas que je souhaiterais inclure, etc.

Cela dépend de l’idée, mais s’il s’agit d’une idée très technique, je peux aussi faire une préparation préalable et utiliser des notes prises précédemment, par ex. il peut s’agir de quelques lignes de code ou d’autres exemples de programmation. Je peux également faire des recherches supplémentaires sur Internet pour savoir s’il y a autre chose auquel je n’ai pas pensé. Ce n’est pas une mauvaise chose de s’inspirer d’autres sources, bien sûr tant que vous ne paraphrasez pas ou ne faites pas de plagiat!

A ce stade, je ne fais pas attention ni à l’orthographe, ni aux fautes de frappe et autres fautes de grammaire, j’écris littéralement ce qui me passe par la tête et que je ne voudrais pas oublier. J’utilise un simple éditeur de texte plutôt que d’utiliser l’éditeur de blog en ligne afin d’éviter toute distraction.

Cela ne vous concerne peut-être pas, mais comme mon blog est bilingue, avec un contenu disponible en français et en anglais, je dois aussi décider dans quelle langue je vais écrire en premier. Selon moi, je ne pense pas qu’il soit très efficace d’écrire dans les deux langues en parallèle, et je préfère me concentrer sur une seule à la fois en laissant la traduction à la fin. La plupart du temps et même si le français est ma langue maternelle, j’écris d’abord en anglais. La raison principale est que je risquerais d’écrire des phrases trop complexes en français qui seront difficilement traduisibles en anglais, une autre raison est le fait que je travaille dans le secteur des technologies dans un environnement anglais, donc cette langue est tout simplement plus naturelle (je n’aurais jamais pensé écrire ça un jour!).


Réviser, Améliorer, Peaufiner, Répéter

Maintenant que j’ai couché sur papier (numérique) toutes les informations associées à mon idée, on pourrait penser que je suis à peu près à 60% du processus d’écriture. Malheureusement, c’est loin d’être le cas, et de façon réaliste, je dirais que je n’ai fait qu’environ 30%.

C’est à ce moment qu’entre en piste un processus itératif de révision et d’amélioration, plutôt long et fastidieux. C’est l’étape la plus longue de la rédaction d’un article, mais aussi la plus importante, c’est là que la structure de l’article va prendre forme. Je réorganise mes pensées de manière logique afin que le contenu soit facile à lire et à suivre pour mes lecteurs. Les retours à la ligne, les paragraphes, les sections, les titres et les sous-titres apparaîtront naturellement au fil des révisions. Il est tout à fait acceptable de supprimer une section si vous réalisez qu’elle ne s’intègre pas avec le reste, ou de développer une section si certains détails ont été omis, ou même de réécrire des pans entiers de texte.

Il est important d’adapter le ton de voix et de le garder cohérent à travers tous vos articles. Si c’est votre propre blog, c’est quelque chose auquel vous ne penserez sûrement pas, mais imaginez que vous écrivez un article dans un blog d’une revue scientifique dont le contenu est écrit par plusieurs auteurs, écrire une blague est probablement la dernière chose que vous voudriez faire…

A noter que j’arrête d’utiliser le simple éditeur de texte au profit de l’éditeur de blog en ligne, ainsi je peux donc utiliser le mode aperçu et voir le rendu final de l’article. C’est important, car cette étape ne se concentre plus uniquement sur le texte, mais je pense aussi aux images que j’aimerais intégrer, aux liens que j’aimerais inclure et à la mise en forme que j’aimerais appliquer.


Le Visuel

Lorsque vous ajoutez des images, n’en faites pas trop. Non seulement l’ajout d’images aura un impact non négligeable sur la bande passante, mais pourra également causer une certaine distraction pour vos lecteurs. Dans la plupart des cas, une image en haut de l’article suffira.

Pour rechercher l’image parfaite et si vous n’êtes pas satisfait de vos propres photos, vous pourriez être tenté d’utiliser Google Images, mais il existe bien d’autres ressources disponibles, qui vous éviteront notamment toute forme de violation du droit d’auteur.

  • Unsplash
  • Pexels
  • The Noun Project

Peut-être devez-vous créer un diagramme ou un schéma? Personnellement, j’utilise PowerPoint, ce n’est peut-être pas le meilleur outil, mais il a un rendu que j’apprécie et je suis très familier avec la suite Office. Au cas où j’aurais besoin de générer un schéma plus technique, j’utilise également PlantUML. Cela dépendra vraiment de ce sur quoi vous écrivez et de votre domaine d’expertise, bref, choisissez l’outil que vous préférez!


Liens

Lorsque vous ajoutez des liens, n’en faites pas trop. Le lien est l’outil fondamental pour naviguer sur Internet, il aide à référencer les sites Web incluant le vôtre, mais l’ajout de nombreux liens pourrait être distrayant et votre lecteur pourrait finir par penser que vous faites de la publicité plutôt que de fournir du contenu informatif.

Lorsque vous ajoutez des liens, assurez-vous qu’ils ont tous une utilité. Aident-ils le lecteur à obtenir plus de contexte? Permettent-ils au lecteur d’accéder à un outil que vous avez mentionné? Il est très important d’étiqueter correctement votre lien et de ne pas utiliser le typique « cliquez ici » qui ne contient aucun contexte.

A l’inverse, ce n’est pas la fin du monde si votre article ne contient aucun lien ou seulement quelques-uns. Cependant, je suggérerais d’avoir au moins une section en bas de l’article avec une liste de liens utiles. Cela peut être à titre de référence (c’est aussi une façon de remercier les auteurs dont vous vous êtes peut-être inspiré), mais cela peut également être utile si le lecteur souhaite aller plus loin sur le sujet.


Mise en page

Lorsque vous ajoutez la mise en forme, n’en faites pas trop. La cohérence et la simplicité sont des concepts clés.

Vous pouvez utiliser plusieurs niveaux pour différencier les titres principaux des sous-titres. Personnellement, je me limite à 2 niveaux maximum. Si vous avez besoin de plus, votre article est peut-être trop complexe et il faudrait peut-être envisager de le décomposer en une série d’articles.

En général, espacez votre texte et évitez les phrases longues et complexes qui ont tendance à générer des pavés. Utilisez des listes à puces quand cela a du sens, pas partout.

Certaines mises en forme de texte mineures comme le gras et l’italique peuvent être utiles, mais à utiliser avec parcimonie.

  • Le gras peut souligner une idée et attirer l’attention du lecteur.
  • L’italique peut être utilisé pour introduire un terme technique ou pour citer un texte.


Dernière Revue

A ce stade, il est primordial d’utiliser le mode aperçu de votre éditeur de blog, ainsi vous pourrez vérifier qu’il n’y a pas de liens cassés, que les images sont rendues correctement au bon endroit dans les bonnes dimensions, que la mise en forme et l’espacement fonctionnent comme prévu, etc.

Je dois admettre que j’utilise Word pour la vérification de mon orthographe et grammaire, je copie le contenu complet dans un document Word, puis je répercute les éventuelles corrections suggérées dans l’article. Un outil plus sophistiqué comme Grammarly ou Antidote peut également être une aide précieuse, ces outils s’intègrent directement dans votre navigateur donc vous n’aurez même pas besoin de transférer le contenu.

Si vous connaissez quelqu’un prêt à vous aider et relire votre article, cela peut être un collègue, un ami ou un membre de votre famille, demandez-lui! Il est toujours bon d’avoir des yeux supplémentaires sur votre travail. Personnellement, je saute cette étape et fais ma propre revue. Mais faire comme moi peut être légèrement risqué, surtout si vous publiez au nom de votre entreprise par exemple. Je suis à peu près sûr d’avoir de nombreux articles publiés avec des fautes, c’est particulièrement vrai dans la version anglaise de mes anciens articles (j’espère que mon anglais s’est amélioré depuis). Encore une fois, ce n’est pas la fin du monde, surtout si cela se produit sur un blog personnel, vous avez déjà pris du temps pour écrire et partager vos connaissances, et votre lecteur ne vous jugera pas pour cela.

Comme le titre l’indique, il s’agit d’une dernière revue, alors ne révisez pas encore et encore. Je sais qu’il peut être tentant d’améliorer à nouveau votre texte. Je pense que ça peut être mieux comme ça. Je pense que je suis allé trop dans les détails dans cette partie et pas assez dans celle-là. La formulation n’est pas super ici. Et si j’utilisais cette phrase à la place? Soyons honnêtes, il y a peu de chance que vous soyez pleinement satisfait.

Puisque vous avez déjà passé plusieurs heures sur votre article, il est temps de lâcher prise et de cliquer sur le bouton de publication! Ah, enfin, n’oubliez pas de trouver un bon titre, il doit être court, accrocheur et véhiculer l’idée principale de votre article.


Traduction facultative

Dans mon cas, je n’ai pas encore fini, je dois aussi traduire l’article en français avant de publier.

Bien que le français soit ma langue maternelle, je prends des raccourcis pour accélérer le processus de traduction et j’utilise Google Translate. Je peux donc partir d’une base et d’un texte déjà traduit que je peux ensuite relire, reformuler quelques phrases ici et là. La traduction automatique n’est pas parfaite, mais je dois dire qu’elle est plutôt bonne, je dirais qu’environ 70% du contenu est généralement laissé intact ou avec des modifications mineures.

A moins que je doive recréer quelques schémas en français, la traduction est probablement la partie la plus rapide à faire, puisque je garde les mêmes images, le texte et la mise en forme, et le français est évidemment plus facile pour moi…

Processus écrire article


Bon blog!

Articles similaires

androidListe de mes applications Android favorites Windows 7Test de Windows 7 EclEmmaEclEmma – Une bonne couverture pour l’hiver Maven sitePlus loin avec le Maven Site
Commentaires
Pas de Commentaires »
Catégories
Management
Tags
blog, bonnes pratiques, partage, société, write
Flux rss des commentaires Flux rss des commentaires

Attaques de robots: vous n’êtes pas seul…

Fabian Piau | mardi 20 avril 2021 - 16:42
  • Imprimer
  • Twitter
  • LinkedIn
  • Facebook
  • Pocket

 English version available

Remarque
J’ai publié cet article pour la première fois sur le blog tech d’Expedia Group sur Medium (en anglais): Bot Attacks: You are not alone…

Dans un article récent, Security Magazine a déclaré que 1,3 milliard attaques de robots ont été détectées au troisième trimestre 2020. Ce n’est pas une surprise. Nous ne sommes pas seuls. Vous n’êtes pas seul.

L’année dernière, l’équipe Opex Excellence d’Expedia Group a passé en revue tous les incidents survenus en production ayant impacté le site Hotels.com. Nous avons couvert une période de 12 mois et nous avons identifié les attaques de robots comme étant l’une des menaces les plus importantes.

Anything that can go wrong will go wrong — Murphy’s law

Dans cet article, je vais définir et expliquer ce que sont les robots et les attaques de robots. J’espère que cela vous permettra d’acquérir des connaissances pour mieux comprendre cette menace qui plane sur votre site web, afin que vous puissiez mettre en place un ensemble de stratégies et solutions pour prévenir et atténuer l’impact d’une attaque si vous y êtes confronté.

Know the enemy and know yourself, in a hundred battles you will never be in peril — Sun Tzu, The Art of War

Bots - Photo par Eric Krull sur Unsplash

Qu’est ce qu’une attaque de robots?

Le premier type d’attaque de robots qui vient généralement à l’esprit est l’attaque de type déni de service (Denial of Service – DoS) ou DDoS (lorsqu’elle est distribuée). Une attaque DDoS affecte généralement l’ensemble du site, les erreurs se produisant en cascade, rendant le site indisponible. L’attaquant envoie un grand nombre de requêtes (par exemple, en effectuant simultanément une énorme quantité de requêtes GET / POST sur des URLs aléatoires) afin de surcharger les services sous-jacents à tel point qu’ils ne peuvent plus gérer le trafic. Les services commencent à répondre aux requêtes avec des réponses en timeout ou en erreur. Evidemment, cela affecte également les requêtes venant de clients légitimes – dans notre cas, des clients qui tentent de réserver leur séjour à l’hôtel.

Un autre type d’attaque, légèrement plus ciblé, est une attaque de type scraping. Un robot d’exploration (crawler) peut scanner différentes pages afin d’extraire des informations spécifiques. Ceci est également connu sous le nom de data scraping. Ces robots ciblent généralement vos données d’inventaire, par exemple tous les détails des hôtels avec les informations de contact, ou les différents prix pour des dates spécifiques. Parfois, il peut même s’agir de l’intégralité du contenu de certaines pages de votre site web, afin de les reproduire à l’identique pour préparer une attaque de phishing.

ℹ️ Dans l’idéal, l’attaquant ne veut pas être vu quand il scanne et récupère des informations. Bien souvent, il essaiera de dissimuler ses traces en attaquant sur une plus longue durée, par exemple sur plusieurs jours pour éviter une augmentation du trafic soudaine qui pourrait déclencher une alerte et une investigation du côté de la victime. A moins que l’attaque ne soit sophistiquée et ne provienne de différentes machines, elle est en général assez facile à identifier lorsqu’il y a un nombre anormalement élevé de requêtes provenant de la même adresse IP (ou plage d’adresses IP) au niveau Edge. Je donnerai plus de détails sur le niveau Edge dans la partie suivante.


Si les attaques de type DoS et scraping ont une portée étendue, dans le sens où elles s’attaquent à des pans entiers du site, nous constatons également des attaques chirurgicales ciblant des pages et fonctionnalités spécifiques.

Les attaques spécialisées sont bien plus précises et ciblent généralement une page ou une fonctionnalité spécifique de votre site. Voici quelques cas réels auxquels nous avons été confrontés:

  • Une attaque sur la page de réservation, lorsque l’attaquant tente de trouver des coupons en générant et en essayant plusieurs codes, en espérant pouvoir trouver et exploiter un pattern. Cette attaque utilise la force brute.
  • Une attaque sur la page de connexion, lorsque l’attaquant tente plusieurs combinaisons de login et de mot de passe. L’idée est d’avoir accès aux comptes utilisateurs et aux données confidentielles, ou ce que nous appelons Account Take Over (ATO). Cela utilise également la force brute.
  • Une attaque sur la page de l’application mobile, lorsque l’attaquant tente d’envoyer un grand nombre de SMS à des numéros de téléphone aléatoires ou faux. Il est assez courant de nos jours d’inviter les utilisateurs à télécharger une application sur leur appareil mobile en envoyant un SMS contenant le lien vers l’application sur l’App Store. Le site web ciblé finira par payer de l’argent, car le service de messagerie est généralement géré par un fournisseur tiers et chaque SMS envoyé a un coût.

Générale ou spécifique, une attaque peut être basique ou sophistiquée. Un exemple d’attaque basique est une personne qui essaie désespérément de trouver un code de réduction en envoyant des dizaines de requêtes à un service de coupons. Les attaques de base sont difficiles à repérer, mais faciles à bloquer: vous pouvez bloquer l’adresse IP avec une règle WAF (Web Application Firewall). Le risque reste faible.

Et il y a les attaques sophistiquées, elles peuvent être distribuées et étendues sur des milliers de machines situées dans différents pays et utilisant des technologies de script avancées, comme un navigateur headless. Le niveau d’impact et de risque est beaucoup plus élevé, mais ils sont évidemment plus faciles à repérer comme elles sont associées à une montée en charge soudaine du trafic.

Matrice de risque d'attaque de robots

Doit-on bloquer tous les robots?

Evidemment non! Tous les robots ne sont pas mauvais, certains sont même bienveillants.

  • Il existe les robots d’exploration (spider et crawler bots) des moteurs de recherche populaires tels que Google Search ou Microsoft Bing. Si vous les bloquez, l’indexation du site sera fortement impactée, le trafic légitime se dégradera avec le temps et la popularité du site diminuera.
  • Il existe également les robots commerciaux (ad bots, par exemple, le robot Google AdSense), pour proposer des publicités personnalisées aux utilisateurs, y compris les publicités pour votre propre site.
  • Il y a les robots de données (data bots) comme les agrégateurs de contenu et de flux, et il y a aussi le robot archiveur qui construit la plus grande archive Internet.
  • Il existe aussi les robots de copyright, qui traquent plagiat et vol de propriété intellectuelle. Vous avez peut-être rencontré l’un d’entre eux si vous avez essayé d’uploader une vidéo sur YouTube avec votre musique préférée en arrière-plan. Vous réalisez alors rapidement que Google l’a supprimée, en vous rappelant poliment que vous ne pouvez utiliser aucun contenu protégé.
  • Il existe également des robots de surveillance pour vous assurer que votre site est en bonne santé et vous signaler quand ce n’est pas le cas. Par exemple, Akamai, Datadog, etc. utilisent des robots pour s’assurer que votre site répond correctement.

ℹ️ Vous ne devez bloquer aucun de ces robots, car ils ne sont pas mauvais, et généralement ils ne sont pas agressifs, et en plus ils contribuent à Internet. Néanmoins, si vous pensez que votre trafic légitime en souffre, au lieu de les bloquer, il est préférable de mettre en place une stratégie de limitation de débit pour atténuer leur impact. Plus de détails à ce sujet dans la partie suivante à propos du niveau Edge.

Si tous ces robots sont des tiers, vous pouvez parfois avoir votre propre robot. Dans notre cas, un robot interne vérifie régulièrement les pages de destination pour s’assurer qu’il n’y a pas de liens morts ou de redirections inutiles. Nous ne voulons donc certainement pas le bloquer!

Que faire contre les attaques?

Nous pouvons empêcher les attaques au niveau Edge et les atténuer au niveau Applicatif.

Niveaux Edge et Applicatif

Utilisation du fichier robots.txt

La première chose qui peut vous venir à l’esprit lorsque vous souhaitez manipuler des robots est le fichier robots.txt. Il est présent sur chaque site web et il existe depuis des lustres. Il s’agit d’un fichier texte accessible publiquement à la racine de votre site. Il spécifie les règles pour tous les robots accédant à votre site. Ces règles définissent les pages que les robots peuvent et ne peuvent pas explorer, et quels liens ils doivent et ne doivent pas suivre.

Les robots bienveillants suivront ces règles. Par exemple, si un propriétaire de site web ne souhaite pas qu’une certaine page de son site apparaisse dans les résultats de recherche Google, il peut écrire une règle pour celle-ci, et le robot d’exploration de Google n’indexera pas cette page. Bien que le fichier robots.txt ne puisse pas appliquer ces règles lui-même, les robots bienveillants sont programmés pour rechercher ce fichier et suivre les règles avant de faire quoi que ce soit d’autre. Cela se base sur un code d’honneur en quelque sorte.

Les mauvais robots malveillants ne suivront évidemment aucune de vos règles. Au contraire, ils le liront souvent pour savoir quel contenu un site tente de leur interdire, puis accéderont à ce contenu. Ainsi, la gestion des robots nécessite une approche plus active que la simple définition des règles de comportement des robots dans le fichier robots.txt. C’est ce que nous allons voir dans la partie suivante.

ℹ️ Le fichier robots.txt peut également être utilisé comme un piège, en exposant un leurre qui permet d’exposer les robots malveillants. Le leurre peut être une page du site interdite aux robots par le fichier robots.txt. Les robots bienveillants liront le fichier robots.txt et éviteront cette page, alors que les mauvais robots exploreront cette page. En suivant les informations des robots qui accèdent à cette page piégée, les robots malveillants peuvent être identifiés et bloqués. Source: Cloudflare


Gestion avancée des robots

Le principal rempart contre les mauvais robots est la gestion des robots au niveau Edge. Cette défense est beaucoup plus avancée que le fichier robots.txt. J’ai pris cette liste sur Cloudflare mais les fonctionnalités seront similaires pour tout autre outil Edge:

  • Différencie les robots par rapport aux visiteurs humains (à l’aide de l’analyse comportementale et potentiellement de l’apprentissage automatique)
  • Calcule la réputation des robots
  • Identifie les adresses IP d’origine des robots et les bloque en fonction de la réputation IP
  • Analyse le comportement des robots
  • Ajoute les robots bienveillants aux listes d’autorisation
  • Ajoute les robots malveillants aux listes de blocage
  • Challenge les robots potentiels via un test CAPTCHA, une injection JavaScript ou d’autres méthodes
  • Limite le taux de requêtes d’un robot potentiel sur-utilisant un service
  • Ralentit les requêtes de robot, également connu sous le nom de ‘Tarpitting’ (voir la définition ci-dessous)
  • Refuse l’accès à certains contenus ou ressource pour les robots malveillants
  • Diffuse du contenu alternatif ou mis en cache aux robots

ℹ️ ‘Tarpitting’ est une fonctionnalité intéressante. Cela signifie ajouter un délai artificiel à la requête. C’est généralement bien plus efficace que le blocage, car le robot ne saura pas qu’il a été découvert, mais l’attaque ralentira considérablement car moins de requêtes atteindront le niveau Applicatif, car elles pourraient expirer au niveau Edge. La limitation de débit peut également être une autre bonne stratégie que vous voudriez peut-être envisager.

Lorsque vous choisissez un gestionnaire de robot avancé, vous pouvez utiliser un fournisseur tiers populaire tel que Akamai ou Cloudflare.

Pros

  • Aucun impact sur le code de l’application.
  • Une règle de robot est relativement rapide à déployer avec un effet immédiat.

Cons

  • La plupart des inconvénients résident dans le fait que ce sont des outils tiers.
  • Il y a un coût de licence.
  • Les règles de robot ne peuvent être définies que par rapport à des paramètres génériques tels que le user-agent, l’adresse IP, l’URL, etc.
  • Ils impliquent parfois un processus d’approbation lourd, par ex. l’ajout d’une nouvelle règle nécessitera des personnes extérieures à l’entreprise ainsi que des personnes internes disposant d’une autorisation spéciale.
  • Une nouvelle règle peut avoir des effets secondaires. A moins de bloquer une adresse IP unique, il est très difficile d’être sûr que cela ne bloquera aucun trafic légitime.
  • La gestion des règles peut être fastidieuse au fil du temps.
  • Accès et visibilité partiels pour les équipes applicatives.

La plupart des inconvénients peuvent être contournés si vous utilisez votre propre outil Edge interne. C’est particulièrement intéressant lorsqu’il est utilisé en supplément d’un outil Edge tiers. C’est un investissement lourd et toutes les entreprises ne pourront pas se le permettre, mais cela donnera beaucoup plus de flexibilité et ouvrira des possibilités.

  • Possibilité de définir des règles fonctionnelles liées à votre business.
  • Possibilité d’ajouter une règle temporaire ponctuelle pour atténuer une attaque que vous pouvez supprimer peu de temps après la fin de l’attaque.
  • Possibilité de centraliser la surveillance Edge et de mettre les informations à la disposition de chaque équipe.


Hiérarchisation du trafic

L’idée ici n’est pas de remplacer votre outil Edge principal, mais d’ajouter une logique de priorisation des robots après ce premier rempart. Un tel outil agira comme une file d’attente de hiérarchisation afin que les requêtes de robot à faible valeur soient dépriorisées en faveur des requêtes d’utilisateurs réels qui ont une valeur commerciale plus élevée, avec une réservation potentielle dans notre cas.

Requêtes des utilisateurs > Requêtes des robots internes > Requêtes des robots bienveillants externes

ℹ️ Netflix applique des concepts similaires que vous pouvez lire dans Keeping Netflix Reliable Using Prioritized Load Shedding (en anglais).


Mise en cache

Nous avons parlé de gestion de robot, mais il y a autre chose que la couche Edge peut vous fournir, à savoir la possibilité de mettre en cache le contenu. Nous référons généralement cela à un Content Delivery Network (CDN). L’idée est de proposer des pages mises en cache aux robots bienveillants plutôt que de générer de nouvelles pages.

Nous avons fait des expérimentations l’année dernière et cela a considérablement réduit le trafic vers certains de nos services Backend sans affecter le référencement du site. Cette année, nous cherchons à généraliser cette approche.


Atténuation au niveau applicatif

La gestion des robots au niveau de l’application signifie qu’une attaque de robots a pu passer entre les mailles du filet au-delà du niveau de protection supérieur fourni par l’Edge.

Les solutions dont nous disposons à ce niveau ne sont que des solutions d’atténuation afin d’être proactif et de réduire au maximum les conséquences d’une attaque.

Malheureusement nous savons que cela va arriver tôt ou tard, et même plusieurs fois, nous devons donc nous y préparer. Heureusement, ce que nous savons, c’est que les attaques de robots ne durent pas éternellement. Une attaque sophistiquée coûte une quantité importante de ressources à l’attaquant, et comme les ressources coûtent de l’argent. Tant que nous faisons en sorte que l’attaquant dépense plus de valeur qu’il n’en obtient, nous sommes certains que l’attaque se stoppera d’elle-même.

Il y a différentes actions que nous pouvons entreprendre, pour la plupart il s’agit de bonnes pratiques…

  • Tout d’abord, lors du coding de l’application, il faut éviter d’avoir un code de grande complexité, de bloquer des threads, etc. Une bonne idée est de séparer les ports d’application et de gestion. Si vous utilisez le même port, en cas d’attaque de robots, le service sera tellement surchargé qu’il ne pourra pas répondre aux healthchecks et votre plate-forme d’infrastructure pensera que le service est défectueux. Même si cela ne résout pas tous vos problèmes, le fait d’avoir un port distinct peut atténuer ce problème.
  • Avoir un état d’esprit chaotique (chaos engineering) est important. Pour les services critiques, assurez-vous d’avoir des tests de charge et de stress en place dans votre pipeline. Cela permet de garantir que vos services sont suffisamment résilients et que vous avez identifié des fuites de mémoire potentielles dans votre code, des goulots d’étranglement atteignant les services en aval ou les sources de données. En cas de problème, vous souhaitez toujours fournir une réponse dégradée pour atténuer l’impact sur le client. Vous pouvez également mettre en place un mécanisme de mise en cache.
  • Assurez-vous de tirer parti de votre infrastructure. Si vous utilisez Kubernetes, vous pouvez jeter un oeil à l’autoscaling. Soyez vigilant lorsque vous l’activez. Assurez-vous que la configuration du service est bien pensée et conforme à ses dépendances. En effet, configurer un nombre élevé de pods et considérer le travail terminé sera une erreur, car vous partagerez également la charge avec vos dépendances en aval et, si elles ne sont pas préparées pour cela, vous déplacerez fondamentalement le goulot d’étranglement plus profondément dans la pile sans le résoudre. Cela peut également vous coûter plus cher si votre infrastructure est hébergée sur un fournisseur de cloud comme AWS. Assurez-vous également que vos pods sont prêts à recevoir du trafic une fois qu’ils sont exposés à l’attaque. Une warm up routine comme Mittens pourra être utile, en particulier pour les applications qui mettent du temps à démarrer.

Il existe également d’autres stratégies au niveau applicatif qui ne sont pas liées à la configuration et à l’infrastructure. Certaines reproduisent ce que l’on trouve avec une solution de gestion de robot au niveau Edge:

  • Mécanisme Captcha. Une méthode courante consiste à afficher un captcha à l’utilisateur s’il y a trop de tentatives, ou à cibler les attaques liées aux comptes utilisateurs.
  • Mécanisme d’authentification. Si vos API sont publiques, vous pouvez ajouter une authentification, simple comme ‘Basic Auth’ ou plus complexe comme ‘CSRF Token’. Mais vous devez être conscient que cela ajoutera de la complexité à votre système et que vous devez donc trouver un équilibre, par exemple, demandez-vous si les informations exposées par votre API sont suffisamment sensibles pour être protégées.
  • Mécanisme de mise en cache, de blocage et de limitation du débit. Cela peut être assez complexe à réaliser et à maintenir, en particulier dans une architecture micro-service, mais je préfère le mentionner, car cela pourrait être une solution potentielle si vous n’avez pas d’outil Edge ou si vous travaillez sur une application monolithique.


Observabilité, Surveillance et Alerte

Enfin, il est très important que vous ayez une observabilité appropriée en place sur votre site. Toutes les attaques de robots qui deviennent suffisamment sérieuses et commencent à exercer une forte pression sur votre système devraient déclencher automatiquement un ensemble d’alertes.

Au niveau Edge:

  • Alerte sur les règles de robots lorsqu’une règle créée récemment bloque trop de trafic ou, au contraire, lorsqu’une règle n’a bloqué aucun trafic au cours des ‘n’ derniers mois et peut être réexaminée pour une éventuelle suppression.
  • Alerte lorsque le trafic du robot (bon ou mauvais) est beaucoup plus élevé que d’habitude.

Au niveau des applications et de l’infrastructure:

  • Alerte sur l’auto-scaling et le nombre d’instances. Par exemple, quand Kubernetes ajoute 5 nouveaux pods au cours des 5 dernières minutes et que ce n’est pas Black Friday, il y a probablement quelque chose de louche…
  • Alerte sur le temps et le statut des réponses lorsque le service commence à répondre lentement et/ou avec des erreurs. Je vous recommande de lire Creating Monitoring Dashboards (en anglais), qui couvre tout ce que vous devez savoir sur le monitoring.
  • Vous pouvez également configurer certaines alertes au niveau des logs. Cela peut être utile si vous n’exposez pas certaines métriques dans votre application et si vous utilisez un outil avancé de gestion de logs comme Splunk.

Le mot de la fin

J’espère que cet article vous a été utile et que vous avez maintenant une meilleure connaissance des robots et des attaques qu’ils peuvent impliquer.

Je n’ai discuté d’aucune solution miracle ici, car il n’existe pas un outil anti-robot parfait pour tout le monde. Mais il y a toujours place à l’amélioration pour prévenir et atténuer les attaques de robots.

Ah… Et bonne chance pour la prochaine attaque! 👋 🤖

Commentaires
Pas de Commentaires »
Catégories
Technologie
Tags
attaque, bonnes pratiques, gestion des incidents, robot, robots, sécurité
Flux rss des commentaires Flux rss des commentaires
Page 1 sur 5012345…102030…50
Télécharger l'app CarmaBlog

Flux RSS

  • Flux RSS RSS - Articles
  • Flux RSS RSS - Commentaires

Articles les plus vus

  • Changer la langue de Firefox - 115 579 vues
  • Réaliser un sondage en ligne avec Google Forms / Drive / Docs - 63 166 vues
  • FAQ – Sondage en ligne avec Google Forms / Drive / Docs - 52 403 vues
  • Personnaliser Gnome 3 (Shell) - 30 017 vues
  • La signification d’URL, URI et URN - 17 251 vues
  • Java EE & CDI vs. Spring - 15 442 vues
  • Open Street Map, une meilleure carte que Google Maps? - 14 648 vues
  • Comparaison NoSQL: Couchbase et MongoDB - 14 082 vues
  • Firefox Nightly, Aurora, Beta, Desktop, Mobile, ESR & Co. - 13 087 vues
  • API, REST, JSON, XML, HTTP, URI… Vous parlez quelle langue en fait? - 12 718 vues

Commentaires récents

  • Pauline sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsMerci Fabian, mais le but étant que nos clients pu…
  • Fabian Piau sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsProbablement mais ces options sont en général paya…
  • Pauline sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsBonjour Fabian, Merci de votre retour, oui j'avais…
  • Fabian Piau sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsBonjour Pauline, ce n'est pas possible de créer un…
  • Pauline sur FAQ – Sondage en ligne avec Google Forms / Drive / DocsBonjour, Je suis en train de créer un Google Forms…

Articles récents

  • Comment écrire un article de blog? En tout cas à ma façon! - Il y a 3 mois et 2 semaines
  • Attaques de robots: vous n’êtes pas seul… - Il y a 1 an et 11 mois
  • Flagger – Monitorer vos déploiements Canary avec Grafana - Il y a 2 ans et 8 mois
  • Flagger – Déploiements Canary sur Kubernetes - Il y a 2 ans et 10 mois
  • Flagger – Premiers pas avec Istio et Kubernetes - Il y a 2 ans et 10 mois
  • CoderDojo Expedia à Londres - Il y a 3 ans et 7 mois
  • Etre bénévole à Devoxx4Kids - Il y a 3 ans et 10 mois
  • Une migration Java 11 réussie - Il y a 4 ans et 2 mois
  • Conseils pour sécuriser votre site WordPress - Il y a 4 ans et 5 mois
  • Devoxx UK 2018 – Jour 2 - Il y a 4 ans et 9 mois
  • Devoxx UK 2018 – Jour 1 - Il y a 4 ans et 9 mois
  • Wise, Revolut et Monzo, une petite révolution dans le monde des expatriés et voyageurs - Il y a 5 ans et 1 mois
  • Autocomplétion pour Git - Il y a 5 ans et 10 mois
  • Swagger, la documentation API automatisée - Il y a 6 ans et 2 semaines
  • Architecture Microservices – Les bonnes pratiques - Il y a 6 ans et 5 mois
Offre moi un café

Langue

  • Français
  • English

Suivez-moi!

Suivez-moi sur Linkedin
Suivez-moi sur Twitter
Suivez-moi sur Stackoverflow
Suivez-moi sur Github
Suivez-moi sur Rss
Link to my Contact

Abonnement email

Saisissez votre adresse email pour être informé des nouveaux articles.

Étiquettes

.net agile agilité android bash blog bonnes pratiques cache cloud conférence css devoxx docker développeur eclipse extreme programming firefox flagger google helm hibernate informatique intégration continue istio java jug kubernetes londres mobilité informatique métier outil panorama partage performance plugin programmeur script société spring sécurité tdd test ubuntu windows wordpress

Liens

  • Blog Ippon Technologies
  • Blog Publicis Sapient
  • Blog Zenika
  • Classpert
  • CommitStrip
  • Coursera
  • Le Touilleur Express
  • Les Cast Codeurs Podcast
  • OCTO talks !
  • The Twelve-Factor App

Catégories

  • Evénement (15)
  • Linux (3)
  • Management (8)
  • Programmation agile (29)
  • Technologie (45)

Archives

  • décembre 2022 (1)
  • avril 2021 (1)
  • juin 2020 (1)
  • mai 2020 (2)
  • juillet 2019 (1)
  • mai 2019 (1)
  • décembre 2018 (1)
  • octobre 2018 (1)
  • juin 2018 (1)
  • mai 2018 (1)
  • janvier 2018 (1)
  • mai 2017 (1)
  • mars 2017 (1)
  • octobre 2016 (1)
  • avril 2016 (2)
  • mars 2016 (1)
  • novembre 2015 (1)
  • mai 2015 (1)
  • février 2015 (1)
  • décembre 2014 (1)
  • novembre 2014 (1)
  • septembre 2014 (2)
  • août 2014 (1)
  • juillet 2014 (2)
  • juin 2014 (1)
  • avril 2014 (1)
  • mars 2014 (1)
  • février 2014 (2)
  • janvier 2014 (1)
  • décembre 2013 (1)
  • novembre 2013 (1)
  • octobre 2013 (3)
  • septembre 2013 (5)
  • juillet 2013 (1)
  • juin 2013 (1)
  • mai 2013 (1)
  • avril 2013 (1)
  • mars 2013 (2)
  • février 2013 (1)
  • janvier 2013 (2)
  • décembre 2012 (2)
  • octobre 2012 (1)
  • septembre 2012 (1)
  • juillet 2012 (1)
  • mai 2012 (1)
  • avril 2012 (1)
  • mars 2012 (1)
  • février 2012 (1)
  • janvier 2012 (2)
  • décembre 2011 (1)
  • novembre 2011 (2)
  • octobre 2011 (2)
  • septembre 2011 (1)
  • juillet 2011 (1)
  • juin 2011 (2)
  • avril 2011 (1)
  • mars 2011 (1)
  • février 2011 (1)
  • janvier 2011 (2)
  • novembre 2010 (2)
  • septembre 2010 (1)
  • août 2010 (1)
  • juillet 2010 (1)
  • juin 2010 (1)
  • mai 2010 (1)
  • avril 2010 (1)
  • mars 2010 (1)
  • février 2010 (1)
  • décembre 2009 (1)
  • novembre 2009 (1)
  • octobre 2009 (2)
  • septembre 2009 (2)
  • août 2009 (3)
  • juillet 2009 (1)
  • juin 2009 (2)
Suivez-moi sur Twitter
Suivez-moi sur Linkedin
Suivez-moi sur Stackoverflow
Suivez-moi sur Rss
Link to my Contact
Suivez-moi sur Github
 
Fabian Piau | © 2009 - 2023
Tous droits réservés | Haut ↑