Securing iDempiere

Seed Contributor: Carlos Ruiz - GlobalQSS - please feel free to improve.

Browsers (chrome, firefox, safari, ie, opera)

https

Don't use http, always use SSL encrypted https

client certificates

You can provide client certificates to your users to restrict who can connect

Proxy Web Server (nginx, apache)

Set up a proxy web server and publish JUST the services required by the users, most of the times is just webui

iDempiere Services on web

rest webservices

There were webservices that returned the database password, these webservices were dropped after version 7.1

server operating system (linux, windows, mac)

idempiere-server folder

You must protect the files idempiereEnv.properties, idempiere.properties and .idpass and some other files containing the database password.

• in windows by default usually it has read permission from everybody
• in linux the file is protected by default and the password is obfuscated using base64
  • There is a provision to customize the way to obfuscate/encrypt the password, or externalize it (avoid to save it on the server). Note externalizing the password protect against physical access (like stolen hard drive), but these passwords CANNOT be protected against a hacker accessing the live server, unless you sacrifice the ability to automate many things requiring manual intervention from an operator to provide some credentials.

swing client

swing client is insecure, not recommended

database password encrypted in properties file

The database password on swing client is "encrypted" in a properties file, the problem is that the encryption algorithm is usually common and easy to decrypt, and even if you change it can be easily extracted from the jar files. There is the possibility of implementing alternative keys, algorithm or even classes to encrypt better the strings.

terminal server approach (nx, citrix, ts)

if definitely you are needing to use swing client is better to use it via a terminal server where you have control of the machines

jasper reports

• Be careful, jasper can read anything over the database, just install trusted reports.
• Consider including in your jasper queries the security layer of iDempiere, like is included by MRole.addAccessSQL, like:
  • Restrict to the organizations the user has access to
  • Take into account AD_Private_Access and AD_Record_Access

external tools

If you need to give direct SQL access to other tools like jasper, odbc/jdbc connections to libreoffice, datawarehouses, ETL, talend, etc - better consider creating a read-only user with access to preconfigured views. The views can contain the security filter for AD_Client_ID

iDempiere configuration

roles

• configure access not menus (menus don't restrict access - user still can zoom)
• db access (tables, columns)
• private records
• record access

NOTE ON ADVANCED ROLES

The advanced roles are intended for IT on client side - do not give an advanced role to an end user. You must consider advanced roles as SuperUser, they have access to all security holes.

Also you must consider SuperUser as if it has access to the operating system user used to install iDempiere on the server.

Multi-factor Authentication

Since version 8.2.2021-06-09 iDempiere is able to manage Multi-factor Authentication on login time. Refer to Configure MFA for details about how to setup and use this feature.

You can trace MFA failures in the file AuthFailure.log, it is recommended to setup a mechanism to inform users when MFA failures happen, it can mean that their password was leaked.

tracing possible attacks

Every trial to login with a wrong password, or an MFA failure is recorded in the file AuthFailure.log

external tools to deny service on attacks

You can use tools like denyhosts to ban IP addresses that are testing passwords based on the AuthFailure.log file

initial steps

• sysconfig ZK_ROOT_FOLDER_BROWSER
• change encryption key
• hash passwords (if not using hashed passwords, then encrypt AD_User.Password and AD_Password_History.Password)
• encrypt all columns containing passwords (not required for AD_User.Password and AD_Password_History.Password if using hashed passwords)
• setup password rules
• change default passwords for SuperUser, System, GardenAdmin and GardenUser
• change default passwords after creating a new client (in Initial Client Setup can select not to assign passwords by default for better security)