Given the choice I’d rather connect by cable and turn off any WiFi connectivity, if this were an option. You are clearly more au fait with networking I.T. than I am, I was hoping just to plug it in an focus on getting end nodes working.
1 Like
and you can … I see maybe 20 wifi ssid’s… secured… no problem.
if you want a TTN router you can cable connect it and wait for the update where you can switch off wifi completely, or you buy another gateway.
but to me imho there’s no problem at all at this moment … I have to see the first POC to misuse the TTN gw over wifi
2 Likes
Wi-Fi security is continually evolving, just because something ‘claims’ secure doesn’t mean it is truly so :-
…what was once considered secure is no longer so and also in any given system implementation there may be weaknesses or poor implementations. As you know we now rarely uses WEP, WPA has moved on, WPA-2 saw issues late last year and early this and many router and even GW manufacturers have issued new firmware to address some of the issues(*). Given the problems TTP (and its subbies) have had getting LoRa subsystem or even full GW to function 100% reliably are you confident there are no Wi-Fi related issues?! 
As you will also know the new WPA3 spec has just been released to continue to evolve security…hence my suggestion that Wi-Fi likely a large potential attack vector…basic premise for anyone concerned with network security is if you don’t need a n/w interface turn it off/disable if in doubt…only with the TTN GW you cant…or can you?
(*) e.g. Laird issued this update in December to address WPA-2 KRACK vulnerability:-
1 Like
are you confident that every device on your LAN is 100 % secure ? now and in the future ?
1 Like
I’d also say what I’d call the “windows” effect applies.
For computers you don’t see as many viruses, malware and such for OSX & Linux systems because the majority of people don’t use them. And that’s why windows is the most commonly affected.
I don’t know many hackers that will try and target LoRa gateways to get into your network compared to Smart TVs, TV Boxes, Phones, Smart hubs & speakers, Printers and more. As you’re in the UK I’d say its more likely that there’s going to be a issue with your Router Modem Combo being more of a vulnerability than a LoRa gateway.
So lets be real… how would you attack a system like this ?
I bet my money on the ‘auto update’ firmware as weakest point … but even that would not be easy
2 Likes
I think the question would be what are we also hacking for? To get access to the owners personal network for files or to get the gateway under their control?
1 Like
In the 3 years my gateway has been up, firstly as a private LoRaWAN network then as part of TTN I’ve not seen any issues. It doesnt use wifi so unless you are part of the TTN community you wont even know it is there.
1 Like
The real question isn’t really if somebody can take over a gateway or not, but if the gateway can be used as an attack vector into the office network…
Easiest is to isolate the gateway in a separate network, that way whatever happens won’t affect your business.
Network isolation can easily be achieved with a somewhat decent router, or even with Steve Gibson’s “3 dumb routers”…
(I do agree that the gateway is a a very low risk device compared to other appliances, but if it is about a corporate network, better be safe than sorry)
1 Like
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 
2 Likes
Some useful thoughts, thanks. I’ll be at a meeting of the TTN Norfolk (UK) group on Monday and will mention this discussion.
1 Like
@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”.
1 Like
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.
1 Like
DMZ
1 Like
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.
1 Like
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?
1 Like
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.
1 Like
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
1 Like
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.
1 Like
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 
1 Like