Neo4j Security Benchmark

Overview:

This document, Neo4j Security Benchmark, provides prescriptive guidance for establishing a secure configuration posture for Neo4j Enterprise Edition versions 3.5.0 and higher. This guide was tested against Neo4j 3.5.0 running on Ubuntu Linux 18.04, but applies to other Linux distributions as well. If you have questions, comments, or have identified ways to improve this guide, please write us at feedback@neo4j.com.

(This document should integrate and incorporate present information on the public website available here: https://neo4j.com/docs/operations-manual/current/security/checklist/)

Intended Audience:

This document is intended for system and application administrators, security specialists, auditors, help desk, and platform deployment personnel who plan to develop, deploy, assess, or secure solutions that incorporate Neo4j Enterprise Edition.

Changes in Neo4j 3.5:

Neo4j 3.5 provides the following enhancements regarding security configuration:

  • Encryption of the cluster discovery protocol.
  • New settings have been introduced to prevent brute force attacks.
  • SAN/HV: Subject Alternative Name / Hostname Verification for Neo4j Cluster.
  • Configuration settings to allow users to disable HTTP/HTTPS

Recommendations

1. Installation and Patching

This section provides guidance on ensuring that the Neo4j software is up to date to eliminate easily avoidable vulnerabilities.

1.1 Ensure the appropriate Neo4j software version/patches are installed

Description:
The Neo4j installation version, along with the patch level, should be the most recent that is compatible with the organization’s operational needs.

Rationale:
Using the most recent Neo4j software version along with all applicable patches helps limit the possibilities for vulnerabilities in the software. The installation version and/or patches applied should be selected according to the needs of the organization. At minimum, the software version should be supported. The latest releases can be found at: https://neo4j.com/download-center/. As of November 2018, Neo4j 3.2.12, Neo4j 3.3.7, Neo4j 3.4.8 and Neo4j 3.5.0 are the latest supported versions.

Remediation:
Upgrade to the latest version of the Neo4j software:
1. Backup the data set.
2. Download the binaries for the latest Neo4j revision from the Neo4j download page and store the binaries in a temporary location. The binaries download as compressed files that extract to the directory structure used by the Neo4j installation.
3. Shut down the Neo4j instance.
4. Replace the existing Neo4j binaries with the downloaded binaries.
5. Restart the Neo4j instance.

Default Value:
N/A

2. Authentication

This section contains recommendations for requiring authentication before allowing access to the Neo4j database.

2.1 Ensure that authentication is enabled for Neo4j databases

Description:
This setting ensures that all clients, users, and/or servers are required to authenticate prior to being granted access to the Neo4j database.

Rationale:
Failure to authenticate clients, users, and/or servers can enable unauthorized access to the Neo4j database and can prevent tracing actions back to their sources.

Remediation:
The authentication mechanism should be implemented before anyone accesses the Neo4j Server.

To enable the authentication mechanism: In the Neo4j.conf file, uncomment the dbms.security.auth_enabled setting:

# Whether requests to Neo4j are authenticated.
# To disable authentication, uncomment this line
dbms.security.auth_enabled=true

Modify the Neo4j user password, ensuring that its password meets organizationally-defined password complexity requirements.

IMPORTANT: Use the set-initial-password command of neo4j-admin to define the password for the native user neo4j. This must be performed before starting up the database for the first time.

Default Value:
Authentication is enabled by default with the neo4j username and neo4j password.

2.2 Ensure authentication is enabled in the Neo4j cluster

Description:
Authentication is enabled in a Neo4j cluster when keyfiles are created and configured for all components. This ensures that every client that accesses the cluster must provide credentials, to include Neo4j instances that access each other within the cluster.

Rationale:
Enforcing a key on a sharded cluster prevents unauthorized access to the Neo4j database and provides traceability of database activities to a specific user or component.

2.3 Use Neo4j with an LDAP Auth Provider

Description:
Configuring Neo4j to use an LDAP Auth provider offloads management of federated users to the LDAP service. The LDAP service facilities are used for administration.

Rationale:
An LDAP auth provider provides stronger user management (disable users, password changes, password complexity, etc.) than available with Neo4j native users. It also streamlines the user management across a cluster, as Neo4j does not centralize management of native users.

Remediation:
The authentication mechanism should be implemented before anyone accesses the Neo4j Server.

All settings need to be defined at server startup time in the default configuration file neo4j.conf.

# Turn on security
dbms.security.auth_enabled=true

# Choose LDAP connector as security provider for both authentication and authorization
dbms.security.auth_provider=ldap

In environments where you need both LDAP authentication as well as some native user accounts, there is a way to allow this in Neo4j 3.1 and newer. Use the configuration setting dbms.security.auth_providers instead of the singular version dbms.security.auth_provider. This will allow you to supply a list of providers to use for authentication.

Default Value:
Not configured

2.4 Use Neo4j with Kerberos (Optional)

Description:
The official Neo4j Kerberos add-on can be used to extend Neo4j with Kerberos authentication.

Rationale:
The official Neo4j Kerberos add-on provides authentication and should be used in conjunction with another provider such as LDAP for authorization.

Remediation:
Consult with Neo4j Support to configure the Kerberos add-on.

Default Value:
Not configured

2.5 Configure User Authentication Maximum Failed Attempts

Description:
When using Neo4j native user management, configure the maximum failed attempts to guard against brute force attacks.

Rationale:
Configuring the maximum failed attempts will help minimize the chance of a successful brute force attack (avoid an attacker guessing a password by constantly requesting authentication to the server).

Remediation:
In the Neo4j.conf file, add the dbms.security.auth_max_failed_attempts configuration parameter:

dbms.security.auth_max_failed_attempts=10

The default value for this parameter is 3.

Default Value:
Not configured

Note:
1. Neo4j native user management does not have strong password requirements to include password length, complexity or expiration and may not meet stringent password requirements.
2. The settings are per-user, i.e. the server keeps a list of the number of consecutive failed attempts to login for each user.
3. The settings are global, i.e. they apply to all the users.

2.6 Configure User Authentication Lockout Time

Description:
When using Neo4j native user management, configure the user lockout time after unsuccessful authentication attempts to guard against brute force attacks.

Rationale:
Configuring the user lockout time will help minimize the chance of a successful brute force attack (avoid an attacker guessing a password by constantly requesting authentication to the server).

Remediation:
In the Neo4j.conf file, add the dbms.security.auth_lock_time configuration parameter:

dbms.security.auth_lock_time=10

The default value for this parameter is 5. The unit of measure for this parameter is seconds.

Default Value:
Not configured

Note:
1. Neo4j native user management does not have strong password requirements to include password length, complexity or expiration and may not meet stringent password requirements.
2. The settings are per-user, i.e. the server keeps a list of the number of consecutive failed attempts to login for each user.
3. The settings are global, i.e. they apply to all the users.

3. Encryption

This section contains recommendations configuring Neo4j to use encryption ensures that sensitive data and passwords are not passed over the network in clear text.

3.1 Require TLS for Bolt Connections

Rationale:
The bolt protocol can operate either encrypted or unencrypted. This setting ensures that unencrypted mode may not be used by clients. This in turn ensures that unencrypted data and authorization information never crosses the wire.

Remediation:
In the Neo4j.conf file, configure the dbms.connector.bolt.tls_level configuration parameter:

dbms.connector.bolt.tls_level=REQUIRED
3.2 Install a signed TLS certificate

Rationale:
The bolt protocol can operate either encrypted or unencrypted. This setting ensures that unencrypted mode may not be used by clients. This in turn ensures that unencrypted data and authorization information never crosses the wire.

Remediation:
Use SSL certificates issued from a trusted Certificate Authority. 1. For configuring your Neo4j installation to use encrypted communication, refer to https://neo4j.com/docs/operations-manual/current/security/ssl-framework/ [Section 7.3, “Unified SSL framework”].
2. For configuring your Bolt and/or HTTPS connectors, refer to https://neo4j.com/docs/operations-manual/current/configuration/connectors/ [Section 3.6, “Configure Neo4j connectors”].
3. If using LDAP, configure your LDAP system with encryption via StartTLS; see the section called “Use LDAP with encryption via StartTLS”.

References:

Default Value:
Not configured

3.3 Disable HTTP Port

Rationale:
Data passed over the http port is unencrypted.

Remediation:
You can disable the HTTP port by setting the dbms.connector.http.enabled parameter to false.

# HTTP Connector. There must be exactly one HTTP connector.
dbms.connector.http.enabled=false

Default Value:
dbms.connector.https.enabled=true

4. Neo4j Browser

This section contains recommendations for enhancing the Neo4j browser security and other http security measures.

4.1 Ensure Neo4j Browser does not cache login information

Description:
The Neo4j browser requires a username / password for login. This setting ensures that all clients using the Neo4j browser are required to login each time and that the login credentials are not maintained.

Rationale:
Enforcing a login each time prevents unauthorized access to the Neo4j database and provides traceability of database activities to a specific user or component.

Remediation:
The browser login should be implemented before anyone accesses the Neo4j Server.

To disable the browser from retaining connection credentials:

In the Neo4j.conf file, add the browser.retain_connection_credentials configuration parameter:

browser.retain_connection_credentials=false

Default Value:
Not configured

4.2 Implement Neo4j Browser Time-Out

Description:
The Neo4j browser requires a username / password for login. This setting ensures that a client using the Neo4j browser will be logged out after a period of inactivity.

Rationale:
Enforcing a time-out after a period of inactivity prevents unauthorized access to the Neo4j database.

Remediation:
The browser time-out setting should be implemented before anyone accesses the Neo4j Server.

To enable the browser time-out:

In the Neo4j.conf file, add the browser.credential_timeout configuration parameter and configure it to the appropriate setting.

browser.credential_timeout=5m

Default Value:
Not configured

4.3 Configure CORS Headers

Description:
The Access-Control-Allow-Origin response header indicates whether the response can be shared with resources with the given origin. For requests without credentials, the server may specify “*” as a wildcard, thereby allowing any origin to access the resource.

It may be necessary to specify the CORS response header to limit access to a specific URI.

Rationale:
Enabling a specific CORS response header limits the ability to access the website.

Remediation:
To specify a specific CORS response header:

In the Neo4j.conf file, add the dbms.connectors.access_control_allow_origin parameter and configure it to the appropriate setting. The expected value is a string.

dbms.security.http_access_control_allow_origin=http://neo4j.com

Default Value:
dbms.security.http_access_control_allow_origin=*

4.4 Set HTTP Strict-Transport-Security (HSTS) Response Header

Description:
The HTTP Strict-Transport-Security (HSTS) header tells browsers that a webpage should only be accessed using HTTPS instead of HTTP. It is attached to every HTTPS response.

Rationale:
Enabling the HSTS Response Header ensures that the browser is only available via HTTPS.

Remediation:
To enable the HSTS header:

In the Neo4j.conf file, add the dbms.security.http_strict_transport_security parameter and configure it to the appropriate setting.

dbms.security.http_strict_transport_security=Strict-Transport-Security: max-age=31536000; includeSubDomains

Default Value:
Not set.

5. Disable the UDC Data Collector

Description:
The Neo4j Usage Data Collector, UDC, is a subsystem that gathers usage data, reporting it to the UDC-server at udc.neo4j.org. It is easy to disable, and does not collect any data that is confidential.

Rationale:
Disabling the Usage Data Collector prevents any data from being sent to a third-party server.

Remediation:
Disabling the Usage Data Collector should be implemented before anyone accesses the Neo4j Server.

To disable the Usage Data Collector:

In the Neo4j.conf file, add the dbms.udc.disabled configuration parameter and configure it to the appropriate setting.

dbms.udc.enabled=false

Default Value:
dbms.udc.enabled=true

7. Data Encryption

This section contains recommendations for securing data at rest (stored) and data in motion (transiting) for Neo4j.

7.1 Ensure TLS or SSL protects all network communications

Description:
Use TLSv1.2 or SSL to protect all incoming and outgoing connections. This should include using TLS or SSL to encrypt communication between a Neo4j cluster as well as between all applications and Neo4j.

Rationale:
This prevents sniffing of cleartext traffic between Neo4j servers or performing a man-in-the-middle attack of Neo4j.

Audit:
To verify that system activity is being audited for Neo4j, inspect the neo4j.conf file for the following settings:

nmap --script ssl-enum-ciphers -p 5000 localhost
nmap --script ssl-enum-ciphers -p 6000 localhost
nmap --script ssl-enum-ciphers -p 7000 localhost
nmap --script ssl-enum-ciphers -p 7473 localhost

Remediation:
Configure Neo4j servers to require the use of SSL or TLS to encrypt all Neo4j network communications.

To implement SSL or TLS to encrypt all Neo4j network communication, review the referenced section of our manual.

  1. Read the following 2 sections in the Operations Manual: https://neo4j.com/docs/operations-manual/current/security/ssl-framework/ and then read: https://neo4j.com/docs/operations-manual/current/clustering/intra-cluster-encryption/
  2. Make sure your Java installation supports JCE or the ciphers won’t work. See https://neo4j.com/docs/operations-manual/current/security/ssl-framework/#ssl-java-configuration
  3. Run nmap –script ssl-enum-ciphers localhost to determine what ciphers are available.
  4. Configure intermediate certificates and server certificates per https://neo4j.com/docs/operations-manual/current/clustering/causal-clustering/intra-cluster-encryption/

Default Value:
Not configured.

Notes:
Neo4j drivers enable TLSv1.2 by default.

7.2 Configure Cluster Discovery to use AKKA

Description:
Configure the cluster discovery to use AKKA to enable secure cluster discovery communications.

Rationale:
The Clustering Discovery Service, i.e. the communication to implement service discovery among the members of a Neo4j cluster, is secured via TLS. This prevents transmission of cluster discovery communications in clear text.

Audit:
To verify that the server has enabled SSL or TLS usage for cluster discover, run one of the following commands:

nmap --script ssl-enum-ciphers -p 5000 localhost

Remediation:
Configure Neo4j servers to require the use of SSL or TLS to encrypt all Neo4j cluster discovery communications.

causal_clustering.middleware_type=akka
causal_clustering.discovery_implementation=akka

Default Value:
Not configured. Neo4j uses Hazelcast by default.

Supported Versions:
This feature is only available in a Causal Clustered environment and only available on versions 3.5 or later.

7.3 Encrypt Data Backups

Description:
Use TLSv1.2 or SSL to protect all data backups.

Rationale:
This prevents sniffing of cleartext traffic when performing a Neo4j backup.

Audit:
To verify that the server has enabled SSL or TLS usage, run the following commands:

nmap --script ssl-enum-ciphers -p 6362 localhost

Remediation:
Configure Neo4j servers to require the use of SSL or TLS to encrypt all Neo4j network communications.

To implement SSL or TLS to encrypt all Neo4j network communication, review the referenced section of our manual.

  1. Read the following 2 sections in the Operations Manual: https://neo4j.com/docs/operations-manual/current/security/ssl-framework/ and then read: https://neo4j.com/docs/operations-manual/current/clustering/intra-cluster-encryption/
  2. Make sure your Java installation supports JCE or the ciphers won’t work. See https://neo4j.com/docs/operations-manual/current/clustering/causal-clustering/intra-cluster-encryption/#_java_specfic_considerations
  3. Run nmap –script ssl-enum-ciphers localhost to determine what ciphers are available.
  4. Configure intermediate certificates and server certificates per https://neo4j.com/docs/operations-manual/current/clustering/intra-cluster-encryption/
  5. Enable encryption on the backup service for Causal Clustering instances.

Default Value:
Not configured.

Supported Versions:
This feature is only available in a Causal Clustered environment and only available on versions 3.4 or later.

7.4 Change default backup port

Description:
Modify backup port from the default setting of 6362.

Rationale:
This prevents access to the backup by sniffing for servers with ports 6362.

Remediation:
Configure Neo4j.conf to use a different backup port.

#dbms.backup.address=0.0.0.0:6362

Default Value:
6362

8. Activity Logging

This section contains recommendations related to configuring activity logging in Neo4j.

8.1 Ensure that system activity is audited

Description:
Track access to Neo4j. Neo4j Enterprise includes a system auditing facility that can record system events (e.g.m user operations, connection events) on a Neo4j instance. These audit records permit forensic analysis and allow administrators to verify proper controls.

Rationale:
System level logs can be handy while troubleshooting an operational problem or handling a security incident.

Audit:
To verify that system activity is being audited for Neo4j, inspect the neo4j.conf file for the following settings:

dbms.directories.logs=logs

# Log level for the security log. One of DEBUG, INFO, WARN and ERROR.
#dbms.logs.security.level=INFO

# Threshold for rotation of the security log.
#dbms.logs.security.rotation.size=20m

# Minimum time interval after last rotation of the security log before it may be rotated again.
#dbms.logs.security.rotation.delay=300s

# Maximum number of history files for the security log.
#dbms.logs.security.rotation.keep_number=7

Remediation:
1. Set the value of dbms.directories.logs.destination to the appropriate destination.
2. Set the value of dbms.logs.security.level to the appropriate setting.
3. Set the value of dbms.logs.security.rotation.keep_number to the appropriate number of logs to keep.

Default Value:
dbms.directories.logs=logs
dbms.logs.security.level=INFO
dbms.logs.security.rotation.size=20m
dbms.logs.security.rotation.delay=300s
dbms.logs.security.rotation.keep_number=7

9. Operating System Hardening

This section contains recommendations related to hardening the operating system running below Neo4j.

9.1 Neo4j Database Running with Least Privileges

Description:
This setting ensures that the Neo4j service runs as a least privileged user.

Rationale:
Anyone who has been a victim of viruses, worms, and other malicious software (malware) will appreciate the security principle of “least privilege.” If all processes ran with the smallest set of privileges needed to perform the user’s tasks, it would be more difficult for malicious and annoying software to infect a machine and propagate to other machines.

Remediation:
Create a user that’s only used for installing and running neo4j and directly related processes. This user must not have administrative rights to the system.

The user that Neo4j runs as must have the following permissions:

Read Only
* conf
* import
* bin
* lib
* plugins

Read and write
* data
* logs
* Metrics

Execute
* all files in bin

9.2 Ensure that Neo4j uses non-default ports

Description:
Changing the ports used by Neo4j makes it harder for attackers to find the database and target it.

Rationale:
Standard ports are used in automated attacks and by attackers to verify which applications are running on a server.

Remediation:
Change the default ports used by the Neo4j server.

Audit:
Review the neo4j.conf file for:

  • dbms.backup.address
  • dbms.connector.bolt.listen_address
  • dbms.connector.http.listen_address
  • dbms.connector.https.listen_address
  • causal_clustering.discovery_listen_address
  • causal_clustering.transaction_listen_address
  • causal_clustering.raft_listen_address

Impact:
Hackers frequently scan IP addresses for commonly used ports, so it’s not uncommon to use a different port to “fly under the radar”. This is just to avoid detection, other than that there is no added safety by using a different port.

9.3 Ensure that operating system resource limits are set for Neo4j

Description:
Operating systems provide ways to limit and control the usage of system resources such as threads, files, and network connections on a per-process and per-user basis.

Rationale:
These limits prevent a single user from consuming too many system resources.

Audit:
To verify the resource limits set for Neo4j, run the following commands.

Extract the process ID for Neo4j:

 ps -ef | grep neo4j

View the ulimits associated with that process number:

 cat /proc/1322/limits

Remediation:
Every deployment may have unique requirements and settings. Recommended thresholds and settings are particularly important for Neo4j deployments:

  • f (file size): unlimited
  • t (cpu time): unlimited
  • v (virtual memory): unlimited [1]
  • n (open files): 40000
  • m (memory size): unlimited [1] [2]
  • u (processes/threads): 64000

Restart the Neo4j instances after changing the ulimit settings to ensure that the changes take effect.

Default Value:
Not configured.

10. Disable Deprecated Neo4j Utilities

This section contains recommendations related to disabling deprecated utilities.

10.1 Neo4j-Shell

Description:
This setting ensures that the Neo4j-Shell utility is disabled.

Rationale:
Neo4j-shell does not use authentication / authorization when connecting to the Neo4j database.

Remediation:
Ensure that Neo4j-Shell is not enabled in Neo4j.conf. Alternately, you can remove the <neo4j>/lib/neo4j-shell-<version>.jar file.

# Enable a remote shell server which Neo4j Shell clients can log in to.
#dbms.shell.enabled=true

# The network interface IP the shell will listen on (use 0.0.0.0 for all interfaces).
#dbms.shell.host=127.0.0.1

# The port the shell will listen on, default is 1337.
#dbms.shell.port=1337

Default Value:
Not enabled.

10.2 JMX

Description:
This setting ensures that remote JMX monitoring is disabled.

Rationale:
JMX has several drawbacks:
* It is based on the obsolete RMI protocol
* It can trigger harmful functions like garbage collection
* It can be used for nasty exploits like invoking arbitrary code

Remediation:
JMX is not enabled by default. Neo4j provides other monitoring options which are described in our operations manual.

# Remote JMX monitoring, uncomment and adjust the following lines as needed. Absolute paths to jmx.access and
# jmx.password files are required.
# Also make sure to update the jmx.access and jmx.password files with appropriate permission roles and passwords,
# the shipped configuration contains only a read only role called 'monitor' with password 'Neo4j'.
# For more details, see: http://download.oracle.com/javase/8/docs/technotes/guides/management/agent.html
# On Unix based systems the jmx.password file needs to be owned by the user that will run the server,
# and have permissions set to 0600.
# For details on setting these file permissions on Windows see:
#     http://docs.oracle.com/javase/8/docs/technotes/guides/management/security-windows.html
#dbms.jvm.additional=-Dcom.sun.management.jmxremote.port=3637
#dbms.jvm.additional=-Dcom.sun.management.jmxremote.authenticate=true
#dbms.jvm.additional=-Dcom.sun.management.jmxremote.ssl=false
#dbms.jvm.additional=-Dcom.sun.management.jmxremote.password.file=/absolute/path/to/conf/jmx.password
#dbms.jvm.additional=-Dcom.sun.management.jmxremote.access.file=/absolute/path/to/conf/jmx.access

Default Value:
Not enabled.

11. Docker

This section contains recommendations related to running Neo4j securely in Docker.

11.1 Encryption

Description:
This section describes security in Neo4j when running in a Docker container.

Rationale:
Neo4j running in Docker can support Neo4j’s native TLS support.

Remediation:
To use your own key and certificate within the Docker container, provide an /ssl volume with the key and certificate inside. The files must be called neo4j.key and neo4j.cert. You must also publish port 7473 to access the HTTPS endpoint.

docker run --publish=7473:7473 --publish=7687:7687 --volume=$HOME/neo4j/ssl:/ssl neo4j:3.5

Default Value:
Not enabled.

  • Last Modified: 2020-09-15 13:07:09 UTC by David Fauth.
  • Relevant for Neo4j Versions: 3.5.
  • Relevant keywords operations, security, configuration.