I agree we should we need to think about security first, it will be near impossible to fix this later if we get this wrong. Think of the Mirai botnet that reached a 1 Tbit/s attack a few years ago using hacked IoT devices.
The minimum I do at home is physically separate my IoT network from my “normal” network.
Steve Gibson explains one way to do this in his Security Now podcast, episode 545 or Google “three dumb routers”. I think you can do the same with the $50 EdgeRouter X from Ubiquiti.
Even if your gateway or one of the nodes gets hacked / is malicious they won’t get access to the rest of your network.
Also, most “make your own gateway” tutorials don’t mention a firewall but we could easily set a firewall on these Raspberry Pi gateways and only open the ports needed for the package forwarder, no? Anyone knows what the minimal open ports are for the forwarder to do his job?
I haven’t had to open any packets for my RPi based one to work using the mp_pkt_fwd forwarder.
I’d say that the main thing with RPi gateways is to maybe install a linux firewall package. But the usual change the default password away from “raspberry” , change SSH if open to a different port and ideally make it use ssh keys instead. And even delete the Pi user and create a new.
DMZ doesn’t have to open all ports & all traffic indeed it shouldn’t ! - might as well then be a raw direct connection to the Internet/Wild Wild Web - a weak consumer device may do that, but should at least have basic NAT and filtering/port forwarding options however anyone seriously concerned about network security or protecting valuable target assets & looking to implement such would likely buffer the raw internet connection through a router that either has configurable firewall embedded or where a separate firewall platform is run to protect the DMZ and provide initial filtering for onward core network. There are many relatively low cost devices available (giyf) that are suitable for SoHo/SME use and deployment.
Your idea of guest WiFi is sound as far as it goes - it essentially creates a WiFi based DMZ separate from core network and primary WiFi, though many of the ISP supplied devices end up with security issues and weaknesses of their own (not least due to ISP’s own back-doors, and things like poor TR-068/69 implementations etc.) and of course any bad actor only needs compromise one device
I often take an ‘onion’ approach with (say) ISP supplied Modem/Router as front end to 1st layer of network - essentially then considered the DMZ - then have separate, better protected and (stronger) firewalled router buffering the inner core network (and possibly deeper cores behind other layers if needed - though can get complex to set up/debug, adding a little extra latency and forgetting to forward ports etc can be a pain;-) ). With few devices in the DMZ there isn’t much compute beachhead realestate for onward attack to core router and inner network
I imagine there must be a lot of folks like me who would like to grow the network & coverage map, but are concerned about security. I’m aware that LoRA is currently a niche protocol and not on many hacker’s roadmaps, but this will change. My expertise is in embedded, mainly hardware, and I find the I.T. aspect a little bit scary. Make it easy for folks like me to plug a gateway into our ISP router safely, and we’ll help the network to grow.
Despite the postings - including my own - dont sweat too much on it - just do it!
LoRa, or in this case LoRaWAN (which defines the ‘protocol’ as you call it vs the RF Physical layer/modulation of LoRa) is relevent from device to GW, from there on its all ‘just’ TCP/IP or UDP carring a payload of device data and associated metadata and any IP related security issues are essentially no different to any other IT or Networked device/platform…follow best practice for the Network side and you should be as safe as is reasonable and practical
Issues tend to be in the details such as ability to manage and control/turn on/turn off interfaces and to implement any required filtering & fire-walling and longer term how to handle/manage/roll out firmware updates to GW’s and supporting network infrastructure and fixes for bugs later identified…
As I say just do it…the LoRa/LoRaWAN eco-system, the LoRa Alliance and this (TTN) community particularly has a lot of eyeballs looking for problems and gotcha’s, and more importantly suggesting fixes and best practice, so there is some degree of confidence and ‘paranoia’ mitigation
you shouldn’t be… but if its really terrifying for you then maybe its better not tot connect a lorawan router to your isp router
I post a lot of articles about security because IOT in general and security is a worldwide concern.
Another solution I came up with is if its a Raspberry Pi based (or maybe some other commercial if they’re linux based) is to use a 3G / 4G Modem. While there’s the extra data costs it does achieve full isolation.
I think another benefit of LoRA is the end to end encryption, which might in some way make it harder to attack nodes along the way. I’m not a hacker so I’m guessing.
@Ryanteck: Any decent router would have the DMZ as follows:
Internal LAN -- Firewall -- DMZ -- Firewall -- Internet
where the “two” firewalls are just two sets of rules. These rules should allow you to control what ports are open and in what direction.
That said, if you’re using a BT Home Hub it’s not at all clear what gets blocked. What we really need is to place the GW in the DMZ and only allow outgoing traffic.
As others have said, I’d feel safer with another router/firewall as follows:
Internal LAN -- Router/firewall -- DMZ -- ISP router -- Internet
Any decent router would. However I was referring primarily to the three big ISPs own (BT Home Hub, Sky Q Hub & Virgin Medias Superhub 3 of which in the last year I’ve used the Sky & Virgin hubs and both do DMZ where it just opens all the ports and doesn’t isolate it to the best of my knowledge, furthermore there’s a whole argument as to weather you should use them but the hassle to not use them isn’t worth the benefit to me plus the whole cost and the fact every time it goes down the ISP blames your equipment, it just really isn’t worth the hassle.).
As for allowing only outgoing traffic part of the argument is that if the gateway gets turned into a botnet of which outgoing traffic would be part of the issue?
Arguably the best way for isolation would be to have the gateway with its own internet connection. Complete isolation.
However I think for now this is a bit overkill. I’d still say that literally every other device on your network poses a bigger risk.
The DMZ and internal LAN should be on physical separate ports (or at the very least different VLANs with a switch only passing DMZ traffic unencapsulated to any system in the DMZ) for this setup to add any security. If everything is on the same LAN but just different IPs (or even different ranges) any hacker worth a dime will still be able to access all other systems if any DMZ host is vulnerable to any attack. Most cable modems I worked with over the last 10 years did not implement this. (DMZ host in the same IP range and on the same physical network, bad bad bad)
This potentially does not protect anything in the DMZ at all depending on the ISP router setting. So I would prefer a setup:
Internal LAN - Firewall - ISP router - Internet
DMZ /
With LAN and DMZ on separate ports of the firewall (not bridged of course)
As (part) author of a packet forwarder I know a thing or two about the software on the average gateway. Most gateways (not the TTN one) are Linux based and from a network point of view have all the security issues associated with a Linux system. Some have a secured Linux implementation, some haven’t (home build ones based on a Raspberry Pi that are not resin.io based might not be secure as none of the popular setup guides mentions securing the gateway.)
The TTN gateway uses a dedicated software build that only runs a packet forwarder, NTP, DHCP client and wireless access point (no operating system). The wireless access point runs when the gateway is not connected to a WLAN which is the case when the gateway is using wired LAN (and in case of software issues). When the access point is running anyone within range can connect to it and attempt to hack the gateway.
The gateway also automatically downloads and installs software from TTN when available, another possible attack vector. (Build an malicious image, reroute DNS and 24 hours later a gateway is compromised)
When it comes to the packet forwarder being hackable thru LoRaWAN, that is very unlikely. The payload data received by the Semtech chipset and some meta data are combined in an IP packet and forwarded to the back-end. The payload data is not processed by the packet forwarder in any way (it can’t process the payload because the encryption keys for the payload are unknown at gateway level). For the reverse path, an IP packet is unwrapped and the data is transmitted at the time and frequency specified in the meta data of that packet (data is encrypted as well so gateway can’t modify/process it)
I’m using a perimeter firewall for my office network with a few systems in a DMZ (mail and web servers), my LoRaWAN gateways (yes multiple) are connected to the internal network. No one will be able to access them from the outside as the firewall will stop that traffic. The risk is someone running software within the network, for instance a malicious website you open on your desktop/laptop that scans the network and compromises any device it is able to possibly including the gateway. I accept that risk at the moment. To mitigate the risk you can connect the gateway (and any other IoT device) to a separate segment, not the DMZ segment as in most cases that will have some system accepting traffic from the open internet (like a mail server or in domestic environment a game server) which is by definition vulnerable.
I don’t have a TTN gateway but I do have a couple of Linux based gateways, one being Raspberry Pi based.
I run them on isolated vlans, firewalls setup to only allow outbound connections, any default passwords changed to randomly generated ones. Firewalls set to allow ssh in from only a preset list of IP addresses (for both ipv4 and ipv6).
Also for Raspberry Pi based, I always make sure to use a minimal linux installation and install only the software I need to do it’s job.
I think the risk is fairly low and not really much different to running any device with embedded linux. As others have said, an attack vector over LoraWAN seems unlikely although it’s perfectly possible that someone could discover flaws in the protocol or in specific implementations that could lead to being able to compromise or simply crash gateways. The risks here are bad implementation of LoraWAN and failure to stick to best practices such as using OTAA.
Plugging a LoRaWAN gateway in is probably less risky than plugging an IP camera in, following a few rules on security best practises are all that’s needed. A mistake I see over & over (and I don’t mean by people on this thread but the less technical, wider public) not understanding that such devices need the same thought with regards to security as a desktop PC does.
