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
Indeed it is - but you'll also need mod_proxy (just rewriting will not be
sufficient).
On Tue, Jan 7, 2014 at 3:42 AM, Otis Gospodnetic otis.gospodne...@gmail.com
wrote:
Apache url_rewrite can help with this and it's only a few minutes to set
up.
Otis
--
Performance Monitoring * Log
I think generally it might be true that it's too difficult for an admin
without very specific knowledge of Solr internals to utilize simple URL
rewriting to prevent exploits. To show what I mean, here's a story where
someone was able to exploit a Solr server through a custom webapp, which in
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
Apache url_rewrite can help with this and it's only a few minutes to set up.
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr Elasticsearch Support * http://sematext.com/
On Mon, Jan 6, 2014 at 12:55 PM, Developer bbar...@gmail.com wrote:
Hi,
We are currently showing
Hi Aaron,
Are you talking about Securing Lucene Index ?
If so You can try using https://code.google.com/p/lucenetransform/.
Thanks and Regards
Vignesh Srinivasan
9739135640
On Mon, Jun 24, 2013 at 11:21 AM, Aaron Greenspan
aar...@thinkcomputer.comwrote:
Hi,
Some more unsolicited feedback
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
http://lmgtfy.com/?q=jetty+access+control
wunder
On Jun 23, 2013, at 10:51 PM, Aaron Greenspan wrote:
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
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
Aaron, if public access is needed, most people just need to query Solr, not
update it. We tend to do this with reverse proxies. With a proxy you can
whitelist with the request handler and query params that are visible to the
outside world. You can use invariants to restrict many things even
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
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 and choose
carefully what to let through and not.
--
Jan Høydahl, search
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
Instead of hitting the Solr server directly from the client, I think I would go
through your application server, which would have access to all the users data
and can forward that to the Solr server, thereby hiding it from the client.
Mike
-Original Message-
From: Anupam Bhattacharya
Yes, I agree with you.
But Ajax-SOLR Framework doesn't fit in that manner. Any alternative
solution ?
Anupam
On Fri, May 11, 2012 at 9:41 AM, Klostermeyer, Michael
mklosterme...@riskexchange.com wrote:
Instead of hitting the Solr server directly from the client, I think I
would go through
The WIKI has a loose interpretation of how to set-up Jetty securely.
Please take a look at the article I wrote here:
http://anthonyw.net/2011/04/securing-jetty-and-solr-with-php-authentication/.
Even if PHP is not your language that sits on top of Solr you can still
use the first part of
Great posts all. I will give these a look and come up with something based
on these recommendations. I'm sure as I begin implementing something, I will
have more questions arise.
On Tue, May 10, 2011 at 9:00 AM, Anthony Wlodarski
anth...@tinkertownlabs.com wrote:
The WIKI has a loose
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
Hi,
You can simply configure a firewall on your Solr server to only allow access
from your frontend server. Whether you 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
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
:
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]
What about SolrJS? Isn't it designed to hit a Solr directly? (Sure,
as long as the response looked like Solr response, it could have come
through some magic 'security' tier).
Erik
On Nov 16, 2008, at 5:54 PM, Ryan McKinley wrote:
I'm not totally sure what you are suggesting. Is
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
my assumption with solrjs is that you are hitting read-only solr
servers that you don't mind if people query directly. It would not be
appropriate for something where you don't want people (who really
care) to know you are running solr and could execute arbitrary queries.
Since it is an
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
61 matches
Mail list logo
