标签:
SSL support was added in version 4.2 (SolrCloud v4.7).
Authentication and Authorization plugin support was added in 5.2 (SolrCloud only)
Basic Auth & Kerberos plugins and Rule-based Authorization plugin was added in 5.3
There is (as of 5.3) no role-based restrictions on the Admin UI, so be aware that anyone with access to Admin UI will be able to do anything with your system.
Even though you add SSL or Authentication plugins, it is still 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.
If there is a need to provide query access to a Solr server from the open internet, it is highly recommended to use a proxy, such as one of these.
Solr has no known cross-site scripting vulnerabilities.
Quick XSS tip:
Problem: What if you want the browser to highlight text, but you also want to protect yourself from XSS and escape the HTML output? Solution: One solution is to escape the HTML output and then reapply the em tags. Now the rest of the snippet is safe and the browser will recognize the highlighted text.
For example, with groovy/grails you could have the following in your controller:
snippet = snippet.encodeAsHTML() snippet = snippet.replaceAll(‘<em>‘, ‘<em>‘) snippet = snippet.replaceAll(‘</em>‘, </em>)
Even if a Solr instance is protected by good firewalls so that "bad guys" have no direct access, that instance may be at risk to potential "Cross-Site Request Forgery" based attacks if the following are all true:
This is because Solr‘s most basic behavior is to receive updates and deletes via HTTP. If you have a firewall or other security measure restricting Solr‘s /update handler so it only accepts connections from approved hosts/clients, but you are approved then you could inadvertently be tricked into loading a web page that initiates an HTTP Connection to Solr on your behalf.
It‘s important to keep this in mind when thinking about what it means to "secure" an instance of Solr (if you have not already).
A basic technique that can be used to mitigate the risk of a possible CSRF attack like this is to configure your Servlet Container so that access to paths which can modify the index (ie: /update, /update/csv, etc...) are restricted either to specific client IPs, or using HTTP Authentication.
One way to add document level security to your search is through Apache ManifoldCF. ManifoldCF "defines a security model for target repositories that permits them to enforce source-repository security policies".
It works by adding security tokens from the source repositories as metadata on the indexed documents. Then, at query time, a Search Component adds a filter to all queries, matching only documents the logged-in user is allowed to see. ManifoldCF supports AD security out of the box.
*Stub - this is incomplete*
If ManifoldCF does not solve your need, first consider writing a ManifoldCF plugin. Or roll your own.
If you need permission based authentication -- where user A can update document 1 and 2, but not 3 -- you will need to augment the request with user information. Either you can add parameters to the query string (?u=XXX&p=YYY) or use a custom dispatcher filter that augments the context:
public class CustomDispatchFilter extends SolrDispatchFilter { @Override protected void execute( HttpServletRequest req, SolrRequestHandler handler, SolrQueryRequest sreq, SolrQueryResponse rsp) { // perhaps the whole request sreq.getContext().put( "HttpServletRequest", req ); // or maybe just the user sreq.getContext().put( "user", req.getRemoteUser()); core.execute( handler, sreq, rsp ); } } public class AuthenticatingHandler extends RequestHandlerBase { @Override public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp) throws Exception { HttpServletRequest httpreq = (HttpServletRequest) req.getContext().get( "HttpServletRequest" ); if( httpreq.isUserInRole( "editor" ) ) { ... } String user = (String)req.getContext().get( "user" ); ... } ... }
If streaming is enabled, you need to make sure Solr is as secure as it needs to be. When streaming is enabled, the parameters "stream.url" will go to a remote site and download the content. Likewise, "stream.file" will read a file on disk.
Streaming is disabled by default and is configured from solrconfig.xml
<requestParsers enableRemoteStreaming="false" ... />
在Tomcat6增加 Solr的访问权限方法如下:
编辑tomcat6/Catalina/localhost/solr.xml
<Context docBase="/var/solr/solr.war" debug="0" privileged="true" allowLinking="true" crossContext="true"> <Environment name="solr/home" type="java.lang.String" value="/var/solr" override="true"/> <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="192.168.1.100,localhost,192.168.1.103,127.0.0.1"/> <Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="192.168.1.105"/> </Context>
可参考Tomcat配置文档:http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter
要使上面的配置生效,还需要重新开启tomcat的安全机制
编辑sudo vi /etc/default/tomcat6
注释掉最后一句TOMCAT6_SECURITY=no
参考:
http://www.cnblogs.com/ibook360/archive/2011/11/07/2239247.html
http://wiki.apache.org/solr/SolrSecurity
标签:
原文地址:http://www.cnblogs.com/sevck/p/5783307.html