# Can plugin be written for TCP transport? **URL:** \ **Category:** Elasticsearch\ **Created:** [August 13, 2014, 1:38pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257 "2014-08-13T13:38:20Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![javadevmtl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javadevmtl/32/45613_2.png) [@javadevmtl](https://discuss.elastic.co/u/javadevmtl)\ **Post date:** [August 13, 2014, 1:38pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/1 "2014-08-13T13:38:20Z")
Hi I have been looking at the various transport plugins. Correct me if I am wrong but those are for the http rest interface... Can plugins be written for the node transport? Bassically this leads to securing ES. My ES is definitely not public and I know i can use reverse proxies or one of the http plugins... But what about client/programs connecting directly as nodes? Bassically I need user auth and some form of acl. SSL is secondary. Also need to be able to audit the user access. Dealing with credit card data. So I need to know 100% who is accessing the data. So... What are some good steps to secure my ES cluster!? -- 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [August 13, 2014, 1:50pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/2 "2014-08-13T13:50:14Z")
You can write a Java app to authorize access with JAAS and use a SOCKS proxy to connect to an ES cluster in a private subnet. That is all a matter of network configuration, there is nothing that requires the effort of an extra ES plugin. Jörg On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.dev.mtl@gmail.com](mailto:java.dev.mtl@gmail.com) wrote: > Hi I have been looking at the various transport plugins. Correct me if I > am wrong but those are for the http rest interface... Can plugins be > written for the node transport? > > Bassically this leads to securing ES. My ES is definitely not public and I > know i can use reverse proxies or one of the http plugins... But what about > client/programs connecting directly as nodes? > > Bassically I need user auth and some form of acl. SSL is secondary. Also > need to be able to audit the user access. Dealing with credit card data. So > I need to know 100% who is accessing the data. > > So... > What are some good steps to secure my ES cluster!? > > -- > 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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > To view this discussion on the web visit > [https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com) > . > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoF4QuX1OjHeiUOe-7VScPAGvjwB0MTWZnD6SE4nLCBS4g%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoF4QuX1OjHeiUOe-7VScPAGvjwB0MTWZnD6SE4nLCBS4g%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![javadevmtl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javadevmtl/32/45613_2.png) [@javadevmtl](https://discuss.elastic.co/u/javadevmtl)\ **Post date:** [August 13, 2014, 3:07pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/3 "2014-08-13T15:07:45Z")
That's what I was thinking... 1- I would like this java app to use the node client, cause I like that fact that there no extra hop and automatic failover to next node. 2- I figure it would be a firewall setting/socks to only allow the java app to connect to ES. But again here anyone can go create a node client on the same machine and pull data anonymously. I know any one person can log in a machine at any time and any person can read regardless and it's ok, the data is supposed to be read but at least you know who read it and when. That's not an issue... Security is a best effort, but the issue is the audit process and how well you can check if all your eggs are there. Even if I do exactly as you said, subnet plus socks proxy, someone can still go to that machine create their own node client and bypass the java app with no direct trace. This will probably never happen, but all it takes is one angry employ. On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > You can write a Java app to authorize access with JAAS and use a SOCKS > proxy to connect to an ES cluster in a private subnet. That is all a matter > of network configuration, there is nothing that requires the effort of an > extra ES plugin. > > Jörg > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith \<[java.d...@gmail.com](mailto:java.d...@gmail.com) > \\> wrote: > > > Hi I have been looking at the various transport plugins. Correct me if I > > am wrong but those are for the http rest interface... Can plugins be > > written for the node transport? > > > > Bassically this leads to securing ES. My ES is definitely not public and > > I know i can use reverse proxies or one of the http plugins... But what > > about client/programs connecting directly as nodes? > > > > Bassically I need user auth and some form of acl. SSL is secondary. Also > > need to be able to audit the user access. Dealing with credit card data. So > > I need to know 100% who is accessing the data. > > > > So... > > What are some good steps to secure my ES cluster!? > > > > -- > > 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](mailto:elasticsearc...@googlegroups.com) \. > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com) > > . > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![javadevmtl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javadevmtl/32/45613_2.png) [@javadevmtl](https://discuss.elastic.co/u/javadevmtl)\ **Post date:** [August 13, 2014, 4:34pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/4 "2014-08-13T16:34:06Z")
It would be cool if we could use something like Jetty plugin and disable client access from the TCP node and only use the TCP node for cluster related work. On Wednesday, 13 August 2014 11:07:45 UTC-4, John Smith wrote: > That's what I was thinking... > > 1- I would like this java app to use the node client, cause I like that > fact that there no extra hop and automatic failover to next node. > 2- I figure it would be a firewall setting/socks to only allow the java > app to connect to ES. But again here anyone can go create a node client on > the same machine and pull data anonymously. > > I know any one person can log in a machine at any time and any person can > read regardless and it's ok, the data is supposed to be read but at least > you know who read it and when. That's not an issue... Security is a best > effort, but the issue is the audit process and how well you can check if > all your eggs are there. > > Even if I do exactly as you said, subnet plus socks proxy, someone can > still go to that machine create their own node client and bypass the java > app with no direct trace. This will probably never happen, but all it takes > is one angry employ. > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > You can write a Java app to authorize access with JAAS and use a SOCKS > > proxy to connect to an ES cluster in a private subnet. That is all a matter > > of network configuration, there is nothing that requires the effort of an > > extra ES plugin. > > > > Jörg > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) wrote: > > > > > Hi I have been looking at the various transport plugins. Correct me if I > > > am wrong but those are for the http rest interface... Can plugins be > > > written for the node transport? > > > > > > Bassically this leads to securing ES. My ES is definitely not public and > > > I know i can use reverse proxies or one of the http plugins... But what > > > about client/programs connecting directly as nodes? > > > > > > Bassically I need user auth and some form of acl. SSL is secondary. Also > > > need to be able to audit the user access. Dealing with credit card data. So > > > I need to know 100% who is accessing the data. > > > > > > So... > > > What are some good steps to secure my ES cluster!? > > > > > > -- > > > 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](mailto:elasticsearc...@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40googlegroups.com) > > > . > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/c7a7d241-575e-480c-afe9-e2ef69043160%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/c7a7d241-575e-480c-afe9-e2ef69043160%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [August 13, 2014, 6:20pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/5 "2014-08-13T18:20:53Z")
With the configuration settings "transport.type" and "transport.service.type" Example: transport.type: org.xbib.elasticsearch.transport.syslog.netty.SyslogNettyTransportModule transport.service.type: org.xbib.elasticsearch.transport.syslog.SyslogTransportService you can implement your own transport layer. With this mechanism you can write plugins to create an audit trail of all clients or nodes that connect to your cluster and you can log what they did, for later revision. Or, you can add a registry for clients, add JAAS, ... For example, I played with a modified netty transport layer to dump all parsed transport actions between nodes to a remote host syslog, including the action names and the channel connection information of local and remote host/port. On such a custom transport layer implementation, you can add even more low level logic. If you do not want certain nodes or clients to connect, you could a) use zen unicast for manual configuration of permitted nodes or clients and/or b) reject all network actions from unknown/unregistered clients, independent of discovery. Note, manipulating transport layer is not free lunch and is not always fun. Performance may degrade, other things may break etc. Jörg On Wed, Aug 13, 2014 at 5:07 PM, John Smith [java.dev.mtl@gmail.com](mailto:java.dev.mtl@gmail.com) wrote: > That's what I was thinking... > > 1- I would like this java app to use the node client, cause I like that > fact that there no extra hop and automatic failover to next node. > 2- I figure it would be a firewall setting/socks to only allow the java > app to connect to ES. But again here anyone can go create a node client on > the same machine and pull data anonymously. > > I know any one person can log in a machine at any time and any person can > read regardless and it's ok, the data is supposed to be read but at least > you know who read it and when. That's not an issue... Security is a best > effort, but the issue is the audit process and how well you can check if > all your eggs are there. > > Even if I do exactly as you said, subnet plus socks proxy, someone can > still go to that machine create their own node client and bypass the java > app with no direct trace. This will probably never happen, but all it takes > is one angry employ. > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > You can write a Java app to authorize access with JAAS and use a SOCKS > > proxy to connect to an ES cluster in a private subnet. That is all a matter > > of network configuration, there is nothing that requires the effort of an > > extra ES plugin. > > > > Jörg > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) wrote: > > > > > Hi I have been looking at the various transport plugins. Correct me if I > > > am wrong but those are for the http rest interface... Can plugins be > > > written for the node transport? > > > > > > Bassically this leads to securing ES. My ES is definitely not public and > > > I know i can use reverse proxies or one of the http plugins... But what > > > about client/programs connecting directly as nodes? > > > > > > Bassically I need user auth and some form of acl. SSL is secondary. Also > > > need to be able to audit the user access. Dealing with credit card data. So > > > I need to know 100% who is accessing the data. > > > > > > So... > > > What are some good steps to secure my ES cluster!? > > > > > > -- > > > 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](mailto:elasticsearc...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980% > > > [40googlegroups.com](http://40googlegroups.com). > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGXBVE4K0jGusJO-Ta0vcNZRZxiOxbfX4-E6\_n%2BSLHMZg%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGXBVE4K0jGusJO-Ta0vcNZRZxiOxbfX4-E6_n%2BSLHMZg%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![javadevmtl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javadevmtl/32/45613_2.png) [@javadevmtl](https://discuss.elastic.co/u/javadevmtl)\ **Post date:** [August 13, 2014, 7:23pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/6 "2014-08-13T19:23:05Z")
Hi thanks Jorg. Just to be sure, creating a plugin and overriding: transport.type and transport.service.type this allow us to create custom transport for TCP 9300 transport or the HTTP 9200 transport? I don't have a problem with using Subnet and firewall And Nginx or specified plugin. Or Custom application To secure ES from outside world. In fact that's pretty good. We run a web layer in DMZ and ES on a second layer. So only DMZ has access to ES. The question is how do you secure ES from the inside world? Anyone who has access to the subnet and to the ES cluster can just login and install their own "jobs" that can use port 9300 and do what ever they want with ES. Even a simple authentication would be better then nothing here. If what you said above allows us to replace 9300 transport, then awesome. The issue is Elasticsearch has built the really nice fast Ferari but opted out of providing even a simple door locking mechanism. Using nginx is like telling your neighbor to keep an eye on your car while you are away on the weekend and trusting they will do right. On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote: > With the configuration settings "transport.type" and > "transport.service.type" > > Example: > > transport.type: > org.xbib.elasticsearch.transport.syslog.netty.SyslogNettyTransportModule > transport.service.type: > org.xbib.elasticsearch.transport.syslog.SyslogTransportService > > you can implement your own transport layer. > > With this mechanism you can write plugins to create an audit trail of all > clients or nodes that connect to your cluster and you can log what they > did, for later revision. Or, you can add a registry for clients, add JAAS, > ... > > For example, I played with a modified netty transport layer to dump all > parsed transport actions between nodes to a remote host syslog, including > the action names and the channel connection information of local and remote > host/port. > > On such a custom transport layer implementation, you can add even more low > level logic. If you do not want certain nodes or clients to connect, you > could a) use zen unicast for manual configuration of permitted nodes or > clients and/or b) reject all network actions from unknown/unregistered > clients, independent of discovery. > > Note, manipulating transport layer is not free lunch and is not always > fun. Performance may degrade, other things may break etc. > > Jörg > > On Wed, Aug 13, 2014 at 5:07 PM, John Smith \<[java.d...@gmail.com](mailto:java.d...@gmail.com) > \\> wrote: > > > That's what I was thinking... > > > > 1- I would like this java app to use the node client, cause I like that > > fact that there no extra hop and automatic failover to next node. > > 2- I figure it would be a firewall setting/socks to only allow the java > > app to connect to ES. But again here anyone can go create a node client on > > the same machine and pull data anonymously. > > > > I know any one person can log in a machine at any time and any person can > > read regardless and it's ok, the data is supposed to be read but at least > > you know who read it and when. That's not an issue... Security is a best > > effort, but the issue is the audit process and how well you can check if > > all your eggs are there. > > > > Even if I do exactly as you said, subnet plus socks proxy, someone can > > still go to that machine create their own node client and bypass the java > > app with no direct trace. This will probably never happen, but all it takes > > is one angry employ. > > > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > > > You can write a Java app to authorize access with JAAS and use a SOCKS > > > proxy to connect to an ES cluster in a private subnet. That is all a matter > > > of network configuration, there is nothing that requires the effort of an > > > extra ES plugin. > > > > > > Jörg > > > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) wrote: > > > > > > > Hi I have been looking at the various transport plugins. Correct me if > > > > I am wrong but those are for the http rest interface... Can plugins be > > > > written for the node transport? > > > > > > > > Bassically this leads to securing ES. My ES is definitely not public > > > > and I know i can use reverse proxies or one of the http plugins... But what > > > > about client/programs connecting directly as nodes? > > > > > > > > Bassically I need user auth and some form of acl. SSL is secondary. > > > > Also need to be able to audit the user access. Dealing with credit card > > > > data. So I need to know 100% who is accessing the data. > > > > > > > > So... > > > > What are some good steps to secure my ES cluster!? > > > > > > > > -- > > > > 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](mailto:elasticsearc...@googlegroups.com). > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980% > > > > [40googlegroups.com](http://40googlegroups.com). > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/353287e7-16ba-4eb0-abcc-d632f5f98f13%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/353287e7-16ba-4eb0-abcc-d632f5f98f13%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![javadevmtl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javadevmtl/32/45613_2.png) [@javadevmtl](https://discuss.elastic.co/u/javadevmtl)\ **Post date:** [August 13, 2014, 7:52pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/7 "2014-08-13T19:52:19Z")
I think what allot of people is more like this? If I understand correctly... This runs above the 9300 transport. So you still get all the goodies/zen discovery etc... Plus added authentication. Except this only works with found... On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote: > Hi thanks Jorg. > > Just to be sure, creating a plugin and overriding: transport.type and > transport.service.type this allow us to create custom transport for TCP > 9300 transport or the HTTP 9200 transport? > > I don't have a problem with using > > Subnet and firewall > And > Nginx or specified plugin. > Or > Custom application > > To secure ES from outside world. In fact that's pretty good. > > We run a web layer in DMZ and ES on a second layer. So only DMZ has access > to ES. > > The question is how do you secure ES from the inside world? Anyone who has > access to the subnet and to the ES cluster can just login and install their > own "jobs" that can use port 9300 and do what ever they want with ES. Even > a simple authentication would be better then nothing here. > > If what you said above allows us to replace 9300 transport, then awesome. > The issue is Elasticsearch has built the really nice fast Ferari but opted > out of providing even a simple door locking mechanism. Using nginx is like > telling your neighbor to keep an eye on your car while you are away on the > weekend and trusting they will do right. > > On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote: > > > With the configuration settings "transport.type" and > > "transport.service.type" > > > > Example: > > > > transport.type: > > org.xbib.elasticsearch.transport.syslog.netty.SyslogNettyTransportModule > > transport.service.type: > > org.xbib.elasticsearch.transport.syslog.SyslogTransportService > > > > you can implement your own transport layer. > > > > With this mechanism you can write plugins to create an audit trail of all > > clients or nodes that connect to your cluster and you can log what they > > did, for later revision. Or, you can add a registry for clients, add JAAS, > > ... > > > > For example, I played with a modified netty transport layer to dump all > > parsed transport actions between nodes to a remote host syslog, including > > the action names and the channel connection information of local and remote > > host/port. > > > > On such a custom transport layer implementation, you can add even more > > low level logic. If you do not want certain nodes or clients to connect, > > you could a) use zen unicast for manual configuration of permitted nodes or > > clients and/or b) reject all network actions from unknown/unregistered > > clients, independent of discovery. > > > > Note, manipulating transport layer is not free lunch and is not always > > fun. Performance may degrade, other things may break etc. > > > > Jörg > > > > On Wed, Aug 13, 2014 at 5:07 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) wrote: > > > > > That's what I was thinking... > > > > > > 1- I would like this java app to use the node client, cause I like that > > > fact that there no extra hop and automatic failover to next node. > > > 2- I figure it would be a firewall setting/socks to only allow the java > > > app to connect to ES. But again here anyone can go create a node client on > > > the same machine and pull data anonymously. > > > > > > I know any one person can log in a machine at any time and any person > > > can read regardless and it's ok, the data is supposed to be read but at > > > least you know who read it and when. That's not an issue... Security is a > > > best effort, but the issue is the audit process and how well you can check > > > if all your eggs are there. > > > > > > Even if I do exactly as you said, subnet plus socks proxy, someone can > > > still go to that machine create their own node client and bypass the java > > > app with no direct trace. This will probably never happen, but all it takes > > > is one angry employ. > > > > > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > > > > > You can write a Java app to authorize access with JAAS and use a SOCKS > > > > proxy to connect to an ES cluster in a private subnet. That is all a matter > > > > of network configuration, there is nothing that requires the effort of an > > > > extra ES plugin. > > > > > > > > Jörg > > > > > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > wrote: > > > > > > > > > Hi I have been looking at the various transport plugins. Correct me if > > > > > I am wrong but those are for the http rest interface... Can plugins be > > > > > written for the node transport? > > > > > > > > > > Bassically this leads to securing ES. My ES is definitely not public > > > > > and I know i can use reverse proxies or one of the http plugins... But what > > > > > about client/programs connecting directly as nodes? > > > > > > > > > > Bassically I need user auth and some form of acl. SSL is secondary. > > > > > Also need to be able to audit the user access. Dealing with credit card > > > > > data. So I need to know 100% who is accessing the data. > > > > > > > > > > So... > > > > > What are some good steps to secure my ES cluster!? > > > > > > > > > > -- > > > > > 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](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980% > > > > > [40googlegroups.com](http://40googlegroups.com). > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [August 14, 2014, 6:54pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/8 "2014-08-14T18:54:43Z")
Yes, you can reimplement the transport layer. The config setting runs beyond the transport layer and if you get into a mood you could even throw port 9300 and all the netty code away. Not that I recommend it - but this is a very low-level, dark magic intrusion into the ES guts. You can break everything into pieces, including breaking the discovery basics etc. Jörg On Wed, Aug 13, 2014 at 9:52 PM, John Smith [java.dev.mtl@gmail.com](mailto:java.dev.mtl@gmail.com) wrote: > I think what allot of people is more like this? If I understand > correctly... This runs above the 9300 transport. So you still get all the > goodies/zen discovery etc... Plus added authentication. Except this only > works with found... > > On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote: > > > Hi thanks Jorg. > > > > Just to be sure, creating a plugin and overriding: transport.type and > > transport.service.type this allow us to create custom transport for TCP > > 9300 transport or the HTTP 9200 transport? > > > > I don't have a problem with using > > > > Subnet and firewall > > And > > Nginx or specified plugin. > > Or > > Custom application > > > > To secure ES from outside world. In fact that's pretty good. > > > > We run a web layer in DMZ and ES on a second layer. So only DMZ has > > access to ES. > > > > The question is how do you secure ES from the inside world? Anyone who > > has access to the subnet and to the ES cluster can just login and install > > their own "jobs" that can use port 9300 and do what ever they want with ES. > > Even a simple authentication would be better then nothing here. > > > > If what you said above allows us to replace 9300 transport, then awesome. > > The issue is Elasticsearch has built the really nice fast Ferari but opted > > out of providing even a simple door locking mechanism. Using nginx is like > > telling your neighbor to keep an eye on your car while you are away on the > > weekend and trusting they will do right. > > > > On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote: > > > > > With the configuration settings "transport.type" and > > > "transport.service.type" > > > > > > Example: > > > > > > transport.type: org.xbib.elasticsearch.transport.syslog.netty. > > > SyslogNettyTransportModule > > > transport.service.type: org.xbib.elasticsearch.transport.syslog. > > > SyslogTransportService > > > > > > you can implement your own transport layer. > > > > > > With this mechanism you can write plugins to create an audit trail of > > > all clients or nodes that connect to your cluster and you can log what they > > > did, for later revision. Or, you can add a registry for clients, add JAAS, > > > ... > > > > > > For example, I played with a modified netty transport layer to dump all > > > parsed transport actions between nodes to a remote host syslog, including > > > the action names and the channel connection information of local and remote > > > host/port. > > > > > > On such a custom transport layer implementation, you can add even more > > > low level logic. If you do not want certain nodes or clients to connect, > > > you could a) use zen unicast for manual configuration of permitted nodes or > > > clients and/or b) reject all network actions from unknown/unregistered > > > clients, independent of discovery. > > > > > > Note, manipulating transport layer is not free lunch and is not always > > > fun. Performance may degrade, other things may break etc. > > > > > > Jörg > > > > > > On Wed, Aug 13, 2014 at 5:07 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) wrote: > > > > > > > That's what I was thinking... > > > > > > > > 1- I would like this java app to use the node client, cause I like that > > > > fact that there no extra hop and automatic failover to next node. > > > > 2- I figure it would be a firewall setting/socks to only allow the java > > > > app to connect to ES. But again here anyone can go create a node client on > > > > the same machine and pull data anonymously. > > > > > > > > I know any one person can log in a machine at any time and any person > > > > can read regardless and it's ok, the data is supposed to be read but at > > > > least you know who read it and when. That's not an issue... Security is a > > > > best effort, but the issue is the audit process and how well you can check > > > > if all your eggs are there. > > > > > > > > Even if I do exactly as you said, subnet plus socks proxy, someone can > > > > still go to that machine create their own node client and bypass the java > > > > app with no direct trace. This will probably never happen, but all it takes > > > > is one angry employ. > > > > > > > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > > > > > > > You can write a Java app to authorize access with JAAS and use a SOCKS > > > > > proxy to connect to an ES cluster in a private subnet. That is all a matter > > > > > of network configuration, there is nothing that requires the effort of an > > > > > extra ES plugin. > > > > > > > > > > Jörg > > > > > > > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > > wrote: > > > > > > > > > > > Hi I have been looking at the various transport plugins. Correct me > > > > > > if I am wrong but those are for the http rest interface... Can plugins be > > > > > > written for the node transport? > > > > > > > > > > > > Bassically this leads to securing ES. My ES is definitely not public > > > > > > and I know i can use reverse proxies or one of the http plugins... But what > > > > > > about client/programs connecting directly as nodes? > > > > > > > > > > > > Bassically I need user auth and some form of acl. SSL is secondary. > > > > > > Also need to be able to audit the user access. Dealing with credit card > > > > > > data. So I need to know 100% who is accessing the data. > > > > > > > > > > > > So... > > > > > > What are some good steps to secure my ES cluster!? > > > > > > > > > > > > -- > > > > > > 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](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > msgid/elasticsearch/1ef17a07-bd72-4eee-a6b9-93ff8d0e7980%40goo > > > > > > [glegroups.com](http://glegroups.com). > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5% > > > > > [40googlegroups.com](http://40googlegroups.com) > > > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGRd7gdztL4rn7mavmx0fCUEn%3DG7A9\_T3FdC\_\_42PM2Aw%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoGRd7gdztL4rn7mavmx0fCUEn%3DG7A9_T3FdC__42PM2Aw%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![javadevmtl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javadevmtl/32/45613_2.png) [@javadevmtl](https://discuss.elastic.co/u/javadevmtl)\ **Post date:** [August 14, 2014, 10:03pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/9 "2014-08-14T22:03:19Z")
Yeah I tried the foundit plugin and just striped away all their code and it's just a pass through! But would def need to figure out the inards. We have web app in dmz and then ES at lower level. But again it's about protecting from the inside. When having a bunch of support staff that are capable of accessing the box for admin purposes and support... My admin guy is a smart dude and he understands you can only go so far! We just have to see if it's acceptable. On Thursday, 14 August 2014 14:54:51 UTC-4, Jörg Prante wrote: > Yes, you can reimplement the transport layer. The config setting runs > beyond the transport layer and if you get into a mood you could even throw > port 9300 and all the netty code away. Not that I recommend it - but this > is a very low-level, dark magic intrusion into the ES guts. You can break > everything into pieces, including breaking the discovery basics etc. > > Jörg > > On Wed, Aug 13, 2014 at 9:52 PM, John Smith \<[java.d...@gmail.com](mailto:java.d...@gmail.com) > \\> wrote: > > > I think what allot of people is more like this? If I understand > > correctly... This runs above the 9300 transport. So you still get all the > > goodies/zen discovery etc... Plus added authentication. Except this only > > works with found... > > > > On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote: > > > > > Hi thanks Jorg. > > > > > > Just to be sure, creating a plugin and overriding: transport.type and > > > transport.service.type this allow us to create custom transport for TCP > > > 9300 transport or the HTTP 9200 transport? > > > > > > I don't have a problem with using > > > > > > Subnet and firewall > > > And > > > Nginx or specified plugin. > > > Or > > > Custom application > > > > > > To secure ES from outside world. In fact that's pretty good. > > > > > > We run a web layer in DMZ and ES on a second layer. So only DMZ has > > > access to ES. > > > > > > The question is how do you secure ES from the inside world? Anyone who > > > has access to the subnet and to the ES cluster can just login and install > > > their own "jobs" that can use port 9300 and do what ever they want with ES. > > > Even a simple authentication would be better then nothing here. > > > > > > If what you said above allows us to replace 9300 transport, then > > > awesome. The issue is Elasticsearch has built the really nice fast Ferari > > > but opted out of providing even a simple door locking mechanism. Using > > > nginx is like telling your neighbor to keep an eye on your car while you > > > are away on the weekend and trusting they will do right. > > > > > > On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote: > > > > > > > With the configuration settings "transport.type" and > > > > "transport.service.type" > > > > > > > > Example: > > > > > > > > transport.type: org.xbib.elasticsearch.transport.syslog.netty. > > > > SyslogNettyTransportModule > > > > transport.service.type: org.xbib.elasticsearch.transport.syslog. > > > > SyslogTransportService > > > > > > > > you can implement your own transport layer. > > > > > > > > With this mechanism you can write plugins to create an audit trail of > > > > all clients or nodes that connect to your cluster and you can log what they > > > > did, for later revision. Or, you can add a registry for clients, add JAAS, > > > > ... > > > > > > > > For example, I played with a modified netty transport layer to dump all > > > > parsed transport actions between nodes to a remote host syslog, including > > > > the action names and the channel connection information of local and remote > > > > host/port. > > > > > > > > On such a custom transport layer implementation, you can add even more > > > > low level logic. If you do not want certain nodes or clients to connect, > > > > you could a) use zen unicast for manual configuration of permitted nodes or > > > > clients and/or b) reject all network actions from unknown/unregistered > > > > clients, independent of discovery. > > > > > > > > Note, manipulating transport layer is not free lunch and is not always > > > > fun. Performance may degrade, other things may break etc. > > > > > > > > Jörg > > > > > > > > On Wed, Aug 13, 2014 at 5:07 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > wrote: > > > > > > > > > That's what I was thinking... > > > > > > > > > > 1- I would like this java app to use the node client, cause I like > > > > > that fact that there no extra hop and automatic failover to next node. > > > > > 2- I figure it would be a firewall setting/socks to only allow the > > > > > java app to connect to ES. But again here anyone can go create a node > > > > > client on the same machine and pull data anonymously. > > > > > > > > > > I know any one person can log in a machine at any time and any person > > > > > can read regardless and it's ok, the data is supposed to be read but at > > > > > least you know who read it and when. That's not an issue... Security is a > > > > > best effort, but the issue is the audit process and how well you can check > > > > > if all your eggs are there. > > > > > > > > > > Even if I do exactly as you said, subnet plus socks proxy, someone can > > > > > still go to that machine create their own node client and bypass the java > > > > > app with no direct trace. This will probably never happen, but all it takes > > > > > is one angry employ. > > > > > > > > > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > > > > > > > > > You can write a Java app to authorize access with JAAS and use a > > > > > > SOCKS proxy to connect to an ES cluster in a private subnet. That is all a > > > > > > matter of network configuration, there is nothing that requires the effort > > > > > > of an extra ES plugin. > > > > > > > > > > > > Jörg > > > > > > > > > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > > > wrote: > > > > > > > > > > > > > Hi I have been looking at the various transport plugins. Correct me > > > > > > > if I am wrong but those are for the http rest interface... Can plugins be > > > > > > > written for the node transport? > > > > > > > > > > > > > > Bassically this leads to securing ES. My ES is definitely not public > > > > > > > and I know i can use reverse proxies or one of the http plugins... But what > > > > > > > about client/programs connecting directly as nodes? > > > > > > > > > > > > > > Bassically I need user auth and some form of acl. SSL is secondary. > > > > > > > Also need to be able to audit the user access. Dealing with credit card > > > > > > > data. So I need to know 100% who is accessing the data. > > > > > > > > > > > > > > So... > > > > > > > What are some good steps to secure my ES cluster!? > > > > > > > > > > > > > > -- > > > > > > > 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](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > > > To view this discussion on the web visit > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7](https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7) > > > > > > > 2-4eee-a6b9-93ff8d0e7980%[40googlegroups.com](http://40googlegroups.com). > > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5% > > > > > > [40googlegroups.com](http://40googlegroups.com) > > > > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > . > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > > To view this discussion on the web visit > > > > [https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com) > > > > [https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > . > > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [August 15, 2014, 9:04am UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/10 "2014-08-15T09:04:23Z")
You can not protect from superuser access from within an app, except when you are also a superuser, and can create obscure kernel capabilities to protect an app from another superuser. Usually this is not solvable by technical solutions, it is a matter of trust into the infrastructure (data center, network, staff). Jörg On Fri, Aug 15, 2014 at 12:03 AM, John Smith [java.dev.mtl@gmail.com](mailto:java.dev.mtl@gmail.com) wrote: > Yeah I tried the foundit plugin and just striped away all their code and > it's just a pass through! But would def need to figure out the inards. > > We have web app in dmz and then ES at lower level. But again it's about > protecting from the inside. When having a bunch of support staff that are > capable of accessing the box for admin purposes and support... My admin guy > is a smart dude and he understands you can only go so far! We just have to > see if it's acceptable. > > On Thursday, 14 August 2014 14:54:51 UTC-4, Jörg Prante wrote: > > > Yes, you can reimplement the transport layer. The config setting runs > > beyond the transport layer and if you get into a mood you could even throw > > port 9300 and all the netty code away. Not that I recommend it - but this > > is a very low-level, dark magic intrusion into the ES guts. You can break > > everything into pieces, including breaking the discovery basics etc. > > > > Jörg > > > > On Wed, Aug 13, 2014 at 9:52 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) wrote: > > > > > I think what allot of people is more like this? If I understand > > > correctly... This runs above the 9300 transport. So you still get all the > > > goodies/zen discovery etc... Plus added authentication. Except this only > > > works with found... > > > > > > On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote: > > > > > > > Hi thanks Jorg. > > > > > > > > Just to be sure, creating a plugin and overriding: transport.type and > > > > transport.service.type this allow us to create custom transport for TCP > > > > 9300 transport or the HTTP 9200 transport? > > > > > > > > I don't have a problem with using > > > > > > > > Subnet and firewall > > > > And > > > > Nginx or specified plugin. > > > > Or > > > > Custom application > > > > > > > > To secure ES from outside world. In fact that's pretty good. > > > > > > > > We run a web layer in DMZ and ES on a second layer. So only DMZ has > > > > access to ES. > > > > > > > > The question is how do you secure ES from the inside world? Anyone who > > > > has access to the subnet and to the ES cluster can just login and install > > > > their own "jobs" that can use port 9300 and do what ever they want with ES. > > > > Even a simple authentication would be better then nothing here. > > > > > > > > If what you said above allows us to replace 9300 transport, then > > > > awesome. The issue is Elasticsearch has built the really nice fast Ferari > > > > but opted out of providing even a simple door locking mechanism. Using > > > > nginx is like telling your neighbor to keep an eye on your car while you > > > > are away on the weekend and trusting they will do right. > > > > > > > > On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote: > > > > > > > > > With the configuration settings "transport.type" and > > > > > "transport.service.type" > > > > > > > > > > Example: > > > > > > > > > > transport.type: org.xbib.elasticsearch.transport.syslog.netty. > > > > > SyslogNettyTransportModule > > > > > transport.service.type: org.xbib.elasticsearch.transport.syslog. > > > > > SyslogTransportService > > > > > > > > > > you can implement your own transport layer. > > > > > > > > > > With this mechanism you can write plugins to create an audit trail of > > > > > all clients or nodes that connect to your cluster and you can log what they > > > > > did, for later revision. Or, you can add a registry for clients, add JAAS, > > > > > ... > > > > > > > > > > For example, I played with a modified netty transport layer to dump > > > > > all parsed transport actions between nodes to a remote host syslog, > > > > > including the action names and the channel connection information of local > > > > > and remote host/port. > > > > > > > > > > On such a custom transport layer implementation, you can add even more > > > > > low level logic. If you do not want certain nodes or clients to connect, > > > > > you could a) use zen unicast for manual configuration of permitted nodes or > > > > > clients and/or b) reject all network actions from unknown/unregistered > > > > > clients, independent of discovery. > > > > > > > > > > Note, manipulating transport layer is not free lunch and is not always > > > > > fun. Performance may degrade, other things may break etc. > > > > > > > > > > Jörg > > > > > > > > > > On Wed, Aug 13, 2014 at 5:07 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > > wrote: > > > > > > > > > > > That's what I was thinking... > > > > > > > > > > > > 1- I would like this java app to use the node client, cause I like > > > > > > that fact that there no extra hop and automatic failover to next node. > > > > > > 2- I figure it would be a firewall setting/socks to only allow the > > > > > > java app to connect to ES. But again here anyone can go create a node > > > > > > client on the same machine and pull data anonymously. > > > > > > > > > > > > I know any one person can log in a machine at any time and any person > > > > > > can read regardless and it's ok, the data is supposed to be read but at > > > > > > least you know who read it and when. That's not an issue... Security is a > > > > > > best effort, but the issue is the audit process and how well you can check > > > > > > if all your eggs are there. > > > > > > > > > > > > Even if I do exactly as you said, subnet plus socks proxy, someone > > > > > > can still go to that machine create their own node client and bypass the > > > > > > java app with no direct trace. This will probably never happen, but all it > > > > > > takes is one angry employ. > > > > > > > > > > > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > > > > > > > > > > > You can write a Java app to authorize access with JAAS and use a > > > > > > > SOCKS proxy to connect to an ES cluster in a private subnet. That is all a > > > > > > > matter of network configuration, there is nothing that requires the effort > > > > > > > of an extra ES plugin. > > > > > > > > > > > > > > Jörg > > > > > > > > > > > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > > > > wrote: > > > > > > > > > > > > > > > Hi I have been looking at the various transport plugins. Correct me > > > > > > > > if I am wrong but those are for the http rest interface... Can plugins be > > > > > > > > written for the node transport? > > > > > > > > > > > > > > > > Bassically this leads to securing ES. My ES is definitely not > > > > > > > > public and I know i can use reverse proxies or one of the http plugins... > > > > > > > > But what about client/programs connecting directly as nodes? > > > > > > > > > > > > > > > > Bassically I need user auth and some form of acl. SSL is secondary. > > > > > > > > Also need to be able to audit the user access. Dealing with credit card > > > > > > > > data. So I need to know 100% who is accessing the data. > > > > > > > > > > > > > > > > So... > > > > > > > > What are some good steps to secure my ES cluster!? > > > > > > > > > > > > > > > > -- > > > > > > > > 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](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > > > > > To view this discussion on the web visit > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7](https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7) > > > > > > > > 2-4eee-a6b9-93ff8d0e7980%[40googlegroups.com](http://40googlegroups.com). > > > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > > msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40goo > > > > > > > [glegroups.com](http://glegroups.com) > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > > . > > > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f% > > > > > [40googlegroups.com](http://40googlegroups.com) > > > > > [https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > . > > > > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > > To view this discussion on the web visit > > [https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com) > > [https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com?utm_medium=email&utm_source=footer) > > . > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHHL6nZLsR-YZf5vnjZYzhtFW5pwZqU3S5dzGKBpYJ4PA%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAKdsXoHHL6nZLsR-YZf5vnjZYzhtFW5pwZqU3S5dzGKBpYJ4PA%40mail.gmail.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![javadevmtl](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/javadevmtl/32/45613_2.png) [@javadevmtl](https://discuss.elastic.co/u/javadevmtl)\ **Post date:** [August 15, 2014, 3:35pm UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/11 "2014-08-15T15:35:43Z")
Of course understood. I think subnetting/double firewall. DMZ will not have access to 9300 and internal network will not have access to 9300 only subnet for ES cluster functions. On Friday, 15 August 2014 05:04:35 UTC-4, Jörg Prante wrote: > You can not protect from superuser access from within an app, except when > you are also a superuser, and can create obscure kernel capabilities to > protect an app from another superuser. > > Usually this is not solvable by technical solutions, it is a matter of > trust into the infrastructure (data center, network, staff). > > Jörg > > On Fri, Aug 15, 2014 at 12:03 AM, John Smith \<[java.d...@gmail.com](mailto:java.d...@gmail.com) > \\> wrote: > > > Yeah I tried the foundit plugin and just striped away all their code and > > it's just a pass through! But would def need to figure out the inards. > > > > We have web app in dmz and then ES at lower level. But again it's about > > protecting from the inside. When having a bunch of support staff that are > > capable of accessing the box for admin purposes and support... My admin guy > > is a smart dude and he understands you can only go so far! We just have to > > see if it's acceptable. > > > > On Thursday, 14 August 2014 14:54:51 UTC-4, Jörg Prante wrote: > > > > > Yes, you can reimplement the transport layer. The config setting runs > > > beyond the transport layer and if you get into a mood you could even throw > > > port 9300 and all the netty code away. Not that I recommend it - but this > > > is a very low-level, dark magic intrusion into the ES guts. You can break > > > everything into pieces, including breaking the discovery basics etc. > > > > > > Jörg > > > > > > On Wed, Aug 13, 2014 at 9:52 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) wrote: > > > > > > > I think what allot of people is more like this? If I understand > > > > correctly... This runs above the 9300 transport. So you still get all the > > > > goodies/zen discovery etc... Plus added authentication. Except this only > > > > works with found... > > > > > > > > On Wednesday, 13 August 2014 15:23:05 UTC-4, John Smith wrote: > > > > > > > > > Hi thanks Jorg. > > > > > > > > > > Just to be sure, creating a plugin and overriding: transport.type and > > > > > transport.service.type this allow us to create custom transport for TCP > > > > > 9300 transport or the HTTP 9200 transport? > > > > > > > > > > I don't have a problem with using > > > > > > > > > > Subnet and firewall > > > > > And > > > > > Nginx or specified plugin. > > > > > Or > > > > > Custom application > > > > > > > > > > To secure ES from outside world. In fact that's pretty good. > > > > > > > > > > We run a web layer in DMZ and ES on a second layer. So only DMZ has > > > > > access to ES. > > > > > > > > > > The question is how do you secure ES from the inside world? Anyone who > > > > > has access to the subnet and to the ES cluster can just login and install > > > > > their own "jobs" that can use port 9300 and do what ever they want with ES. > > > > > Even a simple authentication would be better then nothing here. > > > > > > > > > > If what you said above allows us to replace 9300 transport, then > > > > > awesome. The issue is Elasticsearch has built the really nice fast Ferari > > > > > but opted out of providing even a simple door locking mechanism. Using > > > > > nginx is like telling your neighbor to keep an eye on your car while you > > > > > are away on the weekend and trusting they will do right. > > > > > > > > > > On Wednesday, 13 August 2014 14:21:01 UTC-4, Jörg Prante wrote: > > > > > > > > > > > With the configuration settings "transport.type" and > > > > > > "transport.service.type" > > > > > > > > > > > > Example: > > > > > > > > > > > > transport.type: org.xbib.elasticsearch.transport.syslog.netty. > > > > > > SyslogNettyTransportModule > > > > > > transport.service.type: org.xbib.elasticsearch.transport.syslog. > > > > > > SyslogTransportService > > > > > > > > > > > > you can implement your own transport layer. > > > > > > > > > > > > With this mechanism you can write plugins to create an audit trail of > > > > > > all clients or nodes that connect to your cluster and you can log what they > > > > > > did, for later revision. Or, you can add a registry for clients, add JAAS, > > > > > > ... > > > > > > > > > > > > For example, I played with a modified netty transport layer to dump > > > > > > all parsed transport actions between nodes to a remote host syslog, > > > > > > including the action names and the channel connection information of local > > > > > > and remote host/port. > > > > > > > > > > > > On such a custom transport layer implementation, you can add even > > > > > > more low level logic. If you do not want certain nodes or clients to > > > > > > connect, you could a) use zen unicast for manual configuration of permitted > > > > > > nodes or clients and/or b) reject all network actions from > > > > > > unknown/unregistered clients, independent of discovery. > > > > > > > > > > > > Note, manipulating transport layer is not free lunch and is not > > > > > > always fun. Performance may degrade, other things may break etc. > > > > > > > > > > > > Jörg > > > > > > > > > > > > On Wed, Aug 13, 2014 at 5:07 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > > > wrote: > > > > > > > > > > > > > That's what I was thinking... > > > > > > > > > > > > > > 1- I would like this java app to use the node client, cause I like > > > > > > > that fact that there no extra hop and automatic failover to next node. > > > > > > > 2- I figure it would be a firewall setting/socks to only allow the > > > > > > > java app to connect to ES. But again here anyone can go create a node > > > > > > > client on the same machine and pull data anonymously. > > > > > > > > > > > > > > I know any one person can log in a machine at any time and any > > > > > > > person can read regardless and it's ok, the data is supposed to be read but > > > > > > > at least you know who read it and when. That's not an issue... Security is > > > > > > > a best effort, but the issue is the audit process and how well you can > > > > > > > check if all your eggs are there. > > > > > > > > > > > > > > Even if I do exactly as you said, subnet plus socks proxy, someone > > > > > > > can still go to that machine create their own node client and bypass the > > > > > > > java app with no direct trace. This will probably never happen, but all it > > > > > > > takes is one angry employ. > > > > > > > > > > > > > > On Wednesday, 13 August 2014 09:50:25 UTC-4, Jörg Prante wrote: > > > > > > > > > > > > > > > You can write a Java app to authorize access with JAAS and use a > > > > > > > > SOCKS proxy to connect to an ES cluster in a private subnet. That is all a > > > > > > > > matter of network configuration, there is nothing that requires the effort > > > > > > > > of an extra ES plugin. > > > > > > > > > > > > > > > > Jörg > > > > > > > > > > > > > > > > On Wed, Aug 13, 2014 at 3:38 PM, John Smith [java.d...@gmail.com](mailto:java.d...@gmail.com) > > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi I have been looking at the various transport plugins. Correct > > > > > > > > > me if I am wrong but those are for the http rest interface... Can plugins > > > > > > > > > be written for the node transport? > > > > > > > > > > > > > > > > > > Bassically this leads to securing ES. My ES is definitely not > > > > > > > > > public and I know i can use reverse proxies or one of the http plugins... > > > > > > > > > But what about client/programs connecting directly as nodes? > > > > > > > > > > > > > > > > > > Bassically I need user auth and some form of acl. SSL is > > > > > > > > > secondary. Also need to be able to audit the user access. Dealing with > > > > > > > > > credit card data. So I need to know 100% who is accessing the data. > > > > > > > > > > > > > > > > > > So... > > > > > > > > > What are some good steps to secure my ES cluster!? > > > > > > > > > > > > > > > > > > -- > > > > > > > > > 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](mailto:elasticsearc...@googlegroups.com). > > > > > > > > > > > > > > > > > > To view this discussion on the web visit > > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7](https://groups.google.com/d/msgid/elasticsearch/1ef17a07-bd7) > > > > > > > > > 2-4eee-a6b9-93ff8d0e7980%[40googlegroups.com](http://40googlegroups.com). > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > > > To view this discussion on the web visit > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8) > > > > > > > > b-43c8-b818-4f942a02daf5%[40googlegroups.com](http://40googlegroups.com) > > > > > > > > [https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/648c4a70-ff8b-43c8-b818-4f942a02daf5%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > > > . > > > > > > > > > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > > > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/) > > > > > > msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f% > > > > > > [40googlegroups.com](http://40googlegroups.com) > > > > > > [https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/68e0b7c5-a67e-447b-b938-fce0d5a2bf5f%40googlegroups.com?utm_medium=email&utm_source=footer) > > > > > > . > > > > > > > > For more options, visit [https://groups.google.com/d/optout](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 [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com) > > > [https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/272e8550-9967-4977-92ad-625622e433e6%40googlegroups.com?utm_medium=email&utm_source=footer) > > > . > > > > For more options, visit [https://groups.google.com/d/optout](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+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/7e43e349-7403-41da-a3ab-cf5ad2e3e3e7%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7e43e349-7403-41da-a3ab-cf5ad2e3e3e7%40googlegroups.com). For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 1:08am UTC](https://discuss.elastic.co/t/can-plugin-be-written-for-tcp-transport/19257/12 "2017-07-06T01:08:17Z")