I would guess most likely as an entry point to the network - most likely via a GW rather than a simple low compute power/low data connection sensor node - so you can then look for ‘easier’ to hack/control devices for e.g. botnet building.
Sadly IoT security is increasingly seen as an issue and we have already had examples of large botnet & DDoS attacks & ransom/extortion efforts as a result (esp using laxly managed or configured ‘consumer’ IoT devices - IP CCTV cameras, ‘smart’ TV’s etc)…IMHO we need to be mindful from the start (not least as once deployed ‘fixing’ issues could be a real PITA Most of the devices and data collected on a LoRa network, under TTN are a ‘dont care’ wrt other people seeing the data but then there is always the exception and so you need to protect for all.
We also have a responsibility to the rest of the TTN and wider LoRaWAN using communities as it will only take one or two bad headlines around the world about ‘TTN used to launch major bank/credit card take down in DDoS attack’, or ‘TTN used to phish personal details from 85 year old grannies and steal their life saving’! or some such to cause people to question and loose faith in the technology making our deployment efforts harder…
‘Professional/corporate’ devices struggle with security at times, and I would suspect that amateur/hacker-space/community built devices will likely vary even more wildly in care/security of builds (not a criticism folks just a fact of life wrt varied skill sets and available tools/resources for testing!), and I know many are using linux and there is often assumption of Linux or MAC more secure than WIndoz but you only have to look at recent Gentoo Linux snafu wrt Github to see how easy compromises may slip through…as for myself I assume none of my kit is 100% secure and simply try to mitigate within reason without paranoia
@Alexmouse: Applause for thinking about security from the outset.
I’m with @Jeff-UK on this one - always choose the most secure option from the start. As a minimum I would place the GW on your router’s DMZ. To “disable” WiFi I would guess you can simply enter erroneous information?
Just because we can’t see why someone would want to hack a GW doesn’t mean it won’t be hacked - we’re not talking about individuals doing manual hacking anymore, there are automated systems constantly looking for vulnerable devices, so it’s not a case of “if” but “when”.
Usually isn’t the DMZ Feature where it essentially opens up all ports to the device? Of which that’ would make it a greater security risk than being behind the built in firewalls and such.
I’m guessing you mean isolation? Of which I’m not sure how many commercial routers support this. While some things call this DMZ most routers still allow the device to access other devices on the network.
However an idea is, if actually using the wi-fi you could create a guest network of which most UK ISP’s hubs support and that would provide as good isolation.
So indeed, it would actually open the gateway up to more risks as the gateway itself doesn’t run a firewall.
Obviously it also depends on what the “router” is most people use. In the UK we’re pretty much forced to use the one the ISP Supplies and in a best case then connect a third party one to it.
However it does look like using a guest wi-fi network could be an option. You have the wireless security factor then however most of the routers that come with ISPs isolate these better than “DMZ” which just opens all traffic up.
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.
Most of the devices and data collected on a LoRa network, under TTN are a ‘dont care’ wrt other people seeing the data but then there is always the exception and so you need to protect for all.
