How to set up a totally locked-down network

Isn't it just normal to put the "IoT" (the "s" stands for security) devices into a separate vlan with no access to the internet at all?

You might want to help us a bit by providing some information of you "smart" things?

Do some need a active internet connection to work? Are you sure you could restrict them to one/some hosts so they are working but not tracking or don't do whatever you don't like?

Oh but I do not want that! That would be easy. The point of this is to control "smart" devices that may even be useful.

Example: We have a modern TV which can probably be a browser and play videos etc. but I dare not let it on the network to use these features because I am absolutely sure it will have a wider agenda. It may even have a girl-friend like Alexa. It might want to update and break itself. So I want to offer it a different WiFi access point into an almost sand-box but where I can decide which servers it will be allowed to access.
Another example is that I think our planned upgrade to our boiler may come with unwelcome features, but may still need to be accessible via the network.

To be honest, if it was easy enough to use I would not mind all our external traffic being vetted. I used to poison unwelcome names by adding them to my PC's hosts file redirecting them to something local and non-existent but I found some analytic sites cleverly making up endlessly different names to defeat this.

I not sure how many "smart" devices you own but to have each "legit" connection white listed it might take you some weeks, months or even years. You will also find out that the same connection needed that the thing "works" (like showing web content for example) is the same they use to deliver "anti features" to you (the things you want to "control"). Another thing is that it will always break. The consumer grade internet of sh!t things are known to ship fast and get ripe at your place (they ship updates to make things work - other break and so on...)

If you have only a coupe of devices and have the time you could maybe work something out... but if you are an average customer you will have already around 15 of this black boxes and the only "real" (time preserving) solution is to proxify them with something like pihole or so...

In the end it comes down to what @trendy says:

1 Like

Exactly. This is why pi-hole is not quite enough. Ideally I want a pi-hole thing to update a whitelist of IP addresses as it dishes up whitelisted results.
And if there are devious protocols to reach sneaky DNS then even more reason for this.

The idea that you can just "not buy" such devices is becoming unrealistic. This crap is not going away any time soon and I want to be on top of it, not underneath!

1 Like

If you want to be on top of it you should avoid to buy the crap :put_litter_in_its_place:. Actually not easy and you have a lot's of vendor locked proprietary "smart" things which often rely on clouds :cloud: (other peoples :family_man_man_girl: computers) are out on the market doing sweet talk to end up in your home :house: or close to you :hear_with_hearing_aid:

On the other hand it's today already de-facto impossible to have state-of-the-art/bleeding-edge technology (like "smart speaker" for example) with only free hard- and software. But one could at least use partly open hardware designs combined with open source software (could use a sbc and run almond to get a privacy preserving virtual assistant).

Instead of a smart tv I use a dumb tv combined with a little $25 arm box supercharged with core elec (running kodi). With this setup I have maximum freedom and can fully utilize the potential of the hardware like using the internal screen grabber for bias lightning (hyperion).

I could now go on and on but it all comes down than if you want control over the stuff in your network you need to know it (really own it). Integrate transparent boxes instead of (crappy) black boxes :bulb:

2 Likes

There are several techniques that can be used to secure a network, but the are always a tradeoff between convenience/ease-of-use and normal functionality of both the devices limiting the connections (router/firewalls, dns filters, etc.) and the devices that need to be restricted (i.e. smart TVs and other IoT/marginally trusted devices).

VLANs are a great way to at least keep the untrusted/marginally trusted devices from gaining access to your trusted systems. But that doesn't solve everything, of course.

Assuming that the devices in question don't use DoH/DoT, you can hijack/blackhole the DNS services fairly easily -- just create a rule on the appropriate network that drops and/or redirects all dns (port 53) requests. From there, you can use a PiHole or other similar package to restrict to only the allowed domains.

You can, of course, always create firewall rules that drop/reject all except the explicitly allowed traffic, be it domains/IP addresses or port numbers -- you can do this on an entire network/VLAN, or you could filter by the specific device(s) IP address(es) on your network.

Another way to approach this is to simply monitor what your device(s) do in terms of their external connections and then craft firewall rules that limit/allow traffic precisely as you need for your network security.

The trouble is that each manufacturer (trustworthy or not) will have their own services and protocols. Some should absolutely be blocked and will make the device 'safer' to use. In other cases, blocking some services/ports might cripple some of the features that are integral to the device that are actually necessary and/or valued by some or all users that device. I'm guessing that this is why nobody makes a pre-fab device or firewall/filtering software environment that can provide a good user experience without adding too much extra work in terms of configuration and maintenance -- at least for the average user. And there's no one-size-fits-all recommendation that can be made here, either.

2 Likes

Thanks guys for drawing my attention to the fact that it is all a lot worse than I thought.
DoH is a disaster! It totally bypasses the pi-hole approach. I am now totally convinced that my idea of only routing IPs that were obtained from whitelisted DNS is the only way to make a safe system.

I can see I will end up having to code this myself. Pity I don't have the time for that.
But is there any way that an external machine could do something to an OpenWrt thingy to say to it "here is a valid IP address for your routing table"?

and when the A/AAAA record is modified on the upstream dns server... how will that external machine know that ip is valid?

Not sure I understand what you are saying here.
I am not trying to validate the DNS service results. I just want to construct a network that only allows clients to talk to IP addresses that they were given by my DNS server. If they ask a different one they may well be out of luck - so they must use the one provided. If the DNS database is updated then something will have to ask again.

how do you know the one they are asking for is the correct one?

You will always behind and even if you spend a lots of time you will realize that many of the crappy/sh!tty "smart" devices work with the principal "eat or die". So in the end it comes down if you are confident enough to use it with all the "anti features" (like tracking etc.) or you don't use them and turn them into a :brick:.

I also really wonder if you already thought about your other "smart" devices like phones :iphone:. They are very well known collect any possible data of you. Just an idea what apple and google like to know about you:

We find that even when minimally configured
and the handset is idle both iOS and Google Android share
data with Apple/Google on average every 4.5 mins. The phone
IMEI, hardware serial number, SIM serial number and IMSI,
handset phone number etc are shared with Apple and Google.
Both iOS and Google Android transmit telemetry, despite the
user explicitly opting out of this. When a SIM is inserted both
iOS and Google Android send details to Apple/Google. iOS sends
the MAC addresses of nearby devices, e.g. other handsets and
the home gateway, to Apple together with their GPS location.
Users have no opt out from this and currently there are few, if
any, realistic options for preventing this data sharing.

Over 99% of users typically bite the bullet (or bitter apple :green_apple: they say in german) and only a fraction tries to lower the collection fever from the manufacturers.

There is also literally nothing you can do on a apple device to stop this, not in your router and not in your phone. All or nothing.

1 Like

There are lists of IPs of DoH servers on the Internet. (example)
These would have to be blocked in the firewall with port 443.
There are not that many servers - it is basically enough to block the large providers, since they are most likely the fallback from the smart devices.
Therefore, it also makes sense to implement a rule for classic DNS that blocks all traffic on port 53 except to your desired server. You can also go a bit further and secretly redirect all traffic on port 53 to your DNS. This way the devices think they are communicating with 8.8.8.8, but instead they get the replies from the local pi-hole.

Even if this (incomplete) list and DoH wouldn't be a problem it comes down that you (@GMB) play the cat and mouse game. Thing is you will always be on the loosing side as manufactures have ways (source code, infrastructure, resources, ...) to just always be ahead of you.

There is simply no way to to trust not trustful (crap) devices even a little bit.

Instead of investing a lot of time trying to partly mitigate anti features of sh!tty devices you should rather focus on not getting more of them and (slowly) migrating to trustworthy (local, open source) solutions like you did with your decision for openwrt :+1:

That's the only way..

2 Likes

This is entirely dependent on your perspective -- a user or an admin.

From the user perspective, this is a significant improvement over standard DNS. It provides an improvement in privacy with respect to dns queries -- the connection between your device and the DNS resolver is encrypted which means that people in the middle (such as ISPs, governments, etc.) cannot peer into your requests (although they can still see the IP addresses you visit post-DNS resolution). But maybe more importantly, it secures the DNS system from redirection attacks. Using a pihole as an example, I could redirect your queries to another address and potentially phish your credentials (ssl/tls websites do help prevent this to a degree, but people don't always notice if a site isn't actually https).

Obviously, as an admin, this is a harder situation since it severely limits the dns monitoring and filtering capabilities.

1 Like

Probably the most secure way to do it is to use the firewall to block everything except the Ip addresses of the servers you allow. You will have to update if the ip changes, either manually or through a script. Even with encrypted dns, it can only communicate with the ips you choose.

For home automation, i suggest flashing your devices with a custom firmware like tasmota and running a local server like homeassistant. This can keep everything local to your network.

If you need remote access you can use zerotier.

I just think that DoH using the usual https port was a deliberate decision to make it hard to stop. The other encrypted DNS system has its own port - much better.

My concern with all this is growing because "don't buy it" is a dying option. For example I understand that homes with electric car chargers are obligued to give them an Internet connection. And I suspect that the replacement for our mangy central heating boilers may need to be controlled over the Internet so I need a way to make it visible without it getting ideas about doing its own surfing. The trouble with WiFi and DHCP is that once a device knows the password it gets given too much access. Having a little OpenWrt access/router will let me keep it at arms length. And I think I will try pi-hole running on my rPi server.

Any reasons for that? Don't think so.

But guess, I can control my water heater over the internet, also most of my lights, fans, water pump and most other stuff in and around my home.

Did I ever use it? Kind of never, I think once (like 2 years ago) turned my water heater on from remote when we came back from holidays so we directly had warm water arriving late and could have a hot shower.

Actually I retrofitted my "dumb" hot water heater with like $10 hardware and refined it with a open source firmware (esphome). Actually all my "smart" stuff runs open source software.

does the rest combined with my openwrt managed network. So I got (in theory) wireguard to access my home network but in reality it almost never (can't really remember the last time) get's used. But because I use open software (no vendor lock!) I set up signal on my home assistant server which is quite convenient (E2E encrypted communication without vpn). I get snapshots from my (local only) camera :movie_camera: if motion is detected (it also works as a automatic bell at home and plays a chime on the stereo system :bell:) Also it's possible for me to "talk" and ask like the warm water temperature (solar) for example.

And all this without depending on any sh!tty manufacture (and their limited possibilities). You don't own crap (or data) when you rely on cloud services (which can btw. vanish from time to time or just start to have a subscription fee). To depend on other peoples computer for stuff in your own home is surely one of the most stupid invention we had in the past.

But sure, go ahead if you think you need the crap just buy it and get happy in the golden cage :grin:
You will just end up with limited possibilities and wasting your time trying to tame the beast - good luck :clinking_glasses:

1 Like

I think we can stick to the technical discussion rather than debating the good and bad of this particular approach. Let me paraphrase OP's need:

  1. block/redirect outside DNS and DoT/DOH to force local resolve
  2. stateful IP allow-listing based on DNS responses
    This is basically what happens on a paid wi-fi access point before you pay. When you send DNS request to the whitelisted domain names (e.g., maps.googleapis.com), the response IP address is allowed.

I think this works reasonably well (it blocks off a lot of actual human being and trick them into paying!) so it's quite worthwhile to implement it. Although easy to bypass, it's still meaningful. I always bypass it by manually sending a request to get a Google IP whitelisted, and start a SSL connection to that IP to access gmail etc.

I believe the feature I mentioned is commonplace builtin feature of some ubiquiti/aruba commercial-grade wi-fi controllers. Not aware of any open-source solution though -- it needs a tight coupling between the DNS resolver and the firewall. Maybe pfsense works. Hacking OpenWRT is definitely an option but you probably will need to write a custom script to monitor and parse DNS resolve logs (from dnsmasq) and add iptables rules in real time, and also expiring those rules.

That's interesting about how the WiFi access works. I had always wondered.
I can see I will have some work to do. I had hoped it would have already been done.

MangoMan completed misunderstood. The whole point is that I will NOT be using cloud service access routes because I have my own little cloud but if I let a "smart" thing get a wiff of the outside world it will surely go after its home. But they may need to be accessed locally. Also anything offering a handy service like a browser I might want it to work, but again while keeping it away from its home base.