I am exploring what possible strong security options are there to safeguard ODK aggregate.
My client is very concerned that the open interface of Aggregate (the login page) over the public internet is not OK. He wants some extra security on top of it, something like the Aggregate login page be available only to the admin, and not to anyone else.
One option is to put a fixed IP allow-list on tomcat config, with only admin IP in it. But the logic tells me that it will also stop the data collectors to access the server and send the data from the mobiles to the server (since they access the same IP and port as the aggregate). Another option is to put an extra apache server (perhaps HTTP) username/password auth page on top of ODK login page. But this also will bring up the same issue for field workers to send data.
So if your client is primarily concerned with unauthorized users gaining access to collected data, one possible solution is to keep as little data as possible actually in the server. For example, each day you could download the synced data to a secure location and then delete it from the server. You would have to be very, very careful to make sure you got all of the data downloaded and then multiply back it up, but it would no longer be on the server.
I will let someone with more technical expertise weigh in on the tomcat option.
Agreed with Caroline that before any security measure is implemented, it's good to understand what attackers and scenarios you'd like to protect against so you can weigh the trade-offs.
If the data is what you wish to protect, then use encrypted forms. It's a little more cumbersome for users, but it will protect the data.
If you are worried about unauthorized devices, then I'd use a VPN so only authorized devices can connect to the server. Again, a little annoying to use, but it will be secure.
If you have access to the fire wall on that box and know the Mac addresses of all the devices, you can block access only to white listed Mac addresses. For tablets and smartphones, you will need the WiFi Mac and the wireless Mac.
That would be the most secure. Also I would block all addresses outside the country.
On a previous system we stored data on the devices and only uploaded the data through ssh while on WiFi. Data can be stored encrypted on the device and unencrypted on the server.
Thanks Caroline, Yaw, and Brad. These are valuable suggestions.
Caroline's option of removing the data at a manageable frequency (like once a day) seems the simplest. It will need some careful sync practices to keep the data of one form together. The downside I see here is that since we are purging all data from Aggregate, we would not be able to use any aggregate features together (like maps, export in one file, etc), since the data would always be partial on the server and remaining downloaded and deleted already. The same issue would be extended to the customized dashboard. I have made one on top of ODK, which uses the real database of ODK for live incoming data (doesn't pull data to its own table), since the data is never complete.
Yaw, I just read the encrypted forms info, and it is very useful. However, is my understanding correct that it would nullify the viewing of data on aggregate? Since the info seems to say that the data would stay encrypted until you download via briefcase and then provide a key. Does this mean that we would not be able to see data in aggregate, even with a valid username/password?
For Yaw, my basic line of question is related to hacking/brute force attempts on ODK aggregate login page to break security. For this thread, I am not bringing into discussion ODK collect, or the data channel between the mobile phone and ODK Aggregate, which I see from your provided info, are pretty much covered already (encrypted forms, using SSL, VPN, etc). Thanks for pointing those out though!
Brad, your suggestion is a very relevant one with implementation scenarios outside ODK. I was already wondering to get into tomcat config to do these things. Surely an outside firewall would be a better option. How do you whitelist a full country addresses? Please do share.
Removing the data daily could reduce the overall harms, but I would argue that it doesn't make you significantly safer. A savvy attacker can compromise the server and copy the data as it comes in every day.
Encrypted forms do indeed prevent you from viewing data on the server. The only time you can see that data is before you finalize it with Collect and after you've decrypted it with Briefcase. It's not convenient if you want to see data in the dashboard, but it is very secure.
If you want to prevent brute force attempts, then an IPSec VPN would absolutely help. It'll let you put the server inside the private network and only approved devices can connect to that private network. This is similar to Brad's idea of whitelisting at the firewall level.
And speaking of whitelisting, whitelisting a country's addresses is not the way to go because that's just way too broad. It's also trivial for an attacker to route traffic through that country. Ditto with MAC addresses -- those are very easy to spoof.
I agree with Yaw -- Running within an IPSec VPN is the best way to mitigate external brute force attacks. It ensures that the only traffic reaching the server is traffic from devices on which there is a configured IPSec VPN connection.
If you do this, you should ensure your devices have a login screen and reasonable timeout.
The device storage should also be encrypted (so that the VPN credentials are more difficult to extract from the device).
Those countermeasures would protect you from device theft or loss.
And, of course, you need to ensure that physical and/or direct access to your server is secured -- and in particular the logs (and the access logs). Periodic examination of the access log should be performed to detect unexpected accesses.
