lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Greenspan <aar...@thinkcomputer.com>
Subject Solr Security
Date Mon, 24 Jun 2013 05:51:40 GMT
Hi,

Some more unsolicited feedback since my last experience setting up Solr…

I am concerned that having a duplicate copy of a large part of my database up on the internet
at a guessable location, available for the world to see, is probably not such a good idea.
So I went to look up the various methods available to secure Solr, and found that all of them
are terrible, if recent documentation is even available, which it's often not. Most of the
blog posts I found are from 2010, presumably long before the version I use was created.

According to the Solr Security wiki (http://wiki.apache.org/solr/SolrSecurity), it looks like
you can edit some XML files (if you can find them) in complex ways to turn on HTTP authentication,
or you can restrict the IP that Solr runs on. Less clear is some way to change the default
port number from 8983.

The wiki itself is full of semi-useless information, which is pretty infuriating since it's
supposed to be the best source. The XML edits seem to change for different versions of Solr.
Statements like "standard Java web security can be added by tuning the container and the Solr
web application configuration itself via web.xml" are not helpful to me. I don't know what
"standard Java web security" is, nor am I inclined to trust it since "Java security" is already
believed by many to be something of an oxymoron. I don't have any idea where the file web.xml
is--the default Solr install is a nest of needlessly complex folders. (Is it the one at ~/example/solr-webapp/webapp/WEB-INF/web.xml?)
At the end of the page, there is a reference to "server.xml", but according to my install
there is no such file.

Basically, instead of (or at least on top of) this giant mess, the web interface for Solr
should prompt the user, before doing anything else, to set up an administrative username and
password, which one should be able to optionally require for queries and/or updates. It's
just common sense. If I remember correctly, Netscape Enterprise Server prompted you to do
that a decade and a half ago, and the internet has gotten a lot less friendly since then.
You should also be able to limit the IP addresses that Solr runs on through the web interface,
and change the port if desired, (or add/remove/edit users and passwords).

The web server should also log when someone signs into the administrative interface, and from
what IP address. There's probably some way to do this through the "Logging/Level" tree, but
it's not exactly clear to me.

In the meantime, I found that the approach most likely to work, and least likely to take a
week to implement, was just to use iptables to set up a firewall on port 8983. Contrary to
what one post on StackExchange (voted -1) says, it works only if you do the ACCEPT rules (iptables
-A INPUT -p tcp -s xxx.xxx.xxx.xxx --dport 8983 -j ACCEPT) before the DROP all rule (iptables
-A INPUT -p tcp --dport 8983 -j DROP). But either way, that's a pretty ridiculous solution.
I don't know of any other server product that disregards security so willingly.

Aaron

	
Aaron Greenspan
President & CEO
Think Computer Corporation

telephone +1 415 670 9350
fax +1 415 373 3959
e-mail aarong@thinkcomputer.com
web http://www.thinkcomputer.com



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message