1024 c'est obsolète le 4096 ne coute rien c'est mon par défaut en RSA partout, vu le nombre de machine sur le LAN j'utilise Ansible ou mussh...

 

Se faire voler une PI domotique ? Le principe d'une clé publique c'est que tu peux justement la diffuser sans aucun risque. Puis surtout c'est plus facile de refaire un ssh-keygen que d'inventer un autre password

 

Aussi les box d'opérateurs je n'utilise pas. Convertisseur ethernet fibre + machine routeur firewall + switch gigabit manageable c'est la base lol... Faire du spécifique à fond pour ne pas rentrer dans l’intéressant à pirater.

 

Toujours suivre le best pratice ça sert a rien d'en faire de trop et se polluer la vie, la parano c'est du 100% commercial, sauf si on est passionné ou pour s’amuser à apprendre.

 

En d'autres mots t'as toujours des gens qui font planer le petit doute sur la sécurité de l'auto hébergement c'est de la foutaise y'a aucun risque, un peu de bon sens comme aucune commande domotique dangereuse, surveillez que ça fonctionne de temps en temps faire les MAJ Debian et c'est tout.... Même si la Debian comporte pendant un moment the big faille de sécurité ce sera très très vite bouché,

 

Les hackers préfèrent toujours s'attaquer a un système de GRANDE série (comme la Livebox du post de cocothebo) qu'a la PI et au système spécifique de monsieur tartanpion. Un hacker chercheur ou propriétaire de 0day (= nouvelle faille de sécu) qui s'attaque à un truc spécifique -> un humain qui bosse à fond pour trouver une faille sans rien espérer de "gloire" en retour = on est dans du hautement improbable (le hacker zéro gloire ni retour) qui se trouve lui même déjà dans du hautement improbable (le mec avec la 0day debian qui arrive sur ta PI). J'ajoute encore une couche suplémentaire de hautement improbable, ce même hacker nogloire 0day veux et peux réussir à faire un truc mal chez toi avec ta PI et c'est pas déjà cassé en ayant vu l'uname -a....

 

Donc bidouillez et mettez des bidules en ligne sans aucune retenue !!!!

Et au pire, même si le hautement improbable arrive, se faire hacker sa pi et sa box ? la box l'opérateur se débrouille avec, échange gratos. la pi raz la micro SD et on recommence en mieux cette fois ! rien de tel qu'une bonne erreur pour apprendre. c'est meilleur pour le cerveau que le parano qui fait rien qui à peur de tout faire. il est absolument scandaleux de refroidir les débutants en PI pour rien.

 

Déjà le geek qui joue à faire son serveur web avec une PI est capable de lire sur le net et risque forcément moins que celui qui ne fait rien et se fait hameçonner son numéro de CB par email (et même ça osef ya l'assurance systématique&obligatoire) ! Relativise, halte au sketch, c'est que des bouts de fils et de la ferraille y'a strictement aucun risque pour la vie !!!

Faire tourner un service sous un compte non root permet d'avoir la sécurité Linux en second rempart quand le service comporte une faille. C'est pour protéger le reste du système lui même. Et pour augmenter cette sécurité Linux on peux faire tourner le service en chroot (et pleins d'autres astuces).

 

Mais pour une PI domotique si le service est faillible à quoi bon protéger le reste du système linux d'une raspberry PI ? La réponse c'est de protéger le reste du réseau d'une étude et attaque depuis la raspberry PI et dirigée sur une autre machine. Mais pour ça ya beaucoup mieux.

 

Si ya rien à protéger sur le réseau -> genre une box dont le mot de passe n'est pas par défaut + une PI, faire tout tourner en le service en root n'augmente en rien le risque...

 

Le seul risque sur ce genre de réseau minimaliste box + PI c'est de servir d'hébergeur de proxy pour faire des conneries sur internet sous son identité (IP) et dans ce cas le fait de tourner en compte non-root n'apporte presque pas de sécurité. Pour l'augmenter c'est du côté du réseau que ça se passe : isolation de la pi des autres PCs par VLAN domotique, firewall et filtrage en amont (box), le suft (wget) peut être bloqué depuis la PI...

Avec une bonne conf du LAN même si le service tourne en root sans prise de tête cela ne diminue pas significativement le niveau de sécurité.

 

En gros la parade absolue étant de rendre le hack complètement obsolète "tiens t'es root sur cette raspberry PI amuse toi dessus" mais tu peux rien faire d'autre que tuer l'OS de cette même raspberry pi, tu peux jouer avec l'éclairage mais t'as pas accès a mon LAN ni au Web.

Du coup, utiliser des ports moins connus permet aussi d'éviter les Scan bots les plus courant ?

 

Forcément c'est logique... pour retrouver le SSH le bot doit de scanner un certain nombre de ports TCP (il y en a 65535 car 16 bits sans compter le 0 non dispo pour applicatif) + tester le protocole derrière pour voir si il s'agit bien de SSH et pas autre chose...

Les risques sont *quasi* inexistants... Grand adepte du serveur auto hébergé à la maison depuis les débuts d'internet et j'ai jamais eu le moindre problème.

 

Il suffit d'avoir une distrib Linux (préférablement strict minimale en mode console) tenue up to date (apt update / apt upgrade) et appliquer les bases de sécurité dont on trouve les tutos partout sur le net.

 

La base c'est d'avoir un password SSH correct ou mieux : n'accepter qu'une clé RSA privée

(/etc/ssh/sshd_config décommenter le PasswordAuthentication yes et le foutre à no après avoir mis ton id_rsa.pub dans ~/.ssh/authorized_keys et garder au chaud le id_rsa clé privée)

 

Le quasi c'est :

 

 - Se faire DDOS dans le cas d'une connexion ADSL + un gosse sur internet ne t'aime pas et obtient ton IP systématiquement. ça dure jamais bien longtemps et c'est possible dans le cas ou tu fait un site publique ayant un domaine et que le gosse en question ai une pseudo raison d'être innervé après toi.

 

Pour s'amuser (vécu) on peux faire rentrer les fameux vulnerability scan bots dans de fausses machines qui n'ont accès à rien (PI, VMs...) et étudier leurs actions en live.

C'est encore plus drôle quand le "hacker" crois tenir une trouvaille et se connecte manuellement dans le pot de miel monté comme un escape room prévu pour lui faire miroiter des choses tout en le faisant souffrir sur la durée.

 

"tuer une mouche avec un canon" :

- Qui va se faire chier à exploiter une vulnérabilité zero-day pour obtenir le root sur une PI et gagner l'accès a la lumière du salon de tonton jacky-les-lumières à trifouilly-les-oie ?

 

Il y a beaucoup de choses à dire sur la sécurité mais à partir d'un certain point sur une PI domotique perso ça devient de la parano pure et simple... Sauf si c'est pour s'amuser et c'est ce qui compte !

Je ne recommande absolument pas de faire une paire de clé RSA si c'est pas pour automatiser... Pas besoin de plus qu'un bon mot de passe et un apt update/upgrade pour commencer à s'amuser à faire un serveur avec une PI partager des pages ou des fichiers via le répertoire web HTTP.

 

Et non ce n'est pas un sketch, pour la plupart des gens, scotcher la clé de sa maison sur sa porte d'entrée n'est pas pensable et pourtant c'est à peu pret ce qu'ils font avec tout ce qui concerne l'informatique.

Les clé d'une maison oui, mais la il s'agit d'une maisonnette de poupée voir une coquille d’escargot... Et faut pas pousser celui qui se paye une PI et qui à rien que l'idée d'en faire un serveur web à le minimum d'ouverture d'esprit et de capacité de recherche sur internet faut pas les prendre pour des cons... tu amalgames 2 populations sévèrement différentes la.

 

 

ça rappelle mon premier serveur perso. Quand je regardais les log apache passer en live, avec les tentatives permanentes pour exploiter les failles. Il y avait aussi toujours une ou deux session ssh (anonyme) qui n'étaient de moi. Sérieusement, je flippais complètement.

Idem sauf que j'ai tellement adoré les sniffer, faire des stats publiques sur le site, les enfermer dans des pots de miels, les faire tourner en bourrique avec des password bidons qui donnent sur rien...

 

Regarde moi ça encore maintenant juste les bots qui tentent des auth HTTP les 96 dernières heure :

 

Aussi pour les paranos de la sécurité le logiciel de robot vigibot qu'on va diffuser avec Mike est un client -> aucun besoin d'ouverture de port ou de laisser se connecter des gens sur la PI, c'est elle qui se connecte à un serveur lui même sécurisé par des habitués ça fonctionne même en 4G sans IP publique... ça va sûrement évoluer en télécommande domotique pourquoi pas

Il n'y aucun débat, tu parles à un informaticien aussi, la première réponse donne assez d'info à celui qui veux faire un serveur PI pour qu'il continue à chercher de lui même, sauf question technique plus précise auquel cas on y répondra avec plaisir.

Si la personne est parano d'entrée sur les attaque de bots lui recommander le changement de ports et l'auth par clé semble la base logique.

 

Ne pas oublier qu'il arrive souvent que ses bidouilles que les passionnés font à la maison sont plus élégantes et performantes que celles des pros ou les équipes mal coordonnées qui ne font ça que pour gagner le salaire à la fin du mois. Genre la petite PI bien bichonée et apt updatée se retrouve plus sécurisée que le vieux serveur oublié dans une baie !

Un numéro port TCP est le "numéro de téléphone" d'un logiciel ouvrant ce port, au même titre qu'une adresse IP est le "numéro de téléphone" d'une interface réseau distante.
D'où le nom de TCP/IP.

L'adresse IP + le port (192.168.0.10:1234) forment une socket TCP/IP et si on ajoute le protocole exemple https://192.168.0.10:1234on dispose de l'information complète pour communiquer avec un logiciel sur le réseau.

gerardosamara parle d'une méthode "mnémotechnique" qui permet de retrouver le numéro de port, dans son cas par calcul, des additions.

 

Par exemple t'as plusieurs caméra dans plusieurs immeubles alors le numéro de port c'est le numéro de l'immeuble + le numéro de la pièces...

 

Dans une maison avec quelques caméra pas besoin de ça, n'importe quelle méthode est valable tant que tu retrouves tes numéros de ports en cas de besoin...

Aussi les routeurs permettent d'ajouter des petites notes associés à l'ouverture de port (forwarding)...

Juste pour pinailler 

Citation

 

 

Sur cette box Orange à faire en sorte que le mot de passe par défaut ne soit pas identique pour tout le monde, c'est sécurisé par défaut.

Voila encore une affirmation à la hache qui peut être vrai comme très fausse. C'est comme dire ya HTTPS donc c'est secure...

 

Quand on pinaille, on explique, on cite des cas possible et on ne mystifie pas la chose :

 - Orange se fait pirater le générateur de mot de passe ou la liste des mots de passe par défaut pour un certain nombre de clients.

 - Un numéro de série dans le boitier permet avec un algo de retrouver ce mot de passe.

 - Le mot de passe par défaut est trop faible...

 

J'ai répondu précisément ça car j'ai testé cette livebox (d’ailleurs je la loue pour rien avec ma fibre pro) et effectivement elle est sécurisée par défaut -> C'est le travail obligatoire des ingés chez Orange et les autres opérateurs de sécuriser par défaut les abonnés afin de protéger leurs vue privée conformément aux condition du service

Sur cette box Orange à faire en sorte que le mot de passe par défaut ne soit pas identique pour tout le monde, c'est sécurisé par défaut.

 

Mais tu peux t'habituer à avoir un mot de passe à toi différent pour chaque chose en utilisant un moyen qui te permet de tout mémoriser facilement + de noter ça en lieu sur ex: les papiers de l'abonnement ou un carnet à mot de passe qui se ne trouve pas a côté de l'ordi ou pire un post-it devant une caméra lol ça c'est déjà vu.

Un point suffisamment remarquable qui mérite un post supplémentaire sur les batteries :

 

Il faut se taper 4 VIS pour ouvrir le robot en deux pour sortir très très difficilement les batteries (super chiant moi qui aime pas rayer le cul et l'isolant des accus que je prend neuf pour chaque appareils) afin de recharger...

 

Bref a l'heure de l'objet connecté H.24 pour moi c'est un gros fail.

Ben oui j'ai bien aimé sur le coup, j'ai oublié de parler de l'alim :

 

Ce sont des 14500 des Lithium plus petites que les 18650 (forcément lol) qui font la taille des classiques R6 ou AA.

Une entrée USB câblée sur un USB to serial TTL avec alimentation 5V utilisable afin de ne pas pomper les accus, pas de reboot à la bascule batterie/alim USB.

On dispose donc de 2 cellules 600/750mA en série pour faire du 7.2V puis d'un step down pour fournir le 5V à la PI.

En série ce qui est une grosse connerie car inexploitable pour une base de recharge DIY, une mise en parallèle était préférable malgré le rendement légèrement plus faible d'un step up (et encore) qui aurait permis une charge USB DIY en toute sécurité sans adjonction d'un module BMS pour l'équilibrage.

 

Le socle double-14500 est juste, et il est difficile de faire rentrer la version protected des 14500 (accus avec PCB de sécurité sous/sur voltage)

 

Donc je répète pas de gestion de batterie : ni coupure tension minimum ni chargeur intégré... ni possibilité simple d'ajout DIY de base de recharge.

 

J'ai pas vu si ils avaient eu l'intelligence de câbler un analog input pour surveiller la tension... mais j'ai des doutes

 

Il y a un neopixel à quelques diodes RGB intégré (pas testé) une série de capteurs pour un suiveur de lignes, 2 capteurs d'obstacles tout-ou-rien à l'avant...

 

Enfin voila quoi... Vaux mieux le faire sois même. On va en design de biens mieux avec Mike, ou il sera facile de se positionner sur un chargeur, à induction ou pas. La base de recharge à distance, c'est la base en robotique. Surtout pour notre système de "robot casting".

 

Pascal

Salut les roboticiens !!!

 

Tout d'abord attention, n'achetez pas ce produit de chez Waveshare Electronics : je vais expliquer pourquoi...

 

Je voulais deux kits pour développer *RAPIDEMENT* le code client de la version économique et basée exclusivement sur une Raspberry PI d'un robot connecté au futur cluster de serveurs de pilotage temps réel (dont je développe en ce moment l'interface multi-robots / multi-utilisateurs).

 

Premièrement : petite surprises au déballage pour le grand maniaque de la carte électronique que je suis : sur deux kits, deux PCBs sur quartes profondément rayés (du vernis jusqu'au cuivre) et des composants abimés/tordus, malgré la qualité de fabrication de type industrielle soudé à la machine, très propre mais bâclé, sans doute par une logistique pré/post production lamentable et/ou des salariés maltraités.

 

Secondo : les palonniers Tower Pro ne sont pas compatible avec l'axe X de ce kit pan & tilt à quelques dollar, et même sur la vidéo YouTube officielle ils en ont bavés pour l’assemblage, c'est archi-coupé de façon salle et bien hésitante voir à 5:44 :

 

https://youtu.be/ONg0qpxYWQo?t=344

 

Au premier visionnage on ne s'en rend pas compte, mais ça en devient presque risible de revoir le passage de la vidéo après avoir découper/limier à fond et dans tout les sens ce pauvre petit palonnier croix (le moins pire niveau compatibilité) pour au final se retrouver avec des trous qui ne peuvent pas tomber en face.

Les vis rikiki qui ne sont pas utilisables sans profonde modifications plasturgique bien crades, mais heureusement, il y a l'impression 3D pour tout refaire...

Cependant bye bye la mise en service *RAPIDO* que j'ai payée au prix fort soit 80 balle le kit pour me retrouver avec ce... Truc (pour ne pas dire autre chose)...

Un palonnier de servomoteur ça se taille uniquement dans la longueur le reste : affinage des bras et reperçage du plastique trop proche de trous déjà existants EST, pour un kit commercial du bricolage de bas étage.

 

Troisième point, et la c'est le carton rouge :

 

Ils se sont mélangé les pinceaux dans les entrées sorties du double pont en H (TB6612FNG) entre les A, les B, les 1 et les 2 (AIN1/AIN2/BIN1/BIN2).

 

C'est pas grave, si ce n'était que du software car j'ai tout bien re développé en Node.js ... pour au final me retrouver avec un robot ayant les deux hardware PWM de la Raspberry PI (soit les GPIO 12 et 13 du broadcom) sur LE MEME PUT1 DE MOTEUR (le gauche) ! Ce qui explique pourquoi ils ont utilisés du software PWM bien crado dans le code Python d'origine voir code python https://github.com/d...rc/AlphaBot2.py

 

Or que le pilotage de moteurs ne nécessite pas un timing précis au point de devoir faire du DMA, ils pouvais exploiter le PWM Hardware d'origine de nos PI 2/3... Voir même nous garder les HPWM suffisants pour les servomoteurs ou lieu de nous claquer cette interface I2C vers PWM pour contrôler les servomoteurs.

 

Et pendant ce temps la le buzzer qui nous éclate les oreilles aux parasites ultrasons, vive le filtrage... intégrer un filtre LC à la carte était bien trop compliqué pour Waveshare : "de l'analogique, au secours !!" les pauvres...

 

Moi les deux kits c'est retour à l'expéditeur !

 

Je vais passer quelques instants en mode prototypage (PI + jumper wire) pour trouver la combinaison H/PWM SoftPWM DMA/PWM permettant d'avoir les commandes les plus précises possible sans adjonction d'un Arduino. C'est important pour obtenir une version rikiki (PI Zéro) ou économique d'un robot malgré tout fluide et performant sur le web.

 

L'ajout d'un Arduino (ou autre microcontrôleur) reste la version idéale en architecture robotique : l'IHM / client web / Mathématiques SLAM en Node.js/C++ sous Linux et le temps réel en C/C++ sur un coprocesseur dédié les deux communicants en UART.

 

Pascal

 

techniquement si tu arrives avoir les données LIDAR + pilotage moteur et lecture encodeurs je pourrais foutre le code de Mike118 et moi dessus mais c'est trop de travail pour qu'on s'en occupe actuellement

Tu ne pourras pas exploiter le SLAM toi même tu seras obligé de comprendre comment lire les capteurs/lidar toi même et de faire ton propre algo...

MDR tu pourras moisir leurs cloud avec des valeurs impossible:D t'as sniffer voir le protocole ? SSL j'espère.

Essai de récupérer le maximum de chose mais a mon avis le SLAM est propriétaire codé (ou salement pompé?) par eux.

 

Par contre récupère moi les moteurs + encodeurs et je pourrait essayer facilement mon code de base NodeJS (sans SLAM) dessus.

Concrètement tu as une base robotique avec un microcontrolleur (MCU) accessible depuis un port série monté dans un /dev (/tmp bizarre) d'une carte linux.

 

Il te faut rétro "ingéniefier" les types de trames de pilotage et surtout celles des réponses avant de pouvoir en faire qqchose...

 

Les modules les plus intéressants c'est a dire la navigation et cartographie sont des briques logicielles dont tu ne dispose que du binaire et des fichiers de configuration donc tu ne peux rien en faire sauf si ils ont prévu dans le framework un accès de haut niveau pour faire un GoTo XY mais très peu probable...

 

 

Je peux pas éditer mes posts d'ici je passe par un proxy https dans https. tu peux tenter de désassembler comme suggère cocothebo pour avoir les interfaces... (jamais testé moi je préfère créer mon propre code lol)

Il faut essayer de faire dessiner tes données de position ça ressemble à l'odometrie brute

NodeJS est capable de faire le server web lui même (express etc...) mais perso j'utilise Apache avec un module de proxy websocket pour multiplexer et rendre accessible plusieurs petits processus Nodejs + servir le contenu statique et php7 qui est un language super ultra pratique pour un site web.

Apache est ancien et éprouvé niveau sécurité et je le maîtrise mais il existe bien d'autres serveurs web comme nginx ou lighttpd que je n'ai pas encore essayés (https://www.digitalo...-considerations)

Vu que je n'ai pas envie de tout coder en Javascript côté serveur mais uniquement la partie temps réel rendue minimaliste et rapide, j'utilise le serveur web classique pour faire la majorité du site en fait. Sur un aspirateur c'est sûrement un surplus mais si t'as l'espace dispo a voir...

PTDR l'humain à la rescousse du robot, pour l'instant

Puis la désolé je peux pas envoyer un robot te rebrancher le port USB car il risque de se faire reprogrammer par ton système de surveillance domotique, se retourner contre les humains et paf ça fait skynet...

pour que ce soit proprement intégré ça risque d'être plus difficile a faire en rétro ingénierie que de refaire un robot from scratch... je te fait confiance pour trouver le plus de choses possible en mode hack et si t'as des choses intéressantes a publier via une IHM web je pourrais t'aider facilement.

Désassembler sur du certainement C++ ou pire pas optimisé j'essai même pas... Essai de voir tout ce que tu peux gratter, récupère les données d'odométrie il te faut un chiffre qui change quand tu tournes les roues...

Il faut que tu puisses envoyer plus ou moins de vitesse aux moteurs et la OK je te le rend pilotable à l'aide d'un port HTTP que tu peux ouvrir ou pas sur Internet:)