Securing eZ Find's Solr installation

When using eZ Publish's eZ Find extension on a public facing site or project -- arguably any project -- it is vital to secure it to prevent unauthorized access and potential data loss. eZ Find is powered by Apache Solr, an open-source search server based on the Lucene Java search library. Its power and flexibility make eZ Find a great tool when working with a lot of content in eZ Publish.

"First and foremost, Solr does not concern itself with security either at the document level or the communication level. It is strongly recommended that the application server containing Solr be firewalled such the only clients with access to Solr are your own. A default/example installation of Solr allows any client with access to it to add, update, and delete documents (and of course search/read too), including access to the Solr configuration and schema files and the administrative user interface." (emphasis added)

The canonical risk? A remote anonymous user can trivially clear a site's index if Solr is not secured prior to deployment.

BasicAuth via Jetty UserRealms

eZ Find 2.1 to eZ Find LS 5.2 use Solr 3.5.x/3.6.x, which uses Jetty 6.x for its HTTP stack. In this post we'll use Jetty 6.x.

eZ Find 5.3 introduced Solr 4.7.x, which uses Jetty 8.x. The configuration for Jetty 8.x differs slightly and won't be covered here. See the links section for further reading.

Here's how to secure your Solr search installation with basic authentication. In short, you will be configuring a username and password for only eZ Publish to be able to update and otherwise manage the search index. Using this same username and password, remote developers can still access the Solr admin panel for debugging purposes.

Edit extension/ezfind/java/etc/jetty.xml

The UserRealms block is usually already in jetty.xml, just commented out. Uncomment it as shown below.

The refreshInterval setting determines how often (in seconds) the realm.properties file is checked for updates.

While this does secure Solr's administration interface to anyone remote, it also denies access to developers that may need to access the Solr admin panel for debugging. To get around this issue, we can create an SSH tunnel from our developer machine to the remote server.

Links

Method considerations

While iptables is arguably the better option as it locks down access at a higher level, it does come with some inconveniences for the developer. Having to tunnel in or configure iptables to allow access to a number of developer IPs, which may change over time, adds ongoing management overhead.

The iptables setup is also usually not part of the site's code repository, which means that if the site is moved to a new host and the iptables rules aren't moved along with it, Solr would be vulnerable again.

The BasicAuth setup using Jetty's UserRealms on the other hand would be part of the code base and would safeguard the Solr install in such a case.

Ideally, both methods should be used in conjunction to avoid nasty surprises.