Over the years, the blog has featured a few articles on running Internet-facing services on RISC OS, from web servers (WebJames and HTTPServ) to VNC and Samba shares. While those articles did go a little into the security of running those services on RISC OS in this day and age, they didn’t cover what you can expect if you open up your WebJames or Samba instance to the wider Internet.
While browsing the ROOL forums I came across a discussion about how secure it really is to run servers on RISC OS in this day and age – considering how old the majority of server applications are for RISC OS, and how creaky some parts of RISC OS’ networking stack are. That got me thinking, how secure really is it to run services that you care about on RISC OS, or maybe a service that you don’t particularly care about (e.g. a Samba share you never use) but it’s running on a system that you do want to protect.
So to understand what kind of threats there are out there today and how relevant it is to RISC OS, it’ll be first worth going over what the threat landscape is today for Internet-facing servers in general and how sophisticated (or not) threat actors are with their attempts to steal or break your cyber-stuffs.
So unsurprisingly the vast majority of attacks against servers on the Internet are attempts to guess their password, and a huge quantity of those are not very sophisticated at all. This is mainly down to it being so easy to get into systems on the Internet with incredibly weak passwords (if they even have one). Password cracking tools such as Hydra and John the Ripper do allow for complicated ways of getting at people’s passwords other than just going through a list of widely used passwords, but realistically, attackers just don’t need to go to that level of effort.
The Mirai malware, which enslaves Linux systems all over the world, took down a large portion of the world’s most popular websites for a while in 2016 through an enormous Denial of Service attack on DynDNS – a DNS provider that supports services such as Netflix, Twitter and GitHub – in turn taking those websites down. Mirai achieved this through scanning the entire Internet (it’s quicker and easier than you think) and attempting to login to the Telnet service at each IP address armed with a small set (about 20 or so) of default usernames and passwords that are known to be distributed with popular Internet-connected appliances such as CCTV cameras and Network Attached Storage (NAS) drives – ‘admin’ and ‘password123’ type stuff for the most part. After logging into these systems via Telnet, the malware would then get the infected machines to launch Denial of Service attacks at a target all at once.
To give you an idea of the kind of password login attempts an average server might see on the Internet. A server I administer received just under 18,000 login attempts via the SSH protocol in September, which boils down to about 235 unique IP addresses attempting on average 76 login attempts. This in itself shows that attackers generally aren’t trying every possible password connection to break into your system, instead their plowing through a list of common usernames and passwords. Below is an excerpt of the SSH access logs so you get an idea of the kind of behaviour to expect in a password attack.
Nov 20 15:09:48 Plankton sshd: Failed login for invalid user admin from 194.61.XX.XX port 55962 Nov 20 15:43:54 Plankton sshd: Failed login for invalid user service from 194.61.XX.XX port 55962 Nov 20 17:33:11 Plankton sshd: Failed login for invalid user monitor from 194.61.XX.XX port 55969 Nov 20 18:10:33 Plankton sshd: Failed login for invalid user guest from 194.61.XX.XX port 50669 Nov 20 18:49:03 Plankton sshd: Failed login for invalid user support from 194.61.XX.XX port 50669 Nov 20 19:25:06 Plankton sshd: Failed login for invalid user test from 194.61.XX.XX port 50711 Nov 20 20:01:25 Plankton sshd: Failed login for invalid user debian from 194.61.XX.XX port 50712 Nov 20 20:39:15 Plankton sshd: Failed login for invalid user service from 194.61.XX.XX port 50712 Nov 20 21:16:33 Plankton sshd: Failed login for invalid user ubuntu from 194.61.XX.XX port 57006 Nov 20 21:54:46 Plankton sshd: Failed login for invalid user user from 194.61.XX.XX port 57006 Nov 20 22:34:53 Plankton sshd: Failed login for invalid user ubnt from 194.61.XX.XX port 57006 Nov 20 23:16:28 Plankton sshd: Failed login for invalid user pi from 194.61.XX.XX port 63389
So with all that in context. If you want to password-protect content on your RISC OS web server, Samba or VNC server – just set a reasonably secure password and don’t reuse that password elsewhere. This website lets you see roughly how long it might take for someone to brute-force crack your password, once you get to 8 characters or longer, a password containing a mix of uppercase and lowercase letters as well as numbers and special characters is pretty tricky to crack – most attackers would move on.
That said however, if someone with enough knowledge and determination is for some reason targeting you specifically, then you might want to stop using passwords to authenticate altogether. As far as I’m aware, this will mean you’ll need to use a non-RISC OS solution for Samba, VNC etc. as I’ve not come across a RISC OS application that supports key-based authentication yet.
If your server is going to be handling any data you don’t want others getting their grubby mitts on, for example your family photos or maybe a website visitor’s form submission, then you’ll want to be using a server solution that utilises encryption when receiving and sending data. Intercepting data being passed across the Internet using a protocol that doesn’t use encryption, for example HTTP, is trivial with the right tools.
Unfortunately for us, there are no VNC, Samba or Web server programs for RISC OS that support encryption – this includes HTTPserv and WebJames, which are HTTP only web servers.
That said, if you want to run a web server that only serves free software you’ve written to its visitors, or just some information that you don’t mind anyone seeing, then hosting it on RISC OS isn’t a terrible option.
An example of this would be my Raspbery Pi at home, it runs a WebJames instance that consists of one webpage that links to other services on my local network (my file server, media server etc.), so if someone was to sniff that connection, all they’d be able to see is links to other services, but there’s no real data being passed across.
Denial of Service
Denial of Service (DoS) attacks were making the news quite a lot a few years back but they’re still a popular method of attack today, especially for people with very limited computer skills looking to create some damage. A notable attack from the last few years was the time Sony’s Playstation Network went belly up on Christmas Day due to their servers being flooded by enormous amount of bogus traffic in order to ensure that no genuine users could log onto the online gaming network.
Coupled with RISC OS server applications being more susceptible to DoS attacks than most modern servers, the threat of huge amounts of data flooding your server to stop you or others from gaining access for a little while is a real possibility. Although it does raise the question of why, unless there’s a particular reason why someone would want to take your server down for a period of time then this isn’t something I’d be too worried about.
Vulnerability exploitation is a very real threat to all web-facing servers around the world. New flaws that can be exploited into remotely exposing private data or allowing attackers to take access of the system in questions are occurring all the time. These are generally fixed by software vendors in the form of software updates once they’ve been made aware of a particular vulnerability.
There are some quite old and easy-to-exploit vulnerabilities that will be lurking in Samba and probably VNC server applications for RISC OS right now due to the age of the software or protocol versions they’re based on.
In the case of Samba, the latest version for RISC OS is 2.0.2-19990209, versions of Samba 3.6.3 and lower suffer serious security issues but given that RISC OS is an entirely different beast to the Unix/Linux and Windows systems that these exploits are designed for, I find it very unlikely that Samba on RISC OS will be exploitable unless someone goes to the extent of researching then coding a RISC OS specific exploit – incredibly unlikely unless you’ve seriously pissed off a nation state or something.
To sum up
So in the grand scheme of things, if you want to run a server from a RISC OS system and you don’t have any data that could be damaging to you or others should it fall into the wrongs hands, then there’s not really any huge red flags in your way. The possibility of someone exploiting the server software to get into your computer is incredibly small, and providing you don’t cheese off a load of teenage online gamers, then you’re probably not going to fall victim to a DoS attack either.