a few AJAX
GETs? Cheers -- Rick
On November 30, 2017 3:10:14 PM EST, Rick Leir <rl...@leirtech.com> wrote:
>Hi all
>I have just been looking at solr-security-proxy, which seems to be a
>great little app to put in front of Solr (link below). But would it
>make more sense to use a
Hi all
I have just been looking at solr-security-proxy, which seems to be a great
little app to put in front of Solr (link below). But would it make more sense
to use a whitelist of Solr parameters instead of a blacklist?
Thanks
Rick
https://github.com/dergachev/solr-security-proxy
solr
To: solr-user@lucene.apache.org
Subject: RE: [Poll]: User need for Solr security
Jan - we don't really need any security for our products, nor for most clients.
However, one client does deal with very sensitive data so we proposed to
encrypt the transfer of data and the data on disk through a Lucene
-Original Message-
From: Markus Jelsma [mailto:markus.jel...@openindex.io]
Sent: Thursday, March 12, 2015 6:51 PM
To: solr-user@lucene.apache.org
Subject: RE: [Poll]: User need for Solr security
Jan - we don't really need any security for our products, nor for most
clients. However, one
Eric,
right, filesystem level encryption is the way. Making encryption part of
the lucene data structures would be a tall order.
On Thu, Mar 12, 2015 at 5:22 PM, Erick Erickson erickerick...@gmail.com
wrote:
About 1. Gotta be careful here about what would be promised. You
really _can't_
Jan,
Index encryption is not really about trust to root users for us. It is
about letting client company to be able to secure their index with their
key. To prevent information loss through hacking to a server. What I agree
with is that this does go beyond just search ;)
Thanks for the JIRA,
-need-for-Solr-security-tp4192624p4192816.html
Sent from the Solr - User mailing list archive at Nabble.com.
About 1. Gotta be careful here about what would be promised. You
really _can't_ encrypt the _indexed_ terms in a meaningful way and
still search. And, as you well know, you can reconstruct documents
from the indexed terms. It's lossy, but still coherent enough to give
security folks fits.
For
If you cannot trust your root users you probably have bigger problems than with
search... I think it has been suggested to encrypt on codec or directory level
as well. Yep, here is the JIRA
https://issues.apache.org/jira/browse/LUCENE-2228 :)
--
Jan Høydahl, search solution architect
Cominvent
: RE: [Poll]: User need for Solr security
Jan - we don't really need any security for our products, nor for most clients.
However, one client does deal with very sensitive data so we proposed to
encrypt the transfer of data and the data on disk through a Lucene Directory.
It won't fill all gaps
Hi,
I’m currently working with indexes that need document level security. Based on
the user logged in, query results would omit documents that this user doesn’t
have access to, with LDAP integration and such.
I think that would be nice to have on a future Solr release.
Henrique.
On Mar 12,
and it would certainly make
Solr/Lucene the search platform to use for some enterprises.
Markus
-Original message-
From:Henrique O. Santos hensan...@gmail.com
Sent: Thursday 12th March 2015 23:43
To: solr-user@lucene.apache.org
Subject: Re: [Poll]: User need for Solr security
Hi,
I’m
Hi,
Things you have mentioned would be useful for our use-case.
On top we've seen these two requests for securing Solr:
1. Encrypting the index (with a customer private key for instance). There
are certainly other ways to go about this, like using virtual private
clouds, but having the feature
Hi,
Securing various Solr APIs has once again surfaced as a discussion in the
developer list. See e.g. SOLR-7236
Would be useful to get some feedback from Solr users about needs in the field.
Please reply to this email and let us know what security aspect(s) would be
most important for your
Hi,
I am trying to apply the security patch(Solr-4470.patch) on solr 4.10.1 tag.
SOLR-4470.patch 14/Mar/14 16:15278 kB
Getting error with the hunk failure. Could any one confirm if this the right
patch for 4.10.1.
Thank you so much
RegardsRaj
On 11/5/2014 5:04 PM, kuttan palliyalil wrote:
I am trying to apply the security patch(Solr-4470.patch) on solr 4.10.1 tag.
SOLR-4470.patch 14/Mar/14 16:15278 kB
Getting error with the hunk failure. Could any one confirm if this the right
patch for 4.10.1.
The latest patch is almost 8
Got it. Thank you Shawn.
RegardsRaj
On Wednesday, November 5, 2014 10:39 PM, Shawn Heisey
apa...@elyograg.org wrote:
On 11/5/2014 5:04 PM, kuttan palliyalil wrote:
I am trying to apply the security patch(Solr-4470.patch) on solr 4.10.1 tag.
SOLR-4470.patch 14/Mar/14 16:15278 kB
if we just display the read-only
endpoints
to the public users? Can someone please advise?
http://wiki.apache.org/solr/SolrSecurity
--
View this message in context:
http://lucene.472066.n3.nabble.com/SOLR-Security-Displaying-endpoints-to-public-tp4109792.html
Sent from the Solr
://wiki.apache.org/solr/SolrSecurity
--
View this message in context:
http://lucene.472066.n3.nabble.com/SOLR-Security-Displaying-endpoints-to-public-tp4109792.html
Sent from the Solr - User mailing list archive at Nabble.com.
://lucene.472066.n3.nabble.com/SOLR-Security-Displaying-endpoints-to-public-tp4109792.html
Sent from the Solr - User mailing list archive at Nabble.com.
On 1/6/2014 10:55 AM, Developer wrote:
We are currently showing the SOLR endpoints to the public when using our
application (public users would be able to view the SOLR endpoints (/select)
and the query in debugging console).
I am trying to figure out if there is any security threat in terms of
On 1/6/2014 11:18 AM, Shawn Heisey wrote:
Even if you disable admin handlers so that it's impossible to gather
full information about your schema and other settings, generating
legitimate queries is probably enough for an attacker to get the
information they need.
Self-replying on this
On 06 Jan 2014, at 19:37 , Shawn Heisey s...@elyograg.org wrote:
On 1/6/2014 11:18 AM, Shawn Heisey wrote:
Even if you disable admin handlers so that it's impossible to gather full
information about your schema and other settings, generating legitimate
queries is probably enough for an
.nabble.com/SOLR-Security-Displaying-endpoints-to-public-tp4109792.html
Sent from the Solr - User mailing list archive at Nabble.com.
, 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
You might want to read up on Jetty webserver security if that is what you
are using for the web container.
K
To change Solr's default port number just pass -Djetty.port= on the
command line, works a treat.
As Solr is deployed as a web-app, it is assumed that the administrator
would be familiar with web apps, servlet containers and their security, if
not, then that is something you need to
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
On Jun 24, 2013, at 12:51 AM, Aaron Greenspan aar...@thinkcomputer.com wrote:
all of them are terrible,
it looks like you can edit some XML files (if you can find them)
The wiki itself is full of semi-useless information, which is pretty
infuriating since it's supposed to be the best
its a little frustrating to see the smug responses to your query
and its fair to say the solr security situation could be *improved*
this JIRA ticket is worth reading
https://issues.apache.org/jira/browse/SOLR-4470
in short
-it is possible to restrict access to solr nodes using connection
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
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
9:45 AM
To: solr-user@lucene.apache.org
Subject: Re: SOLR Security
Hi,
There is nothing stopping you from pointing Ajax-SOLR to a URL on your
app-server, which acts as a security insulation layer between the Solr
backend and the world. In this (thin) layer you can analyze the input
the client.
Mike
-Original Message-
From: Anupam Bhattacharya [mailto:anupam...@gmail.com]
Sent: Thursday, May 10, 2012 9:53 PM
To: solr-user@lucene.apache.org
Subject: SOLR Security
I am using Ajax-Solr Framework for creating a search interface. The search
interface works well
is logged
in, and adds terms to the query to limit returned results to those the user is
permitted to see.
-Original Message-
From: Jan Høydahl [mailto:j...@hoydahl.no]
Sent: Fri 5/11/2012 9:45 AM
To: solr-user@lucene.apache.org
Subject: Re: SOLR Security
Hi,
There is nothing stopping
[mailto:anupam...@gmail.com]
Sent: Thursday, May 10, 2012 9:53 PM
To: solr-user@lucene.apache.org
Subject: SOLR Security
I am using Ajax-Solr Framework for creating a search interface. The search
interface works well.
In my case, the results have document level security so by even indexing
@lucene.apache.org
Subject: SOLR Security
I am using Ajax-Solr Framework for creating a search interface. The search
interface works well.
In my case, the results have document level security so by even indexing
records with there authorized users help me to filter results per user
based
about Solr security on the WIKI:
http://wiki.apache.org/solr/SolrSecurity
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
On 9. mai 2011, at 20.57, Brian Lamb wrote:
Hi all,
Is it possible to set up solr so that it will only execute dataimport
commands if they come
use the built-in software
firewall of Linux/Windows/Whatever or use some other FW utility is a choice
you need to make. This is by design - you should never ever expose your
backend services, whether it's a search server or a database server, to the
public.
Read more about Solr security
Hi all,
Is it possible to set up solr so that it will only execute dataimport
commands if they come from localhost?
Right now, my application and my solr installation are on different servers
so any requests are formatted http://domain:8983 instead of
http://localhost:8983. I am concerned that
Solr does not provide security (I believe Lucid EnterpriseWorks has
something there).
You should keep Solr itself secure behind a firewall, and pass all
requests through some intermediary that only allows sensible stuff
through to Solr itself. That way, the DataImportHandler is accessible
inside
backend services,
whether it's a search server or a database server, to the public.
Read more about Solr security on the WIKI:
http://wiki.apache.org/solr/SolrSecurity
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
On 9. mai 2011, at 20.57, Brian Lamb wrote:
Hi all
. feb. 2010, at 14.07, Vijayant Kumar wrote:
Hi Xavier,
Thanks for your feedback
the firewall rule for the trusted IP is not fessiable for us because the
application is open for public so we can not work through IP banning.
Vijayant Kumar wrote:
Hi Group,
I need some feedback on solr
Hi Group,
I need some feedback on solr security.
For Making by solr admin password protected,
I had used the Path Based Authentication form
http://wiki.apache.org/solr/SolrSecurity.
In this way my admin area,search,delete,add to index is protected.But Now
when I make solr authenticated
Vijayant Kumar wrote:
Hi Group,
I need some feedback on solr security.
For Making by solr admin password protected,
I had used the Path Based Authentication form
http://wiki.apache.org/solr/SolrSecurity.
In this way my admin area,search,delete,add to index is protected.But Now
when I make
Hi Xavier,
Thanks for your feedback
the firewall rule for the trusted IP is not fessiable for us because the
application is open for public so we can not work through IP banning.
Vijayant Kumar wrote:
Hi Group,
I need some feedback on solr security.
For Making by solr admin password
Vijayant Kumar wrote:
Hi Xavier,
Thanks for your feedback
the firewall rule for the trusted IP is not fessiable for us because the
application is open for public so we can not work through IP banning.
Vijayant Kumar wrote:
Hi Group,
I need some feedback on solr security.
For Making
Xavier Schepler wrote:
Vijayant Kumar wrote:
Hi Xavier,
Thanks for your feedback
the firewall rule for the trusted IP is not fessiable for us because the
application is open for public so we can not work through IP banning.
Vijayant Kumar wrote:
Hi Group,
I need some feedback on solr
You could set a firewall that forbid any connection to your Solr's
server port to everyone, except the computer that host your application
that connect to Solr.
So, only your application will be able to connect to Solr.
I believe firewalling is the only possible solution since SOLR doesn't
For Making by solr admin password protected,
I had used the Path Based Authentication form
http://wiki.apache.org/solr/SolrSecurity.
In this way my admin area,search,delete,add to index is protected.But
Now
when I make solr authenticated then for every update/delete from the
fornt
end is
On Wed, 17 Feb 2010 10:13:46 -0400
Fuad Efendi f...@efendi.ca wrote:
You could set a firewall that forbid any connection to your
Solr's server port to everyone, except the computer that host
your application that connect to Solr.
So, only your application will be able to connect to Solr.
Have anyone had an experience to setup the Solr Security?
http://wiki.apache.org/solr/SolrSecurity
I would like to implement using HTTP Authentication or using Path Based
Authentication.
So, in the webdefault.xml I set like the following:
security-constraint
web-resource-collection
On Nov 16, 2008, at 6:12 PM, Ian Holsman wrote:
famous last words and all, but you shouldn't be just passing what a
user types directly into a application should you?
LOL
I'd be parsing out wildcards, boosts, and fuzzy searches (or at
least thinking about the effects).
I mean jakarta
On Nov 16, 2008, at 6:18 PM, Ryan McKinley wrote:
my assumption with solrjs is that you are hitting read-only solr
servers that you don't mind if people query directly.
Exactly the assumption I'm going with too.
It would not be appropriate for something where you don't want
people (who
On Nov 16, 2008, at 6:27 PM, Ryan McKinley wrote:
I'd be parsing out wildcards, boosts, and fuzzy searches (or at
least thinking about the effects).
I mean jakarta apache~1000 or roam~0.1 aren't as efficient as a
regular query.
Even if you leave the solr instance public, you can still
On Nov 16, 2008, at 6:55 PM, Walter Underwood wrote:
Limiting the maximum number of rows doesn't work, because
they can request rows 2-20100. --wunder
But you could limit how many rows could be returned in a single
request... that'd close off one DoS mechanism.
Erik
On Mon, Nov 17, 2008 at 8:54 AM, Erik Hatcher
[EMAIL PROTECTED] wrote:
Sounds like the perfect case for a query parser plugin... or use dismax as
Ryan mentioned. Shouldn't Solr be hardened for these cases anyway? Or at
least hardenable.
Say you do filtering by user - how would you enforce
On Nov 17, 2008, at 9:07 AM, Yonik Seeley wrote:
On Mon, Nov 17, 2008 at 8:54 AM, Erik Hatcher
[EMAIL PROTECTED] wrote:
Sounds like the perfect case for a query parser plugin... or use
dismax as
Ryan mentioned. Shouldn't Solr be hardened for these cases
anyway? Or at
least hardenable.
Erik Hatcher schrieb:
On Nov 16, 2008, at 6:18 PM, Ryan McKinley wrote:
my assumption with solrjs is that you are hitting read-only solr
servers that you don't mind if people query directly.
Exactly the assumption I'm going with too.
It would not be appropriate for something where you
Limiting the number of rows only handles one attack. The one I mentioned,
fetching one page deep in the result set, caused a big issue on prod at
our site. We needed to limit the max for start as well as rows.
It is possible to make it safe, but a lot of work. We did this for
Ultraseek. I would
On Nov 17, 2008, at 10:22 AM, Walter Underwood wrote:
It is possible to make it safe, but a lot of work. We did this for
Ultraseek. I would always, always front it with Apache, to get some
of Apache's protection.
What protections specifically are you speaking of with Apache in
front?
Say you do filtering by user - how would you enforce that the client
(if it's a browser) only send in the proper filter?
Ryan already mentioned his technique... and here's how I'd do it
similarly...
Write a custom servlet Filter that grokked roles/authentication
(this piece you'd need
Ryan McKinley wrote:
solr.jar on the other hand lets you package what you want around
search features to build a setup for your needs. Java already has so
many options for how to secure / authenticate that you can just plug
them into your own app. (if that is appropriate). In the past I
Ryan McKinley schrieb:
however I have found that in any site where
stability/load and uptime are a serious concern, this is better handled
in a tier in front of java -- typically the loadbalancer / haproxy /
whatever -- and managed by people more cautious then me.
Full ack. What do you think
PROTECTED]
Sent: Monday, November 17, 2008 9:07 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr security
Ryan McKinley schrieb:
however I have found that in any site where
stability/load and uptime are a serious concern, this is better
handled
in a tier in front of java -- typically
On Nov 17, 2008, at 12:06 PM, Matthias Epheser wrote:
Ryan McKinley schrieb:
however I have found that in any site where
stability/load and uptime are a serious concern, this is better
handled in a tier in front of java -- typically the loadbalancer /
haproxy / whatever -- and managed by
Subject: Re: Solr security
Ryan McKinley schrieb:
however I have found that in any site where
stability/load and uptime are a serious concern, this is better
handled
in a tier in front of java -- typically the loadbalancer / haproxy /
whatever -- and managed by people more cautious
-Original Message-
From: Matthias Epheser [mailto:[EMAIL PROTECTED] Sent: Monday,
November 17, 2008 9:07 AM
To: solr-user@lucene.apache.org
Subject: Re: Solr security
Ryan McKinley schrieb:
however I have found that in any site where
stability/load and uptime are a serious concern
About that read-only switch for Solr: one of the basic HTTP design
guidelines is that GET should only return values, and should never change
the state of the data. All changes to the data should be made with POST. (In
REST style guidelines, PUT, POST, and DELETE.) This prevents you from
passing
I believe the Solr replication scripts require POSTing a commit to read
in the new index--so at least limited POST capability is required in
most scenarios.
-Sean
Lance Norskog wrote:
About that read-only switch for Solr: one of the basic HTTP design
guidelines is that GET should only return
if thats the case putting apache in front of it would be handy.
something like
limit POST
order deny,allow
deny from all
allow from 192.168.0.1
/limit
might be helpful.
Sean Timm wrote:
I believe the Solr replication scripts require POSTing a commit to
read in the new index--so at least
trouble is, you can also GET /solr/update, even all on the URL, no
request body...
http://localhost:8983/solr/update?stream.body=%3Cadd%3E%3Cdoc%3E%3Cfield%20name=%22id%22%3ESTREAMED%3C/field%3E%3C/doc%3E%3C/add%3Ecommit=true
Solr is a bad RESTafarian.
Getting warmer!
Erik
On Nov 17, 2008, at 4:20 PM, Erik Hatcher wrote:
trouble is, you can also GET /solr/update, even all on the URL, no
request body...
http://localhost:8983/solr/update?stream.body=%3Cadd%3E%3Cdoc%3E%3Cfield%20name=%22id%22%3ESTREAMED%3C/field%3E%3C/doc%3E%3C/add%3Ecommit=true
Solr is a
Ryan McKinley wrote:
On Nov 17, 2008, at 4:20 PM, Erik Hatcher wrote:
trouble is, you can also GET /solr/update, even all on the URL, no
request body...
If the user is using the new java Solr replication then he can get rid
of the /update and /update/csv handlers altogether. So the slaves are
completely read-only
--Noble
On Tue, Nov 18, 2008 at 2:14 AM, Sean Timm [EMAIL PROTECTED] wrote:
I believe the Solr replication scripts require POSTing a
: Full ack. What do you think about the only solr related thing left, the
: paramter filtering/blocking (eg. rows1000). Is this suitable to do it in a
: Filter delivered by solr? Of course as an optional alternative.
: As eric mentioned earlier, this could be done in a QueryComponent -- the
:
I'm pondering the viability of running Solr as effectively a UI
server... what I mean by that is having a public facing browser-based
application hitting a Solr backend directly for JSON, XML, etc data.
I know folks are doing this (I won't name names, in case this thread
comes up with any
Erik Hatcher wrote:
I'm pondering the viability of running Solr as effectively a UI
server... what I mean by that is having a public facing browser-based
application hitting a Solr backend directly for JSON, XML, etc data.
I know folks are doing this (I won't name names, in case this thread
On Nov 16, 2008, at 5:41 PM, Ian Holsman wrote:
First thing I would look at is disabling write access, or writing a
servlet that sits on top of the write handler to filter your data.
We can turn off all the update handlers, but how does that affect
replication? Can a Solr replicant be
I'm not totally sure what you are suggesting. Is there a general way
people deal with security and search?
I'm assuming we already have good ways (better ways) to make sure
people are authorized/logged in etc. What do you imagine solr
security would add?
FYI, I used to have a custom
Plus, it's just too big a can of worms for solr to handle. You could
protect up to a small point, but a real ddos attack is not going to be
defended against by solr. At best we could put in 'kiddie' protection
against.
- Mark
On Nov 16, 2008, at 5:51 PM, Erik Hatcher [EMAIL PROTECTED]
. Is there a general
way people deal with security and search?
I'm assuming we already have good ways (better ways) to make sure
people are authorized/logged in etc. What do you imagine solr
security would add?
FYI, I used to have a custom RequstHandler that got the user
principal from
Erik Hatcher wrote:
On Nov 16, 2008, at 5:41 PM, Ian Holsman wrote:
First thing I would look at is disabling write access, or writing a
servlet that sits on top of the write handler to filter your data.
We can turn off all the update handlers, but how does that affect
replication? Can a
Agreed, it is pretty easy to create a large variety of denial
of service attacks with sorts, wildcards, requesting a large
number of results, or a page deep in the results.
We have protected against several different DoS problems
in our front-end code.
wunder
On 11/16/08 3:12 PM, Ian Holsman
in etc. What do you imagine solr
security would add?
FYI, I used to have a custom RequstHandler that got the user
principal from the HttpServletRequest (I have a custom
SolrDispatchFilter that adds that to the context) and then augments
the query with a filter that limits to stuff that user
I'd be parsing out wildcards, boosts, and fuzzy searches (or at
least thinking about the effects).
I mean jakarta apache~1000 or roam~0.1 aren't as efficient as a
regular query.
Even if you leave the solr instance public, you can still limit
grossly inefficent params by forcing things
Limiting the maximum number of rows doesn't work, because
they can request rows 2-20100. --wunder
On 11/16/08 3:27 PM, Ryan McKinley [EMAIL PROTECTED] wrote:
I'd be parsing out wildcards, boosts, and fuzzy searches (or at
least thinking about the effects).
I mean jakarta apache~1000 or
If you have a master slave configuration I guess it is a good idea to
remove the updatehandler altogether from slaves.
--Noble
On Sat, Jun 28, 2008 at 2:39 AM, Chris Hostetter
[EMAIL PROTECTED] wrote:
: A basic technique that can be used to mitigate the risk of a possible CSRF
: attack like
SOLR-607 is still open.Till it is committed this solution may not be poossible
--Noble
On Mon, Jun 30, 2008 at 10:23 AM, Noble Paul നോബിള് नोब्ळ्
[EMAIL PROTECTED] wrote:
If you have a master slave configuration I guess it is a good idea to
remove the updatehandler altogether from slaves.
On Fri, Jun 27, 2008 at 1:54 AM, Chris Hostetter
[EMAIL PROTECTED] wrote:
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
Solr isn't normally concerned with Security related issues...
http://wiki.apache.org/solr/SolrSecurity
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
91 matches
Mail list logo
