I have an Anvil app that is a front end for a database. I have the database and Anvil uplink hosted on a remote Ubuntu headless server. Just before Christmas the server was hacked, they deleted my database and left a ransom note in the database demanding some bitcoin for the return of my backups. It’s not a huge deal to me as I have local copies of the database, just more of an inconvenience and a learning opportunity. It’s hard to know how they got in, as they deleted all the logs up to the point of their hack, but I suspect it was a brute force attack, as looking at logs previously there were lots of those attempts daily. I had a Wazuh agent running on the server but the threat level wasn’t correctly configured, so I couldn’t glean any info from that either. I left the server up for about a week, with the Wazuh agent correctly configured hoping they would access again, but they haven’t from what I can see, so I have now killed the server and am configuring a new one. Naturally with the new one I am adding some further security layers one being a Wireguard VPN.
I’m not an IT professional and am unfamiliar with VPN’s and particularly any considerations I should consider with regard the Anvil connection.
I have had a search through the forums here, but there isn’t a lot of info in this regard.
Does anyone have any suggestions about anything I should consider before proceeding?
I’m not an IT guy, but have basic questions about your configuration:
What database system was hacked? Were you running Anvil on anvil.works hosted servers or using anvil-app-server with Postgres on the Ubuntu server (as the system database for your Anvil app), or was that DB only used for separate data storage by the app?
More information about common attack vectors would be helpful, for example how was SSH configured on your Ubuntu server? SSH should be limited to only whitelisted IP addresses (and on a non-standard port). If intruders achieve SSH access, virtually all other security can be foiled…
More info about your uplink configuration and functions would be helpful.
Are you encrypting any columns of the database? You said this is more of a learning opportunity - if critical columns containing personal info are encrypted in future situations, some sorts of attacks may be reduced to more of an inconvenience (restore a backup) than a very costly security breach.
Just my first thoughts and 2 cents. Please defer to other professionals for advice about how to handle compliance, legal, financial, etc. obligations.
Hi,
It was a mySQL database and it was purely a seperate data storage for the app. Anvil is running on their servers and it only connects to the remote server to retrieve query results. SSH was configured on a non standard port but password authentication was enabled. I have since disabled password authentication for ssh and also disabled root login. I guess I could use an IP whitelist, as I would only have to whitelist myself and I’m assuming the Anvil server? To be honest I’m not completely clear on how the Uplink works, I’m assuming it’s some sort of encrypted connection between the anvil servers and my app data, but I don’t really understand the method of how it connects.
I should add there was an autossh tunnel between the server and my machine that runs the wazuh server in order to provide a connection.
I’m not sure about common attack vectors, I’m not even sure if they only gained access to the database or the server as a whole. The only anomaly I could find afterwards was that Wazuh picked up a Trojaned library ‘/etc/diff’. I checked this file against a known good one and also did a hash check and it passed both of those tests.
I don’t really know what to tell you about the uplink, as it was just implemented normally as instructed in the Anvil documentation.
With regard the database nothing was encrypted, as there’s no personal, financial or otherwise info in there and the data isn’t of value to anyone, it’s just statistical calculations.
In all honesty the server password wasn’t super strong. I only realised there was an issue when I didn’t get a notification that the database had backed up that evening. When I looked at the database all the tables were gone. I went to restore a backup and instead of there being 3 available backups, as is normal there was just the one. I restored it and then saw that it contained a new table called ‘README’. Inside that was the ransom demand for 0.01 bitcoin.
Update to a stronger password (not just for the database, but for every level of server access).
Consider every type of log file and history information. If DB logs were deleted, perhaps SSH, web server, network traffic, SFTP, etc., may be available. Even data such as timestamps on systems files and IP address information in any log files which haven’t been considered (for any service that uses a network port), can be useful for forensic analysis.
Review firewall rules, user permissions, and the state of security patches on the server.
Scan for malware and backdoors.
Update any third-party software running on the server to ensure they’re free of known vulnerabilities.
Disable or restrict any unnecessary services and ports on the server.
Install your own intrusion detection, prevention, security information and event management systems on the server.
Encrypt data at the column level in your database.
Consider conducting a penetration test, vulnerability assessment, information security audit, code review, etc. to identify weaknesses.
For software that requires compliance, I rely on third party professionals to handle all these sorts of requirements.
Perhaps @nickantonaccio points are enough, perhaps they are not, I’m the last person to judge, I’m not an expert.
And that’s why I would never setup and manage my own database. I trust the Anvil service for the security it provides, and the day I will need to rely on an external database, I will use a database service, setup by professionals, not by me. I am flying solo here, and I know enough about security to know that I don’t know enough, and I trust that sooner or later I would screw up.
Maybe I could even be able to follow the best practices on day one and get everything working securely for some time. But sooner or later I would shift the focus to other priorities, forget that database thingy that is working so smoothly and doesn’t need my attention, and slowly become vulnerable because I didn’t keep up with the latest security updates.
Adam said that security for his app isn’t ‘a huge deal’, that this topic is ‘just more of an inconvenience and a learning opportunity’. The thoughts above are meant to provide some direction in learning about considerations involved in security management, and perhaps performing some forensic research to understand what happened in his case, since he’s curious. I think it’s certainly important to be aware that all the topics above need to be addressed (at least), for any app that needs to be secured.
I’ve taken quite a few steps to tighten things up. All passwords are now very strong. Passwords are disabled for SSH and only keys for authentication. Root login for SSH is disabled. None of the credentials are hard coded anywhere. Wazuh is now setup correctly and all the logging is piped to it, so if it happens again I’ll at least be able to view the logs. I haven’t yet disabled unnecessary services and ports, which is my next task.
Security is quite the rabbit hole to go down. I can see why it pays so well in the industry. At the end of the day, if someones determined enough they probably will get in. Fortunately there’s nothing of any real value for them to find.