27.1. Securing access to the Neo4j Server
- Secure the port and remote client connection accepts
- Server authentication and authorization
- HTTPS support
- Arbitrary code execution
- Server authorization rules
- Hosted scripting
- Security in depth
Secure the port and remote client connection accepts
By default, the Neo4j Server is bundled with a Web server that binds to host
localhost on port
7474, answering only requests from the local machine.
This is configured in the conf/neo4j-server.properties file:
# http port (for all data, administrative, and UI access) org.neo4j.server.webserver.port=7474 # Let the webserver only listen on the specified IP. Default is localhost (only # accept local connections). Uncomment to allow any connection. #org.neo4j.server.webserver.address=0.0.0.0
If you want the server to listen to external hosts, configure the Web server in the conf/neo4j-server.properties by setting the property
org.neo4j.server.webserver.address=0.0.0.0 which will cause the server to bind to all available network interfaces.
Note that firewalls et cetera have to be configured accordingly as well.
Server authentication and authorization
Neo4j requires clients to supply authentication credentials when accessing the REST API. Without valid credentials, access to the database will be forbidden.
The authentication and authorization data is stored under data/dbms/auth. If necessary, this file can be copied over to other neo4j instances to ensure they share the same username/password (see the section called “Copying security configuration from one instance to another”).
Please refer to Section 21.3, “REST API Authentication and Authorization” for additional details. When access Neo4j over unsecured networks, ensure HTTPS is configured and used for access (see the section called “HTTPS support”).
If necessary, authentication may be disabled. This will allow any client to access the database without supplying authentication credentials.
# Disable authorization dbms.security.auth_enabled=false
Disabling authentication is not recommended, and should only be done if the operator has a good understanding of their network security, including protection against cross-site scripting (XSS) attacks via user browsers. Developers should not disable authentication if they have a local installation using the default listening ports.
The Neo4j server includes built in support for SSL encrypted communication over HTTPS. The first time the server starts, it automatically generates a self-signed SSL certificate and a private key. Because the certificate is self signed, it is not safe to rely on for production use, instead, you should provide your own key and certificate for the server to use.
To provide your own key and certificate, replace the generated key and certificate, or change the conf/neo4j-server.properties file to set the location of your certificate and key:
# Certificate location (auto generated if the file does not exist) dbms.security.tls_certificate_file=ssl/snakeoil.cert # Private key location (auto generated if the file does not exist) dbms.security.tls_key_file=ssl/snakeoil.key
Note that the key should be unencrypted. Make sure you set correct permissions on the private key, so that only the Neo4j server user can read/write it.
Neo4j also supports chained SSL certificates. This requires to have all certificates in PEM format combined in one file and the private key needs to be in DER format.
You can set what port the HTTPS connector should bind to in the same configuration file, as well as turn HTTPS off:
# Turn https-support on/off org.neo4j.server.webserver.https.enabled=true # https port (for all data, administrative, and UI access) org.neo4j.server.webserver.https.port=443
Arbitrary code execution
By default, the Neo4j Server comes with some places where arbitrary code code execution can happen. These are the Section 21.17, “Traversals” REST endpoints. To secure these, either disable them completely by removing offending plugins from the server classpath, or secure access to these URLs through proxies or Authorization Rules. Also, the Java Security Manager, see http://docs.oracle.com/javase/7/docs/technotes/guides/security/index.html can be used to secure parts of the codebase.
The neo4j server exposes remote scripting functionality by default that allow full access to the underlying system. Exposing your server without implementing a security layer poses a substantial security vulnerability.
Security in depth
Although the Neo4j server has a number of security features built-in (see the above chapters), for sensitive deployments it is often sensible to front against the outside world it with a proxy like Apache
This provides a number of advantages:
Control access to the Neo4j server to specific IP addresses, URL patterns and IP ranges. This can be used to make for instance only the /db/data namespace accessible to non-local clients, while the /db/admin URLs only respond to a specific IP address.
<Proxy *> Order Deny,Allow Deny from all Allow from 192.168.0 </Proxy>
While equivalent functionality can be implemented with Neo4j’s
SecurityRule plugins (see above), for operations professionals configuring servers like Apache is often preferable to developing plugins. However it should be noted that where both approaches are used, they will work harmoniously providing the behavior is consistent across proxy server and
Run Neo4j Server as a non-root user on a Linux/Unix system on a port < 1000 (e.g. port 80) using
ProxyPass /neo4jdb/data http://localhost:7474/db/data ProxyPassReverse /neo4jdb/data http://localhost:7474/db/data
Simple load balancing in a clustered environment to load-balance read load using the Apache
<Proxy balancer://mycluster> BalancerMember http://192.168.1.50:80 BalancerMember http://192.168.1.51:80 </Proxy> ProxyPass /test balancer://mycluster