PROJET AUTOBLOG


Korben

source: Korben

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Découvrez le mouvement ServerLess

lundi 12 février 2018 à 07:27

Si vous êtes développeur et que tout ce qui est administration système vous donne des boutons, j'ai découvert un truc qui s'appelle ServerLess et qui je pense va vous intéresser.

ServerLess est un mouvement "spirituel" (bon j'exagère un peu, mais vous voyez l'idée) qui permet de redonner le pouvoir aux développeurs qui souhaitent se concentrer uniquement sur leur code. Je ne suis pas développeur (d'où ma découverte tardive de ce truc), mais j'ai trouvé ça passionnant, ce qui explique cet article d'aujourd'hui.

Cette technologie permet de faire abstraction de tout ce qui concerne l'hébergement et le déploiement de votre application. Grâce à l'approche ServerLess, vous allez pouvoir développer directement des applications qui vont supporter un trafic en production et que vous n'aurez pas besoin de scaler. Pas besoin non plus de provisionner des serveurs et de payer des ressources non utilisées. Pas besoin de mettre à jour un Linux… Bref, plus besoin de se concentrer sur des actions à peu de valeur ajoutée pour vos utilisateurs.

Et le secret de tout ça c'est AWS Lambda, Microsoft Azure, Google Cloud Platform ou encore IBM OpenWhisk qui proposent des offres FaaS (Function As A Service) permettant de faire exécuter votre code sur une infrastructure de calcul à haute disponibilité et de faire effectuer au provider du service toute l'administration des ressources de calcul, y compris la maintenance du serveur et du système d'exploitation, le dimensionnement des capacités et la mise à l'échelle automatique, le déploiement du code et des correctifs de sécurité, ainsi que la surveillance et la journalisation du code.

ServerLess exploite donc ce concept de FaaS pour redonner une entière autonomie aux développeurs et leur fera surtout gagner du temps. Et même si je suis plutôt partisan de gérer soi-même son serveur et éviter de tout mettre chez Amazon, Google ou un autre, il faut reconnaître que le côté "J'ai plus qu'à coder et basta !" fait saliver. Cela peut-être aussi intéressant pour du déploiement en test, car la plupart des fournisseurs FaaS proposent des offres gratuites en dessous d'un certain nombre de requêtes mensuelles. Par exemple, chez Amazon, c'est 1 million de requêtes offertes ainsi que 400 000 Go-secondes de temps de calcul par mois.

Le Framework ServerLess que vous pouvez trouver ici permet donc de déployer facilement votre code chez le provider de votre choix, en configurant automatiquement les paramètres qui vont bien, le langage que vous utilisez, et les plugins ServerLess dont vous avez besoin. Et ensuite, c'est easy :

#Install serverless globally
npm install serverless -g

#Login to your Serverless account
serverless login

#Create a serverless function
serverless create --template hello-world

#Deploy to cloud provider
serverless deploy

#Function deployed! Trigger with live url
http://xyz.amazonaws.com/hello-world

L'approche ServerLess a déjà été adoptée par des gros comme Coca Cola, Expedia, Reuters, ou encore EA. Et pour le coup, vous ne paierez que ce que vous consommerez.

Bref, à tester à l'occasion.

Et si vous restez sur votre faim après la lecture de cet article d'introduction, je vous invite à lire celui-ci beaucoup plus détaillé sur le sujet.

Une Nintendo Switch avec Linux dessus, grâce à un bug qui ne peut pas être corrigé

samedi 10 février 2018 à 00:38

Il n'y a pas beaucoup d'infos, mais c'est dans un tweet que fail0verflow qu'on ne présente plus, a publié il y a quelques jours cette photo d'une Nintendo Switch avec un joli Linux dessus.

D'après fail0verflow, son exploit utilise un bug situé dans la rom nécessaire au boot, ne nécessite aucune puce et qui plus beau encore, ne peut pas être patché sur les Switch sorties jusqu'à présent.

Bien que Nintendo propose depuis l'année dernière, un programme de Bug Bounty pour justement récompenser ce genre de découverte et corriger ses vulnérabilités, il semble que certains préfèrent s'amuser avec des homebrews et éventuellement plus tard, avec des jeux piratés sur des consoles rootées.

Affaire à suivre, surtout si effectivement, l'impossibilité de patcher s'avère vraie.

Oji – Pour fabriquer vos emojis text (◕‿◕)

vendredi 9 février 2018 à 22:41

Vous connaissez sans doute ces petits emojis tout en texte construits à base de parenthèses et autres caractères ASCII.

Comme ce petit joyeux…

\ (•◡•) /

ou encore ce gros musclé…

ᕦ(ò_óˇ)ᕤ

Et bien, il existe un constructeur d'emoji texte nommé oji à installer comme ceci :

npm i -g oji

Lancez ensuite oji et vous n'aurez plus qu'à sélectionner les petits morceaux de votre emoji et laisser libre cours à votre créativité.

Ça ne sert pas à grand-chose donc c'est méga indispensable. 😉

Et si comme moi, vous n'avez aucun talent de création en emoji text, voici 2 sites qui vous en donneront des tous tout fait, tout beau.

Ce qu’on ne peut pas s’acheter avec 45 000 $

vendredi 9 février 2018 à 18:14

Zerodium, spécialisé dans l'achat / revente de vulnérabilité 0day a fait hier, une annonce sur son compte Twitter.

Si pour vous tout ceci n'est qu'un amas de gros mots techniques, je vous explique. En gros, Zerodium propose 45 000 $ en échange d'un 0day (une vulnérabilité non patchée et non connue) fonctionnant avec les distribs Linux les plus connues (Fedora, Ubuntu, Debian, CentOs et Red Hat Entreprise).

À titre de comparaison, ils avaient, il y a quelques années, proposé 1,5 million de $ pour un 0day touchant iOS 10.

Big bounties, small penis

45 000$ c'est une belle somme et ça pourrait tenter pas mal de monde. Mais ce business reste un business de merde, et je vais vous expliquer pourquoi.

Premièrement, s'ils lancent cet appel, c'est qu'ils ont des clients. Probablement des gouvernements ou des boites privées puissantes. L'objectif de ces clients, c'est de pouvoir s'introduire sur des machines Linux pour les véroler ou en sortir des informations. Y'a pas vraiment de mystère.

Le premier problème, c'est que par définition, celui qui vendra son 0day à Zerodium se fera arnaquer. 45 000$ un 0day qui sera surement revendu avec une doc d'utilisation, le double de son prix (voire plus) à 2, 3, 4…10 ou 100 clients, j'appelle ça se faire arnaquer 🙂

Bon, ça c'était pour la blague.

Maintenant ce qui est grave c'est-ce que ce 0day va permettre.

Repensez aux révélations Snowden, repensez à votre vie privée et à votre vie tout court. Un 0day Linux qui grosso modo peut ouvrir une porte sur un grand nombre de serveurs est un sacré problème, y compris si vous n'avez pas de machine Linux sous la main. Car vous ne le savez peut-être pas, mais toutes vos données et votre activité en ligne circulent ou se retrouve stockées sur des machines Linux. Donc même si vous êtes un utilisateur lambda, cela vous concerne totalement.

Pensez ensuite aux gens qui pourraient souffrir directement d'une telle arme. Les activistes, les opposants politiques, les gens qui travaillent dans les entreprises et qui ont des secrets industriels à défendre, les gouvernements au travers de ses soldats ou de ses agents sur le terrain, sans parler de ceux qui se retrouveraient en position de subir un chantage ou une humiliation à cause de données dérobées via de tels moyens.

Le champ des possibilités est vaste et même si on est totalement dans les hypothèses, celles-ci sont parfaitement plausibles, car déjà vues.

Et je ne vous parle pas, le jour où le 0day est enfin découvert et annoncé publiquement, du bad buzz que cela peut ensuite avoir sur Linux, sur les sociétés touchées, sur les serveurs non patchés subissant les ravages des scripts kiddies et bien sûr de la surcharge de boulot non prévue pour les admin sys et la communauté Open Source.

J'ai beau retourner le problème dans tous les sens, vendre une telle vulnérabilité à un tiers qui est tout sauf de confiance, c'est un peu comme vendre une kalachnikov à un intermédiaire, sans savoir qui va l'utiliser, ni quand et contre qui, tout en espérant qu'on ne sera pas l'une des victimes.

Maintenant c'est sûr, 45 000$ c'est une belle somme. On peut s'en payer des jolies choses avec 45 000$… Une belle voiture, des travaux pour la maison, faire la fête pendant 1 an, ou arrêter de bosser quelques temps.

Mais s'il y a un truc que vous ne pourrez pas vous payer avec ces 45 000$, ce sera une éthique. Car oui, quoi qu'en disent les pubs à la TV et quoi qu'en disent les médias qui s’esclaffent sur la proposition de Zerodium, la notion d'éthique reste à mon sens primordial.

Car toute l'année, que ce soit mes copains de YesWeHack, ou d'autres hackers de par le monde, on se casse le cul à sécuriser la planète, à remonter le niveau de compétence des gens et des boites dans un seul but : Que chacun puisse évoluer dans le cyberespace avec une relative tranquillité d'esprit.

Tout n'est pas parfait, c'est sûr, mais ça va dans le bon sens pour servir l'intérêt général, grâce aux efforts de chacun. Malheureusement, l'initiative de Zerodium est à l'opposé de ces efforts.

Seulement, pour contrer de telles pratiques qui n'ont comme but que de faire du pognon au détriment de l'intérêt général, il n'y a malheureusement que 3 possibilités.

– Soit les Américains décident que Zerodium va dans le sens contraire de leurs intérêts, et décident d'interdire de telles pratiques. Mais j'imagine que cela n'arrivera jamais, car ils sont surement leurs premiers clients et ont probablement négocié quelques exclusivités mondiales avec eux.

– Soit je trouve une planche à billets magique, et je propose x3 en pognon pour racheter les 0day avant qu'ils ne tombent entre de mauvaises mains pour ensuite les offrir à la communauté open source dans un cadre de divulgation coordonnée de vulnérabilités.

– Soit, j'en appelle au bon sens, en ayant conscience du côté bisounours de la chose, en expliquant aux gens que tout ceci est éthiquement malsain et que la seule option quand on découvre une vulnérabilité sur un site, un soft, un service (peu importe), c'est de la remonter à celui qui est impacté par ce problème pour qu'il puisse patcher au plus vite.

Pour le moment, à moins que vous ne soyez tous Milliardaires, c'est cette dernière possibilité qui est à notre portée à tous. Et cela peut se faire de 2 façons :

– Via un principe de CVD (Divulgation Coordonnée de Vuln) en passant par une plateforme non-profit comme Zerodisclo.com

– En passant par le Security.txt ou le programme de Bug Bounty de l'organisation / site / projet impacté pour remonter au plus vite la vuln.

Vous voilà informé. N'oubliez pas que la vraie richesse débute quand vous amassez toutes ces petites choses qui ne peuvent pas s'acheter.

À vous de voir maintenant ce que vous préférez.

Le HTTPS, au delà de la sécurité, c’est aussi une question d’image

vendredi 9 février 2018 à 12:11

Si vous avez un site internet, que ce soit un site sur lequel transitent des informations personnelles ou une simple vitrine statique, il est maintenant grand temps, si vous ne l'avez pas encore fait, de passer en HTTPS.

Alors oui, si vos internautes remplissent des champs ou s'identifie avec un mot de passe sur votre site, il est vital que ce dernier propose à minima une connexion HTTPS.

Mais si vous avez un site statique, qui n'est qu'une vitrine et qui ne présente aucun risque à être diffusé via le protocole HTTP uniquement, je vais vous donner 2 bonnes raisons de passer en HTTPS.

La première (et c'est déjà le cas) c'est que Google (et probablement d'autres moteurs de recherche) favorise dans leurs résultats les sites en HTTPS au détriment de ceux en HTTP. Donc si vous avez des besoins de positionnement dans les moteurs de recherche, vous n'avez pas d'autre choix que le HTTPS.

La seconde raison est celle qui va faire le plus mal. À partir de la version 59 de Firefox et de la version 68 de Chrome, TOUS les sites diffusés en HTTP seront marqués dans le navigateur comme "Not Secure" (Pas sécurisé). Même si techniquement l'impact d'un tel marquage est nul, celui en terme d'image auprès de vos internautes va être violent.

Ils seront très peu à savoir exactement de quoi il retourne et la plupart en voyant ce "Not Secure" prendront peur, passeront leur chemin, vous contacteront pour vous faire part du problème ou vous donneront de grandes leçons sur l'importance du chiffrement (ah ah).

Et à service équivalent, entre choisir le joli petit cadenas vert ou l'alerte rouge "Not Secure", je vous laisse deviner où vos internautes iront.

Vous n'avez donc plus le choix. Le HTTP c'est de l'histoire ancienne et vous allez devoir migrer tous vos sites même le plus basique et le moins à risque, en HTTPS, simplement pour préserver votre image 

Si maintenant vous êtes motivé, sachez qu'il existe des tas de tutos sur le net qui expliquent comment faire. De mon côté, j'ai appliqué la méthode Certbot qui est sans doute la plus simple et la plus gratuite 🙂

<style> @import url(https://fonts.googleapis.com/css?family=BenchNine:700); .snip1582 { background-color: #ff7b10; border: none; color: #ffffff; cursor: pointer; display: inline-block; font-family: 'BenchNine', Arial, sans-serif; font-size: 1em; font-size: 22px; line-height: 1em; margin: 15px 40px; outline: none; padding: 12px 40px 10px; position: relative; text-transform: uppercase; font-weight: 700; } .snip1582:before, .snip1582:after { border-color: transparent; -webkit-transition: all 0.25s; transition: all 0.25s; border-style: solid; border-width: 0; content: ""; height: 24px; position: absolute; width: 24px; } .snip1582:before { border-color: #ff7b10; border-top-width: 2px; left: 0px; top: -5px; } .snip1582:after { border-bottom-width: 2px; border-color: #ff7b10; bottom: -5px; right: 0px; } .snip1582:hover, .snip1582.hover { background-color: #ff7b10; } .snip1582:hover:before, .snip1582.hover:before, .snip1582:hover:after, .snip1582.hover:after { height: 100%; width: 100%; } .sniplink { background: none !important; }

À bon entendeur, salut !