It’s been a while since we updated this site. The prime reason as that the underlying company that sponsered this site no longer exists, but we have secured permission to run this site anyway now (and with the original name), as a means of trying to inform of real-world amatuer server operation and maintenance. Importantly, all of the old articles that were originally posted on this site have now been restored. This site is now being operated by Andrew Wilson only (me!), with no additional ‘IT’ support, so everything on here now represents my work/ideas etc.

Hopefully some of this proves to be useful to someone out there. More to come. 🙂

Updated WordPress – Good or Bad?

So lots of chatter on Twitter about the new WordPress, and especially the new editor.  With a lot more negative comments than positive.  So here’s to our new Editor – this is just a simple post to see if it works.  And if it doesn’t, we might not worry too much as we have recovered from a major (near city-wide) power outage that even killed off our servers.  Yet we stayed online, because we had a plan.

Look for our story on the power failure which includes some major take-away lessons for us, in an article to be posted soon.  Short version: it is worth planning for events like that.  We did, but it didn’t go perfectly.  Hopefully the next such excursion will go even better for us.

Dumb Admin LXC-Fan VPN “Tip”

So, if you are wondering why you can’t remotely decrypt your server after a reboot, you might check your VPN…

Ours was running in an LXC container…on the very computer we were trying to reboot. SO of course, the container WAS NOT RUNNING. After some panic when SSH did not respond, we found that ALL web services did not respond.  We actually really liked that!   It was only then that we figured out or dumb mistake…

“Pro Tip” – Disconnect the non-functioning VPN before you SSH to the encrypted server.   It’s a lot less stressful than trying to do it the other way round.  😐


So we have been asked for more information about our Information System by small-business owners who are also coming to grips with ITAR, NIST-800-171 etc., and the need for a USABLE AND USEFUL ‘IT’ infrastructure.

Our methods might not suit all: our system is especially developed to suit a remote-access and remote-maintenance capability, as we are spending a LOT of time way from the corporate office (where we locate our servers), but in case it helps, here’s a snapshot of what we do, in a rather summary form (with hyperkinks added to most of the referenced software, so you can drill down in any item of interest):

Hardware: we use LAPTOPS to host our primary Linux servers.  They are extremely capable for our small business needs AND they come with built-in battery back-up for the odd power-cut or so.

Software: we run ALL of our services in LXD containers, hosted on a single hardware server that runs Linux Ubuntu 16.04 as the host service.  We make minimal changes to the real server; we deploy as much as we can via LXD (since it’s containers are, in our case, unprivileged and thus safe and secure de-facto).

We secure all of our hardware with Linux LUKS full disk encryption, which we can remotely reboot AND unlock via Dropbear SSH.  #PrettyCool

ALL of our SSH (most of which are via OpenSSH, except for the DropBear disk decryption process after reboot) connections require public/private keys.  Our port numbers are…unusual (we don’t exist at port 22, and we don’t make that search easy, but feel free to verify that).  #SSH-somewhat-Hardened

We employ 2FA for all of our server SSH logins.  That actually means we have TRIPLE factor authentication since our private SSH key needs a password too. #WayBetterThan-US-State-Department

We have THREE servers that mirror capabilities (so that as and when one dies, we can still be online.  It works too, having tried it once already for real – yikes).  It’s not as good as what a large corporation will do, but it’s better than nothing.  #LiveBackupsAreEssential

Our LXD containers are all running on LUKS encrypted zfs drives. #VeryCool


We have already mentioned Ubuntu 16.04 server and LXD, but it’s so good it’s worth a re-mention.  🙂

We run Nextcloud server (latest version, or maybe latest-1 -we don’t enjoy being the first to field the latest version of this mission-critical software).  This is the HEART of our Operations, as ALL of our CUI/ITAR documents are managed via the totally brilliant Nextcloud.  All logins are via 2FA second-factor credentials.  We also employ server-side encryption of Nextcloud; and…

We extensively use Cryptomator to provide END TO END encryption of ALL CUI/ITAR and other mission-critical data.

We use sftp via our strong SSH to access server files.  This is via a Nautilus/Cryptomator (Linux) or Mountain Duck (Windows) interface.

We run an OnlyOffice server so we can remotely create/edit CUI (Word, Excel and PowerPoint formats) even when overseas.  The free Desktop Apps are also used by us as part of our journey to move away from the expensive and metadata-mining Microsoft Office365 products (the only software subscription we have).  Regrettably, DoD uses Microsoft so it’s hard to completely eliminate the Office365 products from our toolbox.  One day, maybe…

We use WordPress for our web-site services (including for THIS POST).

We use haproxy as our front-end server just behind the router.  Fast, reliable.

We run our own OpenVPN server and use it whenever we are in an un-trusted location.  We don’t use this to hide our identity/location (like many privacy-minded people, and even some bad-guys do).  Rather, we use it to prevent man-in-the-middle threats to our online data when at hotels etc. that meet our high-risk profile.  It’s unwise to trust a free wifi hotspot.  And even many paid-for services should be viewed with suspicion.  That said, our connectivity to our servers is always via  HTTPS via LetsEncrypt certificates, so the VPN server is arguably an overkill at times.

We use ‘andOTP‘ to manage our multiple 2FA credentials.  This is better than the standard Google Authentication app.

We use android devices.  We employ full disk encryption on our android devices.

We still use Microsoft Office 365 for our email.  We constantly agonise over that, and maybe one day we will run our own mail server.  But not today.  We don’t use the Outlook app – we only access email via the web portal.  We think it sucks, but email is so hard for small businesses: customers servers will likely reject self-hosted server emails as an anti-spam measure, so you may never know if some emails make it or not.  We can’t operate with that risk.  We think it’s important to have a reliable email service.  Office 365 does that job nicely, as much as we hate to admit it…  🙂

We believe we are COMPLIANT with all the regulations that impact our primary business.

Overall, we are quite pleased at how well our integrated systems WORK TOGETHER. It’s proven to be reliable, usable and satisfactory for our business needs.  How do you run YOUR small business IT?

Questions or comments as usual via email to: [email protected]

Or you can message us on LinkedIn or Twitter, which is probably faster (but not private).


Securely Sharing Files from Nextcloud

So we’ve been asked ‘How do you share files from Nextcloud securely’?

It’s a fair question because if you END-TO-END encrypt a file, you can’t actually share the file unless you also share a means of decrypting it.  And we don’t share our end-to-end encryption keys, EVER.

So how do we manage sharing?  How do we protect our files as we hand them over to our customers?  The short answer is with LAYERS of security:

Our files are protected by one of several levels of independent security:

Robust SSL/TLS connectivity (HTTPS all digital coms)

End-to-end encryption for files

Server-side encryption for files

Full Disk Encryption (FDE) for computer drives (server or desktop)

We can ignore FDE here as it doesn’t really come into play (it’s only really applicable here to a stolen PC).

For normal at-rest files, we have end-to-end AND server-side encryption in play.  So our files are protected against threats of all kinds.  You just can’t get at our data without TWO separate sets of credentials, neither of which are connected, neither of which are stored in a file.

When we share a file, we have to remove one of these layers (the end-to-end encryption), and that of course makes the protection weaker during the process of sharing FOR THAT FILE, since it only has server-side encryption to keep it safe.  Note that this is not “bad” – the file is still encrypted, and it’s safe from even quite determined hackers.  But you know, we like to be a bit paranoid and very responsible, so we bring other measures in play.

Firstly, here’s a real file from our server we created with end-to-end encryption still applied:

It’s very exciting.  #notReally.  You can see, the name is complete gibberish.  And for the record, if you download this ‘blob’ and view it in Notepad, this is what you get:

91Ïií=¡l‰­¸üN#åS›¬Æàçý*¨”PÔãºÕë*,8ƒÇŠûìÒ†Áè‹™p\ \©Jšs|Ö_ž›”ÒÿEÊ ÈÈõÁÁ”

And as you will see later, the real file is actually a simple text message.

Once the file has end-to-end encryption removed, we can now more easily find it on the server AS THE SYS-ADMIN (or as a hacker that has somehow penetrated our system).  It takes a while, but you can find it:

Wow, there it is.  Plain as day.  This file is actually present in an lxc container.  If you can ‘see’ this, you are ither a SysAdmin or an unauthorized hacker.  But the good news, you are not at the system root (you just think you are), so your damage potential is still very limited.

The file we created especially for this demo is shown among other directories.  The server ADMIN or hacker (not necessarily the owner of the file) can “see” the file, so it seems.  But before everyone panics, let’s take a close look at what he or she can actually “see”.  There’s a file name and permissions and modification time and apparent size (meta-data if you will).  You can also see file/folder names too.  Gosh, does that mean the SYS-ADMIN or hacker can snoop on my files?  Let’s look at the contents using cat:

Well that doesn’t look terribly useful.  As you can see, the DATA are still encrypted.  Albeit this time via the SERVER keys.  A hacker and even the SysAdmin can’t look at file contents (but it’s true, he or she can see the name and other file meta data).  So, the file is still quite well protected against hacking and theft.

In fact, the ONLY way you can view these data is if you unlock the server-side encryption that’s now in effect for that file.  And for this, you either need an exploit that works against Nextcloud’s encryption (very unlikely) OR you need to somehow secure the credentials needed to login to the Nextcloud account which will then unlock these files.  For that, you need a Nextcloud password AND 2FA code (one that changes every 30 seconds), so that too we think is quite safe from unauthorized disclosure.  But when you do enter those data, the file becomes fully decrypted and is then more visible, albeit over an HTTPS connection only (our final level of protection):

So “finally”, this is a file we can read:  HelloWorld.txt, that says “Hello everyone.  Have a nice day”.  So the Nextcloud user can read the file (just as he/she should).

When it comes to SHARING this file, we actually share an HTTPS:// link for that file that includes the decryption credentials for that file.  In Nextcloud, this is what that looks like:

You can see on the bottom right that a sharing link has been created.  We also add a PASSWORD to that link and an EXPIRATION DATE for the link, so that the link will not be active for long AND you need the extra password to access the file.  We send the LINK to the file via regular email.  Regular email is not terribly safe.  It can be intercepted.  We know that.  But let’s continue:

This link looks like this:

(The link won’t exist for long, so it’s probably not worth trying, sorry!).

If you click on the link and it’s still active, it will bring up THIS page:

Which is still not the file.  You need that password.  We do not send the password with the link.  We don’t even send the password via email.  We send that via another means, say WhatsApp, or Signal or even SMS.  So, to get to this file, you need the link (from an email sent to you) AND the password (sent in a different way) sent to you.  Finally, if you get the link and the password, you can click/enter the top secret password assigned to protect this file, you get rewarded in this case with this:

The file.  In decrypted form.  Finally!  You can download the file but ONLY via https:// (SSL/TLS) connection (our final layer), so even then it remains encrypted-in-transit until it hits your download folder.  Only then do we relinquish our management –> OVER TO YOU!  🙂

So that’s how we share our data.  it is ALWAYS protected with up to four layers of encryption: FDE, End-to-End, Server-side and lastly SSL/TLS.

These “layers” are gradually stripped off as we get closer and closer to sharing a file with you, but only when it lands on your machine is our last (but strong) layer of encryption removed.  We use 2FA credentials to share our data and even the Sys-Admin (or unauthorized hacker) has very little access to our data: they NEVER see raw decrypted data, but occasionally they can sometimes view a file name and some basic meta-data.

Is this perfect?  No.  We are always looking to improve it.  This system is our latest and greatest implementation, but it won’t be our last.  Is this pretty good?  We think so!  What do you think?

So this is how we ROLL our file-sharing; how we securely share data with our customer.  What do you do?

Comments by email only – [email protected] or you can catch us on Twitter @SysAdminEI

Meeting Compliance with the aid of Nextcloud, Cryptomator and Mountain Duck

So like all SysAdmins, we have a lot to worry about in order to continually meet the burdens of compliance.  For us, data residency (location) and digital “state” (encryption status) is very important.

We have had a productive few days improving the PERFORMANCE of our systems by using better-integrated software.  So, why is PERFORMANCE being addressed under compliance?  Well, simply, because if you make a compliant system easier to use, users are more likely to use them, and thus be more compliant.

It’s no secret, we are great fans of Nextcloud – we self-host our cloud server, and because we use that to host our data, we use several different security layers to help thwart accidental and malicious exposure.  Our cloud server, based at our office HQ in Tennessee, is where we store all of our important data.  So we try to make it secure.

Firstly, our cloud server can only be accessed by HTTPS (SSL/TLS).  Logging in requires 2FA credentials:

This gets you to the next step:

So this is good.  And we have server-side encryption enabled in Nextcloud, which provides an additional layer of security – not even the SysAdmin can read the client data on the server.

This is cool.  Server-side encryption does help us with sharing of files to customers, but because the decryption key is stored on the server, we don’t like to rely solely on that for protecting our important data.

So our data are end-to-end encrypted with Cryptomator – an open source, AES encryption software package, with apps for Linux, Windows and Android (we use all three) – and even apps for IOS for those that like their Apples too (we don’t).

Of course, one of the things that makes this system “inconvenient” is that it’s hard to access end-to-end cloud-encrypted files quickly.  On the server, they look like THIS:

Not entirely useful.  Really hard to work on a file like this.  You have to  physically download your encrypted file(s) (say using the webdav sync software platform, like the great one provided by Nextcloud) and store them locally on your device, then decrypt them locally, on your device, so you can work on them.  This is fine when you are in your office, but what about when you are on the road (as we often are)?

Data residency and security issues can arise with this method of working when on travel, so you can’t download files en-mass to your device and decrypt them all when you are in the “wrong place”.  You have to wait until you can get back to a right location before you can work.  Customers don’t really like the delays this can cause them, and we don’t blame them.  And worse still, in that situation, even when you are done, you have to delete (or even ERASE) files on your PC if you are going back on travel etc. again to a location where data residency becomes an issue.  Then when you get to a secure location again, you have to repeat this entire process for working on your files again. This is hard to do.  Believe us, we know, as we have had to do this, but we now have a better way.

A more secure but LESS CONVENIENT way is to somehow only download the files you need as you need them, and decrypt and work on them etc.  ONLY AS YOU NEED THEM.   This is more secure, as you only have one decrypted file on your device (the one you are working on in your word processor etc), but how can that be done and be done CONVENIENTLY?

Obviously, this “convenience v security” issue is one we have spent a lot of time looking at.  We have used webdavs connected to our cloud servers and tried to selectively sync folder(s).  It’s not efficient, not pretty, not fast (actually really slow) and sometimes it just doesn’t work.

But thankfully we now have a much faster, reliable, efficient, effective yet totally compliant way of addressing the problem of keeping files end-to-end encrypted yet still be able to work on them ONE AT A TIME even when you are in a location that can otherwise bring data residency issues.

For us, this requires several systems that have to work together, but they are built (mostly) on Open Source software that has, in some cases, been tried and tested for many years so is probably as good as you can get today:

  • OpenSSH – for Secure Shell connectivity;
  • Nextcloud server;
  • Nextcloud sync clients;
  • Cryptomator;
  • 2FA Authentication credential management apps;
  • And last but not least…Mountain Duck.

SSH is an established, reliable secure service used globally to securely connect to servers.  If configured correctly, they are very reliable.  We believe ours are configured properly and hardened, not least because NONE of our SSH connections work with a username/password login.  Every connection requires a strong public/private key combination, and every key itself is further password protected; and, each SSH connection ALSO requires a second-factor (2FA) code.  We think that’s pretty good.  We have already explained Nextcloud and Cryptomator.  2FA apps are the apps that generate the six-digit code that changes on your phone every 30 seconds.  We have written about a new one we like (PIN protected), so we won’t go into that anymore.  That leaves ‘Mountain Duck’.  Yes ‘Mountain Duck‘.  We know, it’s not a name one naturally gives to a secure file-access system, but bear with us (and in any case, we didn’t name it!).  Put simply, Mountain duck allows us to use our 2FA protected SSH connections to our servers to access our files, but it does so in a really neat way:

In the image above, taken from their we site, note the text we circled in red.  Mountain Duck comes with CRYPTOMATOR integration.  So this effectively makes Mountain Duck a ‘Windows explorer’ that can be 2FA-connected via SSH to a server to access and decrypt in real-time Cryptomator end-to-end encrypted files stored on our HQ-based servers.  To that, we say:

Just WOW.

So how does this work in the real world; how do we use this?

Well we have a Nextcloud sync client that syncs each users files to a separate LXC container running on the corporate server.  Each container is used to sync the users files between the Nextcloud server and the Nextcloud user files.  Both the Nextcloud server AND the Nextcloud client files are ultimately stored in the HQ facilities, albeit in very different LXC containers.  Files are end-to-end encrypted in both the Nextcloud server and the Nextcloud client container.  All are further protected by full disk encryption and SSL/TLS connectivity.

Whether we are on the road OR in the office, we work on our files by logging into our Nextcloud client container using OpenSSH and Mountain Duck.

It’s all a lot simpler than it might sound:  First, we connect to our Nextcloud client containers via strong SSH credentials via Mountain Duck’s friendly interface, which asks first for our private key password:

And then asks for our 2FA code:

The 2FA code is generated on an our 2FA App on our encrypted, locked android smartphone, in a PIN protected app (We use ‘Protectimus‘ and also ‘andOTP‘).

With these credentials, Mountain Duck logs into our Nextcloud client container via the secure SSH connection, and then it accesses our end-to-end encrypted files but in doing so, it automatically detects our Cryptomator Vault (because it’s built into Mountain Duck) And it then allows us (if we want) to UNLOCK our Cryptomator Vault and access it:

So in one operation and three “codes”, we can securely connect to our Nextcloud client container via secure SSH and access our end-to-end encrypted files from anywhere in the world (where there’s internet!).

And Mountain Duck makes this easier because it allows you to bookmark the connection: open Mountain Duck and click a bookmark to the SSH server then enter your SSH password/2FA code.  Mountain Duck logs into your server and accesses the files located there.  It can even remember your passwords if you want (we don’t do that, as we don’t trust Windows much at all), but you could configure this to JUST require a 2FA code if you want.

The whole process takes, maybe, 30 seconds including the time to get the phone out and obtain a 2FA code.  Not bad!  And once you have done that, you can work on your END TO END encrypted files stored on your office based Nextcloud client container files from anywhere in the world.  No files are needed to be on your PC – in the office or on the road.  Everything remains solidly encrypted so if you do get hacked, there are no readable data that can be stolen, so at least that threat is low.  And everything is going through modern, secure OpenSSH transfer protocols, which in our case, makes us sleep a lot better than having some proprietary code with back-doors and all sorts of unpleasant surprises that always seem to arise.

The catch?  Well, you do need internet connectivity or you can do NOTHING on your data.  The risk in the office is low, but when your on the road it does happen, so it’s still not perfect. 🙂

Also, you do have to set this stuff up with some poor SysAdmin.  But if we can do it, probably anyone can?

Finally, this is what it looks like for real after we go through that hard-to-explain-but-easy-to-do login.  A window appears and you can see your files just like a normal file view on your Windows PC.

Above is a regular Windows Explorer window, accessing the Nextcloud client container files via fast and secure SSH.  The folder ‘Vault’ is actually a Cryptomator end-to-end encrypted folder, but because we have entered the credentials (above), it can be accessed like any other.  Files inside can be copied, edited, saved, shared, printed etc. just as files in the other folders.  It’s totally transparent, and it’s TOTALLY AWESOME.  The files in the Nextcloud client container (and the Nextcloud server) remain fully encrypted all the time.  A file ONLY gets decrypted when it’s selected and downloaded by the user.  Viewing a file in explorer (as in the view above) does NOT decrypt it – you have to double-click etc. the file to initiate downloading and decryption.  All your changes get immediately sync’d to the Nextcloud client container (which immediately sync’s everything back to the server).  Nothing gets stored on the PC you are using to work on your files unless you deliberately save it to the device.

So, THIS is how WE roll our own end-to-end encrypted data storage.  How do you do yours?

questions or comments by email only [email protected]


SSH Public-Private Keys

So in reviewing the var/log/auth.log etc. files today, I note a drastic (as in 100%!) reduction in unauthorized SSH login attempts at the EXPLOINSIGHTS servers.  Bloody brilliant!
This either means:

  • All the hackers have turned into good guys; OR
  • Russia and China are on holiday (prior month SSH hack attempts, of which there were many had IP addresses “from these nations”, which is hardly a smoking gun as IP’s can be spoofed, but it’s all I had to go on); OR
  • Using public-private SSH login keys AND two-factor login has done it’s job* – yay!

Two-factor login is enabled for the EI servers and the services thereon.  If you are not using two-factor then I say THANK YOU – it makes you a more attractive target, so hopefully the hackers will continue to leave me alone for a while.  🙂
Tip:  And on the subject of SSH two-factor login, it took me quite a while to figure out why I couldn’t log back into my servers AFTER the first reboot after I enabled two-factor.  All the tests via SSH worked before the reboot.  It drove me NUTS.  The reason was that my Ubuntu encrypted /home/user directory is NOT unlocked via SSH login, so the SSH tunnel could not read my keys at ~.ssh/authorized_keys thus I failed the first and biggest login hurdle.  Either disable /home/user folder encryption or move your encryption keys to another location (say /var/SSH).


*I actually also did something else beyond two-factor and pub-private keys, but I am not sharing that publicly.  Message me, and if I feel like trusting you (a real email address goes a long way…), I will let you know my third factor.  🙂

Self-Hosting – The Journey Begins

So this blog site is part of EXPLOINSIGHTS (EI) journey into a self-hosted IT infrastructure, caused by trying to navigate the seemingly conflicting information system requirements for complying with NIST-800-171 and ITAR.  Maintaining an effective office document information system that works with your business model is not as easy as a small business would like.  EI quickly concluded that achieving compliance is easier if you DON’T use the convenient services that we have all taken for granted.  For EI’s journey, this meant moving away from the admittedly excellent Microsoft Office 365 product.  But baby steps are needed, as Office 365 (and the Google Apps equivalent) is robust and capable.  It’s not easy trying to match that.  However, as of the date of this article, EI is now the owner-operator of a server that hosts:-

  • A cloud file system using Nextcloud;
    • Files shared with Customers are via a link to this secure site.  Two factor authentication is enabled for all users and file shares.  That’s already at least as good as Microsoft’s OneDrive service, but it’s self-hosted so data residency compliance at least is a non-issue.
  • A WordPress blog site;
    • If you’re reading this article, then the site works!  Let me know how your experience is please.  EI’s blog site is also self-hosted.
  • A web site.

The web site was in fact established first (, but there’s actually nothing but a placeholder on it today, as it’s really just being used as a portal to the other two self-hosted services.  That’s a work-in-progress.
The journey to get here started a long time ago, and it’s not been easy even though I used to consider myself to be reasonably tech-savvy (not anymore – Linux OS and command-line driven programs like Apache web-server have made me rethink how good my IT skills are).
This is still a beginning for EI.  This self-hosting journey has more to go.  Microsoft Office 365 is a low-cost small-office service that EI once used with confidence, but their privacy-mining practices are discomforting at best and more importantly, their data servers and thus your company and customer information are located in places we don’t really know or manage as well as we need to for maximum compliance .  The solutions to these privacy and data-residency etc. problems using proprietary software from cloud-based organizations like Microsoft and Google are difficult on the best of days.  So EI believes it has more to do in terms of self-hosting on company owned hardware.  On the list of potential projects includes:

  • Self-hosted email;
    • Several options exist.  “Open Source” is the only decision made so far.  Watch this space!
  • Self-hosted OnlyOffice file server –
    • An Open Source but otherwise very Microsoft-format-compatible office suite (spreadsheets, documents and presentations);
    • Desktop versions exist BUT sometimes you need to work on a secure web portal.  A self-hosted option exists!
  • Self-hosted Virtual Private Network (VPN).
    • Open Source of course – do you see the trend?

And this has to be done all the while trying to keep up with the latest bad-guy malware and security threats; and keeping effective backups that can mitigate anything the bad guys can throw at us.
A few tips from EI for anyone who ventures down the self-hosting path:
1. Reconsider your Operating System

  • Microsoft Windows is part of the problem for small businesses, not the solution.  Proprietary software makes things worse from a compliance perspective.
    • EI runs on Ubuntu 16.04.  Linux rules when it comes to self-hosting options.  Ubuntu does use some proprietary code, but most of it is based on Debian, which is…Open Source.

2. Use (Linux) Containers

  • Using non-privileged containers is the way to go with Linux.  Virtual Machine snapshots make backups a breeze AND they are so forgiving when you screw things up (just restore your prior snapshot).  More importantly, they add an enterprise-level of defense against hackers.  If one web-service is compromised, containers make it harder for them to spread, so damage can be minimized.  Oh, and take snapshots often!  EI runs on LXD containers, but you have other Virtual Machine options if you prefer something different.

3. End to end file-encryption is your inconvenient friend

  • Cloud file servers are so useful, but if you use one, use client-side encryption.  “Security is not convenient” (that phrase brazenly plagiarized from an EI customer) – but it is essential.  Client-side encryption with strong keys and passwords WILL save your data from being exposed.  It won’t stop you losing it, but it WILL stop it being used by someone else.

EI’s cloud files – encrypted BEFORE they hit the server

  • EI employs Linux Encfs (Open Source) and Boxcryptor (Proprietary) for client-side file encryption.  The next official release of Nextcloud has end-to-end encryption built in, so it might provide an even better option.

4. Check things THOROUGHLY before you go live

  • Use online services to check and validate your security before
  • you go live.  These two helped me a lot, and there are multiple free web-server security checking sites:

Hello world!

Welcome to EXPLOINSINGHTS Inc. Blog Site!
This is my first ever posting here, and the concept of a blog is itself an experiment.  The intention is to use this site to share things that EXPLOINSIGHTS Inc. cares about – both from a customer and stakeholder perspective:

  • Information and insights on the services provided by EI to the ammunition and energetic materials community; and
  • The challenges that EI as an organization has to overcome to survive and hopefully thrive in the industry we serve.