Lazer

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.

Alors là c'est pire que tout, et c'est bien là le problème, en gros ta porte d'entée est grande ouverte, le reverse proxy n'apporte pas de sécurité supplémentaire. Autant ne rien mettre, ça fait moins de travail. On en avait discuté il y a quelques pages, le minimum vital c'est de configurer ton reverse proxy pour que le site par défaut soit une poubelle, mais surtout pas un vrai site interne. Mais évidemment ça ne suffira pas, car comme je disais plus haut, si le certificat publique est exposé, n'importe quel visiteur "voit" le domaine, et il est assez facile de trouver les différents sous-domaines. C'était l'objet de ma question initiale, j'aimerais bien connaitre le comportement de vos configs. @MAM78, @BenjyNet, ... ? EDIT : je pose la question par courtoisie et pour faire avancer le débat, car il m'est assez facile de trouver vos IP publiques et d'aller fouiner moi même.... mais ça n'est pas étique.

Avec un chargeur sans écran, je ne vois pas bien comment tu peux affirmer que tes accus fonctionnent comme au premier jour, si ce n'est au juger à l'utilisation. Seul l'écran sur le chargeur te permet de connaitre la capacité restante de tes accus. C'est mathématique.

Comme je te disais plus haut, je doute fort que tu trouves une clim module avec interface IP, mais ça existe peut être. Par comparaison dans le haut de gamme en FIXE, c'est rare et en option et via un cloud fermé. Alors tu vois.... Dans la doc du ZXT tu as les codes préenregistrés pour chaque marque de clim... il faut donc que tu cherches si Beko est connue dedans. Souvent les marques low-cost et inconnues sont du OEM de marques plus connues. Souvent des marques chinoises... donc chercher sur Internet peut aider à trouver sur quel fabricant original se base la marque Beko. (Il y a des centaines de marques commerciales, mais seulement quelques dizaines de fabricants dans le monde) Enfin, déjà le prérequis est de t'assurer que le modèle que tu veux dispose bien d'une télécommande, et donc d'une interface IR. C'est évidemment un pré-requis à tout ça. La bonne nouvelle, c'est que même si tu ne trouves pas les codes préenregistrés dans le manuel, tu as toujours la possibilité de les apprendre à la main. Comme une télécommande universelle, l'une en face de l'autre, et tu apprends les touches les unes après les autres. Fastidieux. Concernant la portée, oui l'IR est assez mauvais... si tu as des murs satin blanc, ça rebondit bien et tu peux cacher le ZXT en haut d'une armoire. Sinon il faut viser en direct. Bref, il faut tester sur place. Note qu'il existe un autre module super populaire chez les Jeedomien pour piloter des interfaces IR, c'est le RM Pro, mais non compatible avec HC2.

Comme je disais, le ZXT 120 Il n'est pas très populaire, car complexe à configurer, et plusieurs sur le forum n'ont pas réussi. Perso le premier que j'ai eu était buggé, remplacé par le vendeur en garantie. Depuis il fonctionne parfaitement, ça doit faire 3 ou 4 ans qu'il tourne non stop (pour piloter une clim fixe, et j'ai eu de la chance, j'ai trouvé le code de ma clim, donc je n'ai pas eu besoin de faire l'apprentissage des codes IR) Faut bien comprendre que ce module n'est jamais qu'une télécommande universelle, comme pour les TV. Sauf qu'au lieu de la prendre en main et d'appuyer sur les boutons, on la pose et on la pilote depuis la box domotique en Z-Wave.