Lazer

J'ai trop de congés (5 semaines...) Alors je suis contraint de les poser avant fin mai. En plus il fait beau, c'est le combo gagnant ! Donc j'en profite pour me remettre au bricolage. Merci pour la proposition, mais ca ira plus vite d'aller chercher un rouleau chez touslescables à Paris, ou me faire livrer par Amazon Prime (mais plus cher).

Et ça compte quand c'est aussi le 3ème prénom ? Bonne fête Philippe

Après midi productive ... j'ai résolu un problème que je traine depuis quelques années... au sujet du réseau entre la maison et le garage. La gaine souterraine qu'avait laissé l'ancien proprio est rompue en plein milieu du jardin, l’aiguille bloque au milieu, et ressort complètement mouillée. Donc ça fait quelques années que je devais supporter du CPL, au débit tout pourri, connexion instable, etc. (même avec les Devolo 1200) Bref, excédé, j'ai pris le taureau par les cornes pour trouver une solution fiable. L'ancien proprio avait passé du câble d'alarme 8 brins entre la maison et le garage... câble qui n'a jamais servi. Ce n'est pas du câble torsadé, mais j'ai quand même tenté le coup... connecteur RJ45 à chaque extrémité, connexion entre un switch et un PC portable.... il y a du signal, mais aucun octet ne passe. Même en forçant à la vitesse la plus basse, 10 Mbps Full Duplex (ou même Half Duplex), dans les stats des ports, on voit les paquets envoyés, mais que des paquets reçus en erreur. Bref, ça ne passe pas.... conclusion, même pour du vénérable 10 Mbps, il faut impérativement de la paire torsadée. C'est idiot d'avoir passé du câble d'alarme, même du bête câble téléphonique, qui utilise des paires torsadées, permet de passer du 100Mbps. Impossible de tirer sur le câble, c'est totalement coincé dans la gaine... et je n'ai aucune idée du chemin de passage de la gaine (j'ai fait quelques suppositions qui vont s'avérer totalement fausses, voir la suite). J'ai donc acheté un testeur de câble, tout simple ( https://www.amazon.fr/dp/B01NCNZCF2/ref=pe_3044141_185740131_TE_item_image ) Ce truc est génial Il y a plusieurs modes de fonctionnement. On branche l'émetteur d'un coté, et avec le récepteur on suit le câble pour écouter le bip-bip. La gaine part dans le plafond de la cave, j'arrive à suivre, puis je perds le signal (au delà de 10 cm de béton, il n'y a plus rien qui passe). Je vais au dessus, et par chance la gaine passe juste sous le carrelage... je suis la gaine avec mon testeur, et là surprise, elle ne va pas en ligne droite, premier virage.... je continue à suivre, ça part vers un mur extérieur. Je sors donc dehors, je retrouve le signal qui descend vers les fondations... j'enlève quelques pierres, et là, quelle surprise, une boite de dérivation planquée !!! Vite un tournevis.... et là méga (bonne) surprise Je retrouve mon câble d'alarme qui va vers le garage, mais aussi d'autres câbles... ce qui semble être les câbles de l'interphone et de commande du portail ! En clair, je vais pouvoir remplacer le câble pour amener du réseau, et donc du POE à l'interphone (ça change tous mes plans ça...... vivement que Fibaro débuggue son Intercom.... ) Revenons à nos moutons, je peux tirer le câble d'alarme dans les 2 sens (vers la maison et vers le garage), donc je vais pouvoir le remplacer par du Grade 3S, et enfin amener du réseau au garage Mesure rapide, il me faut environ 25m de câble. Je vais chercher ma bobine en stock, pas de chance il me reste environ 20m Bref, faut que je commande une nouvelle bobine de 100m, je vais reprendre du Acohome Grade 3S, il est top. Suite la semaine prochaine, mais enfin je vais solutionner ce problème de réseau

J'ai inclue le Heavy Duty Switch sans problème, par contre pas de template. Ce n'est pas gênant, la configuration des paramètres par défaut convient bien, la mesure de consommation est mise à jour en temps réel, le module se souvient de son état après une coupure de courant (donc on peut le laisser en Always-ON pour alimenter par exemple une plaque de cuisson). Testé avec un peu plus de 3kW de charge.

J'ai testé, ma Sirène inclue depuis très longtemps, en mode normal. Fonctionne toujours parfaitement suite aux différentes mises à jour de la box HC2. Même débranchée, la sirène sonne bien. Par contre je n'ai pas mesuré l'autonomie de la batterie.

Oui sur domotique-store ça fait un moment qu'elle est très basse, on en parlait il n'y a pas longtemps sur un autre topic, et ces promos éternelles sont inquiétantes pour la santé financière de cette boutique. Pendant ce temps là aux US, elle est toujours à 1200$ : https://www.amazon.com/Fibaro-FGHC2-Home-Center/dp/B01N8VWQJM/ref=sr_1_1?ie=UTF8&qid=1525348690&sr=8-1&keywords=fibaro+home+center+2

Bien vu, mais ça devient compliqué. Perso j'utilise toujours HAproxy, je n'ai pas eu besoin de faire tout ça.... Config ultra basique avec les paramètres par défaut dans le panneau de config de DSM, et je demande juste à HAProxy de forcer une redirection du http vers https : frontend http ... acl is_dsm hdr(host) dsm.domaine.com !ssl_fc redirect scheme https code 301 if is_dsm ... Et c'est tout.

Joyeux anniversaire @Domodial

Ah ça je l'ai déjà la VM Android x86, ça fonctionne. C'est pour remonter les notifications de l'application Diagral Connect pour mon alarme, avec Tasker.

@ADN182 je pense que ton problème provient de l'option HSTS que tu as activé sur DSM. Essaye sur un autre navigateur que tu n'as jamais utilisé pour te connecter au Syno et qui n'a donc jamais reçu le header HSTS, ça devrait fonctionner (= tu ne devrais pas avoir la redirection forcée) Si vous avez suivi le même tuto, je ne comprends quand même pas pourquoi @ADN182 et @BenjyNet vous avez un comportement différent sur la présentation du certificat par défaut.

J'ai déjà une VM Android x86, je me demande si ça fonctionnerait. Je vais essayer d'installer l'apk

Oui c'est bon c'est bien paramétré, c'est bien de ça que je parlais. Du coup c'est peut être la faute du paramètre HSTS, et là c'est la merde pour le virer celui-là... même pas certain que vider le cache du navigateur suffise. PS : trop bien l'adresse IP en 257, on se croirait dans un film de hackers au cinéma hollywoodien

Tu n'aurais pas forcé le HTTPS dans les paramètres du Syno ? Il y a une option dans le panneau de config, il faut la décocher. Sinon ça redirige tout seul sur le 5001 car le Syno croit que le l'utilisateur est en local (il n'a pas conscience du reverse proxy)

Il s'en fout, il ne parle pas Anglais mprinfo. Par contre le lituanien ne lui pose pas de problème

Pas particulièrement, ou tous à la fois. N'importe quel bout de code LUA avec une requête POST ou PUT, il y en a des tonnes.

Oui et non. Voir mon discours précédent sur l'utilité ou non de changer les ports par défaut. En synthèse, si tu as confiance dans la sécurité de ton reverse proxy, cela ne sert à rien de changer le port, au contraire cela entraîne des dysfonctionnement si tu veux te connecter depuis un réseau d'entreprise.

Euh, là c'est comme si tu n'avais aucun port ouvert, en tout cas ni le 80 ni le 443 Mais si tu n'as pas suivi ce tuto, tu as suivi quoi ? Est-ce que tu as mis en place un reverse proxy, ou alors tu as fait une simple redirection de ports (auquel cas tu as surement ouvert des ports différents)

Et à part la mise à jour du firmware, tu as réussi à envoyer des SMS via l'API, Pascal ?

@Kana-chan parfait @jojo 1/ 99% des scans sont des robots, qui ne connaissent pas ton domaine, mais uniquement ton IP (forcément c'est pas là qu'ils arrivent). Idem pour un petit malin comme moi ou l'un de tes collègues au travail ou sur n'importe quel LAN qui s'amuse à récupérer ton IP publique. Si il ne connait pas le domaine, il ne va pas plus loin. Si il connait le domaine, il peut déduire un certain nombre de sous-domaine, et donc rentrer plus facilement. 2/ Bof.... changer les ports, c'est une technique de base pour cacher, mais encore une fois, ça ne fonctionne qu'avec les robots qui scannent les ports par défaut. Celui qui te veut du mal, avec un nmap il retrouve tes ports en moins de 2 (c'est le premier truc que j'ai testé tout à l'heure chez Benjy ), donc ça ne ralentie pas le mec plus de 2 Minutes. Changer les ports est une mauvaise technique, en tout cas elle n'est pas suffisante. Mais surtout, changer les ports, c'est s'exposer à des dysfonctionnements. Car la plupart des proxy/firewalls d'entreprise ne laissent passer que les ports 80 et 443, donc tu ne pourras plus accéder chez toi. Si tu voyages, tu verras que c'est pareil à l'échelle entière de certains pays dont la censure est encore plus important qu'en France. D'ailleurs, c'est la raison pour laquelle j'ai monté mon premier reverse proxy sur le port 80 il y a pas mal d'années, c'était justement pour m'y connecter de n'importe où. PS : pour ceux qui font du OpenVPN, idem, il faut le mettre sur le port 443 afin de passer au travers des proxy/firewalll des entreprises.

Perso ça fonctionne très bien avec Ubiquiti EdgeRouter, il fait la détection de faillover par simple ping, et tout est paramétrable (nombre de ping, intervalle, etc). Si ça ne suffit pas, on peut remplacer le ping par un script Shell de son choix qui peut faire des tests très poussés. Bon par contre, c'est pas graphique, le WAN Failover se configure en ligne de commande. Un routeur Synology c'est plus simple et efficace (mais plus cher)

Je précise, parce que la capture d'écran n'est pas claire (j'ai caché trop d'infos). Les zones rouges barrées sont l'adresse IP publique, donc aucun nom de domaine n'apparait.

Alors chez BenjyNet, c'est très bien, aucune information n'est divulguée Le certificat présenté est un certificat auto-signé par Synology. Donc ça répond parfaitement à mes interrogations. Le Reverse Proxy ne présente pas l'un de vos certificats par défaut, mais le siens (auto-signé, d'où l'avertissement de sécurité), qui est générique et en donne aucune informations de domaine. Bref, parfait

je confirme, presque qu'une minutes pour charger la page de httpbin.org sur Orange Fibre moi aussi. Pas étonnant que la requête de la HC2 parte en timeout. (je n'utilise pas ce script, donc je ne rencontre pas de problème reboot intempestif)

Non pas encore

OK donc si tu as un site poubelle, c'est déjà pas mal. Je reprends mon explication afin d'essayer de me faire comprendre. Je scanne Internet....soit avec un robot (99% des logs de vos firewalls viennent de robot, souvent en Russie/Chine), afin d'obtenir une liste d'IP avec des ports ouverts. Alternative : je connais déjà votre IP parce que je vous cible particulièrement, donc je n'ai plus qu'à scanner vos ports ouverts (avec "nmap" ça prend quelques minutes) Admettons que votre IP publique c'est 1.2.3.4 Si vous avez appliqué ce tuto, vous avez 2 ports ouverts : 80 (http) et 443 (https). Je prend mon navigateur (Firefox parce que c'est mon préféré, mais ça peut aussi être Chrome ou encore un autre, bref, tout navigateur moderne sauf Internet Explorer). J'ouvre une page Web sur http://1.2.3.4 Là je vois un site "poubelle" que le reverse proxy me renverra, par exemple une page blanche avec un code 403 (je vous laisser faire le test sur votre propre IP). Je ne peux pas aller plus loin. Maintenant, avec le navigateur, j'ouvre une page sur https://1.2.3.4 (donc sur le port 443 que le navigateur va automatiquement sélectionné car je lui ai demandé du https sécurisé) Première chose que je constate, un avertissement de sécurité, car le domaine de l'URL demandée (1.2.3.4) ne correspond pas au domaine pour lequel le certificat par défaut (*) a été signé. Supposons que votre domaine soit mondomaine.com, on est tous d'accord pour dire que mondomaine.com <> 1.2.3.4 (simple comparaison textuelle) Là où ça devient intéressant, c'est que je clique sur le bouton pour voir les détails du message d'avertissement et du certificat... et on voit clairement apparaitre le nom du domaine "mondomaine.com" (je ne met pas de capture d'écran, faites le test avec votre IP publique) Intéressant tout ça, ce nom de domaine me donne une piste. Premier cas, ce certificat par défaut (*) contient déjà un sous-domaine (exemple hc2.mondomaine.com). Bingo, j'ai juste à ouvrir une fenêtre sur https://hc2.mondomaine.com et là j'ai accès à votre HC2. Si celle-ci fonctionne sous une vieille version de Debian avec une vieille version de Apache et des pages web développées par un stagiaire (c'est une exemple fictif hein.... ou pas), il y a de bonnes chances de trouver des failles de sécurité et de les exploiter. Exemple, la faille permettant de rooter la HC2 via l'interface Web publiée en septembre dernier (et corrigée en vitesse par Fibaro, comme quoi quand ils veulent, ils peuvent). Une fois le serveur rooté, c'est la porte d'entrée à tout votre LAN... et là je ne parle pas que de domotique. Il devient très facile de rooter les caméras Hikvision non patchées, les TV connectées, accéder aux fichiers du NAS, etc. Second cas, soit parce que le certificat par défaut (*) ne m'a pas donné de sous-domaine, et/ou parce que j'ai envie de découvrir tous les autres sous-domaines liés à votre nom de domaine, il existe différentes méthodes pour parcourir les arborescences DNS et tenter de découvrir tous les sous-domaines.... ça ne fonctionne pas à tous les coups, mais on peut trouver des choses intéressantes. A ce moment là, tout les sous-domaines que je vais trouver vont me donner autant de points d'entrées que nécessaire pour me connecter à vos équipements internes au travers de votre reverse proxy, qui fera simple son job, rien de plus. En bref, le Reverse Proxy vous permet de chiffrer la connexion https entre votre navigateur client et votre serveur à la maison, et c'est tout. Il est incapable de cacher les équipements internes sur votre réseau. En fin de compte, il n'apporte pas plus de sécurité que d'ouvrir un ensemble de ports sur votre routeur, face à un pirate qui veut pénétrer votre réseau. (*) certificat par défaut : c'est bien là tout le problème. Votre reverse proxy a pris l'un de vos certificats (signé par Let's Encrypt dans les règles de l'art) et s'en est servit pour répondre à la requêtes générique https://1.2.3.4 Le choix du certificat ne se fait pas au hasard, avec HAproxy il prend le premier par ordre alphabétique parmi la liste des certificats que vous avez généré. Prenons un exemple, j'ai fait signer 3 certificats : - mondomaine.com (la racine de mon domaine) - hc2.mondomaine.com (Fibaro) - dsm.mondomaine.com (Synology) Le premier par ordre alphabétique, c'est dsm.mondomaine.com !!! Il est critique celui-là en plus (par chance Synology met à jour régulièrement les failles de sécurité, mais on n'est jamais à l'abri) Donc le visiteur verra immédiatement par quelle porte d'entrée passer pour avoir accès à un premier équipement, sans même avoir besoin de commencer une recherche DNS. Est-ce bien clair maintenant ? Pour répondre à Jojo, le fiat de faire signer un certificat Wildcard (valable pour *.mondomaine.com) ne change strictement rien au problème, votre domaine sera toujours visible dans le certificat par défaut présenté par le serveur Web lors d'une requête https. On notera tout le comique de la situation, le port 80 non sécurisé ne donne aucune information, tandis que le port 443 sécurisé permet de récupérer des informations !!! Donc maintenant la solution Il faut se débrouiller pour que le reverse proxy présente un certificat différent, qui ne fasse pas du tout partie de votre domaine, lors d'une requête web générique (le fameux https://1.2.3.4) Donc on va générer ce certificat. Comme je le disais hier, je connais 2 méthodes : Générer son propre certificat auto-signé avec une autorité de certification maison. Cela se fait très bien sous Linux, mais nécessite quand même un certain nombre de manipulations, et d'avoir un Linux sous la main. Pour info on utilise les outils de la suite OpenSSL tout simplement (OpenSSL est utilisé sur la très grande majorité des systèmes Linux, notamment pour faire fonctionner SSH, et votre navigateur et serveur Web en https. Autant dire que n'importe quel Linux devrait pouvoir agir comme autorité de certification). Une fois qu'on a obtenu ce certificat, on modifie la configuration de notre Reverse Proxy pour lui dire de l'utiliser par défaut (ça se fait très bien avec HAproxy, je ne sais pas ce qu'il en est avec Synology DSM comme présenté dans ce tuto). En conséquence, quand le visiteur se pointe sur https://1.2.3.4, le reverse proxy lui présentera ce certificat auto-signé, il aura quand même un message d'avertissement signalant que le certificat n'est pas valide (puisqu'auto-signé et non signé par une autorité de certification reconnue telle que Let's Encrypt), mais ce n'est pas un souci... en regardant les détails du certificat, il ne verra qu'un nom de domaine bidon, celui que vous avez choisi au moment de la génération avec OpenSSL sous Linux. Donc il ne sera pas plus avancé. Bien sûr, si l'utilisateur est légitime (vous), et demande d'accéder à https://dsm.mondomaine.com, alors le reverse proxy lui présentera le certificat associé à ce domaine et correctement signé par Let's Encrypt, et tout fonctionnera normalement. Générer un certificat signé avec une autorité de certification reconnue telle que Let's Encrypt (de la même façon que vos certificats habituels pour mondomaine.com). L'astuce consiste ici à faire un reverse DNS lookup de votre IP publique (nslookup 1.2.3.4 sous Windows, ou dig -x 1.2.3.4 sous Linux). Le nom de domaine ainsi obtenu correspond à celui de vote opérateur, par exemple bidule.abo.wanadoo.fr. Il n'y a plus qu'à demander à Let's Encrypt de nous signer un certificat avec ce nom de domaine, elle sera en mesure de le signer car vous êtes bien propriétaire de l'IP associée à ce domaine (au moins pendant 24h si votre IP change tous les jours). Avantage, il n'y a pas besoin de taper la 10zaine de commande nécessaires pour générer un certificat auto-signé sous Linux, et ce certificat présenté par défaut au visiteur sur https://1.2.3.4 sera valide, donc la navigateur n'affichera même pas un message d'avertissement. Cela n'apporte par de sécurité supplémentaire par rapport au certificat auto-signé, mais c'est plus propre. Inconvénient, il faut régénérer ce certificat tous les 3 mois maximum (limitation Let's Encrypt), mais normalement vous avez déjà un script pour regénérer vos certificats légitimes mondomaine.com régulièrement, il suffit de l'utiliser.