Blog
We believe in securely connecting everything by enabling users to build private networks within the internet that only they can see. We provide zero trust IT/OT networking as a service.
Language
English
NASA discovered in April that an unauthorized and unsecured Raspberry Pi attached to its network had been hacked and 500MB of data had been stolen. Raspberry Pi are great platforms for rapidly developing connected devices and tools, and the security concerns for such devices are mounting as they gain popularity in global markets.. Developers and network administrators must ask themselves, how much risk comes with a connected device or service on my network, and what can I do about it?
Think about this: devices connected to the public internet are likely to be detected in an hour or less according to the The Internet Storm Center. Twenty years ago, a single device on the internet could depend on security by obscurity as one small speck in the 3.7 billion address space of the internet. Today, tools such as ZMAP can scan the entire IPv4 address space in about an hour. ZMAP is a tool used by academics and cybersecurity researchers, but many similar tools exist for legitimate and less legitimate applications.
Security by obscurity is obsolete.
Knowing that a connected device will be detected by 3rd parties within an hour of connecting it to the network should concern the security minded and prompt questions like “when my device is detected by intruders, how ready am I to fend off hackers?”
This is why companies started to ship Raspberry Pi and its variants with SSH disabled by default. Disabling SSH by default is a simple and effective solution when any hacker detecting a Raspberry Pi could apply the default username and password to get into the system. Disabling SSH completely closes that attack vector for hackers… until someone needs to use SSH and turns it on. Will they change the default password? Will they pick a password that is difficult and time consuming for an automated attack to crack?
The answer is for developers to set up their connected devices in the most secure state by default, and then systematically open up security in a way that maintains security while letting authorized users access the devices. High velocity, automated hacking is the norm, so developers working with connected devices and services should make security their norm. As a user, best practices are to take the approach of setting up your connected device in the most locked down state, and then deliberately and systematically opening up network functions following a secure protocol.
This is a good starting point for basic security on connected devices and services. Developers don’t specialize in security, but by following this checklist, they can avoid some of the easy-to-avoid vulnerabilities common to setting up connected devices and services.
And never, ever use the default password.
A lot of security vulnerabilities occur because of negligence or laziness. Maybe you didn’t realize your device had many network services on, and you never checked. Maybe you were in a rush to use SSH so you never changed the default password.
remote.it provides an alternate way to communicate remotely with connected devices. When a device is enabled with remote.it, it can assume a “drop stance” that makes it unresponsive to the pervasive probing of the internet while maintaining the ability to communicate with other remote.it enabled devices. The device effectively become invisible to internet snooping, and therefore has no attack surface to assault. Devices with remote.it can communicate with other devices over the internet by using remote.it like it was “DNS as a service” to route protected communications over TCP/IP between remote.it devices. Developers can also connect remote.it devices directly in a peer-to-peer fashion.
To learn more about how remote.it can secure your connected devices and services, creating a Virtual Private Internet for your devices, sign up for a free developer’s account here.
