DDNS Servers, Services and Security

Hardware Questions and Recommendations
1

This is admitedly not a LEDE only discussion, but I am looking for some perspective related to how secure (or not) my environment becomes by using common IoT devices at home (behind LEDE).

As best I can tell, all major IoT platforms use DDNS services, which I believe are created in the background during device configuration (with little user knowledge.. Oh it Works!!). I assume I get at least 1 per vendor.

Assuming I change the devices default user and passwords, what exposure is there for these devices and more importantly what exposure is there for the rest of my computers and NAS?

If one of these vendors gets hacked, what additional info about my devices and network can they obtain?

What options are there in LEDE to better secure the environment?

And of course, I don't know what I don't know.

2

A wired participant on your network can do basically anything they desire. From listening on the wire to actively bruteforcing passwords, participating in a ddos attack, doing p2p filesharing or mining the next virtual currency units. With untrusted or known compromised devices on your network, you do lose the first line of defense and basically degrade your internal network to the same (in)security standards of the open internet.

The only things you can do is jailing untrusted devices into their own vlan and switchport, their own DMZ, and then trying to limit their abilities (firewall rules) as much as possible. But at least the typical cloud-connected features remain vulnerable to the mercy of their owner (or to anyone who has found an exploitable security hole), which is not you, but the one running the cloud service in question. The only limits are the hardware capabilities of the devices in question and the performance of your WAN connection.

If you care about security or sustainability, you'll only run devices that can run in a standalone fashion without requiring a connection to someone elses cloud, jail them into their own vlan (dedicated switchport) without actual internet access and only connect to them from the inside (or a VPN login to the inside).

1 Like
3

Obviously there are different shades of grey, from more or less fixed-function devices only submitting their status to "the cloud" (think temperature sensors, only posting the temperature readings; don't underestimate their surveillance value though), video cameras relaying their video stream to external entities up to devices that allow configuration changes (up to and including firmware replacements) from the vendor's cloud. Anything that does include a backchannel (not just posting data to the internet, but allowing external access, like facilitated by various dyndns like capabilities) should be considered dangerous, even without active malicious intent from the vendor (who will stop security support sooner than later).

4

As to options to better secure the environment, there are numerous ways to split up the network.

For low-bandwidth devices, you can nail down their ip address with a lease, plug them into their own port on a LEDE device, then use ebtables/nftables to ensure they use only the leased IP/MAC tuplet and control what they talk to both on-net and off. You can do the same on wifi gadgets as long as you are hairpinning wifi clients off a br.

Doing this for higher bandwidth devices would tap too much CPU, unless you can afford to throw more hardware at the problem.

The more challenging thing is that since most of the wifi capable gadgets are WPA2-PSK only, and anything that as your WPA-PSK key should be considered a possible impersonation/MITM attack vector, you'd optimally want each to have their own SSID, and things fall apart when you run more than a handful of SSIDs due to beacon congestion (less so on 5GHz, but cheapo gadgets won't have that.) Hopefully dot11u will find a reason to become trendy enough for the IoT hipsters to put it in.

None of this protects you from cloud service compromises letting people read how you are doing on your diet or perving over your cat-cam, but it can keep a compromise from spreading to ore sensitive gadgets... but of course, not your phone, since all this crapware has to have an app.

5

@slh I guess this falls into the I do not know what I do not know category. Your comments beg the question of how to determine what is a trusted device, as the disclosures, assuming one reads the fine print, is limited.

@skids, thank you, but unfortunately most of your comments are above my understanding.

I like the vlan suggestion, but will a guest AP that has no access to the rest of the lan work if I only have wireless devices?
LEDE could use a good How TO on setting up the VLAN. I am struggling with this page: https://lede-project.org/docs/user-guide/switch_configuration

I have spent too much time the last two days reading about this and just amazed at how insecure all this is. What is most scary is there does not seem to be info on how to determine if your device is hacked. It sounds like immediately changing my default creds is the best thing to prevent botnets, but is like locking the front door. A window still maybe open.

What I am not clear on, and think I fear more, is that if a vendor gets hacked, the info they have collected would permit access to the device and my LAN through the device.

It seems that Home Assistant is the only tool that I can find that clearly states it can run offline, indeed defaults to this mode. Way too much I do not understand about configuring this. It does appear that while there is a lot of supported hardware, much of the major hardware is not supported, as I assume it wants to call home.

6

I feel your pain on security... welcome to the wonderful world of prosumer equipment.

(Actually I work mostly with enterprise-grade equipment, and while it is much more secure, sometimes even there, there are some surprising features missing... at least surprising to anyone who actually cares to secure things at the network level.)

The issue of vendors compromising client devices is not very new... the same issues exist with your web browser offering a possible back door into your PC... and it has taken quite some work over the years for browser developers to develop and implement a security model.

The difference is that IoT is still in the wild west stage. In analogous browser terms they are just about moving from MOSAIC to NetScape and maybe thinking about implementing https.

Playing with the switch config is pretty treacherous... you can lock things up pretty badly if you do it wrong and have to go back to failsafe mode or even reflash depending on what platform you are working on. First get it working from the cli using one of the switch control packages (these days there is a legacy and an iproute2 version of just about all network cli tools). That way you can just reboot to fix things.

It's actually really simple and I don't know why it ends up being so hard to explain:

  1. Each switch has one internal ID for each VLAN. This ID is not necessarily the same as the VLAN tag as it appears on the wire. Each "switch_vlan" statement is one of those internal IDs. The "vlan" option in this section says what the outside-world VLAN tag is for this internal ID. LEDE config files never show you the internal vlan ID.

  2. Each switch has a connection to the CPU. From the perspective of the switch this is just another port (just without a jack). From the perspective of the CPU, this is a network card. Each "switch" statement is one of those. The network device seen by the CPU is the name of the "switch" section. We will assume for now you only have one switch.

  3. Each port, including the fake one attached to the CPU has an internal number on the switch (some switches start at 1, some start at 0). Knowing which port number is the CPU is important. Also, knowing which number is the interface you are logging in with is important. Knowing that there is an extra "fake" CPU port that (for your purposes) goes nowhere on a lot of models can also come in handy. The numbers do not always match numbers printed on the plastic.

  4. The WAN port is usually not part of the switch. It is seen by the CPU as another network card.

  5. From among your switch_vlan statements, each port, including the fake one that connects the CPU, can choose one "untagged" VLAN and as many "tagged" vlans as the hardware supports. Ports do not have to carry every VLAN on the switch, so we list which ports are in each VLAN. And we add a "t" if that VLAN is tagged on that port. A port should have a "t" after it in every switch_vlan it appears in except optionally one.

  6. The switch_vlan statement where your CPU port has no "t", if any, determines what VLAN the "ethX" device on the router is talking with. Where "ethX" is the name of the owning "switch" statement.

  7. If the CPU port appears with a 't' after it in a switch VLAN, you can create a vlan interface on the router. We usually name these "ethX.Y" where Y is the actual VLAN tag (we pretend the switch's internal VLAN IDs and internal port IDs do not exist; they are useless outside the switch). This interface can talk with that VLAN.

  8. If a port is listed without a "t" it now has to deal with a small problem: it is sending packets from one VLAN without a tag on them. It expects replies to those packets to come back without a tag attached. But what does it do if it gets a packet that IS tagged and the tag is the same VLAN as it is sending out without tags? In a sane world, the answer would be that there is a flag that decides whether to ignore those packets, or alternatively, just pretend they didn't have a tag, but since networkers will make anything more complicated just to allow for weird use cases, instead what they did was give you this "pvid" value, which requires you to manually tell the switch what to do with packets that have NO tag, and on prosumer gear they do NOT give you the option of ignoring tagged packets. Jut set the PVID to the VLAN tag of the switch_vlan stateent where the port appears without a 't' after it.

  9. Keep everything neatly ordered if you are gong to use LUCI to set up the switch. Some of the LUCI scripts can screw things up royally if things are out of order to start with.

  10. For best security, don't use untagged VLANs on your backbone wired links or links to servers that have to be on multiple VLANs, to prevent QinQ tag hopping attack vectors. Only use them alone, for clients. Note that WiFi has no (functional) VLAN tag, hostapd emulates that, so you don't have to worry there.

  11. You can see the port numbers for your switch by looking for its model string in /etc/board.d/02_network, and hoping it is right for your particular device. Some models even have the numbers printed on the plastic mapped there so UIs can make use of them. If the plastic numbers do not appear, it could mean they match the switch numbers, or it could mean nobody has bothered to flll them out since that feature was added.

  12. You can apply IP addresses to the ethX or ethX.Y interfaces directly, but usually, you join them to a bridge and apply the IP to the br interface. That allows you to put wifi clients on the vlan.

So for admin purposes, if you must admin from Wifi, the best thing is to get your admin device locked to a particular IP, then allow packets to go through the AP, to the router, through a pinhole for that IP in the firewall, and onto the backbone, where you are letting LUCI listen on the APs.

Locking IPs can be done by giving them a special lease in the DHCP server configuration.

Making sure that devices do not steal your IP can be done by adding firewall/bridge-firewall rules to only allow that IP to be used from your MAC address. (Which is why when I started playing with LEDE one of the first things I did was make packaging for ebtables-dhcsnooping to do so automatically for all clients.)

Making sure nobody steals your MAC address when you are not around (or through another AP) requires running WPA-enterprise and doing crazy stuff with FreeRADIUS, not to mention rolling your own mini-PKI.

TLDR: running a truly secure wifi network is really friggin hard, and you cannot buy your way out of the pain with prosumer gear, and the only thing enterprise gear does is move half of that pain to your wallet.

also TLDR from my first post: WPA2-PSK is inherently insecure unless you trust all your clients not to mess with each other (per SSID). IoT clients cannot be trusted for reasons you stated beautifully, and most only do WPA-PSK/2.4GHz. You only have so many SSIDs to burn on 2.4GHz. Ergo, IoT wifi junk is utter crap for security (and wired is junk too, given prosumer wired switch feature sets.)

Obviously, to sit here and write this, I am waaaaaayyyy too bored tonight.

2 Likes
7

Thanks for your reply.

Apparently I do not have a switch in my current device. I began this new post hoping it would be more generally relevant. ALIX 2D13 - No Switch for VLAN

I glean from your comments at the end that an infected device may infect other devices. I also assume that in addition to using different SSIDs for wireless that these should be fire-walled so as not to see each other. I also infer from this that devices connected to a hub may possibly communicate and compromise each other.

Unfortunately I do not understand this

I set all my devices static IPs in the DHCP file. I like to know what is what.

I have not heard of pinholeing before. Googled, but not really following (or need more coffee). I assume this means some firewall rules to regulate the devices.

I think i can create a separate interface on my ALIX and put all my devices on that with it's own AP and hubs as needed. If I use Home Assistant in it's default stand alone mode, does this eliminate many of my issues?

I guess I could isolate it totally from the internet, but would like to be able to send text messages or an email to my phone (I assume this is possible) for alerts. (My big want is a water leak sensor and a door lock. I really need alerts for the sensor to be of value, the door I only need to lock and unlock when I am on the WIFI)

I have little need to manage the services from outside, but I do have an OpenVPN server running. I assume that I would want a second VPN server that points to the "IoT" interface to keep things separate.

8

Pinhole just means a small exception to a general rule. So if your general rules is "wifi devices cannot see my cell phone" a pinhole would be "...except this one WiFi device". (There's a more technical definition that applies to NAT helpers, but not here.)

If you're happy with just keeping the IoT devices in a place where the only thing they can mess with is each other... which is better than most people manage... I don't think you need to have a separate AP. You don't need a switch on the ALIX itself to do VLANs... you just need to be able to define tagged subinterfaces. You could hang a hub off a LEDE device which does have a switch, and use that LEDE device to bridge that hub's LAN to the ALIX over a VLAN. You could also add a separate SSID's wlan interface to that bridge (on the LEDE device) to merge in IoT wifi clients... all while your normal hosts use a different SSID and different hub on a different VLAN on that same AP.

This would be easier to see if you didn't have to view it through the fog of a pfsense configurator.

I'd focus on understanding a simple link between two devices carrying more than one VLAN. You can do this
with a couple of linux PCs or LEDE devices. Then learn how to add interfaces to a br interface and move the IP address from the member interface to the br interface. Then it will make more sense.

Suppose you have two linux boxes each with just an eth0, connected directly to each other. Configure
them to communicate with IP addresses. This is an untagged link.

ip link add link eth0 name eth0.10 type vlan id 10 on both
ip link set eth0.10 up

...now you'll see eth0.10 on both boxes and you can configure a different subnet there, as if you had two ethernets on each box and two wires. Test that that works. Then try to get your ALIX to see two interfaces on its extra port through whatever abomination of a UI pfSense uses for this, and test with one of the boxes that it does.

Then delete the IP from one of the LEDE/linux interfaces, create a bridge interface, add that interface to the bridge interface, and put the original IP on the bridge interface. Things should still work as before. You can then add other interfaces to that bridge and the linux or LEDE box pretends to be a switch connecting them all together.

1 Like
9

ALIX is running OpenWRT CC 15.05 RC2.

Still not clear that I can or can not simplify this by setting each Ethernet port to it's own interface and subnet?

I only have dumb switches, but do have a number of unused APs.

[quote="skids, post:8, topic:4954"]
If you're happy with just keeping the IoT devices in a place where the only thing they can mess with is each other... which is better than most people manage... I don't think you need to have a separate AP
[/quote]It's bad enough that to just use the internet I have become an unwilling statistic, but for me to pay someone to use their product and also be required to give them my usage info rubs me the wrong way. I see little of what HA does truly needed outside the house, past the "cool" factor.

10

Well, if you've got the APs and switches to throw at it, sure, using the other ALIX interface to have another IP range on a physically separated interface is a quick and easy solution. You just need to teach the firewall about the new zone and write up policies as to what can and cannot happen between zones, make sure NAT and routing are squared away and you are done.

1 Like