OFN is built upon two frameworks: Ruby on Rails and Spree Commerce. Each of these continually release security updates. Open Food Network is a number of releases behind on each of these, so some work is required to upgrade our system. This work will allow us to leverage the security improvements made by each of these platforms. These upgrades are currently in progress.
Security Audit
Once OFN is running the most recent versions of these frameworks, I propose a security audit of the system. This could look broadly at two areas:
A penetration test to search for security issues through which a hacker could gain access to the system.
A review of OFN’s access control system, to ensure that no user can access data in the site that they’re not permitted to.
Availability
As well as securing the site against attack, we want to ensure that it remains available at all times. This will be addressed through the provision of redundant servers, so that the site will continue to run if any server has an issue (see the infrastructure estimate). Additionally, we will store regular database backups in multiple locations so that the site can be recovered in the case of an emergency.
Ping @pmackay - I believe you were interested in this?
Since the OFN has been used in production for a while, a lot of security concerns have been addressed already. It also benefits from best practises already implemented in the used frameworks. Features include:
All access to servers is encrypted.
System admin access via SSH keys.
All web traffic via HTTPS.
No use of unencrypted FTP or SMTP services.
The servers are configured to install security updates automatically (Ubuntu security releases).
The application uses personal logins via email address and password.
Passwords are stored hashed with salt. Even system administrators can not read them.
All cryptographic features use industry standard code published as free software.
The application has a detailed permission system allowing people working together while protecting information about customers and enterprises.
All code of the OFN and used by the OFN is open source and available for security audits by the public.
Pinging also @gnollet@sylvain@pierredelacroix
Gilles, can you also tell if we have the server security updates stuff installed? And system admin access via SSH keys?
It would be great to ensure we are aligned with this security strategy for France in the new infrastructure deployment.
If you have any other comment on how to improve security please also comment.
@MyriamBoure by security, what do you mean ?
There is security point of view on maintaining the system up to date and the application as secure as possible.
There is security point of view on doing backup and keep them in secure storage
There is security point of view on application usage and what admin can do on the application.
In France, I’m keeping the system up to date as soon as possible. I do it manually because we need to schedule reboot and check if everything is ok after upgrade.
SSH access are allowed only to 2 persons, paco and me. paco is using ssh key and I’m using strong password.
SSH key is maybe better only if you don’t trust your PC. How to be sure your PC is not infected by malware ?
@RohanM and @maikel is there anything planned against a distributed denial of service attack [DDoS], which seems to be the most common attack (quoting some personal source = my boyfriend @Olivier ;-)) and as far as I understand can explode the RPM.
SSH key is maybe better only if you don’t trust your PC. How to be sure your PC is not infected by malware ?
It would be more secure to use an SSH key protected by a password. If your PC is infected, a key logger can get your passwords as well. Nothing helps in that case, except second factor authentication.
I try to keep my machine secure by running a stable Linux system and installing software only from trusted sources. My home directory is encrypted so that a stolen laptop doesn’t reveal any keys or passwords.
is there anything planned against a distributed denial of service attack [DDoS], which seems to be the most common attack
As recent cases have shown, DDoS is very difficult to defend. Some of the most specialised companies were not able to defend against that. The most important thing is that a DDoS attack results only in the service not being accessible during an attack and that there are no bugs revealing sensitive information during the attack. That is something the security audit should find if there is any such bug.
The infrastructure estimate includes a load balancer which can help a lot during such an attack. Optimising the performance of the OFN should help as well. We could also think of a reverse-proxy to take some load off the web and database servers. Implementing a filter on the load balancer should help as well so that a DDoS attack has as little impact as possible. But there is no way to deny these attacks to 100%.
Do we have someone looking at security issues yet? I think there are some good automated security assessment suites around that could give some decent feedback on a broad range of potential issues.
“Vega” by the Subgraph team looks good. I think it could be used to analyse both the web app in general and possibly our server setups as well: https://subgraph.com/vega/index.en.html
A simpler first step I would like to see is for the PR CI process to run Rubocop with a very conservative issue set that check for useful security related stuff, as well as Brakeman potentially.
Before that we’d have to run them and cleanup any current warnings.
