An excellent read. I wish they would market the device better to people like me (us?) that require web security. I might have bought their product. Might still, in fact, after reading that.
It's important to take some caution to adding and trusting IoT devices. On Oct 9, 2016 6:42 PM, "Andrew Milner" <[email protected]> wrote: > This tells you how the bridge works: > http://moderntoil.com/?p=794 > > It would appear to me that the bridge has no real need for security as > such since it only transmits data to acurite web site from your weather > station using POST commands. It's security is controlled by your own > router, and it would only respond to incoming data when it switched to > update mode to update its firmware. > > > > On Monday, 10 October 2016 02:28:39 UTC+3, Tim Phillips wrote: > >> So I've totally misinterpreted what Apache does for the weewx >> service....I'm super new to this so I'm sorry you need to explain these >> things like this. My WAN/IP education is limited to setting up a handful of >> foscam's on WAN manually as well as doing a RPi webcam project >> (RPi-Cam-Interface) which worked well. >> >> I ALWAYS set a custom password on my stuff and change the username if >> possible. Actually, I decided to use my RPi as a weather station server >> because the Acurite "bridge" accessory gave no indication of how their >> security works, which I disliked. So I took it as an opportunity to learn >> all about it, hopefully via this project as a starting point. I was not >> keen on just plugging in their bridge accessory to my router and thinking >> that's A-OK. >> >> >> I appreciate the clarification! >> >> >> >> On Sunday, October 9, 2016 at 12:28:56 PM UTC-7, vince wrote: >>> >>> On Sunday, October 9, 2016 at 10:10:00 AM UTC-7, Tim Phillips wrote: >>>> >>>> My understanding of how my Weewx on my Pi is: >>>> >>>> Weewx running as a daemon (service/background process). >>>> >>> >>> almost certainly yes >>> >>> >>>> Apache2 is the web server so a user can access the Weewx service >>>> (daemon) from a browser on LAN/WAN (if port forwarded). >>>> >>> >>> no. Apache does not talk to the weewx daemon at all. >>> >>> It listens on the port(s) you have it configured to listen on, commonly >>> http (tcp/80), and makes available whatever data or programs apache is >>> configured to permit (typically, just a document tree). Sometimes your web >>> pages are executable (php typically) but most times not. Initially it's set >>> up to just return data. >>> >>> The default weewx output from the default skins is just data....html >>> files and image files. Other skins might have executable php content >>> (saratoga templates to name one). Again, the apache configuration must be >>> set up to permit php files to execute, and there is additional software >>> you'd install to do that. There are a lot of apache-related packages. >>> >>> >>> - Apache2 runs in the background and is the "gatekeeper" to the >>>> services that request a browser-based information request. >>>> >>> >>> not really. It's a daemon that listens on the port(s) it is configured >>> for, and does what it's configured to do based on the apache config >>> file(s). Again, usually it just provides a way to read files using a >>> remote web browser kind of interface, from a well-defined directory on the >>> filesystem. >>> >>> - Services get access *through *the Apache server to the >>>> destination port it's assigned to. In Weewx's case it's "/weewx". >>>> >>>> >>> no. Apache makes some files (in locations defined by the apache config >>> files) on the pi accessible via http or https, assuming those files are >>> accessible by the non-privileged account the apache daemon runs as. >>> >>> >>>> BUT, if the port to Apache is 80, and that directs to Weewx, then how >>>> would I set up multiple WAN access, say if I had a webcam service running >>>> on the same Pi? >>>> >>>> >>> Again, apache doesn't really 'direct' to weewx, it can make >>> weewx-generated output files available, if weewx puts it in a place apache >>> is configured to know about, and if the files are set with the right >>> permissions so the apache daemon can read them. >>> >>> You would configure the webcam to accept incoming requests on another >>> port typically, hopefully over https with a strong non-default password >>> required to see the files. This seems to be what most of the IoT break-ins >>> seem to be exploiting....folks who just go shields-down in a insecure >>> vendor-default configuration. >>> >>> I'm not quite sure what you're asking about WAN vs. LAN access, but if >>> you're a typical home user you likely have your LAN behind a gateway device >>> that blocks all incoming WAN access, unless you forward particular ports >>> through your firewall. >>> >>> Be very careful here. If you're asking the types of questions you're >>> asking, I'd suggest doing it right might be a little above your >>> understanding/expertise at this point in time. By far the safest thing to >>> do is to permit 'no' incoming traffic WAN=>LAN even through port forwarding. >>> >>> >>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "weewx-user" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/weewx-user/ot23QZHY15o/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
