This page is intended to gather information about network, application, and operating system security; to discuss strengths, weaknesses, and implementation details.
Why Do We Need It?
Mifos contains personal and financial data, which is often carried between the Mifos Server and users over the network. These data must be protected from unintended disclosure.
Ideally, the database and application servers would be on different subnets.
Virtual Private Network
A VPN normally provides secure, encrypted traffic over the Internet between nodes. See this Wikipedia page for lots of information.
In the case of Mifos, one node will be the Mifos Server and others would be either single workstations or a group of workstation on an office LAN.
There are commercial options, but the one considered here is OpenVPN with the OpenVPN GUI client installed on Windows workstations.
This is a TLS/SSL VPN. The other main option is IPSec, with Openswan as an example. We have tried both and now use OpenVPN.
Referring to the diagram, the users make their VPN connection to the firewall, then they use an internal IP address within the VPN session to connect to resources on the network. Suitable firewall rules are required.
How To Build an OpenVPN Network
Two option will be covered:
A hybrid network combining both options can also be set up if you have a combination of remote sites with multiple computers and single-PC sites or mobile users.
This is one of the most common ways to secure information in a browser session, and gives the familiar padlock icon to show a page is secure.
Data is encrypted to a reasonable level - banks trust it - making interception of confidential information unlikely.
Users are familiar with it: they will be used to seeing the padlock when they visit secure sites.
The downside is that the MFI will need a server certificate, which costs money and may be an inhibiting factor.
Free certificates are available CACert is an example, but their root certificate is not included in mainstream browsers and needs user intervention to install.
Referring to the diagram, the users' sessions are directed to the web server or reverse proxy by the firewall and the traffic is decrypted there.
Please see CertsAndSSL and this mailing list post for hints on forcing all Mifos requests through SSL when using the Tomcat servlet container.
The IP addresses of the nodes allowed to connect to Mifos are defined in advance.
I'll put in some more analysis later, but believe this to be the weakest option for a few reasons including:
- Data is not encrypted unless some other mechanism is employed
- It will fail for dynamic IP addresses, typical of dial-up or ADSL links
- server security (database and application servers)
- firewall only allows necessary connections, for example: MySQL and SSH
- nonstandard ports used for SSH and MySQL services and/or denyhosts/fail2ban/tcp_wrapper rules to prevent brute-force attacks
- only allow key-based authentication for remote SSH login
- sudo used for all root access
- tripwire for binary integrity checking (makes sure no programs change)
- apparmor for mandatory system access controls
- frequent audits of login attempts
- VPN used between database and application servers, if co-located
- frequent auditing and continual monitoring of CPU, memory, and disk
- security updates for system software applied as available
- application server (Tomcat)
- secure connection via TLS/SSL (https)
- only allowed IPs can connect (optional)
- run as non-root user
- database server (MySQL)
- strong root password is set
- encrypt all database traffic with SSL
- connection from application only by non-root user with only the necessary permissions
- run as non-root user
- Data Center
- Physical security standards | Information security standards ISO27k | Data center - SAS 70 Type I | Type II
- external to Mifos / organizational
- email communication between branches
- always digitally signed with PGP or S/MIME
- signed and encrypted when sensitive information is present