Okay lets try an experimental new thing, a different kind of post with a new aim. I recently embarked upon an interesting endeavour, looking at new ideas as a means to secure a server. Having recently begun using Kali Linux for it's penetration testing tools I decided I could use a machine for building custom tools on.

Initially I figured, I'll just run up a VM using VirtualBox and play with it in there. The process started off easy enough and before I knew it I was installing my distro, everything seemed fine, however I hadn't counted on how much Windows is a resource hog these days. It turned out I was so short on resources setting up the partitions for the disk took 1 and a half days! When it promptly crashed during the next phase it became blindingly obvious I was going to need a better solution.

As it happens I had a Raspberry Pi sitting spare, handy little boxes these that can run all manner of services. I had done a lot of this sort of thing before about 5-7 years back when trying to work my way back into the world of computers, so armed with this experience I figured I know these can run what I need lets set one up. So I set about looking up the install process and I suddenly had a bright idea, I had hear down the grapevine about how insecure Kali can be and thought to myself maybe I'd be better with Arch I've been wanting to look into that anyway.

So I began setting up Arch Linux ARM, it's relatively easy to get set up with the basics following the guides (assuming you know the model you have, I didn't but I soon sussed it out as a 3B) so sorting the SD card was a doddle. The next thing was installing sudo, well I was aware of this already having had a bit of a play with it previously, only then I was horrified to see the suggested sudo set up. Most of the Raspberry Pi based guides suggested building in a sudo override for a no password sudo, now I completely understand this is easier for children so that is how Pi generally do things, but to anyone who has ever administrated a Linux server it is the most horrible of priviledge hacks, the reason it is called an override is because it overrides the security. If by chance you with to do this properly you should use visudo to edit the sudoers file (I tend to override vim with nano as I prefer it, Arch has a nice guide on that), ensure that the group you wish to provide sudo access is listed as ALL=(ALL:ALL) ALL and then add them to the right group. You can look up the manual to see what each means and I recommend you do if you want to properly secure servers, also sudo -i is far more secure than sudo su due to the way it works but achieves the same results (kinda, look it up to see the differences).

Here I began to tread into less common waters and began immediately hitting brick wall, so with a fight I got what seemed to be a working network configuration and stuck it on it's intended port, this didn't work but the reasons why got figured out much later. I decided I should probably try to integrate with the GUI since I wanted one and use that method to set up the network, this in hidsight was a huge mistake. I had successfully managed this only once before and badly using a guide, I had a vague idea what goes into making a GUI but vastly underestimated the complexity of it. Ultimately I spent a good deal of time fighting with it and eventually lost patience, reverting back to Kali.

By this point I Arch had taught me a few things, and I had a bunch of bright spark ideas, I had decied that a good way to secure a server is to have a read-only filesystem. Now I had encountered these on Pis as a means of preserving data in the disk, but here the intent is if an intruder successfully breaks into a lower level account there should be no logs to speak of and they can't alter any files without knowing how to make it read write, theoretically a simple reboot would flush any malicious philandering. I had gotten the idea from the instances you often see in cloud environments, well, this turned out to be a royal nightmare. I followed some instructions I was able to find on how to do this on raspbian but it soon became obvious it wasn't close enough and was designed for a far more basic system than I was using when it wouldn't boot. It did teach me some neat tricks about temporary filesystems and suppressing logs though.

So at this point as you might imagine I was quite despondent, especially with another project I was working on not going at all to plan, I had to go away and think about it all for a while. When I came back though, I was onto something, I discovered a way to achieve a similar result. I could use a jail or chroot to essentially lock the vulnerable user inside their home folder, a wise tactic if you with to prevent them causing damage outside of it. I could then additionally set up home as a temporary filesystem, I have no need for it to be persistent, so every reboot it simply wipes anything the users might have left in there as a safeguard. The final trick is one I owed to my scripting, as during the previous attempt I had intended to add a script that rebooted upon logout, however the script didn't recognise the command, a far simpler method is simply touch the reboot-required file upon logout and have a cron job occassionally check for it and reboot if so, voila.

There are a great many other security measures I take on my devices, but I felt this story was interesting enough to share, for the pitfalls to be avoided, and the lessons that can be learned from it.