Printable View
I have not been able to find anything on how the smart bridge is secured.
It is connected to the internet but there is no information on how it is secured. Is there a password? If so, how does one go about setting it or changing it.
Also, is there a way to set a static IP address? A 2014 post talked about "Advanced Setting". The only thing in Advanced setting is "location" in the latest version of the iOS app.
Go to Settings-->Advanced-->Integration-->Network Settings
As noted on my original post, the only thing that shows up in Settings->Advanced is "Time and Location".Quote:
Originally Posted by davisadm
This is on the latest version of the "Luton App for Caseta Wireless" for iOS.
Is there another app or is there some other setting I'm missing?
I've also looked at the iOS "Settings" for the app and there is nothing relevant to network settings there.
Is the "Advanced" tab only visible for the Smart Bridge Pro perhaps? It does show up on mine but I have a Pro.
I am running Version 4.0.1.
When I go Settings->Advanced, I get 2 choices, Integration and Time and Location.
My settings:
https://forums.lutron.com/attachment...ntid=563&stc=1
My Advanced:
https://forums.lutron.com/attachment...ntid=564&stc=1
My Integration:
https://forums.lutron.com/attachment...ntid=565&stc=1
I was just thinking about the differences between Smart Bridge and the Pro. That could be the reason. I will check with my Caseta Rep.
Thank you guys for the responses.
I guess that Lutron doesn't think that the non-pro bridges deserve to be secured.
This and the absence of documentation. Wish I had found out about this sooner. I would have returned the product. I won't use any internet connected device that cannot be secured.
Setting a static ip for the bridge makes no security improvements nor deteriorates security in any way. Lutron takes network security very serious. I am sure if you search the support documents there is documentation on the security measure the Caseta Bridges use. All traffic to the bridge actually comes through Lutron's servers. The app connects to Lutron and Lutron connects to your Bridge. The bridge isn't just listening on a open port waiting for a login.
Nobody suggested that setting a static IP address improves security. Setting a password certainly will. As noted in the original post, there does not seem to be a way to set a password.
Lutron takes the security of the Case?ta Smart Bridge and the user’s phone very seriously. Lutron employs computer industry best practices including encryption of the communication between the Case?ta Smart Bridge and the user.Quote:
Originally Posted by DomZho
The initial set-up of the Case?ta Smart Bridge requires the user to be physically inside their home with access to their local network and to press a button on the Case?ta Smart Bridge to create their Account. In daily use, the system requires the username and password (stored in the App), set by the user at initial set-up, for remote access to their lighting. Just as the user protects the username and password to their other on-line accounts, the Case?ta Wireless username and password must also be protected so that no one else can access the user’s Case?ta Wireless account, lighting, and other connected systems.
Lutron recommends that users not share their username and passwords, not write them down where others could access them , or use easy to guess passwords such as “password”, home address, birthday, or the same passwords used with other online websites. If the user believes that their password may have been compromised, they should change it immediately.
I'm pretty sure that telnet access uses non-changable default credentials. That seems like a big security hole to me...
But telnet would only be available from within the local network unless you port forward the router to specifically allow telnet from the WAN.
Don't let hackers on your LAN or you will have bigger issues than someone turning your lights off.
I think this grossly overestimates the technical abilities of those buying home automation products. Even the more skilled could protect their computers and devices they actually have more control over. But items like the Caseta SmartBridge, and the plethora of other devices being heavily marketed and sold do not offer a lot of control.Quote:
Originally Posted by Lukeetal
And worse, few document what their ACTUAL network requirements are (needing access to ALL of the Internet on numerous ports is absurd, and would be rejected at my company for use; just DOCUMENT it... not like it has a LOT of requirements for access), and many have incredibly insecure implementation despite all the marketing BS published (and often written) by those who don't have a clue what they're talking about. The word "encryption" does not make things secure, secure implementation of encryption can. "telnet" pretty much says "insecure". telnet is not an encrypted protocol. So that means that IP camera someone bought and which was hacked within 5 minutes of connecting (because that device opened up ports on the home router/fw with outdated firmware), can now sniff the local traffic.
Seriously... the whole "IoT" thing is pretty terrifying, and really unfortunate that companies (including Lutron) fail to reasonably document what they do to actually MAKE it secure for their consumers, or what network access needs are actually needed (not the broad, we need these 10 ports to ALL of the Internet). So even those who KNOW what they're talking about, could try to secure things and protect some devices from others. Heck, I segment my home network (because I can; wouldn't expect most to) to isolate these devices, but they're still exposed to each other. I'm not about to do micro segmentation on a device-by-device basis at home.
Anyway... two things would be nice...
1. Document the actual network requirements (IP ranges if possible, hostnames configured if IPs/subnets are not possible, and ports for each [not just any of these ports to any of these IPs]); It's sad that the customers are having to post the IPs and ports they're observing. I may add my own to a thread on that, since I log all network access in either direction crossing any network segments (allowed or not).
2. Transparency about security controls - document it in reasonable detail (not just marketing/legal BS someone posted earlier). Heck, if someone's done a fair 3rd party assessment, publish that!
If you know of a working exploit why not contact Lutron and work with them to resolve it?
You can request a white paper on Caseta directly from Lutron
http://www.lutron.com/en-US/company-...iterature.aspx
Most might argue that any unencrypted control traffic over a local network (i.e. telnet) is a vulnerability in itself, though. It would be on almost any pen test report as a finding. I'm not planning to spend the time to do a full pen test and analysis on Lutron's product. I don't have the time and quite honestly a cost I think vendors should take on to ensure their products are reasonably secure.
This isn't just Lutron, though. My biggest gripe is lack of documentation... with Lutron and nearly every company making in-home (and corporate) products that now connect to the Internet.
Thank you for the link about the white paper. I'll request for it and take a look, but I doubt it will have the detail I expect/want (and many others have been asking about as I read through the forums).
That is very disappointing to hear. I was in the process of planning my deployment of the Lutron Caseta system in my home. My plan was to purchase the Lutron Smart Bridge, 6 Caseta dimmers and 8 Caseta on/off switches. I wanted to use the app, but only via my home LAN. For remote access I planned to use a VPN connection back to my home LAN.Quote:
Originally Posted by Eric H.
Would it be possible for the next version of the app and Smart Bridge to interface directly with each other? I do not want to be reliant on Lutron to secure access to my lighting system.
The App does talk directly to the Lutron SmartBridge. I actually can VPN in to manage my own via the Lutron app. I'm going more with using HomeKit, and making that my only "trusted" remote management method for any/all IoT where possible.Quote:
Originally Posted by dsfranken
Something I've been meaning to post is a network analysis I spent a little time on. It may help those looking to secure their Lutron hubs, or at least understand what it's doing/talking to. I'm attaching a ZIP here with two CSV files, showing the DNS hostname it's using to connect to IPs, what port and protocol it's communicating with, and some additional notes of things I observed (in some cases inspecting actual packets).
Primarily, for those looking to lock things down, enable the update related IPs and the AWS IPs it uses, so you can get updates. Lock down most other things with Internet access. NTP (time) uses a bunch of services, including some I suspect they hard code by IP address. I don't generally block NTP (port 123/udp), and few people do.
If you have your bridge on a separate subnet internally from the rest of your systems, and you want to do HomeKit integration, you'll need to look into mDNS repeating with your router. Unless you run something more advanced than most basic home routers, this wouldn't be an option for you, but then again, you probably don't have isolated subnets. :) Also, you will want to put your mobile device (with the Lutron app) on the same subnet when pairing it. That way it knows what IP to find your Smart Bridge at when it's not seeing locally broadcast info (could be an issue with a VPN IP range, unless they're bridged). I forget if there were any issues with a possible IP re-assignment, or if I tested that. I statically assign IPs (via DHCP), so it's a non-issue for me.
Anyway... I hope that helps for those looking to be more complex and/or secure/restrictive with their networks.
Oh... btw... with what I did see, security wise, things don't look too bad (minor issues). I would like to see the firmware update hash files to be over TLS and not something that could be Man-in-the-middle attacked. But an attack on that would also require compromise to the firmware updates sources AND a MitM attack. So, lower risk, but still not best practice.
I still would like to see Lutron formally publish this kind of info, rather than someone like me having to monitor network traffic and correlate DNS queries to get it.
Cheers,
-Alex
Attachment 614
First off, you sir are awesome! Thank you.
I have a couple of questions.
1) You mentioned that you VPN in, to remotely manage your lighting using the app. Does that mean if you blocked the bridge from accessing the internet you would still be able to manage it with the app? I am planning on completely blocking it from the internet. Have you tried this?
2) When internet access is blocked will any functionality be lost or will there be any nagging warnings in the app to restore internet connectivity?
I don’t mind a device receiving automatic updates, but in this case Lutron seems to indicate that the bridge is remotely controllable via their cloud(AWS). This is especially worrisome as their devices will be in control of power systems in my home. Even if I isolated the bridge from the rest on my network, used a destination NAT to send NTP to my server and filtered the DNS with something like OpenDNS, I would still be concerned about external backdoor access.
All these concerns would be allayed if you can confirm that it can function without any internet access at all.
Thanks. You're welcome.Quote:
Originally Posted by dsfranken
I can VPN in. I tested that early on when I was setting this up. The bridge had no access to the Internet at all (except time) when I tested that. Currently, it does have access for firmware updates. I just re-tested it a little to be able to answer this accurately. I had some issues, but have confirmed that my VPN connection was able to communicate directly with the bridge through my VPN link. I had some issues when connecting in from a different network, but I'm certain that is entirely something with my network config, and likely related to mDNS not being repeated to my VPN link (although not verified).Quote:
Originally Posted by dsfranken
What I have tested just now is that with the Lutron having no access (I temporarily disabled even the access to updates), I could directly control the lights via the bridge when my iPhone was connected to a different internal subnet (mDNS repeated), and from my VPN zone when I connected to that. I verified this with traffic logs and what fw rules were triggering for the connections.
So, if you do have issues, it will likely be related to any complexity of your home network. Here, I fully isolate my IoT from my home computers and from my entertainment type systems (i.e. media center and Apple TVs), such as they are on different subnets (i.e. 192.168.44.x vs. 192.168.45.x), with firewall rules enforcing zone separation and specific rules. My VPN is just another zone with another set of rules. This is more complex than most people will have setup at home though. Most likely, people will have a single flat internal network, and fw rules that restrict access for specific devices to the Internet. And if your VPN dumps you onto the same subnet, then you shouldn't have any issues.
I still really wish it was an option, at least, to be able to specify internal IP addresses for your Lutron bridge(s) rather than ONLY negotiated via mDNS or other broadcast.
Not that I've seen. If it fails to connect, it tells you so, but if it connects, it seems to work normally. Again, for me, it's a limited test cases with direct use of the Lutron app. My primary use is to connect with HomeKit, and then I use the HomeKit interfaces, including HomeKit method of remote access (without having to VPN in). For me, this consolidates the many ways devices my "enable access" to my network, and I generally trust Apple's approach with HomeKit remote management over the various IoT vendors (no offense intended, Lutron). Going with HomeKit for that also let's me use a Raspberry Pi as a bridge where I can define devices and let Siri control them if I can have the Pi control them (i.e. an IP power strip that can be controlled via ssh commands, or ANY other method of control).Quote:
Originally Posted by dsfranken
In most cases with IoT vendors, I fully agree. For example a SmartMeter (electricity) bridge I have tries to establish an outbound VPN link as their method of pushing updates. While possibly a very secure method to push updates if you trust the vendor's network control, it's frightening to think that vendors think it's okay to establish VPN links into other people's networks.Quote:
Originally Posted by dsfranken
However, Lutron does this a bit better than most, I have to say. They have completely separated the services for remote management and firmware updates. If you look at the CSV data I shared, you'll see they have separate hostnames for the different functions, AND they don't seem to have overlap in the respective IP ranges. So, you can reasonably assume that if they connect to 52.216.0.0/16, it's for the access to the firmware update hash file (hopefully actually used for an integrity check when it gets the FW update, and not just to see if there is one to DL). Or 54.243.115.89 would be for the firmware update itself. The 52.23.255.232 IP (along with a handful of others) seem to be the ones they use for the bridge to authenticate against the service. But the remote control service itself seems to be entirely managed through 52.23.255.0.24 with the xively.com service.
So, with that reasonable separate they seem to be using, you can allow some things, but not others. Of course, since they don't maintain a published list of IPs/subnets (poke poke, Lutron!), this could change. This data is based on a couple months of capturing traffic while I allowed it to talk to the Internet openly.
This I can confirm. I would be annoyed if Internet access was required just to work. I absolutely avoid any IoT devices where it only works if their service is available online. That creates a dependency where your stuff stops working if the company goes out of business or discontinues a service, and I won't accept that when I put good money into something.Quote:
Originally Posted by dsfranken
I would recommend letting it do firmware updates, though. Even without it having broader access to the Internet, keep in mind that vulnerabilities over time could still be exploited if something else gets on your network, and then could use the outdated (assuming security vulnerabilities and firmware updates haven't applied) Lutron bridge to infect and maintain a foothold.
Anyway... again... hope that helps. With a more advanced network config, you may need to do some extra leg work, especially if you do full subnet isolation like I do. But the Lutron device itself (and app) CAN work even in my config, so if you hit issues that occur when crossing network segments, look to network structure and/or mDNS/broadcast packet repeater needs.
Cheers,
-Alex
I set this up today. I have a separate IoT network (VLAN and WiFi) on my firewall for IoT devices. On my network all of my trusted WiFI is allowed into the IoT network, but all IoT network communications are blocked unless I explicitly permit them. I had to enable *source* port 8081, 5353, and 4548 from IoT devices to my LAN to get the app working.Quote:
Originally Posted by asleeis
Note that the smartbridge requires NTP and also tries to communicates to AWS on port 8883. No idea what it's doing in the latter case but I'm gonna leave that disabled.
What exactly is the concern here? You're behind a firewall and a NAT at home there is no way for someone outside your network to access the bridge without the bridge contacting them first- ie. Lutron's servers. Either you trust Lutron or you don't. And really, what's the worst that can happen? Hackers try to break into your home wifi so they can turn on your dining room lights?