Re: iptablex trojan experiences?
probably related http://bouk.co/blog/elasticsearch-rce/ -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b6207d97-8baa-4c27-9ecd-7da9933503ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
On 04 juin 2014, at 05:38, 'Adolfo Rodriguez' via elasticsearch wrote: here is some sample code on how to exploit the system for version 1.2.0, port 9200 exposed to internet and flag setting script.disable_dynamic=false as is by default http://bouk.co/blog/elasticsearch-rce/#how_to_secure_against_this_vulnerability I've had a great deal of fun reading this. And I'm really concerned that in 2014 people are still developing products like ES with absolutely no security features. This blogger should have added a word of warning about running ES as root/admin, I'm pretty sure most developers are running ES with their admin account, or even with root. Use a dedicated user account for the ES process, with very limited permissions and powers. Always think about privilege separation before you install a new software. ES should really be quarantined. On FreeBSD, one can use a jail (very easy nowadays with ZFS and ezjail). I'm pretty sure similar things exist for Linux. If you have the guts, go with SELinux. Requires some work, but it's rewarding and it has some pretty dam' cool things inside. Patrick -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/8C53A03A-BBB9-4450-86CF-562BC1E45CD1%40patpro.net. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
This is exactly the kind of things I was planning for my next deployment: a jail and finer permission tuning (besides closing the port and changing flag configuration). Exactly I was running ES libraries as root embedded in a Tomcat app. However, I think software should fit for purpose and delegate security in other specialized programs. Making the specific warnings, this policy looks ok to me. -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/d92b6677-35a3-4fec-b19f-813e854fce86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
* ES with absolutely no security features* *However, I think software should fit for purpose and delegate security in other specialized programs.* just to clarify, I think there is not need of any additional security modules but, I agree that, any configuration option must be safe by default. And if any additional module is provided, make it optional to prevent unnecessary burden -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
One very essential feature, from the very beginning, is that Elasticsearch instances, when started, automatically form a cluster over the network. This is only possible in an open network environment and by having multicast enabled. Are you aware, that by talking about safe configuration options by default, you no longer can expect Elasticsearch to form a cluster? And that others would have to suffer from that? If you want security, you can not do this simply by adding security modules or by safe configuration options: it's always the responsibility and the awareness of the admin in person to run and maintain the software in a protected environment. It is just ridiculous to read that running applications under superuser privileges and allowing world-wide access over the internet to a host with user applications need safe configuration options by default and unnecessary burden must be prevented. This is open source. Use the power of it. But do not blame others for your personal mistakes. Jörg On Wed, Jun 4, 2014 at 11:34 AM, 'Adolfo Rodriguez' via elasticsearch elasticsearch@googlegroups.com wrote: * ES with absolutely no security features* *However, I think software should fit for purpose and delegate security in other specialized programs.* just to clarify, I think there is not need of any additional security modules but, I agree that, any configuration option must be safe by default. And if any additional module is provided, make it optional to prevent unnecessary burden -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHhDcwQxuhMpjO%2BX0sGe9wkmRRhkqQDwWo5nZ-WWvh_-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
Containers, or VMs are also a valid approach to limiting access and potential breaches. Like all security, it's a multi-layered approach. Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: ma...@campaignmonitor.com web: www.campaignmonitor.com On 4 June 2014 19:57, joergpra...@gmail.com joergpra...@gmail.com wrote: One very essential feature, from the very beginning, is that Elasticsearch instances, when started, automatically form a cluster over the network. This is only possible in an open network environment and by having multicast enabled. Are you aware, that by talking about safe configuration options by default, you no longer can expect Elasticsearch to form a cluster? And that others would have to suffer from that? If you want security, you can not do this simply by adding security modules or by safe configuration options: it's always the responsibility and the awareness of the admin in person to run and maintain the software in a protected environment. It is just ridiculous to read that running applications under superuser privileges and allowing world-wide access over the internet to a host with user applications need safe configuration options by default and unnecessary burden must be prevented. This is open source. Use the power of it. But do not blame others for your personal mistakes. Jörg On Wed, Jun 4, 2014 at 11:34 AM, 'Adolfo Rodriguez' via elasticsearch elasticsearch@googlegroups.com wrote: * ES with absolutely no security features* *However, I think software should fit for purpose and delegate security in other specialized programs.* just to clarify, I think there is not need of any additional security modules but, I agree that, any configuration option must be safe by default. And if any additional module is provided, make it optional to prevent unnecessary burden -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com https://groups.google.com/d/msgid/elasticsearch/79a862e2-713b-4c05-821f-70f505a6ee60%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHhDcwQxuhMpjO%2BX0sGe9wkmRRhkqQDwWo5nZ-WWvh_-A%40mail.gmail.com https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHhDcwQxuhMpjO%2BX0sGe9wkmRRhkqQDwWo5nZ-WWvh_-A%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624YjRikoQ4xdo05X1LNy3BSAiRbUmL1Mg5xw3qQTZJ%2Bcwg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
sorry if you took the message personally. Is your problem, not mine. I was not attacking you at all, rather saying that, in my opinion, software should fit for purpose and either prevent (when feasible) or warn about possible security holes. Just that. But not building additional security features beyond purpose (as I understood Richard was suggesting). So, basically the same that you are stating. It is just ridiculous to read that running applications under superuser privileges and allowing world-wide access over the internet to a host with user applications need safe configuration options by default and unnecessary burden must be prevented. well, is ridiculous if you are google and have 2000 employees to create a couple of servlets. But if you have limited resources, and you are paying attention to other functionalities and working on beta, is not ridiculous. Is an assumed and controlled risk. But do not blame others for your personal mistakes. Can you please show me where I did that? I totally agree what you did here https://github.com/elasticsearch/elasticsearch/issues/5853. No more question here. Sorry, you have blamed yourself, I did not. -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/a72a0161-91c5-47b3-a989-7dd8548f996a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
iptablex trojan experiences?
Hi, I had a couple of exploits in the last 2 weeks in my CentOS 5.7 with a trojan iptablex. Apparently it does a DDoS and, after, opens connections somewhere else. There are reported cases of connections open to someone at China Telecom. If you look processes in your server, you will find something as: root 4252 632 0 18:44 ? 00:00:00 /boot/.IptabLex root 4260 624 0 18:45 ? 00:00:00 /boot/.IptabLes This is the second time happening to me and in both cases root is compromised so it requires a full server reinstall. In the first case, I though the problem could come from Tomcat 7 which is having quite a few vulnerabilities last months (http://tomcat.apache.org/security-7.html) so I upgraded to Tomcat 8.0.8, latest release. However, problem reproduced again after fully reinstalling the server. In this second time I have found that ports 9200 and 9300 are open in my VPS by my hosting provider and I found some other cases of iptablex trojan attacking machines though Elastic Search ports. I know, they should not be open. You can find an increasingly number of reported cases on internet pointing to ES (and also Tomcat/struts) http://nerdanswer.com/answer.php?q=524925 http://security.stackexchange.com/questions/58862/logging-server-compromised-iptables-and-iptablex So, has any other user in this group experienced the same? -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f96fa6c7-a722-4bc3-9a4e-84385ceb11ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
There has been a few comments in IRC about similar things happening, all due to ports 9200 and/or 9300 being open to the internet. However, as you mentioned, you really shouldn't have ES directly accessible to the outside world Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: ma...@campaignmonitor.com web: www.campaignmonitor.com On 4 June 2014 05:38, 'Adolfo Rodriguez' via elasticsearch elasticsearch@googlegroups.com wrote: Hi, I had a couple of exploits in the last 2 weeks in my CentOS 5.7 with a trojan iptablex. Apparently it does a DDoS and, after, opens connections somewhere else. There are reported cases of connections open to someone at China Telecom. If you look processes in your server, you will find something as: root 4252 632 0 18:44 ? 00:00:00 /boot/.IptabLex root 4260 624 0 18:45 ? 00:00:00 /boot/.IptabLes This is the second time happening to me and in both cases root is compromised so it requires a full server reinstall. In the first case, I though the problem could come from Tomcat 7 which is having quite a few vulnerabilities last months (http://tomcat.apache.org/security-7.html) so I upgraded to Tomcat 8.0.8, latest release. However, problem reproduced again after fully reinstalling the server. In this second time I have found that ports 9200 and 9300 are open in my VPS by my hosting provider and I found some other cases of iptablex trojan attacking machines though Elastic Search ports. I know, they should not be open. You can find an increasingly number of reported cases on internet pointing to ES (and also Tomcat/struts) http://nerdanswer.com/answer.php?q=524925 http://security.stackexchange.com/questions/58862/logging-server-compromised-iptables-and-iptablex So, has any other user in this group experienced the same? -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/f96fa6c7-a722-4bc3-9a4e-84385ceb11ac%40googlegroups.com https://groups.google.com/d/msgid/elasticsearch/f96fa6c7-a722-4bc3-9a4e-84385ceb11ac%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624aU%3DGZ6fH3fUVuD4eo5g%2BsFVFuCUTKeWhP4AYRA8Pd%3D0A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
i was using release *elasticsearch-0.90.5* in my exploited server, so maybe this is already fixed in current release by disabling script.disable_dynamic by default https://github.com/elasticsearch/elasticsearch/issues/5853 (besides not exposing port 9200 outside) -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3772e3b3-9b82-4018-8468-392ee2f1c4b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: iptablex trojan experiences?
On Tue, Jun 3, 2014 at 3:33 PM, 'Adolfo Rodriguez' via elasticsearch elasticsearch@googlegroups.com wrote: i was using release elasticsearch-0.90.5 in my exploited server, so maybe this is already fixed in current release by disabling script.disable_dynamic by default I got caught by this a week ago using 1.1.0 on Ubuntu 12.04. Had not even thought about a high port like 9200 being open by default. (And no, there's no Tomcat or Struts app on that box.) Luckily NewRelic tipped me off right away and I was able to put it into rescue mode while I provisioned a new server. One more item for the checklist :-) -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan -- 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 elasticsearch+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CACmC4yC%3D24X-0OBT3weju9s_9v--RJ4yLBahPn6dSuKwBho2ig%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
