I poked around in the code and the only code place I fine "You Know, for
Search" is
There doesn't appear to be an explicit flag that would allow me to suppress
that, but perhaps that's somewhere else? My IT folks are in a tizzy that
version information is being displayed, saying it's a major security risk.
Sigh.
Honestly, if it doesn't break something else, I wouldn't mind if there was
just a way to turn off that default response entirely. That'd do it too.
On Thursday, December 19, 2013 12:50:29 PM UTC-8, Ivan Brusic wrote:
From what I can tell from the code, it appears that you can disable
returning the version field.
--
Ivan
On Thu, Dec 19, 2013 at 12:27 PM, Josh Harrison <hij...@gmail.com<javascript:>
wrote:
The subject says it all pretty much, is it possible to turn off the
reporting of version data in response to GET http://localhost:9200?
Thanks,
Josh
Just having the REST endpoint open is a security risk. You can always
put a proxy in front of elasticsearch that intercepts certain calls such as
PUT, POST, DELETE or simply / in your case.
Normally in elasticsearch, a request is built with various parameters via a
builder and then the resulting response will have the correct fields. You
can see an example with the nodes stats:
The main action does not really have specific request/response classes. You
can try raising an issue or even submitting a pull request yourself, but I
do not see this issue as being very important. That is just my guess.
--
Ivan
On Thu, Dec 19, 2013 at 2:52 PM, Josh Harrison hijakk@gmail.com wrote:
On Thursday, December 19, 2013 12:50:29 PM UTC-8, Ivan Brusic wrote:
From what I can tell from the code, it appears that you can disable
returning the version field.
--
Ivan
On Thu, Dec 19, 2013 at 12:27 PM, Josh Harrison hij...@gmail.com wrote:
The subject says it all pretty much, is it possible to turn off the
reporting of version data in response to GET http://localhost:9200?
Thanks,
Josh
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
Yeah, it's been looking like a proxy is the way to go. If it was an already
existing functionality allowing me to suppress the version info from /, I'd
have been happy to use that, but I agree - it isn't worth anyone's time to
add this.
Thanks Ivan!
-Josh
On Thursday, December 19, 2013 3:04:15 PM UTC-8, Ivan Brusic wrote:
Just having the REST endpoint open is a security risk. You can always
put a proxy in front of elasticsearch that intercepts certain calls such as
PUT, POST, DELETE or simply / in your case.
Normally in elasticsearch, a request is built with various parameters via
a builder and then the resulting response will have the correct fields. You
can see an example with the nodes stats:
The main action does not really have specific request/response classes.
You can try raising an issue or even submitting a pull request yourself,
but I do not see this issue as being very important. That is just my guess.
--
Ivan
On Thu, Dec 19, 2013 at 2:52 PM, Josh Harrison <hij...@gmail.com<javascript:>
On Thursday, December 19, 2013 12:50:29 PM UTC-8, Ivan Brusic wrote:
From what I can tell from the code, it appears that you can disable
returning the version field.
--
Ivan
On Thu, Dec 19, 2013 at 12:27 PM, Josh Harrison hij...@gmail.comwrote:
The subject says it all pretty much, is it possible to turn off the
reporting of version data in response to GET http://localhost:9200?
Thanks,
Josh
--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.
Can you explain why showing the prompt is a problem?
Maybe it helps us to understand if it is a common use case and a patch for
the codebase would be appropriate.
As for the proxy, it is recommended to not expose ES to HTTP frontend
access, so a proxy is the best method I know. ES can be well hidden in a
private network like 10.0.0.0 or 192.168.0.0 - also there are a few
dangerous commands, and HTTP methods like DELETE to take care of. These are
open by default for maximum convenience, for admins with curl at hand, and
must be protected against malevolent access, if you set up ES in a hostile
environment.
They're worried that giving the exact version info of both ES and Lucene makes it easier should a threat already internally on the network attempt to compromise the system. At least I think that's the concern.
On Dec 20, 2013, at 12:16 AM, "joergprante@gmail.com" joergprante@gmail.com wrote:
Can you explain why showing the prompt is a problem?
Maybe it helps us to understand if it is a common use case and a patch for the codebase would be appropriate.
As for the proxy, it is recommended to not expose ES to HTTP frontend access, so a proxy is the best method I know. ES can be well hidden in a private network like 10.0.0.0 or 192.168.0.0 - also there are a few dangerous commands, and HTTP methods like DELETE to take care of. These are open by default for maximum convenience, for admins with curl at hand, and must be protected against malevolent access, if you set up ES in a hostile environment.
I understand. There are many methods of compromising a system. For example,
blast random loads of bytes to open ports, until the process on the server
dies. Or syn floods. DoS attacks are possible, as long as a port is open,
like 9200. But there is also 9300.
There are firewalls or other network setups that can protect backend apps
from intruders and DoS attacks.
As said, just hide all ES nodes from public network access, or ramp up
firewalls settings. Changing the ES environment is the primary solution. Do
not fight symptoms, fight the cause.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.